Prerequisites

• Your AWS Organization

The Lesson

Sometimes you just need to do the scut work. This is one of those times.

As we covered in the Stage Check, our AWS Organization is in great shape for us to start implementing more security thingies (a technical term — you can look it up) and building out some workloads. Before moving on we need to do a few small things which I pushed off until now because they didn’t fit the progression.

This week we will change one small but essential security setting in our management account, and create a workload account, so we have something to… work with. Yes, my words are lacking creativity today, but you try writing original works of art every week!

Alternate Contacts

AWS periodically sends email related to activity in your accounts. Right now you are receiving all these at your primary email (root user email) for your management account. Actually the root users of all your accounts are get these emails. This leads to fun things like waking up in the morning and finding that I have 186 identical emails on the exact same issue streaming into my inbox because I used + email addressing on all my personal accounts.

Anyhoo, in a larger organization I typically recommend setting up a distribution list for AWS email. It tends to fall into 4 categories:

• Billing information, like those “your free tier is running out” emails some of you are already seeing.

• Operational information, like Lambda deprecating support for the version of Python you’ve been using.

• Security information, like “hey, we found this access key on the Internet and we have evidence someone in North Korea has been using it to run bitcoin miners in your account”. (The nice thing about North Korea is I don’t have to worry about offending any potential readers there!)

• Marketing email. These get old fast.

AWS understands that the security, operations, and billing teams might be interested in different things. Unlike Max, which seems to think my entire family wants the same TV recommendations. Can we have HBO back, please?

AWS lets us set up alternate contacts for each of these categories. And not just for email — you can provide names and phone numbers AWS can use in a more serious situation. Since we are setting all our root user accounts to procedurally generated email addresses, this is a valuable to ensure named teams, or even individuals, can get email and be appropriately contacted on specific issues by AWS. Like, security stuff.

You can, and should, still send these emails to a distribution list, but now you can send security to the security team and operational stuff to the ops team. You can send billing info to my cat Goose. He won’t do anything about it — he’s kind of worthless that way.

Note that you can set these differently for different accounts, even in the same organization, which may be useful for those of you with really large footprints.

Prod vs. NonProd

I’ve mentioned this before, but within the Workloads organizational unit we will set up additional organizational units to help set up our security with Service Control Policies.

One of the most common ways of doing this is to set up Prod (production) and NonProd (figure it out yourself) OUs right under the Workloads OU. We put really restrictive SCPs on Prod and less restrictive ones on NonProd for development and testing environments.

What’s a Prod AWS account, and what’s NonProd?

I’ve been saying that for years, and it is weirdly controversial. To me it’s a hard rule, because we choose between Prod and NonProd based on risk. And if an AWS account touches production data — even for testing or development — the data is still at risk and must be treated just like a full production application. Many Bothans died to bring us this information.

Lesson Key Points

• Alternate contacts are an important and valuable way to ensure teams see critical communications from AWS.

• Prod and NonProd are common ways of defining workloads, used as Organizational Units so we can more effectively scope Service Control Policies.

The Lab

Today we will set alternate contact information for our accounts, create Prod and NonProd OUs, and create a NonProd account to start playing with.

Video Walkthrough

Step-by-Step

First go to your IAM Identity Center sign-in page, sign in, and select AdministratorAccess for the CloudSLAW management account:

Phase 1: Set Alternate Contacts

Then go to Organizations > Services > AWS Account Management.

We need to enable trusted access for this capability. The way Organizations works is that you need to explicitly enable the various functions you want to use. In some cases, as with CloudTrail, this was largely automatic when we clicked the button to enable an Organization trail — although that does error sometimes. In this case we enable it from Organizations, because there isn’t really one dashboard for all account management.

Click Enable trusted access and type enable when prompted:

Now we need to change those account settings. We are just going to do it for one account today, and in a future lab we will learn how to automate it for all accounts. In the real world you would want to set alternate contacts for all accounts from the start.

Go to Accounts and then pick your management account (CloudSLAW):

Scroll down slightly, click the Contact info tab, and then Billing contact:

Then fill in your info and click Save. Remember, in a real environment you would be more likely to send this to an email distribution list for billing and provide their department number. AWS documentation is that they support this — it doesn’t need to be an individual’s personal information.

Repeat that process for Operations and Security and it will look like this, but with your name. Unless you put down my name, but you realize I still ain’t paying your bills, right?

If you want to go set this info for your other accounts (all in your Security OU) go for it. While we will learn how to automate the process later, it’s going to be much later. Or cheat and use this Terraform from Chris Farris. (Don’t actually do that — it would mess up our other labs — but it’s useful to keep handy for your day jobs).

Phase 2: Create the Workload OUs and Test Account

Now switch gears. We will stay in Organizations but go back to the main Accounts page and click our Workloads OU:

Then Actions > Create new:

Name it Prod and click Create organizational unit:

Repeat those steps to create NonProd!

If you go back to Accounts and scroll down, it should look like this:

Cool. Now scroll up and Add an AWS account:

Name it TestAccount1, use email + addressing again, and click Create AWS account:

Almost there! You might need to wait 30 seconds and refresh your browser for the account to show up. Then select it, scroll up, and click Actions > Move: 

Select Workloads > NonProd and Move AWS account:

And that’s it! The Accounts page should now look like this:

Cya in a week!

-Rich