CloudWatch vs CloudTrail (vs Config and GuardDuty): The Difference With Real Examples, Pricing, Using Them Together for Alerts, and Exam Tips

CloudWatch vs CloudTrail in one line: Amazon CloudWatch tells you how your resources and applications are doing (CPU, errors, latency, your application's logs, alarms when something crosses a line), while AWS CloudTrail tells you who did what in your AWS account (every API call: which user or role stopped the server, deleted the bucket or changed the security group, when, and from which IP address). CloudWatch is performance and health monitoring; CloudTrail is an audit log of actions. A third service often joins the comparison: AWS Config records what each resource's configuration looked like over time. The part people miss is that they work best together, and the cheapest pairing is free: CloudTrail keeps 90 days of management events at no charge in every account, already turned on, and CloudWatch's first 10 alarms and 10 custom metrics are free.

Jake's shop website went down at 2:14 one morning. Ethan opened CloudWatch first and found the answer to "what happened": the web server's CPU dropped to zero at 2:14 and the status checks stopped. That told him the server had stopped, not why. Then he opened CloudTrail and found the answer to "who did it": a StopInstances call at 2:14, made with the access key on an old laptop script that was meant to stop the test server. Two services, two questions, one five-minute fix.

This guide explains the difference between CloudWatch and CloudTrail with real examples, where AWS Config and EventBridge fit, what each one costs, how to wire them together for security alerts, and how to pick the right one in a certification exam question. For each service on its own, see what CloudWatch is and what CloudTrail is.

The difference between CloudWatch and CloudTrail

Both services collect data about your AWS account, both can store your logs, and both appear on every security checklist you will read, which is why they are confused so often. The cleanest way to keep them apart is the question each one answers:

• CloudWatch answers "how is it doing?" It collects metrics (numbers over time, such as CPU utilization, request count, error rate, free memory), logs (text your applications and services write), and acts on them with alarms and dashboards. It is about performance, health and operations.
• CloudTrail answers "who did what?" It records API calls made in your account: through the console, the CLI, SDKs and AWS services acting for you. Each record names the identity (user, role or service), the action (RunInstances, DeleteBucket, PutBucketPolicy), the time, the source IP address, and the parameters. It is about governance, auditing and security investigations.

A simple test: if the answer is a number or a log line from your code, it is CloudWatch. If the answer is a person or role plus an action, it is CloudTrail. "Why is the site slow?" is CloudWatch. "Who opened port 22 to the world?" is CloudTrail.

The two do overlap in one place, which causes most of the confusion: CloudTrail can send its events into CloudWatch Logs. Once there, CloudTrail records sit in a CloudWatch log group like any application log, and CloudWatch can count them and alarm on them. That does not make CloudWatch an audit service; it makes it the alerting engine for CloudTrail's audit data. More on that pairing below.

What CloudWatch records

CloudWatch is several tools under one name. The ones that matter for this comparison:

• Metrics. Time series of numbers, published automatically by most AWS services (EC2 CPUUtilization, Lambda Errors and Duration, ALB HTTPCode_Target_5XX_Count, DynamoDB throttles) and by your own code as custom metrics. Metrics live in the Region where they were created.
• Logs. Log groups and streams for your applications, Lambda functions, containers, VPC Flow Logs, and anything sent by the CloudWatch agent. Query them with CloudWatch Logs Insights.
• Alarms. Rules on a metric ("CPU above 80 percent for 10 minutes") that change state and trigger actions: an SNS notification, an Auto Scaling action, an EC2 reboot.
• Dashboards, Application Signals, Synthetics, Container Insights and more for observability beyond the basics.

How long it keeps metric data depends on the detail: data points finer than one minute are kept for 3 hours, 1-minute data for 15 days, 5-minute data for 63 days, and 1-hour data for 455 days (15 months). Older data is rolled up into coarser periods, so a month-old graph shows 5-minute points, not 1-minute ones. Log retention is yours to set per log group, from one day to ten years or never expire, and "never expire" is the default, which is how log bills creep up.

What CloudWatch does not record: who made a change. A CPU graph shows the server stopped at 2:14; it cannot show the StopInstances call or the access key that made it.

What CloudTrail records

CloudTrail records events, and there are several kinds:

• Management events: control-plane actions that create, change or delete resources (RunInstances, CreateUser, PutBucketPolicy, AuthorizeSecurityGroupIngress), plus console sign-ins. Recorded by default.
• Data events: high-volume actions on the data inside resources, such as S3 GetObject/PutObject, Lambda Invoke and DynamoDB item operations. Off by default; you choose which resources to record, because they can be billions of events.
• Network activity events: API calls made through VPC endpoints, for seeing what passes through a private endpoint.
• Insights events: CloudTrail's own detections of unusual API call rates or error rates, when you enable CloudTrail Insights.

Every account has Event history switched on from day one: a searchable, downloadable, immutable record of the last 90 days of management events in each Region, at no cost. For anything longer, or for data events, you create a trail (which delivers log files to an S3 bucket, and optionally to CloudWatch Logs) or a CloudTrail Lake event data store (which stores events for SQL queries). A trail delivers files about every 5 minutes, and an event typically appears within about 5 minutes of the API call; that delay is not guaranteed.

Ethan's 2:14 question took one command against the free Event history:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=StopInstances \
  --start-time 2026-10-22T00:00:00Z --end-time 2026-10-23T00:00:00Z \
  --query 'Events[].{time:EventTime,user:Username,event:EventName}'

Each event's full record (in CloudTrailEvent) shows the identity type and ARN, the access key ID, the source IP address, the user agent (which is how Ethan knew it was a script, not the console), and the instance IDs in the request. lookup-events accepts only one lookup attribute per call, such as an event name, a user name or a resource name, so filter further in the output. The request shapes in this guide were checked against the current AWS SDK API models (botocore 1.43.118).

What CloudTrail does not record: how a resource is performing, or what your application wrote to its logs. It also skips requests that fail authentication (invalid credentials), though it does log requests that are denied by permissions.

What a CloudTrail event looks like, next to a CloudWatch metric

Seeing one record from each makes the difference concrete. Here is a standard example of a CloudTrail management event, an EC2 StartInstances call (abridged):

{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "IAMUser",
    "arn": "arn:aws:iam::123456789012:user/Mateo",
    "accessKeyId": "AKIAIOSFODNN7EXAMPLE",
    "userName": "Mateo",
    "sessionContext": { "attributes": { "mfaAuthenticated": "false" } }
  },
  "eventTime": "2023-07-19T21:17:28Z",
  "eventSource": "ec2.amazonaws.com",
  "eventName": "StartInstances",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "192.0.2.0",
  "userAgent": "aws-cli/2.13.5 Python/3.11.4 ... command/ec2.start-instances",
  "requestParameters": { "instancesSet": { "items": [ { "instanceId": "i-EXAMPLE56126103cb" } ] } },
  "responseElements": { "instancesSet": { "items": [ { "currentState": { "name": "pending" },
                                                       "previousState": { "name": "stopped" } } ] } },
  "readOnly": false,
  "eventType": "AwsApiCall",
  "managementEvent": true,
  "eventCategory": "Management"
}

Read it top to bottom and you have the whole story: who (userIdentity: an IAM user, which access key, and that MFA was not used), what (eventSource and eventName), when (eventTime, in UTC), from where (sourceIPAddress and userAgent, here the AWS CLI in CloudShell), on what (requestParameters), and what happened (responseElements: stopped to pending). A failed call adds errorCode and errorMessage, such as AccessDenied.

A CloudWatch metric, by contrast, is just numbers over time with no identity at all. Asking for the same server's CPU returns data points like these:

aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abc123def4567890 \
  --start-time 2026-10-22T00:00:00Z --end-time 2026-10-23T00:00:00Z \
  --period 300 --statistics Average Maximum

{ "Label": "CPUUtilization",
  "Datapoints": [ { "Timestamp": "2026-10-22T02:10:00Z", "Average": 31.2, "Maximum": 58.0, "Unit": "Percent" }, ... ] }

(The data point values above show the shape of the response, not a measurement.) There is no "who" anywhere in a metric, and no "how busy" anywhere in a CloudTrail event. That is the whole difference in two records.

CloudWatch vs CloudTrail vs AWS Config: side by side

Where AWS Config fits

CloudTrail tells you that someone called AuthorizeSecurityGroupIngress at 2:14. AWS Config tells you what the security group looked like before and after, and keeps a timeline of every configuration it has ever had, with links to the CloudTrail events that changed it. Config also evaluates rules ("no security group may allow 0.0.0.0/0 on port 22", "every S3 bucket must block public access") and marks resources compliant or not.

So for one incident, the three tell one story from three angles: CloudWatch shows the symptom (traffic dropped), CloudTrail shows the action (who changed the rule), and Config shows the state (what the rule was before, and that it now breaks your policy). What AWS Config is covers recorders, rules and pricing in detail.

Which one answers which question

Other services read these sources for you: GuardDuty analyzes CloudTrail events, VPC Flow Logs and DNS logs for threats, and Security Hub collects findings in one place. What GuardDuty is explains how it uses CloudTrail.

CloudWatch Logs vs CloudTrail logs

Both produce "logs", and both can end up in CloudWatch Logs, so this deserves its own answer. CloudWatch Logs is a storage and query service for log text: whatever your application prints, Lambda output, container logs, VPC Flow Logs, and, if you choose, CloudTrail events. CloudTrail logs are a specific kind of record (one JSON event per API call) that CloudTrail writes to S3 by default, and optionally also to a CloudWatch log group.

• Source: CloudWatch Logs takes anything you send it. CloudTrail logs come only from CloudTrail.
• Content: CloudWatch Logs holds free-form text or JSON. CloudTrail events always have the same structure: eventTime, eventName, userIdentity, sourceIPAddress, requestParameters, errorCode.
• Integrity: CloudTrail log files in S3 can be validated with digest files to prove they were not changed or deleted. CloudWatch Logs has no such feature.
• Price: CloudWatch Logs charges for ingestion ($0.50 per GB) and storage; a trail's first copy of management events costs nothing beyond the S3 storage of the files.

Using them together: alert on root logins and risky changes

This is the setup every account should have, and it is the reason CloudTrail and CloudWatch are so often mentioned in one breath. The trail sends events to a log group, a metric filter counts the dangerous ones, and an alarm notifies you.

1. Create (or reuse) a trail that records management events in all Regions, delivering to an S3 bucket.
2. Send the trail to CloudWatch Logs. Create a log group and an IAM role that lets CloudTrail write to it, then attach both to the trail:

   aws cloudtrail update-trail --name shop-trail \
     --cloud-watch-logs-log-group-arn "arn:aws:logs:us-east-1:111122223333:log-group:CloudTrail/shop:*" \
     --cloud-watch-logs-role-arn arn:aws:iam::111122223333:role/CloudTrailToCloudWatch

3. Add a metric filter for the events you care about. The classic one counts any use of the root user:

   aws logs put-metric-filter --log-group-name CloudTrail/shop \
     --filter-name RootActivity \
     --filter-pattern '{ $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }' \
     --metric-transformations metricName=RootActivityCount,metricNamespace=Security,metricValue=1

4. Create an alarm on that metric that notifies an SNS topic:

   aws cloudwatch put-metric-alarm --alarm-name root-activity \
     --namespace Security --metric-name RootActivityCount \
     --statistic Sum --period 300 --evaluation-periods 1 --threshold 1 \
     --comparison-operator GreaterThanOrEqualToThreshold \
     --treat-missing-data notBreaching \
     --alarm-actions arn:aws:sns:us-east-1:111122223333:security-alerts

5. Repeat the filter-and-alarm pair for other risky events: console sign-in failures, IAM policy changes, security group changes, CloudTrail itself being stopped, and KMS keys scheduled for deletion.

Two things to know. A metric filter only counts events that arrive after it is created, and the pattern is case-sensitive; why a metric filter never counts old logs explains both. And the alarm fires about 5 minutes after the event at the earliest, because that is how long CloudTrail takes to deliver. For faster reactions, an EventBridge rule on "AWS API Call via CloudTrail" events can trigger a Lambda function or SNS topic directly, without a log group. What EventBridge is shows the rule patterns. Ethan set up the root-user alarm the same week, and wired the old laptop script's key to an alarm too, before deleting the key entirely.

Investigating an incident with all three, step by step

When something breaks, the order matters: start with the symptom, then the cause, then the change. This is the sequence Ethan used at 2:14, generalized:

1. Confirm the symptom in CloudWatch. Open your dashboard or the service's metrics for the time of the alert: errors, latency, CPU, status checks. Note the exact minute you see things change.
2. Read your application's own logs in CloudWatch Logs Insights around that minute: fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc.
3. Ask CloudTrail who acted on your resource in the same window: Event history filtered by resource name or event name (StopInstances, ModifyDBInstance, PutBucketPolicy, UpdateFunctionConfiguration).
4. Check the identity in the event: user or role, access key, source IP, user agent, MFA. If you see a script's user agent or an IP you do not recognize, your response changes from "fix it" to "contain it".
5. Use AWS Config to see before and after for configuration changes: the resource timeline shows the old and new settings and links to the CloudTrail event.
6. Fix, then prevent: roll back the change, rotate or delete your key if needed, and add a CloudWatch alarm or EventBridge rule so the same action alerts you next time.

To search older or larger sets of events with SQL, CloudTrail Lake answers questions like "every console sign-in without MFA this quarter" in one query, and CloudWatch Logs Insights does the same for CloudTrail events sent to a log group:

-- CloudTrail Lake (SQL), against your event data store
SELECT eventTime, eventName, userIdentity.arn, sourceIPAddress
FROM YOUR_EVENT_DATA_STORE_ID
WHERE eventName = 'StopInstances' AND eventTime > '2026-10-22 00:00:00'

# CloudWatch Logs Insights, on the CloudTrail log group
fields @timestamp, eventName, userIdentity.arn, sourceIPAddress
| filter eventName = "StopInstances"
| sort @timestamp desc

CloudTrail Lake vs CloudWatch Logs for searching events

If you want to query CloudTrail events, you have two places to keep them. CloudTrail Lake is CloudTrail's own event store: you create an event data store, it ingests CloudTrail events (and other sources), keeps them for a retention period you choose, and you query them with SQL. CloudWatch Logs receives the same events when a trail sends them to a log group, and you query them with Logs Insights or count them with metric filters for alarms.

• For alarms and near-real-time alerts, CloudWatch Logs (metric filters) or EventBridge rules. Lake is for investigation, not alerting.
• For long retention and audits, Lake: immutable storage, years of retention, SQL across accounts in an organization. Ingestion is $0.75 per GB with one-year retention (US East), queries $0.005 per GB scanned.
• For a cheap archive, the trail's own files in S3, queried with Athena when needed, cost the least of all.

Many teams use two of the three: S3 files as the permanent record, and CloudWatch Logs or EventBridge for alerts. Lake earns its price when security teams run frequent questions across many accounts and want SQL without building their own tables.

CloudTrail vs CloudWatch Events (EventBridge)

One more name in the mix: CloudWatch Events, which is now Amazon EventBridge. It is neither a log nor an audit trail. It is a router: it receives events (from AWS services, from CloudTrail API calls, from your applications, on a schedule) and sends matching ones to targets such as Lambda, SNS, SQS or Step Functions. If CloudTrail is the logbook, EventBridge is the person who reads each new line as it is written and phones someone when it matters. Old documentation and exam questions still say "CloudWatch Events"; treat it as EventBridge.

CloudWatch vs CloudTrail vs GuardDuty, X-Ray, VPC Flow Logs and CloudFront

Several more names come up in the same breath. A one-line job for each:

• CloudWatch vs AWS X-Ray. CloudWatch tells you that your requests are slow; X-Ray (and CloudWatch Application Signals, built on the same tracing) shows where inside a request the time goes, call by call across services. Start with your metrics, and reach for traces when you need the path. What X-Ray is covers tracing and its cost.
• CloudTrail vs GuardDuty. CloudTrail records events; GuardDuty reads CloudTrail events (with VPC Flow Logs and DNS logs) and tells you which ones look like an attack, such as API calls from a known malicious IP or unusual credential use. CloudTrail is the evidence, GuardDuty the detective.
• VPC Flow Logs record network traffic (source and destination IP, port, accepted or rejected) for your VPC, not API calls. CloudTrail tells you who opened port 22; Flow Logs show who then connected to it. Flow Logs are delivered to CloudWatch Logs or S3.
• Amazon CloudFront is unrelated to both, despite the name: it is a content delivery network that serves your website from edge locations. It has its own access logs and CloudWatch metrics, and its configuration changes appear in CloudTrail like any other API call.
• Trusted Advisor checks your account against best practices (open security groups, unused resources, service limits). It is a periodic advisor, not a log of events or a monitor of performance.
• Security Hub then gathers GuardDuty, Config and other findings into one list with a security score. What Security Hub is explains how they connect.

CloudWatch vs CloudTrail pricing

Both have a free layer that covers small accounts, and both get expensive in one specific way. Prices from the AWS price list for US East (N. Virginia), October 2026:

Where your money really goes: in CloudWatch, log ingestion (a chatty application can send hundreds of GB a month at $0.50 each) and custom metrics with many dimensions (each unique combination is a separate metric). In CloudTrail, data events on busy resources (an S3 bucket serving 10 million reads a month is $10 a month in data events alone) and a second trail that records the same management events again at $2.00 per 100,000. Sending CloudTrail into CloudWatch Logs adds CloudWatch ingestion on top, so if your volume is high, filter the trail to the events you alert on.

For Jake's shop the whole setup above costs about the price of a coffee a month: Event history and the first trail copy are free, one log group of management events is a few hundred megabytes, and four alarms are within the free ten. "So the logbook is free and the dashboard is nearly free," Jake said. "What's the catch?" Ethan: "The catch is nobody reads either until something breaks."

CloudWatch vs CloudTrail in AWS certification questions

If you are studying for a certification, you will meet this pair in the Cloud Practitioner, Solutions Architect, CloudOps (SysOps) and Security exams, usually as "which service should the company use?" The keywords decide it:

• "Monitor", "metric", "CPU", "latency", "threshold", "alarm", "dashboard", "application logs" point to CloudWatch.
• "Audit", "who made the change", "API calls", "governance", "track user activity", "investigate a deleted resource" point to CloudTrail.
• "Configuration history", "compliance with rules", "what a resource looked like", "drift" point to AWS Config.
• "React in near real time to an API call" points to EventBridge with CloudTrail events, or a CloudWatch metric filter and alarm on CloudTrail logs.
• "Prove logs were not altered" points to CloudTrail log file integrity validation.

A frequent trap answer is "CloudWatch Logs" for "who deleted the bucket". CloudWatch Logs only knows if CloudTrail sent the event there; the service that records the action is CloudTrail.

Best practices for using both

• Create one organization trail for all your accounts and Regions, delivering to a central, locked-down S3 bucket with log file validation on.
• Record data events only where they matter to you (buckets with customer data, sensitive Lambda functions), using advanced event selectors to limit your volume.
• Send CloudTrail to CloudWatch Logs or EventBridge for alerts on root use, IAM changes, security group changes and CloudTrail being stopped.
• Set retention on every CloudWatch log group you own; the default keeps your logs forever.
• Alarm on symptoms your users feel (5xx rate, latency) rather than only on CPU.
• Turn on AWS Config for the resource types you need history and compliance for; you do not have to record everything.

Troubleshooting by symptom

I cannot find an event older than 90 days

Event history keeps only 90 days of management events. Older events exist only if a trail delivered them to S3 or a CloudTrail Lake store recorded them.

An S3 object deletion is not in CloudTrail

DeleteObject is a data event, recorded only if the trail has S3 data events on for that bucket. S3 server access logs may also show it.

A brand-new change is not in CloudTrail yet

Delivery typically takes about 5 minutes. Wait and search again.

My CloudTrail metric filter counts nothing

Filters only see events after they were created, and patterns are case-sensitive. Test the pattern against a real event.

CloudWatch shows the server stopped but not why

CloudWatch has no identities. Look up StopInstances or TerminateInstances in CloudTrail for the same time.

The CloudWatch bill keeps growing

Check log ingestion by log group, set retention, and look for custom metrics with high-cardinality dimensions.

Frequently asked questions

The laptop script is gone, its access key deleted, and the root-user alarm has fired exactly once since: when Jake logged in as root to update the billing card, which is the one thing root is for. He got an email about himself a few minutes later, and decided that meant it worked.

Revision note. Written October 23, 2026. "An ounce of prevention is worth a pound of cure," the proverb says; one root-user alarm is the ounce.