Following-on from the 'Landing Zones, Organizations, OUs and Multi-Account Environments blog', I decided to "practice what I preach" with my personal AWS Accounts!
Currently I have 5-10 Accounts for different workloads (spikes, storage of personal data, web app hosting etc); I have had these accounts for many years and I manually used AWS Organizations via the Console to create & manage them
NO guardrails or SCPs have been implemented, I have probably deployed & configured some AWS services wrong and I have probably created IAM users with broad (*) permissions
The purpose of this blog is to address the above concerns; To refactor my accounts into a Landing Zone that follows the AWS best practices.
My Accounts - Current Account Architecture
The below Diagram shows my current Account structure
org-formation - Overview
Taken from github org-formation; AWS Organization Formation is an Infrastructure as Code (IaC) tool for AWS Organizations.
org-formation orchestrates CloudFormation and AWS Organizations for account creation and resource provisioning
Tasks / Features
Tasks files can be added to enable a variety of Automated features such as:
- OrganizationAccountAccessRole restrictions (SCPs)
- Budget Alarms
- AWS Access Key Rotation checks
- Enabling CloudTrail
- Centralising and Enabling Guard Duty
- Many IAM Configurations (Password Policy, force MFA)
- Many S3 Configurations (Prohibit Read & Write, Enable encryption)
- VPC Security Groups conform to (user-defined) ALLOW list
This feature list is what I intend to implement on my Accounts.
For the full list of available org-formation features, please refer to the 40mb pdf
FYI on Tooling Decision
Control Tower? Terraform? CloudFormation? org-formation? CDK?...
- It is not the purpose of this post to go into the detailed comparisons of these tools.
I am an AWS Architect at Version 1, I have experienced all of the above tools used to produce Landing Zones for Clients.
org-formation (DAPx)
One of the Version 1 DAPx Landing Zone Accelerators is built upon org-formation, I have used this for my Landing Zone.
- It is not the purpose of this post to sell DAPx, please message me if you would like to know more about DAPx,
My Accounts - Target Accounts Architecture Design
The below diagram shows the Target Account structure that is aligned to the best practices & architecture detailed in the 'LZs, Organizations, OUs and Multi-Account Environments blog'
Development Summary
org-formation is a highly flexible and powerful toolkit, to prevent content bloat I will provide only a few code/console snippets for key important featues.
IAM Role - Account/OU Access
Secure Defaults
Budget Alarms
GuardDuty
AWS Config
Centralised AWS Config in the Master Account, AWS Config has access to all member/child accounts.
The LogArchive Bucket is in the LogArchive Account, this has Access Restrictions and Cleardown Policies by-default
AWS Config Findings Alerts (inc SNS Topic by-default), All AWS Config Managed Rules are available to use
CloudTrail
SCPs
The End Result
The below diagram shows the final Account Structure & AWS Services that have now been implemented
Cleanup on isle "Config Findings"
These Config Rule Alerts include:
- access-keys-rotated
- iam-password-policy
- root-account-mfa-enabled
- s3-bucket-server-side-encryption-enabled
- vpc-sg-open-only-to-authorized-ports
Once I have remediated these I will feel a lot better about the security of my AWS accounts!
Thank you for reading, constructive feedback is welcomed.
Top comments (2)
Interesting. Did you run this as a pipeline or one off from the CLI?
What was your starting point for the templates; blank canvas or starting with the org-formation-reference implementation?
CLI - Because the changes to the LZ are not expected to be frequent, I couldn't justify spending the time to create a pipeline!