The Importance of a Multi-Account AWS Strategy

When the cloud environment grows, an AWS account is quickly becoming very challenging to manage. The security boundary is becoming increasingly fuzzy, permissions are becoming more complex, and operational risks are accumulating.

A multi-account strategy addresses these challenges by:

• Separating workloads and environments

• Providing enhanced security and compliance

• Simplifying access control

• Mitigating blast radius during incidents

• Enabling autonomous ownership within teams

• Accommodating growth of the organisation

Ensuring that these accounts are created and maintained in a standardised fashion, is the main challenge. AWS Control Tower and AFT are solving these two challenges.

Set up the Landing Zone with AWS Control Tower

The setup process started with AWS Control Tower, which provides a governed environment for managing multiple AWS accounts at scale.

The following items were included in the landing zone:

• Setup of the AWS Organisation

• Configuration of the Identity Center

• Accounts for auditing and logging purposes

• A centralised backup strategy

• Enabled AWS Config

• Defined governing rules and governance controls

• The organisational unit structure (OU)

These formed the building blocks of all accounts and workloads in AWS going forward.

Defining the Organisational Structure

An clear hierarchical organisational structure was designed and implemented through OUs to keep workload separation and governance boundaries clean.

The following is an example OU structure:

• Sandbox

• Security

• Infrastructure

• Workloads

• Suspended

Image source: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html

Each OU was governed through the baselines supplied by the Control Tower, which ensures that the security controls and compliance standards are consistent across all accounts.

Automated Account Provisioning via AFT

Following the successful establishment of the landing zone, AFT was put into place.

Account Factory for Terraform (AFT) extends AWS Control Tower, enabling account provisioning in a GitOps-style by means of Terraform.

Instead of creating the accounts in the console, the teams create requests for the accounts they need via a repository. AFT can automatically create and onboard the account and its basic settings.

This results in:

• Automated account creation

• Enforcement of controls from the beginning

• Standard account setup

• Reproducible Infrastructure as Code processes

• Reduction of operational workload

When a new account is created, the system automatically:

• Applies control Tower's governance baselines

• Configures the account for AWS Config

• Sets up standard IAM roles

• Configures central logging

• Applies all necessary security guardrails

The average creation of the account takes around 30 to 40 minutes.

Managing OUs as Infrastructure as Code

The system treats OUs as code too. Terraform modules have been designed to:

• Create OUs

• Define the OU hierarchy

• Ensure governance compliance across all OUs

• Version control all changes through pull requests

Image Source: https://aws.amazon.com/blogs/aws/new-aws-control-tower-account-factory-for-terraform/

The AWS organisational structure changes at the same pace as any other infrastructural and application changes.

Introduction of Centralised Deployment

It can quickly become overwhelming when it comes to the deployment of resources into the different AWS accounts.

To make this more manageable, a centralised deployment account was set up. Instead of pushing deployments from individual Git repos to workload accounts, a central deployment account handles all deployments into the workload accounts.

The following is achieved through this approach:

• Centralised control of deployments

• Uniformity across all deployments

• Fewer access keys need managing

• Simpler audits

• Improved visibility into operations

Workload accounts can grant trust to the deployment account to execute deployments in the account.

Removal of Static Access Keys through OIDC

One of the security requirements that was identified early on was to prevent long-living access keys from being included in CI/CD pipelines. This was solved by configuring an OpenID Connect (OIDC) connection between the CI/CD platform and AWS.

Image Source: https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html

By implementing OIDC:

• No sensitive information remains in source control or CI/CD tools

• Short-lived, dynamically generated credentials

• Access to resources are limited to the absolutely required permissions

• The security posture is drastically improved

Whenever a pipeline needs to deploy, it can exchange an OIDC token for a set of temporary credentials with AWS Security Token Service (STS).

Eliminates risk associated with statically configured access keys and improves the overall cloud security posture.

End-to-End Account Onboarding Process

The full lifecycle of an account is handled by a completely automated process:

1. The new OU is created via a Terraform change.

2. The OU is registered to the AWS Organisation.

3. A new account is requested through a Git request.

4. AFT automatically creates the account and its basic configurations.

5. Governance controls from Control Tower are implemented automatically.

6. The account's default IAM roles and settings are deployed.

7. The account is prepared to accept centralised deployments.

8. OIDC is set up and its trusts configured in the account.

9. Workloads are deployed into the account from a central deployment account.

This provides a repeatable and auditable way to set up any new account in the AWS cloud.

Core Security and Governance Principles

A few high-level principles drove the design of this platform.

Governance by Default

From day one all accounts are inherently managed by Control Tower's rules.

Infrastructure as Code

Everything is handled as Infrastructure as Code, from the OU hierarchy all the way to account provision requests and customised resources.

Least Privilege

User access controls are minimal to the exact required level.

Centralised Visibility

Logging, auditing and backups are managed centrally.

Credential-less CI/CD

The credentials, or rather lack of them, in the CI/CD pipelines significantly reduce the overall risk of sensitive information leak.

Business Benefits of the Implemented Platform

• The number of accounts and the ability to onboard new environments to AWS were sped up tremendously.

• Consistent rules apply throughout all your accounts.

• Security posture improved, mainly thanks to the secure CI/CD integration.

• Operational overhead for maintaining AWS was reduced significantly.

• Compliance with different standards is much easier to manage.

• This is a highly scalable adoption model for the cloud.

• Finally, CI/CD pipelines are much more secure as they do not contain static credentials.

Most of all, it gives you a foundation that can be relied upon when building more future workloads without a need to fundamentally rethink the architectural setup.

Concluding Thoughts

A truly efficient cloud platform cannot exist without strong governance, a flexible automated system, tight security, and operational uniformity from the get go.

The platform implemented integrates AWS Control Tower, AFT, Terraform, and OIDC, setting up a modern and scalable foundation that will be able to adapt to the rapid changes and growing requirements of your business, while at the same time upholding high security and governance standards.

For organisations looking to embark on an AWS multi-account strategy, investing time and effort in building a solid foundation with a well-defined landing zone from the very beginning can minimise operational complexity and promote successful long-term cloud usage.