Please note that this post, first published over a year ago, may now be out of date.
In the last few years we’ve reviewed around 400 AWS architectures, and one thing we still find from time to time is customers running a single AWS account containing all their development and staging environments alongside their production workload.
This seems like an intuitive decision to make: creating a new account is a bit of a faff, you have to verify an email address and phone contact details, and register a payment card. It’s convenient to have everything under one login - but making this choice introduces unnecessary risk.
All your eggs. In this one basket. It’s a metaphor. (Photo by Natalie Rhea on Unsplash)
Today’s best practices, documented by the AWS Well-Architected framework recommend organising workloads across separate accounts. Let’s explore why.
Blast Radius Reduction
We’ve all been there: that sinking feeling when you realise you’ve just run a destructive command against entirely the wrong set of resources.
As your developers are building things, it’s pretty likely they’ll be building and destroying resources multiple times a day as they figure out what the solution will ultimately look like. This is the sort of activity you’ll want to keep well away from your production workloads in order to reduce the risk of disrupting availability for your customers.
Running production workloads in their own accounts is the safest way to avoid this sort of embarrassing accident.
Developer Productivity
Teams who share development accounts between individuals are forever worried about stepping on each others toes. This either leads to inaction, or time consuming discussion about who owns that resource, ultimately slowing down the rate at which they can innovate and deliver value.
Once you’re comfortable with creating new accounts, it becomes easy to provide one or more accounts per developer, for them to use as their own dedicated sandbox.
Least Privilege Access
In highly regulated industries such as financial services and healthcare, it’s important to be able to demonstrate that your customer data is kept safe and secure, away from individuals who shouldn’t have access to it.
Placing production data in its own AWS accounts and then only providing access to those accounts for those users who have a legitimate business need to log into them is a great way to demonstrate your security posture to auditors.
This doesn’t just apply to customer data: if you have a separate account for collecting security logs, where nobody has permission to modify or delete these logs, you can prove that this important audit trail can’t be tampered with.
Using Service Control Policies, you can even restrict what the root user of each account can do. For example, even a developer with full admin rights to their own sandbox account can be prevented from deleting the very important IT Audit role from that account.
Avoiding Service Limits
It’s tempting to think of the cloud as providing unlimited resources, but the reality is of course a little different. A new AWS account comes with a number of service limits, designed to protect you from accidentally running up huge bills.
Some limits are soft limits, and can be changed. For example, the total number email messages you can send via the Amazon Simple Email Service (SES) is initially limited to 200. You can have that raised by opening a support ticket and justifying your use case.
Some limits are hard limits, and can’t be increased in a single account however justifiable your request. For example, in the world of AWS Lambda, you’re limited to 100 requests per second against the GetFunction API call. If you have large development teams all using one of the serverless frameworks in their CI tooling, you’ll hit that limit pretty often.
Separating out a workload into its own account allows it to use that whole limit itself. In the CI case above, perhaps you’d provide a production AWS account per team, or per product line, in order to avoid those limits.
Additionally, using tools like Amazon CloudWatch, Amazon GuardDuty, and Amazon Detective can be easier when you can easily disregard noise from non-production accounts and focus on what’s really important. Your developers will be glad not to have to receive alarms for issues with no customer impact.
Simple Cost Attribution
Billing on AWS is a pretty complex affair, which is why there’s a whole “Cloud Economics” industry built alongside it. If you don’t want to get into the complexity of setting and enforcing resource tagging policies in order to report on usage, separating workloads into their own AWS accounts is a really simple way to attribute costs.
You might choose to create accounts per department, or per product line. The total spend for the account will then be clearly attributable to that department or product.
If cost is a concern, you could consider shutting down development resources outside of typical office hours. This could potentially save up to 70% of the running costs of these accounts, and is way easier to automate when you can be sure your scripts won’t also accidentally shut down production resources.
SaaS Tenant Isolation
If you’re building a SaaS platform, you’ll need to give consideration to which SaaS tenancy model you’ll adopt.
One way to separate tenants’ data from one another is to deploy resources for each tenant into their own AWS accounts. This provides the reassurance your customers need that their data is isolated, and makes per-tenant cost attribution easy to achieve.
Multiple Account Management with AWS Control Tower
The more AWS accounts you need to deploy, the greater the management overhead. If you don’t have a good way to centrally manage and maintain your accounts, this will quickly become a time sink for your team. Luckily there’s an AWS native solution for this: AWS Control Tower.
This service allows you to automate the creation of new AWS accounts using blueprints you create to meet the requirements of your business. These blueprints set up access for your teams, and apply configuration guardrails to protect your data and your wallet, as well as setting up backups and security monitoring which can all be managed centrally.
Getting AWS Control Tower set up is something most companies will only ever need to do once, and it can be tricky to get right first time. With our years of experience working with SaaS customers, we can help you build a solution that’s right for your business, taking into account your tenancy model and your compliance requirements.
Like the sound of all that but want some expert help implementing Control Tower in your AWS estate? Our SaaS Foundations package includes a bespoke Control Tower design and installation by our experienced AWS consultants for a simple fixed price.
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.
