Centralized Logging Across AWS Accounts to S3

A DevOps engineer is setting up centralized logging for multiple AWS accounts. They need to collect VPC Flow Logs, CloudTrail logs, and application logs into a single Amazon S3 bucket. What is the most efficient approach?

⚠ Common exam trap

The trap here is that candidates often overcomplicate the solution by choosing managed services like Kinesis or Lambda, when a simple S3 bucket policy with cross-account write access is the most efficient and AWS-recommended approach for centralized log aggregation.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use an S3 bucket in a centralized logging account with a bucket policy that grants write access from all other accounts.

It uses a centralized logging account with a single S3 bucket configured with a bucket policy that grants write access (s3:PutObject) to all other accounts. This approach avoids data duplication, eliminates the need for replication or intermediate compute resources, and is the most efficient and cost-effective method for aggregating logs from multiple accounts into a single destination.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Configure a Lambda function in each account to copy logs to a central S3 bucket.
Why it's wrong here
Invoking a Lambda function in each account to copy logs is an anti-pattern because it requires building and maintaining custom code, IAM roles, and event triggers per account. Every log source (e.g., CloudTrail, VPC Flow Logs, application logs) would need a distinct subscription or notification pipeline, and Lambda offers no built-in retry semantics for failed S3 writes beyond its limited dead-letter queue. This adds operational burden and failure points when the native S3 bucket-policy approach already supports direct cross-account writes.
✗
Create an S3 bucket in each account and use S3 replication.
Why it's wrong here
Enabling S3 replication from per-account buckets requires source and destination buckets to have versioning enabled, creates asynchronous copying with publication lag, and only starts replicating objects written after the rule is configured—pre-existing logs are excluded. Cross-account replication also depends on IAM roles in each source account and incurs replication fees, making it slower and more expensive than direct writes. To centralize logs, you want a single destination with immediate, service-native PutObject calls, not eventual copies.
✗
Use Amazon Kinesis Data Firehose to stream logs from all accounts to a central S3 bucket.
Why it's wrong here
Amazon Kinesis Data Firehose is a streaming ingestion service, not a log-delivery mechanism; it requires a producer to send records, so every account would still need CloudWatch Logs subscriptions or Lambda functions to forward logs into the Firehose stream. Data Firehose introduces buffering delays of 60–900 seconds, per-GB costs, and compression/formatting configuration before delivering to S3. For centralized logging, the extra hop and latency undercut the simplicity of having AWS services like CloudTrail write directly to a shared bucket via a bucket policy.
✓
Use an S3 bucket in a centralized logging account with a bucket policy that grants write access from all other accounts.
Why this is correct
Placing a single S3 bucket in a centralized logging account with a bucket policy that grants s3:PutObject to principals in all source accounts is the most efficient pattern because CloudTrail, VPC Flow Logs, and similar services can deliver logs cross-account natively without additional moving parts. The bucket policy can restrict writes using aws:SourceArn or aws:SourceAccount conditions to prevent the confused-deputy problem, and the central account owns objects for unified lifecycle and access control. This direct-write model achieves lower latency and zero maintenance compared to middleware or copying mechanisms.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

Centralized Logging Across AWS Accounts to S3

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question