Multi-Account End-State

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

Looks more complicated than it is

If you’ve been in the cloud game for a while (say since 2015) and have all your resources crammed into a single account (or a couple), considering the following diagram in your road map could cause you to lose sleep.

Diagram 1: Example of a large multi-account configuration

If you’re just now considering moving your operations to the cloud or are basically just starting operations and want to be 100% cloud, this diagram may give you pause. You may think it will be more complicated than you expected. You don’t have the manpower to support this.

First, you may be right.

Second, it doesn’t actually need to be this crazy.

What you are supposed to get out of this diagram is multi-account architecture is flexible and scaleable. Depending on where you are currently, multi-account could me two accounts or twenty. Leverage this diagram to use your imagination and think of the different ways you would want your organization’s hierarchy to look. Because that is what this is — a hierarchy of accounts and inheritance of resources very similar to an active directory structure.

What is this mess?

I’ll only briefly explain the components of this diagram here as we will get into considerable more detail in future posts. Having this basic understanding will hopefully aid in generating thoughts of how you could best implement (or change) your multi-account architecture going forward.

AWS Organizations

‘Orgs’ is at the center of all of this. With AWS Organizations you can centrally manage billing, compliance, and control services used in all other sub-accounts. Without the use of Orgs, you will run into some issues with the ability to share resources (i.e. Networking) from one account into the others. Orgs allows you to deploy and organize new accounts into a logical structure (Organisational Units or OUs) that works for your business so that you can control access to different AWS services as well as enhance security across all your accounts. You can learn more about AWS Organizations here.

Administration & Orchestration

This is your management tier for AWS accounts. As an organization, it is up to you to decide when a service, function, or responsibility requires a new account. You can have as few or as many accounts as you wish. At the OU level, you can then control which services should(n’t) be used within those accounts.

For example, one account could host all your enterprise Active Directory, Exchange, Roaming Profile configuration, and security policy. Having a separate account for these solutions will allow you to provide more granular access to the administrators of these services and at the OU level, you can prevent your Windows Systems Admins from accessing anything related to AWS IoT services for example. Because why would they need that?

Other accounts here could be for aggregating all security logs from all other accounts for archive purposes as well as the integrity of the logs. In the same account or a separate account, you could give your security team access to run and deploy all the tools they need to keep your network infrastructure and operating systems safe and secure.

Shared Services

These are the account(s) that will manage any AWS services that you want to share across the rest of your environment. One major change in 2018 was the ability to share AWS VPCs (subnets) across accounts. This feature allowed the pooling of IP Space that can then be delegated to an entire environment without needing to be explicitly assigned upfront, and therefore difficult to move around and reuse for future projects.

Managing your organization’s DNS at a central point will ensure developers and other system admins can get the benefit of using the cloud but are not making changes to critical services without going through the proper channels and processes.

Another possible option is a consolidated storage account for resources that are statically shared across your organization or divisions within it. The storage account can have all copies of the software, user data, etc. that is needed and within that account, replication can be configured for disaster recovery and all storage billing can be accounted for within a single account.

Scale indefinitely

Once your configuration of Administration and Shared Services accounts is complete, you’re done laying the foundation. Now you can have a virtually limitless number of sub-accounts that can be used for different projects, divisions, or applications within your organization. These accounts can be deployed or tore down at will and linked within the AWS architecture where required to inherit the appropriate service controls and shared services desired.

You now have the ability to layout the architecture at this point however you’d like. We’ll further discuss some of the potential configurations in a later post. Just keep all these details in mind as you go forward.

Pros & Cons

Regardless of what you feel when looking at that very busy picture, there are pros and cons to each situation which I will briefly address here:

Just starting

If you’re not in the cloud yet, lucky you. You have a slight edge over any organization that already has workloads off-site. AWS Organizations is somewhat more ‘organizable’ from a blank slate. You get to learn everything from scratch and get this right from the beginning (also a con).

• PROS
  • minimize rework of permissions configuration
  • aggregate and archive logging appropriately
  • store and organize resources properly
• CONS
  • slow-moving
  • steep learning curve
  • analysis paralysis – will you ever land on a design?

Already cooking

Rather you’ve been in the cloud for one year or ten, you are going to face some challenges as you begin to examine what a ‘true’ multi-account configuration will look like. There are more positives than negatives. It’s just that your negatives could have some serious impact if not accounted for in transition.

• PROS
  • you may already know the ideal design based on lessons learned to-date
  • you can address your backlog of rework in this transition
  • leverage newly available services not easily refactored into your existing configuration
• CONS
  • permissions and Service Control Policies (SCPs) inherited from your new Orgs configuration
  • may need to consider new billing process
  • won’t notice any benefit from the labor until much later in the process

Still worth it?

Some of these pros and cons will be better addressed in future posts of this series. Additional considerations regarding the logical structuring of your organizational configuration will also be shared as we go forward.

Either situation you are in, the reality is, in the long term a multi-account configuration will set you up better for success. You will have less to worry about with tagging of resources, making sure your developers aren’t messing up already approved configurations, and proper billing/forecasting of your production costs over your R&D costs.

In a well-thought-out multi-account architecture, what you know you need running can be placed in a safe space while anything that isn’t business-critical becomes ephemeral and you can cut-bait at any time to start fresh.

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