Written by Joern Barthel
Originally published on March 17th 2021
A short introduction into the reasoning behind AWS multi-account strategies
Choice typically overwhelms our customers when they embark on their AWS journey. Hundreds of services provide application services, deployment interfaces, full-blown solutions and various other building blocks. And at the same time, a parallel ecosystem of distributed best practices further blurs the big picture.
It’s no wonder that our customers - especially when they start with a really small bill of monthly recurring revenue on AWS - are confused when we recommend a multi account strategy to them even in the very beginning of their cloud journey. Why invest in additional configuration and management efforts? What’s the benefit?
In order to begin to quantify these benefits, we need to talk about two major topics on AWS: billing and policies.
Cost attribution
Billing is an extremely complicated part of AWS. It can be viewed from multiple angles, such as an architectural feature, continuous optimization processes, re-billing problems and many others. In fact, the subject is so complex that part of our own consulting practices is dedicated to it, and one of the reasons why movements such as FinOps exist!
But the one point that gets lost in this big picture is that the easiest way to get an understanding of what you spend money on is by splitting workloads, environments and shared services into distinct AWS accounts. In that case you don’t even need to understand the cost explorer, cost and usage reports or introduce third party billing tools. You just need to ask your finance department to process PDF invoices by linked member accounts.
This simplicity can be a great time saver in smaller organizations, especially when they are providing multi-tenant services.
Least privilege for humans
Policies are a set of topics in AWS that provide permission systems to principals performing actions against AWS APIs. Policies are hard to get right, but get the job done when describing what least-privilege access a machine actor (such as a Lambda function) should have. Giving human operators the freedom to do their work, but only in a bounding box such as a workload or an environment (or both) however, is very hard to do.
Without going into too much detail, policies are simply too deep a topic to be easily checked visually for correctness in such situations. The effective permissions being applied to a principal are a result of a complex evaluation logic; a set of overlapping policies on multiple levels (like identity policies, session policies, resource policies with specific caveats to their behavior such as cross-account situations and KMS key policies, service control policies and permission boundaries) and late-binding variables on policy conditions.
The alternative is giving very broad permissions but scope them to highly specific AWS accounts. In this scenario one could give Alice full access to workload “foo” in environment “staging” by making her a member in the AWS Single Sign-On group “foo-staging” that provides administrative access to the AWS account “foo-staging.” This has the same effect as creating very long and complex policies to express the same intent in one, shared AWS account. It is however much easier to verify.
This implies that if you ever want to implement least-privilege or some separation of duties for human operators in your accounts, you’ll be strictly better off with a multi-account strategy from the beginning.
Supporting future growth
Since AWS accounts without workloads running in them cost nothing per se, introducing a multi-account strategy from the beginning is a net-win for an organization, regardless of its size and spend. On the other hand, deferring this decision can lead to unfortunate outcomes such as having to spend time and money on internal migration efforts.
Additionally, as organizations begin to mature, one of the many challenges is keeping development and deployment velocity high. One way to archive this is by keeping workload teams as independent from each other as possible. Multi-account strategies enable these patterns naturally by providing clear technical boundaries: workload teams can do “their” thing in the confines of specific AWS accounts limited only by policies, which enforce aspects that are relevant for the organization as a whole (such as network configurations, domain names, tagging strategies etc.).
By providing these guardrail policies as infrastructure as code, a central platform team that “owns” these guardrails can easily review change requests to these guardrails and provide quick remediations through continuous integration and deployment mechanisms.
Getting started
Fortunately, getting started with a multi-account strategy nowadays has never been easier. In fact, it is so easy that it does not even require external consultants.
Together with our friends from superluminar GmbH, we‘ve created an official AWS QuickStart and Open-Source project that provides a modern AWS Control Tower Landing Zone with a lot of useful foundational services enabled. Its installation takes currently about 90 minutes of mostly unsupervised working time and costs less than 10 USD / month in AWS material.
Please have a look at our introductory blog post for superwerker or talk to us directly via the contact form below. We’re here and happy to help!
Cover Photo by Denys Nevozhai on Unsplash
Top comments (0)