Monitoring Operations

User asks about CloudWatch metrics, alarms, instance health, maintenance windows, backups, snapshots, or operational best practices.

Discover CloudWatch Metrics

Before naming or configuring a metric, retrieve the service monitoring documentation for the selected engine variant and deployment type, then inspect the metrics published for the resource in its account and Region:

Follow metric discovery to verify the exact metric name, namespace, dimensions, unit, and supported statistics. Use only values confirmed by the documentation or observed telemetry. An empty list-metrics result is not proof that a metric is unsupported; verify the account, Region, dimensions, publication activity, and documentation before drawing that conclusion.

Recommended Alarm Configuration

Derive thresholds from the metric’s documented semantics, resource capacity, workload baseline, and operational objectives. For a signal not exposed through CloudWatch, use only an alternative monitoring surface documented for the selected engine variant and deployment.

MUST: Enable SSE-KMS on your SNS topic to encrypt alarm notifications at rest — never use at-rest unencrypted notifications for operational data. Alarm notifications can contain operationally sensitive information (instance IDs, metric thresholds, account details). Ensure your SNS topic access policy restricts sns:Subscribe to authorized principals only, and verify that all subscription endpoints (email, HTTPS, Lambda) belong to your organization. If alarm notifications are also delivered to CloudWatch Logs, enable SSE-KMS encryption on those log groups as well.

Before connecting a CloudWatch alarm to a topic encrypted with a customer-managed KMS key, retrieve the Amazon SNS key-management guidance (opens in a new tab) and CloudWatch alarm-notification guidance (opens in a new tab). Verify the service principal, required KMS actions, and supported source conditions. Merge the documented permissions into the existing policy of <kms-key-arn>; if the retrieved guidance differs from this template, use the retrieved values:

In a KMS key policy, "Resource": "*" refers only to the KMS key to which the policy is attached. Keep the source-account condition and use the full ARN of each authorized alarm; when a topic serves multiple alarms, list their ARNs rather than broadening access beyond the intended alarms.

Merge this statement into the topic’s existing resource policy, preserving its administrative statements:

Apply the merged policy with aws sns set-topic-attributes --topic-arn "$SNS_TOPIC_ARN" --attribute-name Policy --attribute-value file://<merged-topic-policy.json>. Then run aws sns list-subscriptions-by-topic --topic-arn "$SNS_TOPIC_ARN" and confirm every endpoint and protocol is authorized before connecting the topic to an alarm.

Maintenance Windows

Customer Managed Maintenance Windows:

• Set preferred day, time, and timezone via console, CLI, or SDK
• Engine patches and minor updates applied during the window
• Major version changes require explicit approval

Backup & Snapshots

• Before providing backup guidance, verify the customer-managed backup and restore documentation (opens in a new tab) and Timestream for InfluxDB CLI or SDK API model. Confirm support by engine variant and Region for on-demand, scheduled, continuous, point-in-time, and self-service restore capabilities rather than treating any of them as universally available.
• When the API exposes CreateDbBackup, DbBackupConfiguration, or RestoreFromDbBackup, describe the resulting DbBackup resources as backups, not snapshots.
• Before selecting a restore mode, verify the restrictions in the RestoreFromDbBackup Boto3 reference (opens in a new tab) and the customer-managed backup and restore documentation (opens in a new tab). When those sources prohibit REPLACE_EXISTING for a cluster encrypted with a customer-managed KMS key, use NEW_RESOURCE.
• Verify the documentation for service-managed snapshot accessibility and recovery before describing an AWS Support path. Check the API model before asserting that a customer-managed snapshot operation is absent; regardless of API evolution, do not relabel a DbBackup resource as a snapshot.
• For an independent, portable copy, use the InfluxDB data-plane API and store the export in an S3 bucket protected with SSE-KMS. Never put a token literal in the command or write an unencrypted export to local disk.

Load INFLUX_TOKEN or V3_TOKEN from Secrets Manager using the patterns in getting started, keep shell tracing disabled, and then export:

Delete staging data only after a successful S3 upload, following the organization’s secure-deletion policy; preserve it on failure so the upload can be retried. Keep shell tracing disabled, unset token variables immediately after use, and restrict the backup bucket and KMS key policies to authorized backup and restore roles.

AWS CloudTrail Integration

Before asserting event coverage, retrieve the Timestream for InfluxDB CloudTrail documentation (opens in a new tab). Configure a trail to record the management-event classes and operations that documentation lists, retain them according to organizational policy, and apply the CloudTrail S3 encryption and log-file validation controls in security best practices.

Do not infer data-plane coverage from management-event coverage. Verify native audit-log and metrics availability for the selected engine variant before recommending data-access monitoring, and state only the coverage the service documentation confirms.

Operational Checklist

• Not done: CloudWatch alarms configured for each verified resource-health and capacity signal
• Not done: Maintenance window set to low-traffic period
• Not done: Backup and restore strategy defined after verifying DbBackup, restore, and data-plane export capabilities
• Not done: SNS topic and its customer-managed KMS key permit only the intended CloudWatch alarms and authorized subscribers
• Not done: CloudTrail event coverage verified and a trail configured for the documented management events
• Not done: Instance right-sized for workload (check CPU/memory utilization trends)
• Not done: Storage monitoring uses the documented surface for the selected engine variant and deployment