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.
Create a billing account to centralize billing and take advantage of volume discounts and Reserved Instance (RI) purchases. Use the billing account to:
Additional Billing Account Solutions that could also be implemented include the following:
Cost Explorer: Provide reporting, analytics and visualization capabilities to track and manage your AWS costs.
Cost Optimization Monitor: Helps you more easily analyze and visualize service usage and related costs.
Security and Audit Account
Create a security and audit account to manage security and compliance-related logging and auditing activities. Use the security account to:
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:
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.
Create application or business unit accounts to host services for individual workloads. Examples of application accounts include:
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:
Additional Application Account Solutions that could also be implemented include the following:
EC2 Scheduler: Automatically stops and starts your Amazon EC2 instances.
EBS Snapshot Scheduler: Automatically takes snapshots of your EBS volumes, and automatically deletes those snapshots after a defined retention period.
Cost Optimization Right Sizing: Analyzes Amazon EC2 utilization data and provides right-sizing recommendations to help you optimize your Amazon EC2 costs.
Key Account Design Considerations:
- Use separate application account per critical production application per region.
- Create and implement AWS tagging standard across your accounts.
- Use separate billing accounts for different currencies.
- Create separate account structure (billing, security, shared-services) for application groups supported by different lines of businesses of different organizational groups.
Security Baseline for Accounts
The following services should be configured as part of the security baseline.
Identity and Access Management (IAM)
- Protect the root account
- Create a strong password and enable hardware MFA.
- Use IAM user credentials instead of root credentials for day-to-day interaction with AWS.
- Use IAM roles or user access keys instead of root access keys.
- Create and document a process for adding and removing authorized IAM users that fully integrates with your company’s existing employee provisioning/de-provisioning process.
- Create IAM groups that reflect organizational roles.
- Use managed IAM policies to grant specific technical permissions as required.
- Create a security e-mail distribution list to receive security-related notifications.
- Configure security-related alerts.
- Create and Amazon SNS topic for security notifications and subscribe the security distribution list to the topic.
- Generate AWS usage and billing reports.
- Enable CloudTrail in all AWS Regions, and configure CloudTrail integration with CloudWatch Logs.
- Enable AWS Config.
- Automatically store monitoring data in Amazon S3 and configure access in the bucket policy.
- Enable audit and access logging capabilities wherever available.
- Get the most out of your logs: analyze log data, create actionable reports, and configure alerting.
- Use Amazon S3 for secure, durable storage to ensure log files are not accidentally lost, stolen or tampered with.
- Consolidate logs in a single location.
- Use a consistent file naming standard to help organize log files.
- Create and implement lifecycle policies for storing, aggregating, analyzing, archiving, and deleting log files.