AWS multi-account automation utopia

Earlier this year, an excellent whitepaper was published about organizing your AWS environment using multiple accounts. To ease adoption of a multi-account environment, I've been working on automating the recommendations based on work I described in an earlier post titled Why not Terraform. I wrote another post about an AWS Serverless Application Model (SAM) project to automate new account creation activities with AWS Control Tower. I've been refining the project in hopes of submitting it as an official AWS Quick Starts to codify AWS' official recommendations and best practices. I organized the project into two components:

1. One-time organizational set up
2. New account creation via Control Tower

sam-organization-setup

This projects deploys a single Lambda function and is invoked as a CloudFormation custom resource. The project needs to be deployed into the AWS Organizations management account because it sets up delegated administrators for a variety of services.

The project can be deployed either before or after Control Tower has been set up, as long as an organization in AWS Organizations is available.

The Lambda function does the following one-time setup activities:

• AWS Organizations - enables all policy types
• AWS Organizations - enables AWS service access
• AWS Service Catalog - enables AWS Organizations access
• AWS Resource Access Manager - enables organizational sharing
• AWS Identity & Access Management - creates an organizational IAM access analyzer in the Control Tower "Audit" account
• AWS Firewall Manager - delegates administration to the Control Tower "Audit" account
• Amazon GuardDuty - in each region, delegates administration to the Control Tower "Audit" account and enables organizational access
• AWS SecurityHub - in each region, delegates administration to the Control Tower "Audit" account and enables organizational access
• Amazon Macie - in each region, delegates administration to the Control Tower "Audit" account and enables organizational access
• AWS Audit Manager - in each region, delegates administration to the Control Tower "Audit" account

I want to continue enhancing the Lambda function to support:

• Region enforcement via a service control policy
• Denying specific services via a service control policy

sam-account-setup

This project watches for the AWS Control Tower CreateManagedAccount event on Amazon EventBridge and orchestrates a variety of activities on the newly created account using a AWS Step Functions state machine.

There are individual Lambda functions that perform these activities:

• Deletes the default VPC created in every region. In all of the companies I've worked at, we wanted control over the creation of VPCs in an account and didn't want to allow users to provision public EC2 instances by default. By deleting the default VPC in every region, we can introduce another mechanism for provisioning VPCs (like AWS Service Catalog) and close that security gap.
• Enables all of the ECS account level settings for ARN and ID formats
• Creates an Amazon CloudWatch resource policy that grants Amazon Route53 permission to log query logs in us-east-1 (must be us-east-1)
• Configures the account-level S3 public access block to prevent public buckets
• Accepts shared AWS Service Catalog portfolios and associates the proper AWS SSO IAM principals to the portfolios (using the "AWSReservedSSO_*" IAM roles in the account)
• At my last company, we adopted a naming convention for our AWS SSO groups that allowed us to automate the assignment of the AWS SSO permission sets in the management account when new groups were created. For example, if a group was called "AWS-A-AccountA-AWSReadOnlyAccess" ("-A-" for account), that group was for an AWS account named "AccountA" and an AWS SSO permission set named "AWSReadOnlyAccess". We also had a set of AWS SSO groups that we wanted to have access to every AWS account, so we named those groups "AWS-O-AWSAdministratorAccess" ("-O-" for organizational). By following the naming convention, when a new account is created, we can automatically associate all of the "AWS-O-*" groups to the new account and associate any "AWS-A-AccountA-*" groups to the new account.

Conclusion

I see a lot of customers using Terraform to manage their multi-account environments, and there's nothing wrong with that approach, but I would strongly encourage customers to evaluate AWS Control Tower and the guardrail capabilities that it provides out of the box. It will save a lot of time from having to replicate the guardrails using Terraform and they wouldn't be able to take advantage of any future enhancements being released in AWS Control Tower.

AWS Control Tower's integrations into other services such as Amazon EventBridge, give you almost unlimited customization and automation opportunities to secure your environment.

#aws #awscontroltower #serverless #sam

Related

• Customizations for AWS Control Tower (AWS Solutions Implementation)
• Customizing account configuration with AWS Control Tower lifecycle events (AWS Management & Governance Blog)
• Self-service VPCs in AWS Control Tower using AWS Service Catalog (AWS Management & Governance Blog)