How to turn on audit logging in AWS

Why this matters

Audit logging in AWS starts with CloudTrail. CloudTrail records API activity: console sign-ins, IAM user creation, security group edits, S3 bucket policy changes, KMS key deletion. Each event carries the identity, source IP, user agent, time, and request parameters. If you only use the default Event history, you get 90 days of management events per region and no durable copy.

An active trail writes events to an S3 bucket as compressed JSON files plus digest files for log file validation. You can also stream the same events to CloudWatch Logs for search and alarms. That gives you two jobs done: evidence you can keep, and a way to page someone when a root user signs in or a trail is stopped.

Keep the log store away from the accounts it watches. A separate log archive account with a strict bucket policy means a compromised workload admin cannot delete the evidence. The same design makes customer security reviews and incident response much faster.

Before you start

Map your accounts and regions first. If you use AWS Organizations, create one organization trail from the management account and send logs to a central bucket. If you do not use Organizations, create a trail in each account and point them at a shared bucket with a cross-account policy. Write down which account owns the bucket and who can read it.

Pick a retention plan that matches your contracts and internal policy. A common setup keeps 90 days in S3 Standard, moves to Glacier after that, and expires after one year or longer. CloudTrail Event history is not a retention plan: it is 90 days and it lives in the same account.

You need permissions before you start: cloudtrail:CreateTrail, cloudtrail:StartLogging, s3:CreateBucket, s3:PutBucketPolicy, kms:CreateKey, logs:CreateLogGroup, iam:CreateRole, and organizations:CreateTrail for an organization trail. Use an admin role with MFA, not the root user. For the bucket, choose a name and region now, because changing the log destination later means a new trail.

Create a customer managed KMS key in the same region as the bucket. Its policy must let cloudtrail.amazonaws.com call kms:GenerateDataKey* and let your security team call kms:Decrypt. If the key policy is wrong, the trail starts but deliveries fail.

How to do it

Build the core trail first. Then add network and storage logs that fill gaps CloudTrail does not cover. Do this in a sandbox account if you have one, because you will change bucket policies and IAM roles.

Use the CloudTrail console for the first pass. It creates the bucket policy and IAM role for you, which reduces typos. Review both after the trail is live. For an organization trail, the management account is the only place you can create it.

Do not stop at CloudTrail. VPC Flow Logs show accepted and rejected network connections. S3 server access logs show request-level access, including HEAD requests, that CloudTrail data events do not cover by default. AWS Config records resource configuration changes over time. Together they answer different questions.

1. Create the log bucket. Create an S3 bucket in your log archive account and region. Turn on Block Public Access, versioning, and default encryption. Add a bucket policy that allows cloudtrail.amazonaws.com to write and denies non-TLS requests.
2. Create the trail. In CloudTrail, open Trails and create a trail. Apply it to all regions, send events to the S3 bucket, and turn on log file validation. Encrypt with SSE-KMS using a key whose policy allows CloudTrail.
3. Make it an organization trail. If you use AWS Organizations, create the trail from the management account and enable organization trail. New accounts get covered automatically. Review the bucket policy so it allows the organization ID.
4. Send logs to CloudWatch. Create a CloudWatch log group such as /aws/cloudtrail/org-trail. Let CloudTrail create the IAM role that writes to it. Then add metric filters for root sign-in, IAM policy changes, security group changes, and CloudTrail stops.
5. Enable selective data events. Add data events for S3 object-level actions on buckets with customer or regulated data. Add Lambda invoke and DynamoDB item changes only where needed. Use advanced event selectors to limit volume.
6. Turn on VPC Flow Logs. For each VPC, create a flow log that delivers to CloudWatch Logs or S3. Capture both accepted and rejected traffic. Use a log group per VPC or a central group with fields for account and interface.
7. Turn on S3 server access logging. For buckets that serve public content or hold sensitive data, enable server access logging. Point logs to a separate target bucket in the same region. Keep the target private and add a lifecycle rule.
8. Protect and retain logs. Restrict s3:DeleteObject and s3:PutBucketPolicy to a break-glass role. Enable MFA delete on the bucket and add a lifecycle rule to move logs to Glacier and expire them after your retention period. If you need immutable logs, create the bucket with S3 Object Lock enabled at creation time.

How to check it worked

Open CloudTrail in the console and go to Event history. Create a low-risk test change, such as tagging an EC2 instance or creating a test IAM user. Wait a few minutes, filter by event name, and open the event. Confirm the userIdentity, sourceIPAddress, and eventTime look right.

Check the trail status from the CLI: aws cloudtrail get-trail-status --name org-trail. IsLogging should be true, LatestDeliveryTime should be within the last few minutes, and LatestDeliveryError should be empty. Then list the bucket: aws s3 ls s3://your-bucket/AWSLogs/your-account-id/CloudTrail/ --recursive | head. You should see .json.gz files and digest files. An empty bucket usually means a bucket policy or KMS key policy problem.

Look in CloudWatch Logs for the log group you created. Open a stream and search for the test event. If you set a metric filter on root sign-in, test it in a sandbox account, not production. For VPC Flow Logs, check the flow log status in the VPC console and confirm records are arriving in the target log group or bucket. S3 server access logs can take a few hours to appear, so check the target bucket prefix the next day.

Add a weekly check of LatestDeliveryTime and a monthly review of who can delete logs. Delivery is silent when it breaks; the alarm should be on the absence of logs as well as on suspicious events.

Mistakes to avoid

One common mistake is a single-region trail. CloudTrail is regional, so a trail in us-east-1 does not record API calls in eu-west-1 unless it is multi-region. Turn on the all-regions option and confirm new regions are covered.

Another is storing logs in the same account with no protection. If an admin can delete the bucket or stop the trail, the audit record is gone. Use a separate log archive account, deny delete to normal roles, and turn on log file validation so you can prove files were not altered. If you need immutability, use Object Lock at bucket creation.

Turning on every data event is a fast way to create noise and cost. Start with S3 buckets that hold customer data, Lambda functions that process payments, and DynamoDB tables with regulated records. Use advanced event selectors and review volume after a week.

Logging without alerting is another trap. A trail that writes to S3 is evidence, not a monitoring system. Add metric filters and alarms for root sign-in, IAM policy changes, security group changes, CloudTrail stop or delete, and S3 bucket policy changes. Route alarms to a channel someone reads. If you want an outside check on logging, alerting and backup, the Cloud security review from Cloudverg is a fixed price $6,500 engagement that runs 2 to 3 weeks and starts within 10 business days. Treat it as one option among others.

Frequently asked questions