Monitoring, Logging, and Remediation
Metrics and alarms
CloudWatch is the operational hub. EC2 basic monitoring publishes every 5 minutes; detailed monitoring (paid) every 1 minute. Memory, disk usage, and swap are not default EC2 metrics - they require the CloudWatch agent as a custom metric. Alarm states are OK, ALARM, and INSUFFICIENT_DATA, and actions fire on state transitions only. Configure Period, Evaluation Periods, and Datapoints to Alarm (M of N) for flapping tolerance, and choose Treat Missing Data deliberately (notBreaching, breaching, ignore, missing).
Logs and audit
CloudWatch Logs groups streams under log groups; retention defaults to never expire. Metric filters turn log patterns into metrics; subscription filters stream to Lambda, Kinesis, or Firehose. CloudTrail records API calls - management events by default, data events (S3 object-level, Lambda invoke) only when enabled - and can validate log file integrity. Config records configuration history and evaluates rules; it detects, it does not block.
Remediation
EventBridge rules pattern-match events such as an EC2 state change or a Config compliance change and invoke Lambda, SSM Automation, or SNS. Systems Manager Automation documents can stop, resize, snapshot, or re-tag resources; OpsCenter aggregates operational issues.
Traps
Questions often offer SNS where an automated fix is needed - SNS only notifies. Alarms cannot act on metrics in another region. An Auto Scaling CPU alarm must use the ASG dimension, not per-instance metrics.
Rule of thumb
Remediation = detection (alarm, EventBridge, or Config) + action (SSM Automation or Lambda) + notification (SNS). For a new-instance CPU alarm use 3 x 60 s periods, 2 of 3 datapoints, and Treat Missing Data = notBreaching so boot does not trigger it.