TestForge Blog
← All Posts
#cloud #aws #landing-zone #security #network

AWS Multi-Account Landing Zone Guide — Organizations, IAM Identity Center, and Network Segmentation

Running everything in a single AWS account quickly becomes painful as teams, environments, and compliance needs grow. This post explains a practical multi-account landing zone using Organizations, OU structure, IAM Identity Center, shared networking, centralized logging, and security guardrails.

TestForge Team ·

Why multi-account matters

A single AWS account looks simple at first, but the pain shows up quickly:

  • production and development resources mix together
  • IAM boundaries become unclear
  • cost allocation gets messy
  • blast radius becomes too large
  • centralized audit and security control become difficult

That is why mature AWS environments usually move to a multi-account model early.

Principles to define first

  • separate by environment: prod, staging, dev
  • separate by function: shared, security, logging, network
  • separate by access level: admin vs developer
  • separate by cost ownership: service or team accounts
  • separate by audit responsibility: logging and security accounts stay independent

The key idea is to treat an AWS account as a strong security boundary.

Root
 ├─ Security
 │   ├─ audit
 │   └─ log-archive
 ├─ Infrastructure
 │   ├─ network
 │   └─ shared-services
 ├─ Workloads
 │   ├─ prod
 │   ├─ staging
 │   └─ dev
 └─ Sandbox
     └─ experiments

This structure makes it easier to apply policy by OU.

Account roles

log-archive

  • central CloudTrail storage
  • Config snapshots
  • long-term log retention

audit

  • Security Hub aggregation
  • GuardDuty aggregation
  • IAM Access Analyzer
  • read-only audit access

network

  • Transit Gateway
  • central egress VPC
  • shared DNS
  • IP planning

shared-services

  • common CI/CD
  • operational access via SSM
  • shared artifact storage
  • shared internal platforms

prod, staging, dev

  • workload accounts for real applications
  • can be split further by team or service

Build access around IAM Identity Center

In modern AWS environments, human access is usually better through IAM Identity Center than individual IAM users.

Recommended model:

  • integrate with your corporate IdP
  • use group-based access
  • define permission sets per account type
  • keep production admin access tightly controlled

Example roles:

  • Platform-Admin
  • Security-Audit
  • Developer-ReadOnly-Prod
  • Developer-PowerUser-Dev

This makes onboarding and offboarding much easier.

Use SCPs as hard guardrails, not as detailed policy

SCPs sit above IAM policy, so they should be used carefully.

Common examples:

  • block unapproved regions
  • prevent CloudTrail disablement
  • prevent GuardDuty or Config shutdown
  • restrict root account usage
  • block unapproved services

The practical rule is simple: use SCPs for things that must never happen.

Network design: central control vs full isolation

Networking is one of the biggest landing-zone design decisions.

Centralized model

  • Transit Gateway
  • central egress
  • shared firewall and DNS

Pros:

  • consistent policy
  • easier visibility

Cons:

  • higher dependency on the network account
  • more complexity

Fully isolated model

  • separate VPCs per account
  • connect only where needed

Pros:

  • stronger isolation
  • higher team autonomy

Cons:

  • duplicated effort and cost

A balanced pattern is often shared network account + isolated workload VPCs.

Centralize logs and security from day one

A real landing zone should include:

  • organization-wide CloudTrail
  • AWS Config aggregation
  • GuardDuty at the organization level
  • Security Hub aggregation
  • centralized S3 log buckets

Without central logging, incident response becomes far harder than it should be.

Cost governance is also part of the landing zone

Multi-account design helps not only with security but also with financial responsibility.

Good practices:

  • clear account naming
  • enforced tag policies
  • per-account budgets
  • explicit handling of shared account cost allocation

Common mistakes

  • keeping prod and dev in the same account
  • continuing to create IAM users for people
  • skipping a central logging account
  • creating VPCs without IP planning
  • overusing SCPs until teams cannot operate

A practical rollout sequence

  1. create AWS Organizations
  2. define the OU structure
  3. create audit, log-archive, network, and shared-services
  4. integrate IAM Identity Center with your IdP
  5. apply minimal SCP guardrails
  6. centralize logs and security
  7. onboard workload accounts

Closing thoughts

An AWS landing zone is not just a way to split accounts. It is a long-term operating model for access control, security, networking, cost governance, and auditability.

It may feel heavier at the beginning, but the cost of not having it grows much faster as the platform scales.