AWS Multi-Account Landing Zone: Organizations, IAM Identity Center and SCPs

One AWS account means one incident can reach every workload. I split it into management, security, shared services and workload accounts, with SSO through IAM Identity Center, SCP guardrails and CloudTrail everywhere.

Project Overview

When an organisation runs everything in a single AWS account, a security incident can affect every workload simultaneously. This project implements a proper multi-account structure that provides blast radius isolation and centralised governance.

Account Structure

AWS Organizations Root
├── Management Account (Organizations, Billing, SCPs)
├── Security OU
│   └── Security Account (GuardDuty, Security Hub, CloudTrail)
├── Infrastructure OU
│   └── Shared Services (Transit Gateway, ECR, Route 53)
└── Workloads OU
    ├── Dev Account
    ├── Staging Account
    └── Production Account

Service Control Policies

{
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": ["iam:*", "organizations:*", "route53:*"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["eu-west-1", "eu-central-1"]
        }
      }
    }
  ]
}

Results

Blast radius isolation across all environments
Engineer onboarding: one SSO permission set, no IAM user creation
CloudTrail coverage: 100% across all accounts, 90-day retention
SCPs blocked 3 unauthorised region deployments in the first month

Project Links

GitHub Repo

Tech Stack

AWS OrganizationsIAM Identity CenterSCPsCloudTrailGuardDutyTerraform

Back to projects