CloudTrail's Single-Region Default Blinds Whole Accounts
A CloudTrail trail provisioned through Terraform or the CLI without the multi-region flag logs only its home region, yet dashboards, S3 delivery, and audit sign-off all read as if account-wide API activity is captured. GuardDuty correlation, incident forensics, and compliance evidence for AWS all silently exclude every other region until someone checks the IsMultiRegionTrail attribute directly.
Operational summary
At a glance
- Symptom
- API activity occurs in a region outside the trail's home region and is never delivered to the log bucket.
- Likely cause
- CloudTrail trail created with IsMultiRegionTrail=false via CLI or Terraform default.
- Impact
- Incident responders and GuardDuty lose all management-event visibility outside the home region, with no error to signal the gap.
- Verification signal
- Re-run the detection test and a controlled negative-path test.
- Safe correction
- Force is_multi_region_trail=true on every trail, enforce via AWS Config managed rule cloudtrail-multi-region-enabled, and use an organization trail from the management account.
- Rollback or recovery
- Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
The Trap
A CloudTrail trail created with IsMultiRegionTrail=false, inherited silently from the AWS CLI and Terraform defaults, while everyone downstream treats it as account-wide coverage.
The Default State
aws cloudtrail create-trail sets IsMultiRegionTrail to false unless you explicitly pass --is-multi-region-trail. The Terraform aws_cloudtrail resource does the same: is_multi_region_trail defaults to false. Both scope the trail to whichever region the API call or Terraform provider was targeting, typically us-east-1. The console wizard has defaulted its toggle to “Enabled for all regions” since 2019, so console-built trails look global, which is exactly why teams stop checking the flag on trails built through IaC or scripted provisioning. A trail exists, an S3 bucket receives objects, CloudWatch Logs shows entries, and the box gets ticked.
The Blast Radius
Every management event outside the home region simply never reaches the trail. IAM user creation, security group modification, EC2 launches, and S3 bucket policy changes in eu-west-1 or ap-southeast-2 generate no CloudTrail record at all, not a filtered one, an absent one. GuardDuty findings that depend on correlating CloudTrail management events return empty for those regions. Incident responders reconstructing a breach find zero API history for the region where the attacker actually operated, because reconnaissance and lateral movement rarely stay in one region on purpose. Auditors accept the trail’s existence during a SOC 2 or ISO 27001 review without pulling describe-trails to check the boolean, so the compliance evidence is built on a false premise. CloudTrail Lake queries and Insights, which only ingest from trails actually forwarding events, inherit the same blind spot without any error state to flag it.
The Lead Mechanic Fix
Run aws cloudtrail update-trail --name <trail-name> --is-multi-region-trail on every existing trail and verify with aws cloudtrail describe-trails --query 'trailList[].[Name,IsMultiRegionTrail]'. In Terraform, set is_multi_region_trail = true explicitly rather than relying on defaults, and add a plan-time check that rejects any aws_cloudtrail resource without it. Deploy the AWS Config managed rule cloudtrail-multi-region-enabled with automatic remediation, and replace per-account trails with a single organization trail created via aws cloudtrail create-trail --is-organization-trail --is-multi-region-trail --name org-trail from the management account, so member accounts cannot narrow the scope.
Apply the safer control
Before you change production
Confirm the affected scope, export the current configuration, and test the replacement control in a non-production environment first.
Fix commands and configuration
aws cloudtrail update-trail --name <trail-name> --is-multi-region-trailaws cloudtrail describe-trails --query 'trailList[].[Name,IsMultiRegionTrail]'is_multi_region_trail = trueVerify, roll back or escalate
Verify
Re-run the detection test and a controlled negative-path test. Confirm the unsafe behaviour is blocked while approved traffic still succeeds.
Rollback
Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
Escalate
Escalate when the blast radius is uncertain, the control cannot be tested safely, or remediation requires an outage or security exception.