Build an AWS Multi-Account Strategy According to Best Practices

In this blog post, we’ll delve deep into the topic of the AWS Multi-Account Strategy, guided by industry best practices. Whether you’re new to AWS or a seasoned cloud engineer, you’ll get valuable insights to improve the manageability, security, and efficiency of your AWS environments.

As AWS environments grow in complexity and scale, the need for a robust organizational framework becomes paramount. One key element of this is an intentional AWS Multi-Account Strategy. A well-structured approach ensures that resources are properly separated, permissions are clearly defined, and cost-tracking is streamlined. Moreover, as AWS continues to expand its service offerings, staying attuned to best practices becomes even more crucial.

We will cover:

1. What is an AWS Multi-Account Strategy?
2. Benefits of using a Multi-Account Strategy to evolve your AWS Environment
3. Tools and services to build a robust AWS Multi-Account setup
4. AWS Accounts structure and overall architecture scenario

An AWS Multi-Account strategy uses multiple AWS accounts to manage and operate workloads, resources, and users within an organization. If applied properly, this strategy can provide enhanced security, clear operational boundaries, and better cost management.

Why do you need an AWS Multi-Account Strategy?

A common scenario for many organizations is to start their AWS journey in a single AWS account for everything because it’s quick and easy to set up. You can think of an AWS account as a container for your cloud resources. You create and manage your AWS resources in an AWS account, and the AWS account provides administrative capabilities for access and billing. 

As your business grows, you start to think about how to set up the right permissions, resource limits, and cost allocations for different teams, different workloads, and different environments of the workloads. All these considerations become more complex as your environments grow, and managing them properly inside a single AWS Account becomes increasingly difficult. Here’s where a deliberate AWS Multi-Account comes into play. 

1. Resources Isolation

Primarily, an AWS Multi-Account strategy provides the highest level of separation of resources, ensuring that any disruptions or failures in one environment don’t cascade into another. This isolation fosters enhanced security, allowing for granular permission boundaries that drastically reduce the potential blast radius in the event of unwanted access or breaches.

Even more, it’s considered a best practice to use different accounts for different environments like development, staging, and production. This ensures that developers and cloud engineers can experiment and test without risk to production environments.

2. Simplified Cost-Tracking and Allocation

Moreover, segregating workloads into individual accounts paves the way for precise cost tracking and allocation, enabling organizations to pinpoint and manage expenditures effectively. AWS provides detailed billing information per account, making attributing costs to specific teams, projects, or clients easier.

3. Centralized Management and Governance

Coupled with AWS’s robust suite of management tools like AWS Organizations, this approach simplifies the oversight of numerous accounts, ensuring consistent policies and streamlined operations. 

4. Limits and Service Quotas Management

Lastly, AWS imposes various service-specific limits on each account for security purposes that help protect you from unexpected excessive provisioning of AWS resources and malicious actions that could dramatically impact your AWS costs. By using multiple accounts, organizations can effectively overcome these limits or expand them when necessary for specific accounts. 

A Multi-account strategy is indispensable for organizations targeting scalable, secure, and cost-effective AWS deployments and environments. To get started, check out the Organizing Your AWS Environment Using Multiple Accounts whitepaper.

AWS Account

An AWS account is the basic container for all the AWS resources you create as an AWS customer. An AWS account is also the foundational security boundary for your AWS resources. 

Account Structure

An account structure refers to the concept of compartmentalizing AWS resources, users, and operations into distinct accounts. This ensures clear separation and isolation of workloads. 

Every AWS account has its own set of AWS Identity and Access Management (IAM) entities. This separation means that a compromised entity in one account does not necessarily jeopardize another entity. Using separate accounts for distinct projects or departments makes it easier to associate costs directly. AWS provides detailed billing per account, and tools like AWS Cost Explorer can be used to analyze and attribute costs.

Organizational Units (OUs)

Within AWS Organizations, you can group individual accounts into OUs. OUs provide you with a logical way to group your accounts according to their function. Structuring your accounts in OUs allows for hierarchical, policy-based management, where different OUs can have different permissions and guardrails.

Environment Segregation

As a best practice, different environments, such as development, testing, staging, and production, should be created in separate AWS accounts to ensure isolation of resources, security, least-privileged access, stability, and reduced blast radius.

To develop and build an elaborate AWS Multi-Account setup, you can leverage two main tools; AWS Organizations and AWS Control Tower. 

AWS Organizations

An AWS service that lets you consolidate multiple AWS accounts into an organization you create and manage centrally. It forms the backbone of the multi-account strategy, facilitating policy-based management and consolidated billing. AWS Organizations is the foundational basis for a Well-Architected AWS multi-account setup. 

Organizational Units (OUs)

An organization is an entity that allows you to consolidate your AWS Accounts and group and organize them hierarchically into Organizational Units (OUs). Each organization has a management account at the top of the hierarchy and is responsible for managing many aspects of the organization and member accounts. This account should ideally not be used for workloads but only for management purposes. 

Member Accounts

Customer workloads are then deployed into member accounts. Member accounts are grouped into OUs to group and manage accounts that share common attributes. OUs allow us to apply standard policies, share tags, and manage common resources. 

Service Control Policies (SCPs)

Service Control Policies define the services and actions authorized for users and roles within the accounts. SCPs share similarities with IAM permission policies but differ in that SCPs do not grant permissions themselves. Instead, SCPs define the uppermost bounds of permissions for an organization, an OU, or an individual account.

Here’s an example structure of a basic organization: 

Check out Getting Started with AWS Organizations to get more details.

AWS Control Tower

This service provides an easy, quick, and prescriptive way to set up and govern a secure, compliant multi-account AWS environment. It automates the setup of a well-architected multi-account environment and incorporates best practices. 

Behind the scenes, it orchestrates several other AWS Services such as AWS Organizations, AWS Service Catalog, AWS IAM Identity Center, AWS Config, AWS CloudTrail (among others) to build your multi-account environment landing zone. Control Tower provides a consistent way to provision new AWS accounts and introduces rules and controls for more accessible governance. 

Landing Zone

A landing zone is a well-architected, multi-account basis for your AWS environments rooted in security and compliance best practices. It serves as the foundation across the entire organization, housing all OUs, accounts, users, and other resources that require compliance adherence. The scalability of a landing zone can effortlessly accommodate enterprises of varying sizes.

Controls (Guardrails)

A control, also known as a guardrail, is a broad governing principle that continually oversees your AWS environment at a top level. These principles are articulated in straightforward language and fall into three categories: preventive, detective, and proactive. Three guidance categories apply to controls: mandatory, strongly recommended, or elective.

Account Factory

An Account Factory serves as a customizable account blueprint that streamlines the creation of new accounts by incorporating pre-approved account settings. AWS Control Tower includes an integrated Account Factory, which automates setting up new accounts within your organization.

Control Tower Dashboard

The dashboard provides ongoing monitoring of your landing zone for your central cloud administrator team. Utilize the dashboard to view provisioned accounts throughout your enterprise, enabled controls for enforcing policies, controls for detecting policy violations continuously, and non-compliant resources categorized by accounts and OUs.

Default AWS Control Tower Structure

AWS Control Tower is provisioned with a default structure you can customize.

• Management Account

This is the dedicated account you established exclusively for your landing zone. It handles billing for all components within your landing zone, facilitates Account Factory account provisioning, and manages organizational units (OUs) and controls.

• Initial OUs and Accounts

Root: The top-level organizational unit encompassing all other OUs within your landing zone.

Security OU: Within this OU, you’ll find the `Log Archive` and `Audit accounts`, often called shared accounts. When setting up your landing zone, you can customize the names of these shared accounts.

Sandbox OU: The Sandbox OU is established during the landing zone launch and houses the accounts that are generally used for testing and experimentation.

• IAM Identity Center Directory

Control Tower integrates directly with IAM Identity Center. It keeps a directory that helps you securely create or connect your users and manage their access centrally across AWS accounts. 

To start building your landing zone, check out How to get started with Control Tower.

Let’s look into a scenario for building a Multi-Account setup from scratch and how to design its overall architecture. In this example, we will leverage the concepts we saw previously and combine them with various other AWS services and components to build a realistic production-ready AWS multi-account setup.

An imaginary company wants to move to AWS and needs to define its multi-account structure according to best practices. The design must satisfy the following requirements. After defining each requirement, we will define the derived objectives and actions that we need to take to satisfy them.

Requirement a : The Central IT team owns the overall setup and must be able to control the whole AWS landscape from a central place. They don’t have extensive AWS expertise in-house, and they would like to leverage managed services and prescribed guidance according to best practices to set up their accounts and AWS environment.

Objective a : Leverage Control Tower and set up a multi-account setup according to best practices and a top-level management account.

Requirement b : The company must have central visibility of overall costs, the costs of each Business Unit(BU), and typical infrastructure costs. They want to provide cost visibility for each BU and team regarding their respective cloud costs.

Objective b : Enable Cost Explorer for the Organization in the management account and set up CUR per account. 

Requirement c : Access to different accounts should be managed centrally by leveraging its existing self-managed Active Directory and using Multi-Factor Authentication (MFA).

Objective c : Deploy AWS IAM Identity Center/SSO Principles and integrate existing AD.

Requirement d : They want to be able to group similar accounts based on function, apply standard policies, and reshare common resources between accounts to avoid duplication. Regarding the different groups, they have identified Workloads, Security, Infrastructure, Suspended, Sandbox.

Objective d : Define an OUs structure.

Requirement e : Define different AWS accounts: They would need an account to store all their logs in one place, an account for security tooling, an account used for auditing purposes, an account dedicated to networking components, an account dedicated to shared infrastructure components, and one account dedicated to identity management components. They currently have two applications, A and B, and one team per application. Every application needs a sandbox account and three accounts per workload for dev/staging/production environments. 

 Objective e : Define accounts under OUs. 

OUs and Accounts Structure based on Requirements

Let’s continue with a few more requirements before we design the rest of the AWS architecture.

Requirement f : The administrators must be able to provision new accounts according to a predefined flow and pre-approved blueprints.

Objective f : Enable AWS Control Tower Account Factory and Customizations and combine with Service Catalog to create a blueprint.

Requirement g : The administrators must be able to enforce controls and rules for governance in terms of security, operations, and compliance and the correct granularity applied to a group of accounts or specific accounts.

Objective g : Enable Control Tower controls: Detective Controls with Config + Preventive with SCPs.

Requirement h : There should be a central place for aggregating all the logs for auditing and operational purposes. Logs created should be encrypted.

Objective h : Set up a Log Archive account that ingests logs from CloudTrail (+ CloudTrail data events) + VPC flow logs + DNS Logs, Cloudwatch Logs from apps. Leverage AWS KMS to encrypt them. 

Requirement i : The security team must have an isolated environment for their tooling Security tooling account and a process to set up security checks, centralize alerts, and assess cloud security posture management.

Objective i : Set up Security Hub, GuardDuty, Config, Detective, Inspector (Delegated Admin).

Requirement j : All the AWS resources and environments must be modeled and managed via Infrastructure as Code principles.

Objective j : Set up IaC with CloudFormation with StackSets.

Requirement k : The AWS environment should be connected to an on-premises network through a central hub that acts as a cloud router.

Objective k : Set up a dedicated Network Account and a Transit Gateway, connection to on-premises environment, hybrid networking, and DNS.

Considering all these requirements, here’s an overview architecture design of the solution:

In this blog post, we introduced the concept of an AWS Account and the benefits of leveraging a multi-account strategy for building a robust AWS setup. We explored the core concepts of an AWS multi-account structure and its two primary services: AWS Organizations and AWS Control Tower. Finally, we went over a complete scenario of designing a Multi-Account Landing zone setup for an imaginary company by creating the necessary OUs and accounts and combining different AWS services to build a production-ready solution.

Does your organization have extra compliance concerns? Here you can learn more about self-hosting Spacelift in AWS, to ensure your organization’s compliance, control ingress, egress, internal traffic, and certificates, and have the flexibility to run it within GovCloud. Book a demo today with one of our engineers to learn more about the platform, or open a free account here.

Thank you for reading, and I hope you enjoyed this as much as I did!