AWS CloudTrail: What It Is and When to Use It

Definition

AWS CloudTrail is the audit-logging service for Amazon Web Services. It records every API call made in your AWS account — by the Console, SDK, CLI, or another AWS service — capturing who made the call, when, from where, what resource was touched, and whether it succeeded. These records are the foundation of AWS security investigations, compliance reports, and operational forensics.

CloudTrail is on by default for every AWS account: the last 90 days of Management Events are viewable in the Console Event History at no charge. For longer retention or custom queries, you create a Trail that delivers events to S3 (and optionally CloudWatch Logs) for as long as you want.

How It Works

CloudTrail captures three categories of events:

1. Management Events — write and read operations on AWS resources at the control plane: RunInstances, CreateBucket, AttachRolePolicy, ConsoleLogin, etc. On by default in every account and free for the last 90 days in Event History.
2. Data Events — object-level / data-plane operations: S3 GetObject, S3 PutObject, Lambda Invoke, DynamoDB item-level ops. Off by default because of volume and cost; enable per bucket, function, or advanced event selector.
3. Insights Events — anomaly detection on write Management or Data Events, flagging unusual spikes or rare API calls. Paid feature, enabled per trail.

For custom retention and analytics, create a Trail:

• Single-Region trail — captures events only in its home Region.
• Multi-Region trail (recommended) — aggregates events from all Regions into one S3 bucket.
• Organization trail — captures events across every account in an AWS Organization into a central management-account bucket; member accounts cannot delete it. Essential for central security teams.

A trail's log files are JSON, written to S3 every ~5 minutes in batches, optionally encrypted with KMS and integrity-validated (digest files).

For ad-hoc SQL-style analysis, CloudTrail Lake provides a managed, queryable event store with up to 10-year retention and direct integration with Athena-like queries.

Key Features and Limits

• Event History (last 90 days): free, Console-only, Management Events only.
• Trails: one free trail capturing Management Events in each AWS Region; additional trails and Data/Insights Events are paid.
• S3 destination: long-term storage, integration with Athena, AWS Glue Data Catalog, Amazon SageMaker.
• CloudWatch Logs destination: subscribe for near-real-time alerting and metric filters (e.g., alarm when DeleteTrail is called).
• EventBridge / Amazon SNS: Trails can fan events out in near-real-time for automated response.
• Log file validation: SHA-256 digest files let you verify no logs were tampered with.
• KMS encryption: enforce SSE-KMS on trail log files.
• CloudTrail Lake: managed event store with up to 10 years retention and SQL queries.
• Integrity-protected Organization Trails: member accounts can't delete, stop, or modify.
• Integration with AWS Security Hub, GuardDuty, IAM Access Analyzer, and third-party SIEMs (Splunk, Datadog, Wazuh).

Common Use Cases

1. Security forensics — when an incident occurs, trace exactly which principals did what and when.
2. Compliance reporting — PCI, HIPAA, SOC 2, and ISO 27001 all require audit logs of privileged access.
3. Root-cause troubleshooting — who turned off the Multi-AZ option on that RDS instance? who deleted the bucket?
4. Unauthorized-change alerting — CloudWatch metric filter on ConsoleLoginFailed, DeleteTrail, ChangePassword, etc. → CloudWatch Alarm → SNS.
5. Automated remediation — EventBridge rule on CreateUser or AuthorizeSecurityGroupIngress that triggers a Lambda to revert unauthorized changes.
6. Policy evolution — inspect which API calls an IAM role actually uses so you can tighten its policy with IAM Access Analyzer.
7. Organization-wide audit — a central security account receives every API call from every child account.

Pricing Model

CloudTrail pricing has three main components:

1. Management Events — first trail per Region that captures Management Events is free; additional trails capturing Management Events are paid per 100,000 events.
2. Data Events — paid per 100,000 events regardless of trail count. S3 and Lambda are the most common (and voluminous) sources.
3. Insights Events — paid per 100,000 write Management or Data events analyzed.

In addition:

• S3 storage — per GB-month for the destination bucket.
• KMS requests — if SSE-KMS is enabled.
• CloudTrail Lake — per GB ingested + per GB-month stored + per GB scanned by queries.
• CloudWatch Logs — ingestion + storage if you enable the secondary destination.

For most workloads, the free Management-Events trail + a multi-Region S3 destination is all you need; Data Events are opt-in because they can dwarf the rest of your AWS bill if enabled for a busy S3 bucket.

Pros and Cons

Pros

• On-by-default baseline audit trail — zero configuration to get the last 90 days of Management Events.
• Multi-Region and Organization trails centralize auditing at the org level.
• Integrity-validation and KMS encryption satisfy strict compliance frameworks.
• Native integration with CloudWatch, EventBridge, SNS, Security Hub, GuardDuty.
• CloudTrail Lake turns event data into queryable analytics.

Cons

• Data Events can be very expensive on busy S3 buckets — tune with advanced event selectors.
• Events are batched (~5-minute latency to S3); for true real-time, subscribe via CloudWatch Logs or EventBridge.
• Log volume is large and must be managed with S3 lifecycle rules to control cost.
• Not every AWS API is captured by CloudTrail — a handful of older/legacy services have gaps.

Comparison with Alternatives

| | CloudTrail | CloudWatch | AWS Config | | --- | --- | --- | --- | | Scope | API-call audit log | Metrics, logs, alarms | Resource configuration history | | Question answered | Who did what, when, from where? | What is happening / how is it performing? | What does this resource look like now, and how has it changed? | | Typical consumer | Security, compliance, SOC | SRE, DevOps, application teams | Compliance, change management | | Delivery | S3 + optional CloudWatch Logs | CloudWatch Metrics / Logs | Amazon S3 + Config Console |

Use all three together for a complete observability and compliance story: CloudTrail tells you who did it, CloudWatch tells you how the system is behaving, and Config tells you the resource state over time.

Exam Relevance

• Cloud Practitioner (CLF-C02) — know CloudTrail records API calls for auditing.
• Solutions Architect Associate (SAA-C03) — Trails to S3, Management vs Data Events, Organization trails, CloudTrail + CloudWatch Logs for alerting.
• SysOps Administrator (SOA-C02) — log file integrity validation, multi-Region trails, metric filters on CloudTrail logs.
• Security Specialty (SCS-C02) — heavy coverage: GuardDuty correlating with CloudTrail, Insights Events, cross-account audit, KMS for trail encryption, CloudTrail Lake queries.

Classic exam trap: Data Events are off by default. If the scenario asks to audit who read a specific S3 object, the answer includes enabling Data Events on that bucket (with advanced event selectors to scope the cost).

Frequently Asked Questions

Q: What's the difference between CloudTrail and CloudWatch?

A: CloudTrail records API activity — every call, who made it, what resource, success/failure. It's the audit log of "who did what, when, from where." CloudWatch monitors operational data — metrics, logs, alarms, traces. It's the answer to "what is happening / how is it performing." They are complementary: CloudTrail often writes to CloudWatch Logs so you can set alarms and use Logs Insights to query API-call history.

Q: Are Data Events worth enabling?

A: For security-sensitive buckets or functions — yes. For a high-traffic public asset bucket — probably not, because the cost explodes with every GetObject. Use advanced event selectors to scope Data Events tightly: e.g., only record PutObject and DeleteObject on your audit-logs bucket, or only record Lambda invocations for a specific set of business-critical functions. This gives you the audit coverage you need without logging every byte read.

Q: How do I ensure CloudTrail logs haven't been tampered with?

A: Enable log file validation when creating the trail. CloudTrail then writes a periodic digest file with the SHA-256 hashes of the preceding log files, signed with an AWS-managed key. Anyone with the aws cloudtrail validate-logs CLI command (or equivalent SDK call) can later verify the chain of digests back to the time of creation — any modification or deletion of a log file breaks the chain. Combined with S3 Object Lock and a multi-account Organization trail, this gives you court-admissible integrity.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS CloudTrail documentation before making production decisions.