AWS Cloud Operations Blog

Integrating existing AWS CloudTrail configurations when launching AWS Control Tower

The customers that we work with often use multiple AWS accounts to meet their business needs. These multi-account environments are built based on the guidelines that AWS published. Customers have created custom mechanisms using AWS Organizations, AWS CloudTrail, and other AWS services to implement the guidelines. AWS Created the AWS Control Tower service as a mechanism to standardize the implementation and configuration of AWS services that support multi-account environment. AWS Control Tower was purpose built to provide the easiest way to set up and govern a multi-account AWS environment. Customers, who are adopting AWS Control Tower to minimize the overhead of maintaining the custom mechanisms, asked us for guidance on how to launch AWS Control Tower in their existing organizations that have CloudTrail configured.

In this post, we’ll talk about the most common CloudTrail deployment scenarios that we see with our customers. Furthermore, we’ll learn how to effectively handle the AWS Control Tower enrollments with minimal impact.

When deploying AWS Control Tower in the existing organizations, one common scenario that arises is related to centralized logging. AWS Control Tower centralizes logging from CloudTrail, and AWS Config stored in Amazon Simple Storage Service (Amazon S3). This is critical for auditing, security, and compliance reasons for many customers. Although there are few other prerequisites to verify, we’ll focus primarily on CloudTrail in this post. Refer to Plan your AWS Control Tower landing zone for additional details regarding the prerequisites.

Customers who operate on multi-account AWS environments most commonly have CloudTrail enabled using organization trail, or they have multi-Region trails enabled across all of their accounts using AWS CloudFormation StackSets or their own automation pipelines. CloudTrail publishes events to Amazon EventBridge when you make API calls. You can route this event to a target, such as AWS Lambda, AWS Step Functions, and many others. For customers with these workflows, must have at least one active CloudTrail trail or CloudTrail Lake event data store at all times.

When you launch AWS Control Tower, it creates a multi-Region CloudTrail on all the accounts managed by AWS Control Tower. If you already have an active trail in your account, then the trails created by AWS Control Tower are duplicate trails and will result in additional costs. The additional costs will vary depending on your cloud usage and increase with your cloud activity.

This post is for customers looking to enable AWS Control Tower governance in their existing multi-account environments. You’ll learn how to efficiently enable AWS Control Tower in environments with existing CloudTrail trails. In addition, you will learn how to achieve this without interrupting your existing event-based workflows in a cost-efficient way.

Prerequisites

  1. A few concepts, such as organization trails and landing zone referred to in this post, assume you have AWS Organization enabled with all of its features.
  2. This solution is to be deployed only in your organizations management account.
  3. You need permissions to enable AWS Control Tower on your AWS account.
  4. Identify (or create) an S3 bucket to collect CloudTrail logs.
  5. Identity (or create) an AWS Key Management Service (AWS KMS) key if you need to encrypt your CloudTrail logs.
  6. You must enable organizations access to operate a service-managed stack set.

Overview

AWS Control Tower offers a simple way to set up and govern an AWS multi-account environment following prescriptive best practices. AWS Control Tower automatically creates CloudTrail trails when you enroll an AWS account using Account Factory.

If you’re already using organization trails and want to install AWS Control Tower, you must disable the trusted access for CloudTrail to pass the AWS Control Tower pre-install checks. When you disable the trusted access, all the organization trails in your accounts will become non-functional. When you enable AWS Control Tower in your existing organization, the management, audit, and log archive accounts are only enrolled by default. All the remaining accounts must be enrolled separately. Once you enroll an account, AWS Control Tower configures a multi-Region trail in the account and captures all the events centrally in the S3 bucket located in the log archive account.

It’s important to have at least one active trail in the accounts to avoid any interruptions to event-based workflows powered by Amazon EventBridge. Therefore, you could set up a temporary multi-Region trail across all the accounts before you disable trusted access for CloudTrail. If you skip this step, then you’ll lose the audit log collection, and any event-based workflows could be interrupted between the period when you disable the trusted access and launch AWS Control Tower.

The following high-level steps make up this post:

  1. Prepare your environment
  2. Setup temporary multi-Region trails
  3. Disable organization trails
  4. Install AWS Control Tower
  5. Enroll existing accounts and delete duplicate trails

High-level steps

Integrate existing AWS CloudTrail configurations - Decision Tree

Figure-1. Integrate existing AWS CloudTrail configurations – Decision Tree

When you have multiple trails on an account, you incur costs for the additional copies of the events delivered. The steps mentioned in this post will create temporary trails in your AWS. These will result in increased costs during the transition time. The cost varies depending on the amount of activity in your accounts. Refer to the CloudTrail pricing page for details.

To help manage costs, and avoid missing any audit log collection or impact event-based workflows, consider keeping both trails active for at least a couple of hours after you complete the transition/process.

Solution Architecture

The CloudFormation template provided as part of this post uses service-managed CloudFormation StackSets to create cross-account AWS Identity and Access Management (IAM) roles with assume-role access from the Management Account. These cross-account roles are used to launch the second CloudFormation StackSet across all the existing accounts. A custom resource is used to get the list of AWS accounts and add stack instances on all the accounts. The stack creates a multi-Region CloudTrail and collects the logs in the S3 bucket destination that you provided. In addition, it logs the CloudTrail events in Amazon CloudWatch Logs.

Solution Architecture Overview

Figure-2: Solution Architecture Overview

Walkthrough

Step 1: Prepare your environment

Step 1a- Identify an S3 bucket and update the bucket policy to collect temporary trails

You may reuse your existing S3 bucket or create a new bucket to host audit logs collected by the temporary CloudTrail trails that you’ll create in the next steps. In this step, you’ll update the bucket policy to let CloudTrail service write the CloudTrail trail events into this bucket. Optionally, you can configure CloudTrail logs to be delivered to a specific prefix on your S3 bucket.

  • Navigate to the Amazon S3 console
  • Choose the S3 bucket and the Permissions tab to edit the bucket policy
  • If you’ve created a new S3 bucket, then apply the policy provided in the following.
  • For S3 buckets with existing policies, append the Sid elements from the following policy.

Replace the strings <your-bucket-name> and <prefix> with your S3 bucket name and prefix. Refer to the Amazon S3 bucket policy for CloudTrail.

{
"Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSCloudTrailAclCheck",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::<your-bucket-name>"
        },
        {
            "Sid": "AWSCloudTrailWriteTemp",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<your-bucket-name>/<prefix>/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        }
    ]
}

Step 1b: [Optional] Identify a KMS Key and update the key policy

Navigate to this document, and scroll down to Optionally configure AWS KMS keys to grant access to the key policy.

Step 2: Setup temporary multi-Region trails in all of your accounts

Deploy a CloudFormation Stack to simplify the creation of temporary tails across all of your accounts.

Download this template.

  • Navigate to the Stacks option in the AWS CloudFormation console in your management account.
  • Choose Create Stack with new resources.
  • Under Specify template, choose Upload a template file, and Choose file.
  • Browse and select the CloudFormation template that you downloaded in the previous step.
  • Choose Next.
  • Provide the following parameter values when prompted:
    • ControlTowerHomeRegion: AWS Region where you’re planning to deploy AWS Control Tower.
    • OrganizationRootID: Navigate to Organizations, and note the ID for Root (r-abcd).
    • AuditBucketName: S3 bucket that you identified in Step 1.
    • AWSLogsS3KeyPrefix: Navigate to Organizations, and note the Organization ID (o-xxxxyyyyzz).
    • ManagedResourcePrefix: Change as needed. You can leave the default value for this post.
    • KMSKeyArn: Type in the KMS key ARN if the S3 bucket is encrypted.
    • You can leave the remaining values as defaults and choose Next.
  • Review all of your selections and select the check box for I acknowledge that AWS CloudFormation might create IAM resources with custom names.
  • Choose Submit.
  • Wait for the Stack operation status to change to SUCCEEDED.

Confirm that the temporary trails are created in all of your accounts and that events are getting delivered to the configured S3 bucket and prefix.

[Optional] Migrate existing log processing workflows

We commonly see customers configuring additional workflows, such as routing the audit log to security information and event management (SIEM) tools using Amazon S3 events. If you have configurations like that, then don’t forget to configure those events on the new Amazon S3 CloudTrail target as well. Note the duplicate events that your SIEM systems will receive from both of the temporary trail organization trails during this period.

Step 3: Delete the Organization trails and disable CloudTrail trust access

As the temporary trail is now configured to collect the audit events, you can turn off the organization level trails and disable the trusted access. This is required before we can enable AWS Control Tower in your organization.

Step 3a: Turn off the organization trails on your management account

  • Navigate to the Trails option in the CloudTrail console.
  • Identify the trails with Organization trail: Yes and Status: Logging.
  • Select the trail, and choose Stop logging. Repeat this for all of the organizational trails.
  • [Optional] Choose Delete to delete the trail permanently. This is required if you have a total of five trails in your account, including both active and inactive trails.

Step 3b: Disable trusted access for CloudTrail in your AWS Organization

  • Navigate to the Services option in the Organizations console.
  • Choose CloudTrail.
  • In the CloudTrail page, choose Disable trusted access.
  • For Disable trusted access for CloudTrail? Pop-up, type-in disable, and choose Disable trusted access.

Step 4: Enable AWS Control Tower

Follow the instructions in the Enable AWS Control Tower document to launch AWS Control Tower in your account.

AWS Control Tower creates two new accounts in your organization: an audit account and a logging account. The log archive account works as a repository for logs of API activities and resource configurations from all of the accounts in the landing zone. When AWS Control Tower is first enabled, it defaults by managing three accounts: the management account, log archive account, and the audit account enrolled. Your existing accounts will remain unchanged, and they aren’t managed by AWS Control Tower. You must enroll your other accounts to be managed by AWS Control Tower.

[Optional] Migrate existing log processing workflows

If you have any SIEM configurations, then don’t forget to configure those events on the newly created S3 bucket in the AWS Control Tower log archive account. As you enroll new accounts into AWS Control Tower, this bucket will be the centralized collection point for all of the accounts.

Step 5: Enroll accounts into AWS Control Tower and delete the temporary trail

When you have multiple trails on an account, you incur costs for any additional copies of events delivered. To avoid those additional usages for your trails, you should plan to delete trails that are capturing duplicate events. AWS Control Tower automatically creates and maintains a CloudTrail trail in each account that is enrolled.

The management account is already enrolled by default as part of your AWS Control Tower creation. You should start with these accounts and delete the temporary trails that we created in Step 3, as well as any other trail that is duplicating the CloudTrail trail. Repeat these steps for each of the accounts as you enroll new accounts into your Control Tower.

  • Navigate to the StackSets option in the CloudFormation console in your management account.
  • Choose “TemporaryCloudTrailStackSet” StackSet from the list of StackSets.
  • Select the Actions, and choose Delete Stacks from StackSet.
  • Select Deploy stacks in accounts.
  • Enter the account number that was successfully enrolled, and select the Region.
  • Leave the deployment options to default, and select Next.
  • After confirming the inputs, select Submit.
  • Confirm deletion.

As you enroll each of your accounts into AWS Control Tower, consider leaving both of the trails on the account on for a couple of hours. This will help you avoid missing any events in the audit log before you delete the temporary trail.

Congratulations, you have successfully enabled AWS Control Tower in your account.

Cleanup

Navigate to the stacks option in the CloudFormation console, select the stack that you deployed in Step 3, and delete. Successful stack deletion will remove all of the resources that were deployed in this post. Note the CloudTrail events delivered to the temporary S3 buckets and CloudWatch Logs groups won’t be removed.

Conclusion

In this post, we’ve demonstrated a way to continually receive audit events into a central location for customers using Organization level trail and wanting to enable multi-account governance using AWS Control Tower. Using the centralized CloudTrail provided by AWS Control Tower and removing account-level trails capturing duplicate events can significantly reduce CloudTrail usage costs.

Thanks for reading this post. If you have any feedback or questions, add them in the comments section.

Authors

Kishore VinjamSrinivas Paranthanate is a solutions architect at AWS. He is passionate about simplifying the cloud journey for AWS customers. His areas of interest include builder experience, big data, and serverless technologies.
Shruti BilgundiShruti Bilgundi is a Software Engineer with AWS Control Tower. Her passion is improving the customer experience and helping customers scale their AWS environments. She has been a part of AWS Control Tower from inception and worked on several core features. In her spare time, she enjoys painting and reading books.
Kishore VinjamKishore Vinjam is a partner solutions architect focusing on AWS Service Catalog, AWS Control Tower, and AWS Marketplace. He is passionate about working in cloud technologies, working with customers, and building solutions for them. When not working, he likes to spend time with his family, hike, and play volleyball and ping-pong