Taming the Noise: A Practical Guide to Selective AWS CloudTrail Logging

In a multi-account AWS environment, centralized logging is a cornerstone of security and governance. Enabling CloudTrail at the Organization level to send logs to a central S3 bucket is a standard best practice. However, this approach can create a new problem: an overwhelming flood of data from non-production accounts, leading to increased costs and alert fatigue for your security team.

Our team faced this exact issue. With an AWS environment managed by Landing Zone Accelerator, both our production and test account logs were funneled into a single S3 bucket for our SIEM tool. This inflated our Events Per Second (EPS), spiked costs, and generated a stream of low-priority incidents from test accounts, distracting our security team from what truly mattered. The challenge was that the organization-level trail offered no simple option to exclude specific accounts or Organizational Units (OUs).

Evaluating the Solutions

We considered three potential paths to regain control over our logging strategy:

• AWS Control Tower: A powerful solution for setting up and governing a secure, multi-account AWS environment. However, implementing it solely for this logging issue would have been overly complex for our immediate needs.

• AWS Config Conformance Packs: These allow you to package and deploy compliance rules across your organization. While useful for enforcing standards, it felt like an indirect way to solve a direct configuration problem.

• AWS CloudFormation StackSets: This service lets you create, update, or delete CloudFormation stacks across multiple accounts and regions with a single operation. This appeared to be the most direct, flexible, and scalable solution for our specific goal.

  Our Solution: Using CloudFormation StackSets

  We chose CloudFormation StackSets for its ability to target deployments with precision. By managing the process from our AWS Organizations management account, we could apply a specific CloudTrail configuration exclusively to the accounts that needed it.

  The strategy involved disabling the broad, organization-level trail and then deploying a new, more targeted trail only to our production accounts.

  Implementation Steps

  1. Create a CloudFormation Template: We first authored a simple CloudFormation template. This template defined a new CloudTrail trail configured to send logs to our central security S3 bucket.

  2. Create the StackSet: In the management account, we initiated the creation of a CloudFormation StackSet. We provided a name for the StackSet and pointed it to the template we had just created.

  3. Define Deployment Targets: This was the critical step. During the StackSet setup, we specified the deployment target. Instead of applying it to the entire organization, we selected only our Production OU. We also specified the AWS regions where this configuration should be active.

  4. Deploy and Verify: With a single action, the StackSet deployed the CloudFormation stack to every account within the Production OU. This automatically created the desired CloudTrail configuration in all our production accounts, while leaving the test accounts untouched.

     The Results

     This targeted approach immediately resolved our challenges and delivered significant benefits:

     • The noise was eliminated. Our SIEM now only ingests logs from critical production environments.

     • SIEM-related costs and EPS usage dropped noticeably.

     • Our security team can now focus on meaningful alerts, improving our overall security posture.

     • We now have a scalable and repeatable pattern for deploying granular configurations across our AWS Organization.

     By leveraging CloudFormation StackSets, we were able to implement a more intelligent logging strategy that aligns with our security needs without creating unnecessary operational overhead. It is a powerful tool for any team looking to apply fine-grained control across a multi-account AWS environment.