AWS multi-account organizations
Everyone starts from a single AWS account and you may be wondering why you would need multiple AWS accounts. Let me explain…
The WHY
Easy multi-environment deployments
Having multiple accounts in your AWS organisation makes it very easy to create ‘staging’ environments. When using a single AWS account, resources that require a name to be supplied will need unique name values per-deployment to support multiple deployments in a single account. This can involve adding an environment name into the resource name. Whilst this is perfectly feasible, it will often trip up even experienced AWS users. When deploying environments to different accounts the same resource names can be used, keeping your resource configuration much simpler.
Some AWS services, like S3, also need unique names across accounts and so multi-account will not provide a full solution for those.
Apply distinct security controls by environment
It’s common to apply different security and operational policies for the non-production and production environments of a given workload. By using separate accounts for the non-production and production environments, by default, the resources and data that make up a workload environment are separated from other environments and workloads.
When AWS users have full access to your production environment it is very easy to make high impact mistakes that would be difficult to recover from. Users can use the AWS web console or CLI to modify or delete production resources, some of which have state (buckets, databases, etc.) that may be difficult to recover.
By removing delete permissions from production accounts we can create a safety net that prevents serious errors from happening. We can ensure that all production changes are source controlled, reviewed before deployment and managed using Terraform. IAM roles used for deployment can have delete permission disabled for stateful resources by default. When someone has approved the deletion action then the permission can be enabled.
Constrain access to sensitive data
When you limit sensitive data stores to an account that is built to manage it, you can more easily constrain the number of people and processes that can access and manage the data store. This approach simplifies the process of achieving least privilege access. Limiting access at the coarse-grained level of an account helps contain exposure to highly sensitive data.
For example, designating a set of accounts to house publicly accessible Amazon S3 buckets would enable you to implement policies for all your other accounts to expressly forbid making S3 buckets publicly available.
Distribute AWS Service Quotas and API request rate limits
AWS Service Quotas, also known as limits, are the maximum number of service resources or operations that apply to an account. For example, the number of Amazon Simple Storage Service (Amazon S3) buckets that you can create for each account.
You can use Service Quotas to help protect you from unexpected excessive provisioning of AWS resources and malicious actions that could dramatically impact your AWS costs. AWS services can also throttle or limit the rate of requests made to their API operations.
Because Service Quotas and request rate limits are allocated for each account, use of separate accounts for workloads can help distribute the potential impact of the quotas and limits.
I have witnessed several severe incidents around service limits. Some examples:
- One team had a lambda function that consumes from an SQS queue with uncapped concurrency. AWS has a default limit on total lambda concurrency in a region-account combination. That one lambda function pushed the total lambda concurrency to the limit, which stopped all of our other teams’ lambda functions from executing, effectively taking the business offline for a period of time.
- A hard service limit was hit on SSM parameter store requests, so runtime processes could not retrieve required credentials.
- Reaching a hard limit on the number of IAM policies in an account, requiring a refactor of resources to more AWS accounts before development could coninute.
When using a single account it is often possible to request service limit increases and put rate limit protections in place to prevent one resource from consuming too much of your quotas, but multi-account deployment is much easier and safer.
Manage costs
An account is the default means by which AWS costs are allocated. Because of this fact, using different accounts for different business units and groups of workloads can help you more easily report, control, forecast, and budget your cloud expenditures.
In addition to cost reporting at the account level, AWS has built-in support to consolidate and report costs across your entire set of accounts. When you require fine-grained cost allocation, you can apply cost allocation tags to individual resources in each of your accounts.
Alternatively, most AWS resources also support applying tags, which is useful for cost management. But, it requires additional work that multi-account can negate.
Group workloads based on business purpose and ownership
You can group workloads with a common business purpose in distinct accounts. As a result, you can align the ownership and decision making with those accounts and avoid dependencies and conflicts with how workloads in other accounts are secured and managed.
If you acquire a business that is already operating in AWS, you can move the associated accounts intact into your existing organisation. This movement of accounts can be an initial step toward integrating acquired services into your standard account structure.