AWS CloudTrail Audit Logs

You’ve locked down IAM, encrypted your data, and hardened your containers—but if someone exfiltrates an S3 bucket or deletes a production database, will you even know? Most cloud breaches go undetected for months because engineers skip the audit trail. AWS CloudTrail is your forensic backbone: it records every API call in your account, giving you the who, what, when, and where for security investigations, compliance audits, and incident response. This lesson teaches you how to use AWS CloudTrail for audit logs so you can answer the question, "What happened in my AWS account?"—before an auditor or attacker does.

The problem this lesson solves

Without CloudTrail, you're flying blind in the cloud. Imagine a developer accidentally deletes a production DynamoDB table, or a compromised access key starts launching expensive EC2 instances. AWS has no built-in record of these API calls unless you enable CloudTrail. You can't audit permissions, detect anomalies, or prove compliance with frameworks like SOC 2 or PCI-DSS.

CloudTrail addresses this by capturing all read, write, and management events across compute, storage, networking, IAM, and more. It gives you:

• Visibility: every API call logged, including who made it, from which IP, and with what result.
• Accountability: tie actions to IAM users or roles, and detect misused credentials.
• Compliance: produce audit-ready logs for regulators and customers.
• Incident response: reconstruct the exact sequence of events before and during a breach.

The cost of ignoring CloudTrail: a breach you didn't detect, compliance fines, and a reputation hit. In this lesson, you'll learn not just what CloudTrail logs, but how to make it work for you in practice.

Core concept / mental model

Think of CloudTrail as a security camera for your AWS account. Every API call is a frame: the actor (who), the action (what), the resource (target), the source IP (where), and the time (when). CloudTrail records all of this into an event, which is then delivered to an S3 bucket or CloudWatch Logs.

The key mental model is the CloudTrail trail—a configuration object that specifies:

• Which account events to capture (e.g., all regions or a single region).
• Where to store the logs (S3 bucket, CloudWatch Logs, or both).
• Whether to enable multi-region or single-region capture.
• Optional data events for high-volume resource-level actions like S3 object operations.

CloudTrail writes logs in JSON format, gzipped, in 5-minute intervals—it's not real-time, but nearly. The trail is like a recorder; the S3 bucket is the tape; and the event history UI is the playback screen.

Here's a common analogy: if IAM is the lock on your front door, CloudTrail is the security system that records who enters and with which key. You might have the best locks, but without a camera, you can't prove who broke in.

Key terms you'll encounter

• Management events: control-plane operations like ec2:RunInstances or iam:CreateUser.
• Data events: resource-level operations like s3:GetObject or lambda:InvokeFunction (not enabled by default).
• Insights events: detection of unusual activity patterns (separate feature, not this lesson).
• Event history: searchable view in the Console, typically 90 days of events.

How it works step by step

Here’s the logical sequence from click to log:

1. You enable a CloudTrail trail (either via Console, CLI, or CloudFormation).
2. CloudTrail starts capturing API calls from services in the specified regions. Every API call generates a CloudTrail event.
3. CloudTrail writes events to the specified S3 bucket as compressed JSON files, typically in 5-minute batches. Optionally, it can send them to CloudWatch Logs for real-time monitoring and alerting.
4. You (or Ops) retrieve and analyze logs—either using the Console event history, Athena queries, or external SIEM tools.

5. You review the logs to answer audit questions: Which IAM user deleted that bucket? When? From which region?

   the flow is: enable trail → capture events → store to S3 → analyze with tools.

Hands-on walkthrough

Now let’s get your hands dirty. We’ll use the AWS CLI to create a trail, make a test API call, and read the resulting log. Make sure you have the aws CLI installed and configured with appropriate permissions (cloudtrail:CreateTrail, s3:CreateBucket, etc.).

Step 1: Create an S3 bucket for logs

CloudTrail needs a destination. Create a bucket that isn't public, and enable versioning for extra safety:

aws s3api create-bucket --bucket my-cloudtrail-logs-2025 \
  --region us-east-1
aws s3api put-bucket-versioning --bucket my-cloudtrail-logs-2025 \
  --versioning-configuration Status=Enabled

Pro tip: Use a unique bucket name (globally unique across all AWS accounts). Consider adding a prefix like security/cloudtrail/ to organize logs.

Step 2: Create a CloudTrail trail (all regions)

aws cloudtrail create-trail \
  --name my-audit-trail \
  --s3-bucket-name my-cloudtrail-logs-2025 \
  --is-multi-region-trail \
  --enable-log-file-validation

This creates a trail that captures events from all regions and enables file validation (SHA-256 hashes to detect tampering).

Step 3: Start logging

aws cloudtrail start-logging --name my-audit-trail

Step 4: Make a test API call

aws ec2 describe-instances --region us-east-1

Step 5: Read the latest log file

After a few minutes, list the files in your bucket:

aws s3 ls s3://my-cloudtrail-logs-2025/AWSLogs/<account-id>/CloudTrail/ --recursive

Then download and decompress the latest .json.gz file, and grep for DescribeInstances:

aws s3 cp s3://my-cloudtrail-logs-2025/AWSLogs/<account-id>/CloudTrail/ <local-dir> --recursive --exclude "*" --include "*.json.gz"
find . -name "*.gz" -exec gunzip {} \;
grep -l "DescribeInstances" *.json

Examine the event with jq to see the key fields:

cat .json | jq '.Records[] | {eventTime, userName, eventName, sourceIPAddress, errorCode, errorMessage}'

{
  "eventTime": "2025-04-01T15:30:00Z",
  "userName": "alice@example.com",
  "eventName": "DescribeInstances",
  "sourceIPAddress": "203.0.113.7",
  "errorCode": null,
  "errorMessage": null
}

Congratulations—you’ve captured your first audit event! This is the core pattern of AWS CloudTrail audit logs: enable a trail, make a call, read the record.

Automate with CloudFormation (optional)

For production, declare the trail as code:

Resources:
  CloudTrailBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-prod-audit-logs
      VersioningConfiguration:
        Status: Enabled
  MyTrail:
    Type: AWS::CloudTrail::Trail
    Properties:
      TrailName: my-audit-trail
      S3BucketName: !Ref CloudTrailBucket
      IsMultiRegionTrail: true
      EnableLogFileValidation: true

Compare options / when to choose what

Not all trails are equal. Here’s how to choose your security posture:

When to choose what:

• Single-region for a test environment or a region-isolated workload.
• Multi-region for production accounts to catch all activity.
• Enable data events for critical S3 buckets with personal data or sensitive IP.
• Use Insights events (if budget allows) to detect API call anomalies.

Variation: CloudWatch Logs destination—stream events for real-time alerting with Lambda or SIEM integration. Some teams prefer this over raw S3 for operational visibility.

Troubleshooting & edge cases

• No log files appear: check that you started logging (start-logging), that the S3 bucket policy allows CloudTrail to write (CloudTrail auto-configures on create, but custom policies can block), and that the trail is in the right region.
• Log files are empty: you may not have made any API calls yet, or you’re looking before the 5-minute aggregation window.
• AccessDenied when reading logs: your IAM user needs s3:GetObject permissions on the bucket; attach a policy like AmazonS3ReadOnlyAccess.
• Cant find an event: If the action was a data event (like S3 read), you must have data events enabled; management events won’t show it.
• Log file validation fails: indicates tampering; investigate immediately—someone may have altered the logs.
• CloudTrail disabled accidentally: check the trail status; if Inactive, call start-logging again.

Pro tip: Always enable CloudTrail before you first use your production account to ensure no gaps in your audit trail.

What you learned & what's next

You’ve mastered the core of use AWS CloudTrail for audit logs: you know how to create a trail, capture events, and analyze logs for security and compliance. You can now explain the difference between management and data events, and you’ve seen how to automate trail creation with CloudFormation.

Review goals: You achieved both learning objectives—explaining the core idea and completing a hands-on exercise.

Best practices to carry forward:

• Enable multi-region trails for all production accounts.
• Turn on log file validation to detect tampering.
• Enable data events for your highest-risk resources (S3, Lambda).
• Stream logs to CloudWatch for real-time alerts on suspicious activity.
• Restrict S3 bucket permissions to prevent unauthorized reads of logs.

Next in the track: Now that you can audit actions, the next step is to detect and respond to threats using services like GuardDuty and Security Hub. You’ll combine CloudTrail logs with threat detection to build a complete security monitoring pipeline.