AWS CloudTrail Organization Trail: Multi-Account Logging Architecture and SIEM Integration
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
AWS multi-account architectures are the standard deployment model for organizations operating AWS at scale — separate accounts for production, development, staging, shared services, and log archive provide blast radius reduction, cost allocation, and access isolation. But multi-account architectures also fragment security monitoring: without an organization trail, each account generates CloudTrail logs independently, and correlating a lateral movement incident that crosses account boundaries requires manually gathering and correlating logs from multiple accounts, often under time pressure during active incident response.
The organization trail is the architectural solution: created once in the management account, it automatically covers all accounts in the organization, including accounts created after the trail is configured. The architectural decisions around S3 bucket security, SIEM streaming method, and data event selection determine the effectiveness and cost of the resulting log infrastructure.
Architecture design: where to store logs and how to protect them
The log storage architecture determines the cost, security, and queryability of CloudTrail data across your organization. Three decisions define this architecture: which AWS account holds the log bucket, what tamper-resistance controls protect the stored logs, and whether to enable CloudWatch Logs integration alongside the S3 delivery path for real-time SIEM streaming. Getting these decisions right at setup prevents the costly retrofit of migrating log storage or enabling CloudWatch Logs retroactively when an incident response team discovers the current setup cannot support cross-account queries or sub-minute detection latency.
Use a dedicated log-archive account for CloudTrail log storage
Store CloudTrail organization trail logs in an S3 bucket in a dedicated log-archive AWS account, separate from the management account and all workload accounts. Rationale: a compromised workload account cannot access or delete logs in a separate account with correctly configured bucket policies and SCPs. The log-archive account should have minimal services deployed, limited console access (break-glass only), and an SCP denying s3:DeleteBucket and s3:DeleteObject on the log-archive bucket from all member accounts. Enable S3 Object Lock with a compliance mode retention period matching your longest compliance requirement (HIPAA: 6 years, PCI DSS: 12 months). Compliance mode Object Lock cannot be overridden even by the bucket owner during the retention period — this is the strongest available protection against log deletion by a compromised AWS administrator.
Enable CloudWatch Logs integration for real-time SIEM streaming
CloudTrail's direct S3 delivery has 5-minute delivery latency (CloudTrail aggregates and delivers log files every 5 minutes). For real-time detection (alerts on suspicious API calls within seconds of occurrence), enable CloudTrail's CloudWatch Logs integration: each API event is delivered to CloudWatch Logs within seconds of being recorded. From CloudWatch Logs, use a subscription filter and Kinesis Data Firehose to stream events to your SIEM in near real-time. The S3 delivery path remains for compliance retention. The CloudWatch Logs path serves real-time detection. Both are generated from the same organization trail at the additional cost of CloudWatch Logs ingestion and storage for the log group.
Incident response: using the organization trail for cross-account investigations
The organization trail's primary investigation value is cross-account visibility — correlating actions that span accounts is only possible with centralized logs. Cross-account role assumption is the principal lateral movement vector in multi-account AWS environments, and the organization trail is the only source that captures both the AssumeRole call in the originating account and the subsequent API calls made under the assumed identity in the target account. The Athena query pattern below provides the starting point for building that correlation into your SIEM detection logic or incident response runbooks.
Cross-account AssumeRole correlation for lateral movement detection
Cross-account role assumption (AssumeRole where the calling account differs from the target account's account ID) is the primary lateral movement mechanism in multi-account AWS environments. An attacker who compromises an IAM identity in a development account may attempt to assume a role in the production account. The organization trail captures both the AssumeRole API call in the management account and the subsequent API calls in the target account under the assumed role identity. Athena query to find cross-account role assumptions: SELECT eventTime, userIdentity.arn, requestParameters.roleArn, sourceIPAddress, recipientAccountId FROM cloudtrail_logs WHERE eventName='AssumeRole' AND userIdentity.accountId != JSON_EXTRACT_SCALAR(requestParameters, '$.roleArn', 'accountId') ORDER BY eventTime DESC. Alert on cross-account role assumptions that occur from unexpected source accounts or outside of documented automation workflows.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
The AWS CloudTrail organization trail is the foundation of AWS security monitoring for multi-account environments. A single trail created in the management account covers all current and future accounts in the organization, eliminates the maintenance overhead of per-account trail management, and provides the centralized log source that makes cross-account security investigations possible. The architectural decisions that matter: store logs in a dedicated log-archive account with S3 Object Lock to prevent tampering, enable CloudWatch Logs integration for sub-minute SIEM streaming alongside S3 delivery for long-term retention, enable data events selectively for high-value resources, and build detection rules for the cross-account lateral movement patterns that the organization trail uniquely enables.
Frequently asked questions
How do I create an AWS CloudTrail organization trail from the management account?
Prerequisites: you must be signed into the AWS Organizations management account. The management account must have CloudTrail access enabled for the organization (this is on by default for organizations created after 2019; check with aws organizations describe-organization). Creating the trail in AWS Console: go to CloudTrail > Trails > Create trail. Trail name: organization-security-trail. Storage location: create a new S3 bucket with the correct bucket policy (see S3 bucket policy FAQ). Check 'Enable for all accounts in my organization' — this is the key setting that makes it an organization trail. Log file validation: enable (SHA-256 signing of log files for integrity verification). CloudWatch Logs: enable and configure a log group for real-time SIEM streaming. Click Next, select management events (Read and Write), configure data events selectively. Review and create. Using AWS CLI: aws cloudtrail create-trail --name organization-security-trail --s3-bucket-name your-cloudtrail-bucket --is-organization-trail --is-multi-region-trail --enable-log-file-validation --cloud-watch-logs-log-group-arn arn:aws:logs:REGION:MGMT_ACCOUNT:log-group:CloudTrail/OrganizationLogs --cloud-watch-logs-role-arn arn:aws:iam::MGMT_ACCOUNT:role/CloudTrail-CWLogs-Role. Then start the trail: aws cloudtrail start-logging --name organization-security-trail.
What S3 bucket policy does the CloudTrail organization trail log delivery require?
The S3 bucket for CloudTrail organization trail log delivery requires a bucket policy that allows the CloudTrail service principal to read the bucket ACL and write log files on behalf of all member accounts. Required bucket policy statements: (1) Allow CloudTrail to verify bucket ACL: Principal: {Service: cloudtrail.amazonaws.com}, Action: s3:GetBucketAcl, Resource: arn:aws:s3:::your-bucket. (2) Allow CloudTrail to write logs from all organization accounts: Principal: {Service: cloudtrail.amazonaws.com}, Action: s3:PutObject, Resource: arn:aws:s3:::your-bucket/AWSLogs/YOUR_ORG_ID/*, Condition: StringEquals: s3:x-amz-acl: bucket-owner-full-control AND StringEquals: aws:SourceArn: arn:aws:cloudtrail:REGION:MGMT_ACCOUNT_ID:trail/organization-security-trail. The bucket should be created in the security/log-archive account (not the management account) as a best practice — member accounts including compromised ones should not be able to delete or modify log files. Enable S3 Object Lock (WORM) with a retention period matching your compliance requirement to prevent log tampering.
How do I stream CloudTrail organization trail logs to a SIEM in real time?
Two streaming architectures: Architecture 1 (CloudWatch Logs subscription filter, low-latency): Enable CloudWatch Logs for the CloudTrail trail. In the destination account: create a Kinesis Data Firehose delivery stream pointed at your SIEM endpoint (Splunk HEC, Datadog, Elastic). Create a CloudWatch Logs subscription filter that sends log events matching your filter to the Kinesis stream. Latency: typically 2-5 minutes from API call to SIEM. Architecture 2 (S3 SQS notifications, simpler setup): configure the CloudTrail log bucket to send SQS notifications for new log file deliveries. Configure your SIEM's S3 input to poll the SQS queue, download new log files from S3, parse, and index. Latency: 5-15 minutes (CloudTrail typically delivers log files every 5 minutes). Most enterprise SIEMs (Splunk, Microsoft Sentinel, Elastic, Chronicle) have documented input configurations for both architectures. For Microsoft Sentinel: use the AWS S3 connector with the SQS notification method — it is the officially supported architecture for ingesting CloudTrail logs into Sentinel.
Which CloudTrail data events should I enable and which should I skip?
Enable data events for: (1) S3 object-level operations on buckets containing sensitive data: limit to specific bucket ARNs (not all S3 buckets) using the data resource selector. Focus on: production data buckets, backups, PII storage. (2) Lambda function invocations for production functions: useful for detecting unexpected Lambda execution patterns. (3) DynamoDB operations on production tables: table-level read/write events. Skip data events for: (1) All S3 buckets with organization-wide selection — high-traffic S3 buckets (static asset CDN buckets, log storage buckets) generate enormous event volumes at significant cost. (2) S3 management console sign-in events. (3) Development environment resources where the security value does not justify the cost. The data event selection UI in CloudTrail allows specifying resources by ARN or by filtering criteria. Use advanced event selectors (available via CLI: --advanced-event-selectors) for more granular control than the console UI provides. Calculate estimated cost before enabling: aws cloudtrail get-event-selectors returns the current configuration; estimate cost by checking current S3/Lambda request metrics in CloudWatch.
How do I query CloudTrail organization trail logs in S3 using Athena?
Athena allows SQL queries directly against CloudTrail log files in S3 without ingesting them into a separate system. Setup: (1) Create an Athena table over the CloudTrail S3 prefix: in CloudTrail console > Event history > Create Athena table. This auto-generates the CREATE TABLE DDL with the correct SerDe for CloudTrail JSON format and partitions by account, region, and date. (2) Alternatively, in CloudTrail Lake: query the CloudTrail Lake event store directly without S3/Athena setup. Key Athena queries: find all API calls by a specific IAM user: SELECT eventTime, eventName, sourceIPAddress, userIdentity.arn FROM cloudtrail_logs WHERE userIdentity.userName='compromised-user' AND eventTime > '2026-07-01' ORDER BY eventTime; Find all IAM role creation events: SELECT eventTime, requestParameters, userIdentity.arn, recipientAccountId FROM cloudtrail_logs WHERE eventName='CreateRole' AND eventTime > '2026-07-01'; Find all cross-account role assumption: SELECT eventTime, userIdentity.arn, requestParameters.roleArn FROM cloudtrail_logs WHERE eventName='AssumeRole' AND userIdentity.accountId != recipientAccountId ORDER BY eventTime; Partition projection (highly recommended): configure Athena partition projection on the CloudTrail table to avoid manual partition management and enable Athena to automatically limit data scanned to the queried time range.
What are the key CloudTrail detections to configure for AWS security monitoring?
Priority CloudTrail detections: (1) Root account usage: eventName=ConsoleLogin AND userIdentity.type=Root — root account usage outside of documented break-glass procedures is a high-severity alert. (2) IAM access key creation followed by API calls from a new IP: correlate CreateAccessKey events with subsequent calls using that access key from a geographically unexpected IP (S3 GetObject, EC2 RunInstances from an unfamiliar country). (3) CloudTrail logging disabled: eventName=StopLogging or DeleteTrail — attackers who compromise the management account may attempt to disable CloudTrail to cover their tracks. (4) Security Group rule allowing all inbound: eventName=AuthorizeSecurityGroupIngress AND requestParameters containing '0.0.0.0/0'. (5) S3 bucket made public: eventName=PutBucketAcl or PutBucketPolicy WHERE the new ACL or policy includes AllUsers or AuthenticatedUsers. (6) New IAM admin user creation: eventName=CreateUser followed by AttachUserPolicy where the policy is AdministratorAccess or a custom admin policy.
How do I protect CloudTrail logs from tampering or deletion by compromised accounts?
Log integrity and tampering protection: (1) Enable CloudTrail log file validation: log file validation generates a SHA-256 hash for each log file and records it in a digest file, allowing verification that log files have not been modified. Enable via the trail configuration: --enable-log-file-validation. Verify with: aws cloudtrail validate-logs --trail-arn arn:... --start-time 2026-07-01. (2) Store logs in a separate security/log-archive account: create the CloudTrail log S3 bucket in a dedicated log-archive account that member accounts (including potentially compromised member accounts) do not have Delete or modify access to. Use AWS Organizations Service Control Policies (SCPs) to deny s3:DeleteObject and s3:DeleteBucket on the log-archive account from member accounts. (3) Enable S3 Object Lock with governance mode: S3 Object Lock WORM (Write Once Read Many) with a retention period prevents deletion of log files during the retention period even by the bucket owner. (4) Enable Amazon EventBridge rule to alert on StopLogging and DeleteTrail API calls in real time.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.