In this article, we will dive deeper into the concept of the AWS platform and look at some best practices and considerations for defining an AWS multi-account environment.
Although best practices are there to provide guidance, the architecture of your AWS environment will be significantly influenced by business factors, individual requirements, and your strategic direction. Therefore, let's explore some of the common benefits regarding defining an AWS account strategy. Not every one of them will apply to your use case and, ultimately, the different aspects need to be illuminated to define a custom-fit multi-account strategy and landing zone.
7 Reasons Why You Should Split Your Monolithic AWS Account Into Multiple Accounts
1. Drive innovation and agility
With advancing digitalization, the IT department becomes a driving force for innovation and agility within a company. To nurture ideas at an early stage, you can provide your employees with separate AWS accounts. With broader access to AWS services, these environments offer more flexibility than tightly controlled production-like testing or even centrally managed production environments.
To keep things in check, we recommend setting up security guardrails and cost budgets for these types of accounts.
2. Separation of customer data
As a SaaS provider in particular, you might wonder how to efficiently segregate different sets of customer data. Achieving separation through different AWS accounts becomes particularly attractive when a very straightforward boundary per tenant is needed. If your customers are concerned about potential cross-tenant access, an AWS account-based isolation model is the most compelling argument for data security.
3. Reduce explosion radius
Resources on one account are isolated from resources on other accounts, even within your own AWS organisation.
This boundary provides you with the ability to limit the impact of an application-related problem, misconfiguration, or malicious act. If an issue occurs within one account, the impact on workloads in other accounts is either reduced or eliminated.
4. Security and compliance
Assuming your applications process GDPR-relevant data, wouldn't it be much more efficient to point your auditor or pentester to a dedicated production account? These dedicated accounts allow security teams to focus on the necessary controls and detailed threat models, rather than auditing the entire cloud landscape. Not only does this simplify your auditing process, but it also encourages innovation by leveraging less restrictive accounts in other areas of your organisation.
5. Support different IT operating models, teams and organisational structures
Let's say an organisation wants to encourage autonomy among its project teams. In such a case, it makes sense to isolate each team within a dedicated AWS account and provide each team with a playground or sandbox to experiment. This allows each team to choose the optimal operating model for their application, such as Traditional Ops - CloudOps - DevOps.
A suitably configured landing zone gives you the ability to set guardrails for the different models.
6. Manage costs
Many organisations have the requirement to allocate AWS costs to a specific business unit (BU), environment, application, or project cost centre. A multi-account strategy allows you to break down costs by account. For this reason, using different accounts for different business units and groups of workloads is helpful to control, forecast and budget your cloud spending more easily.
There is also the ability to allocate costs through fine-grained reports and filters using AWS resource tags. While this feature is helpful, it may not be the easiest mechanism for cost allocation for versatile and large workloads. Also, keep in mind that not every resource type supports tagging for detailed accounting.
7. Distributing AWS Service Quotas and API Request Rate Limits
AWS Service Quotas, also known as limits, represent the maximum number of service resources or operations applicable to an account. For instance, this could include the number of Amazon Simple Storage Service (Amazon S3) buckets.
Perhaps you're running a high-performance application that processes events across various event-driven AWS Lambda pipelines. These should not be affected by service limits and concurrent Lambda execution thresholds, as they might be shared by other applications. In such cases, you have a strong use case for isolating this application within a dedicated AWS account.
The above-mentioned points cannot be considered separately; instead, each aspect should be weighed individually when evaluating the suitable multi-account concept in AWS for your case.