AWS Multi-Account Design

In the previous two blog posts, we covered the core principles of establishing a successful cloud foundation and some of the organisational considerations for a multi-account platform.

In this post, we will investigate some of the common patterns applied to an AWS multi-account structure to aid in workload segregation and aid the transparency of billing across your organisation.

The previous post elaborated on AWS Organisations, which form the basis of many multi-account solutions, including the ones offered by AWS.

AWS Control Tower

Before we get into the weeds of AWS Control Tower, we must pause for a second to pay attention to AWS Landing Zone. AWS Landing Zone is not a service that you get to access in the console as you would normally do, but rather it is a complex process supported by AWS Professional Services or an AWS Partner. It configures AWS Organisations and establishes several AWS accounts, with some baseline configurations utilising AWS CloudFormation. In summary, it configures an account vending machine, baseline security controls and several core AWS accounts to get you started. Due to the complexity of this process, and multi-account strategies gaining popularity, AWS launched Control Tower at re:Invent 2018 and was made Generally Available (GA) in June 2019.

AWS Control Tower takes the concept of AWS Landing Zone and packages it up as a complete service, with user interfaces and various supporting features to manage Guardrails (both preventive and detective) and monitor compliance of the member accounts. AWS Control Tower deserves a complete article to explore all the features in depth, so we will not dive into further detail in this blog.

Unfortunately, AWS Control Tower is not available in all AWS Regions, thus is not a solution for every use-case currently. Keep an eye out on the announcements on additional region availability. At the time of writing this blog, ap-southeast-2 – Sydney region does not offer AWS Control Tower.

Both AWS Control Tower and AWS Landing Zone has an operational cost associated with it, as it provisions and maintains several guardrails and enables core features by default. It also makes use of integrated AWS services to manage the service. A good point to make here is that a basic AWS Control Tower deployment is very affordable and offers the small-to-medium business fantastic control over its multi-account ecosystem with minimal effort. The major benefit here is what took many IT-teams' months to plan and implement, is now a few button-clicks away. Like AWS Landing Zone, the AWS Control Tower service offers a range of tools and baseline deployments, which includes an AWS account “vending machine” as it is called. This vending machine assist the account administrator to easily define and provision new accounts within minutes that have all the necessary security guardrails configured as default, thus lowering overall risk in managing multiple accounts.

AWS multi-account reference structures

Combining all the topics and services explored, let's dive into two recommended AWS account patterns for both the small business and the larger enterprise.

The diagram below highlights an account structure for the larger organisation with various business units and a dedicated security and platform team.

Each of the account types depicted above serve a specific purpose and defined as follows:

Automation (CI/CD): This account is dedicated for activities related to the software development lifecycle (SDLC). Each business unit will setup their build and deployment pipelines centrally and deploy to one or more other AWS accounts. Services like CodeCommit, CodePipeline and CodeBuild will be the primary contenders for this account.

Sandbox: An optional account allowing for exploration and early testing of unproven software or services. The reason an account is provided to each business unit is primarily for billing isolation.

Non-Production & UAT: A good practice is to separate true non-production workloads from UAT (or official test) workloads. This practice will allow for different user privileges to be applied at each account, ensuring UAT is protected from manual activities and offer a higher confidence level of success when deploying changes to infrastructure or applications to production.

Production: Separating production from any other environment offers the best level of isolation and guarantees that only privileged users will have access to production resources.

Centralised Logging: Although not strictly a must, it is considered best practice to configure a centralised logging account. This is especially true for organisations that operate within a regulated industry. This account is to offer very limited access to ensure the integrity of log data for analysis and inspection in the event of an incident.

Shared Services: Platform Operations is conducted from this account, with AWS Systems Manager and patch management performed centrally into all the other accounts. Security & Audit: An account dedicated to the Cloud Platform Security team, which offers elevated access to all other accounts. Security incident response and forensic analysis tooling is a good candidate for services to be deployed into this account. Another good practice for organisations that make use of Amazon GuardDuty is to provision the master GuardDuty service in this account.

Central Networking: With services like AWS Transit Gateway, it may be appropriate to have a dedicated account to manage this “transit network” configuration. Central VPC-networks could also be established within this AWS account and shared to other accounts through services like AWS Resource Access Manager, although a shared network architecture like this should be considered only after various AWS account limits and supported services have been evaluated.

A good tip when getting started with more complex workload deployments is to define a good naming convention for all your AWS resources. A key take away from this structure is to understand that “non-production” or “production” may host multiple environments, and that the environment concept in the account structure govern the system-access and information-access policies, rather than denoting a physical environment.

Looking into a simplified multi-account ecosystem, the same account types apply, however some accounts may be combined for simplified management.

AWS account best practices

There are hundreds of cloud-native AWS best practices to follow, spanning every AWS service. AWS accounts are not excluded from this list, so here are some good practices for each of your AWS accounts.

**email-address: **use an alias or distribution list for your AWS account root users. A dedicated cloud-platform team address using the plus - (“+”) - character is also a great option if your organisation supports it (e.g. aws-account+sales@acme.com and aws-account+marketing@acme.com) . Remember that crucial account warnings and updates are sent to this email address, thus it is a good idea to have someone actively monitoring it. **root-user security: **each blog article mentions this but is not always followed in practice. Ensure that each root account has Multi-Factor-Authentication (MFA) enabled, preferably with a physical security key[JR1] , locked away in a safe place. Create a dedicated privileged user for billing related activities and lock-away the ROOT user credentials for a rainy day. See this blog for a step-by-step tutorial on enabling billing for non-root users.

Conclusion

AWS is continuously making improvements on how resources can be shared across accounts, cross-account connectivity, and billing allocations – thus there is no one-size-fits all model. Be sure to adopt cloud-native development practices such as Infrastructure-as-Code to make it easier for your teams to move workloads to new AWS accounts should it become a necessity.

We are looking forward to some great announcements this year at re:Invent 2019, and AWS Control Tower in the Asia Pacific Sydney region is one of them.

This blog article was written by Jaco Olivier, AWS Practice Lead at AC3. Join Jaco as he presents at AC3's AWS re:Invent Recap Lunch and Learn this December.