AWS CloudTrail configuration best practices: a practitioner’s guide
If you’re running workloads in AWS and haven’t spent deliberate time on CloudTrail configuration, you’re flying blind. In the event of a breach, your incident response team will feel that painfully. CloudTrail is your AWS audit trail: every API call, every console action, every SDK invocation flows through it. Get the configuration wrong and you lose the forensic evidence you need when regulators, insurers, or a compromised account demand answers. I’ve responded to enough AWS security incidents to know that the organisations that suffer most are almost never missing a firewall rule. They’re missing logs. This guide covers the configuration decisions that actually matter in production.
Why the default CloudTrail setup is not enough
CloudTrail is enabled on your AWS account when you create it and provides an event history of account activity from the past 90 days. That sounds reassuring until you look at what “default” actually means: no durable S3 storage, no encryption with a customer-managed key, and no tamper protection.
CloudTrail records three types of events: management events that capture control plane actions on resources; data events that capture data plane actions within a resource, such as reading or writing an S3 object; and Insights events that help identify unusual activity associated with API call rates and error rates. Out of the box, trails log management events only. Data events and Insights events are off by default.
For any environment handling sensitive data, whether that’s financial records, PII under UK GDPR, or government data, that default is inadequate. Getting to a robust configuration is not complicated. It just requires deliberate choices.
1. Deploy an organisation trail, not account-level trails
If you’re running AWS Organizations (and you should be), the single most impactful thing you can do is deploy an organisation-wide trail from your management account or a delegated security account.
Managing CloudTrail across multiple AWS accounts without centralisation leads to inconsistent settings, security gaps, and limited visibility. An organisation trail solves this by delivering logs from every member account to a single, hardened S3 bucket in a dedicated log archive account.
The account structure I recommend: a Log Archive account that receives all CloudTrail logs, Config snapshots, and VPC Flow Logs, protected by an SCP that prevents anyone from deleting logs; and a Security Tooling account running GuardDuty, Security Hub, and your detective controls. This separation means that even if the Security Tooling account is compromised, the log archive remains intact.
One important protection that often gets overlooked: when you enable an organisation trail, member accounts cannot disable it. A member account that is part of an organisation with an active organisation trail cannot stop that CloudTrail monitoring. That alone is worth the effort of setting it up correctly.
2. Enable all regions and global service events
Attackers often target unused regions on the assumption they’re less monitored. If CloudTrail isn’t active in all regions, activity there produces no evidence. A multi-region trail with IncludeGlobalServiceEvents set to true is the baseline. It captures IAM, STS, and CloudFront activity regardless of which region those API calls hit.
The CIS AWS Foundations Benchmark Level 1 controls are explicit here: CloudTrail must be enabled in all regions, and it must be integrated with CloudWatch Logs. These aren’t aspirational recommendations. They’re the floor.
3. Encrypt logs with a customer-managed KMS key
By default, CloudTrail encrypts log files using S3 server-side encryption (SSE-S3). That’s better than nothing, but it doesn’t give you key-level audit trails, separation of duties, or the ability to revoke access that a customer-managed key (CMK) provides.
CloudTrail logs should be encrypted using a CMK in the same region as the S3 bucket receiving them. As a security practice, add an aws:SourceArn condition key to the KMS key policy. This restricts CloudTrail to using the key only for the specific trail or trails you designate, rather than any principal with kms:Decrypt permissions.
One risk worth planning for: if an attacker disables or schedules deletion of the CMK, all future log decryption fails. Add kms:DisableKey and kms:ScheduleKeyDeletion to the SCP deny list for the trail encryption key. More on that in section 5.
Here’s a minimal CloudFormation snippet for the trail itself, with SSE-KMS and log file validation enabled:
AWSTemplateFormatVersion: "2010-09-09"
Description: "Organisation CloudTrail — security baseline"
Parameters:
LogBucketName:
Type: String
KMSKeyArn:
Type: String
Resources:
OrganisationTrail:
Type: AWS::CloudTrail::Trail
Properties:
TrailName: org-security-trail
S3BucketName: !Ref LogBucketName
IsLogging: true
IsMultiRegionTrail: true
IncludeGlobalServiceEvents: true
EnableLogFileValidation: true
KMSKeyId: !Ref KMSKeyArn
IsOrganizationTrail: true
EventSelectors:
- ReadWriteType: All
IncludeManagementEvents: true
DataResources:
- Type: AWS::S3::Object
Values:
- "arn:aws:s3:::my-sensitive-bucket/"
- Type: AWS::Lambda::Function
Values:
- "arn:aws:lambda"
Tags:
- Key: SecurityBaseline
Value: "true"
- Key: ManagedBy
Value: "SecurityTeam"
4. Enable log file integrity validation
This is one of the most consistently overlooked controls. Log file integrity validation uses SHA-256 hashing and RSA digital signatures to produce digest files every hour. These digest files let you cryptographically verify that no log files have been modified, deleted, or forged after delivery.
Without validation, an attacker who gains write access to the S3 bucket could alter logs to cover their tracks, and you’d have no way to prove it in court or to an auditor. For FCA-regulated firms and organisations handling data under UK GDPR, the ability to demonstrate log integrity is not optional. It needs to be on every trail.
5. Lock trails down with SCPs
An organisation trail gives you coverage. SCPs give you protection against someone turning that coverage off. A Service Control Policy can block attempts to delete trails, update configurations, or stop logging, ensuring audit logs remain intact regardless of what happens to individual account credentials.
Apply this at the root or security OU level, with an exception for your security break-glass role:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCloudTrailTampering",
"Effect": "Deny",
"Action": [
"cloudtrail:DeleteTrail",
"cloudtrail:StopLogging",
"cloudtrail:UpdateTrail",
"cloudtrail:PutEventSelectors",
"kms:DisableKey",
"kms:ScheduleKeyDeletion"
],
"Resource": "*",
"Condition": {
"ArnNotLike": {
"aws:PrincipalARN": [
"arn:aws:iam::*:role/SecurityBreakGlassRole"
]
}
}
}
]
}
AWS recommends using SCPs to prevent any tampering with CloudTrail. See the “Prevent tampering with AWS CloudTrail” section of “How to use AWS Organizations to simplify security at enormous scale” on the AWS Security Blog for the rationale behind this approach.
6. Integrate with CloudWatch Logs and enable Insights
Storing logs in S3 is necessary but not sufficient for real-time detection. Sending CloudTrail logs to CloudWatch Logs gives you the ability to build metric filters and alarms on specific API patterns, supporting both real-time alerting and historic investigation.
Beyond alarms, enable CloudTrail Insights. When enabled, Insights monitors API call rates and error rates, generating events when it detects statistically significant deviations: sudden spikes in resource provisioning, unusual access patterns, or abnormal error rates. Credential stuffing attacks, misconfigured Lambda functions spinning up thousands of invocations, and enumeration attempts all produce anomalous API patterns that Insights will surface automatically. It’s not a substitute for GuardDuty, but it catches a different class of signal.
7. Query CloudTrail efficiently during investigations
When a security event occurs, you need to move fast. The problem most teams hit is that analysts need to recall complex AWS CLI syntax across multiple services, manually correlate findings from GuardDuty and CloudTrail, and document every step for compliance, all under pressure.
AWS’s recently released Kiro CLI addresses this directly. It organises incident response into five phases (preparation, detection and analysis, containment, eradication and recovery, and post-incident activity) and provides structured tooling to triage GuardDuty findings, assess impacted EC2 resources, analyse CloudTrail logs, and generate remediation scripts. Investigations that previously took hours can run in minutes without skipping documentation steps.
For longer-term querying across months of history, Amazon Athena pointed at your CloudTrail S3 bucket remains the standard approach for most teams. If you’ve been using CloudTrail Lake, note that it will no longer be open to new customers from 31 May 2026. AWS recommends Amazon CloudWatch as the replacement for similar capabilities.
Common pitfalls to avoid
Relying on the 90-day event history
The default 90-day retention window is not enough. Most regulatory frameworks relevant to FCA-regulated firms require significantly longer retention periods. Configure S3 lifecycle policies to move logs to Glacier after 90 days and retain them for at least seven years for regulated data.
Logging management events but not data events
By default, CloudTrail logs management events only. The s3:ListBuckets API call is logged; s3:GetObject is not, because it’s a data event. If you’re handling sensitive objects in S3 or invocations of critical Lambda functions, the absence of data events means a data exfiltration incident may produce no CloudTrail evidence at all. Data events are priced per event, so be selective, but be deliberate about what you enable for sensitive resources.
Not monitoring for CloudTrail configuration changes
Given the role CloudTrail plays in incident response, failing to monitor changes to its own configuration is a significant gap. Create a CloudWatch metric filter covering cloudtrail:StopLogging, cloudtrail:DeleteTrail, and cloudtrail:UpdateTrail, and connect it to an SNS alert that reaches your security team immediately.
Orphaned S3 buckets from old trails
Buckets from previous CloudTrail configurations or security tool pilots can linger indefinitely. They introduce risk by leaving potentially sensitive log data unmonitored and unsecured, and they waste storage costs. Audit for S3 buckets with CloudTrail prefixes as part of any periodic security review.
Ignoring IAM Identity Center event structure changes
In early 2025, AWS modified the structure of CloudTrail events generated by IAM Identity Center. The changes affect how user identity information appears in the userIdentity element of CloudTrail records. Previously, certain fields used internal identifiers that were hard to correlate with human-readable usernames. The updated structure provides clearer attribution but requires updates to existing queries, alerts, and SIEM parsing rules. If your SIEM ingests CloudTrail and your organisation uses IAM Identity Center for federated access, audit your parsing logic now.
Putting it together
Getting CloudTrail right doesn’t require a multi-month programme. Six actions will move you from default to defensible:
- Deploy an organisation trail from a dedicated security account. It gives you consistent coverage and prevents member accounts from disabling monitoring.
- Encrypt with a CMK and add
aws:SourceArnto your KMS key policy. SSE-S3 is insufficient for regulated environments; a customer-managed key provides separation of duties and a full audit trail of decrypt operations. - Enable log file integrity validation on every trail. The SHA-256 digest files are your cryptographic proof that logs haven’t been altered, and you’ll need that proof when responding to an FCA audit or a GDPR breach investigation.
- Enforce SCP guardrails denying
cloudtrail:DeleteTrail,cloudtrail:StopLogging, andkms:ScheduleKeyDeletion. SCPs are the only control that a compromised account administrator cannot override. - Enable data events selectively for sensitive resources. S3 object-level events and Lambda invocations on critical functions close the gap between “we were breached” and “we can prove exactly what was accessed and when.”
- Integrate with CloudWatch Logs and enable Insights. Real-time alerting on anomalous API patterns transforms CloudTrail from a passive audit log into an active detection layer.