Project 01 — Enterprise AWS Landing Zone Project

Learning Path

☁️ Phase 02 – AWS Cloud Security

🚀 Enterprise Cloud Security Projects & Capstone Labs

🎯 Lesson Objective

In this project, you will work as CloudNova Technologies’ Lead Cloud Security Engineer and design an enterprise AWS landing zone.

You will move beyond creating individual AWS accounts and build a governed multi-account environment that supports:

Centralised identity
Account isolation
Security governance
Centralised logging
Compliance monitoring
Automated account provisioning
Workload separation
Multi-Region operations
Security operations
Enterprise scalability

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

Explain the purpose of an enterprise AWS landing zone.
Design an AWS multi-account strategy.
Build an organisational unit hierarchy.
Understand AWS Organizations architecture.
Explain AWS Control Tower architecture.
Identify the purpose of shared AWS accounts.
Design a dedicated Security organisational unit.
Design Infrastructure, Workloads and Sandbox organisational units.
Implement Service Control Policies.
Configure IAM Identity Center.
Design permission sets for enterprise teams.
Configure centralised logging.
Configure security and audit accounts.
Establish account provisioning standards.
Design account vending and lifecycle processes.
Define tagging and naming standards.
Create landing-zone governance documentation.
Build a professional enterprise architecture proposal.

📚 Lesson Information

Area	Details
Project	CloudNova Enterprise AWS Landing Zone
Project Type	Architecture, Governance and Implementation
Estimated Time	12–16 Hours
Difficulty	Advanced
Delivery Mode	DIY or Instructor-Led
Primary Services	AWS Organizations, AWS Control Tower, IAM Identity Center
Supporting Services	CloudTrail, AWS Config, CloudWatch, S3, KMS, Security Hub, GuardDuty
Main Deliverable	Enterprise AWS Landing Zone Design
Environment	Dedicated training or sandbox AWS environment
Prerequisite	Completion of Modules 01–13

🏢 Business Scenario

CloudNova Technologies is expanding its cloud operations across several countries.

The organisation currently has separate AWS accounts created independently by different teams.

Existing accounts include:

Development accounts
Testing accounts
Production accounts
Data analytics accounts
Security accounts
Research accounts
Proof-of-concept accounts

There is no consistent account structure.

Each business unit manages its AWS environment differently.

The internal audit team has identified the following problems:

Root users are still used for administration.
AWS accounts do not follow a consistent naming standard.
Centralised logging is incomplete.
Security teams cannot access every account during investigations.
Production and development workloads are mixed.
Developers can deploy resources in unapproved AWS Regions.
Some accounts do not have GuardDuty enabled.
Some accounts do not send CloudTrail logs to the security team.
Former employees may still have account-level access.
New accounts are created without security baselines.
No formal account closure process exists.
Compliance reporting requires manual evidence collection.
Security policies are implemented differently across accounts.

CloudNova plans to grow to more than 500 AWS accounts over the next three years.

The Chief Information Security Officer asks:

“How can we create a secure AWS foundation where every new account automatically receives identity, logging, security and governance controls?”

You have been assigned to lead the CloudNova Enterprise AWS Landing Zone Project.

🧑‍💼 Your Role

You are working as the:

Lead Cloud Security Engineer

Your responsibilities include:

Gathering business and security requirements.
Designing the AWS organisation.
Defining the organisational unit hierarchy.
Selecting shared service accounts.
Designing centralised identity.
Establishing governance controls.
Creating account provisioning standards.
Defining security guardrails.
Documenting the architecture.
Presenting the design to technical and executive stakeholders.

1. Understanding an AWS Landing Zone

An AWS landing zone is a governed multi-account environment that provides a secure foundation for deploying cloud workloads.

It establishes standard controls for:

Account creation
Identity and access
Network connectivity
Logging
Monitoring
Security operations
Compliance
Resource governance
Billing
Workload isolation

A landing zone is not a single AWS service.

It is an enterprise operating model implemented using multiple AWS services, processes and governance standards.

2. Why Enterprises Use Multiple AWS Accounts

An AWS account acts as an important security, operational and billing boundary.

CloudNova will separate workloads into multiple accounts to provide:

Security isolation
Reduced blast radius
Independent resource quotas
Separate billing visibility
Environment separation
Business-unit separation
Compliance boundaries
Simplified access management
Independent incident containment

Example Account Separation

CloudNova Technologies

├── Security Accounts
├── Infrastructure Accounts
├── Development Accounts
├── Testing Accounts
├── Production Accounts
├── Data Platform Accounts
├── Sandbox Accounts
└── Suspended Accounts

Mixing all workloads inside one account would make access control, cost allocation, incident response and compliance significantly more difficult.

3. Landing Zone Design Principles

CloudNova will use the following principles:

Principle 1 — Separate Workloads by Account

Production, development, testing and security workloads must not share the same AWS account.

Principle 2 — Protect the Management Account

The AWS Organizations management account will be used only for organisation-level activities.

Business workloads will not run inside the management account.

Principle 3 — Centralise Identity

Human access will use IAM Identity Center and enterprise identity federation.

Long-term IAM users will be avoided wherever practical.

Principle 4 — Centralise Security Visibility

Security findings, audit logs and compliance information will be made available to authorised security teams.

Principle 5 — Automate Account Provisioning

New accounts will be created through an approved account provisioning process.

Principle 6 — Apply Preventive Governance

Service Control Policies and Control Tower controls will restrict high-risk activity.

Principle 7 — Preserve Evidence

Security logs will be protected from alteration or deletion by workload administrators.

Principle 8 — Design for Scale

The structure must support hundreds of accounts without requiring manual configuration in each account.

4. Target Enterprise Architecture

CloudNova Corporate Identity Provider
                 |
                 v
       AWS IAM Identity Center
                 |
                 v
      AWS Organizations Management
                 |
                 v
         AWS Control Tower
                 |
     +-----------+-------------------+
     |           |                   |
     v           v                   v
 Security OU  Infrastructure OU  Workloads OU
     |           |                   |
     |           |                   +-- Development OU
     |           |                   +-- Testing OU
     |           |                   +-- Production OU
     |           |
     |           +-- Network Account
     |           +-- Shared Services Account
     |           +-- Platform Account
     |
     +-- Log Archive Account
     +-- Audit Account
     +-- Security Tooling Account
                 |
                 v
       Central Security Operations

5. AWS Organizations

AWS Organizations provides the foundation for centrally managing CloudNova’s AWS accounts.

It allows CloudNova to:

Create and manage AWS accounts.
Group accounts into organisational units.
Apply policies centrally.
Consolidate billing.
Delegate supported administrative services.
Establish organisation-wide governance.

Core Components

Component	Purpose
Organisation	The complete collection of CloudNova AWS accounts
Management Account	The account that owns and manages the organisation
Member Account	An AWS account belonging to the organisation
Organisational Unit	A logical group of accounts
Root	The top-level parent of all organisational units and accounts
Service Control Policy	A policy that defines permission boundaries for accounts
Delegated Administrator	A member account authorised to administer a supported AWS service

6. Management Account Security

The management account is the most sensitive account in the AWS organisation.

Compromise of this account could affect organisation-wide governance.

CloudNova standards require:

No business workloads in the management account.
Root-user MFA.
Hardware-backed or phishing-resistant MFA where available.
No root access keys.
Restricted management-account access.
Dedicated emergency access procedures.
Centralised CloudTrail logging.
Monitoring of all management-account activity.
Separate administrative roles.
Formal approval for organisation-level changes.
Delegation of supported services to member accounts.

Management Account Activities

The management account may be used for:

AWS Organizations administration
AWS Control Tower administration
Organisation billing
Delegated administrator registration
Organisation policy management
Emergency governance operations

It should not be used for:

Hosting applications
Running EC2 workloads
Storing business data
Development activities
CI/CD workloads
General security operations

7. AWS Control Tower

AWS Control Tower helps establish and govern an AWS multi-account landing zone.

It brings together AWS services such as:

AWS Organizations
IAM Identity Center
AWS CloudTrail
AWS Config
AWS Service Catalog
AWS Control Tower controls

Key Control Tower Capabilities

Capability	Purpose
Landing Zone	Establishes the governed multi-account foundation
Controls	Applies governance requirements
Account Factory	Standardises account provisioning
Dashboard	Provides visibility into governed accounts and controls
Organisational Unit Registration	Brings OUs under Control Tower governance
Account Enrolment	Enrols accounts into the landing zone

8. AWS Control Tower Controls

Controls help CloudNova establish governance requirements.

Control categories may include:

Preventive controls
Detective controls
Proactive controls

Preventive Controls

Preventive controls stop prohibited actions from succeeding.

Examples:

Restricting unapproved AWS Regions
Preventing CloudTrail configuration changes
Preventing deletion of security logs
Restricting changes to shared security accounts

Detective Controls

Detective controls identify resources that do not meet expected requirements.

Examples:

Detecting public S3 buckets
Detecting unencrypted storage
Detecting unrestricted security groups
Detecting resources without required configurations

Proactive Controls

Proactive controls evaluate supported resources before deployment.

They can help prevent non-compliant Infrastructure as Code resources from being provisioned.

9. Shared Enterprise Accounts

CloudNova will establish dedicated shared accounts.

9.1 Management Account

Purpose:

Organisation governance
Control Tower management
Consolidated billing
Organisation-level administration

9.2 Log Archive Account

Purpose:

Central security log storage
CloudTrail log retention
AWS Config log retention
Audit evidence preservation
Long-term forensic evidence

Workload administrators must not receive permission to delete central logs.

9.3 Audit Account

Purpose:

Security and compliance access
Cross-account audit roles
Investigation access
Compliance reviews
Security assessment activities

9.4 Security Tooling Account

Purpose:

GuardDuty delegated administration
Security Hub delegated administration
Amazon Inspector delegated administration
Detective administration
Security Lake administration
Security automation
SOC integrations

CloudNova may use the Audit account or a separate Security Tooling account depending on operational requirements and separation-of-duties decisions.

9.5 Network Account

Purpose:

Transit Gateway
Network Firewall
Centralised routing
DNS services
Shared VPC endpoints
Hybrid connectivity
Network monitoring

9.6 Shared Services Account

Purpose:

Directory services
Shared automation
Common application services
Enterprise tooling
Internal package repositories
Shared operational services

10. Organisational Unit Design

Organisational units group accounts with similar governance requirements.

CloudNova’s proposed structure is:

Root

├── Security OU
│   ├── Log Archive Account
│   ├── Audit Account
│   └── Security Tooling Account
│
├── Infrastructure OU
│   ├── Network Account
│   ├── Shared Services Account
│   └── Platform Engineering Account
│
├── Workloads OU
│   ├── Development OU
│   ├── Testing OU
│   └── Production OU
│
├── Data OU
│   ├── Data Development Account
│   ├── Data Testing Account
│   └── Data Production Account
│
├── Sandbox OU
│   └── Individual Sandbox Accounts
│
├── Policy Staging OU
│   └── Governance Test Accounts
│
└── Suspended OU
    └── Closed or Quarantined Accounts

11. Organisational Unit Purpose

Organisational Unit	Purpose
Security	Central logging, security monitoring and audit
Infrastructure	Shared network and platform services
Development	Application development workloads
Testing	Integration, quality and security testing
Production	Customer-facing and business-critical workloads
Data	Data engineering, analytics and machine learning
Sandbox	Controlled experimentation and individual learning
Policy Staging	Testing SCPs and governance changes
Suspended	Isolating accounts pending closure or investigation

12. Workload Account Strategy

CloudNova will use account-per-environment separation.

Example:

Customer Portal Application

├── customer-portal-development
├── customer-portal-testing
└── customer-portal-production

For highly regulated applications, additional separation may be introduced:

Payment Platform

├── payment-development
├── payment-security-testing
├── payment-pre-production
├── payment-production
└── payment-disaster-recovery

13. Account Naming Standard

CloudNova account names will follow a consistent format.

<organisation>-<business-unit>-<application>-<environment>

Examples:

cloudnova-finance-payments-production
cloudnova-finance-payments-development
cloudnova-security-tooling
cloudnova-infrastructure-network
cloudnova-data-analytics-production

Account Email Standard

Each account must use a controlled corporate email address.

Examples:

aws+security-tooling@cloudnova.example
aws+log-archive@cloudnova.example
aws+network@cloudnova.example
aws+payments-prod@cloudnova.example

Individual employee email addresses must not be used as permanent AWS account root addresses.

14. Account Metadata

Every account request must include:

Metadata	Example
Account Name	cloudnova-finance-payments-production
Business Owner	Director of Digital Payments
Technical Owner	Payments Platform Team
Security Owner	Cloud Security Engineering
Environment	Production
Data Classification	Confidential
Cost Centre	FIN-220
Compliance Scope	PCI DSS
Primary Region	eu-west-2
Disaster Recovery Region	eu-west-1
Support Tier	Critical
Expected Lifecycle	Long-term

15. Account Factory

Account Factory provides a standard method for provisioning governed AWS accounts.

CloudNova’s account vending process will:

Receive an approved account request.
Validate ownership and business justification.
Select the correct organisational unit.
Create the AWS account.
Apply the required security baseline.
Configure IAM Identity Center access.
Enable centralised logging.
Enable required security services.
Apply mandatory tags.
Register the account in the asset inventory.
Notify the account owner.
Record account acceptance evidence.

16. Account Provisioning Workflow

Business Account Request
          |
          v
Manager Approval
          |
          v
Security and Architecture Review
          |
          v
Account Factory
          |
          v
AWS Account Created
          |
          v
OU and Governance Applied
          |
          v
Identity Permission Sets Assigned
          |
          v
Security Baseline Deployed
          |
          v
Logging and Monitoring Verified
          |
          v
Account Handover

17. IAM Identity Center Architecture

IAM Identity Center will provide central workforce access to CloudNova AWS accounts.

Corporate Identity Provider

        |

SAML / Identity Integration

        |

AWS IAM Identity Center

        |

Users and Groups

        |

Permission Sets

        |

AWS Accounts

        |

Temporary Role Sessions

Example Groups

AWS-Cloud-Platform-Administrators
AWS-Cloud-Security-Engineers
AWS-SOC-Analysts
AWS-Network-Engineers
AWS-Developers
AWS-Auditors
AWS-Finance-Viewers
AWS-ReadOnly-Support

18. Permission Set Design

Permission Set	Intended Users	Access Level
PlatformAdministrator	Cloud platform team	Broad platform administration
SecurityAdministrator	Cloud security engineers	Security service administration
SOCAnalyst	SOC team	Security investigation access
NetworkAdministrator	Network engineering	Network administration
DeveloperPowerUser	Application developers	Development workload access
ProductionReadOnly	Developers and support	Read-only production access
Auditor	Internal and external auditors	Compliance and evidence access
BillingViewer	Finance team	Billing and cost visibility
EmergencyAdministrator	Approved emergency responders	Time-bound privileged access

19. Separation of Duties

CloudNova will separate responsibilities among different teams.

Team	Responsibility
Cloud Platform	Account provisioning and platform operations
Cloud Security	Security services and governance controls
Network Engineering	Connectivity and network security
SOC	Detection, triage and incident response
Application Teams	Application deployment and support
Internal Audit	Independent control validation
Finance	Billing, budgets and cost reporting

A single team should not independently request, approve, deploy and audit the same high-risk change.

20. Service Control Policies

Service Control Policies define the maximum available permissions within affected organisation entities.

An SCP does not grant permissions.

Permissions must still be granted through IAM policies, roles and permission sets.

Proposed SCP Catalogue

SCP	Purpose
DenyRootUserActions	Restrict root-user actions in member accounts
DenyUnapprovedRegions	Restrict resource deployment to approved Regions
ProtectCloudTrail	Prevent unauthorised CloudTrail changes
ProtectAWSConfig	Prevent unauthorised AWS Config changes
ProtectSecurityServices	Prevent disabling required security services
ProtectLogArchive	Prevent modification of central logging resources
DenyLeavingOrganization	Prevent accounts from leaving the organisation
RequireEncryptedStorage	Support storage encryption governance
RestrictPublicS3	Reduce unauthorised public S3 exposure
SandboxRestrictions	Limit expensive or high-risk sandbox services

21. Example Region Restriction SCP

This example must be tested in a Policy Staging OU before production use. Global AWS services and required exemptions must be carefully considered.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "account:*",
        "billing:*",
        "budgets:*",
        "cloudfront:*",
        "iam:*",
        "organizations:*",
        "route53:*",
        "support:*",
        "waf:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "eu-west-2",
            "eu-west-1"
          ]
        }
      }
    }
  ]
}

22. Example Protection SCP

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectCloudTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/CloudNovaSecurityAdministrationRole"
          ]
        }
      }
    }
  ]
}

23. SCP Deployment Safety

An incorrect SCP can interrupt production operations.

CloudNova will follow this deployment process:

SCP Draft

↓

Peer Review

↓

Security Architecture Review

↓

Policy Staging OU

↓

Test Account Validation

↓

Application Owner Approval

↓

Limited OU Deployment

↓

Monitoring

↓

Production Rollout

SCP Safety Checklist

Confirm the business objective.
Identify affected accounts.
Review global AWS services.
Review service-linked roles.
Test emergency-access roles.
Validate automation pipelines.
Check logging and security dependencies.
Deploy to a test OU first.
Monitor denied API activity.
Maintain a rollback procedure.

24. Centralised Logging Architecture

Member AWS Accounts

├── CloudTrail Events
├── AWS Config Records
├── VPC Flow Logs
├── Security Findings
└── Application Security Logs
              |
              v
      Log Archive Account
              |
       Encrypted S3 Storage
              |
      Retention and Protection
              |
              v
    Security and Audit Access

CloudNova logging requirements include:

Organisation-wide CloudTrail
Multi-Region logging
Central log storage
KMS encryption
Restricted deletion
Retention policies
Integrity validation
Security monitoring
Audit access
Incident evidence preservation

25. Security Services Architecture

AWS Member Accounts
        |
        +-- GuardDuty
        +-- Security Hub
        +-- AWS Config
        +-- Amazon Inspector
        +-- IAM Access Analyzer
        |
        v
Security Tooling Account
        |
        +-- Central Findings
        +-- Security Automation
        +-- SOC Integrations
        +-- Incident Response
        |
        v
Amazon Security Lake / SIEM

26. Region Strategy

CloudNova must define:

Home Region
Governed Regions
Workload Regions
Disaster-recovery Regions
Restricted Regions
Data-residency requirements

Example Region Standard

Workload	Primary Region	Recovery Region
United Kingdom Operations	eu-west-2	eu-west-1
European Operations	eu-central-1	eu-west-1
Asia-Pacific Operations	ap-south-1	ap-southeast-1

Region decisions must consider:

Regulatory requirements
Data residency
Service availability
Business latency
Disaster recovery
Operational support
Security monitoring
Cost

27. Tagging Standard

Mandatory tags:

Tag	Example
Organisation	CloudNova
BusinessUnit	Finance
Application	Payments
Environment	Production
Owner	PaymentsPlatform
CostCentre	FIN-220
DataClassification	Confidential
Compliance	PCI-DSS
ManagedBy	Terraform
Criticality	Critical

Tags support:

Cost allocation
Resource ownership
Incident response
Automation
Compliance
Backup policies
Patch management
Asset inventory

28. Network Foundation Considerations

The landing zone must prepare for:

Centralised networking
Transit Gateway
Shared VPC endpoints
Central DNS
Network Firewall
Hybrid connectivity
Inspection VPCs
Internet egress control
Cross-account resource sharing
Network logging

Detailed network implementation will be completed in:

Lesson 03 — Enterprise Network Security Project

29. Account Security Baseline

Every CloudNova account must receive:

Root-user MFA
Root-user monitoring
Organisation CloudTrail
AWS Config
GuardDuty
Security Hub
Amazon Inspector where applicable
IAM Access Analyzer
Central security findings
Centralised logs
Approved IAM Identity Center access
Default encryption controls
Required budgets and alerts
Mandatory tags
Incident response roles
Backup policies where applicable

30. Account Lifecycle Management

Account States

Requested

↓

Approved

↓

Provisioned

↓

Configured

↓

Operational

↓

Suspended

↓

Closed

Account Closure Requirements

Before closing an account:

Confirm business-owner approval.
Preserve required logs.
Export required evidence.
Back up required data.
Remove active workloads.
Review active subscriptions.
Revoke identity access.
Remove network connections.
Confirm legal retention requirements.
Move the account to the Suspended OU.
Apply restrictive SCPs.
Record closure approval.
Monitor the account during the closure period.

31. Landing Zone Threat Model

Threat	Potential Impact	Primary Control
Management account compromise	Organisation-wide control loss	Strong MFA and restricted access
Root-user misuse	Uncontrolled privileged activity	Root monitoring and restrictions
Account created outside process	Missing security baseline	Account Factory
Security service disabled	Loss of detection capability	SCPs and monitoring
Log deletion	Loss of audit evidence	Dedicated Log Archive account
Unapproved Region usage	Compliance and visibility gaps	Region restriction controls
Excessive developer access	Production compromise	Permission sets and separation
Account leaves organisation	Loss of governance	Preventive SCP
Misconfigured SCP	Production interruption	Policy Staging OU
Orphaned account	Security and billing exposure	Account inventory and ownership

32. Enterprise Landing Zone Implementation Phases

Phase 1 — Discovery

Identify existing AWS accounts.
Identify account owners.
Identify existing workloads.
Review regulatory requirements.
Review identity architecture.
Review network connectivity.
Review logging requirements.
Identify migration risks.

Phase 2 — Design

Design the organisation.
Design organisational units.
Select shared accounts.
Define naming standards.
Define Region strategy.
Design IAM Identity Center.
Define SCPs.
Define logging architecture.
Define security services.

Phase 3 — Build

Configure AWS Organizations.
Deploy AWS Control Tower.
Configure shared accounts.
Configure IAM Identity Center.
Register organisational units.
Configure Account Factory.
Deploy security baselines.
Configure central logging.

Phase 4 — Validate

Verify account access.
Verify CloudTrail delivery.
Verify AWS Config.
Verify security-service integration.
Test SCPs.
Test emergency access.
Test new-account provisioning.
Confirm audit visibility.

Phase 5 — Migrate

Assess existing accounts.
Resolve prerequisites.
Enrol eligible accounts.
Move accounts to the correct OUs.
Apply controls gradually.
Validate workloads after migration.

Phase 6 — Operate

Monitor landing-zone drift.
Review account inventory.
Review Control Tower controls.
Review SCP effectiveness.
Audit privileged access.
Maintain account ownership.
Manage exceptions.
Report governance metrics.

🛠 Hands-on Project Labs

Lab 01 — Create the Landing Zone Requirements Document

Mission

Document CloudNova’s business, technical, security and compliance requirements.

Student Actions

Create:

docs/01-requirements/landing-zone-requirements.md

Include:

Business objectives
Current-state problems
Number of planned accounts
Required environments
Identity requirements
Logging requirements
Security requirements
Compliance requirements
Region requirements
Availability requirements
Account lifecycle requirements

Evidence

Completed requirements document
Requirements approval section
Assumptions and constraints

Lab 02 — Design the Organisational Unit Hierarchy

Mission

Create the proposed AWS organisation and OU structure.

Student Actions

Design:

Security OU
Infrastructure OU
Workloads OU
Data OU
Sandbox OU
Policy Staging OU
Suspended OU

For every OU, document:

Purpose
Account types
Security requirements
Applicable SCPs
Access model
Logging requirements

Evidence

OU architecture diagram
OU design table
Governance justification

Lab 03 — Define the Enterprise Account Catalogue

Mission

Identify the AWS accounts required by CloudNova.

Account Catalogue Example

Account	OU	Purpose	Owner
Management	Root	Organisation management	Cloud Platform
Log Archive	Security	Central logging	Cloud Security
Audit	Security	Audit and investigation	Internal Audit
Security Tooling	Security	Security-service administration	Cloud Security
Network	Infrastructure	Central networking	Network Engineering
Shared Services	Infrastructure	Shared enterprise services	Cloud Platform
Payments Development	Development	Application development	Payments Team
Payments Production	Production	Production payments	Payments Team

Evidence

Account catalogue
Account ownership matrix
Account naming standard

Lab 04 — Configure AWS Organizations

Mission

Explore or configure the AWS Organizations structure in a dedicated lab environment.

Console Walkthrough

Sign in using the approved administration role.
Open AWS Organizations.
Review the organisation ID.
Review the management account.
Review the organisation root.
Create the required test OUs.
Create or invite approved test accounts.
Move accounts into the correct test OUs.
Verify account placement.
Document the organisation structure.

Safety Note

Do not perform organisational changes in a business production environment without formal approval.

Lab 05 — Plan the AWS Control Tower Landing Zone

Mission

Create the Control Tower deployment plan.

Student Actions

Document:

Home Region
Governed Regions
Log Archive account
Audit account
Security OU
IAM Identity Center approach
Existing account considerations
Existing organisation considerations
Control selection
Account Factory requirements

Pre-Deployment Checklist

Management account secured
Root MFA enabled
Required email addresses available
Home Region approved
Governed Regions approved
Shared accounts approved
Existing resource conflicts reviewed
Identity strategy approved
Logging retention approved
Budget approved

Lab 06 — Design IAM Identity Center Access

Mission

Design enterprise workforce access.

Student Actions

Create:

Group catalogue
Permission-set catalogue
Account-assignment matrix
Privileged-access workflow
Emergency-access workflow
Joiner, mover and leaver process

Example Assignment Matrix

Group	Development	Testing	Production	Security
Developers	Power User	Read Only	Read Only	No Access
Platform Team	Administrator	Administrator	Administrator	Limited
Security Team	Security Admin	Security Admin	Security Admin	Administrator
Auditors	Read Only	Read Only	Read Only	Read Only

Lab 07 — Build the SCP Catalogue

Mission

Design CloudNova’s preventive governance policies.

Student Actions

Create an SCP catalogue containing:

SCP name
Business purpose
Target OU
Exemptions
Testing plan
Rollback plan
Policy owner
Review frequency

Prepare at least five SCP drafts.

Suggested policies:

Deny leaving the organisation
Protect CloudTrail
Restrict unapproved Regions
Restrict root-user actions
Protect security services

Lab 08 — Design the Central Logging Architecture

Mission

Create the CloudNova organisation-wide logging design.

Student Actions

Document:

Log sources
Destination accounts
S3 structure
KMS strategy
Retention
Access permissions
Integrity controls
Monitoring
Evidence preservation
Incident-access process

Required Diagram

Member Accounts
      |
      v
Organisation CloudTrail
      |
      v
Log Archive Account
      |
      v
Encrypted S3 Buckets
      |
      +-- Security Analytics
      +-- Audit Evidence
      +-- Incident Response
      +-- Long-Term Retention

Lab 09 — Create the Account Provisioning Runbook

Mission

Document the complete process for creating a new AWS account.

Runbook Sections

Request initiation
Required information
Business approval
Security review
OU selection
Account creation
Identity assignment
Security baseline deployment
Validation
Handover
Ownership review
Closure process

Lab 10 — Conduct the Landing Zone Architecture Review

Mission

Present the proposed architecture to the CloudNova Architecture Review Board.

Review Participants

Chief Information Security Officer
Cloud Platform Lead
Cloud Security Architect
Network Architect
Identity Architect
SOC Manager
Compliance Manager
Finance Representative
Application Owner

Review Topics

Business alignment
Security architecture
Account isolation
Identity
Logging
Compliance
Operational model
Cost management
Migration
Risks
Exceptions
Implementation timeline

💻 AWS CLI Exercises

Run these commands only in an authorised training or sandbox environment.

# Display the current AWS identity
aws sts get-caller-identity

# Describe the AWS organisation
aws organizations describe-organization

# List organisation roots
aws organizations list-roots

# List accounts in the organisation
aws organizations list-accounts

# List organisational units under a parent
aws organizations list-organizational-units-for-parent \
  --parent-id r-example

# List accounts under an organisational unit
aws organizations list-accounts-for-parent \
  --parent-id ou-example-12345678

# List available organisation policies
aws organizations list-policies \
  --filter SERVICE_CONTROL_POLICY

# List policies attached to an OU
aws organizations list-policies-for-target \
  --target-id ou-example-12345678 \
  --filter SERVICE_CONTROL_POLICY

# List delegated administrators
aws organizations list-delegated-administrators

# List delegated services
aws organizations list-aws-service-access-for-organization

Example OU Creation Command

aws organizations create-organizational-unit \
  --parent-id r-example \
  --name "Policy-Staging"

Example SCP Creation Command

aws organizations create-policy \
  --name "ProtectCloudTrail" \
  --description "Prevents unauthorised changes to CloudTrail" \
  --type SERVICE_CONTROL_POLICY \
  --content file://protect-cloudtrail.json

Example SCP Attachment Command

aws organizations attach-policy \
  --policy-id p-example123 \
  --target-id ou-example-12345678

✅ Technical Verification Checklist

AWS Organizations

Organisation structure has been documented.
Management account purpose is defined.
Organisational units have approved purposes.
Account placement is documented.
Delegated administrator strategy is defined.

AWS Control Tower

Home Region is approved.
Governed Regions are documented.
Log Archive account is defined.
Audit account is defined.
Account Factory process is documented.
Control-selection process is documented.

Identity

IAM Identity Center strategy is defined.
Groups are documented.
Permission sets are documented.
Account assignments are documented.
Emergency access is documented.
Joiner, mover and leaver processes are documented.

Governance

SCP catalogue exists.
SCP testing process exists.
Policy Staging OU is included.
Exception process is documented.
Rollback procedures are documented.

Logging and Security

Organisation CloudTrail is included.
AWS Config strategy is included.
Log Archive design is complete.
Security Tooling account is included.
Security-service delegation is documented.
Log retention is defined.

Operations

Account provisioning runbook exists.
Account closure runbook exists.
Ownership-review process exists.
Architecture review is complete.
Risks are recorded.

🔧 Troubleshooting Guide

Issue 1 — Unable to Create an Organisational Unit

Possible causes:

Insufficient AWS Organizations permissions
Incorrect parent ID
Organisation feature set not enabled
Service quota reached

Resolution:

Verify the current identity.
Confirm organisation permissions.
Validate the root or OU parent ID.
Review organisation limits.
Check CloudTrail for denied API activity.

Issue 2 — SCP Blocks Required Administration

Possible causes:

Policy attached to the wrong OU
Missing exemption
Incorrect condition
Global service not considered
Administrative role restricted

Resolution:

Review denied CloudTrail events.
Move the test account to the Policy Staging OU.
Correct the policy.
Test with the approved administration role.
Use the documented rollback process.

Issue 3 — Account Does Not Appear in Control Tower

Possible causes:

Account not enrolled
OU not registered
Existing configuration conflicts
Required roles missing
Region configuration mismatch

Resolution:

Review account-enrolment status.
Review OU registration.
Check Control Tower prerequisites.
Review account configuration.
Review the Control Tower console for drift or errors.

Issue 4 — IAM Identity Center Assignment Does Not Work

Possible causes:

Permission set not provisioned
Account assignment missing
Identity-provider synchronisation delay
User placed in the wrong group
Session or browser cache issue

Resolution:

Confirm the user and group.
Confirm account assignment.
Reprovision the permission set.
Review IAM Identity Center audit events.
Start a new sign-in session.

Issue 5 — Central Logs Are Missing

Possible causes:

CloudTrail not configured correctly
S3 bucket policy issue
KMS permissions issue
Organisation trail not enabled
Region not covered
Logging stopped

Resolution:

Verify CloudTrail status.
Confirm the organisation trail.
Review S3 permissions.
Review KMS key permissions.
Check CloudTrail delivery errors.
Confirm all governed Regions.

🏢 Enterprise Best Practices

CloudNova landing-zone standards:

Keep the management account free from workloads.
Protect root users with strong MFA.
Avoid creating root access keys.
Use IAM Identity Center for workforce access.
Use temporary role-based sessions.
Separate production and non-production workloads.
Use dedicated Log Archive and Audit accounts.
Delegate supported security services.
Test SCPs before production deployment.
Use a Policy Staging OU.
Centralise CloudTrail and AWS Config information.
Protect logs from workload administrators.
Automate account provisioning.
Maintain accurate account ownership.
Review account access regularly.
Apply mandatory naming and tagging standards.
Monitor Control Tower drift.
Document exceptions and risk acceptance.
Maintain tested emergency-access procedures.
Review the landing-zone architecture regularly.

🚫 Common Mistakes

Running production workloads in the management account.
Creating one AWS account for the entire organisation.
Applying new SCPs directly to production.
Assuming SCPs grant permissions.
Using individual employee emails for root accounts.
Giving developers unrestricted production access.
Allowing workload administrators to delete security logs.
Enabling only one AWS Region without assessing business requirements.
Creating accounts outside Account Factory.
Failing to assign business and technical owners.
Creating too many organisational units without a governance purpose.
Mixing organisational structure with temporary project structures.
Ignoring existing account-enrolment requirements.
Failing to test emergency access.
Treating Control Tower as a complete security programme by itself.
Failing to document account closure.
Leaving suspended accounts with active access.
Deploying controls without monitoring their operational impact.

📦 Required Project Deliverables

Students must create the following project files:

CloudNova-Enterprise-Security/

└── 01-Enterprise-AWS-Landing-Zone/
    ├── README.md
    ├── 01-Requirements/
    │   ├── Business-Requirements.md
    │   ├── Security-Requirements.md
    │   └── Assumptions-and-Constraints.md
    ├── 02-Architecture/
    │   ├── Landing-Zone-Architecture.md
    │   ├── Organisation-Structure.md
    │   ├── OU-Design.md
    │   └── Account-Architecture.md
    ├── 03-Identity/
    │   ├── IAM-Identity-Center-Design.md
    │   ├── Permission-Sets.md
    │   └── Access-Matrix.md
    ├── 04-Governance/
    │   ├── SCP-Catalogue.md
    │   ├── Control-Catalogue.md
    │   ├── Exception-Process.md
    │   └── Tagging-Standard.md
    ├── 05-Logging/
    │   ├── Central-Logging-Design.md
    │   ├── Log-Retention-Policy.md
    │   └── Evidence-Access-Model.md
    ├── 06-Operations/
    │   ├── Account-Provisioning-Runbook.md
    │   ├── Account-Closure-Runbook.md
    │   ├── Emergency-Access-Runbook.md
    │   └── Landing-Zone-Operations.md
    ├── 07-Risk/
    │   ├── Risk-Register.md
    │   └── Threat-Model.md
    ├── 08-Evidence/
    │   ├── Screenshots/
    │   ├── CLI-Outputs/
    │   └── Validation-Checklist.md
    └── 09-Reports/
        ├── Architecture-Review.md
        ├── Executive-Summary.md
        └── Lessons-Learned.md

🧪 DIY Enterprise Challenge

CloudNova acquires a smaller technology company called DataSphere Labs.

DataSphere currently operates:

25 independent AWS accounts
No AWS Organizations implementation
Local IAM users in every account
Multiple production workloads
Inconsistent CloudTrail configurations
Resources in six AWS Regions
No centralised security account
No formal account ownership
Several legacy applications
Different billing arrangements

Design a migration plan to bring DataSphere into the CloudNova landing zone.

Your submission must include:

Current-state assessment
Account inventory
Account-owner identification process
Identity migration plan
Logging migration plan
Security baseline plan
Organisational unit placement
Region rationalisation
SCP deployment strategy
Account-enrolment sequence
Risk register
Rollback plan
Communication plan
Migration validation checklist
Executive summary

📊 Knowledge Check

Question 1

What is the primary purpose of an enterprise AWS landing zone?

Answer:
To provide a secure, governed and scalable multi-account foundation for deploying and operating AWS workloads.

Question 2

Why should business workloads not run in the AWS Organizations management account?

Answer:
The management account has organisation-wide authority and should have a minimal attack surface. Running workloads there introduces unnecessary operational and security risk.

Question 3

What is the purpose of an organisational unit?

Answer:
An organisational unit groups AWS accounts so that governance policies and controls can be administered consistently.

Question 4

Does a Service Control Policy grant IAM permissions?

Answer:
No. An SCP defines the maximum permissions available to affected accounts. IAM policies and roles must still grant the required permissions.

Question 5

Why is a Policy Staging OU important?

Answer:
It provides a controlled environment where new SCPs and governance policies can be tested before they affect production accounts.

Question 6

What is the purpose of the Log Archive account?

Answer:
It provides centralised and protected storage for organisation-wide security and audit logs.

Question 7

What is the purpose of the Audit account?

Answer:
It supports independent security, compliance and investigation access across governed AWS accounts.

Question 8

Why should production and development use separate AWS accounts?

Answer:
Separate accounts improve security isolation, reduce blast radius, simplify access control and support independent governance.

Question 9

What problem does Account Factory solve?

Answer:
It standardises and automates the provisioning of governed AWS accounts.

Question 10

Why should IAM Identity Center be used for workforce access?

Answer:
It centralises user and group access, supports temporary role sessions and simplifies multi-account access management.

Question 11

What is delegated administration?

Answer:
It allows a designated member account to administer a supported AWS service without requiring routine access to the management account.

Question 12

Why should SCP changes follow change management?

Answer:
An incorrect SCP can deny required actions across many AWS accounts and potentially disrupt business workloads.

Question 13

What is an account security baseline?

Answer:
It is the minimum set of identity, logging, monitoring, encryption and security controls applied to every AWS account.

Question 14

Why is account ownership metadata important?

Answer:
It ensures that business, technical, security and financial responsibilities remain assigned throughout the account lifecycle.

Question 15

What should happen before an AWS account is closed?

Answer:
Required data and logs should be preserved, access removed, workloads decommissioned, approvals recorded and legal or regulatory retention requirements confirmed.

Question 16

Why should central logs be inaccessible to workload administrators?

Answer:
This reduces the risk that a compromised or malicious workload administrator can alter or delete investigation evidence.

Question 17

What is the difference between an OU and an AWS account?

Answer:
An OU is a logical governance container, while an AWS account is a security, operational and billing boundary that contains resources.

Question 18

What is the purpose of the Suspended OU?

Answer:
It isolates accounts that are being investigated, decommissioned or prepared for closure under restrictive controls.

Question 19

Why should Regions be governed?

Answer:
Ungoverned Regions can create security-monitoring gaps, regulatory issues, unexpected costs and unsupported operational environments.

Question 20

What is the final outcome of this project?

Answer:
A documented and review-ready enterprise AWS landing-zone design covering accounts, organisational units, identity, governance, logging, security operations and account lifecycle management.

💡 Key Takeaways

After completing this lesson, you should understand that an enterprise AWS landing zone is much more than an AWS Organizations hierarchy.

It combines:

Multi-account architecture
Organisational units
Shared security accounts
Centralised identity
Preventive governance
Centralised logging
Automated account provisioning
Security-service delegation
Account lifecycle management
Operational governance

A well-designed landing zone gives CloudNova a secure foundation on which every future application, security service, network and cloud platform capability can be built.

🎓 Project Completion Criteria

You have completed this project when:

The organisation structure is documented.
The OU design is justified.
Shared accounts are defined.
The account catalogue is complete.
IAM Identity Center access is designed.
The SCP catalogue is prepared.
The central logging architecture is complete.
Account provisioning and closure runbooks exist.
The risk register is complete.
The architecture review has been conducted.
All required evidence is stored in the project repository.
The executive summary is ready for presentation.

🚀 Next Lesson

➡️ Lesson 02 — Enterprise Identity & Zero Trust Implementation Project

In the next lesson, you will design CloudNova’s enterprise identity architecture using:

IAM Identity Center
Enterprise federation
Permission sets
Role-based access control
Attribute-based access control
Privileged access management
Cross-account access
Emergency access
Zero Trust principles
Continuous access governance