This Post is a notes-summary of AWS Best Practices for:

• Governance, risk, and compliance when establishing your cloud presence (AWS Blog Page)

• Organizational Units with AWS Organizations (AWS Blog Page)

• Managing the multi-account environment using AWS Organizations and AWS Control Tower (AWS Blog Page)

PART 1. Best Practices for... Governance, risk, and compliance when establishing your cloud presence

• Check the Management and Governance Lens (A Well-Architected Lens extension) This is built up from years of migrations and best practices learned along the way

Introducing a Landing Zone

• Separation of concerns get more important and also difficult as companies grow in AWS
• Separate costs for budgets and billing
• Security enforcement, resource isolation

A Landing Zone is a...Well-architected multi-account AWS environment that is stable and secure

It is:

• The starting point for your cloud journey
• Built on AWS Organization w/ multiple accounts

Landing Zone Framework

Foundational OUs

Shared Services OU is for things like log archival, networking - Usually the responsibility of central teams

• Infrastructure - Shared IT Services & Networking
• Security - Log Archival, security tools, break-glass / forensics

Additional OUs

• Sandbox OU to allow developers to have their own accountsa to spike/experiment
• Workloads OU to isolate and tightly control production/app services
• etc - These are a guide, pick which fits the company the best

Landing Zone Automation

2 Tools to assist here...

• AWS Control Tower - AWS Managed Service to setup and govern multi-account env ** It uses AWS Organizations and a number of other services to automate the orchestration ** Easier option, minimal customisations; Still allows your to centrally manage governance and has preconfigured best practices
• AWS Organizations - Use this directly, high levels of customisation Personal Note: Check out org-formation or Terraform

PART 2. Best Practices for... Organizational Units with AWS Organizations

• Apply SCPs at an OU Level

• SDLC OUs - Think of having SCPs at each stage of the lifecycle of the application
  
  e.g Different Policies in different Stages/Environments (Dev vs Test)

• Deployments OU - If you have different governance and operational models for CICD compared to accounts in Workloads OU (Prod / SDLC)
  ** Reduces dependency on shared CI/CD environments
  ** Pipelines and CICD should match the operational model of the software service it builds and deploys
  

• Infra OU may looks like this:
  

• Security OU for hosting security-related services, should be managed by Security team(s)
  

• Log Archive - Audits

• ReadOnlyAccess - Humans for Read-Only permission, cross-account role from here

• Breakglass - Humans in rare scenarios/security incidents, special authorisation would be required, all access to this logged in detail

• Tooling - MINIMAL Humans, Master Account for Guard Duty, Security Hub and Amazon Detective...Human Access for Admin purposes only, infrequent
  ** IaC should be heavily used

• Sandbox OU for individuals wanting to play, should limit internet access if possible
  ** Individuals Accounts created in here e.g ColinWillisAccount

• Workloads OUs
  

• Suspended OU - Accounts that are to be deleted from the Organisation
  ** Apply an SCP to deny all actions, add Tags for traceability if they need to be restored
  ** Accounts are permanent deleted after 90 days

• Exceptions OU - Accounts that warrant exceptions to Security or Auditing conditions
  ** SCP may be applied directly to the accounts here

Think Top-Secret Project Account; it may have MORE scrutiny than standard accounts

PART 3. Best Practices for... Managing the multi-account environment using AWS Organizations and AWS Control Tower

Permissions Management

• Once Organization is created, enable AWS SSO
• AWS SSO can recognize existing users and groups who need access
• Prebuild in AWS or use External Identity store (like Azure AD or Okta)
• SCP can restrict boundaries e.g Which AZ a user can work in
• https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html is good to reference

** Preventative guardrails are SCPs that limit actions based on your policies.

** Detection guardrails are AWS Config rules paired with AWS Lambda

*** These detect noncompliant resources and alert you through the Control Tower dashboard for remediation

Security

• AWS offers a feature called Delegated Administration, which allows you to designate an account (such as via Security Tooling Account) ** Use this to then manage the following AWS security and audit services on behalf of the entire organization

AWS Audit Manager - automates the continuous collection of evidence to help you audit your use of cloud services.
AWS Config - detects and provides mitigation recommendations for incorrectly configured resources.
Amazon GuardDuty - detects unexpected and potentially unauthorized and malicious activity in your AWS environment.
Amazon Macie - continuously evaluates your content to identify business-critical or potentially confidential data.
AWS Trusted Advisor - identifies opportunities to improve stability, save money, or help close security gaps.
IAM Access Analyzer - helps you identify any resources or data in your AWS environment that are shared with external entities.
AWS Security Hub - provides you with security checks and recommendations across your organization.

• Security users can then centrally view and manage security events
• NOTE: You may need to enable certain Security Services at the management/organizational account level

Account Management

• After initial Organization setup, new or invited Accounts can be assigned to OUs
• Integrated into AWS Organizations, these help you get accounts ready to use:

** AWS Resource Access Manager - Make resources available cross-account e.g EC2 Capacity Reservation, VPC Endpoints

** AWS CloudFormation StackSets - Share Stacks cross account e.g Automatically delete or create resources when an Account joins or leaves the Organization