AWS Scenarios
Secure Cross-Account CloudTrail Logging
Design centralized AWS CloudTrail logging across accounts using AWS Organizations, an organization trail, a log archive account, S3 bucket policies, encryption, and immutability controls.
After this, you will understand
Centralized logging is the multi-account pattern that proves accounts are not just billing folders: they are ownership and audit boundaries.
Create an organization trail and deliver logs from all accounts to a protected S3 bucket in a dedicated log archive account.
Teams let each workload account own its own logs, so a compromised account can tamper with the evidence needed for investigation.
Separate workload accounts from log ownership, then lock down CloudTrail delivery, S3 bucket policy, KMS access, retention, and validation.
Think before readingWhy should production logs often land in a separate log archive account?
Reading in progress
This page is saved in your local study history so you can continue later.
Concepts Covered
- Multi-account logging
- AWS Organizations
- Organization trails
- CloudTrail management events
- S3 log archive bucket
- Bucket policy for CloudTrail delivery
- KMS key policy
- Log file validation
- Retention and immutability
- SAA-C03 governance traps
1. Situation
An organization uses multiple AWS accounts: production, development, shared networking, security tooling, and sandbox accounts. The security team needs centralized audit logs for AWS API activity across all accounts.
The logs must be protected from accidental or malicious deletion by workload teams. New accounts should automatically be covered. The design should support investigation, compliance evidence, and long-term retention.
This is an important AWS architecture scenario because it combines accounts, Organizations, IAM, S3, CloudTrail, KMS, and least privilege.
The usual answer is an organization trail delivering logs to a protected S3 bucket in a dedicated log archive or security account.
2. Naive Design
The naive design lets every account configure its own CloudTrail trail and S3 bucket:
dev account -> dev logs bucket
prod account -> prod logs bucket
sandbox account -> sandbox logs bucket
Each workload team owns the bucket that stores its logs. Some accounts may forget to enable trails. New accounts may not be covered. Bucket policies, encryption, lifecycle, and retention settings drift.
Another naive design sends all logs to an S3 bucket in the production account because production is "important." That still lets production account administrators or a production compromise reach the log storage boundary.
The audit system should not be owned by the same account it is auditing.
3. What Breaks
Coverage breaks when new accounts are created without logging. Investigation breaks when logs are scattered across accounts with inconsistent naming, retention, and permissions.
Evidence integrity breaks when workload administrators can delete or modify their own logs. A compromised administrator in an account could try to remove traces of unauthorized actions.
Access control breaks when bucket policies are too broad. CloudTrail needs permission to write logs, but normal workload principals should not be able to change or delete them.
Encryption can break delivery if KMS key policies do not allow CloudTrail and the right principals. Querying can break if analysts have no read path to the archive.
Centralized logging is not just "turn CloudTrail on." It is a protected data pipeline.
4. AWS Architecture
Use AWS Organizations and create an organization trail from the management account or delegated administrator where supported.
Deliver CloudTrail logs to an S3 bucket in a dedicated log archive account. Configure the bucket policy so CloudTrail can write logs for the organization. Restrict normal principals from deleting or modifying log objects.
Use SSE-S3 or SSE-KMS depending on requirements. If using KMS, configure the key policy so CloudTrail can encrypt log files and authorized security principals can decrypt for investigation.
Enable log file validation so investigators can verify whether delivered log files changed after CloudTrail delivered them.
Add lifecycle policies for retention and transition to cheaper storage classes. For stronger immutability requirements, consider S3 Object Lock with an appropriate retention mode and governance process.
The shape:
AWS Organizations
-> organization CloudTrail trail
-> S3 log archive bucket in log account
-> security analytics and investigation access
5. Request Or Data Flow
An API call happens in a member account, such as ec2:RunInstances or s3:PutBucketPolicy.
CloudTrail records the management event according to trail configuration. For data events, such as S3 object-level access or Lambda invocations, the trail must explicitly include those event selectors when needed.
CloudTrail delivers log files to the central S3 bucket. The bucket policy allows CloudTrail service delivery for the organization trail. If KMS is used, CloudTrail also needs encryption permission.
Security users or tools read from the archive bucket using tightly scoped roles. Athena, Security Lake, SIEM tools, or custom pipelines may query or process logs depending on the organization's maturity.
Lifecycle rules transition older logs to cheaper storage while preserving required retention.
6. Security Controls
Separate ownership. Put the log archive bucket in an account that application teams do not administer.
Use a restrictive bucket policy. Allow CloudTrail to write to the expected prefixes. Deny insecure transport where appropriate. Restrict delete permissions.
Use KMS key policies carefully if encrypting with a customer-managed key. CloudTrail delivery and security-reader roles need the right permissions, but workload accounts should not have broad decrypt access.
Enable CloudTrail log file validation. It helps detect whether log files were modified or deleted after delivery.
Use S3 versioning and Object Lock if retention requirements demand stronger protection.
Monitor changes to CloudTrail, S3 bucket policies, KMS keys, and organization settings. The logging system itself is a high-value target.
7. Resilience Controls
An organization trail improves coverage because it applies to member accounts in the organization, including newly added accounts.
S3 provides durable log storage. Lifecycle policies can move logs to archive storage while retaining them for compliance.
For higher resilience, consider replication to another Region or account if the business requires regional disaster recovery for audit logs.
Avoid a single human administrator as the operational dependency. Use roles, break-glass procedures, and change management.
Validate the full delivery path periodically. A broken bucket policy or KMS key policy can silently become an audit emergency if no one checks.
8. Performance Controls
CloudTrail delivery is managed. The main performance concern is downstream analysis.
Partition log storage by account, Region, service, and date as CloudTrail does by default. That makes Athena or SIEM queries more efficient.
Use event selectors deliberately. Management events are foundational. Data events can be high volume and should be enabled for important resources where the investigation value justifies cost.
For large organizations, central log analytics may use Athena, Glue Data Catalog, OpenSearch, Security Lake, or a SIEM integration.
Do not send every possible event to expensive analysis pipelines without filtering and retention planning.
9. Cost Controls
CloudTrail management events have a different cost profile from data events. Data events can grow quickly for busy S3 buckets or Lambda functions.
S3 storage cost depends on retention and storage class. Use lifecycle transitions for older logs when retrieval requirements allow it.
KMS request costs can matter at high volume if using customer-managed keys.
Athena and SIEM query costs depend on scanned data. Partitioning, compression, and selective queries help.
The cheapest logging setup is not always acceptable. Logs are only useful if they exist, are protected, and can be found during an incident.
10. Exam Variants
"Centralize CloudTrail logs across AWS accounts" points to an organization trail and central S3 bucket.
"New accounts should automatically be logged" points to AWS Organizations organization trail.
"Prevent member accounts from deleting logs" points to a separate log archive account, restrictive S3 permissions, versioning, and possibly Object Lock.
"Verify logs were not changed" points to CloudTrail log file validation.
"Encrypt CloudTrail logs with a customer-managed key" points to KMS key policy permissions for CloudTrail and readers.
"Log S3 object-level API activity" points to CloudTrail data events, not only management events.
11. Common Traps
Do not store each account's audit logs only inside that same account.
Do not assume CloudTrail logs every data event by default.
Do not forget the S3 bucket policy required for CloudTrail delivery.
Do not break delivery with an overly restrictive KMS key policy.
Do not give workload administrators delete access to central logs.
Do not confuse CloudTrail with CloudWatch metrics. CloudTrail records AWS API activity.
12. Related Topics
Review AWS Account Model, Identity Policies vs Resource Policies, Amazon S3, and IAM Foundations.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.