9 best practices for AWS CloudTrail compliance: Avoid the common mistakes

CloudTrail logs every API call made in your AWS account: who made it, when, from where, and what the result was. It is the record that answers "what happened?" during an incident investigation and "who made that change?" during an audit. Every UK-regulated business using AWS needs it configured correctly, not just enabled.

The common mistake is treating CloudTrail as a checkbox: it is on, therefore we are compliant. The reality is that a CloudTrail enabled only in one region, logging to an S3 bucket accessible to the same IAM roles that manage production infrastructure, without log file integrity validation or adequate retention, provides much weaker protection than a properly configured trail.

1. Enable CloudTrail in all regions

A single-region trail only captures API calls made in that region. Attackers and misconfigured services do not limit themselves to your primary region. An IAM role created in us-east-1, an EC2 instance launched in eu-west-1 by mistake, a Route 53 DNS change (a global service): all of these are missed by a single-region trail.

Create a multi-region trail. In the CloudTrail console, when creating a trail, select "Yes" for "Apply trail to all regions". This creates a single trail that captures events from every enabled region.

aws cloudtrail create-trail \
  --name org-wide-trail \
  --s3-bucket-name your-cloudtrail-bucket \
  --is-multi-region-trail \
  --include-global-service-events

The --include-global-service-events flag captures events from global services (IAM, STS, CloudFront, Route 53) that are not region-specific.

2. Create an organisation trail for multi-account environments

If you use AWS Organisations, a single organisation trail captures events from every member account and stores them centrally. Without an organisation trail, you need a trail per account, which is operationally complex to maintain consistently.

Create the organisation trail from the management account:

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name org-cloudtrail-bucket \
  --is-organization-trail \
  --is-multi-region-trail

Member accounts can view the trail but cannot modify or delete it. This provides tamper-resistance: a compromised member account cannot cover its tracks by disabling logging.

3. Enable both management and data events

CloudTrail management events (control-plane operations) are enabled by default. Data events (data-plane operations) are not.

Management events cover: creating and deleting IAM roles, modifying security groups, launching EC2 instances, creating S3 buckets. These are the configuration changes.

Data events cover: S3 object-level operations (GetObject, PutObject, DeleteObject), Lambda function invocations, DynamoDB item-level operations. These are the actual data accesses.

For compliance with GDPR (data subject access requests require knowing who accessed personal data) and PCI DSS (cardholder data access must be logged), data events for S3 buckets and other services containing regulated data are required, not optional.

Enable data events selectively for regulated data buckets rather than enabling them for all S3 operations globally. All-bucket data events generate very high log volumes and cost.

4. Protect the S3 bucket storing CloudTrail logs

CloudTrail logs are only as trustworthy as the bucket that stores them. A bucket accessible to the same IAM roles that manage production infrastructure can be modified or deleted by someone covering their tracks.

S3 bucket configuration for the CloudTrail log bucket: - Block all public access: enabled - Versioning: enabled (prevents log deletion by overwriting; deleted versions remain recoverable) - MFA Delete: enabled (requires MFA device to delete object versions; prevents automated deletion) - S3 Object Lock: enable with Governance mode and a retention period matching your compliance requirement - Bucket policy: deny all s3:Delete* and s3:Put* actions from all principals except the CloudTrail service principal and your designated log archive role

Keeping the CloudTrail log bucket in a separate, dedicated log archive account (a common multi-account pattern) provides the strongest protection: even if a workload account is fully compromised, the attacker cannot access the log archive account.

5. Enable log file integrity validation

Log file integrity validation uses cryptographic hashing to detect whether log files have been tampered with or deleted after delivery to S3. CloudTrail creates a digest file every hour containing the SHA-256 hash of each log file delivered during that period. Each digest file is signed with the CloudTrail private key.

Enable it when creating or updating a trail:

aws cloudtrail update-trail \
  --name your-trail \
  --enable-log-file-validation

To validate a log file after the fact:

aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:eu-west-2:ACCOUNT:trail/your-trail \
  --start-time 2026-01-01T00:00:00Z

This validation confirms that the log record has not been altered since CloudTrail delivered it. An audit that cannot confirm log integrity is weaker evidence than one that can.

6. Encrypt logs with customer-managed KMS keys

CloudTrail logs can be encrypted with an AWS KMS customer-managed key (CMK) rather than the default S3 server-side encryption. CMK encryption provides: - Access control at the key level (in addition to S3 IAM permissions) - Key rotation that you control - The ability to prevent access by rotating or disabling the key - Audit evidence that you control the encryption key (required by some compliance frameworks)

Create a CMK in KMS, configure the key policy to allow CloudTrail to use it, and specify the CMK ARN when creating the trail:

aws cloudtrail update-trail \
  --name your-trail \
  --kms-id arn:aws:kms:eu-west-2:ACCOUNT:key/your-key-id

7. Set retention matching your compliance obligation

CloudTrail delivers logs to S3 with no retention limit (S3 objects persist until deleted). Apply S3 Lifecycle rules to the CloudTrail bucket to manage retention:

  • Online (queryable) retention: 90 days in S3 Standard or S3 Standard-IA for Athena queries during active investigation windows
  • Archive retention: move to Glacier Deep Archive after 90 days, retain for the compliance-required period (PCI DSS: 12 months with 3 months immediately available; FCA: typically 5-7 years for some record types)
  • Deletion: apply only after the mandatory retention period expires

UK GDPR does not specify a fixed retention period for security logs, but the standard of evidence for a data breach investigation typically requires at least 12 months of detailed access logs.

8. Integrate with CloudWatch Logs for real-time alerting

CloudTrail logs delivered to S3 support forensic investigation but not real-time alerting. Integrate CloudTrail with CloudWatch Logs for near-real-time detection of critical events.

Configure the trail to deliver to a CloudWatch Logs log group. Then create metric filters on specific high-priority events:

  • Root account console sign-in: eventName = ConsoleLogin AND userIdentity.type = Root
  • IAM policy changes: eventSource = iam.amazonaws.com AND (eventName = CreatePolicy OR eventName = DeletePolicy OR eventName = AttachRolePolicy)
  • Security group modifications: eventName = AuthorizeSecurityGroupIngress
  • Trail configuration changes (someone trying to disable logging): eventSource = cloudtrail.amazonaws.com

Create CloudWatch alarms on these metric filters with SNS notifications routing to your on-call channel.

9. Review logs regularly, not only during incidents

CloudTrail logs are most commonly reviewed during incident investigations, which means findings come after the fact. Periodic proactive review catches suspicious patterns earlier.

Schedule a monthly CloudTrail review using Athena to query for: - Unusual API calls from unexpected source IPs - Root account activity (should be near-zero) - Failed authentication attempts above baseline - Large data transfers out of S3 buckets containing sensitive data

Athena queries against S3-stored CloudTrail logs are cost-effective (charged per data scanned, which is low for targeted queries on partitioned log data).

Where Critical Cloud comes in

CloudTrail configuration that satisfies a checklist and CloudTrail configuration that actually provides the protection and evidence your regulators expect are different things. We configure and operate CloudTrail for regulated businesses, with log integrity validation, multi-account trails, and detection rules that surface meaningful events rather than raw log noise. As the world's first Powered by Datadog accredited partner, we correlate CloudTrail events with infrastructure and application signals in a single operational view. See how Critical Support works.