Santanu Das

Posted on Oct 28 • Edited on Oct 31

Building a Scalable AWS Multi-Account Environment with Control Tower, Terraform AFT, and SCP Guardrails

#aws #cloudarchitecture #devops #security

Overview
Organizational Structure
Regional Strategy
Conceptual Flow
Multi-Region Setup
CT & AFT Integration
Services Strategy
Governance & Security
SCP Guardrails
Control Layers
Deployment Workflow
Future Enhancements

Managing multiple AWS accounts securely and consistently is one of the hardest challenges in modern cloud architecture. In this guide, we’ll walk through how to build a scalable, governed AWS environment using Control Tower, Account Factory for Terraform (AFT), and Service Control Policies (SCPs), which is loosely based on Zenler's multi-account organization structure.

🔖 Overview

This document outlines the AWS account structure, governance, and control strategy used across our organization. We'll talk about how these three layers — Control Tower (govern), AFT (automate), and SCPs (enforce) — work together to provide an enterprise-grade foundation for compliance, security, and automated multi-account landing zone — aligning with AWS Well-Architected and CIS Benchmarks. This is the same model many large AWS customers use to keep their landing zones predictable and audit-ready while letting individual teams move fast with Terraform.

Below is an illustrative AWS Organization layout

🏣 Organizational Structure

OU	Description	Primary Accounts
Security OU	Core compliance and security monitoring	`Log Archive`, `Audit`
Internal OU	Shared platform services and IAM root	`Shared Services`, `IAM/Root`
NPR Networking OU	Non-Production networking environment	`Internal Workload`, `External Workload`
PRD Networking OU	Production networking environment	`Internal Workload`, `External Workload`
Deprecated OU	Legacy accounts (no new workloads)	Various (read-only)

🧭 Regional Strategy

Component	Region	Rationale
IAM Identity Center (SSO)	`us-east-1`	Global endpoint for AWS SSO and Organizations
Control Tower Management Account	`us-east-1` backend	Required by AWS
All Member Accounts	`eu-west-2` (London)	Primary data residency & workload region
Backup / DR	`eu-west-1` (Ireland)	Optional failover region

💠 Conceptual Flow Diagram

                 ┌──────────────────────────────────────────────┐
                 │               Management Account             │
                 │ (AWS Organizations + Control Tower + AFT)    │
                 └──────────────────────────────────────────────┘
                                   │
                 ┌──────────────────────────────────────────────┐
                 │ Control Tower Landing Zone                   │
                 │ • Security OU (LogArchive + Audit)           │
                 │ • Creates baseline guardrails (AWS-managed)  │
                 │ • Delegates to AFT for account provisioning  │
                 └──────────────────────────────────────────────┘
                                   │ Management Acct (us-east-1)
              ┌────────────────────┴────────────────────┐
              │                                         │
    ┌──────────────────────────────┐          ┌──────────────────────────────┐
    │ Account Factory for TF (AFT) │          │ AWS Organizations (Org Root) │
    │ • GitOps: account requests   │          │ • OU hierarchy (SEC, INT,    │
    │ • Customizations pipelines   │          │   NPR, PRD, DEPRECATED)      │
    │ • Baselines, tagging, roles  │          │ • SCPs attached per OU       │
    └──────────────────────────────┘          └──────────────────────────────┘
              │                                         │
              │                                         │
              │              ┌────────────────────────────────────────┐
              │              │ SCP layer (Preventive Guardrails)      │
              │              │ • Enforced at Org root / OU level      │
              │              │ • Deny/allow APIs before IAM evaluated │
              │              │ • Prevents config drift or unsafe ops  │
              │              └────────────────────────────────────────┘
              │
     ┌────────┴─────────┐
     │ Enrolled Account │
     │ (e.g. Internal,  │
     │ NPR, PRD, etc.)  │
     └──────────────────┘

🌍 Why Setup Multi-Region

Like a lot of many others, we also started with everything in one region — but as soon as you deploy Control Tower, IAM Identity Center, and multi-account governance, regional separation becomes not just practical but recommended.

Here’s why I kept our management & identity layer in us-east-1 and our workloads in eu-west-2, following the best practice:

1️⃣ AWS Global Service Dependencies

Some services, like AWS Organizations, Control Tower, and IAM Identity Center (SSO) — are global by design but physically anchored in us-east-1. Running these components in their native region (if possible and allowed) ensures:

Full feature compatibility (some CT/AFT APIs only run in N. Virginia)
Stable upgrades when AWS releases new landing zone versions
Reduced orchestration latency for service-managed controls and SCPs

Control Tower’s orchestration backend always executes from us-east-1, even if your governed regions are elsewhere. Keeping the management plane in there prevents drift or control sync issues.

2️⃣ Regional Data Residency and Compliance

Our workloads stay in eu-west-2 (London), which:

Meets UK data sovereignty requirements
Keeps PII (Personally Identifiable Information), audit logs, and business data physically in-region
Aligns with GDPR and UK government guidelines for cloud workloads

This gives us the best of both worlds:

Control and governance (global layer in us-east-1)
Data and workload residency (EU region)

3️⃣ Reduced Blast Radius

By splitting control and data planes:

Security incidents in workload accounts cannot impact IAM or Organizations configuration.
SCPs and AFT pipelines stay isolated in the management plane, away from operational workloads.
Compliance tooling (Config, GuardDuty, Security Hub) in the Audit account can observe EU workloads without touching identity infrastructure.

4️⃣ Disaster Recovery and Fault Isolation

If the EU region faces an outage, our:

SSO / IAM Identity Center
Control Tower orchestration
AFT pipelines

…still remain operational in us-east-1, enabling us to recover or redeploy without waiting for the EU region to recover.

That’s a significant operational advantage for regulated workloads and CI/CD pipelines.

5️⃣ Aligned with AWS Multi-Account Reference Architecture

AWS explicitly recommends:

Global management and identity region (us-east-1)
Regional landing zones for workloads

This pattern is described in the AWS Multi-Account Landing Zone reference architecture, and most enterprise Control Tower deployments follow the same approach.

🧩 Control Tower & AFT Integration

Landing Zone

Deployed via AWS Control Tower in the management account.
Establishes:
- AWS Organizations
- Log Archive and Audit accounts
- Baseline guardrails (AWS-managed)

Account Factory for Terraform (AFT)

Provides GitOps-based account lifecycle management.
Each account is provisioned using Terraform pipelines that:
- Enroll the account in Control Tower
- Apply OU-specific baselines (e.g., Config, logging)
- Tag accounts automatically
AFT runs in its own AFT Management Account.

Account Hierarchy Diagram

Management Account
 ├── AWS Control Tower (Landing Zone)
 ├── AFT Pipelines (Account Factory for Terraform)
 └── AWS Organizations (Root OU)
      ├── Security OU
      ├── Internal OU
      ├── NPR Networking OU
      ├── PRD Networking OU
      └── Deprecated OU

🧰 Networking & Shared Services Strategy

Service	Owning Account	Scope	Sharing Mechanism
Transit Gateway (TGW)	Internal Comms (per env)	Environment-specific	AWS RAM (within the env)
Internet Gateway (IGW)	External Comms (per env)	Environment-specific	Single point of entry - not shared
NAT Gateway (NGW)	Shared Services	Cross-environment	Single point of exit - not shared
Network Firewall (NFW)	Shared Services	Cross-environment	AWS RAM + TGW routing
VPC Endpoint Services	Shared Services	Org-wide	Route53 Reslover

🔐 Governance & Security Controls

Governance is enforced using three layers:

Layer	Type	Enforcement Mechanism
Preventive	Service Control Policies (SCPs)	AWS Organizations
Detective	Config / Security Hub / GuardDuty	Audit account
Proactive	CloudFormation Hooks / AFT Customizations	Terraform baselines

🚫 Core SCP Pack (Preventive Guardrails)

1️⃣ Deny Root User Access

Prevents use of root credentials in any account.

{
  "Sid": "DenyRootUser",
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "aws:PrincipalArn": "arn:aws:iam::*:root"
    }
  }
}

2️⃣ Restrict Regions (EU + us-east-1)

{
  "Sid": "DenyOutsideApprovedRegionsExceptIdentity",
  "Effect": "Deny",
  "NotAction": [
    "iam:*","organizations:*","route53:*","sso:*","support:*"
  ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["eu-west-1", "eu-west-2", "us-east-1"]
    }
  }
}

3️⃣ Deny Unapproved Network Creation

{
  "Sid": "DenyUnapprovedNetworking",
  "Effect": "Deny",
  "Action": [
    "ec2:CreateInternetGateway","ec2:AttachInternetGateway",
    "ec2:CreateNatGateway","ec2:CreateVpcPeeringConnection",
    "ec2:CreateTransitGateway","ec2:DeleteTransitGateway"
  ],
  "Resource": "*"
}

4️⃣ Restrict Service Creation

Resource	Allowed Account(s)	SCP Condition
TGW (Transit Gateway)	Internal Comms (PRD/NPR)	`aws:PrincipalAccount` = INC IDs
IGW (Internet Gateway)	External Comms (PRD/NPR)	`aws:PrincipalAccount` = EXC IDs
NFW (Network Firewall)	Shared Services	`aws:PrincipalAccount` = SSV ID
NGW (NAT Gateway)	Shared Services	`aws:PrincipalAccount` = SSV ID
VPC Endpoint Services	Shared Services	`aws:PrincipalAccount` = SSV ID

5️⃣ Tag Enforcement

{
  "Sid": "RequireStandardTags",
  "Effect": "Deny",
  "Action": ["ec2:RunInstances","rds:CreateDBInstance","s3:CreateBucket"],
  "Resource": "*",
  "Condition": {
    "Null": {
      "aws:RequestTag/Environment": "true",
      "aws:RequestTag/Owner": "true"
    }
  }
}

6️⃣ Deny Org Tampering

Protects core logging and control-plane resources

{
  "Sid": "DenyOrgTampering",
  "Effect": "Deny",
  "Action": [
    "organizations:LeaveOrganization",
    "cloudtrail:StopLogging",
    "config:StopConfigurationRecorder"
  ],
  "Resource": "*"
}

7️⃣ Deprecated OU Policy

{
  "Sid": "DenyNewCreates",
  "Effect": "Deny",
  "Action": ["*"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/Environment": "deprecated"
    }
  }
}

🧠 Control Layers Explained

Layer	Description	Managed By
Control Tower	Creates baseline governance (OU, guardrails, log archive, audit)	AWS
AFT	Automates account provisioning, tagging, baseline controls	Platform team
SCPs	Prevent actions that violate org standards (region, network, security)	Org root
Delegated Security Accounts	Detect & monitor compliance (Config, GuardDuty)	Security team

🪜 Deployment Workflow

Step	Action	Tool
1	Enable Control Tower (Landing Zone)	Console / CLI
2	Bootstrap AFT management	Terraform
3	Create OUs + SCPs	Terraform
4	Submit account requests via AFT	GitOps
5	Apply OU-specific baselines	Terraform
6	Validate security controls	AWS Config / Security Hub
7	Continuous compliance	Detective + Proactive guardrails

🧩 Future Enhancements

Add Policy Staging OU for testing new SCPs.
Integrate Proactive Controls (CloudFormation hooks).
Automate SCP compliance drift detection using AWS Config custom rules.
Add organizational backup plans (AWS Backup delegated admin).

DEV Community