I’ve worked with several small businesses that seem to survive using a single AWS account. Just to be clear, an “account” in this context is not a user account, but a complete AWS tenant with all the services and regions at its disposal. If you’re not familiar with what a multi-account setup looks like, here’s a quick, simple breakdown.
What is a Multi-Account Setup?
A multi-account setup is several accounts under one master account. All the billing rolls up to the master account. The master account can act as an authentication point to gain role-based access to the child accounts, and you can organize the child accounts into a structure with different rules for what can exist in those accounts and how much access each user can have. You can also track costs by account which can help you easily break out your production vs non-production costs, for example.
If this sounds like too much unnecessary “enterprise-level” complexity, I offer up the following benefits that I’ve personally realized from having multiple accounts.
- I can separate production from non-production. That means I can give developers access to the development account without worrying they might do something to impact production. This goes for your administrators as well. There is comfort in knowing you’ve signed into the test AWS account and can’t break production.
- Depending on what you’re building or hosting, there’s inevitably that client that comes with a list of compliance demands before they’ll sign on with you. I see this becoming more commonplace and not just for financial systems or systems with personal information. Corporations want assurance your SaaS service is trustworthy and secure. If an accounting application can be moved into a dedicate AWS account, you’ll have a smaller footprint for an IT controls auditor to scrutinize. You could also dedicate an account to that customer, isolating them from everything else going on in your AWS environments.
- Ideally, we’ve reached an era where customer data is securely separated and we can provide them API access to their data when required. Unfortunately, we’re still dealing with some pretty old systems out there and your client might want direct database access for reporting or an integration. This is another instance where carving that client off to their own AWS account makes things easier. Then you can establish a VPN or whatever connectivity is required into that account without worrying you’ll expose your other client’s data.
- If an AWS account is breached, there is less for an attacker to gain access to (provided your master account isn’t compromised).
- You can setup guardrails to limit services and other operations in groups of accounts from the master account. These are known as SCPs or Service Control Policies and they can’t be overridden in a child account, even by an administrator.
- All billing rolls up to the master account. One place to pay for everything and the Cost Explorer can help you track costs across all your accounts. Nice!
- You can setup CloudTrail across all your accounts and centralize the logs. Then you can create metric alarms against those logs to monitor for things like root account usage in any account, authorization failures, expensive EC2 instance usage, etc. You should have this even in a single-account environment. You’ll sleep better knowing this in place.
- My personal favourite, you get your own sign-in page where you can quickly get temporary credentials to do bits of command-line work. These are time-bombed credentials in the form of environment variables that you can copy and paste into your terminal to use with the AWS CLI, Python boto3-based scripts, etc. No more saving IAM programmatic keys on your computer. I don’t know why AWS hasn’t made this available in the console for single-account setups.
And now for the drawbacks. It’s not all gold.
- Unless you have an extremely expensive support agreement with AWS, you’ll need to pay for support in each individual account. This adds up to much more than you’d pay in the single-account model. You can work around this by paying for a higher level of support in production and lower level in dev, for example. If you have a problem in test and you don’t have support there, try to reproduce the issue in dev and open a support ticket from there instead.
- As you grow, your needs will change. Suddenly, having a general “production” account is too broad and doesn’t meet the needs of one or more applications. You might be looking at a potentially complex migration. It’s worth it to really think through your structure before implementing.
- If you’re relatively new to AWS, the complexity can be high. Out of the box, the multi-account setup (AWS Organizations) includes some accounts you might not be familiar with like the audit and log archive accounts, so there’s another learning curve.
I hope this gives you some things to think about. It can be a challenging decision to move to a multi-account configuration. If you need help, you can always reach out. Thanks for reading!
Mike
Mike Shareski is the founder of RefactorIT and holds an AWS Solutions Architect Professional certification.