Lesson 02 — Secure Multi-Account Architecture, Landing Zones & AWS Security Reference Architecture

Learning Path

☁️ Phase 02 – AWS Cloud Security

📘 Module 12 – AWS Security Architecture

🎯 Lesson Objective

By the end of this lesson, you will be able to:

Explain why enterprises adopt Multi-Account Architecture.
Understand AWS Organizations.
Design Organizational Units (OUs).
Explain AWS Landing Zones.
Understand AWS Control Tower.
Apply the AWS Security Reference Architecture (SRA).
Design enterprise account structures.
Centralize security services.
Centralize logging.
Design identity boundaries.
Separate production from development.
Design secure cross-account access.
Implement governance using Service Control Policies (SCPs).
Reduce blast radius using account isolation.

📚 Lesson Information

Estimated Time: 5–6 Hours

Difficulty: Advanced

Prerequisites: Lesson 01 – AWS Security Architecture Fundamentals

Hands-on Labs: Yes

💼 Business Scenario

CloudNova Technologies has grown significantly.

Current AWS footprint:

140 AWS Accounts
9 AWS Regions
600 Developers
80 DevOps Engineers
50 Security Engineers
Multiple Business Units
Hundreds of Applications
Thousands of AWS Resources

Initially everything existed inside a single AWS account.

Problems soon appeared:

Developers accidentally modified production.
Security teams had AdministratorAccess everywhere.
Billing became difficult.
Logs were mixed together.
Compliance evidence became difficult to collect.
Service quotas were shared.
Security incidents affected multiple workloads.
Testing occasionally disrupted production.

The CIO asks:

“How do companies like Amazon, Netflix and large enterprises organize hundreds of AWS accounts securely?”

As CloudNova’s AWS Security Architect, your task is to redesign the AWS environment following AWS enterprise best practices.

Why Not One AWS Account?

Many beginners start with one account.

Example:

AWS Account

├── Production
├── Development
├── Testing
├── Security
├── Networking
├── Shared Services
└── Sandbox

Initially this seems simple.

However, problems quickly emerge.

Problems with Single Account Architecture

A single account introduces several risks.

Shared IAM permissions
Difficult cost allocation
Shared service quotas
Large blast radius
Poor separation of duties
Compliance challenges
Complex resource management
Difficult auditing
Risk of accidental deletion
Weak isolation

Enterprise Multi-Account Architecture

Instead of one account, CloudNova separates workloads.

AWS Organization

├── Security
├── Infrastructure
├── Shared Services
├── Production
├── Development
├── Testing
└── Sandbox

Each account has a dedicated purpose.

Benefits of Multi-Account Design

CloudNova gains:

Better Security
Better Governance
Easier Compliance
Cost Visibility
Service Quota Isolation
Reduced Blast Radius
Independent Teams
Easier Automation
Safer Experimentation
Better Incident Response

AWS Organizations

AWS Organizations allows enterprises to centrally manage multiple AWS accounts.

Features include:

Centralized Billing
Organizational Units
Service Control Policies
Account Provisioning
Delegated Administration
Governance
Compliance

AWS Organization

↓

Multiple AWS Accounts

↓

Central Governance

AWS Organization Components

Every AWS Organization contains:

Management Account

↓

Organizational Units

↓

AWS Accounts

↓

Policies

Management Account

The Management Account is responsible for:

Creating AWS Accounts
Billing
Governance
Policy Management
Consolidated Billing
Organization Administration

Best Practice:

Never deploy production workloads inside the Management Account.

Organizational Units (OUs)

Organizational Units logically group AWS accounts.

Example:

Organization

├── Security OU
├── Infrastructure OU
├── Production OU
├── Development OU
├── Sandbox OU

Policies are applied at the OU level.

Example CloudNova Organization

AWS Organization

│

├── Management Account

│

├── Security OU

│     ├── Log Archive

│     ├── Security Tooling

│

├── Infrastructure OU

│     ├── Network

│     ├── Shared Services

│

├── Production OU

│     ├── Banking

│     ├── Retail

│     ├── Healthcare

│

├── Development OU

│     ├── Dev Banking

│     ├── Dev Retail

│

├── Testing OU

│

└── Sandbox OU

Why Separate OUs?

Each OU can have different:

SCPs
Security Controls
Compliance Requirements
IAM Standards
Guardrails

AWS Landing Zone

A Landing Zone is a pre-configured secure AWS environment.

It provides:

Governance
Identity
Logging
Networking
Security Baselines
Account Factory
Compliance

Think of it as:

A secure foundation before applications are deployed.

AWS Control Tower

AWS Control Tower automates Landing Zone deployment.

It provisions:

AWS Organizations
Organizational Units
AWS Accounts
Guardrails
Identity Integration
Audit Accounts
Log Archive Accounts

AWS Control Tower

↓

Landing Zone

↓

Secure AWS Organization

Landing Zone Components

CloudNova’s Landing Zone contains:

Identity

↓

AWS Organizations

↓

Networking

↓

Logging

↓

Security

↓

Account Factory

↓

Governance

Account Factory

Account Factory allows teams to create new AWS accounts using standardized configurations.

Every account receives:

Naming Standards
Logging
IAM Baselines
Security Controls
Networking
SCPs

AWS Security Reference Architecture (SRA)

AWS SRA is AWS’s recommended enterprise architecture.

It defines:

Account Structure
Security Services
Logging
Identity
Networking
Governance

AWS SRA High-Level Structure

AWS Organization

│

├── Management Account

│

├── Security OU

│     ├── Log Archive

│     ├── Security Tooling

│

├── Infrastructure OU

│     ├── Network

│     ├── Shared Services

│

├── Workloads OU

│     ├── Production

│     ├── Development

│     ├── Testing

│

└── Sandbox OU

Security OU

Purpose:

Protect enterprise security services.

Contains:

Security Hub
GuardDuty
Inspector
IAM Identity Center Administration
Detective
Incident Response

Log Archive Account

Purpose:

Centralized immutable logging.

Stores:

CloudTrail
Config
VPC Flow Logs
DNS Logs
Security Logs
Audit Logs

Best Practice:

No application workloads.

Security Tooling Account

Purpose:

Operate security services.

Contains:

Security Hub
GuardDuty
Detective
IAM Access Analyzer
Amazon Inspector
Incident Response Tools

Infrastructure OU

Contains shared enterprise services.

Examples:

Transit Gateway
DNS
Directory Services
Shared CI/CD
Shared Monitoring

Network Account

Purpose:

Central networking.

Contains:

Transit Gateway
VPN
Direct Connect
Network Firewall
Route53 Resolver
Shared VPC Services

Shared Services Account

Hosts:

Shared CI/CD
Internal DNS
Shared Artifacts
Shared Container Registry
Patch Management
Shared Monitoring

Production OU

Contains:

Banking
Payments
HR
CRM
ERP

Each application can have its own AWS Account.

Development OU

Contains:

Development Accounts
QA Accounts
Integration Accounts

Developers cannot directly modify Production.

Sandbox OU

Purpose:

Experimentation.

Policies are more relaxed but isolated.

Security Architecture

                    AWS Organization

                           │

        ┌──────────────────┼─────────────────┐

        │                  │                 │

   Security OU      Infrastructure OU     Workloads OU

        │                  │                 │

 Log Archive      Network Account      Production

 Security Tools   Shared Services      Development

                                       Testing

                                       Sandbox

Cross-Account Access

Instead of sharing credentials:

Use IAM Roles.

Developer

↓

IAM Identity Center

↓

Assume Role

↓

Development Account

↓

Temporary Credentials

Never share IAM Users across accounts.

Why Cross-Account Roles?

Benefits:

Least Privilege
Temporary Credentials
Better Auditing
Easy Revocation
Central Identity

Service Control Policies (SCPs)

SCPs define the maximum permissions allowed.

Think of SCPs as:

Enterprise Guardrails

Even if IAM allows an action:

SCP can deny it.

Example SCP

Prevent deleting CloudTrail.

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Effect":"Deny",
      "Action":[
        "cloudtrail:DeleteTrail"
      ],
      "Resource":"*"
    }
  ]
}

SCP Hierarchy

Organization

↓

OU

↓

AWS Account

↓

IAM Policy

↓

Resource Policy

SCPs affect every account underneath.

Enterprise Guardrails

CloudNova enforces:

Root Account Protection
CloudTrail Mandatory
Config Mandatory
MFA
Encryption
Region Restrictions
Public S3 Restrictions
IAM Restrictions

Identity Architecture

CloudNova uses:

Corporate Identity Provider

↓

IAM Identity Center

↓

Permission Sets

↓

AWS Accounts

↓

IAM Roles

Developers receive temporary access only.

Centralized Logging

All logs flow into Log Archive.

AWS Accounts

↓

CloudTrail

↓

CloudWatch

↓

S3 Log Archive

↓

Security Team

Centralized Security

Security findings from all accounts are aggregated.

AWS Accounts

↓

Security Hub

↓

GuardDuty

↓

Inspector

↓

Security Tooling Account

Blast Radius Reduction

Bad Architecture:

One Account

↓

Compromise

↓

Everything Impacted

Good Architecture:

One Production Account

↓

Compromise

↓

One Application Impacted

Cost Management

Separate accounts allow:

Chargeback
Cost Allocation
Budgeting
Billing Reports

Compliance Benefits

Separate accounts simplify:

PCI DSS
HIPAA
ISO 27001
SOC 2
GDPR

Evidence is easier to collect.

Enterprise Best Practices

CloudNova standards:

Multiple AWS Accounts
Dedicated Security OU
Dedicated Network Account
Dedicated Log Archive
IAM Identity Center
Temporary Credentials
SCPs
Landing Zone
Control Tower
Central Logging
Central Security Monitoring
Infrastructure as Code

🛠 Lab 01 — Create an AWS Organization Design

Design an organization containing:

Security OU
Infrastructure OU
Production OU
Development OU
Sandbox OU

Deliver:

Architecture diagram.

🛠 Lab 02 — Design Organizational Units

Create OUs for:

Security
Infrastructure
Production
Development
Sandbox

Explain why each exists.

🛠 Lab 03 — Design SCPs

Create SCPs for:

Block Root Usage
Block CloudTrail Deletion
Restrict Regions
Prevent Public S3
Mandatory Encryption

🛠 Lab 04 — Design Landing Zone

Include:

AWS Organizations
Control Tower
IAM Identity Center
Security Hub
GuardDuty
Log Archive
Shared Services

🛠 Lab 05 — Design Cross-Account Access

Document:

Identity Provider
IAM Identity Center
Permission Sets
IAM Roles
Temporary Credentials

🛠 Lab 06 — Build CloudNova Enterprise Architecture

Design a complete AWS SRA architecture.

Include:

Security OU
Infrastructure OU
Workload OU
Logging
Monitoring
Networking
Identity

💻 AWS CLI Lab

Verify AWS Identity

aws sts get-caller-identity

List AWS Organization Accounts

aws organizations list-accounts

List Organizational Units

aws organizations list-organizational-units-for-parent \
--parent-id ROOT_ID

List SCPs

aws organizations list-policies \
--filter SERVICE_CONTROL_POLICY

List Attached SCPs

aws organizations list-policies-for-target \
--target-id OU_ID \
--filter SERVICE_CONTROL_POLICY

Describe Organization

aws organizations describe-organization

List GuardDuty Detectors

aws guardduty list-detectors

Describe Security Hub

aws securityhub describe-hub

Describe Control Tower Landing Zone

aws controltower get-landing-zone \
--landing-zone-identifier LANDING_ZONE_ID

✅ Verification

Verify that you understand:

✔ AWS Organizations

✔ Organizational Units

✔ AWS Landing Zones

✔ AWS Control Tower

✔ AWS Security Reference Architecture

✔ SCPs

✔ Cross-Account Roles

✔ Centralized Logging

✔ Centralized Security

✔ Enterprise Governance

✔ Blast Radius Reduction

🔍 Troubleshooting

Problem

Developers can modify Production.

Verify:

IAM Roles
SCPs
Permission Sets
Cross-Account Trust

Problem

CloudTrail deleted.

Verify:

SCP
IAM Policies
Organization Policies

Problem

Logs not centralized.

Verify:

CloudTrail
S3 Policies
Organization Trails
Bucket Permissions

🚫 Common Mistakes

❌ One AWS Account for everything

❌ Shared IAM Users

❌ Root Account usage

❌ AdministratorAccess everywhere

❌ No SCPs

❌ Public workloads in Security Accounts

❌ Mixing Security and Production

❌ Manual account creation

🧪 DIY Enterprise Challenge

Design an AWS Organization supporting:

500 AWS Accounts
Multi-Region
PCI DSS
HIPAA
Financial Services
Global Operations
Central Security
Landing Zone
AWS Control Tower
Zero Trust

Prepare:

AWS Organization Structure
OU Design
SCP Strategy
Identity Architecture
Landing Zone Design
Logging Architecture
Security Architecture
Executive Presentation

📊 Knowledge Check

Why do enterprises use multiple AWS accounts?
What is AWS Organizations?
What is an Organizational Unit?
What is a Landing Zone?
What does AWS Control Tower automate?
What is the AWS Security Reference Architecture?
Why should production be isolated?
What is a Log Archive account?
What is a Security Tooling account?
What are Service Control Policies?
How are SCPs different from IAM policies?
Why use cross-account IAM roles?
Why centralize logging?
Why centralize security services?
How does multi-account architecture reduce blast radius?

💡 Key Takeaways

After completing this lesson, you should understand:

AWS Organizations provides the foundation for managing multiple AWS accounts through centralized governance, billing and policy management.
Organizational Units (OUs) allow accounts with similar security and operational requirements to be grouped so that governance controls, including Service Control Policies (SCPs), can be consistently applied.
AWS Landing Zones and AWS Control Tower provide a standardized, automated way to establish secure enterprise environments with identity, logging, networking and governance configured from the beginning.
The AWS Security Reference Architecture (SRA) recommends dedicated accounts for management, security tooling, log archiving, networking, shared services and workloads to reduce operational risk and improve security.
Cross-account IAM roles and IAM Identity Center provide temporary, auditable access without sharing long-term credentials across AWS accounts.
Centralized logging and security monitoring enable security teams to detect, investigate and respond to threats across the entire organization from dedicated security accounts.
Multi-account architecture significantly reduces blast radius, improves compliance, simplifies cost management and supports secure growth as cloud environments scale.

🚀 Next Lesson

➡️ Lesson 03 — Enterprise Network Segmentation, VPC Design & Secure Connectivity