AWS Multi-account architecture

Have you ever heard the saying ‘never put all the eggs in one basket’?

Even today, we stumble upon projects, even recent ones, which are managed with a single AWS account. This triggers The Little Red Light (™) in the brain of any Teraclouder, because of the risks that this decision implies.

Why?

As you can guess, the main benefits are in the security aspect. Using different accounts for different workloads or applications we create a logical boundary, thus improving the general security. This also minimizes the blast radius in case of a security breach because only the resources in the affected account will be compromised. While the fine-grained access controls provided by AWS IAM make it possible to separate access within AWS accounts, it is easier to do it through the separation of access across accounts.

From the billing perspective, using multiple AWS accounts simplifies how you allocate your AWS cost by helping identify which specific business unit (BU), environment, application, or project cost center is responsible for an AWS charge. Tagging resources may allow you to achieve the same, except that not every type of resource supports tagging for detailed billing. You might think that having an invoice on every account is going to be chaotic, but AWS Organizations allow a company to roll up all the invoices from every account into one central bill. So the eggs are in different baskets, but they are still under control.

Now, suppose that your company asks you to prepare your environment to get credit card payments. There is a very high chance that you need to comply with heavy regulatory requirements, as dictated by HIPAA or PCI for example. If your whole environment is on a single account, the cost and time needed to adjust it to the regulations can be astronomical. By separating the critical, regulated workloads to a separate account you can isolate these processes and keep the cost at a minimum.

Now, suppose your company asks you to prepare your environment to get credit card payments. Having several accounts simplifies compliance requirements. Many organizations have exceptional compliance or privacy considerations. They need to apply to their data and processes, like HIPAA or PCI. By moving workloads that don’t have to be compliant and follow regulations, remove the need for these workloads to participate in the time-consuming and burdensome processes.

Enable autonomy between teams may be another good reason to isolate each organizational unit within a dedicated AWS account and offer each group a playground or sandbox to experiment.

Best practices

There is no single way to design your multi-account architecture; the design will be different for each company depending on its workloads and security restrictions. However, there are common patterns to apply to any company.

● Centralize security logs, like CloudTrail logs, Config snapshots, VPC Flow logs on an AWS account with restricted access.

● Centralize security findings and notifications across all accounts in one place.

● Use a different account to deploy services shared between multiple accounts like Active Directory.

And remember: Always automate! Infrastructure automation enables speed through faster execution when configuring your infrastructure, removes the risks of human error, and allows collaboration between teams across the organization. Infrastructure as Code is a must-have in the multi-account scenario.

Conclusion

With a well-architected multi-account strategy, you will be able to innovate safer, cheaper, and tidier in AWS, and all your eggs will be safe now because you have a plan with contingency actions. Do not hesitate to contact us at Teracloud.io with questions or concerns about multi-account architecture on AWS. We can help you.