Things to do with a new AWS account

tl;dr: some important thoughts (okay, Rik’s personal opinions) on the essential tasks that must be completed while setting up a new Amazon Web Services account.

Why use AWS?

There’s many monsters in the cloud; the one I shall be chatting about today is called Amazon Web Services (AWS). Now don’t think this is favouritism on my part: I have an equal and passionate loathing for Google Cloud and Microsoft Azure, but gone are the days when we, as ‘serious’ web developers, could find a local web hosting service with excellent customer support and just slap up a site.

(… yes, I know that’s not true. There’s some decent outfits out there who specialize in easy-to-use solutions for hosting a Wordpress site, or a Drupal site, or some Docker containers, etc. But if we want to do anything interesting or innovative with a site or app then we’re gonna have to play with the Big Boys).

AWS are iterating fast these days. If we’re looking to run a bespoke site off a scalable server, possibly with Continuous Deployment (or Integration) all tied into various bells, alarms, whistles, reports, forecasts and - possibly - unicorn detectors, then AWS probably have us covered. Equally, if our site is static and simple and not needing a whole Laravel routing-and-database-backend solution, then deploying the site to an AWS S3 bucket with added CloudFront cover is a competitively cheap sell to clients.

It is ridiculously easy to sign up for an AWS account. Only after we’re through the gates do the problems start. Why? Because AWS offers us everything in a big buffet of sort-it-out-yourself. It takes just a few clicks to slap up a test database and do some experimenting with it, only to forget it exists until the monthly bill arrives in the inbox.

And the temptation to do everything as the root user is massive - dealing with IAM users and groups feels like a hassle from the get-go; failing to do that necessary work from the start will, I guarantee, lead to epic headaches and tantrums down the line.

What follows are my own personal opinions on the things folks should be doing when they set up a new AWS account, either for themselves or for a client. I’ve probably missed some obvious steps - heck, I’m still learning AWS. Comments and corrections are always welcome!

Secure the root user

After filling in the new account form and giving up the keys to somebody’s credit card, AWS will give us an owner’s - also called a ‘root’ - account and take us straight to the logged-in home page.

The owner’s account is sacrosanct. Never share details of the owner’s account with outsiders! Access details to the account should also be strictly limited internally, for instance to the person responsible for the credit card we used to create the account.

We need to concentrate and do necessary security stuff before we get distracted by all the AWS Shiny and kittenz. Step one is to secure our root account. We do this in the management and security bits of the site, which are hidden in links in the dropdown to the right side of the header:

See the security status panel? AWS are really keen for us to secure our root user. The additional items section to the right gives links to various relevant pages in the AWS documentation. AWS documentation is scary in its own right. Even with the great improvements AWS are making to their documentation, the sheer volume of it all makes navigating and absorbing the information an Olympic-level challenge.

Let’s start by clicking on the My Security Credentials link; we sometimes get a nice warning when we first access it, which is worth repeating here:

Here we can do things like change the root user’s password, enable Multi Factor Authentication (MFA) and other more techy security stuff. More usefully, the link has taken us to the Identity and Access Management part of the console. Click on the Dashboard link on the left.

The IAM console is kinda funky. Before we get down to creating users and groups, let’s customize our user’s sign-in link (more on this below) - because the one AWS auto-generates for us is ugly and unmemorable:

Another important place to visit in IAM is the Account settings page. Our job here is to set a password policy which will apply to the entire account. The form is simple to use and apply.

Set up our first account group and user

The other sections in IAM we are interested in are the Groups and Users tabs. We need account users because we absolutely do not want everybody using the root user to access the AWS console.

My personal Best Practice is to use groups to allocate ‘policies’ (permissions to do stuff) to users. Let’s set up our first group:

As we go through the process of setting up a group we get given an opportunity to allocate ‘policies’ (again, permissions) to the group. The AdministrationAccess policy will give users in this group access to pretty much everything. This is dangerous! It is too easy to add new users to this group as we create them, simply so they don’t bother us with requests for extended permissions to do more stuff as time goes by. Resist this urge!

(In fact I think AWS should do something to make it a lot harder to allocate the AdministrationAccess policy to users and groups. A good start would be to rename that policy to something like YouSureYouWannaAllocateAdministrationAccessToTheseGuys? - just saying.)

Next we create our first (non-root) user. This time we get asked if we want to add the new user to a group. A user can belong to many groups - which is a good reason to strictly limit the permissions we give to each group we create, centering them around a set of tightly defined tasks. Losing sight of who has permissions to do what is an easy route to unexpected security breaches and other disasters like shutting down the wrong server or database …

Less obvious things to set up right from the start

AWS are the Seventh Heaven for gotchas: little things which will - at some point - drive you nuts trying to figure out and fix. It makes sense to fix a couple of them right now.

These particular things are not in the main services console, but rather in the management console - click on the My account link in the dropdown menu under our logged-in name, which should still be our root user’s email address.

Access to billing information - we, as the root user, need to explicitly enable account users (with the relevant policies/permissions) access to this data:

Cost allocation tags - another really useful thing to activate is the cost allocation tags functionality. These tags will make tracking the costs of individual projects a heck of a lot easier as time goes by:

Testing our new user

Now we can logout of AWS to test our new user. Easy, huh? Nope. Here’s another gotcha: AWS has two login forms - the one (you may have) used before when logging in as the root user, and a second one whose url we customized in the IAM console. Go visit it now (using the customised url which - of course - you stored in a secure place like LastPass, alongside the user’s name and password) and login as our new admin user:

Notice that it looks a lot like the root user’s login form. But it’s not:

… I guarantee that at some point you will find yourself cussing out your computer because you try to sign into AWS via the root login using your IAM user’s details. To make things even happier there’s no link to the IAM user login page from the root user login page.

Okay. I think that’s enough. There’s tons of other useful stuff we can do on the admin side for AWS - for instance setting up some cost alerts to warn us that our monthly AWS spend is about to go above a given level. Remember that while AWS is (relatively) cheap, it also costs us money - do not rely on everything being on the Free Tier! - and leaving a big database idling for a couple of weeks after we finished experimenting with it can often turn out to be a less-than-pleasurable experience for that poor credit card.

Enjoy your time with AWS. Remember: every visit is a new adventure!