Creating Your AWS Lab Account

We need to start at the beginning, but hopefully I include enough little knowledge crumbs in these posts to keep even you experts a little mentally engaged.

Rich Mogull
December 07, 2023 • Estimated Reading Time: 11 minutes

The Lesson

You want to start this program with a new AWS account.

You NEED to start this program with a new AWS account.

Seriously, use a new account, because we are totally going to rip it to pieces as we poke and prod our way through these labs. I realize some of you already have lab environments but you REALLY WANT A NEW LAB ENVIRONMENT for the work we are about to start together.

This account will serve as your AWS Management Account for the AWS Organization you will eventually build. Every cloud provider uses a different term for your cloud footprint; for AWS the core structure is an Organization, which contains Accounts. Azure starts with a Tenant that contains Subscriptions, and Google also starts with an Organization that contains projects.

Over at the Cloud Security Alliance we use the term “Deployment” to refer to an account/subscription/project. It isn’t perfect but we haven’t found anything better yet. And yes, I’m the one who decided on Deployment as the term, so you can blame me if you don’t like it.

With Azure and Google the ‘root’ of your Tenant/Organization is set up right when you sign up. Amazon is different because it went many years without having any concept of a deployment hierarchy; everything was a blob of individual accounts you could glue together manually without any central control.

Those were fun days. Not.

AWS Organizations is an overlay added after the fact, so you don’t start by signing up for an Organization — instead you start by creating an Account, which you then turn into the root/management account for the eventual Organization.

We’ll discuss this a lot more when we get to building our Organization. The important piece for this lab is that this account will become your Organization management (root) account, because of that we want to be careful how we set it up, and we DO NOT want to use an existing account.

Because this will eventually become your Organization Management Account you really want to pay attention to security, and that all revolves around the root account. What’s that? Our management account has a root account?

Yes, we have confusing and conflicting terminology right at the beginning. You see AWS refers to their unit of deployment as an Account, but within an AWS Account is the root account, the actual user that owns the AWS Account. (To further confuse [and hopefully eventually clarify] things, next lesson will cover IAM user accounts).

The root account is the email address, phone number, and password for whoever owns the AWS account. It is thus a critical point of potential security failure. The root account is basically ring 0 for your AWS account, and whoever can use that email address (or phone number — see the video for more) can take over the AWS account. Because of this I have some security recommendations in the lesson to help reduce the risk of root account compromise, which is the game over to end all game overs.

Key Success Criteria:

Start with a brand new AWS account.
Use an email provider which supports “+” naming. Gmail and various flavors of Microsoft Exchange support a feature where if you add “+<text>” to an email address, any email sent to that address will route to the main address. For example mail to [email protected] would go to [email protected] without having to set up a second mailbox. This will be important later when we set up additional accounts in your organization.
Use a unique email for these labs: either [email protected] or something like that. It will make life easier later.

We will cover a bunch more on root account security in our next lab, but let’s jump in. The entire process should take less than 10 minutes:

The Lab

Video Walkthrough

Step-by-Step

First go to https://aws.amazon.com

Click Create an AWS Account.

Now use that ‘+’ email addressing feature I mentioned earlier to create your root email. Remember: you absolutely need to monitor this email, and anyone who can read it can potentially take over your AWS account!!! You can also pick a name for your account. This needs to be unique, and it helps if it’s easy for you to remember. For our lab it can be whatever you want.

The email address you choose for a root account is one of the MOST IMPORTANT security decisions you can make this early. Anyone with access to that email can potentially take over the entire AWS account. And since every single AWS account is tied to an email, and you might eventually have thousands of accounts (I personally own hundreds), you need to keep them organized while also secure. In later labs I’ll show you how to lock out root accounts at scale, but you can never do that for your Organization Management Account.

Here are my recommendations for this email address:

Use the pattern “[email protected]”. I generate the random seed using my password generator. This pattern helps you know what the deployment is for, and track it back to the owner (the project owner, or you could use a business unit name instead). Thanks to the random seed it can’t be phished by guessing the pattern.
Send all emails to that address to a distribution list with security, the deployment owners, and IT on it. You will get critical emails there which say things like “we have detected exposed credentials.”
Anyone who can send email from that address has the potential to take over the account, so… be careful with that access. And the security of your email server.

Next check your email for your verification code and enter it.

After you verify you need to enter a root account password. Make darn sure this is long, complex, and stored in a password manager! You’ll make a lot of mistakes in this training, but don’t make that mistake. After you enter your password you will go to a screen that asks for your personal information; now you have another critical decision: use a phone number that only you can answer (like your cell phone). Personally I do NOT recommend using Google Voice or another virtual number; just give AWS your cell phone (and don’t get SIM swapped, but that’s a discussion for another day). I always just use the same numbers for personal accounts, but when you set up a new Organization Management Account for work you really need to be careful which number to use. It needs to be a corporate phone number that goes directly to someone who is trusted and can always answer it. So the SOC or similar is a good option.

The next screen will ask for billing information. We do our best to keep costs down, but some things will cost a bit. In one of our early labs we will set up billing alerts to avoid any surprises, and I am structuring the labs to turn things off as much as possible when we don’t need them to keep monthly costs below a cup of coffee at the start. I’ll warn you when costs might increase.

Then AWS will ask you to confirm your identity via phone. Since you enter this number here, it can be different than before, but you need to have the phone at hand. This will also be your first experience with the WCIH (Worst CAPTCHA In History). I think I can only get it right one out of 3-4 tries.

Whoever can answer this phone number effectively owns the AWS account. This is the number support will call to validate account ownership. In an enterprise environment, as with the root email, make darn sure you know who can answer this phone and that you can keep some level of security on it.

I have run technical assessments where I had to ask the client who owned the root account phone and it turned it it was a former employee, or maybe a contractor, or the dude standing outside the bar who had a better connection when the developer signed up for that first AWS account after a really deep conversation with their friend in town from the Bay Area.

Then select the free support plan. Don’t worry, I got your back.

Set up MFA

Now that your account is set up, you can log in and enable MFA. Start by going to https://console.aws.amazon.com — choose the option to log in using your root account email, and use the email address you just registered with.

Now click your account name in the upper right corner, then Security Credentials.

On the next page click Assign MFA.

If you haven’t, go download a Virtual MFA app on your phone (or use one you are already familiar with). I use Authy for my lab environments because it is free, easy, and reliable. With that downloaded you will click on the AWS page to show the QR code, scan it with Authy, and then type in 2 of the time-based codes. That means entering the first code Authy gives you, then waiting for the next one, and entering that. This syncs up the MFA. Follow these screenshots (or the video):

And you’ll see a nice green band when everything syncs up:

And that’s it! Now you have your lab AWS account with MFA enabled for the root user. Congrats on finishing the first lab!

Key Points

For our labs use a new, clean, isolated account.
Use a hard-to-phish root account email address with a random seed.
‘Plus’ addressing can be very helpful for managing the many emails you will need as we expand and create more accounts.
Establish MFA immediately.

And that’s it! The video walkthrough is always up at the top if you need it. See you next week!

-Rich

Reply

or to participate.