CloudWatch vs CloudTrail vs AWS Config: Monitoring, Auditing, and Change Tracking

These three services appear in almost every CLF-C02 exam — and confuse even experienced engineers because their names all sound like 'watching things.' The clean split: performance, activity, configuration.

CloudWatch — how is it performing?

• Metrics (CPU, latency, custom metrics), alarms on thresholds, dashboards
• Logs from Lambda, applications, agents — with metric filters and Insights queries
• Answers: 'is CPU high?', 'why did this alarm fire?', 'show me error counts'
• Time-series focused — it's about state over time, not events or history

CloudTrail — who did what?

• Every API call in the account: who, what action, when, from where, on what resource
• Event history (90 days free) and organization trails to S3 for permanent audit
• Answers: 'who deleted the bucket?', 'who modified the security group?', 'was this API call made?'
• The forensic/audit layer — enabled by default at the account level

AWS Config — what is the configuration state?

• Configuration timeline: snapshots of resource settings and how they changed over time
• Config rules evaluate compliance: 'are all buckets encrypted?', 'is MFA enabled?'
• Remediation actions can auto-fix drift via SSM documents
• Answers: 'when did this SG rule change?', 'is this resource compliant?', 'what did the VPC look like last week?'

The scenario test

They compose in practice: CloudTrail captures the event, Config tracks the resulting state change, and CloudWatch alarms on the operational impact.

• 'Who terminated the instance?' → CloudTrail (API activity)
• 'Why did the app slow down at 3am?' → CloudWatch (metrics/logs)
• 'When did the security group start allowing 0.0.0.0/0?' → Config (config timeline)
• 'Alert me when any bucket becomes public' → Config rule (+ optional remediation)
• 'Notify me when root is used' → CloudTrail event + EventBridge → alert