AWS CloudTrail Delivery Delays: Reading the DELIVERY_DELAY Indicator Before You Assume Logs Are Lost

CloudTrail captures API events and delivers them to an S3 bucket (and optionally CloudWatch Logs) on a batch schedule. CloudTrail does not deliver events in real time -- it aggregates events within a region and writes log files every few minutes. The documented delivery SLA is approximately 5-15 minutes for management events under normal conditions.

Several event types are inherently slower:

• IAM and STS events: these are global service events routed through us-east-1 regardless of where the caller was located. If your trail covers us-east-1, IAM events appear. If not, they are absent even though they were generated.
• ConsoleLogin events: routed through the global authentication endpoint and can lag 10-20 minutes behind the actual login.
• Data events (S3 object-level, Lambda invocations): written separately from management events and can have higher delivery latency during high-volume periods.

A 20-minute gap in a trail that covers only us-west-2 for IAM events is not a gap -- the events never existed in that trail to begin with.

Step 1: Check trail delivery status.

The fastest diagnostic is GetTrailStatus via the AWS CLI:

aws cloudtrail get-trail-status --name <trail-name> --region <region>

Key fields to read:

• IsLogging: must be true. If false, the trail was manually stopped or paused.
• LatestDeliveryTime: the timestamp of the most recent successful delivery. If this is hours old during a time when you expected activity, delivery has stalled.
• LatestDeliveryError: present when the most recent delivery attempt failed. The error message tells you why.
• LatestDeliveryAttemptTime: the most recent delivery attempt, regardless of success. If this is recent but LatestDeliveryTime is old, all recent delivery attempts are failing.

Step 2: Check for delivery errors.

Common delivery errors:

• S3.BucketDoesNotExist: the destination bucket was deleted or renamed
• S3.InsufficientS3BucketPolicy: the bucket policy was modified and no longer allows CloudTrail to write
• InsufficientEncryptionPolicyException: the KMS key policy was modified and CloudTrail can no longer use it
• InsufficientSnsTopicPolicyException: the SNS notification topic policy no longer permits CloudTrail to publish

Each of these produces a delivery error in GetTrailStatus and prevents ALL events from being delivered until fixed.

Step 3: Verify the trail covers the right regions.

Check whether the trail is multi-region:

aws cloudtrail describe-trails

Look at IsMultiRegionTrail. A single-region trail only captures events from its home region. IAM events only appear in us-east-1. If your trail is not multi-region and not in us-east-1, IAM and STS events are absent by design, not by failure.

Step 4: Check S3 delivery directly.

For events in the gap window, check the S3 bucket directly:

aws s3 ls s3://<bucket>/AWSLogs/<account-id>/CloudTrail/<region>/<year>/<month>/<day>/ --recursive | sort

If log files exist for the gap window and your SIEM simply hasn't ingested them yet, the logs are present and the issue is SIEM-side, not CloudTrail-side.

Fix: Trail stopped (IsLogging: false).

Restart logging:

aws cloudtrail start-logging --name <trail-name>

Note that events that were generated while the trail was stopped are not retroactively captured. CloudTrail only logs events going forward from when logging is re-enabled.

Fix: Bucket policy rejected delivery.

CloudTrail requires specific bucket policy conditions. The policy must allow cloudtrail.amazonaws.com to PutObject to the specific key prefix pattern. The easiest fix is to use the AWS Console to re-run the trail creation wizard against the existing bucket -- it will offer to update the bucket policy automatically. Alternatively, re-attach the standard CloudTrail bucket policy from the documentation.

Fix: KMS key policy change blocking delivery.

If the trail encrypts log files with a KMS key and the key policy was modified to remove CloudTrail's GenerateDataKey permission, delivery fails with InsufficientEncryptionPolicyException. Re-add the following to the KMS key policy:

{
  "Sid": "Allow CloudTrail to encrypt logs",
  "Effect": "Allow",
  "Principal": {"Service": "cloudtrail.amazonaws.com"},
  "Action": ["kms:GenerateDataKey*", "kms:DescribeKey"],
  "Resource": "*"
}

Fix: Organization trail with new member account.

For organization trails, new member accounts require the CloudTrail service role to have permission to write to the centralized bucket. If a new account was added to the org and its events are absent, check that the bucket policy includes arn:aws:iam::<new-account-id>:root or uses the organization-aware wildcard condition.

Check GetTrailStatus again.

After applying a fix, re-run GetTrailStatus. Within a few minutes of restoring delivery permissions, LatestDeliveryTime should update to a recent timestamp and LatestDeliveryError should clear.

Generate a test event and time delivery.

Make a simple, harmless API call (e.g., aws sts get-caller-identity) and note the timestamp. Watch the S3 bucket for a new log file containing that event. The time between the API call and the appearance of the log file in S3 is your current delivery latency. This confirms delivery is working and gives you an accurate latency baseline.

Set up a CloudWatch alarm on delivery failures.

CloudTrail publishes delivery status metrics. Configure a CloudWatch alarm on LatestDeliveryError to page when any delivery failure persists for more than 15 minutes. This eliminates the scenario where delivery fails silently for hours before an incident response team notices the gap.

Global service events in a single-region trail. IAM, STS, AWS Organizations, and Route 53 events are global and only appear in trails covering us-east-1. A trail in any other region misses them by design.

Data events not enabled. CloudTrail does not log S3 object-level operations (GetObject, PutObject, DeleteObject) or Lambda function invocations unless you explicitly enable data events on the trail. Management event trails do not capture these. If your gap covers S3 or Lambda operations, check whether data events are enabled:

aws cloudtrail get-event-selectors --trail-name <trail-name>

Approximately 5-15 minutes of events at trail startup. When a trail is first created or logging is re-enabled, the first delivery batch covers events from the moment logging started, not from earlier. Events from before the trail existed cannot be retroactively captured.

Events in Athena/SIEM but not visible in CloudTrail console. The CloudTrail console's Event History shows only the last 90 days and only management events for the region you are viewing. Events older than 90 days or in other regions require querying S3 directly or via Athena.

Open a support case when:

• IsLogging is true, there are no delivery errors, and LatestDeliveryTime is current, but events you know occurred are absent from both S3 and the CloudTrail Event History after 30+ minutes.
• You are using an organization trail and member account events are missing despite the trail and bucket policy being correctly configured.
• Delivery error messages reference an internal AWS service rather than a customer-controllable resource (errors mentioning 'internal failure' or 'AWS service error').

For a support case, provide: the trail ARN, the specific event types and timestamps expected but not found, the GetTrailStatus output, and the GetEventSelectors output. This documentation allows support to distinguish a service-side delivery issue from a customer configuration issue within minutes.