CloudWatch vs. CloudTrail: monitoring, audit logs, and incident response

An endpoint suddenly starts returning 403 responses. CloudWatch shows the rising error rate and the affected service. CloudTrail may reveal that someone changed the IAM policy used by that service just before the failures began. Together, the records help distinguish a code failure from a permissions change.

CloudWatch and CloudTrail are therefore usually complementary. CloudWatch primarily observes system health and application behavior; CloudTrail records supported AWS account activity and API events. Neither automatically covers everything: application logs need collection, data events need selectors, alerts need configuration, and retention is not unlimited simply because a service is enabled.

Guance Editorial Team · Reviewed October 21, 2026. This documentation-based guide covers common CloudWatch, CloudTrail event-history, and trail workflows in AWS commercial Regions. Confirm regional availability and feature pricing separately. We did not conduct fault-injection or cost tests.

Start with the question you need to answer

The distinction between event history and data events is easily lost in the claim that CloudTrail records every API call.

CloudWatch does not automatically know every application detail

Many AWS services publish native metrics. Operating-system memory, application logs, and request traces can still require the CloudWatch Agent, SDKs, or other collection paths. CloudWatch is also more than CPU monitoring: Application Signals provides application metrics, dependencies, and SLOs, while Logs Insights queries collected logs. CloudWatch Agent and Application Signals

For an on-call engineer, this helps establish impact first. When did errors begin? Is one version or Region affected? Did CPU, queues, or dependency latency change at the same time? Only then does it make sense to investigate possible changes rather than treating the first nearby API call as the cause.

Logs stored in CloudWatch are not automatically correlated. Application, account, Region, resource identifiers, and timestamps need consistent meaning. Time-zone differences or clock skew can even distort the apparent order of events.

What the 90-day CloudTrail history includes

An AWS account has access to CloudTrail event history by default. It covers management events from the preceding 90 days in a single Region, with no CloudTrail charge for viewing it. It does not include data events, Insights events, or network activity events, and it is not an organization-wide historical query service. Its search scope and filters have explicit limits. Event-history boundaries

Changing an S3 bucket configuration and reading an object inside it are different activities. Object-level operations such as GetObject, PutObject, and DeleteObject are data events. Trails do not log them by default; configure the relevant resources and selectors and account for the additional charges. Enabling collection today cannot recover yesterday's unrecorded object access. Data events and selectors

For ongoing audit retention, configure a trail to deliver selected events to S3, using multi-Region or organization scope where appropriate. Define retention, access control, encryption, integrity validation, and checks on delivery status. Having files in a bucket is not the same as meeting your organization's evidence requirements.

There is also an important change for new designs: CloudTrail Lake stopped accepting new customers on May 31, 2026. Existing customers can continue using it, but account-level event data stores have restrictions on coverage of newly added organization accounts; organization-level stores have different provisions. This does not end support for CloudTrail trails, Insights, or other unaffected features. New query designs should evaluate CloudWatch and other paths under AWS's current guidance rather than assume every new account can adopt Lake. AWS availability notice

Follow a 403 alert to a permissions change

A small, controlled exercise can test whether the two sources support one investigation. The following is a suggested validation procedure, not an experiment performed for this article.

1. In a test environment, retain baseline request metrics and logs, then make an authorized, reversible permissions change. Record the account, Region, resource, and time.
2. In CloudWatch, confirm the error-rate or application-log change and narrow it to the affected service. Host CPU is not a substitute for request outcomes.
3. Find the corresponding management event in CloudTrail. Inspect the calling identity, event name, target resource, request parameters, and success or failure information. A role session identifies the credentials used; determining the human operator may also require identity-provider and sign-in records.
4. Compare request behavior before and after the change, establish impact, and verify recovery after rollback. Nearby timestamps are a lead, not proof of causation.

For an S3 object-access investigation, confirm data-event collection before the exercise. A 403 application-log entry also does not prove CloudTrail must contain the same business request. The services observe different activities.

Notifications need another configured step

CloudTrail supplies event records. Supported event paths can feed EventBridge rules that match events and route them to targets. Another common design sends trail logs to CloudWatch Logs, creates metric filters, and uses CloudWatch alarms to notify responders. Event coverage, latency, permissions, and costs differ between these paths. CloudTrail with CloudWatch Logs

Do not stop at successfully saving a rule. Use an expected event to check that it matches, reaches its target, and leaves a diagnosable failure if delivery breaks. Confirm that the recipient knows where to continue investigating. Paging on every routine operation can exhaust attention faster than a missing dashboard.

If the same event is retained in original CloudTrail files, CloudWatch Logs, and a third-party platform, prevent duplicate alerts. Multiple investigation copies may be useful; notification and response ownership should still be explicit.

Free event history is not a free audit system

Viewing CloudTrail event history is free. The first copy of management events delivered to S3 by trails in each Region also has its own free-delivery rule. These are separate provisions. Additional management-event copies, data events, and selected additional features may incur charges. S3 storage and requests, CloudWatch Logs, queries, and notification paths can add their own costs. CloudTrail pricing

CloudWatch charges depend on the feature and Region: metrics, APIs, log ingestion and storage, queries, alarms, and application monitoring have relevant billing dimensions. A single log-ingestion price per GB does not include unlimited retention, queries, or every application feature. CloudWatch pricing

Start an estimate with event sources and volume. Ten million daily reads of an object create a very different data-event workload from a small number of configuration changes. Selectors can narrow collection, but excluding events creates a corresponding evidence gap. Decide what must be recorded, for how long, and where it will be queried before evaluating cost.

What should you improve first?

If incidents occur without a clear picture of the affected service, improve CloudWatch metrics, application logs, and critical alarms. If incidents are detectable but the team relies on chat history to guess who changed what, review CloudTrail coverage and ongoing retention.

Production systems commonly need both kinds of evidence. That does not require indiscriminately enabling every event, log, and additional feature. Begin with an operational view of critical services and an audit scope for critical resources. Use one controlled change to establish that both can support the same investigation, then expand coverage.

Official references

• CloudTrail event history, data events, and Lake availability
• CloudTrail delivery to CloudWatch Logs and CloudTrail pricing
• CloudWatch Application Signals and CloudWatch pricing

Sources checked October 21, 2026. Verify current availability and pricing for the destination Region and account before deployment.