AWS Multi-Account Management that Doesn’t Suck: Account Onboarding

Congratulations, you’ve decided to break your big old legacy AWS account into multiple accounts. You know the benefits and are about to create a new management account with AWS Control Tower. You are happy, the CISO is happy, and the business is happy. Such an exciting journey ahead!

Fast-forward a year, and you find yourself in a nightmare, trying to manage tens (sometimes hundreds) of accounts and facing new challenges:

• AWS Account onboarding
• IAM management
• Network management
• Security controls
• Monitoring and visibility (security/operational/cost)

In this series of posts, I’d like to share with you how at Next Insurance, we leverage AWS Organizations and other native capabilities to overcome those challenges, what decisions we made, what challenges we had, and some lessons that we’ve learned along the way.

A lovely picture to relax with; help is on the way!

From Account to Organizational Unit (OU)

The most important decision we’ve made at Next Insurance was to define the Organizational Unit(OU) as the smallest component of our organization. We do not want to manage our security and governing policies on a per-account basis, and we don’t want to get attached to our AWS accounts. In fact, we’re naming our accounts with incremental numbers (bi-dev-02, data-prod-03, etc.), and we usually delete them within a year or less (Why? Because this is how we do our DR drills. More about that in one of the following posts, stay tuned).

Each OU represents an account type (profile), and all the accounts inside that OU share the same baseline (same owners, security controls, roles, tags, network requirements, DR requirements, cross OU permissions, etc.).

We’ve decided to use a 2-tiers structure* (for more alternatives and other design patterns, please refer to AWS docs) to determine the account profile:

1. The first tier is based on the workload type (prod/dev/infra etc.), and it covers most of our security/network/backups/permissions requirements.
2. The second tier is based on the business units, and it allows us to fine-tune our tags strategy, cost controls, and cross OU permissions.

* To avoid complicated policies, each OU can host either accounts or OUs but never both.

Account Onboarding

Account onboarding is one of the biggest challenges you’ll face when working with multiple accounts. For many companies, it is a manual (or semi-manual) process that takes time and requires decision making and triggering one or more automation flows.

The typical account onboarding process involves the following steps:

1. Create a new email address for the account (usually takes time — need to open an IT ticket).
2. Create the account (enter email, account name, and destination OU).
3. Enable AWS support.
4. Create IAM roles for users, 3rd-party vendors, and other automation roles.
5. Enable security tools.
6. Create a backup policy based on the workload type.
7. Deploy network and other infra-related resources (e.g., Route53 private domain)
8. Configure budget alerts and tools.

Luckily for us, there are four “tools” that we can use to automate the entire process end-to-end:

1. Naming Convention

The only thing that matters for us when creating a new account is the type. No other information is required.

The account name is generated based on the OU name + incremental number, and the email address is the same for all the OU accounts (using an email alias).

For example, assuming we want to create a new production account for the data team, we’ll use the following inputs:

ou_name: data-production  #The account profile
account_name: data-production-02  #(n+1)
email_address: amazon-data-production+02@example.com

2. CloudFormation StackSets

CloudFormation may not be your primary IaC tool (our primary IaC tool is Terraform), but you should use it for account onboarding! CloudFormation is integrated with AWS Organizations and will trigger an automatic deployment on new accounts the second they are created.

You can deploy a stack across all accounts in the organization or only on specific OUs (based on the account profile) in a single region or multiple regions. The two main advantages of CloudFormation StackSets are:

1. You deploy it once, and from that point, all the existing and future accounts will get the baseline resources automatically.
2. You can update/modify the stack, and AWS StackSets will update all relevant accounts accordingly in minutes(no multiple Terraform apply or Jenkins jobs to run).

At Next Insurance, we use StackSets to provision all of our 3rd-party roles, automation roles, and other baseline resources.

3. AWS Organizations Integrations

The AWS Organizations service team frequently releases new integrations (you can follow this RSS feed to track new releases); use them! It will save you hours of automation development and maintenance.

Are you working with AWS security tools like Config, Macie, GuardDuty, SecurityHub, Access Analyzer, and others? Great! Enable the integration once, and that’s it — it’s running on all accounts (existing and future), and now you can manage and monitor everything from a single pane of glass.

Are you working with AWS Backup? (if not, you should) — great! You can configure and manage backups for your entire organization or specific OUs from a single place.

With Firewall manager, you can manage/enforce and monitor your Security Groups, WAF, and Network firewall policies across all accounts.

The point is clear — you need a very good reason to manage those services using Terraform or any other automation.

4. Event-Driven Automation

Sometimes you need to automate a process that you can’t do with StackSets or any other service integration — for example, calling an external API with the specific account ID or running custom scripts from the new account.

For us, we needed to develop event-driven automation to register new accounts to the AWS Enterprise support plan and for the creation of some unique SSM parameters in each AWS account.

For such use-cases, you can build event-driven automation as described in the following diagram:

• [1] AWS EventBridge allows you to trigger workflows based on events in your AWS Organizations (AWS Account/OU creation/deletion)

an event pattern to catch new account creation when using ControlTower

• [2] Consider AWS StepFunction for more advanced automation flows.
• [3] Suppose you need to run API calls from the newly created account. You can assume the built-in role OrganizationAccountAccessRole ( or AWSControlTowerExecution when using ControlTower) to gain admin access to that AWS account.

Conclusion

In this post, the first of a series of posts, we show how to easily automate an AWS account creation/onboarding using AWS Organizations and native tools and why you should change your focus from account management to account profile management.

In the following posts, I’ll share more tips about SCPs and security controls, cross OU permissions, and advanced networking.