CloudWatch vs CloudTrail vs Config: AWS Monitoring and Audit Services Compared

Amazon CloudWatch monitors how your resources are performing, AWS CloudTrail records who did what in your account, and AWS Config tracks how your resources are configured and whether that configuration complies with your rules. The three services sound similar and appear together in exam answer choices constantly, but they answer three different questions: “Is it healthy?”, “Who did that?”, and “Is it configured correctly?”. Match the question in the scenario to the right service and these become some of the easiest points on CLF-C02.

Amazon CloudWatch: performance and operational monitoring

Amazon CloudWatch is the observability service. AWS services publish metrics to it automatically: CPU utilization for an EC2 instance, request counts for a load balancer, read latency for a database. You can also publish custom metrics from your own applications. On top of metrics, CloudWatch provides:

• Alarms that watch a metric and act when it crosses a threshold you set. An alarm can notify people through Amazon Simple Notification Service (SNS), or trigger an action directly, such as adding instances through an Auto Scaling policy or stopping an idle instance.
• Dashboards that visualize metrics from many services and Regions on one screen.
• CloudWatch Logs, which centralizes log files from EC2 instances, Lambda functions, and other sources so you can search them and set alerts on their contents.

The mental model: CloudWatch tells you what is happening operationally, right now and over time. If a scenario involves CPU thresholds, application logs, performance dashboards, alarms, or “notify the operations team when utilization exceeds 80 percent,” it is a CloudWatch question.

Closely related but distinct: Amazon EventBridge (formerly CloudWatch Events) reacts to events and schedules by routing them to targets. At the Cloud Practitioner level, just recognize that alarms on metric thresholds belong to CloudWatch itself.

AWS CloudTrail: the audit log of API activity

Nearly everything done in AWS, whether through the Management Console, the Command Line Interface (CLI), a Software Development Kit (SDK), or another AWS service, is an API call. AWS CloudTrail records those calls as events: who made the call (the identity), when, from what IP address, against which resource, and what the request and response looked like.

That makes CloudTrail the account’s audit trail. It is the service for governance, compliance evidence, security analysis, and incident investigation. Typical uses:

• Determining which user terminated an EC2 instance or deleted an S3 bucket, and when.
• Detecting unusual activity, such as API calls from an unexpected location.
• Producing an activity record for auditors.

CloudTrail is enabled on every AWS account and keeps a rolling 90-day event history of management events viewable in the console. For retention beyond that, or for analysis tooling, you create a trail that delivers events to an S3 bucket, where they can be kept as long as you need and protected with log file integrity validation to prove the records have not been tampered with.

The mental model: CloudTrail tells you who did what, where, and when. Any scenario built around accountability for an action points here.

AWS Config: resource configuration and compliance

AWS Config continuously records the configuration of your resources: what settings each resource has, how those settings change over time, and how resources relate to each other. Where CloudTrail records the action (“user X called the API that opened port 22”), Config records the resulting state (“this security group now allows inbound port 22, and here is its full configuration history”).

Config’s second half is compliance evaluation. Config rules express your desired state (examples: EBS volumes must be encrypted, S3 buckets must not allow public access, security groups must not permit unrestricted SSH), and Config continuously evaluates resources against those rules, flagging each one as compliant or noncompliant. It can trigger automatic remediation for violations, and it provides a timeline view so you can see exactly what a resource’s configuration was at any point in the past, which is invaluable for audits and for answering “what changed right before the outage?”

The mental model: Config tells you what your resources look like, how they got that way, and whether that state is allowed.

Side-by-side comparison

	CloudWatch	CloudTrail	Config
Core question	Is it performing well?	Who did what?	Is it configured correctly?
Records	Metrics, logs, alarms	API calls and account activity	Resource configurations and changes
Primary use	Operational monitoring, alerting	Auditing, governance, security investigation	Compliance checking, change history
Example trigger	CPU above 80 percent fires an alarm	User deletes a bucket, event recorded	Unencrypted volume flagged noncompliant

The three are complementary, not competing. A mature account runs all three: CloudWatch catches the performance impact of a change, Config shows what the configuration change was, and CloudTrail identifies who made it. Note also what none of them do: threat detection from log analysis is Amazon GuardDuty’s job, a distinction unpacked in GuardDuty vs Inspector vs Macie.

How the CLF-C02 exam tests this

• A scenario asks how to find out which IAM user made a specific change, deleted a resource, or called a particular API. The answer is CloudTrail. CloudWatch and Config will be sitting right there as distractors.
• A scenario wants notification when a metric crosses a threshold (CPU, disk, request latency) or wants application logs collected and searched. The answer is CloudWatch (alarms with SNS, or CloudWatch Logs).
• A scenario requires proving to auditors that all resources meet a configuration standard, such as encryption enabled everywhere, or requires a history of how a resource’s settings changed over time. The answer is AWS Config.
• A combined pattern gives one sentence per need (“track API activity, monitor performance, evaluate resource compliance”) and asks you to map services to needs. Anchor on the verbs: recorded actions go to CloudTrail, measured performance goes to CloudWatch, evaluated configuration state goes to Config.

Quick reference

• CloudWatch: metrics, logs, alarms, dashboards. Operational question: is it healthy and performing?
• CloudTrail: record of API calls and account activity. Audit question: who did what, when, from where?
• Config: resource configuration inventory, change timeline, compliance rules. Governance question: is the setup correct and allowed?
• CloudTrail keeps 90 days of management event history by default; a trail to S3 extends retention indefinitely.
• Config rules evaluate resources as compliant or noncompliant and can auto-remediate.
• CloudWatch alarms can notify via SNS or trigger actions like Auto Scaling.
• Together they cover performance (CloudWatch), accountability (CloudTrail), and configuration state (Config).