AWS Landing Zone - A Technical Guide to Enterprise Cloud Foundations
AWS | Sep 03, 2026 | 8 views
When an organization starts using AWS, the first few teams can usually create resources manually:
Developer
↓
AWS Account
↓
VPC
↓
EC2 / RDS / S3
This works when there are only a few people and a few workloads.
But imagine the organization grows to:
500 developers
100 AWS accounts
20 teams
10 business units
multiple Regions
production + non-production
regulated workloads
Now the problem changes.
The question is no longer:
“How do I deploy an EC2 instance?”
It becomes:
“How do I make sure 100 AWS accounts are secure, governed, connected, observable, and consistently managed without creating a huge operational burden?”
This is where the concept of an AWS Landing Zone becomes important.
AWS defines a landing zone as a well-architected, multi-account AWS environment based on security and compliance best practices. It provides a starting environment containing things such as account structure, networking, security, identity, and logging before workloads are deployed.
1. Landing Zone in one sentence
A Landing Zone is the standardized foundation of an organization's AWS environment, designed so application teams can safely deploy workloads within established security, networking, identity, logging, compliance, and governance boundaries.
Think of it as:
LANDING ZONE
|
+-----------------+-----------------+
| | |
Identity Security Network
| | |
v v v
IAM / SSO Guardrails VPC
Roles Logging TGW
Audit DNS
| | |
+-----------------+-----------------+
|
AWS Accounts
/ | \
Dev Stage Prod
| | |
VPC VPC VPC
| | |
Apps Apps Apps
The important idea is:
The Landing Zone exists before most application workloads.
It establishes the environment in which those workloads will live.
2. Why does an organization need one?
Let's start with the problems.
Suppose an organization has 100 AWS accounts.
Without centralized design, you might have:
Account 1
└── VPC
└── custom security rules
Account 2
└── VPC
└── different security rules
Account 3
└── VPC
└── logging disabled
Account 4
└── public S3 bucket
Account 5
└── unrestricted admin access
...
Account 100
└── completely different configuration
This creates several problems:
Security inconsistency
Operational inconsistency
Compliance problems
Networking complexity
Identity complexity
Logging gaps
Cost-management problems
Account-provisioning problems
A Landing Zone tries to establish consistent foundations and guardrails across the organization.
AWS's multi-account guidance explicitly treats AWS accounts as isolation boundaries that can reduce blast radius, separate workloads/data, support governance, and provide billing boundaries.
3. Landing Zone is not just one AWS service
This is an important distinction.
A Landing Zone is an architecture/foundation, not simply a single AWS resource.
You might build one yourself using AWS services:
AWS Organizations
IAM Identity Center
CloudTrail
AWS Config
VPC
Transit Gateway
S3
CloudFormation
...
Or you can use AWS Control Tower, which provides an orchestration layer for establishing and governing a multi-account landing zone. AWS describes Control Tower as orchestrating capabilities from services including AWS Organizations, AWS Service Catalog, and IAM Identity Center.
So:
Landing Zone
=
Architecture / foundation
AWS Control Tower
=
AWS service that helps establish and govern that foundation
There are also organizations that build customized landing zones instead of relying entirely on Control Tower. AWS explicitly describes both service-based and customized landing-zone approaches.
4. What problems does a Landing Zone solve?
Let's go through the major problems one by one.
Problem 1: Too many AWS accounts
Imagine:
Company
|
+-- Account 1
+-- Account 2
+-- Account 3
...
+-- Account 100
Questions immediately appear:
- Who owns each account?
- Which accounts are production?
- Which accounts are development?
- Which accounts are allowed to access sensitive data?
- Who can administer them?
- Which policies apply to each?
- Where are the logs?
- How do we create account 101?
A Landing Zone establishes an organizational structure.
For example:
AWS Organization
│
├── Security OU
│
├── Infrastructure OU
│
├── Workloads-Production OU
│
├── Workloads-NonProduction OU
│
└── Sandbox OU
OU = Organizational Unit.
An OU is simply a way to group AWS accounts so that policies and controls can be applied to groups rather than configuring every account individually.
AWS recommends organizing accounts into OUs based on governance and operational needs rather than creating unnecessarily deep OU hierarchies.
Problem 2: Security inconsistency
Without centralized governance:
Team A:
MFA enabled
Team B:
MFA partially configured
Team C:
Some public resources
Team D:
Logging missing
That's dangerous.
You want organizational policies such as:
Production accounts
|
+-- encryption requirements
+-- logging requirements
+-- approved Regions
+-- restricted services
+-- security monitoring
This is where AWS Organizations policies and Control Tower controls become useful.
Control Tower controls can be preventive, detective, or proactive.
5. Preventive controls
A preventive control says:
Don't allow this action to happen.
For example, suppose your organization doesn't want workloads deployed in a particular Region.
Conceptually:
Developer
|
| Create resource in forbidden Region
v
Organization policy
|
X
DENIED
This is much better than discovering the violation weeks later.
Control Tower implements preventive controls using mechanisms including AWS Organizations policies such as SCPs and, where applicable, RCPs.
6. Detective controls
A detective control says:
Let it happen if necessary, but detect the violation.
For example:
Developer
|
v
Creates resource
|
v
AWS Config
|
v
Configuration violation detected
|
v
Security team alerted
This is useful when prevention isn't appropriate or when you need continuous compliance visibility.
Control Tower uses AWS Config-based mechanisms for detective controls.
7. Proactive controls
A proactive control attempts to identify noncompliance before a resource is provisioned.
Conceptually:
CloudFormation deployment
|
v
Compliance check
|
+---+---+
| |
Pass Fail
| |
v X
Deploy Block
Control Tower describes proactive controls as checks against resources that would be deployed through CloudFormation templates.
So you can remember:
Preventive → Stop it
Detective → Find it
Proactive → Check before deployment
Problem 3: No centralized logging
Imagine a production account gets compromised.
Security engineers ask:
"What happened?"
But each account stores logs differently.
Account A → logs here
Account B → logs somewhere else
Account C → logs deleted
Account D → logging wasn't configured
That's a major operational and security problem.
A Landing Zone typically establishes centralized logging.
For example:
Account A ─┐
Account B ─┤
Account C ─┼──→ Central Log Archive
Account D ─┤
Account E ─┘
A Control Tower landing zone includes shared security/logging accounts; AWS documentation describes the Security OU as containing the Log Archive and Audit accounts.
The key architectural principle is:
Application teams should not be able to casually modify or delete the organization's security evidence.
Problem 4: No central audit capability
Suppose an auditor asks:
"Who changed this production resource?"
You need an audit trail.
A landing zone can establish centralized collection and security monitoring around services such as:
CloudTrail
AWS Config
GuardDuty
Security Hub
CloudWatch
S3
The exact service combination depends on the organization's requirements.
The important architecture is:
AWS Accounts
|
+---- CloudTrail
|
+---- Config
|
+---- Security services
|
v
Central security/audit
This gives security teams a centralized view instead of requiring them to investigate 100 accounts independently.
Problem 5: Account creation is inconsistent
Imagine a new development team asks:
"We need an AWS account."
Without automation:
Cloud team
|
+-- Create account
+-- Create VPC
+-- Configure IAM
+-- Configure logging
+-- Configure security
+-- Configure policies
+-- Configure networking
+-- Configure tags
Every new account becomes a manual project.
With a standardized landing zone:
Developer / Platform Team
|
| Request account
v
Account provisioning
|
v
Standard configuration
|
+-----+-----+
| | |
IAM Logs Security
| | |
+-----+-----+
|
v
Ready account
AWS Control Tower's Account Factory provides configurable account templates for standardized account provisioning and enrollment.
This is one of the biggest benefits of a mature landing zone:
Creating account #101 should not require reinventing the architecture used for account #1.
Problem 6: Networking becomes unmanageable
Suppose you have:
100 accounts
200 VPCs
Teams want:
Dev → shared services
Prod → security services
On-prem → Prod
On-prem → shared services
Monitoring → all accounts
If every team creates point-to-point connections:
VPC A ↔ VPC B
VPC A ↔ VPC C
VPC B ↔ VPC D
VPC C ↔ VPC D
...
the network becomes difficult to operate.
A centralized architecture might use:
Network Account
|
Transit Gateway
/ / | \ \
/ / | \ \
VPC VPC VPC VPC VPC
Dev Stage Prod Shared Security
The Landing Zone can establish this networking foundation.
This is especially useful for organizations with many accounts.
Problem 7: Production and development interfere with each other
Imagine:
Dev
|
+-- Developer accidentally deletes resource
|
v
Production affected
That's a huge blast radius.
Instead:
Dev Account
|
+-- Dev VPC
+-- Dev resources
Production Account
|
+-- Prod VPC
+-- Prod resources
Now the account boundary itself becomes a security and operational boundary.
AWS specifically recommends separate production and non-production environments and describes accounts as resource containers and isolation boundaries.
Problem 8: IAM becomes impossible to manage
Imagine 10,000 developers.
You don't want:
Developer
↓
IAM user
↓
Access keys
↓
100 different accounts
Instead, use centralized identity/federation:
Corporate Identity Provider
|
v
IAM Identity Center
|
+-----+-----+
| |
Dev Prod
| |
Role A Role B
Developers authenticate centrally and assume appropriate roles in the accounts they need.
This helps separate:
Who are you?
↓
Identity
What can you do?
↓
Permission set / IAM role
Where can you do it?
↓
AWS account
AWS's multi-account guidance recommends federated access to simplify human access management.
Problem 9: Compliance is difficult to prove
Suppose your company has requirements like:
Production data must be encrypted
Security logging must be enabled
Certain Regions are prohibited
Public access must be restricted
Without centralized governance:
100 accounts
↓
100 manual checks
With governance:
Organization
|
v
Policies / Controls
|
+---- Account 1
+---- Account 2
+---- Account 3
...
+---- Account 100
Now you can continuously monitor compliance.
Control Tower controls are applied to OUs, which means accounts within those OUs inherit the relevant governance controls.
Problem 10: Cost management
A landing zone doesn't magically reduce your AWS bill.
But it gives you a better organizational structure for managing cost.
For example:
AWS Organization
│
├── Production accounts
├── Development accounts
├── Data accounts
└── Shared services
Now finance can reason about:
Who owns this cost?
Which business unit?
Which application?
Which environment?
AWS Organizations also provides consolidated billing capabilities, while separate accounts provide useful billing boundaries.
You can combine this with:
Tags
Cost Categories
Budgets
Cost Explorer
Billing alerts
11. Problem 11: Lack of standardization
Imagine five teams deploy applications.
Team A:
VPC CIDR = 10.1.0.0/16
Team B:
VPC CIDR = 10.1.0.0/16
Team C:
VPC CIDR = 10.1.0.0/16
Now you want to connect them.
Oops.
Overlapping CIDRs can make routing difficult.
A landing zone can establish standards such as:
Dev accounts
10.0.0.0/16 ranges
Stage
10.10.0.0/16
Production
10.20.0.0/16
The exact IP plan depends on the organization, but the principle is:
Establish standards before hundreds of teams make independent decisions.
12. Problem 12: Cloud infrastructure drift
Drift means the environment gradually differs from the intended configuration.
You wanted:
Production
Encryption = ON
Logging = ON
Security controls = ON
But six months later:
Production
Encryption = ON
Logging = OFF ❌
Security control modified ❌
Someone changed something manually.
A mature landing zone continuously monitors for this kind of deviation.
AWS describes Control Tower controls as helping keep organizations and accounts from drifting away from established best practices.
13. What does a typical Landing Zone look like?
Here's a simplified enterprise architecture:
AWS Organization
|
Management Account
|
+-----------------------+-----------------------+
| | |
v v v
Security OU Infrastructure OU Workloads OU
| | |
+----+----+ +----+----+ +----+----+
| | | | | |
Log Archive Audit Network Shared Prod NonProd
Account Account Account Services | |
VPC VPC
| |
Apps Apps
A Control Tower landing zone currently establishes a Security OU containing Log Archive and Audit accounts, with other OUs/accounts added according to the organization's needs.
14. What does each account do?
Management account
Responsible for organization-level management.
Conceptually:
Organization
|
Management Account
|
+-- Accounts
+-- OUs
+-- Organization policies
A best practice is not to run normal application workloads in the management account. AWS explicitly recommends avoiding workload deployment there.
Log Archive account
Central place for security/audit logs.
Workload accounts
|
v
Log Archive
This provides separation between:
Application administrators
and:
Security evidence
Audit/Security account
Used by security teams for centralized security/audit activities.
Conceptually:
Security Team
|
v
Audit/Security Account
|
+-- security findings
+-- investigation
+-- audit access
Network account
Central networking infrastructure can live here:
Network Account
|
+-- Transit Gateway
+-- DNS infrastructure
+-- Network inspection
+-- Connectivity to on-premises
Not every organization uses exactly this structure, but it is a common pattern.
15. How a workload gets deployed
Suppose the application team wants a production account.
The process could look like:
Developer
|
| Account request
v
Account Factory / provisioning
|
v
Production Account
|
+-- baseline IAM
+-- logging
+-- security controls
+-- network connectivity
+-- policies
+-- monitoring
|
v
Application team
|
v
Deploy application
The application team shouldn't have to reinvent the foundational security and networking.
This is one of the core ideas:
Central platform team owns the foundation; application teams own their workloads.
16. Landing Zone vs Application Infrastructure
This distinction is very useful.
Landing Zone
Answers:
How should the organization use AWS?
Examples:
How many accounts?
How is identity managed?
Where do logs go?
Which Regions are allowed?
How is networking structured?
What security controls apply?
How are accounts created?
Application infrastructure
Answers:
How does this application run?
Examples:
EC2
ECS
Lambda
RDS
DynamoDB
S3
ALB
Auto Scaling
So:
AWS
|
Landing Zone
|
+-------+-------+
| | |
Dev Stage Prod
|
v
Application
|
+--------+--------+
| | |
EC2 RDS S3
17. Landing Zone vs VPC
Another important distinction.
A VPC is a networking boundary.
AWS Account
|
+-- VPC
|
+-- Subnets
+-- Route tables
+-- Security groups
A Landing Zone is an organizational/cloud foundation.
Organization
|
+-- Accounts
| |
| +-- VPC
|
+-- Accounts
| |
| +-- VPC
|
+-- Accounts
|
+-- VPC
Therefore:
VPC
=
networking inside an account
Landing Zone
=
foundation/governance across the AWS organization
18. Landing Zone vs Control Tower
This distinction often appears in interviews.
Landing Zone
The concept:
A standardized multi-account AWS foundation.
Control Tower
An AWS service that helps create and govern that foundation.
Landing Zone
|
"What we want"
|
v
AWS Control Tower
|
+--------------+--------------+
| | |
Organizations Identity Controls
| | |
OUs IAM Identity Governance
Center
AWS describes Control Tower as an orchestration layer over AWS services that helps set up and govern a multi-account environment.
19. Landing Zone is not only about security
This is another misconception.
People sometimes think:
Landing Zone = security setup.
Security is important, but the scope is much broader.
A mature landing zone covers:
LANDING ZONE
|
+-------------+-------------+
| | |
Security Identity Networking
| | |
+-------------+-------------+
|
+-------------+-------------+
| | |
Logging Governance Operations
| | |
+-------------+-------------+
|
Cost
|
v
Workloads
AWS's landing-zone guidance explicitly describes foundational areas including multi-account architecture, IAM, governance, data security, network design, and logging.
20. How Landing Zone solves the "100 AWS accounts" problem
Let's connect everything.
Without Landing Zone:
100 accounts
|
+-- 100 different configurations
+-- inconsistent security
+-- inconsistent networking
+-- inconsistent logging
+-- manual account creation
+-- difficult compliance
+-- difficult auditing
With Landing Zone:
Organization
|
Landing Zone
|
+-----------------+-----------------+
| | |
Governance Security Network
| | |
+-----------------+-----------------+
|
Standardized accounts
|
+--------+--------+--------+--------+
| | | | |
Dev Stage Prod Data Sandbox
| | | | |
VPC VPC VPC VPC VPC
The organization moves from:
“Every team manages AWS independently.”
to:
“Teams operate within a common cloud platform.”
21. The real business value
This is the part that's often missing from technical explanations.
A Landing Zone isn't valuable simply because it contains:
OUs
VPCs
CloudTrail
SCPs
IAM
It's valuable because it solves organizational problems.
Without it
More accounts
↓
More manual work
↓
More inconsistency
↓
More security risk
↓
More compliance effort
↓
Slower development
With it
Standard foundation
↓
Automated account setup
↓
Consistent security/governance
↓
Self-service for teams
↓
Faster workload deployment
↓
Better operational control
AWS describes these benefits in terms of centralized governance, faster account provisioning, adherence to corporate standards, regulatory requirements, and best practices.
22. The key architectural philosophy
The most important idea is centralize what should be standardized, decentralize what should belong to application teams.
For example:
Central platform/security team
Own:
Account structure
Identity foundation
Security policies
Central logging
Network foundation
Compliance controls
Account provisioning
Application team
Own:
Application code
Application deployment
EC2/ECS/Lambda configuration
Application database
Application-specific alarms
Application scaling
So:
Cloud Platform Team
|
+-------------+-------------+
| | |
Identity Security Network
| | |
+-------------+-------------+
|
Landing Zone
|
+-------------+-------------+
| | |
Dev Stage Prod
| | |
Team A Team A Team A
| | |
Workload Workload Workload
This separation allows developers to move quickly without giving every developer unrestricted control over the entire organization's AWS environment.
23. A real-world example
Imagine a bank with:
15 business units
500 developers
100 AWS accounts
production in 2 Regions
on-premises data centers
strict regulatory requirements
The bank might establish:
AWS Organization
|
Landing Zone
|
+-------------------+-------------------+
| | |
Security Network Identity
| | |
v v v
Log Archive Transit GW IAM Identity Center
Audit VPN/DX Federation
GuardDuty DNS
Config
|
+----------------+----------------+
| | |
Production NonProd Sandbox
| | |
Accounts Accounts Accounts
| | |
VPCs VPCs VPCs
| | |
Apps Apps Experiments
Now a new business unit arrives.
Instead of asking:
"How do we build an AWS environment from scratch?"
the organization can say:
"Create a new workload account using the approved organizational pattern."
The platform establishes the baseline.
The application team then deploys its application.
That's the operational value of the Landing Zone.
24. What a Landing Zone does NOT solve
It's equally important to understand the boundaries.
A Landing Zone doesn't automatically guarantee:
❌ Your application is secure
❌ Your application has no vulnerabilities
❌ Your database schema is correct
❌ Your application is highly available
❌ Your AWS bill will be low
❌ Your developers can't make mistakes
It establishes foundational controls and boundaries.
For example:
Landing Zone
|
v
Production account is governed
|
v
Application team deploys insecure application
|
v
Still possible unless appropriate controls
detect/prevent the specific issue
The landing zone is the foundation, not a replacement for application security and architecture.
25. Landing Zone evolution
A good Landing Zone isn't something you configure once and forget.
AWS notes that landing zones generally evolve as the number of OUs and accounts grows.
You might start:
Year 1
Security
NonProd
Prod
Then grow:
Year 3
Security
Infrastructure
Data
Sandbox
NonProd
Prod
Security-Prod
Security-NonProd
Then perhaps:
Year 5
Multiple business units
Multiple workload OUs
Multiple Regions
More compliance controls
More centralized services
The foundation evolves with the organization.
26. The complete mental model
Here's the mental model I recommend remembering:
AWS ORGANIZATION
|
v
LANDING ZONE
|
+------------------------+------------------------+
| | |
v v v
IDENTITY SECURITY NETWORK
| | |
Federation Guardrails VPC
IAM Identity Logging TGW
Center Audit VPN/DX
| | |
+------------------------+------------------------+
|
GOVERNANCE / OUs
|
+---------------------+---------------------+
| | |
v v v
DEV STAGE PROD
| | |
VPC VPC VPC
| | |
Apps Apps Apps
And around everything:
+---------------------+
| LANDING |
| ZONE |
+---------------------+
/ | \
/ | \
Security Network Identity
| | |
+---------+----------+
|
Governance
|
AWS Accounts
|
Applications
Tags: #LandingZone, #Enterprise, #Governance
No comments yet.