Basic setup for a new AWS account
Setting up a brand new AWS account using organizations with basic security.
Introduction
Some of you might ask: why AWS? Can’t we use Digital Ocean or [any other generic cloud provider]? You can use basically any cloud provider (or even on-prem) to deploy your solution. I like AWS because you get everything from one single provider. It is also not as expensive as one might assume comparing it to other providers like Digital Ocean, Vultr and others, once you understand the pricing structure and things like saving plans, reserved instances. AWS also has a great support for startups in their partner program and many more.
Types of AWS accounts
AWS offers several ways of managing your accounts. The first and easiest is to “just create an account”. If you are just playing around or only have one product, that is the best way to start.
If you should have a company and several clients or products, you can create sub-accounts called “Organisations”. I personally like to create one account per client and product as you receive a separate invoice for each account. To make the payment easier, AWS offers consolidated billing, so you are only charged once each month for all accounts together.
For the sake of this series I have set up one “billing account” and one sub-account for this project (aka. “project account”). The billing account will receive the invoice each month, but we will set up all resources in the project account. AWS lets you share credits and saving plans across accounts, so it is a great tool to separate costs and access control without having any financial downsides. If you decide for one account only, it has no effect on the rest of this series. Everything will work equally with both account set-ups.
Creating a new sub-account
If you are creating a new account, it will take up to 48 hours after verification until you can use all services. There is no need to contact the support, it always takes one or two days. For the case that you already have an AWS account and want to go the path of sub-accounts; first thing is to create an organisation which requires you to verify your email address (again).
After you have verified your email address, you can create a new organisation. If you had another AWS account under the entered email address, there will be no direct validation error. It will silently fail and show you the error in the overview later. If you have used the email address before and have closed the AWS organisation, you cannot re-use the same email for a new account, unless you contact the AWS support.
The “IAM role name” is a role that will be created in the sub-account to allow the parent account to access certain resources. One example is the consolidated billing. As you will receive a consolidated bill from the parent account, it needs to access all required information for this. We will deep-dive into roles and cross-account sharing in a later part of our series.
Basic security
Using the administrator account for daily operations is dangerous. You know that from other systems like *NIX, so I won’t go into details here. Also compromised credentials can get costly on AWS in really short time. Before we create a new user for our daily usage, we want to define a password policy and force new users to use MFA (I am recommending to use a password manager for this. Great choices are tools like 1Password or Bitwarden). AWS makes both very easy.
Password Policy
Browse to IAM > Account settings. You should make the password policy as secure as possible. The users will use a password manager in anyway to store the passwords, but you can adjust the settings based on your requirements (e.g. HIPAA, SOC-II).
MFA enforcement
Next, we are going to create an IAM policy to force the user to change their password on first login and activate MFA. Therefor simply create a new policy. I have created a public gist as the policy JSON is quiet long:
When you create a new user you can assign this policy or you can create a group and assign the policy to the group (e.g. developers, finance, admins).
Next we need a policy that wraps the administrator privileges. Create a new role with a name like “admin” and assign it the “AdministratorAccess” permission. After this create a new policy “AssumeAdminRole” with the following JSON:
In a last step we will create a new user for our daily usage. Assign the two policies we have created above to the new user. The user will then:
- Log in at a specific URL for your account
- Have to change their password on the first login
- Have to activate MFA before using the account
- Have no privileges at all after logging in
- Only gaining access by assuming our administrator role (more on that later)
Identify Center
At the point of writing this, AWS has release a new way to manage IAM users — called “Identity Center”. We will proceed with the “classical” approach throughout the series and talk about the advantages and how-to’s of the Identity Center later on. If you have several AWS organisations and have to access several of them on a daily basis, you should check it out directly.
Afterthoughts
Use your new user for daily usage. It is missing a few functionalities like billing, but you can easily add this in or create a dedicated role for it for the case that you have a department handling these things.
If you have concerns that this will cause problems with using the CLI, you are right. It will break the simple IAM user access, but the AWS CLI does support assuming roles, it’s just a one-time configuration and worth the extra security. A lot of IDEs like PHPStorm support AWS profiles via plugins.