AWS Multi-Account Management Has Come of Age
Recent announcements mark a tipping point for AWS support of multi-account organizations.
Ah the good ol’ days. If you’ve been around AWS for a while, do you want to reminisce with me about logging in as root (as standard practice), no VPCs, a max of 10 tags (and only for a few resource types)? Then to make things more fun, we did all of our work (dev/test/prod and multiple projects) in one or a very small number of accounts. Each account had a unique email address and bill, and somebody’s credit card (do they still work here?). Well, we’ve come a long way baby. All of these account management practices and limitations are fortunately relics of the past.
One practice that stuck around longer than it should have, was not using multiple accounts to better segregate and organize teams, environments, and workloads. Well, actually, while multi-account environments are now very common, there are still plenty of overloaded accounts from legacy environments and even freshly-minted AWS adopters. A major contributing factor that kept teams using too few accounts for too long, was that you do need some technology and automation help to manage even a small collection of accounts, let alone hundreds. Fortunately, there is now a significant ecosystem of third-party tool providers that help manage multiple accounts (for topics such as cross-account management of logs, costs, compliance, and so on) as well as a steady stream of feature enhancements and new service offerings from AWS.
Here are a few resources that more deeply explore the value of a multi-account strategy:
“Account separation” (a.k.a. a multi-account strategy) is the very first principle in my article Cloud Architecture Principles to Enable Team Empowerment.
A multi-account model was a prominent part of my AWS re:Invent 2017 talk “Automated Policy Enforcement for Real-time Operations, Security, and Compliance for Life Sciences (LFS305)”
A companion blog to the above talk Tips for an Enterprise Cloud Transformation to AWS.
It’s always hard to recognize an inflection point in real-time. This is even more true with AWS since change is continuous. However, reflecting on several announcements over the last week, I believe that AWS has now passed a tipping point such that a multi-account strategy (anywhere from a handful to many hundreds of accounts) can be, and in my opinion should be the norm.
I’d love to survey all of the resources to support multi-account strategies (such as AWS Organizations, Amazon Macie, Amazon GuardDuty, etc.), but for today, let’s just take a look at the recent and concurrent GA releases of AWS Control Tower, AWS Security Hub, and Service Quotas that convinced me that we’ve now passed the tipping point and multi-account support has now come of age.
Coupled with AWS Organizations (and other multi-account aware services), these three new services create a central and top-level vantage point from which you can configure, control, and observe important account-level aspects that span all of the accounts in your organization. As a result, you can feel confident and empowered to create as many accounts as you need and not worry (too much) that they will all be configured differently, that you’ll have untenable effort to manage them all, or that bad things will happen and you’ll never know. Sensibly applied (tools don’t stop you from misusing them to lock things down too much or too little), these tools can work together to give centralized functional teams (such as your cloud management team and/or your cyber security team) with the ability to carry out their responsibilities while still empowering individual project or product teams to be empowered to innovate and build solutions, within some defined boundaries.
AWS Control Tower
AWS Control Tower is a service that automates account creation and ensures that the new accounts are grouped and configured in a standard manner. After that, it establishes governance guardrails across all of your accounts to help to uniformly manage policy and maintain visibility across your collection of accounts. If you’ve ever been responsible for creating multiple accounts, you’ll appreciate the challenge of doing this manually and keeping all of your accounts in sync. Even if you maintain good documentation and some automation scripts, since the underlying console UIs and capabilities are constantly changing, documentation and automation for this process has traditionally been quite challenging to keep current. Frankly, years ago when AWS Organizations was announced, I had thought it would have solved this problem (it has limited account creation capabilities). However, in practice, AWS Organizations did not go far enough for account setup and was extremely limited for establishing cross-account guardrails. Coupling AWS Control Tower with AWS Organizations now fills many of the gaps and provides a powerful solution.
AWS Control Tower is best used for entirely new environments where you are not already using AWS Organizations. So, if you are just starting with AWS in a given organization, then I would absolutely start with AWS Control Tower. On the other hand, if you already have AWS Organizations set up, you won’t be able to use AWS Control Tower for accounts that are members of an existing organization. It’s possible to consider creating a new organization (and then in effect have two organizations and two consolidated billing accounts) and then over time dissociate accounts from your old organization and add them to the new organization. There are lots of caveats and considerations for doing this, so I’ll not explore that further today.
AWS Security Hub
AWS Security Hub provides a way to centrally aggregate, prioritize, and act on security events coming from all of your AWS accounts. Alerts are ingested from Amazon GuardDuty, Amazon Macie, Amazon Inspector, and about 30 partner solutions as well. This is another critical tool to make multi-account management practical. Before AWS Security Hub, you’d have to access each source in each account to assess your security status or use a third-party service/tool. Not having either a third-party solution or AWS Security Hub would mean that you would either not be able to use many accounts or would do so with your head in the sand (not a great security policy). Therefore, having AWS Security Hub as a standard AWS offering will be a significant enabler for broader use of multi-account environments.
Service Quotas
“Service Quotas is an AWS service that enables you to view and manage your quotas from a central location” (from What is Service Quotas). Quotas are what we all know as “limits.” AWS is working on renaming limits to quotas, but I suspect both terms will be in interchangeable use for a while. I include Service Quotas as a multi-account enablement service since one of its capabilities is that it integrates with AWS Organizations to allow batch setting of a pre-defined template of quotas for new accounts. As noted earlier, setting up all of the attributes in a new account can get complicated and time consuming quickly (and really not fun if you have, say, 500 accounts). One specific area that this applies to are limits (sorry quotas). In my experience with large numbers of accounts, we’ve been able to group them into account classes that have similar attributes. Typically, all accounts in a given class would need to be initialized with a common set of limits that we had determined would be needed. Since service limit changes required support tickets from the requesting account, this was a time-consuming process. Service Quotas should make this much easier and efficient to manage and will significantly help to ensure that accounts (of a given class) have consistently applied limits.
A note about third parties
I mentioned that there is an entire ecosystem of powerful third-party tools that help support various aspects of multi-account organizations. I’m hesitant to mention any of them without providing a broad and balanced survey. However, the landscape is vast, and I only have experience with a small subset, so I’m simply not qualified to provide such an overview. That said, and biased as it may be, I do have deep experience with Turbot, and since there is overlap with some of the AWS multi-account tools, I think that it would be helpful to share a few observations.
When I first started relying heavily on a multi-account model in 2015 (while I was running Engineering as well as Cloud at a large pharma), AWS had nearly no support for multi-account. To solve the guardrail compliance and visibility problem, we used Turbot to great success. Initial account creation and configuration was still a gap and the release of each of these new services fills an important need and complements Turbot’s offering quite well. Turbot is also one of the 30 vendors that can directly feed into AWS Security Hub. The fact that AWS Control Tower also provides guardrails is an area of partial overlap on paper, but Turbot provides about 100 times more predefined guardrails. It’s early still, but my initial take is that what AWS Control Tower provides will be enough to allow most organizations (small and large) to move to a multi-account model. There are still significant differences between what Turbot and other providers bring to the table, and larger organizations, especially those in regulated industries will want to supplement with one or more third-party tools.
Conclusion
Every organization should be embracing a multi-account model. I (and many others) have used this successfully in large enterprises (with many teams, solutions, and environments) as well much smaller endeavors such as my new startup (Cloud Pegboard). However, managing across multiple accounts does have challenges and requires automation to be successful. In the past, AWS was not quite there with suitable support for multiple accounts and this left us all to either shove too much into a small number of accounts, write our own tools (a distraction from the core business), or use third-party tools. Now with the general availability announcement of AWS Control Tower, AWS Security Hub, and Service Quotas (and building on the existing AWS Organizations), we’ve got a critical mass of multi-account support such that everyone from a small startup to a large enterprise should use a multi-account approach. There is still plenty of room for third-party solutions as AWS does not do everything, but AWS has now done a good job at ensuring we have access to the baseline table stakes required to enable small and large organizations to fully embrace a multi-account strategy.
Now if you’ll excuse me, I have to review 500,000 lines of code in a single main() function. I think that maybe I’ll refactor that now that I’m inspired by the benefits of modularization and encapsulation provided by AWS’s support for multi-account approaches.
AWS NY Summit
If you will be at the AWS NY Summit on July 11, I hope that you can check out my talk (“How a Startup Can Be Both Lean and Enterprise-Grade”) and say hi at the Startup Central stage.
About Cloud Pegboard
Cloud Pegboard helps AWS practitioners be highly effective and efficient even in the face of the tremendous complexity and rate of change of AWS services. We want to keep AWS fun and feel more like dancing in a sprinkler on a hot summer day and less like being blasted with a firehose. We make the AWS information you need amazingly easy to access, and with personalization features, we help you stay up to date on the AWS services and capabilities that are important to you and your specific projects.
Cloud Pegboard datasheets
A feature of Cloud Pegboard are the datasheets that we publish for each AWS service. A datasheet provides a comprehensive data source for everything there is to know about each service (including links to recent announcements and blogs for each). Since you need to register (at present, we are offering 2-year free registrations until we go GA in August) to access these datasheets, all links in the above article go directly to AWS pages and I’ve grouped all datasheets down here. Note that you can sign also up to follow notifications about changes to specific services via the Cloud Pegboard UI. This is particularly useful for new services that have a higher rate of change.
