AWS Account Structures

In this post I’m going to go into one of the sections that is an important consideration for any enterprise that is looking to migrate into AWS which is Account Structures.

AWS offers a variety of services and features that allow for flexible control of the account(s) managing your cloud computing resources. Implementing the most appropriate account structure for your use case can help to ensure proper cost allocation, agility and security.

Key Design Considerations include the following:

Don’t over engineer your initial account structure.

Use an iterative approach to creating and structuring your accounts.

Use seperate AWS account for things that are clearly separate.

Use group e-mail addresses as your account e-mail addresses.

Standardize your e-mail aliases and your AWS Account names.

From my own perspective this has been something that I’ve been working on lately and have utilised the below as a starting point.

Billing Account

Create a billing account to centralize billing and take advantage of volume discounts and Reserved Instance (RI) purchases. Use the billing account to:

Pay for all other AWS Accounts

Analyze AWS usage and spend

Send alerts when billing thresholds are met

Create accounts via AWS Organizations

Enable Billing Reports and Budget

Additional Billing Account Solutions that could also be implemented include the following:

Create a security and audit account to manage security and compliance-related logging and auditing activities. Use the security account to:

Monitor the overall security posture of all accounts

Scan all other accounts for security vulnerabilities

Store security logs in a centralized S3 bucket

Send alerts or take corrective action during security or compliances events

Additional Security & Audit Account Solutions that could also be implemented include the following:

Centralized Logging Solution: Collect, analyses, and displays logs on AWS, specifically in Amazon ElasticSearch.Cloud Custodian: Open-source product from Capital One for securing and remediating rules across multiple accounts.DIY AWS Config Rules & CloudWatch: Start with a set of preconfigured best practices rules for security & compliance monitoring and evolve over time e.g. AWS CIS Framework.

Shared Services Account

Create a shared services account to host common services that are shared among application account. Use the shared services account to:

Host golden (personalized) AMIs

Host AWS Service Catalog portfolios that are shared with the application accounts

Host Directory Services

Connect to different VPCs and remote networks

Additional Shared-services Account Solutions that could also be implemented include the following:

Transit VPC Solution: Allows you to create virtual network transit centers, without the traditional costs of establishing a physical presence in a colocation transit hub or deploying physical network gear.AWS Limit Monitor: Tracks usage of AWS resources against service limits and sends e-mail notifications to you as usage approach limits.

Sandbox accounts: Experimental accounts where developers try new services. These should be connected to on-premises or shared-services accounts.Dev and Test accounts: Accounts used to develop and test new features. These accounts should be connected to on-premises and shared-services accounts.Production accounts: Accounts used to host the production version of applications. These accounts should be connected to on-premises and shared-services accounts. They should also have the highest level of security controls.

Use these accounts to:

Host production applications

Develop and test applications

Try new services

Additional Application Account Solutions that could also be implemented include the following: