7 best practices for AWS audit logs: Setup, retention, and actual usefulness

Audit logs prove what happened. When an incident occurs, audit logs answer: which IAM identity made the change, from which IP address, at what time, and what was the result. When a regulator asks for evidence of access controls, audit logs provide it. When someone claims they did not make a change, audit logs confirm or contradict the claim.

AWS audit logging is primarily CloudTrail, but complete audit coverage also includes VPC Flow Logs, S3 access logs, and application-level logs. These seven practices cover the setup, protection, and operational use of AWS audit logs.

1. Enable multi-region CloudTrail logging

Single-region CloudTrail trails miss activity in other regions. AWS global services (IAM, STS, Route 53, CloudFront) log to us-east-1 unless you enable global service events. An attacker who creates an IAM role in a region you do not monitor leaves no trace in a single-region trail.

Enable a multi-region trail that also captures global service events:

aws cloudtrail update-trail \
  --name your-trail \
  --is-multi-region-trail \
  --include-global-service-events

For organisations using AWS Organisations, create an organisation trail from the management account. The organisation trail automatically captures events from all member accounts and cannot be disabled by member accounts, providing tamper-resistance.

2. Implement strict access controls on log storage

The S3 bucket that receives CloudTrail logs must be protected from the same IAM roles that manage the workloads being audited. If a production administrator can delete CloudTrail logs, the audit trail is not trustworthy.

Configure the log bucket: - Ownership: a dedicated log archive account, separate from workload accounts - Bucket policy: deny all writes except from the CloudTrail service principal (cloudtrail.amazonaws.com) - Deny delete permissions to all principals except a designated log archive administrator with MFA - Enable MFA Delete on the bucket to require MFA for permanent log deletion - Block all public access: enabled unconditionally

IAM roles in workload accounts should have read-only access to their own trail logs (for investigation) and no write or delete access. Log modification should be impossible from workload accounts by design.

3. Enable log file integrity validation

CloudTrail delivers a signed digest file every hour containing the SHA-256 hash of each log file. If a log file is deleted or modified after delivery, the digest file will not match, proving tampering.

Enable integrity validation:

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

Validate logs when evidence integrity matters:

aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:REGION:ACCOUNT:trail/your-trail \
  --start-time 2026-01-01T00:00:00Z \
  --end-time 2026-01-31T23:59:59Z

A validation that returns no errors confirms the logs are unmodified since CloudTrail delivered them. This is the evidence that log integrity has been maintained, which FCA, PCI DSS, and ISO 27001 auditors ask for.

4. Set retention policies that match your compliance obligations

Log retention has two dimensions: how long you keep the data and how quickly you can retrieve it.

Online retention (queryable): Logs in S3 Standard or Standard-IA can be queried with Athena within minutes. Keep 90 days of logs in online storage for active investigation of recent incidents.

Archive retention: Logs older than 90 days move to Glacier Instant Retrieval (minutes to retrieve) or Glacier Deep Archive (hours to retrieve). The cost difference is significant: S3 Standard at £0.018/GB vs Glacier Deep Archive at £0.00077/GB.

Minimum retention periods: - UK GDPR: no fixed minimum for security logs, but a personal data breach investigation typically requires 12+ months - PCI DSS: 12 months total retention with the most recent 3 months immediately available - FCA operational resilience: typically 5-7 years for some record categories

Implement S3 Lifecycle rules on the CloudTrail bucket to automate the transition and deletion schedule. Use S3 Object Lock with a Compliance mode retention period equal to your longest mandatory retention period to prevent premature deletion even by administrators.

5. Connect CloudTrail to CloudWatch Logs for real-time detection

S3-stored CloudTrail logs support forensic investigation. For real-time detection of high-priority events, stream CloudTrail events to a CloudWatch Logs log group.

Configure the CloudTrail trail to deliver to CloudWatch Logs. Then create metric filters for critical events:

Root account activity:

{$.userIdentity.type = "Root" && $.eventType != "AwsServiceEvent"}

Disabling or modifying CloudTrail:

{($.eventName = StopLogging) || ($.eventName = DeleteTrail) || ($.eventName = UpdateTrail)}

Security group changes:

{($.eventName = AuthorizeSecurityGroupIngress) || ($.eventName = RevokeSecurityGroupIngress)}

Create CloudWatch alarms on these metric filters with SNS alerts routing to your security or on-call channel. Root account activity should trigger an immediate alert regardless of time of day.

6. Encrypt audit logs with customer-managed keys

Encrypting CloudTrail logs with a customer-managed KMS key (CMK) provides access control at the key level independent of S3 IAM policies. Even if a principal has S3 read access to the log bucket, they cannot read the log content without the KMS key permission.

Configure CMK encryption for CloudTrail:

  1. Create a CMK in KMS with a key policy that allows CloudTrail to use it (kms:GenerateDataKey, kms:Decrypt)
  2. Specify the CMK ARN in the trail configuration
  3. Grant KMS key access only to authorised auditors and the log archive administrator

KMS key usage is logged in CloudTrail itself, creating a record of who accessed the encryption key. This creates a second-order audit trail: not only are workload API calls logged, but access to those logs is also logged.

7. Query logs regularly rather than only during incidents

A log that is only reviewed during incidents is evidence collected after the fact. A log reviewed on a schedule catches anomalies before they become incidents.

Set up weekly Athena queries against the CloudTrail S3 data:

-- Find root account API calls in the last week
SELECT userIdentity.type, eventName, sourceIPAddress, eventTime
FROM cloudtrail_logs
WHERE userIdentity.type = 'Root'
  AND eventTime > TIMESTAMP '2026-06-01 00:00:00'
ORDER BY eventTime DESC;

-- Find all IAM changes in the last week  
SELECT userIdentity.userName, eventName, requestParameters, eventTime
FROM cloudtrail_logs
WHERE eventSource = 'iam.amazonaws.com'
  AND eventTime > TIMESTAMP '2026-06-01 00:00:00'
  AND eventName IN ('CreateUser', 'DeleteUser', 'AttachRolePolicy', 'CreateAccessKey')
ORDER BY eventTime DESC;

Review these results in a weekly security review meeting. Findings that would be alarming in isolation (an IAM user created outside of the normal provisioning process) are caught within a week rather than months later during an investigation.

Where Critical Cloud comes in

Audit log management for regulated businesses requires configuration, protection, retention management, and active monitoring. Most organisations have CloudTrail enabled but miss the protection, retention, and detection layers. We configure and operate AWS audit logging for FCA, PCI DSS, and ISO 27001-regulated businesses, with detection rules surfacing relevant events in operational tooling rather than buried in log files. As the world's first Powered by Datadog accredited partner, we correlate CloudTrail security events with infrastructure and application signals. See how Critical Support works.