Chapter 0: AWS Account Configuration

The first step to use Amazon Web Services is creating an AWS Account. An account is not just a means for Amazon to bill you for the use of their resources. An AWS Account is also fundamentally a container for resources, a unit of related resources to which security, monitoring, governance can be applied to as a whole. In addition an account also serves as a way to organise billing of related resources.

It is common for an AWS rollout to consist of many different accounts, and a simple implementation of this approach is outlines in this guide. However, please be forwarned that for a single individual’s development/experimentation/learning with AWS, multiple accounts may be overkill, so evaluate if this approach makes sense for your needs.

Multiple Account Design

The scenario that we are going for is supporting learning/exploration/experimentation on AWS. As such the goals of this design are:

• Trying to keep simple
• Allow repeated iterations of tearing down and rebuilding development AWS environment
• Follow AWS Best Practices
• Learn AWS Account Fundamentals

To acheive these goals the following design was chosen:

Leverage AWS Organizations to organize multiple AWS Accounts. The accounts are:

• A Management Account that contains all permanent administration related configuration and resources. Billing, Logging, User Access Control are implemented here.
• A Development Account that contains the resources can be blown away whenever necessary.

AWS Identity and Access Management Cross Account infrastructure is used to allow an Administrative User in the Management Account to administrate both the Management and Development Accounts.

Creating an AWS Account

AWS recommendation of best practices for setting up an AWS account can be found at the following link: AWS Account Set Up Best Practices

These best practices include:

• Use Strong Password
• Use Group Email
• Enable Multi-Factor Authentication
• Delete Root User Access Keys
• Create/Use Distinct Administrative User
• Never (Almost Never) Use Root User Account Again
• Enable CloudTrail in All AWS Regions

Root User

The root user of the management account should never be used except to initially create other administrative users. This user in general cannot be limited by security mechanisms and as such is considered too dangerous to use.

It is recommended that it is created with a group email, and that once it is created access keys are deleted and Multifactor Authentication is enabled. After these steps are complete its recommended you securely store the password for this account, and plan to never use it again.

Administrative User

The next step is creation and configuration of your true administrative user.

AWS provides a managed IAM Role for Administrative access, so creating an administrative user is straightforward.

AWS documentation for settings up an Administrative IAM user can be found at the following link: Create Adminstrative User

Enable Billing Access

By default in AWS Administrative access does not include access to billing information. To minimize need to log in as the Root AWS account, it is recommended to grant permissions for an alternative user to have billing access. In this guide we are granting access to the Administrative User account, your policies may differ.

AWS documentation for granting access to the Billing Console can be found at the following link: Granting Billing Console Access

AWS Organizations

Organization centralize the administration of multiple AWS accounts. One key administrative benefit of AWS Organizations is consolidated billing, which enables the management of billing for multiple accounts from one central management account.

It is recommended that the management account should only be used for administrative/governance purposes and in general AWS resources should not be created in this account.

AWS Documentation for Creating AWS Organizations can be found here: Create AWS Organization

Management Account

The initial AWS Account we created previously is the Management Account (also known as the Payer Account) in this scenario.

Member Account

A Member account is an account that is managed by an AWS organization. In a larger multi-account design there would be many (from dozens to thousands) of accounts at this level that may be used to contain/constrain/secure resources. There are many different design considerations that accounts can by the driver for how accounts are organized:

• Different stages in the software development lifecycle (DEV, TEST, STAGING, PROD).
• Different business units/departments in the enterprise (Marketing, Sales, ECommerce).
• Individual business initiatives
• Sandboxes for individual contributer

In this scenario the development account is a member account that is the primary account used for developement/experimentation/learning purposes.

AWS Documentation for Creating Member Accounts can be found here: Create AWS Organization Member Account

Enable Cross Account Access

In this scenario the same Administrative User from the Management account is used to administrate the Development account. This is facilitated by AWS cross account access infrastructure.

In essence accounts created as part of an AWS Organization have a specific role which is preconfigured to allow access to the member accounts resources.
From the management account permission needs to be granted to assume this role. Recommended best practice is to grant assume to a group instead of an individual user, as such we also will need to create a IAM Group, and add appropriate users to this group.

AWS Documentation for enabling cross account access to an AWS Organization’s Member Accounts can be found here: Enabling Cross Account Access for Organization Member Accounts

Enable AWS CloudTrail

CloudTrail provides fine grained logging of AWS API activity. It is enabled by default, however by default events are only visible via the AWS Console or via AWS sdk call. Further these events are segregated by region, even if CloudTrail is enabled for all regions you only see the Event History for the region you currently have selected in the AWS Console.

Typically a CloudTrail Trail is created to dump CloudTrail logs to S3 where they can be combined/corellated/analyzed. There are potential cost implications for this functionality, however one CloudTrail Trail is free. Be aware that CloudTrails across multiple regions actually spins up seperate trails in separate regions.

It is conveinent to configure an organizational CloudTrail Trail that logs activity across all accounts within your AWS Organization. Be aware that if you enable an organization level CloudTrail Trail and also an account level CloudTrail Trail there will be some overlap, and you will go beyond your one free CloudTrail Trail allowance.

AWS Documentation for enabling Organization level CloudTrail can be found here: Enable Organization Level CloudTrail

AWS Documemtatopm for enabling CloudTrail for all regions can be found here: Enable CloudTrail for All Regions