When to consider a multi-account architecture?

This is post 4 of 9 in a multi-part series (hosted here) discussing the advantages, pitfalls, deployment methodology, and management of a multi-cloud account architecture. For this series, we are focusing strictly on using AWS as the Cloud Service Provider (CSP) but the concepts discussed port well to any provider or even to on-premise operations.

This all seems crazy

So why even consider all the effort to implement a multi-account architecture in the first place?

In short… Because AWS said so.

Initially, when I heard this and learned about the release of AWS Organizations in 2018 and the subsequent release of AWS Control Tower in 2019, I just kept thinking that this is all just a way for AWS to make more money. Waaayy more money.

While it may be true that AWS does benefit financially from selling this mindset, in just the relatively short amount of time I’ve been doing enterprise cloud architecture I’ve come to learn that all of these new services are released for the benefit of the customer. What isn’t seen on the backend is all the planning and road-mapping for the ability to use some of the amazing features of the cloud, that in order to do so requires multiple accounts.

Leveraging a multi-account configuration has many benefits. Some of which we don’t even realize currently. As customers request the ability to do something else within their environments, new features will be released that lean heavily into a well-configured multi-account architecture.

What’s the strategy

There are many different reasons why a small business or large organization would want to and should implement a multi-account architecture similar to what I shared on the previous post. Here are just a few reasons but there could be many more based on your organization. One business case I won’t discuss in detail is acquisition potential or sell-off.

Landing Zones / Control Tower

As I stated right away, AWS says to do it. It’s really that simple. If you want to be able to be nimble and leverage all the great new features that AWS releases weekly, you really need to stay up on the best practices they put out. Those are put out for a reason and that reason is they know the direction they are taking all of their new services. It’s best to keep up.

Not only does segmenting your resources into different accounts provide the benefits of the points I will speak of next, but it also makes your life much easier to adapt to the rapid rate of change that being in the cloud exposes you to. Implementing new and beneficial features doesn’t have to always include a massive overhaul. You can use a phased approach.

Shared Services

The ability to more easily (and securely) share AWS services requires the AWS Organizational structure. When you start to leverage shared services, you have the ability to reuse work already done. You can even broker services to other departments within your organization without having to reinvent the process every time.

Shared services allow for better management by the responsible parties by centralizing access to a single account. This prevents the ability for someone to inadvertently cause much more harm than intended while bouncing around in the Console or using the Command-Line.

Security

It should be obvious by now that using multiple accounts significantly increases your security posture. As stated in the previous post, creating a security account allows for auditing best practices and preserving log integrity.

Having multiple accounts enables granular access restrictions. It helps prevent accidental access to protected resources. Developers should not be able to make changes or see instances that control enterprise services. Sure, IAM permissions can be configured to prevent accidental termination for instance, but why even bother having Domain Controllers intermingled with development instances if you don’t have to.

Billing

Early on in the cloud, tagging was really important if you wanted to separate out the cost for different functions or services. Tagging itself has evolved greatly over time but was never the most reliable way of breaking out the cost for reimbursement. If you wanted to know your total storage cost for your production application, you still had to somehow tag buckets used for the application to distinguish between storage consumed as related to an application vs. storage utilized operationally.

Utilizing different accounts within an organizational structure not only gives you the opportunity to have a better understanding of what your production application storage costs are, but you can further implement tagging within the account specific to the production release of your application to provide more context.

If you have multiple projects or divisions within your organization sharing compute or other resources within a single account, it becomes a mess very quickly if from a budgeting standpoint your IT department needs to recoupe operating costs from the HR and Accounting departments. If each department had its own account, this happens inherently further allowing each department to more easily tag their own resources if they wanted to provide more granular detail on their cloud expenses. Again, sharing resources and VPCs makes configuring department-specific accounts a breeze.

Isolation

Separating resources based off of organizational responsibility for billing purposes is one thing, but how about making sure the Sales team resources aren’t bumping into or gaining access to the Marketing team resources. One of the biggest caveats to accessing cloud resources is it is very easy to elevate your own access or find ways to access resources you should never have had access to. Understanding and managing IAM permissions (Policies, Roles, and Profiles) at a large scale is difficult. Everywhere you look in a policy you could find methods that provide some way privilege escalation.

Breaking resources out into their own accounts not only created added safeguards from and access standpoint, but it also creates a barrier to the creation of resources that should never have been launched and more importantly creates a barrier for accidentally running destructive operations across all account resources of a specific type. You’ve significantly reduced your blast radius for destructive operations. You may lose an entire departments resources at once but should never take down the whole organization.

Recovery

Last but not least in this our list of reasons why multi-account architecture is a good idea is recovery. Related to isolation, the recovery component means that when something goes awry in your organization, you should very easily be able to diagnose what went wrong. May the tech gods have mercy on the soul of someone who negligently terminated every EC2 instance in an account but at least it was only the one account. With other protections and proper configuration in place, that should never be able to happen. But what could happen is the bulk misconfiguration of some Security Groups, or the modification of an Instance Profile, that instead of affecting instances across all departments sharing the same account, only affected a single department and the rest of the teams may not even notice an issue.

If there is something askew with network access for all departments regarding your cloud architecture, there are only really two possible causes:

1. Your on-prem configuration to the cloud has been misconfigured and completely unrelated to your configuration and virtually unpreventable.
2. Someone that had access to your shared services account for Networking made a misconfiguration. Human error can happen.

If you notice that all resources within the Sale and Marketing teams seem to be working just fine and the only team having a problem is Accounting, then you have a good basis to believe you need to start investigating changes to the environment made in their account or to their specific systems. You should be able to immediately narrow down who had the access to make a particular service disruption change, in a specific segment of your architecture, and most importantly when.

If all your resources are shared in a single or only a few shared accounts, anyone at any time in the recent history could have made a change with no expectation it would have had the fallout that it did.

Not so crazy after all

You can see here with just these six reasons that the effort to get a well-architected multi-account configuration could save you boatloads of time in the future — in troubleshooting and outages alone.

All of these reasons relate primarily back to one key theme – security. AWS has many resources that can help you in the implementation, the structure, and the strategy for multiple account configuration. I encourage you to review the AWS Multi-Account Security Strategy to learn more and of course, continue reading on in this series.

Series parts are as follows:

1. Series Introduction
2. My experience with Multi-Account Architecture
3. What does the end-state look like
4. Reasons you might consider multi-account architecture
5. When it is right to implement
6. What the potential architecture might look like
7. How do you get there
8. How do you support and maintain the architecture
9. Lessons learned