aws-cloudwatch-investigation

Use a Logs Insights query that filters messages matching error patterns like /(?i)(error|exception|fatal|critical)/, then aggregate with stats count by 5-minute bins and log stream. Sorting by error count descending surfaces the noisiest sources first.

Note the exact alarm transition timestamp, then query CloudTrail Lake for deployment events like UpdateFunctionCode or CreateDeployment in the prior 30 minutes. A deploy is correlated if it targets the same resource, completed within 15 minutes before the alarm, and came from a CI/CD role.

Filter log entries where @initDuration is present, since that field only appears on cold start invocations. Aggregate count, average, and max init duration by 5-minute bins to quantify cold start frequency and impact during an incident.

Yes, use GetMetricData with two p99 Duration queries—one for the current window and one for the same window last week—then divide them in a metric math expression. A ratio above 2 indicates an anomalous latency regression versus baseline.

Alarm state changes include a built-in evaluation delay equal to the period multiplied by the number of evaluation periods. Metric timestamps are also end-of-period, so the underlying anomaly typically started earlier than the alarm transition time suggests.

CloudTrail events can have up to 15-minute delivery delay, so recent changes may not appear immediately. Always use eventTime rather than ingestion time when reconstructing timelines, and cross-check with logs and metrics for the earliest symptom.