Introduction
Relying on a single AWS account for enterprise workloads creates a critical structural bottleneck that limits security and scalability.
At the beginning of your cloud journey, a single account is perfect: developers have agility, networks are simple, billing is straightforward. However, as your footprint grows, a single account is a recipe for disaster. You’ll hit API rate limits, the blast radius of a compromised IAM credential is enormous, and resource costs by department require a complex tagging strategy.
As a Cloud Architect, you’re likely already considering a multi-account architecture to mitigate these growing problems. However, beyond provisioning accounts comes the difficult task of governing them at scale.
By AWS Organizations, which when combined with AWS Control Tower, represent the standard in enterprise cloud architecture. Let’s explore how to design and secure a multi-account Landing Zone to balance developer agility and security compliance.
The Multi-Account Imperative
Before diving into the tools at our disposal, let’s define why multi-account architecture is a necessity.
- Blast Radius Reduction: If your production environment and your development account are logically separated (but share the same AWS account), a single mistake could bring down your entire application.
- Security & Identity Isolation: It’s much easier to grant a developer Admin access to an account (especially a sandbox account) than it is to define IAM boundaries for a shared account.
- Data Isolation: Having sensitive workloads (such as those bound by regulations like PCI-DSS or HIPAA) reside in their own account facilitates auditing and isolation.
- Financial Visibility: Consolidated billing in combination with per-account cost tracking is infinitely more insightful than resource tagging.
- Quota Management: AWS Service Quotas (e.g. the number of available VPCs or API rate limits) are defined on a per-account basis. Multiple accounts = multiple quota pools.
AWS Organizations: The Building Blocks
AWS Organizations is the foundational service that lets you organize your AWS accounts. It provides the underlying hierarchy that powers policy enforcement across your multi-account landscape.
Key Concepts:
- The Management Account: The root account (or account designated as management) that bills for all other accounts in the organization. You should never deploy workloads to the management account.
- Organizational Units (OUs): Logical grouping of accounts. The structure of OUs can be nested to represent your company’s security boundaries (not necessarily HR organizational charts).
- Service Control Policies (SCPs): This is the secret sauce of AWS Organizations. SCPs are JSON policies that form a boundary for what a given account can do. Unlike IAM policies, which grant permissions, SCPs define the maximum permissions allowed for an account or OU.
Example SCP: You could define an SCP applied to your Organization that prevents any account in the organization from launching EC2 instances in any region other than us-east-1 and eu-west-1.
Even if an IAM user in a sub-account has AdministratorAccess, the SCP will deny access to EC2 instances in ap-southeast-1.
AWS Control Tower: The Architect
If AWS Organizations is the building material, then AWS Control Tower is the architect. Control Tower is an abstraction layer built on top of Organizations, AWS Config, CloudTrail, and IAM Identity Center. It provides an automated “Landing Zone”, which is essentially a secure, pre-configured multi-account environment built on AWS best practices.
Why use Control Tower vs Organizations?
If you want to build a Landing Zone using Organizations, you’ll need to write custom Lambda functions to baseline new accounts, configure central CloudTrail logging, write dozens of SCPs from scratch, etc. Control Tower abstracts all of this complexity and provides an Account Factory, which we’ll discuss shortly.
Designing Your OU Architecture
A key element to designing a successful Control Tower implementation is understanding how to structure your OUs. One of the most common anti-patterns is to organize OUs based on your company’s structure (e.g. HR, Finance, etc.). While you could organize OUs based on security boundaries, it’s typically better to organize based on routing policies and operational life-cycle.
Here is an example topology using standard AWS OUs:
1. Security OU (Foundation)
This OU is created by default by Control Tower. It consists of:
- Log Archive Account: This is a logically separate AWS account that contains an S3 bucket that contains logs from all accounts in the organization. The bucket is immutable (no deletions permitted).
- Audit Account: This account is used by your security team to perform cross-account auditing. This is where centralized security services like Amazon GuardDuty, AWS Security Hub, and Amazon Macie are deployed.
2. Infrastructure OU (Foundation)
This OU is intended to contain accounts that provide shared services to other accounts.
- Network Account: This account contains the AWS Transit Gateway, Direct Connect, and any shared perimeter security (e.g. AWS Network Firewall, Cloudflare WAF endpoints).
- Shared Services Account: This account hosts centralized tooling such as GitLab runners, Active Directory, or a private Docker registry.
3. Workloads OU (Application Layer)
This is where your application accounts live. It is recommended to nest this further to separate Prod and Non-Prod accounts.
- Prod OU: This OU contains SCPs that are strict in nature. Developers should only have read access to resources, and deployments should be done through CI/CD pipelines.
- Non-Prod OU (Staging/Dev): These accounts can contain more lenient SCPs, allowing developers to debug and interact directly with resources.
4. Sandbox OU (Innovation Layer)
- Sandbox Accounts: Individual accounts are given out to developers for experimentation. These accounts are completely separate from the internal corporate network. These accounts, however, are subject to budget alerts and strict SCPs (e.g. no GPU instance types).
Guardrails: Enforcing Security at Scale
Control Tower defines security policies as “Controls” (previously known as Guardrails). There are three general behaviors for controls:
- Preventative Controls (backed by SCPs): These controls prevent users from performing certain actions.
- Example: Disallow internet access for Amazon VPC instances
- Example: Require Amazon EBS volumes to be encrypted at rest
- Detective Controls (backed by AWS Config Rules): These controls detect resources that violate organizational policies.
- Example: Detect if public read access to Amazon S3 buckets is allowed
- Proactive Controls (backed by AWS CloudFormation Hooks): These controls prevent resources from being created unless they adhere to organizational policies.
By attaching controls to different OUs, you can define a security posture per OU. The Prod OU may have preventative controls, whereas the Sandbox OU would have detective controls.
Infrastructure as Code: Account Factory for Terraform (AFT)
For modern SRE/DevOps teams, clicking through the AWS Console to vendor new accounts is an anti-pattern. Everything should be codified.
AWS provides Account Factory for Terraform (AFT), a deployment pipeline that ties together Control Tower with your Git repositories. Instead of opening an IT ticket to vendor a new account, developers can open a Pull Request modifying a Terraform repository. Once the pull request has been merged, AFT can take over and perform the following actions:
- Vend the new AWS account via Control Tower
- Move the new account into the appropriate OU
- Apply global customizations (e.g. IAM roles, baseline security groups, or Datadog agents)
- Apply account-specific customizations
With this GitOps approach, your account provisioning can be peer-reviewed and version-controlled.
Migration Strategy: Taming the Wild West
Adopting Control Tower in an empty environment is one thing. Retrofitting Control Tower into an established, disorganized AWS environment is an entirely different beast.
The migration process would involve the following steps:
- Deploy the Landing Zone: Deploy Control Tower in your existing Management Account to baseline the security OU and accounts.
- Enroll Existing Accounts: Control Tower gives you the option to enroll existing accounts, one by one.
- Validate IAM and SCPs: Before enrolling an account, you should run IAM Access Analyzer to ensure that the new Control Tower SCPs will not interfere with your production workloads.
- Network Refactoring: Migrate resources that use peer-to-peer VPC connections to a centralized Transit Gateway in the Infrastructure OU.
Conclusion
Building a robust cloud environment is not measured by the number of servers you manage, but the boundaries that you define around them. AWS Organizations and Control Tower enable you to shape AWS into something that resembles an enterprise-grade platform. By organizing logically structured OUs, enforcing preventative guardrails with SCPs, centralizing your security auditing, and codifying this infrastructure as code, you enable your developers to work in a world where security and velocity are not mutually exclusive.