AWS Security Blog

Guidelines for When to Use Accounts, Users, and Groups

I often get asked when to use different AWS accounts to enforce separation of duties versus using IAM users and groups within a single account. While the complete answer depends on what AWS services you use, the general guidelines in this post will point you in the right direction.

As context for the guidelines, consider a scenario where you have three environments for an application (development, test, and production) and you want to separate access for AWS resources within each environment.

Using multiple accounts

Many customers start by creating separate AWS accounts for each environment for each application. This helps create a strong separation between all resources in each account. However, this approach can create operational challenges.

For example, if you have separate AWS accounts, you need to re-create IAM users, groups, and policies under each account in order to manage user permissions. This can be inconvenient for employees who need to work in all three environments and then have to sign in to each account separately. As you create additional applications, the number of accounts, IAM users, and credentials can be difficult to manage.

This problem can be somewhat mitigated by using federated access to the AWS Management Console; this lets you use your existing corporate identity management system (e.g., Active Directory) to authenticate users once and grant them access to the AWS account environments they need.

Delegated API access (aka cross-account access) is another IAM feature that can also alleviate password fatigue.  It allows you to gain access to other accounts on a temporary basis without having to sign-in.  There are a variety of use cases for this feature, one of which is to consolidate usage information across all accounts.

Using multiple accounts might also mean that you need to consolidate billing across the three accounts to aggregate costs for the entire application.

Using IAM Users and Groups within a Single Account

As an alternative to using separate accounts, you can create a single account per application and then use IAM users, groups, and permissions to manage permissions for development, test, and production. This simplifies the task of managing users and permissions and simplifies the user’s experience of working with applications.

You can use tags in Amazon EC2 and Amazon RDS for different applications and environments (Resource-level permissions for EC2 and RDS were introduced earlier this year.)  For example, you could tag all your production EC2 instances that run <application 1> as “App1-prod”. The instances in your test and development environments could be “App1-test”, “App1-dev”, etc. You can then assign different permissions to different IAM groups to make sure only a subset of your administrators has permissions to resources in the various environments. You can also use Amazon Virtual Private Cloud (VPC) to implement network-level separation between groups of EC2 resources. If your applications use AWS S3, Amazon RDS or other AWS services that support resource-level permissions, you can extend your permissions management scheme to include those services under a single account.

What if your apps use Elastic Load Balancing (ELB) or another service like Auto Scaling? Some services like ELB currently do not support resource-level permissions. In those cases, you have to decide whether an administrator should have the same privileges for all the resources for that service—for example, to all ELB balancers. If so, you’re fine. If not, you need to consider whether it makes sense to use multiple accounts after all.

A hybrid approach is to use two accounts: production and non-production. This allows you to separate your production administrators from your dev/test/other administrators, while still being able to use IAM users, group, and resource-level permissions. Using a separate account to host a production application that’s subject to compliance audits (e.g., PCI) enables you to carefully manage the scope of the audit and to restrict access in the account to a specific set of resources.

For a complete listing of which AWS services support resource-level permissions, please visit the AWS Services that Support IAM page. Recent blog posts on resource-level permissions can be found at:

Hopefully this has given you some ideas for when to use the different approaches to enforce separation of duties across your AWS environment. Let us know what works for you or if you come up with something different! Oh, don’t forget to improve the security of your account in less than 5 minutes by activating multi-factor authentication.

– Max

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.