What a multi-account architecture might look like

This is post 6 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.

Choose your own adventure

There’s really no ‘one-size-fits-all’ solution when it comes to deploying accounts within your organizational structure. In our previous post about ‘end-state’, we discuss very briefly a few different types of accounts you’d want to include in your architecture and why they might be beneficial. We also shared this diagram:

In this diagram, we show at the top a pretty standard foundation for managing a cloud architecture of any size that should support nearly any scale.

The AWS Organizations structure works by implementing inheritance through the use of containers called Organizational Units. These containers can be nested and used to organize different accounts based on an infinite configuration scheme that best suits your needs. Once the management structure is determined, the organization of sub-accounts can take place.

At the top

In our ‘End-State’ post, we already discussed the key foundational accounts recommended for creating a robust MAA. The number of those types of accounts and for what service they provide should be determined by organizational needs and available resources. There can be a fine line between logical separation of services and total chaos.

At the very least you have your AWS Organizations account that is used to spawn subsequent accounts. In a later series or individual post, we will share how this process takes place. It is in this account you enable the sharing of other AWS Services across all accounts linked in the Organization. This is an important component.

Alongside your Organization account, an architecture should at the very least have a single account for security and enterprise services as well as an account for shared resources.

However ya wanna slice it

Once you’ve established the Root Organizations account and any other management accounts, you can begin placing the accounts into Organizational Units (OU) or ‘functionality buckets.’

These buckets allow you to apply the maximum level of permissions as well as available AWS Services allowed to be used in each account. Controlling the permissions allowed in an account is done through the use of Service Control Policies (SCPs). Too much to cover here; however, these policies allow you to completely disable services in all accounts within the OU they are placed.

One especially beneficial use-case for SCPs is implementing available services within AWS GovCloud Regions. For example, when working with the DOD and their Cloud Computing Security Requirments, you will learn that different AWS services are allowed for different information types or ‘Impact Levels’. However, there a not different types of AWS GovCloud account to accommodate the different impact levels. All services regardless of their accreditation for use are enabled in the GovCloud Regions. You can use OUs and SCP to disable the use of services that have not been vetted for use within a specific impact level. This will prevent even administrators from inadvertently leveraging a service within an environment that it has not been accredited for.

Below is an example of an Organizational Hierarchy for such a situation. Within our testing organization, we have 6 AWS accounts: Orgs/Master, Dev, Prod, Security, Management, and Release.

Prod and Release are in a higher impact level OU, while Dev, is in the lower to enable R&D. The Orchestration Accounts can be excluded from either to enable the use of shared services.

Be logical

The following images are taken directly from a presentation we’ve given on creating and managing via code a multi-account architecture. You can use them to spark ideas on the best way to structure your account hierarchy.

It is important to note that the shaded and unshaded boxes do not need to denote an actual Account or an OU. Depending on the situation, they could both be OUs where the lowest level OU contents all the accounts for that category or service.

Project

A sub OU structure can be created to organize all projects into their own Organizational Units where the first OU is the for the whole project, and all accounts can fall under that single OU, or additional sub-OUs can be containers for like account types.

Billing

Each initial level OU in your structure could be for all accounts that are related to the same cost-center or source of funding. Many organizations have different ‘colors of money’ where lumping like accounts into the same OU structure could enable the disabling of services. For now, you must still use tags to allocate the cost of all services across all accounts in a structure like this, but expect AWS to enhance AWS Organizations to accommodate more granular billing views in the future.

Isolation

If you’ve properly configured your networking and other application-wide services within shared services accounts, it might be logical to completely break out your OU structure to tier specific roles. Not only can you segregate database admins from the developers and their services, but you can also completely disable services that have nothing to do with hosting data from consuming cost in the respective accounts.

Failover & High-availability

This is a concept that we have not personally tested but it seems like, in the right circumstance, it could prove to be very beneficial. There are many different ways to implement blue/green or virtually zero down-time deployments in the cloud. One solution could be to dedicate full accounts to releases of your application or service.

This solution provides many benefits. Depending on your release cycle and how long a release is live, you could have unique billing information for every release. This would give you the ability to more easily see if new changes to your infrastructure, scaling, and/or code reduced the cost of resources or increased.

This solution also more easily gives you the ability to give weighted access to the new release for a small percentage of customers and increase over time. Since nothing at all should have changed in a completely separate account with regards to the development and deployment of new code, you can very easily revert back to the old release if something starts going wrong.

You get to decide

As you can see, there is virtually an infinite number of accounts and OU configurations with regard to the hierarchy of your multi-account architecture. Each business case could serve different needs.

The benefit of this flexibility increases the manageability and scalability of whatever solution you are working to deploy. However, you logically decide to layout your accounts doesn’t have to be concrete either. This can evolve over time. With the proper configuration of shared services, it may even be possible to introduce accounts or services from entirely different organizational structures. But that’s enough to cover for one post.

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