How to accomplish a successful multi-account architecture

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

It’s all about the numbers

Once you’ve made it this far — you’ve laid a solid foundation with your organizational structure — it’s all about turning out ‘widgets.’ Widgets being new AWS accounts that is. What you’ve built up until now is just the starting point of your assembly line. Now you need to make it run like a fine-tuned system. From here on out, it shouldn’t matter if you are creating a new AWS account per week, month, quarter, or once per year. Your growth trajectory doesn’t matter with regards to the work up to this point. Again, you need a solid foundation to build off of, but the real work hasn’t even started yet. Once complete, 3 accounts or 100 accounts shouldn’t give any more or less heart-burn. That goes for Ops, Support, and Security teams.

Getting to the starting line

If you are coming at this from an already ‘well-established’ cloud environment, you might be thinking to yourself “how in the hell…” I don’t blame you. It can look like a really daunting task. It is. Unfortunately, a single blog post can’t help you that much.

If you have a clean slate and are just starting out, you are in a very good position. We will cover the steps for a successful MMA here, starting with your preexisting condition.

Somebody’s baby

No matter how you go about it, someone is likely to get their feelings hurt when you take on such an initiative of correcting your current state of affairs in your cloud architecture. The biggest thing to remember moving forward is — it got this way using the tools, services, talents, and knowledge available at the time. ‘Don’t throw the baby out with the bathwater.’

There is nothing wrong with how it is or how we got to where we are. It is just time to make some changes. Use this opportunity to learn and grow technically (whoever is going to die on the hill about not changing what they created because it is working). Not even a technologist with a crystal ball would have been able to predict the rapid rate of change and service offerings of any cloud provider. It’s pretty amazing you’ve done as well as you have.

If you are in this predicament, here are the abbreviated steps I recommend to get to a good starting point. It is important to realize that the following process will look very different for every organization. Use these steps as a guidepost for the direction you want to head and not as instruction etched in stone.

First, a gif to illustrate all the steps:

1. Take inventory of your current (legacy) architecture
   • The current number of accounts
   • Services represented in each account (AWS and Application Tiers)
2. Deploy a new account an promote it to the AWS Organization Master if you do not already have one
   • Create OUs for your desired structure
   • Enable inherited features/services you know you will use across all account
   • Prepare Billing alerts and quotas
   • Establish potential SCPs but do not deploy them over your OUs yet
3. Stand up your Orchestration and Administration tier
   • create a security account for a logging and security functionality
   • depending on your organization and needs, this may be multiple accounts
4. Deploy a research & development tier
   • If you are developing in a different VPC but in the same account, now is the time to stop
   • Create a sandbox (dirty) environment that has significantly more lax permissions for service so developers can freely test things without mucking up development
   • Dev/Test/QA, depending on the number of accounts you want to manage, should be a 99% replica of your production environment
5. Here there is a fork in the road.
   1. Establish a new production to be a clean slate.
   2. This allows dev to be more in line with the previous bullet.
   3. Hard to move enterprise tools/config can remain in place and move through attrition
   4. Begin pulling out all other administration and enterprise tooling from your existing production account
   5. Establish share/brokered services accounts
   6. Deploy authentication and networking in their own managed accounts
   7. This allows for better delegation and separation of responsibility as well as the ability to more easily leverage new services and features released in the future
6. By here you’ve determined where production is going to live
   • New account
   • legacy account cleaned out
   • Either way now is the opportunity to clean house and lockdown ingress/egress points. I know how hard this step can be, so if at all possible I recommend a clean environment for production
7. Transition your deployment of new releases to your new production environment
   • If you’ve taken this opportunity to establish new roots for production, it’s time to cut over. Leave behind your legacy setup for roll-back
   • If you’re living in your legacy production environment still, you’ve completed moving as much administration and enterprise resources as possible out of this account
8. Terminate legacy or wash – rinse – repeat.

That’s it. You’ve done it!

Well, most of it. We haven’t talked about how to deploy all the additional accounts you might want going forward.

If fact, some of that information could be very beneficial back around Step 3. Luckily for you, we’ll try to cover that in the next post.

Clean slate

If you’re just starting out, you don’t actually get to jump all the way down here. You need to go back and review what life could be like if you don’t properly organize from the get-go.

You see, you have a lot of benefits in being a little tardy to the party. But don’t count your chickens before they hatch. Hindsight is 20/20. Coming into this clean means you don’t know what you don’t know. You don’t have the ability to know how you would have done things differently until after you’ve already deployed a solution.

The upside is with the solid foundation established upfront, ‘back to the beginning’ can be as simple as hitting the delete key.

Just because you have a clean canvas for your architecture doesn’t mean you won’t still find yourself pinned in a corner as a result of some undocumented limitation or you didn’t totally account for the entire cost of implementing a solution.

Use the previous steps to whiteboard a few potential deployments. Ask yourself:

• Who needs to access what services? And for what?
• What security implications are there when putting to services together?
• Which services will be brokered or shared?
• Where will we fail-over to? Is DR in a different availability zone, region, or combination?

Playing the long game

Still, at this point, the work has barely even started. Going forward you will need the tools and resources to deploy rapidly on top of your foundation. While the battle starts here with the planning phase, the war is won by implementing sound processes, standardization, convention, and lots of rigor.

We cover that in the next 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