Monitoring, Logging, and Remediation
What you must know
CloudWatch metrics, alarms, and dashboards; CloudWatch Logs (log groups, streams, metric filters, subscription filters); CloudTrail (management vs data events, trails, EventBridge integration); AWS Config rules and conformance packs; Systems Manager (OpsCenter, Automation, Patch Manager, State Manager); EventBridge rules and targets; SNS/SQS fan-out; X-Ray and ServiceLens.
Traps that show up in questions
- Default vs detailed monitoring: EC2 basic metrics arrive at 5-minute granularity; detailed monitoring is 1 minute and costs extra. Alarm evaluation on a 1-minute metric with a 5-minute period behaves differently than candidates assume.
- Missing metrics: memory, disk, and swap are not default EC2 metrics. You need the CloudWatch agent (or a custom metric). A question offering "create an alarm on memory" is testing this.
- Metric filters vs subscription filters: metric filters turn log events into numeric metrics for alarming; subscription filters stream logs to Kinesis/Lambda/Firehose for processing.
- CloudTrail data events are off by default (S3 object-level, Lambda invoke). Management events are on by default in a trail.
- Alarm actions need a target: SNS topic, Auto Scaling action, or EC2 action. An alarm with no action is just a state change.
- EventBridge vs CloudWatch Events: same service lineage; EventBridge is the current name and adds partner/SaaS buses and schema registry.
Worked rule of thumb
To remediate a non-compliant resource automatically: AWS Config rule detects non-compliance → Config sends an event to EventBridge → EventBridge rule targets an SSM Automation document → document fixes the resource. This "detect → event → automate" chain is the canonical answer whenever a question asks for automatic remediation of drift or policy violation.
Remember: alarms evaluate metrics, EventBridge reacts to events, Config evaluates resource configuration. Pick the layer that matches the trigger described.