Multiple Cloud Account Architecture (Series)

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

First, some context

Imagine you have just joined an organization, are a few months into getting to know the project, but still not totally comfortable with the day-to-day ops. Also, imagine that this is really your first foray into a large-scale enterprise cloud operation. You’ve had cloud experience in the past but nothing like what you are about to be asked to do.

Because you are a part of a pretty small program already, you are charged with the operation and support of the enterprise cloud. You are now the ‘OPS Team Lead’ (a team of 3) and are responsible for supporting roughly a dozen AWS accounts and two-dozen developers building applications across those accounts. Now you’ve been asked to figure out how to scale to ‘literally hundreds’ of accounts and support them, with a ridiculously in-proportionate amount of team members.

Mind you it’s early 2017. Cloud is not new by any means but ‘AWS Organizations’ was literally just released. True multi-account strategy has just now started being discussed and considered at AWS’s premier annual conference, re:Invent, a couple of months prior. To date, it was possible to have multiple AWS accounts, and managing them wasn’t a total nightmare but did take some creative processes.

From this point on, when I speak of operating, managing, and supporting multiple AWS accounts, we mean:

• Managing networking and resources – VPCs, Subnets, Routes, Security Groups, ACLs, etc.

• Controlling the AWS services (and their actions) that CAN and SHOULD be used in the accounts

• Manage S3 bucket policies and ACLs

• Configure multi-account and cross-account access (Dev-to-Prod, Prod-to-Dev, Orchestration to Dev/Prod, etc)

• General end-user support, troubleshooting, and configuration

This is important because a lot of what you read going forward may (or not) cause you to scratch your head. Some of the problems solved, using these processes, aren’t problems at all. They are manufactured by the very process of controlling multiple accounts. That is an important distinction – ‘controlling.’ Depending on the organization, the information present, and the intellectual property involved, your organization may opt to lock down everything in your enterprise cloud. Controlling everything previously listed doesn’t 100% prevent security issues or breaches of data, but it significantly decreases the potential of inadvertent critical mistakes that could put your business on the front page of a tech blog, or worse yet, in front of Congress.

Hopefully, that sets the stage for the following posts in this series.

What this series covers

Now that we’ve laid the foundation for why any of what we are going to be going over matters, let’s briefly discuss the benefits of taking on all the additional work of configuring a multiple-account structure. Even if you are a very small organization, this application has significant benefits. Yes, it feels like a lot of work upfront but we promise it is worth it in the long run. We’ll even cover some processes and systems to make managing all of these a little less burdensome.

Benefits of multi-account architecture

At the time of writing this, It is now time for re:Invent 2019 so if you’ve been in the cloud game for a few years, none of these are new but first let’s list some of the benefits:

• Cost containment

• Enhanced security posture

• Eliminate rouge resources

• More manageable and controlled change

• Isolation of critical services

• Maintainability of a baseline configuration

• Implementation of least privilege

• Better documented (more easily understood) architecture

Pitfalls and complications of multi-account architecture

Benefits never come without costs. That should be obvious in enterprise I.T. by now. One of the costs might actually be… costs. The initial work and effort to put into refactoring your architecture will cost time in human capital. If you are fortunate to just now be considering the cloud, you can sneak past this added cost. You will, however, pay the Cloud Service Provider (CSP) for using some services in more than one location. That is inevitable. What you have to realize that there will be economies of scale. You will recoupe that cost operationally later. You just might not be able to see it now.

There are other obvious costs:

• the added complexity of initial configuration

• potentially a steep learning curve

• the perspective of virtually no noticeable progress near-term

• rework

Moving On

There is so much more to all of this than these few bullets. We make no promises that we can convince you this is how you should spend your next 6 months to 3 years in the cloud. However, in the next parts of this series, we will attempt to make a compelling argument as well as share some complimenting resources to help you make this transition (or advance your current position) much more palatable.

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