What Is AWS CloudTrail? Event History, Trails, and Security Use Cases
AWS CloudTrail records the API calls made in your AWS account. Who did what, when, from where, and what happened as a result. Every time someone launches an instance, changes a security group, assumes a role, or deletes a bucket, CloudTrail captures it. It is the audit log for your entire AWS environment and the starting point for security investigation, compliance evidence, and operational troubleshooting.
Simple explanation
CloudTrail is a record of actions taken in your AWS account. It answers one question: “Who did what in my account, and when did they do it?”
By default, AWS keeps a 90-day rolling log of administrative actions called Event History. If you want to keep logs longer, capture more detail, or set up alerts, you create a trail that delivers logs to an S3 bucket you control.
Think of CloudTrail like the access log for an office building. Every time someone badges in, opens a restricted door, or uses the elevator to a secure floor, the system records who they are, which door they used, and when. CloudTrail does the same thing for your AWS account. Instead of doors, it tracks API calls to AWS services.
Why it matters
Without CloudTrail, you have no record of what happened in your account. When a security incident occurs, the first question is always “who did what and when?” CloudTrail answers that.
- Security investigation. When credentials are compromised, CloudTrail shows exactly what the attacker accessed and changed. See detecting suspicious activity in AWS logs for what to look for.
- Compliance evidence. Frameworks like SOC 2, PCI-DSS, and HIPAA require proof that administrative activity is logged and retained. CloudTrail is how most organizations satisfy that requirement.
- Operational troubleshooting. When a resource disappears or a configuration changes unexpectedly, CloudTrail tells you which identity made the change and from which IP address.
- Feeds other security services. GuardDuty analyzes CloudTrail to detect suspicious API patterns. IAM Access Analyzer uses it to determine which permissions are actually used. Security Hub checks whether your CloudTrail configuration meets compliance baselines.
CloudTrail is the single best tool for answering “what just happened?” in your AWS account. If you set up only one security service, make it this one. For broader account-level monitoring context, see monitoring your AWS account.
How CloudTrail works
There are three main ways to access and store CloudTrail data. Understanding the difference between them is the most important concept on this page.
Event History
Available by default in every AWS account. Shows the last 90 days of management events in the CloudTrail console or via the lookup-events CLI command. Free, no setup required. You can filter by user, event name, resource type, and time range. You can also download events from the console or export them via CLI.
Trails
A trail is a configuration that delivers CloudTrail events to an S3 bucket (and optionally to CloudWatch Logs). Trails support all event types, configurable retention through S3 lifecycle policies, and integration with Athena for SQL queries. This is the standard production setup.
CloudTrail Lake
A managed event data store with built-in SQL querying. CloudTrail Lake stores events in its own storage (not S3) and lets you query them directly without setting up Athena. It supports cross-account and cross-region aggregation. Higher cost than trails with S3, but less setup.
Event History is like checking the last 90 days of security camera footage on a lobby monitor. A trail is like having that footage automatically backed up to your own storage vault every day so you can keep it for years. CloudTrail Lake is like hiring a managed archival service that stores the footage and lets you search it with keywords without building your own search system.
Comparison
| Feature | Event History | Trail (S3) | CloudTrail Lake |
|---|---|---|---|
| Enabled by default | Yes | No, must create | No, must create |
| Retention | 90 days (fixed) | You control via S3 lifecycle | Configurable (up to 7 years) |
| Event types | Management only | Management, data, Insights, network activity | Management, data, Insights, network activity |
| Query / search | Basic console filters, CLI lookup | Athena SQL, CloudWatch Logs Insights | Built-in SQL queries |
| Best for | Quick recent lookups | Long-term storage, alerting, compliance | Cross-account analytics, managed querying |
| Cost | Free | Free (first mgmt copy) + S3 storage | Ingestion + query charges |
Most teams start with a multi-region trail delivering to S3. Add CloudTrail Lake later if you need built-in querying across multiple accounts without managing Athena tables.
What CloudTrail records
CloudTrail captures four categories of events. Only the first is logged by default.
Think of event types like different levels of detail on a bank statement. Management events are the big transactions: opening accounts, changing signatories, closing accounts. Data events are the individual deposits and withdrawals. Network activity events track which ATM or branch was used. Insights events are the fraud alerts that fire when the pattern looks unusual.
Management events (logged by default)
API calls that create, modify, or delete AWS resources. This is the control plane of your account. Examples include ec2:RunInstances, iam:CreateRole, s3:CreateBucket, and sts:AssumeRole. The first copy of management events in a trail is free. This is the most important category for security monitoring.
Data events (must be enabled)
API calls on the data stored in your resources: object downloads, function invocations, database reads. Examples include s3:GetObject, lambda:InvokeFunction, and dynamodb:GetItem. Data events can generate enormous volume. Enable them selectively for sensitive resources, not across the board.
Data events are the most common source of unexpected CloudTrail costs. In a busy account, enabling S3 data events for all buckets can generate millions of log entries per day. Always start with specific high-sensitivity buckets and expand deliberately.
Network activity events (must be enabled)
API calls made through VPC endpoints using AWS PrivateLink. These show which principals are calling which services through which VPC endpoints. Useful for auditing private network access patterns in accounts that use VPC endpoints extensively.
Insights events (must be enabled)
Automatically generated when CloudTrail detects unusual patterns in management event volume or error rates. For example, a sudden spike in TerminateInstances calls or an abnormal burst of access-denied errors. Useful as an early warning system for compromise or misconfiguration.
If you are just getting started, focus on management events first. They are free, cover the most security-relevant activity, and give you the foundation to investigate any account-level change. Add data events and Insights later for specific buckets or accounts that need deeper visibility.
For a detailed breakdown of each event type with cost implications and configuration examples, see CloudTrail log types explained.
What CloudTrail does not give you
CloudTrail is powerful, but it has clear boundaries. Knowing what it does not do saves you from relying on the wrong tool when something goes wrong.
- Not application logs. CloudTrail records AWS API calls, not your application’s internal log output. For application logs, use CloudWatch Logs.
- Not metrics or performance data. CloudTrail does not tell you CPU utilization, request latency, or error rates. That is CloudWatch Metrics.
- Not resource state tracking. CloudTrail records that someone changed a security group, but it does not store what the security group looked like before and after. AWS Config tracks configuration state over time.
- Not data content. CloudTrail records that
s3:GetObjectwas called on a specific key. It does not record the contents of the object, database rows, or any business data.
A common mistake is assuming CloudTrail will tell you what changed in a resource. It only tells you that a change happened and who made it. If you need before-and-after configuration diffs, you need AWS Config running alongside CloudTrail.
When to use this
| Scenario | How CloudTrail helps |
|---|---|
| Incident investigation | Trace exactly what a compromised credential was used for: which APIs, which regions, which resources |
| Auditing IAM and root activity | See every role assumption, policy change, and user creation across the account |
| Compliance evidence | Demonstrate to auditors that all administrative actions are logged with identity, timestamp, and source IP |
| Tracking account changes | Find out who deleted a resource, changed a configuration, or modified a security group |
| Monitoring sensitive data access | Enable data events on specific S3 buckets to track who downloads or modifies sensitive objects |
| Detecting credential misuse | Spot temporary credentials or access keys being used from unexpected locations or at unusual times |
During a real incident, the most useful CloudTrail fields are userIdentity (who), eventName (what), sourceIPAddress (from where), and eventTime (when). Learn to filter on these four fields and you can investigate most situations quickly.
CloudTrail vs CloudWatch vs AWS Config
These three services are frequently confused because they all involve “logging” or “monitoring.” They do different things and complement each other.
| Service | What it answers | Example |
|---|---|---|
| CloudTrail | Who did what? (API activity log) | “Alice called AuthorizeSecurityGroupIngress at 14:03 from 203.0.113.42” |
| CloudWatch | How is it performing? (metrics, logs, alarms) | “CPU on instance i-abc is at 92%” or “Lambda function threw a NullPointerException” |
| AWS Config | What does it look like now, and what changed? (configuration state) | “Security group sg-123 currently allows inbound 0.0.0.0/0 on port 22. It was changed yesterday.” |
Imagine investigating a break-in at an office. CloudTrail is the badge access log showing who entered which room and when. AWS Config is the inventory list that tells you what was in the room before and after. CloudWatch is the building’s sensor system showing temperature spikes, alarms triggered, and doors left open. You need all three to understand the full picture.
In practice, you use all three together. CloudTrail tells you who made the change. AWS Config tells you what the resource looked like before and after. CloudWatch tells you how the change affected system behavior. During an incident, you typically start in CloudTrail to identify the action, check AWS Config for the configuration diff, and look at CloudWatch for the performance impact.
Secure baseline setup
A single multi-region trail with log file validation is the minimum recommended setup. This captures management events from all regions and delivers them to an S3 bucket you control.
# Create a multi-region trail with log file validation
aws cloudtrail create-trail \
--name main-trail \
--s3-bucket-name my-cloudtrail-logs-123456789012 \
--is-multi-region-trail \
--enable-log-file-validation
# Start logging
aws cloudtrail start-logging --name main-trailThe —enable-log-file-validation flag generates digest files that let you verify logs were not tampered with after delivery. It is required by most compliance frameworks and costs nothing to enable. There is no reason to skip it.
The S3 bucket needs a bucket policy that allows the CloudTrail service principal to write logs. If you create the trail through the console, AWS applies this policy automatically. For CLI setup, you need to apply the policy manually. See the AWS documentation for the required bucket policy. For guidance on locking down the bucket itself, see S3 security best practices.
To enable real-time alerting, send trail events to CloudWatch Logs and set up metric filters for high-priority events like root logins and IAM policy changes. For specific detection patterns and alerting setup, see detecting suspicious activity in AWS logs.
Protect your CloudTrail log bucket. If an attacker can delete or modify log files, your audit trail is compromised. Enable S3 Object Lock with a compliance-mode retention policy, block public access, and consider encrypting logs with a KMS key that only authorized roles can use.
Organization-scale use
In a single AWS account, one multi-region trail is sufficient. But most production environments involve multiple accounts managed through AWS Organizations. In that case, single-account thinking leaves gaps.
If each department in a company kept its own visitor log in a different format and a different filing cabinet, investigating a security incident across the company would be a nightmare. An organization trail is like a centralized visitor log that every department feeds into automatically, stored in a locked room only the security team can read.
An organization trail is created in the management account and automatically logs events from every member account. All logs go to one central S3 bucket (typically in a dedicated log archive account), giving your security team a single place to investigate across the entire organization.
- Member accounts cannot disable or modify the organization trail.
- Pair with a Service Control Policy that prevents member accounts from deleting their own trails or stopping CloudTrail logging.
- Keep the log archive account locked down with minimal access. It should be write-only for CloudTrail and read-only for the security team.
Organization trails only capture events from member accounts within the organization. If your teams also use standalone AWS accounts that are not part of the organization, those accounts need their own trails configured separately.
If you are running more than two or three AWS accounts, an organization trail is not optional. It is how you maintain a coherent audit trail. Set it up early, because retroactively centralizing logs from many accounts is significantly harder.
Common mistakes
- Relying only on Event History. Event History is limited to 90 days and management events only. It is useful for quick lookups, but it cannot replace a trail. Create a trail on day one.
- Creating a single-region trail. A single-region trail misses API calls made in other regions. An attacker launching resources in an unused region will not be logged. Always use
—is-multi-region-trail. - Leaving the log bucket unprotected. If the bucket has insufficient permissions, logs can be deleted or modified. Apply S3 Object Lock, block public access, and restrict delete permissions to a break-glass role only.
- Skipping log file validation. Without
—enable-log-file-validation, you cannot prove that logs were not tampered with after delivery. This is required by most compliance certifications and costs nothing to enable. - Enabling data events too broadly. Turning on S3 data events for all buckets in a high-traffic account can generate millions of log entries per day and a significant bill. Start with specific sensitive buckets and expand deliberately.
- Not thinking at organization level. Managing separate trails in each account creates gaps, inconsistency, and operational overhead. Use an organization trail to centralize logging across all accounts.
The most dangerous mistake on this list is leaving the log bucket unprotected. If an attacker can delete CloudTrail logs, they erase the evidence of everything they did. Enable S3 Object Lock in compliance mode on the log bucket before anything else. You cannot retroactively protect logs that were already deleted.
Summary
- CloudTrail records AWS API calls: who, what, when, from where, and the result.
- Event History gives you 90 days of management events for free. Trails deliver all event types to S3 for long-term storage. CloudTrail Lake provides managed SQL querying.
- Management events are logged by default. Data events, network activity events, and Insights events must be explicitly enabled.
- CloudTrail is not application logs, not performance metrics, and not configuration state tracking. Use CloudWatch and AWS Config for those.
- Create a multi-region trail with log file validation as your baseline setup.
- Protect the log bucket with Object Lock and restrict access tightly.
- In multi-account environments, use an organization trail to centralize logging.
Frequently asked questions
Is CloudTrail enabled by default?
Partially. AWS automatically records management events and shows them in Event History for 90 days at no cost. But Event History is limited. It does not store logs long-term, does not capture data events, and does not integrate with alerting. To keep logs beyond 90 days or capture more event types, you need to create a trail or a CloudTrail Lake event data store.
Event History vs trail: what is the difference?
Event History is a built-in 90-day rolling view of management events. It requires no setup and costs nothing, but you cannot extend its retention, log data events, or feed it into CloudWatch for alerts. A trail delivers events to an S3 bucket you control, with configurable retention, support for all event types, and integration with CloudWatch Logs, Athena, and other services.
Does CloudTrail record all activity in my AWS account?
CloudTrail records AWS API calls: who made the call, from where, what they called, and what the response was. By default it only records management events. Data events (like S3 object downloads), network activity events, and Insights events must be explicitly enabled. CloudTrail does not capture application-level logs, database queries, or the contents of your data.
How much does CloudTrail cost?
Event History is free. The first copy of management events delivered to a trail is free. Additional copies of management events cost $2 per 100,000 events. Data events cost $0.10 per 100,000 events. Insights events cost $0.35 per 100,000 management events analyzed. CloudTrail Lake charges for ingestion and queries. The biggest cost surprise is usually data events at high volume.
When should I use CloudTrail Lake instead of a trail with S3?
Use CloudTrail Lake when you want built-in SQL querying without setting up Athena, when you need to aggregate events from multiple accounts and regions into a single searchable store, or when you prefer a managed retention model over maintaining S3 lifecycle policies. Trails with S3 plus Athena give you more flexibility and lower storage cost at scale, but require more setup.