STARTING FROM SCRATCH – HOW TO START WITH A NEW MASTER BILLING ACCOUNT

Recently, I did something I haven’t done in quite some time….. create a new Master Billing Account for a customer. This actually tripped me up a little bit as it raised a question I haven’t had to think about due to the wonderful world of automation;  “What do I need to do to a new AWS Master Billing Account?”

Most of the time when I need a new AWS account, I’m creating an account within an existing AWS Organization. As a result of this, any new account I create has a number of pre-configured things done to it before I even log in for the first time. After all, this is a fundamental tenet of a good Landing Zone solution. But when it comes to setting up a new Master Billing account, none of this automation is in place yet…. As a result, we need to take this into consideration as well as implementing them in a way that will make deploying a Landing Zone easy.

Step 1: Create a new AWS Account

Now, this might sound like a “well Duh!” moment… but the very first page is where we need to make our first design decision –  “What are we going to use as an email address?” Because you will rarely ever login to your Master Billing Account using the root credentials (a.k.a the email address) it’s easy to forget whose email address was used. While this may not be a big problem today, it can become one if you need to login as root and the email address used belonged to an employee who left the company 18 months ago…. and “oh, we need to do a password reset!”.

NOTE: Give some thought to the email address you will use, and if unsure… use a distribution list dedicated solely to this purpose.

DOUBLE NOTE: Also think about monitoring this email address for password reset emails and other correspondence from AWS.

Step 2: What to do with your Root Account Credentials?

OK, so you’ve set up a dedicated email address to use for your account… time to set a super strong password and configure MFA on it (which can be done using the instructions found here). But again, we are presented with an issue… where/what to do with the physical/virtual MFA token assigned to the account? In my experience, the simplest solutions are typically the best. Use either a physical hardware MFA token or procure a cheap/old mobile phone  and store it in a secure location (safe, office, etc) and document where it’s stored.

NOTE: Configure MFA on the Root User as soon as the account is provisioned and store the token in a secure location.

DOUBLE NOTE: Make sure you test it, and document where the token is stored

Step 3: Configure Contact Information

We have our account and have secured our Root Account, now it’s time to start configuring things. First things first, we want to set up contact information for AWS correspondence. On our AWS Account, we can define email addresses that AWS will use for Billing, Operations and Security events. Step by step instructions on how to configure these can be found on the AWS website here.

AWS would reach out to each contact type in the following scenarios:

• Billing – When your monthly invoice is available, or your payment method needs to be updated. If your ‘Receive PDF Invoice By Email’ is turned on in your billing preferences, your alternate billing contact will receive the PDF invoices as well
• Operations – When your service is, or will be, temporarily unavailable in one of more regions. Any notification related to operations
• Security – When you have notifications from the AWS Abuse team for potentially fraudulent activity on your AWS account. Any notification related to security
  
  

What’s important is to make sure that monitored email addresses are used as these emails will inform you of potentially outage level issues and changes to your account.

NOTE: make sure to set specific email addresses or distribution groups for each of the alternative contacts.

Step 4: Configuring Tax Settings

While we’re in the Account settings, we should also take a moment to review our Tax Declaration. While most of the time our customers don’t need to worry about these settings, it’s important to review them and make sure they are correct. Also, considering that we are configuring a Master Billing Account… we should also configure our Tax Settings inheritance so that these settings propagate throughout our AWS Organization. Instructions on how to do this can be found here.

Step 5: Configure IAM

While you probably won’t be creating many IAM users in your Master Billing Account, it’s still important to make sure we configure IAM correctly. The key points here are that we want to:

1. Set our IAM Link. This also controls our AWS Account alias
2. Set an IAM Password Policy. Given this is a key account, you should set this more aggressively than normal given only administrators will be using it
3. Configure at least two IAM user accounts and configure them both with “Administrator Access” permissions. The first account is a “Break-Glass” account and should be configured with an overly complex password. This account is to be used as a “get out of jail free card”. A separate IAM user account should also be created for each administrator who will need regular access to this account
4. Set MFA up on each of the IAM user accounts

Step 6: Configure Cloudtrail

With our basic security in place, and a way for AWS to contact us when things go wrong… we now need to turn our focus onto our audit controls and the first cab off the rank is CloudTrail. This will provide us with a way to monitor what’s been done within our Master Billing Account and is handy to have in place prior to us configuring our Landing Zone.

Given we are just starting out, we can configure CloudTrail via the console using the instructions available here. It is advisable, however, to look towards moving this into your Infrastructure as code solution once you have a pipeline in place.

Final Step: Configure AWS Config

Now, with everything in place we can now set up some AWS config rules to make sure that our configuration stays as expected going forwards. Much like the CloudTrail setup, this should be moved into an IAC solution later on down the track… but to start off with it’s advisable to configure the following AWS Managed Rules:

• CloudTrail-enabled. Checks whether AWS CloudTrail is enabled in your AWS account. Optionally, you can specify which S3 bucket, SNS topic, and Amazon CloudWatch Logs ARN to use
• IAM-password-policy. Checks whether the account password policy for IAM users meets the specified requirements indicated in the parameters. This rule is NON_COMPLIANT if the account password policy does not meet the specified requirements
• IAM-root-access-key-check. Checks whether the root user access key is available. The rule is COMPLIANT if the user access key does not exist.
• IAM-user-mfa-enabled. Checks whether the AWS Identity and Access Management users have multi-factor authentication (MFA) enabled.
• IAM-user-unused-credentials-check. Checks whether your AWS Identity and Access Management (IAM) users have passwords or active access keys that have not been used within the specified number of days you provided. Re-evaluating this rule within 4 hours of the first evaluation will have no effect on the results.
• Root-account-mfa-enabled. Checks whether users of your AWS account require a multi-factor authentication (MFA) device to sign in with root credentials.

Conclusion

While there are a lot of other controls you can put in a Master Billing Account (such as billing alarms, CI/CD pipelines, etc.), the above steps will ensure that you have a good starting point aligned to AWS best practices. The key points to remember are:

1. Don’t use an individual’s email address to sign up for the AWS Account
2. Make sure you use a strong password for the Root User and secure it with MFA
3. Configure alternative contact details for Billing, Operations and Security notifications
4. Setup named and break glass IAM accounts for only those users responsible for administering the organization as a whole
5. Initialise CloudTrail ASAP to capture any changes being made to the account
6. Deploy Config rules to ensure that any configuring drift is detected and can be remediated quickly and easily

Want to explore Landing Zone and how to achieve a best practice aligned AWS environment based on automation?  Get in touch with us!

Cevo is the trusted leader at the forefront of continuous delivery technologies, helping our customers stay competitive through innovative solutions and building capability on the AWS platform.