Multi-Account Architectures in AWS. Why? When? How?

In 2017 AWS made it official — multiple accounts were both supported and recommended with the release of AWS Organisations. Forward-thinking companies had already begun to adopt multiple accounts for the purposes of security, governance, and billing, but at this point, it became mainstream.

AWS Organisations has made it simple to build a hierarchy of accounts dedicated to different purposes, with varying policies that control them. Since launch, additional services have come along to either augment organisations (Control Tower) or tightly integrate with it (Guard Duty, Security Hub, IAM Identity Centre / SSO).

This flexibility does come at a cost though. There is overhead in managing multiple accounts and potential complexity for end users. When is it a good time to adopt a multi-account structure? What architecture achieves the best balance of security and governance? How can the overhead of account vending be reduced?

When to go multi-account?

There is no doubt, that adopting a multi-account architecture, likely based on AWS Organisations is an undertaking, but it can have great benefits, building a strong foundation for your cloud adoption.

In my opinion, there is no wrong time to go multi-account, with one exception. More on that later.

Drivers for adopting a multi-account model within AWS include;

• A desire to create multi-tenancy, for either internal or external consumption,
• Creating separation between environments (Development, Test, Production)
• Delegation of sensitive rights to parts of a business, or protecting them from each other.

The drivers are all different, but they have one thing in common, they require an understanding of your business beyond technology. The way that software is deployed in organisations gives an impression of how they operate.

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” — Conway’s Law

How much authority will you delegate? What connectivity will there be between accounts? What is standard across your accounts? Who will manage the core parts of the deployment? How wide or deep will the account hierarchy be?

These are the fundamental questions that you need to understand before undertaking multi-account initiatives. This is the one exception that I teased.

Unless you know your organisation sufficiently, rushing to multi-account will likely end up having to go through painful refactoring and migration when you do understand it.

Common Cloud adoption actors

Every organisation is different, but, consider the following stakeholders and how they map to your business. Have you considered them?

Cloud Centre of Excellence

A CCoE is likely to be the owner of an AWS Organisation at the highest level. They will define the organisation structure, delegate authority and define guardrails at a broad level. They will be the shining light ensuring that new features are made available to foster innovation but also ensure that the organisation uses AWS effectively, optimally and safely.

Security and Governance

Security will want to understand;

• the implications at a networking level — how will the cloud link into existing networks? what will be internet accessible? Remember — even AWS recommends all traffic even with VPCs should be encrypted in transit by customers.
• how and where audit logs are stored and how can they be queried?
• how access is managed for users and machines?

Internal Developer Platform Engineering

Increasingly, consumption of AWS Accounts in larger organisations is being treated as a product lead experience, with Platform Engineering Teams developing account templates maintained programmatically and treated as a commodity product.

Treating accounts like a product supports the enforcement of consistent security patterns and end-developer experience. The challenge here though is that ‘the product’ has to be clearly defined, with a deep understanding by all stakeholders on the shared responsibility model. For example;

• who will co-ordinate link VPCs to the corporate network?
• who will ship logs to the organisation’s SIEM?
• how much freedom is given with IAM? Pre-baked policies or freeform with enforcement using permission boundaries?

A platform engineering team like this will need a deep understanding of AWS, in particular its mechanisms to enforce policy and behaviour across an AWS Organisation including; best practice SCP authoring, IAM complexity and AWS Config.

Development and Operations

Developing within a sandboxed AWS Organisations managed account can be different to the experience of a regular one. Developers must be educated on how to consume your AWS account product; what is allowed and prohibited, different roles that may be required to perform different actions and what services may not be available.

Operations should have the same restrictions as developers — providing ‘god-mode’ for Operations can lead to over-reliance on ClickOps and create a gulf of understanding, making it difficult to help get into the mindset of developers.

Reducing account vending overhead

When an organisation moves from a handful of accounts to dozens or hundreds, account provisioning needs to become automated. This ensures;

• consumers can vend an account quickly, improving their experience,
• accounts are created to pre-defined patterns, enforcing security and attaching to networks consistently,
• accounts are treated as a product-like consumable entity, encouraging consumption via Infrastructure as Code.

What’s needed to reduce account vending overhead?

1. Model your business use cases and gather requirements;

• What AWS features need to be disabled for compliance?
• What regions can you use?
• What networks do your accounts need to reach?

2. Create a shared responsibility model for your account pattern;

• How will requests for new accounts be received and authorised?
• How opinionated will your pattern be?
• How restrictive will your IAM and SCPs be?
• Who will keep policies updated?
• Who will be responsible for delegating access to the account?
• Who will be responsible for billing and quota administration?

3. Adopt an automation approach for account vending;

Options for automated vending include;

Standalone AWS Organisations

AWS Organisations on their own can technically tick the boxes for managing a large hierarchy of accounts and are the basis of pretty much any other solution (AWS Control Tower or other custom landing zones). However, it is a foundational service and as such doesn’t give the creature comforts of Control Tower (dedicated logging and audit accounts, pre-built guardrails).

However, for anyone learning about multi-account structures, it is the quickest, cheapest way to expand your understanding. If you’re studying for AWS Certifications, setting up your own AWS Organisation is likely the only way to grasp some of the concepts, and on certain exams, it is heavily featured.

AWS Control Tower

Provides an opinionated, but not overly restrictive multi-account platform, with account vending. It’s great to get started with but can be difficult to scale. It does support automation, but generally out of the box steers you towards ClickOps management. The out-of-the-box guardrails cover a broad range of common cloud security principles including encryption, region blocking and logging.

AWS Control Tower with Account Factory for Terraform (AFT)

AFT brings great scalability to Control Tower. It allows the creation of accounts using Terraform, with accounts defined in code, and a very flexible method to apply consistent patterns to accounts. The barrier to entry is surprisingly low with great examples to get you started — https://docs.aws.amazon.com/controltower/latest/userguide/aft-getting-started.html.

Considerations for Architecting your multi-account landing zone

1. Consider how your OU structure will allow you to control both business compartmentalisation and product management.

For example, you may want top-level OUs for Platform, Networking, Security and Workload Accounts. Then under Workload Accounts decompose down to Non-Prod / Prod and Business Units. Remember that tagging can be used to query accounts by business units, so it is likely better to create a taxonomy based on product features/capabilities, and only differentiate by business unit at the lower levels.

Example AWS Hierarchy

2. Consider how your consumers will consume IAM to provide privileged access while preventing them from unpicking guardrails in the account.

There are two options here to provide delegated privileged access within an AWS account — permission boundaries and pre-built policies and roles. Pre-built policies and roles are familiar and require no explicit end-user action apart from simply consuming them, however, it requires meticulous composition to prevent privilege escalation, especially if you want to give the rights to create IAM Roles to attach to instances. The alternative is permission boundaries. Permission Boundaries are poorly understood, but they are the tool for the job here. They provide a way to give a ringfence around a user, even if they have Administrator access in an account, preventing them from getting to resources specifically denied by the boundary. The only downside — users need to explicitly attach their permission boundary to their IAM role, but it is there in Terraform and other SDKs, just overlooked!

3. How will you link your organisation to external networks?

Consider how you will reach your corporate network if you don’t already have this in place. Transit Gateway is likely your only sensible option when scaling to multiple accounts, potentially needing Direct Connect uplinks to your data centres. Do you want to control traffic between accounts using AWS Firewall? How do you want to give internet access, if any?

4. Audit Logging

How will CloudTrail and application audit logs be collected and stored securely? Will they be streamed to a separate log archive with limited access — who will monitor and alert them? AWS doesn’t offer a SIEM tool within its service offerings, so a third-party solution needs to be considered, and how it will integrate with your log ingestion mechanisms.

5. How will run costs be managed and accounted for?

• Who will be responsible for tracking spending, and purchasing Savings Plans and Reserved Instances, as needed?
• Who will measure compliance against tagging requirements?
• How will costs for shared resources be attributed?
• Have you considered the deployment of cost-optimisation tools i.e. https://cloudcustodian.io/ to keep waste under control?

Your AWS multi-account journey

The benefits of adopting multi-account architectures can be large, especially as organisations scale in their AWS adoption, but it does have to be considered and well executed. In summary;

• Don't rush to a solution,
• Know your organisation,
• Focus on the who and the why, not the how.