CloudWatch vs CloudTrail vs AWS Config: what each one actually audits

A security group rule changes and, ten minutes later, an alarm fires. Three services can each tell you part of the story, and most teams have only one of them fully wired up. CloudWatch tells you something broke. CloudTrail tells you who touched the resource last. AWS Config tells you exactly what changed about its configuration, with a before-and-after diff. None of the three does what the other two do — that's the point, not a gap.

• What does each of the three actually audit?
• CloudWatch: how the system is performing
• CloudTrail: who did it
• AWS Config: what changed
• The gap most teams actually have
• Putting it together during a real incident

What does each of the three actually audit?

CloudWatch audits performance — metrics and logs that answer how a system is behaving right now. CloudTrail audits identity — every API call, answering who did what and when. AWS Config audits state — the configuration of a resource over time, answering what changed and to what value. They're not overlapping tools competing for the same job; they're three different questions that only look similar because all three get called "auditing."

CloudWatch: how the system is performing

CloudWatch is the one most teams already have some coverage on, since it's covered extensively elsewhere on this site — alarm setup, thresholds, and cost all have their own dedicated guides. One detail worth flagging here specifically: CloudWatch Logs' export-to-S3 feature (CreateExportTask) is not a real-time path — recently ingested log data can take up to 12 hours to become available for export, and each account can only run one active export task at a time. If you need near-real-time delivery to S3 or another destination, subscription filters are the correct tool, not scheduled exports.

CloudTrail: who did it

CloudTrail is enabled by default for every AWS account, with zero setup — its Event History gives a viewable, searchable, immutable record of the past 90 days of management events (API activity through the console, CLI, and SDKs) automatically. That default window is easy to mistake for full coverage. Two things it doesn't cover out of the box: events older than 90 days (need a trail or an event data store to retain beyond that), and data events — S3 object-level access, Lambda invocations — which are not logged by default because of the volume involved, and have to be turned on deliberately.

AWS Config: what changed

AWS Config is the pillar most teams skip, and it's the only one of the three with a real, unavoidable per-use cost from the first item recorded — no free default window like CloudTrail's Event History. It works through a configuration recorder that detects changes to your resources and captures each one as a configuration item — a point-in-time snapshot of that resource's state, built by invoking the same Describe/List API calls you'd run yourself. Config rules then continuously evaluate those configuration items against conditions you define; a resource that violates a rule gets flagged noncompliant, with a notification.

The distinction that matters in practice: CloudTrail tells you a specific IAM principal called ModifySecurityGroupRules at 14:32. Config tells you the security group's inbound rules changed from [restricted to office IP] to [0.0.0.0/0] at that same moment — the actual before-and-after state, not just the fact that an API call happened. You need both to reconstruct an incident fully; each one alone is half the story.

Both charges are billed per AWS Region — running Config across five regions multiplies both lines by five, not just the infrastructure it's watching.

The gap most teams actually have

The three pillars aren't equally likely to be missing. CloudWatch alarms are the most commonly configured, if imperfectly — most teams have some. CloudTrail's baseline (90-day Event History) exists automatically whether anyone set it up or not, but data events and long-term retention usually aren't turned on. AWS Config is the one most likely to be completely off, precisely because it's the only one of the three with a cost attached to simply having it running, not just to acting on what it finds.

Putting it together during a real incident

An ALB unhealthy-host-count alarm fires — that's CloudWatch, telling you targets are failing health checks right now. You check CloudTrail and find a security group's inbound rules were modified by a specific IAM user ten minutes before the alarm fired — that's who and when. You check AWS Config for that security group and see the exact rule change: an inbound rule that previously allowed the ALB's traffic was removed — that's the before-and-after state that explains why targets stopped responding. None of the three services alone tells the full story. Together, in under a minute of checking, they do.

What Nuberio Audit checks across all three

Nuberio Audit's core scan is CloudWatch alarm coverage — the hygiene score, missing alarms, and noisy-alarm flags. Its security findings layer also surfaces signal from GuardDuty, Security Hub, CloudTrail, Secrets Manager, and AWS Config, so the same read-only scan that tells you which CloudWatch alarms are missing also surfaces whether the other two pillars are configured at all.