Why You Need Multiple AWS Accounts

It is common for organizations to start evaluating Amazon Web Services (AWS) by creating a single AWS account. Some of the experiments and proofs of concept created in that AWS account become load-bearing production resources.

In this article, I will discuss a little history to explain why this is so common and provide five reasons why you need to have multiple AWS accounts.

A Brief History of AWS Accounts and Organizations

When AWS launched in 2006, it was designed with a single-account model in mind. Each AWS account required a unique email address, which inadvertently suggested that organizations should operate with just one account. This perception was reinforced by the absence of a native multi-account management solution.

As cloud adoption grew and enterprise needs became more complex, the limitations of the single-account approach became apparent. In response, AWS introduced AWS Organizations in 2017, a service designed to help businesses centrally manage and govern multiple AWS accounts.

Since Organizations launched, multiple services and features to enable better cross account resource sharing and monitoring have been launched. AWS has also released multiple white papers, blog post and training materials to support proper multi-account usage.

Five Reasons to Have Multiple AWS Accounts

Access Control

If you have production and development resources in the same AWS account how are you limiting developer access to production resources? There are two possibilities here:

1. You are not limiting access
2. You are using a complicated set of IAM Policies

Not limiting access to production resources adds completely avoidable risk and should be addressed immediately. If you are operating in an environment that must meet common compliance goals then this is likely a show-stopper.

To achieve the least privilege you will most likely utilize a combination of Role Based Access Control (RBAC) and Attribute Based Access Control (ABAC). These setups can become quite complicated to understand and maintain.

Limiting developers too much can negatively affect innovation and agility. Granting them too much access introduces unnecessary risk and potential compliance problems. How do we find a good balance while minimizing complexity? I bet you can guess based on the title of this article, multiple AWS accounts.

Utilize separate AWS accounts so developers can have the permissions they need to innovate and learn in AWS without adding complex IAM configurations or introducing unnecessary risks to production.

Understanding Cloud Spend

How much did we spend on AWS for our primary production application? How much are we spending on our compute for our self-hosted CI/CD platform? How much is engineering spending in AWS on experiments and learning? These are not uncommon questions and answering them can mostly be trivial with the right planning.

There are two main ways to set yourself up for success here, and most likely you should utilize a combination of both methods.

1. Cost Attribution Tags
2. Multiple AWS Accounts

Applying tags to resources to identify their environment, team, and project is common and helpful for cost attribution. At a certain point, this system can become complicated and require engineering time to plan and maintain.

Many successful organizations combine a cost-attribution tagging strategy with multiple AWS accounts to simplify the tagging strategy.

Reduce Blast Radius

Picture this: It’s 7:00 PM on a Friday. You’re a security engineer, settling in for a cozy family movie night. The popcorn is hot, the lights are dimmed, and you’re just about to press play when your phone buzzes. It’s a notification about a potential security incident in your AWS environment. With a sigh, you pause the movie and head to your home office.

As you begin investigating, one of your first tasks is to determine the scope of the incident. In a single-account setup, this can be a daunting prospect. If unauthorized access to the AWS control plane has occurred, every system in that account could potentially be compromised. The blast radius is enormous, encompassing development, staging, and production environments alike.

Now, imagine an alternate scenario where your organization uses multiple AWS accounts. You quickly identify that the affected account is your development environment. While still serious, you breathe a sigh of relief knowing that your production systems, running in a separate account, remain untouched. The blast radius is contained, and you can focus your immediate efforts on the affected account without worrying about potential impacts on critical production workloads.

This principle of blast radius reduction applies equally to security incidents and operational issues. Whether it’s an unauthorized access attempt trying to move laterally through your systems, or a well-intentioned but mistaken infrastructure change causing an outage, multiple AWS accounts act as firewalls, containing the problem to a specific environment or workload.

By utilizing multiple AWS accounts, you’re not just making your Friday night interruptions potentially shorter and less stressful. You’re implementing a fundamental principle of cloud security and operational excellence, ensuring that a problem in one area doesn’t cascade into a company-wide crisis. It’s a simple yet powerful strategy that can make all the difference when those inevitable incidents occur.

Utilizing AWS accounts as resource boundaries is a very simple and clear mechanism to reduce blast radius.

Service Quotas

Imagine a developer, enthusiastically working on a new feature. They spin up Amazon EC2 instances, set up auto-scaling groups, and configure databases – all without a care in the world. But lurking in the shadows are service quotas and pre-defined limits for specific resources within an AWS account. These quotas exist for a reason, to prevent runaway costs and ensure fair resource allocation. When you operate in a single AWS account you are sharing these service quotas across all of your environments and potentially starving production of the resources it needs.

For example, the default service limit for on-demand R family EC2 instances is five. AWS will automatically adjust this service limit based on usage and you can (and should) request an increase to this service limit if needed. Imagine a scenario where your production workload is running on two EC2 instances, a scaling event occurs requesting an additional EC2 instance to handle user traffic, but this scaling fails due to testing a developer is doing in the AWS account causing the service limit to be exceeded. This is completely avoidable by having non-critical testing and development resources in a different AWS account than production resources.

Say it with me, “do not let non-production resources impact production”.

Security Controls

Utilizing multiple AWS accounts allows for a more granular and tailored approach to security controls. Here’s how:

1. Environment-specific security: Different environments (development, staging, production) often require different levels of security. With separate accounts, you can implement stricter controls in production while allowing more flexibility in development.
2. Data sensitivity: Accounts handling sensitive data (e.g., customer information, financial data) can have more rigorous security measures compared to accounts with less sensitive information.
3. Compliance requirements: Certain workloads may need to meet specific compliance standards (e.g., HIPAA, PCI DSS). Separate accounts make it easier to implement and maintain compliance-specific controls without affecting other workloads.
4. Cost-effective security: By tailoring security controls to each account’s needs, you can optimize costs while maintaining appropriate security levels across your organization.

AWS Organizations integrates seamlessly with various AWS security services, enhancing your ability to implement and manage security across multiple accounts:

1. AWS Control Tower: Provides a way to set up and govern a secure, compliant multi-account AWS environment based on best practices.
2. AWS Security Hub: Offers a comprehensive view of your security and compliance status across multiple accounts.
3. AWS Config: Enables you to assess, audit, and evaluate the configurations of your AWS resources across accounts.
4. Amazon GuardDuty: Provides intelligent threat detection across your AWS accounts and workloads.
5. AWS IAM Access Analyzer: Helps you identify resources in your organization and accounts that are shared with an external entity.

By leveraging these services in conjunction with AWS Organizations, you can ensure appropriate monitoring and security controls are in place across your entire AWS ecosystem, tailored to the specific needs of each account and workload.

Conclusion

An AWS account is a resource boundary, nothing more nothing less. Operating your entire organization in a single AWS account is not an accomplishment, it is an indicator that you are not following common best practices.