ra2 studio - Fotolia
What you need to know to manage multiple AWS accounts
Explore AWS services and best practices that can optimize multi-account management across your organization.
Many organizations -- begrudgingly -- have to manage multiple cloud accounts within AWS, whether it's the result of acquisitions or because multiple departments sign up separately. However, managing multiple cloud accounts is actually beneficial and a growing number of users recommend this type of segmentation.
Regardless of the reason your organization has multiple AWS accounts, this setup can provide easily provable isolation for security, and simpler billing and cost savings. It also helps enforce software development and infrastructure-as-code best practices.
However, without the proper tools and processes, multiple cloud accounts can also add complexities. Decide which native service is right for you and review some best practices involved in managing multiple AWS accounts.
AWS Organizations vs. Control Tower for multi-account management
There are a few different ways to manage multiple AWS accounts under one main account where all the billing is centralized, and you can see all the sub-account usage and cost. AWS Organizations is the original service Amazon created for this, while AWS Control Tower is a more recent offering. Examine AWS Organizations vs. Control Tower for multi-account management to determine the best fit for your enterprise.
AWS Organizations. While it is not feature-rich, AWS Organizations is reliable and simple to use. You can see all your sub-accounts and create new accounts -- but you cannot delete them directly from the service. It is also often used alongside AWS Single Sign-On (SSO), which provides access to multiple accounts. By integrating AWS SSO with AWS Organizations, you don't have to juggle multiple sets of credentials.
If you use AWS Organizations, make the primary account email for each account one that shares a common root, so you have centralized control. For example, if you use an email service like Gmail that ignores everything after a plus symbol in an email address, you can use the same primary email address for every account.
So, if you put your main account under "[email protected]," then you might put your staging environment account as "[email protected]." This makes it easier for you to access and delete accounts later. If, instead, you use various different email addresses that you don't control when you set up these accounts, it will be difficult to contain costs and manage the sub-accounts.
AWS Organizations is a better option if you:
- already have a number of different accounts;
- don't anticipate making more than 50 or so accounts;
- only do software development with infrastructure as code; or
- trust AWS account holders and don't want to do a lot of policing.
AWS Control Tower. Unlike AWS Organizations, Control Tower can initialize new AWS accounts with preset infrastructure. Admins can use this feature to monitor sub-accounts more closely, applying a level of policy management and summary information.
The downside to Control Tower is that it doesn't have a lot of flexibility after accounts are provisioned. It assumes that the access and sign-on practices put in place when you initially set it up won't change. However, this approach doesn't line up with how AWS SSO works. It also doesn't comport with the strategies of most enterprises, which regularly tweak how they think about permissions, especially within AWS.
If you want to use Control Tower, but don't want to use AWS SSO, you can opt for Active Directory Federation Services (ADFS) instead. To do this, use AWS SSO to get into a new account and configure ADFS. Then, disable the SSO user's access through an AWS service control policy.
AWS Control Tower is a good fit if you:
- plan to impose a lot of restrictions on every sub-account;
- don't need to do a lot of differentiated or complicated provisioning in different accounts; and
- you're willing to submit to the Control Tower view of AWS SSO.
Software development and automation benefits
Multiple accounts help organizations run a more effective software development lifecycle and promotes greater automation in those environments.
When every developer has their own account, other developers can't block them. This can save thousands of dollars per hour of developer salary that would otherwise be wasted waiting while an environment is fixed. This works best in serverless architectures where resources are primarily pay-per-use, but it can also work with cheaper resources in other architectures.
Additionally, if you put every developer and every environment in its own account, you'll be forced to implement infrastructure as code to bring new developers and environments up quickly -- and to keep everyone in sync with the same setup.
It's possible to keep infrastructure deployment manual if you only have a small number of development, staging and production environments. But it's impossible to have manual processes if you support tens or hundreds of developers, each in their own account. Properly setup infrastructure as code creates consistent, uniform configurations for each developer and environment, which significantly improves developer productivity.
Manage the costs of multiple AWS accounts
One of the biggest challenges in cloud cost reduction is understanding who -- if anyone -- is using particular resources, and for what reason. Tags can be useful in this type of identification, but it's not easy to implement effective tagging for both security and billing purposes, and most organizations don't do either well. This is where multiple accounts can help.
When you run multiple AWS accounts, you need a method to monitor cloud costs, especially so you can quickly identify significant spending changes. One option is to use a third-party tool like CloudZero, which notifies organizations about changes that happen in spending within and across accounts.
For example, let's say someone spins up an Amazon EC2 instance in an account. That instance typically costs $100 a month, but suddenly it accrues $50 in charges in a single day. The IT team receives a notification and can identify which service it is, and which account that service is in.
Whichever way you choose to get notifications, maintain visibility into cost changes as you expand your account footprint.
Another area that can create additional costs is accounts that are no longer used. While the account is inactive, it still incurs charges. However, deleting accounts is a challenge.
AWS wants enterprises to orphan the account and then delete it from inside, which helps reduce the risk of accidently deleting the wrong account. However, this is a complex process. It's easier to reuse accounts than delete them, but don't do this. A big benefit of using multiple accounts is the ability to wipe them out entirely to ensure they don't accrue charges.
Deleting an account is not a simple one-click process, so it's best to reserve time for it. Allocate a day every month or every quarter to delete accounts.
Before you make any deletions, back up any resources or data you need. Also, keep in mind that resources are not automatically terminated when the account is deleted. Double check your cloud bill to see if the resources associated with the account will be used by other accounts. Once the account is terminated, you have three days to sign back in to ensure it is not incurring additional charges.
