Leveraging Multiple Accounts in Your AWS Environment
Multiple Accounts Strategy, Cross-Account IAM Roles, and Role Switching – Part one of this three part series.
Considered to be best practices in AWS, as well as one of the most popular ways to fully maximize the potential of AWS, is to utilize multiple accounts. Accounts can be set up as either per-organization, per-department, or even per-application and can be utilized to logically and physically separate any resources to fit your organization’s needs. This, combined with master-account billing and properly utilizing Tags, can allow you to be as separate, yet collected, as you see fit.
Multiple Accounts Strategy, the why of it
There are many reasons an organization may choose to use multiple AWS accounts – maybe they want their development team to have a full environment they can utilize however they see fit, without the risk of a change being made in production. Or maybe they want each developer to have their own sandbox that no other developer has access to. Maybe they have multiple clients in AWS and need an account for each client, while providing complete separation between environments. Regardless of the reason, maintaining logical and physical separation through separate accounts has proven to be a key factor in the security and stability of production workloads.
Multiple logins get messy – Role Based authentication between accounts
Initially, the downside to using multiple accounts was having to provide multiple logins to each person that needed access – a DevOps Engineer may have credentials to their personal sandbox account, internal company accounts, developer accounts, and client accounts. The number of logins required for all of those accounts would be prohibitive – and would make it much more difficult to follow good security practices, such as password rotation and not reusing passwords between accounts.
To battle the credential overload that was occurring AWS implemented cross-account, role-based IAM access. This allows an organization to create an IAM role (i.e. development-role) and assign specific permissions to the role, then allow that role to be accessed by users logged in to a different account.
Users from the main account (user1@MainAccount) are able to Switch Roles to the new role in the client account (Admin@RemoteAccount) and have those specific permissions granted to them. Instead of having multiple sets of credentials, users are now able to maintain one set of credentials but have multiple roles they can switch to which can allow different permissions on either the same account, or across different accounts. The best part? Each time you create a role it also generates a URL which a logged-in user can click to immediately be taken to the Switch Roles screen, making it even easier to manage a large collection of roles.
Accounts do not need to be linked in any way – other than listing one account as a Trusted Entity to the other in the role permissions – for this to be used, making it an ideal way to provide access to consultants or contract workers.
Master Billing Account – One Bill to Pay (for) Them All
An initial reaction to having numerous accounts under a single organization may be “I don’t want to manage 14 separate bills, and 14 places to enter my credit card number” – and that would be a valid reaction. No one wants to deal with that, and no one should have to. AWS allows for a single master billing account to be placed over any number of child accounts, allowing for a single consolidated bill with all of the tags and options of each individual account listed. Billing reports can be created based on account, resource type, region, tags, or any number of other values to show you exactly what you want to see, exactly how you want to see it. This can be used in conjunction with cross-account IAM access but is not a requirement for that access.
That’s all for Part 1 of our blog post detailing the ways that using multiple AWS Accounts can be beneficial to your organization. In Part 2 we will go over how to configure user roles and allow access to your organizations’ other accounts.