Today, I’d like to answer a common question people ask about AWS accounts:
How many AWS accounts do we need?
What’s an AWS Account?
First let’s start with some background about what an AWS Account is and the features it provides. An AWS Account is a logical container that owns resources in the AWS Cloud. The users of an account may provision resources such as EC2 instances or S3 buckets according to the permissions that have been granted via the AWS Identity and Access Management (IAM) service. AWS bills the owner of the account for the use of those resources.
AWS Accounts are the primary management construct and strongest partitioning mechanism for an organization’s activities, resources, and data in the cloud.
Big Scope, (Potentially) Big Problems
There are critical services and limits that are scoped globally or regionally within an account. Let’s explore an example of each here briefly.
IAM is the most critical service to configure properly in AWS as it manages access control for all users, resources, and data in the account. IAM has a global scope within the account and a flat organizational structure. This means that if you create an appeng role, that role exists throughout the entire account. If that role has permissions to create and destroy S3 buckets, then people who use that role will be able to do that throughout the account by default. The capability and potential for someone with the appeng role to destroy an S3 bucket will exist regardless of whether convention says ‘prod buckets go in us-west-2 and dev buckets go in us-east-1’ or that bucket was ‘belonged’ to a different department in your organization. Some of these risks can be mitigated by conditional expressions in IAM policies, but that requires IAM to be managed well in the first place and demands a significant increase in IAM role & policy sophistication.
Every AWS service is rate-limited, including ‘control plane’ APIs like the ones that automation may use to describe EC2 instances or an ECS Service. These API limits generally apply to all of the Account’s clients accessing that API in a given region. The risk here is that a customer-implemented service that manages scaling of EC2 or ECS instances may go crazy and make many requests to a control plane API. The control plane API will enforce its limit regardless of whether the caller is coming from a dev, stage, or production environment. These limits are generally unchangeable, unlike the maximum number of EC2 instances or VPCs in a region.
Update: We built k9 Security to help Cloud engineers understand and improve their AWS Security policies quickly and continuously. Check out how k9 can help you Go Fast, Safely.
Managing Complexity Using Account Partitions
Organizations are Complex systems balancing the many dimensions and shifting priorities of developing, delivering, and running applications on AWS and elsewhere. In AWS, the best way to balance the needs of a fast changing development environment and a revenue producing production environment is to partition those activities into different accounts. Both development and operations activities are critical to the organization. Partitioning these activities into separate accounts helps you tailor the approach to security, stability, and change both need to succeed.
Accounts are the strongest AWS-provided boundaries for
- Security: limiting access between to an environment’s activities and data and containing compromise
- Faults: containing the blast of an accident (or malicious) change that destroys resources or exhausts control plane APIs
- Audit and Compliance: clearly defining and limiting audit scope
Partitioning an organization’s use cases by account also simplifies management of IAM entities. When the use cases of a a given AWS account are narrowly-scoped and well-defined, you can create simpler IAM roles and policies that are targeted for each of your use cases. For example, if you have three phases in your application delivery lifecycle, you might have e.g. a dev, stage, and prod policy for the appeng role. Then you can deploy the IAM entities that are appropriate to a given account, e.g. the appeng role gets (only) the dev-appeng policy in the dev account. A nice feature of this model is that it’s Obvious how to provide application engineers with more capabilities in dev than prod. The process for managing and deploying this kind of IAM model is Complicated, but tractable and comprehensible, which is great for security amongst other concerns.
So the answer to ‘How many AWS accounts do we need?’ is:
Create however many accounts your organization needs to establish safe security and fault boundaries that enable your organization’s primary use cases and expected level of team/application autonomy.
These account use cases are typically driven by the organization’s structure and application delivery process. Conway’s Law rules AWS Organizations, too. A good place to start for many organizations is to create a set of accounts partitioned by delivery phase for each department or business unit. Logically this looks like (blue):
If your company has
- Three business units using AWS: Retail, Business Intelligence, and a new acquisition
- Three phases in the application delivery lifecycle: dev, stage, prod
Then this company might start with 9 ‘runtime’ accounts (3 Business Units * 3 delivery phases) plus a dedicated AWS master+billing account for a total of 10 accounts. The diagram depicts a few other specialized accounts we haven’t discussed (yet).
There are other pieces to this puzzle like how will the organization manage services shared across the organization, disaster recovery, sandboxes, and more. These use cases depend on the organization’s goals.
The overarching goal here is to design and adopt a model that helps your organization get where it needs to go.
Do not take your AWS account structure lightly.
Creating robust security and fault partitions after a large deployment is complete usually means migrating non-production environments out of the (prod) ‘kitchen-sink’ account. Conversely, partitioning the services of a monolithic application/system into dedicated accounts will cause significant problems if the couplings of the existing system is not respected. When individual services are coupled to the rest of the services in the system via change lifecycle, shared data, or similar, then the effort to manage the resulting cross-account dependencies may negate whatever benefits of partitioning you were trying to achieve.
Next Up
In the next post, we will dig deeper into the question of ‘How should I organize my AWS accounts?’ by exploring the pattern of partitioning accounts by Delivery Stage and Business Unit. We’ll cover the benefits, tradeoffs, and identify the situation where this pattern works best.
Please reach out to me with any questions or aspects of AWS account management you’d like to me to cover!
If you’d like assistance architecting and implementing your own AWS account structure, QualiMente has a Secure AWS Account Foundation service to guide and accelerate you.
Stephen
#NoDrama
