AWS Multi-Account Architecture

For small organizations or small dev/test having a single AWS account will most likely do just fine. But for production workloads you’ll need to consider AWS multi-account architecture. There are many reasons you’ll need to use AWS multi-account architecture (listed below), so it’s best to start right. Before you get started take a minute to read this https://cloudly.engineer/2019/wait-dont-create-your-aws-account-yet/aws/. You’ll have to think about the size of your team (people), timeline, budgets and team experience. Each account will be purposely created for specific role. One account would just be the payer account, which is your management account. This AWS account will host your AWS organizations services, too. Do enable the standard IAM account settings, enable CloudTrail logs and other basic security services. Do not run any other services on this account!

Why Multiple AWS accounts?

• Cost separation for budgets and reporting purpose
  • Can easily consolidate billing!
• Bypass AWS services hard quota limitations
• Security separation
• Error tolerance or blast radius problems
• Governance and compliance purposes
• Different teams and contracts
• Code pipeline and much more.

Account Permissions

AWS’s organizations come with another key component besides the consolidated payment. The Service Control Policies (SCPs). SCP’s are just service only permissions for accounts. It’s not user permissions. You can block or explicitly enable services from the management account to its child or to any child account directly. Or even block certain regions or certain EC2 (Elastic Cloud Compute) instances types. Everyone should block those high performance compute (HPC) instances if you don’t plan on using them ever! Otherwise an accidental use of HPC instances can cost you thousands in just few hours.

AWS Multi-Account architectures

Starter Pack

This is a fast and scalable option. Create your management account then utilize AWS Control Tower to create your other accounts.

Well-Architected Structure

The Workspace OU is for accounts that will provision Amazon Workspaces, virtual desktops. The infrastructure OU is for the core or shared resources, such as network, MS active directory account, image builder, pipelines, etc. The sandbox OU is for AWS accounts to do testing and learning of various AWS services and features.

Organizational Units

AWS Organization Units or OU’s are not the same as Microsoft Active Directory OU’s. OU’s here are a way of grouping AWS accounts to manage account permissions (SCPs) in a manageable and scalable manner.

Benefits of OU’s:

• Share SCPs
• Common functionality
• Share resources across multiple accounts within an OU

Management Account

AWS Control Tower is the easiest way to manage your OU’s, accounts, AWS Single Sign On, apply guardrails (SCPs and AWS Config Rules), and manage your landing zone.

The management account will host all your billing information. The breakdown of costs per account and much more. Do set your billing alerts here! As of the time of this writing I wouldn’t recommend using the Amazon CloudWatch billing alert. I recommend using AWS budgets feature only! Why? Because the billing metrics value is different than the AWS budgets. The AWS budgets is the total cost while the CloudWatch metric is only the AWS services; it’s missing any AWS Marketplace charges.

Subscribe! I’ll be posting how to create accounts with the AWS CLI and managing all accounts with Terraform! Here’s how to provision an AWS account with Terraform.

As always if you see any errors, mistakes, have suggestions or questions please comment below. Don’t forget to like, share, and subscribe for more! 🙂