Prerequisites

• Make sure you have completed all the steps in Stage Check.

The Lesson

Sometimes, as I’m talking with folks during my day job, they tell me they have large AWS deployments. When I ask how many accounts they have they say “a few dozen”.

Heh. I have something like 200 personal accounts, 182 in a single organization. With all the automation and centralization I have in place it’s as easy for me to manage 180 or even 1800 as it would be 20 or 30.

You haven’t tasted real cloud power until you’ve deployed a stack of resources across hundreds of accounts simultaneously, and they are all running within 15 minutes. Heck, I have friends who manage thousands of accounts.

Now it’s your turn!

This week we are going to turn on AWS Organizations, and all subsequent labs will build towards a skeleton architecture which is pretty much exactly what you will use when managing a large enterprise cloud footprint. We will turn on Single Sign On, centralize logging, deploy a range of security controls, integrate third-party tools, practice incident response, and eat cookies.

That last one doesn’t have anything to do with AWS but I like cookies. As long as they are chocolate chip.

What Is AWS Organizations?

AWS Organizations is an overlay service for managing multiple AWS accounts. Back in the day we pesky cloud security experts realized that an AWS account is a great way to manage the blast radius of an attack, or a resiliency issue. Think about it — every AWS account has to be segregated and isolated from other AWS accounts, or we could all steal each other’s stuff. The walls around an account need to be absolute, or we couldn't possibly put anything non-public up there.

Many of us started using multiple accounts to isolate our stacks. Prod over here, Dev over there, cookies in the kitchen (sorry, I’m trapped on an airplane and really want a cookie). A key isolation issue which emerged early was IAM. It’s very hard and complex to get IAM privileges scoped down appropriately when you have a lot of people doing a lot of different things in a single account. Splitting things out reduced that IAM management complexity.

Multiple accounts were also often required to deal with Service Limits. AWS (and other cloud providers) have some hard limits on things like the number of particular resources you can have in an account and the volume of API calls. Hit the wall? Spin up another account.

The problem was managing all those accounts in a coherent way. We traded one set of complexities for another. Tools were anemic, and few organizations had the skills and resources to build their own. It took a little while, but AWS created Organizations as a tool to manage all the accounts from a central place. In the process AWS also started creating additional governance controls, now that there was a way to manage accounts from the outside.

How AWS Organizations Works

At the core, that’s all Organizations is: a way to manage multiple accounts. It’s actually the default way Azure and GCP build out, but with AWS it’s an option. Here’s how it works:

• You start with a single account which will become your management account. This is the root of your organization. It’s just a simple, lowly AWS account unless and until you promote it — we’ll do that today.

• A set of additional features to manage your organization unlock. This includes creating your account hierarchy with Organizational Units, which are like folders for accounts, and Service Control Policies, a new kind of IAM policy that works like a security blanket around an account. It also helps deploy Single Sign On (via the AWS Identity Center service) and a slew of ways to enhance centralized management of other AWS services, such as Security Hub. We will learn about all of these as we go.

• Once your Organization is running you can create new accounts directly from it or invite existing accounts to join your org.

• There are two ‘flavors’ of accounts in an org:

  • Consolidated Billing accounts roll up their charges to the management account but are still otherwise independent. I actually use this at times when I have a super-secure account I want to isolate. The downside is you can’t use any of the cool security capabilities of orgs (particularly Service Control Policies, which we will implement very soon).

  • All Features accounts… have all the features. These are the ones you centrally manage.

If you invite another account to join your organization, the owner of that account needs to accept the invitation. Sorry, you can’t steal accounts with an invite. An account also can’t join your org without an invite and a handshake. Hand sanitizer is an option, and based on what I’ve seen, people should… wash their hands more.

Creating an account from your organization automagically puts all the hooks in place — no invite or handshake needed. At the start you have a limit of 10 accounts in your org, but I will show you later how to request a higher quota. The actual hard service limit is in the thousands (and yes, I know people who have hit it).

What About That Control Tower Thing I Saw?

Control Tower is an AWS service for building out your Organization with security guardrails, new account creation automation, and some other capabilities. I’ll talk about it more in the future, but these labs will show you how to manually do everything that Control Tower automates.

Today’s Key Points Are:

• AWS Organizations is a service for managing and organizing multiple AWS accounts.

  • It starts with a management account which is the ‘root’ of the Organization. The account you created in the first lab will become the management account.

• Accounts are an excellent security and resiliency barrier to manage the blast radius of negative events.

• For security, Service Control Policies are an incredibly important tool for protecting accounts (which we will learn to use very soon). Single Sign On, so you don’t have to make IAM users for all your accounts, is another major benefit.

• You can invite existing accounts into an Organization or create new accounts right from the Organizations service.

• An account in an organization can be fully managed, or just use consolidated billing.

• “All features” accounts have two key IAM roles to support Organizations: one to enable Organizations, and another to allow you to go into the account as an administrator.

The Lab

In our lab today we will enable Organizations, create an Organizational Unit, and create a new account in the OU. The entire process should take about 5-7 minutes.

Video Walkthrough

Step-by-Step

First go to https://console.aws.amazon.com and sign in.

Then click your username/account ID in the upper right corner and select Organization.

Now this next part is really tricky… click the button that says, Create an organization.

Well that was anticlimactic. While it didn’t look like much, that button’s got it where it counts. That one click just unlocked a hefty list of new capabilities, many of which, like Service Control Policies, we’ll start using immediately. Take quick note of what you see here. There is a special folder called Root which is… yes, another way AWS uses the word ‘root’. Under that you see your current AWS account, which is now tagged as your management account.

This next bit is really important and critical, and why we haven’t played around with any instances (virtual machines) or other settings yet. The management account has basically full admin rights over every other account you will ever create in your organization. You can even lock out the root account (something we will do soon). Protect the management account, minimize who has access, and minimize what you deploy there!!!! Never ever ever enable Organizations (or deploy Control Tower) from an account which is running any workloads!!!

I bet you’re thinking no one would ever do this, but one of my cloud security associates has… seen the depths of the void (his words).

Okay, with that out of the way let’s create our first Organizational Unit (OU). Apologies to my editor, but since we use the term OU a lot I’m capitalizing when he says I shouldn’t. I know, we should never argue in front of the kids, sorry. First check the Root box (where you will create the OU, since they can be nested), then the Actions dropdown, then Create new:

Now another really complex step: name it Security and click Create organizational unit:

Anticlimactic. Again. Now let’s create our new account. Just click Add an AWS account. You don’t need to check the security OU box like I did.

This next part is important:

• Name the account SecurityAudit.

• Use “+” addressing based on the email address you used for your first root account (back in the first lab), but with a new “+extension”. This is why I made you use an email server/service which supports the capability to just add a plus sign and then other text to your base email address, and receive all that email at your primary address. I hope you listened. I did warn you. Yes, even you. We will create a bunch of accounts over time, so this is very important to keep them organized.

• Don’t change the IAM role name for OrganizationAccountAccessRole. This role gives you full admin into the account from your management account. While you could, and maybe it would give you a smidgeon of security through obscurity, it would just be a problem for these labs, so leave the default. In an enterprise, if you do change it, you’ll want to use automation for consistency. Yes, I’ve locked myself out of the role and had to use other tricks to get back in later. As we get deeper into IAM I’ll also cover strategies for eliminating this role and using something better.

• Once we do this it does take a little time for the account to fully provision. I generally recommend giving yourself 24 hours before trying to do much with the account. Core services will work fine, but you’ll find some things aren’t ready to go yet.

Next we will move this new account into the Security OU. From the AWS Organizations > AWS accounts page, click your Root account, then select the SecurityAudit account and use the dropdown to Move it to Security:

And now your org structure will look like this:

And boom, you’re done. We are all set to start building out our org and using cool new security capabilities like SCPs.

Key Lab Points

• I shall never enable Organizations or Control Tower from a workload account.

• Use “+” email addressing for these labs (and probably for your work accounts) because you’ll be creating a bunch of accounts.

• OrganizationAccountAccessRole is very powerful, and we will review later how to manage it or use an alternative.

The actual process today was easy, but the concepts and capabilities of Organizations are incredibly important, and core to effective AWS security at scale.

-Rich