Introduction to Cloud Landing Zones
Table of Contents
Introduction
Throughout my career working with cloud infrastructure, I've repeatedly seen organizations struggle with the same fundamental challenge: managing cloud resources at scale without a proper foundation.
Early in my cloud journey, I worked on projects where teams independently created AWS accounts for quick testing and experimentation. What seemed like flexibility initially became a significant operational challenge:
Accounts scattered across the organization with no central visibility
Inconsistent security configurations across different environments
VPC networking setups that created IP address conflicts
No centralized logging or monitoring capabilities
Missing cost allocation and tracking mechanisms
Multiple redundant tools and services
Compliance and audit gaps
These experiences taught me a critical lesson: cloud infrastructure needs a solid foundation to scale effectively. That foundation is what we call a "cloud landing zone."
Through building and refining landing zones across various projects, I've learned that establishing proper cloud foundations from the beginning saves significant time, reduces security risks, and enables teams to move faster with confidence.
This article shares the knowledge and patterns I've developed for building effective cloud landing zones - why they matter, what they include, and how to approach them correctly.
What Is a Cloud Landing Zone?
A cloud landing zone is a well-architected, multi-account (or multi-subscription) cloud environment that provides a secure, scalable foundation for your organization's cloud infrastructure. Think of it as the "operating system" for your cloud presence - it provides the core services, security guardrails, and governance that every application and workload needs.
The Analogy That Made It Click
For years, I struggled to explain landing zones to non-technical stakeholders. Then I found an analogy that works perfectly: a landing zone is like a city's infrastructure.
Imagine building a city without planning:
Every building owner creates their own power grid (duplicated effort, unsafe)
No centralized water system (everyone digs their own well)
No zoning laws (factories next to homes)
No fire department (everyone for themselves)
No building codes (structures collapse)
No roads (everyone creates their own paths)
Chaos, right? That's exactly what cloud infrastructure looks like without a landing zone.
Now imagine a properly planned city:
Centralized utilities (power, water, sewage) - everyone plugs in
Zoning laws (commercial, residential, industrial separated)
Building codes (safety standards enforced)
Emergency services (fire, police, medical)
Transportation infrastructure (roads, public transit)
Governance (permits, inspections, compliance)
That's what a cloud landing zone provides for your cloud infrastructure.
Technical Definition
More technically, a cloud landing zone is:
A pre-configured, secure, and compliant cloud environment that provides:
Account/subscription organization with hierarchical management structures
Network architecture with hub-and-spoke topology and hybrid connectivity
Identity and access management with centralized authentication and authorization
Security guardrails with automated policy enforcement
Centralized logging and monitoring for visibility and compliance
Cost management with budgets, alerts, and chargeback
Automation for self-service resource provisioning
Compliance frameworks meeting regulatory requirements
Visual: Landing Zone Conceptual Architecture
The Key Insight
The critical insight that changed my thinking: a landing zone isn't just infrastructure - it's a platform that enables teams to move fast while staying secure and compliant.
Without a landing zone, every team reinvents the wheel for:
Network connectivity
Security configuration
Logging and monitoring
Compliance requirements
Cost management
Access control
With a landing zone, teams get a "paved road" - a pre-built, secure, compliant environment where they can deploy applications immediately without worrying about foundational concerns.
The Cost of Cloud Without a Landing Zone
My $47,000 crypto mining incident was expensive, but it pales in comparison to what I've seen at other organizations. Let me break down the true cost of cloud without proper foundations.
Financial Costs
Wasted Cloud Spend:
Duplicate services: I've seen organizations running 12 different monitoring solutions because each team chose their own tools
Zombie resources: Without governance, resources get created and forgotten. One company I consulted for had $180,000/year in unused resources
No cost visibility: Without tagging and chargeback, teams have no incentive to optimize
Security incidents: Breaches cost far more than prevention. Our $47,000 incident was cheap compared to the $2.3M breach I saw at a healthcare company
Operational Inefficiency:
Reinventing the wheel: Every team building their own VPCs, security groups, IAM roles
Context switching: Engineers spending 40% of their time on infrastructure instead of applications
Delayed launches: Weeks spent on security reviews before production deployment
Support burden: Platform teams firefighting individual account issues
Security Risks
The security implications are what kept me up at night:
Attack Surface:
No consistent security baselines: Every account configured differently
Shadow IT: Accounts created outside IT oversight
Misconfigurations: S3 buckets open to the world, databases without encryption
No centralized monitoring: Can't detect threats across multiple accounts
Privilege escalation: Users with admin access in every account
No segmentation: Prod and dev in the same network
Real Examples I've Seen:
Healthcare company with PHI in publicly accessible S3 buckets (HIPAA violation)
Financial services with production databases accessible from the internet
Retail company with customer credit cards in unencrypted RDS instances
SaaS startup with admin credentials committed to public GitHub repo
Compliance Nightmares
For regulated industries, the compliance risks are existential:
Audit Failures:
No audit trails: Can't prove who accessed what and when
Data residency: Resources created in wrong regions
Encryption gaps: Data at rest and in transit not encrypted
Access control: No role-based access or separation of duties
Change management: No approval workflows for infrastructure changes
The $8M Compliance Penalty:
A financial services company I know failed a SOC2 audit because they couldn't demonstrate:
Centralized logging for 18 months (required retention)
Encryption of data at rest across all systems
Network segmentation between environments
Access reviews for privileged accounts
The resulting compliance penalty: $8 million. The cost to implement a proper landing zone with all required controls: $400,000. The ROI is blindingly obvious.
Organizational Chaos
Beyond money and risk, there's organizational dysfunction:
Team Friction:
Platform team blamed for security incidents
Application teams frustrated by slow infrastructure requests
Security team seen as "blockers" instead of enablers
Finance team can't allocate cloud costs accurately
Technical Debt:
Accumulating misconfigurations that get harder to fix
Snowflake accounts with special configurations
No path to scale without major rearchitecture
Migration nightmares when finally fixing the foundation
The Breaking Point
Every organization I've worked with hit a "breaking point" where the lack of landing zone became untenable:
50+ accounts: Manual management breaks down
First security audit: Compliance gaps become obvious
Major incident: Security breach or significant outage
Leadership change: New CTO demands professional platform
Regulatory requirement: HIPAA, PCI-DSS, SOC2 forces the issue
The pattern is always the same: organizations try to scale on poor foundations, hit a crisis, then have to retrofit a landing zone while keeping production running. It's like rebuilding an airplane engine while flying.
The lesson I learned the hard way: start with a landing zone. Build it before you need it. The cost of retrofitting is 10x higher than building it right from the start.
Platform Landing Zones vs Application Landing Zones
One of the most important distinctions in landing zone architecture is understanding the difference between platform landing zones and application landing zones. This separation is what enables enterprise scale.
Platform Landing Zones: The Foundation
A platform landing zone provides shared services that all application workloads need. Think of it as the "city infrastructure" that everyone uses but nobody wants to build themselves.
What Lives in Platform Landing Zones:
1. Identity & Access Management
Centralized identity provider (SSO, Active Directory)
Federation with corporate identity systems
Service principals and managed identities
Privileged access management (PAM)
2. Network Connectivity
Hub network for centralized routing
VPN and ExpressRoute/Direct Connect to on-premises
Network firewalls and inspection
DNS and private DNS zones
Network monitoring and flow logs
3. Shared Services
Container registry
Artifact repository
CI/CD platform
Secrets management (HashiCorp Vault, Azure Key Vault)
Monitoring and observability platform
4. Security Services
SIEM aggregation
Vulnerability scanning
Threat detection and response
DLP (Data Loss Prevention)
Security posture management
5. Governance & Compliance
Policy enforcement engine
Cost management and chargeback
Compliance scanning
Audit log aggregation
Backup and disaster recovery
Real-World Example:
At a company I worked with, our platform landing zone consisted of:
1 Management account: Organization-wide governance
1 Security account: Centralized security monitoring (GuardDuty, Security Hub)
1 Logging account: All audit logs aggregated here
1 Network account: Hub VPC with transit gateway
1 Shared Services account: Container registry, CI/CD, Vault
1 Backup account: Centralized backup vaults
This foundation supported 350+ application landing zones across the organization.
Application Landing Zones: The Workloads
An application landing zone is a pre-configured account/subscription where teams deploy their applications. It comes with all the foundational connectivity, security, and governance already configured.
What Lives in Application Landing Zones:
Application Resources:
Compute (VMs, containers, serverless functions)
Databases and storage
Application-specific networking (subnets, load balancers)
Application monitoring and logging
Application-specific IAM roles
Pre-Configured Connectivity:
Network connection to hub (spoke VPC peered/connected to hub)
Access to shared services (DNS, monitoring, secrets)
Internet egress through hub firewall
On-premises connectivity via hub
Automatic Governance:
Security policies automatically applied
Compliance scanning enabled
Budget alerts configured
Backup policies enforced
Tagging requirements validated
The Critical Separation
The separation between platform and application landing zones creates clear ownership boundaries:
Owned By
Platform/Cloud team
Application team
Purpose
Shared services for all
Specific workload hosting
Change Frequency
Infrequent, carefully managed
Frequent, team-controlled
Lifecycle
Long-lived
May be temporary/ephemeral
Scope
Organization-wide
Team/application-specific
Security
Highly locked down
Flexible within guardrails
Visual: Platform vs Application Landing Zones
Why This Separation Matters
For Platform Teams:
Manage shared services once, benefit everyone
Enforce security and compliance organization-wide
Scale efficiently without per-application work
Clear SLAs and responsibilities
For Application Teams:
Deploy applications without infrastructure expertise
Self-service provisioning (no tickets!)
Pre-configured security and compliance
Focus on business value, not infrastructure
For the Organization:
Consistent security posture across all workloads
Reduced duplication and cost
Faster time to market
Easier auditing and compliance
The Real-World Impact
At a SaaS company I worked with, implementing this separation had dramatic results:
Before (No Landing Zone):
3 weeks to provision a new environment
Security team reviewed every deployment (bottleneck)
Duplicate services across 40 teams
Inconsistent security - every team configured differently
After (Platform + Application Landing Zones):
15 minutes to provision a new environment (self-service)
Security built-in - no review needed for standard deployments
Shared services - 40 teams using same CI/CD, monitoring, secrets
Consistent security - policies enforced automatically
The result: Development velocity increased 10x while security incidents decreased 80%.
Multi-Cloud Perspective: AWS, Azure, and GCP
One of the most powerful aspects of landing zone thinking is that the concepts are provider-agnostic. Whether you're on AWS, Azure, GCP, or multiple clouds, the patterns are remarkably similar.
AWS: Control Tower and Landing Zone Accelerator
AWS Control Tower is Amazon's solution for automated landing zone deployment. It builds on AWS Organizations to provide:
Key Components:
Organization structure: Multi-account architecture with OUs (Organizational Units)
Account Factory: Automated account provisioning with guardrails
Guardrails: Preventive and detective controls (AWS Config rules and SCPs)
Centralized logging: CloudTrail and Config logs to a log archive account
Dashboard: Compliance and drift detection
Typical AWS Landing Zone Structure:
AWS Landing Zone Accelerator (formerly Landing Zone Solution) adds:
Infrastructure as Code (using AWS CDK)
Advanced networking (Transit Gateway, Network Firewall)
Security services (GuardDuty, Security Hub, Macie)
Compliance frameworks (NIST, PCI-DSS, HIPAA)
Azure: Cloud Adoption Framework Landing Zones
Azure Landing Zones are part of Microsoft's Cloud Adoption Framework (CAF). They provide:
Key Components:
Management Group hierarchy: Organization-wide governance structure
Subscription organization: Platform vs application subscriptions
Azure Policy: Compliance and guardrails at scale
Hub-spoke networking: Centralized connectivity with Azure Virtual WAN or traditional hub
Identity: Integration with Azure AD and hybrid identity
Typical Azure Landing Zone Structure:
Azure Landing Zone Accelerator provides:
Reference implementations (Portal experience, Terraform, Bicep)
Hub-spoke or Virtual WAN networking
Policy-driven governance
Integration with Azure DevOps for automation
GCP: Cloud Foundation Toolkit
Google Cloud Platform takes a more modular approach with the Cloud Foundation Toolkit:
Key Components:
Organization hierarchy: Organization > Folders > Projects
Terraform modules: Pre-built, opinionated infrastructure
Organization policies: Centralized constraints
VPC Service Controls: Security perimeters for services
Centralized logging: Cloud Logging organization sinks
Typical GCP Landing Zone Structure:
Multi-Cloud Comparison
Account/Sub Unit
Account
Subscription
Project
Organization
Organization + OUs
Management Groups
Organization + Folders
Native Tool
Control Tower
Landing Zone Accelerator
Foundation Toolkit
Policy Engine
Service Control Policies (SCPs)
Azure Policy
Organization Policies
Network Hub
Transit Gateway
Virtual WAN / Hub VNet
Shared VPC
Identity
IAM + Organizations
Azure AD + RBAC
Cloud Identity + IAM
Logging
CloudTrail to S3
Activity Logs to Log Analytics
Cloud Logging sinks
IaC Support
CDK, Terraform
Bicep, ARM, Terraform
Terraform
Why Multi-Cloud Landing Zones Matter
Many organizations I've worked with use multiple cloud providers:
Common Patterns:
AWS + Azure: Most common combination (40% of enterprises)
Best-of-breed: Using each cloud's strengths
Acquisition integration: Inherited from acquired companies
Risk mitigation: Avoiding vendor lock-in
Regional requirements: Different clouds in different countries
The Multi-Cloud Challenge:
Without consistent landing zone patterns, multi-cloud becomes a nightmare:
Different teams manage different clouds differently
Inconsistent security postures
Separate identity systems
Different monitoring tools
Duplicated effort
The Multi-Cloud Solution:
Apply the same landing zone principles across all clouds:
Consistent structure: Prod/staging/dev organization in all clouds
Unified identity: Federate all clouds to same identity provider
Common tooling: Terraform for all clouds, common CI/CD
Centralized monitoring: Aggregate logs from all clouds to SIEM
Shared governance: Same policies enforced everywhere
Real-World Multi-Cloud Example
At a financial services company, we built a multi-cloud landing zone:
AWS (Primary):
Customer-facing applications
Data analytics platform
200+ accounts
Azure:
Office 365 integration workloads
Windows-based applications
50+ subscriptions
GCP:
Machine learning and AI workloads
BigQuery data warehouse
30+ projects
Unified Foundation:
Identity: All federated to Okta SSO
Networking: Interconnected via dedicated links (ExpressRoute, Direct Connect, Partner Interconnect)
Monitoring: All logs to Splunk SIEM
IaC: All infrastructure in Terraform with consistent module patterns
Security: Same security scanning and compliance tools across all clouds
The key insight: Landing zone concepts transcend specific cloud providers. Learn the patterns once, apply everywhere.
Core Components of a Landing Zone
Every successful landing zone, regardless of cloud provider, includes these core components. Think of these as the "essential utilities" that every cloud environment needs.
1. Account/Subscription Organization
Purpose: Logical separation of workloads, environments, and teams
Structure:
Hierarchical organization (OUs, management groups, folders)
Separation by environment (prod, staging, dev)
Separation by compliance requirements
Isolation boundaries for security
Why It Matters:
Security: Blast radius containment (a breach in dev doesn't affect prod)
Compliance: Different controls for different data classifications
Cost: Clear ownership and chargeback
Operations: Independent lifecycle management
Real Example:
2. Identity and Access Management
Purpose: Centralized authentication and authorization
Components:
Identity provider integration: Federate to corporate SSO (Okta, Azure AD, Google Workspace)
Role-based access control (RBAC): Predefined roles for common functions
Service accounts: Managed identities for applications
Privileged access management: Just-in-time admin access
MFA enforcement: Multi-factor authentication required
Why It Matters:
Security: Centralized identity is easier to secure than distributed
Compliance: Audit who accessed what and when
User experience: Single sign-on (one password for everything)
Operations: Automated provisioning/deprovisioning
Real Example:
3. Network Architecture
Purpose: Secure, scalable connectivity between workloads and on-premises
Pattern: Hub-and-spoke topology
Components:
Hub network: Centralized routing and security
Network firewall / network virtual appliance
VPN gateway for user access
ExpressRoute/Direct Connect for on-prem connectivity
DNS forwarders
Network monitoring
Spoke networks: Application workloads
Connected to hub via peering or transit gateway
Isolated from each other (unless explicitly allowed)
Internet egress through hub firewall
Hybrid connectivity: Links to on-premises data centers
Internet connectivity: Controlled egress through firewall
Why It Matters:
Security: Centralized inspection and filtering
Compliance: Network segmentation required by many frameworks
Operations: Centralized management of connectivity
Cost: Shared services reduce duplication
Visual: Hub-and-Spoke Network
4. Security and Compliance
Purpose: Automated security controls and compliance validation
Components:
Guardrails: Preventive controls (SCPs, Azure Policies, Org Policies)
Require encryption at rest
Deny public S3 buckets
Restrict regions for data residency
Enforce tagging standards
Threat detection: Detective controls
GuardDuty / Defender / Security Command Center
Anomaly detection
Vulnerability scanning
Configuration compliance (AWS Config, Azure Policy compliance)
Compliance frameworks: Pre-configured controls for regulations
HIPAA, PCI-DSS, SOC2, NIST, ISO 27001
Automated compliance reports
Security services:
DLP (Data Loss Prevention)
SIEM integration
Secrets management
Certificate management
Why It Matters:
Risk reduction: Automated controls prevent human error
Compliance: Demonstrate controls to auditors
Visibility: Know your security posture across all accounts
Response: Detect and respond to threats faster
5. Centralized Logging and Monitoring
Purpose: Organization-wide visibility and audit trails
Components:
Audit logging: All API calls logged (CloudTrail, Activity Logs, Audit Logs)
Log aggregation: Centralized log repository
Immutable storage (can't be tampered with)
Long-term retention (7+ years for compliance)
Encrypted at rest
Security monitoring: SIEM integration
Real-time threat detection
Correlation across accounts
Automated response (Lambda/Functions/Cloud Functions)
Operational monitoring:
Metrics aggregation
Application performance monitoring (APM)
Infrastructure monitoring
Cost and usage tracking
Why It Matters:
Security: Detect breaches and investigate incidents
Compliance: Demonstrate audit trails for regulations
Operations: Troubleshoot issues across distributed systems
Optimization: Identify cost savings opportunities
6. Governance and Cost Management
Purpose: Policy enforcement and financial controls
Components:
Tagging policies: Required tags for cost allocation
Environment (prod/staging/dev)
Owner (team responsible)
Cost center (for chargeback)
Application (workload name)
Compliance level (HIPAA/PCI/etc)
Budget controls:
Account-level budgets with alerts
Automated actions when threshold exceeded
Cost anomaly detection
Policy enforcement:
Require specific configurations
Deny non-compliant deployments
Automated remediation
Compliance scanning:
CIS benchmarks
Regulatory frameworks
Custom policies
Why It Matters:
Cost control: Prevent surprise cloud bills
Accountability: Know who spent what and why
Compliance: Automated policy enforcement
Optimization: Identify waste and optimization opportunities
7. Automation and Self-Service
Purpose: Enable teams to provision resources without manual intervention
Components:
Account/subscription vending: Automated provisioning
Self-service portal or API
Pre-configured security and compliance
Network connectivity automatically established
Monitoring and logging automatically enabled
Infrastructure as Code:
Terraform modules for common patterns
CI/CD pipelines for infrastructure deployment
Automated testing and validation
Service catalog:
Pre-approved patterns (e.g., "3-tier web app")
One-click deployment
Guardrails enforced automatically
Why It Matters:
Velocity: Teams can move fast without sacrificing security
Consistency: Every deployment uses same secure patterns
Efficiency: Platform team scales without growing linearly
Compliance: Security built-in from day one
The Integration Picture
These components don't exist in isolation - they work together:
What I Learned
After building dozens of landing zones, here's what I've learned about these components:
1. Identity is the foundation - Get SSO and federation right first. Everything else builds on identity.
2. Network architecture is hardest to change - Plan IP addressing carefully. You'll live with these decisions for years.
3. Logging is non-negotiable - The first time you need logs for an investigation and don't have them, you'll understand why centralized logging matters.
4. Automation enables scale - Manual processes work for 10 accounts. At 100+ accounts, automation is the only way.
5. Security must be automatic - Relying on humans to remember security steps doesn't work. Build it into the platform.
Business Value and ROI
When I first proposed building a landing zone to leadership, the response was: "Why should we spend 6 months building infrastructure instead of shipping features?" Here's how I learned to articulate the business value.
Quantifiable Benefits
1. Reduced Time to Production
Before landing zone:
3-4 weeks to provision a new environment
15+ tickets across networking, security, compliance teams
Multiple review meetings
Manual error-prone configuration
After landing zone:
15-30 minutes for automated provisioning
Self-service (no tickets!)
Pre-approved configurations
Security and compliance built-in
ROI: Each team launches new services 12x faster. For a team launching 10 services/year, that's 30 weeks of saved time per team.
2. Security Incident Reduction
The data from multiple organizations I've worked with:
Before landing zone:
2-5 security incidents per month (misconfigured resources)
Average cost per incident: $25,000 (investigation + remediation)
Annual cost: $600,000 - $1,500,000
After landing zone:
0-1 security incidents per month
Incidents caught earlier (automated detection)
Average cost per incident: $5,000 (lower due to early detection)
Annual cost: $0 - $60,000
ROI: $540,000 - $1,440,000 saved annually on security incidents alone.
3. Operational Efficiency
Before landing zone (100 accounts):
5 platform engineers spending 80% time on account management
4 FTE dedicated to account management
Cost: 4 × $150,000 = $600,000/year
After landing zone (500 accounts):
Same 5 platform engineers managing 5x more accounts
20% time on account management (automation handles rest)
1 FTE equivalent dedicated to account management
Cost: 1 × $150,000 = $150,000/year
ROI: $450,000/year saved in operational costs while managing 5x more accounts.
4. Cloud Cost Optimization
Before landing zone:
No visibility into resource owners
Orphaned resources accumulate
No budget controls
Teams over-provision "just in case"
After landing zone:
Automatic tagging and cost allocation
Budget alerts prevent overspend
Automated resource cleanup (e.g., dev environments shut down nights/weekends)
Rightsizing recommendations actioned
Real numbers from a 150-account organization:
Annual cloud spend: $3.6M
Wasted spend before: 35% ($1.26M)
Wasted spend after: 12% ($432K)
ROI: $828,000/year saved in cloud costs
5. Compliance and Audit Costs
Before landing zone (SOC2 audit example):
6 weeks of engineering time gathering evidence
3 external auditors for 2 weeks
Remediation work for findings
Total cost: $180,000
After landing zone:
Automated compliance reporting
1 week of engineering time
2 external auditors for 1 week
Minimal remediation (controls automated)
Total cost: $45,000
ROI: $135,000 saved per audit. For organizations with multiple compliance frameworks (SOC2, ISO 27001, HIPAA, PCI-DSS), multiply by number of audits.
Total ROI Calculation
For a mid-sized organization (100 accounts):
Reduced time to production
$500,000
Security incident reduction
$900,000
Operational efficiency
$450,000
Cloud cost optimization
$828,000
Compliance cost reduction
$270,000 (2 audits)
Total Annual Benefit
$2,948,000
Investment:
6 months to build landing zone
3 engineers @ $150K each
Cloud provider costs during build
Total Investment: $450,000
ROI: 555% in first year. Payback period: 1.8 months after go-live.
Intangible Benefits
Beyond the numbers, there are benefits that don't show up in spreadsheets:
Developer Satisfaction:
"I can focus on building features instead of fighting infrastructure"
"I can deploy to production without waiting for tickets"
"Security is handled - I don't have to be an expert"
Risk Reduction:
Sleep better at night (no more 3am security incidents)
Confidence in audit results
Reduced "blast radius" of incidents
Business Agility:
Launch new products faster
Respond to market opportunities
Scale globally with confidence
Talent Attraction:
Engineers want to work on modern, well-architected platforms
"We use infrastructure as code" attracts better candidates
Demonstrates technical sophistication to prospects
The Real ROI Story
At a healthcare SaaS company, we built a landing zone and tracked the results:
Year 1:
Launched 23 new services (vs 8 the previous year)
Passed HIPAA audit with zero findings (vs 12 findings previous year)
Reduced cloud spend 32% while growing revenue 80%
Zero security breaches (vs 7 the previous year)
Engineering satisfaction improved from 3.2/5 to 4.7/5
The CEO's quote at year-end:
"The landing zone was the best infrastructure investment we've ever made. It's invisible to customers but enables everything we do. I wish we'd done it two years earlier."
That's the business value of a landing zone.
Landing Zone Adoption Patterns
After helping dozens of organizations implement landing zones, I've seen two distinct adoption patterns. Choosing the right one for your situation dramatically affects success.
Greenfield: Starting Fresh
Definition: Building a landing zone for a new cloud deployment with few or no existing workloads.
When This Applies:
New company starting cloud journey
New cloud provider adoption (already on AWS, adding Azure)
Spinoff or new business unit
Post-acquisition cleanup (starting over)
Advantages:
Clean slate (no technical debt)
Can implement best practices from day one
No migration complexity
Team learns the "right way" from the start
Challenges:
Longer time before first application deployment
Requires upfront investment before business value
Team learning curve
Must anticipate future needs
Greenfield Approach:
Phase 1: Foundation (Weeks 1-4)
Design account/subscription structure
Set up identity federation
Build hub network architecture
Configure centralized logging
Deploy security guardrails
Phase 2: Automation (Weeks 5-8)
Build account/subscription vending
Create IaC modules for common patterns
Set up CI/CD pipelines
Test deployment workflows
Phase 3: Onboarding (Weeks 9-12)
Document procedures and runbooks
Train application teams
Deploy first pilot workload
Gather feedback and iterate
Real Greenfield Example:
A fintech startup I advised took the greenfield approach:
Context:
30-person engineering team
No existing cloud infrastructure
Required SOC2 and PCI-DSS compliance from day one
Multi-region (US and EU for data residency)
Our Approach:
12 weeks to build landing zone before first production deployment
Started with AWS Control Tower
Added Terraform for custom configurations
Built account vending with ServiceNow integration
Results:
First production deployment at week 13
50 accounts created in first year
Passed SOC2 audit with 2 minor findings
Passed PCI-DSS audit first try
Engineering team velocity: 10 production deployments/week by month 6
Key Lesson: "The 12-week delay to build the landing zone paid for itself within 3 months. We'd still be fighting security findings if we'd rushed to production."
Brownfield: Retrofitting Existing Infrastructure
Definition: Implementing a landing zone for existing cloud deployments with active workloads.
When This Applies:
Organization already using cloud for 1+ years
Multiple teams creating their own accounts
Security or compliance incident forcing change
M&A requiring infrastructure consolidation
Advantages:
Can deliver incremental value
Learn from existing patterns
Business keeps running during migration
Challenges:
Technical debt to work around
Live workload migration complexity
Resistance from teams ("but our way works")
Higher risk (changing production systems)
Brownfield Approach:
Phase 1: Discovery & Assessment (Weeks 1-4)
Inventory all existing accounts/subscriptions
Map ownership and workload criticality
Identify security gaps and compliance issues
Document current network architecture
Assess migration complexity and risk
Phase 2: Foundation Parallel Build (Weeks 5-12)
Build landing zone in parallel (don't disrupt existing)
Create new account structure
Deploy hub network (separate from existing)
Set up logging and security services
Test with non-production workloads
Phase 3: Migration Waves (Weeks 13-52+)
Wave 1: New workloads go to landing zone (immediate)
Wave 2: Migrate dev/test environments (low risk)
Wave 3: Migrate non-critical production workloads
Wave 4: Migrate critical production workloads
Wave 5: Decommission legacy accounts
Parallel Operation:
Old accounts and new landing zone run side-by-side
Migrate workloads incrementally
Validate each migration
Rollback capability for first few months
Real Brownfield Example:
An e-commerce company with major technical debt:
Context:
127 AWS accounts (my crypto mining story!)
3 years of unmanaged growth
Security incident forced change
$15M annual cloud spend
100+ production applications
Our Approach: Discovery (Month 1):
Surveyed all 127 accounts
43 accounts had no owners (teams left company)
67 accounts had production workloads
17 accounts completely orphaned
Foundation (Months 2-4):
Built landing zone with Control Tower
Created new account structure (Prod/Staging/Dev)
Deployed hub network with Transit Gateway
Configured centralized logging and security
Migration (Months 5-18):
Wave 1 (Month 5): All new deployments to landing zone
Wave 2 (Months 6-8): Migrated 30 dev/test accounts
Wave 3 (Months 9-14): Migrated 50 non-critical production workloads
Wave 4 (Months 15-18): Migrated 17 critical production workloads
Cleanup (Months 16-20): Shut down legacy accounts
Results:
127 legacy accounts → 85 landing zone accounts (better organized)
Zero production downtime during migration
$15M spend → $10.2M spend (32% reduction through deduplication)
Security incidents: 2-5/month → 0-1/month
Passed SOC2 audit (previously couldn't pass)
Key Lesson: "Migration was messy and took 18 months, but we delivered value continuously. Each wave reduced complexity and risk. We couldn't have waited to do everything at once."
Choosing Your Approach
Existing workloads
None or few
Many active workloads
Timeline pressure
Can invest upfront
Need quick wins
Risk tolerance
Can take time to build right
Must minimize disruption
Team experience
Learning opportunity
Learn from existing patterns
Technical debt
None
Significant
Best for
New deployments, startups
Existing deployments, enterprises
Hybrid Approach: The Best of Both
Many organizations use a hybrid approach:
Build greenfield landing zone for new workloads while gradually migrating brownfield workloads:
Build landing zone (don't wait for perfection)
All new workloads go to landing zone (immediate value)
Migrate existing workloads incrementally (reduce risk)
Legacy accounts eventually decommissioned (cleanup)
This gives you:
Quick time to value (new workloads in weeks)
Reduced risk (migrations are gradual)
Continuous improvement (learn from each wave)
Clear end state (eventually all workloads in landing zone)
My Recommendation: Unless you truly have a clean slate, assume brownfield. Plan for migration complexity. Build the landing zone, then migrate incrementally. Don't try to migrate everything at once.
Common Misconceptions
After presenting landing zones to dozens of organizations, I hear the same misconceptions repeatedly. Let me address them.
Misconception 1: "Landing zones are only for enterprises"
The Myth: "We're only 20 people. We don't need this complexity."
The Reality: Small organizations benefit even more from landing zones because they have fewer people to manage complexity.
Real Example:
A 15-person startup I worked with:
2 platform engineers (13% of team)
Before landing zone: spending 60% time on account management
After landing zone: spending 15% time on account management
Result: 0.9 FTE gained for feature work (massive for a 15-person team)
The Truth: Landing zones reduce complexity for small teams by automating what they'd otherwise do manually. The ROI is actually higher for small teams because labor is their biggest constraint.
Misconception 2: "We'll build the landing zone later"
The Myth: "Let's just get something to production first. We'll come back and do it right later."
The Reality: Technical debt compounds. Retrofitting a landing zone is 10x harder than building it first.
Real Example:
Two startups I consulted for:
Startup A (landing zone first):
12 weeks to build landing zone
First production deployment week 13
1 year later: 80 accounts, well-organized, no security incidents
Engineering velocity: high (self-service deployment)
Startup B (production first):
First production deployment week 2 (moved fast!)
1 year later: 45 accounts, chaotic, 3 security incidents
Engineering velocity: low (manual processes, security reviews)
Spent months 12-18 retrofitting landing zone (should have been building features)
The Truth: "We'll do it later" usually means "we'll do it after a security incident forces us to" - at 10x the cost and with much higher risk.
Misconception 3: "Cloud provider tools are enough"
The Myth: "We'll just use AWS Control Tower / Azure Landing Zones. We don't need anything custom."
The Reality: Provider tools give you 70% of what you need. The last 30% requires customization for your organization.
What Provider Tools Give You: ✅ Account/subscription structure ✅ Basic security guardrails ✅ Centralized logging ✅ Fundamental networking
What Provider Tools Don't Give You: ❌ Integration with your identity provider ❌ Your compliance framework requirements ❌ Your network topology (on-prem connectivity) ❌ Your cost allocation and chargeback ❌ Your deployment workflows ❌ Your application patterns
The Truth: Start with provider tools (don't reinvent the wheel), but plan for customization. Infrastructure as Code (Terraform) lets you extend provider tools for your needs.
Misconception 4: "Landing zones slow down development"
The Myth: "All these governance controls and policies will make developers wait for approvals."
The Reality: Landing zones accelerate development by providing self-service infrastructure.
Before Landing Zone:
Developer needs new environment
Opens ticket with platform team
Waits 3 days for networking team
Waits 2 days for security review
Waits 1 day for account provisioning
Total: 6 days (and frustration)
After Landing Zone:
Developer needs new environment
Uses self-service portal
Automated provisioning in 15 minutes
Security and networking pre-configured
Total: 15 minutes (and happiness)
The Truth: Automated governance is faster than manual approvals. Landing zones replace slow manual processes with fast automated ones.
Misconception 5: "We're multi-cloud, so landing zones don't apply"
The Myth: "Landing zones are for single-cloud organizations."
The Reality: Landing zone concepts are cloud-agnostic. Consistency across clouds is even more valuable.
Multi-Cloud Landing Zone:
Same organizational structure across clouds (Prod/Staging/Dev)
Same identity provider federated to all clouds
Same compliance policies enforced everywhere
Same IaC tooling (Terraform works across all clouds)
Same monitoring aggregation (SIEM ingests from all clouds)
The Truth: Multi-cloud organizations need landing zones more than single-cloud, not less. Consistency is what makes multi-cloud manageable.
Misconception 6: "Landing zones are a one-time project"
The Myth: "We'll build it in 6 months, then we're done."
The Reality: Landing zones are living platforms that evolve with your organization.
Continuous Evolution:
New compliance requirements (add controls)
New application patterns (create modules)
Team growth (add accounts/subscriptions)
New cloud services (integrate into landing zone)
Security threats (update guardrails)
Cost optimization (refine monitoring)
The Truth: Plan for 20% of a platform engineer's time dedicated to landing zone evolution. It's not a project, it's an operating model.
Misconception 7: "We need a dedicated platform team first"
The Myth: "We don't have a platform team yet, so we can't build a landing zone."
The Reality: Landing zones can be built by small teams or even solo engineers with the right approach.
Minimum Viable Team:
1 platform engineer who knows Terraform
Part-time security person (can be contractor)
Leverage cloud provider tools (Control Tower, Azure Landing Zones)
Use community Terraform modules (don't build from scratch)
Real Example: I helped a 30-person startup build their landing zone with:
1 platform engineer (me, consulting part-time)
1 security contractor (10 hours/week)
12 weeks calendar time
6 weeks of actual engineering effort
The Truth: Modern tools and community resources make landing zones accessible to small teams. You don't need a dozen platform engineers.
Misconception 8: "Landing zones are just for compliance"
The Myth: "We're not regulated. We don't need this."
The Reality: Compliance is ONE benefit. Security, cost, and velocity are equally valuable.
Landing Zone Value Beyond Compliance:
Security: Reduced breach risk (saves millions)
Cost: Visibility and optimization (saves 20-40% of cloud spend)
Velocity: Self-service deployment (10x faster)
Operations: Reduced operational burden (scale without growing team)
Quality: Consistent, tested patterns (fewer production incidents)
The Truth: Even if you have zero compliance requirements, the ROI of landing zones is compelling for security, cost, and operational reasons alone.
What I Wish I'd Known
When I first started building landing zones, I believed several of these myths myself. Here's what experience taught me:
Start small: You don't need perfection. Build the foundation, then iterate.
Automate early: Manual processes don't scale. Automate from day one.
Leverage existing tools: Use Control Tower, Azure Landing Zones, Foundation Toolkit as a starting point.
Focus on outcomes: Landing zones are a means to an end (security, velocity, cost), not the end itself.
Measure value: Track metrics (time to deployment, security incidents, cost) to prove ROI.
Evolve continuously: Your first design won't be perfect. Plan for evolution.
Real-World Success Stories
Let me share three real landing zone implementations that demonstrate the transformative impact across different organization sizes and industries.
Success Story 1: Healthcare SaaS Startup (30 People)
Challenge:
18-month-old company, growing fast
HIPAA compliance required for Series A funding
23 AWS accounts created ad-hoc by different teams
Failed initial HIPAA audit with 47 findings
Investors threatening to pull Series A ($15M round)
Landing Zone Implementation:
Timeline: 10 weeks (faster due to urgency)
Team: 1 platform engineer (hired specifically for this) + 1 security consultant
Approach: AWS Control Tower + Terraform for customization
Brownfield migration: 4 months to migrate all workloads
Architecture:
Key Controls Implemented:
All data encrypted at rest (AWS KMS with audit logging)
Network segmentation (PHI isolated from non-PHI)
Access logging to immutable S3 bucket
Automated compliance scanning (Prowler + AWS Config)
MFA required for all human access
Service Control Policies preventing:
Creating resources outside us-east-1, us-west-2
Disabling CloudTrail
Creating unencrypted resources
Results:
✅ Passed HIPAA audit with zero findings (4 months after implementation)
✅ Series A funding closed ($15M)
✅ Security incidents: 0 (vs 2-3/month before)
✅ Development velocity: +200% (self-service accounts)
✅ Cloud costs: -25% (eliminated duplicate resources)
✅ Engineering satisfaction: 3.1/5 → 4.6/5
CEO Quote:
"The landing zone saved our Series A. Investors required HIPAA compliance, and there was no way we'd pass audit without it. Best $120K we ever spent."
Success Story 2: Financial Services Company (500 People)
Challenge:
6-year-old company with massive technical debt
287 AWS accounts + 43 Azure subscriptions
Multi-cloud strategy with no consistency
SOC2 and PCI-DSS compliance required
Multiple security breaches ($3.2M total cost in previous year)
Cloud spend: $8.5M/year with 40% waste
Landing Zone Implementation:
Timeline: 6 months foundation + 18 months migration
Team: 4 platform engineers + 2 security engineers
Approach: Multi-cloud (AWS Control Tower + Azure Landing Zones)
Brownfield migration: Phased approach with 5 waves
Multi-Cloud Architecture:
AWS (Primary - Customer Applications):
Azure (Secondary - Internal Systems):
Cross-Cloud Integration:
Federated to Okta SSO (both AWS and Azure)
ExpressRoute + Direct Connect hybrid connectivity
All logs to Splunk SIEM (AWS + Azure)
Terraform for both clouds (consistent IaC)
Shared monitoring (Datadog for both)
Key Challenges:
Legacy dependencies: Some applications couldn't easily migrate
Team resistance: "Our account works fine, why change?"
Compliance deadline: Had to pass SOC2 audit during migration
Zero downtime: All migrations during business hours
Migration Strategy:
Results:
✅ 287 AWS accounts → 350 accounts (better organized)
✅ 43 Azure subscriptions → 40 subscriptions (consolidated)
✅ Security breaches: $3.2M/year → $0 (zero breaches in 18 months post-landing zone)
✅ SOC2: Passed during migration (interim controls documented)
✅ PCI-DSS: Passed first attempt post-landing zone
✅ Cloud costs: $8.5M → $5.1M (40% reduction!)
✅ Time to production: 3 weeks → 2 hours (self-service)
✅ Platform team: 4 engineers managing 5x more accounts
VP Engineering Quote:
"We couldn't grow beyond 200 engineers without the landing zone. It was our platform for scale. The migration was painful but necessary - like open heart surgery while running a marathon."
Success Story 3: E-Commerce Company (2,000 People)
Challenge:
Global e-commerce platform (200M+ users)
800+ AWS accounts across 20 business units
Rapid growth through acquisition (12 companies in 3 years)
Each acquisition brought different cloud architectures
Compliance: PCI-DSS, GDPR, SOC2, ISO 27001
Cloud spend: $45M/year
Platform team overwhelmed (12 engineers supporting 800 accounts)
Landing Zone Implementation:
Timeline: 12 months foundation + 3 years migration (still ongoing)
Team: 12 platform engineers + 6 security engineers + 4 finops
Approach: AWS Control Tower + Custom Terraform
Brownfield migration: Continuous migration (never-ending due to M&A)
Enterprise-Scale Architecture:
Governance at Scale:
Policy Framework:
Service Control Policies (SCPs): 50+ policies across different OUs
Baseline (all accounts): Require encryption, MFA, CloudTrail
Production: Deny resource deletion without approval
Payments: PCI-DSS controls (restricted regions, services)
GDPR: EU data residency requirements
Automated Compliance:
AWS Config rules: 200+ rules across all accounts
Automated remediation: 80% of violations auto-fixed
Compliance dashboard: Real-time view across 800 accounts
Automated evidence collection for auditors
Cost Management:
Tagging policy enforced via SCPs (Business Unit, Environment, Application, Owner)
Automated chargeback reports (weekly to each BU)
Budget alerts per account
Automated cleanup of dev resources >7 days old
Reserved Instance/Savings Plan optimization
Self-Service Account Vending:
Innovation: Acquisition Integration Playbook:
Developed standardized process for integrating acquired companies:
Week 1-2: Discovery
Inventory all cloud resources
Map applications and dependencies
Assess compliance gaps
Estimate migration complexity
Week 3-4: Landing Zone Extension
Create OU for acquired company
Set up network connectivity
Integrate identity systems
Enable logging and monitoring
Month 2-6: Migration
Migrate non-production first
Application-by-application migration
Dual-run for validation
Cutover with rollback plan
Post-Migration:
Decommission legacy accounts
Full integration into main landing zone
Team training on new platform
Results:
✅ 800+ accounts managed by same 12-person team (66 accounts per engineer)
✅ Account provisioning: 3 weeks → 15 minutes (automated)
✅ Security posture score: 62% → 94% (AWS Security Hub)
✅ Compliance audits: 4 frameworks, all passed
✅ Cloud costs: $45M → $32M (29% reduction despite 40% growth in resources)
✅ Acquisition integration: 6 months → 2 months (standardized process)
✅ Production deployments: 50/week → 300/week (6x increase)
✅ Security incidents: 8-12/month → 1-2/month (90% reduction)
CTO Quote:
"The landing zone is our competitive advantage. We can integrate acquisitions in 2 months vs competitors taking 12+ months. We move fast while staying secure and compliant. It's what makes our M&A strategy possible."
Common Success Patterns
Across all these success stories, I noticed common patterns:
1. Executive sponsorship was critical
Success stories had C-level support (CTO, CIO, CISO)
Executive champion secured budget and team buy-in
Leadership communicated "why" to the organization
2. Start with security or compliance driver
Audit failure, security breach, or compliance requirement created urgency
Business understood the "burning platform"
Easier to get budget when it's existential
3. Incremental value delivery
All successful implementations showed value within 3 months
Didn't wait for perfection before onboarding first workload
Continuous improvement based on feedback
4. Investment in automation
Manual processes don't scale beyond 50 accounts
Terraform/IaC was non-negotiable for success
Self-service account vending was transformative
5. Measure and communicate ROI
Successful teams tracked metrics (time to deploy, security incidents, costs)
Regular reporting to leadership on value delivered
Used data to justify continued investment
6. Platform team evolution
Platform team grew with organization (typical ratio: 1 platform engineer per 50-100 accounts)
Initially focused on building, later on enablement
DevOps culture (platform team enables application teams)
What Made These Successful
Reflecting on what separated successful landing zone implementations from failed ones:
✅ Success Factors:
Clear business problem (compliance, security, cost)
Executive support and budget
Dedicated team (not side project)
Phased approach (not big bang)
Automation from day one
Continuous measurement and improvement
❌ Failure Factors:
"Nice to have" project (no urgency)
No executive support (battles for budget)
Part-time team (never finishes)
All-or-nothing approach (never ships)
Manual processes (doesn't scale)
No metrics (can't prove value)
The difference between success and failure often came down to treating the landing zone as a strategic platform, not a tactical project.
When Do You Need a Landing Zone?
The most common question I get: "Do we actually need a landing zone, or is this overkill for our size?"
Clear Signs You Need a Landing Zone Now
Security Red Flags:
🚨 You've had a security incident in the past year
🚨 You found resources with public access you didn't know about
🚨 You can't answer "who has access to what" without manual auditing
🚨 Root accounts don't have MFA enabled
🚨 No centralized logging (can't investigate incidents)
Compliance Triggers:
🚨 You need to pass SOC2, HIPAA, PCI-DSS, or ISO 27001
🚨 Auditor findings related to infrastructure controls
🚨 Customer security questionnaires you can't answer
🚨 Data residency requirements (GDPR, local regulations)
Operational Pain Points:
🚨 More than 20 cloud accounts/subscriptions
🚨 Multiple teams requesting new accounts weekly
🚨 Platform team spending >50% time on account management
🚨 Weeks to provision new environments
🚨 Duplicate services across teams (monitoring, CI/CD, etc)
Cost Issues:
🚨 Cloud bill surprises (>20% variance month-to-month)
🚨 Can't attribute costs to teams/projects
🚨 Resources with no owners
🚨 Suspected waste but no visibility
Growth Indicators:
🚨 Engineering team >50 people
🚨 Multiple product teams deploying independently
🚨 Planning multi-region expansion
🚨 M&A activity (acquiring or being acquired)
If you have 3+ red flags, you need a landing zone now.
Growth Thresholds
Based on organizations I've worked with:
0-10 accounts: Optional
Manual management is feasible
Consider if growth expected or compliance required
Build simple foundation even if manual
10-50 accounts: Recommended
Manual management becoming painful
Automation ROI becomes positive
Good time to build before technical debt accumulates
50-100 accounts: Strongly Recommended
Manual management doesn't scale
Security risks increase significantly
Cost waste becomes substantial
Platform team effectiveness plateaus without automation
100+ accounts: Critical
Mandatory for operational viability
Security incidents nearly guaranteed without proper controls
Compliance audits will fail without automated evidence
Platform team will be overwhelmed without automation
Timeline Guidance
If you're greenfield (new to cloud):
Build landing zone BEFORE first production deployment
8-12 weeks for initial foundation
Start simple, add sophistication as you grow
If you're brownfield (existing cloud presence):
Decision point: How many accounts?
<20 accounts: 3-month project
20-100 accounts: 6-month project
100+ accounts: 12+ month project
Plan for parallel operation (old + new)
Migrate incrementally (don't disrupt production)
"But We're Too Small" Argument
I hear this constantly: "We're only X people, landing zones are for enterprises."
Let me reframe the question:
Wrong question: "Are we big enough for a landing zone?"
Right question: "Would our business benefit from better security, faster deployments, and lower costs?"
If the answer is yes, you need landing zone thinking - even if you implement a simplified version.
Minimum Viable Landing Zone:
1 management account/subscription
Basic organization structure (Prod/Staging/Dev)
Centralized logging
Basic security guardrails (require encryption, MFA)
Hub-spoke network (even if simple)
Infrastructure as Code (Terraform)
This can be built in 2-4 weeks by 1 engineer using cloud provider tools (Control Tower, Azure Landing Zones).
When to Wait
There are rare cases where waiting makes sense:
Wait if:
✋ You're in discovery phase (prototyping, not building products)
✋ You're pivoting frequently (product-market fit not found)
✋ You're pre-revenue and burning runway (focus on product)
✋ You're planning to shut down or pivot away from cloud
But even then, consider:
Basic security (MFA, encryption) is always worth it
Centralized logging costs little but saves you during incidents
Simple account separation (Prod/Dev) prevents obvious mistakes
My Recommendation
Greenfield: Build landing zone before first production deployment. The cost is low, the benefit is high.
Brownfield: If you have ANY of the red flags above, start planning your landing zone now. Waiting makes it more expensive.
Size doesn't matter as much as trajectory: If you're growing (team or infrastructure), you'll eventually need a landing zone. Building it early is 10x easier than retrofitting.
Start simple, evolve continuously: You don't need perfection on day one. Build the foundation, ship value, iterate based on feedback.
Getting Started: Your Landing Zone Journey
Ready to build your landing zone? Here's how to get started based on your situation.
Phase 1: Build the Business Case (Week 1-2)
Identify Your Primary Driver:
Most organizations have one of these driving factors:
🎯 Security incident → Prevent the next breach
🎯 Compliance requirement → Pass upcoming audit
🎯 Operational pain → Stop manual account management
🎯 Cost waste → Reduce cloud spend
🎯 Growth → Scale team from 20 to 200 engineers
Calculate ROI:
Use the framework from the Business Value section:
Time savings: How many hours/week spent on manual account management?
Security: Cost of security incidents in past year?
Compliance: Cost of failed audits or audit preparation?
Cloud waste: Estimate duplicate services + orphaned resources
Opportunity cost: Features not built because team doing infrastructure?
Sample ROI Deck for Leadership:
Phase 2: Assemble Your Team (Week 3-4)
Minimum Viable Team:
1 Platform Engineer (Terraform experience required)
0.5 FTE Security Engineer (can be consultant)
0.25 FTE Network Engineer (for hybrid connectivity)
Ideal Team (for faster delivery):
2-3 Platform Engineers
1 Security Engineer
0.5 FTE Network Engineer
1 Product Manager (to prioritize and communicate)
Skills Required:
✅ Terraform / Infrastructure as Code
✅ Cloud platform knowledge (AWS, Azure, or GCP)
✅ Networking (VPCs, subnets, routing)
✅ Security fundamentals (IAM, encryption, logging)
✅ CI/CD pipelines
✅ Python or similar for automation
Skills Nice-to-Have:
👍 Experience with Control Tower / Azure Landing Zones
👍 Compliance frameworks (SOC2, HIPAA, PCI-DSS)
👍 SIEM or log aggregation
👍 Multi-cloud experience
Phase 3: Design Your Landing Zone (Week 5-8)
Step 1: Define Account/Subscription Structure
Example starting structure:
Step 2: Design Network Architecture
Start simple:
Hub VPC/VNet: 10.100.0.0/16
Spoke VPCs/VNets: 10.101.0.0/16, 10.102.0.0/16, etc
On-prem connectivity (if needed)
Internet egress through hub firewall
Step 3: Define Security Guardrails
Minimum policies:
✅ Require MFA for all human access
✅ Require encryption at rest
✅ Require encryption in transit
✅ Deny public access to storage (unless explicitly allowed)
✅ Require CloudTrail/Activity Logging enabled
✅ Restrict regions (for data residency)
Step 4: Choose Your Tools
Cloud Provider Native:
AWS: Control Tower
Azure: Landing Zone Accelerator
GCP: Cloud Foundation Toolkit
Infrastructure as Code:
Terraform (recommended for multi-cloud)
Azure Bicep (Azure-specific)
AWS CDK (AWS-specific)
Monitoring & Security:
Native tools first (GuardDuty, Defender, Security Command Center)
SIEM for aggregation (Splunk, Datadog, Elastic)
Phase 4: Build the Foundation (Week 9-16)
Week 9-10: Management & Governance
Create organization structure
Set up management account
Configure billing and cost management
Deploy Service Control Policies / Azure Policies
Week 11-12: Network Foundation
Create hub network
Configure hybrid connectivity (if needed)
Set up DNS
Deploy network firewall
Week 13-14: Security & Logging
Create security account
Configure centralized logging
Enable GuardDuty / Defender
Set up SIEM integration
Week 15-16: Shared Services & Automation
Create shared services account
Deploy CI/CD platform
Build account vending automation
Create Terraform modules
Phase 5: Pilot & Validate (Week 17-20)
Deploy First Workload:
Choose non-critical application
Create application landing zone account
Deploy application using new patterns
Validate networking, security, logging
Gather Feedback:
Application team experience
Security team validation
Compliance check
Performance benchmarking
Iterate:
Fix issues discovered
Improve automation
Update documentation
Refine processes
Phase 6: Scale & Onboard (Week 21+)
Onboarding Waves:
Wave 1: New workloads (immediate)
Wave 2: Dev/test migrations (low risk)
Wave 3: Production migrations (careful planning)
Enable Self-Service:
Documentation and runbooks
Self-service portal or API
Training for application teams
Support model (Slack, tickets, office hours)
Continuous Improvement:
Monthly retrospectives
Quarterly roadmap updates
Security and compliance reviews
Cost optimization sprints
Resources to Get You Started
Official Documentation:
Terraform Modules:
Community Resources:
AWS re:Invent sessions on landing zones
Azure FastTrack architecture sessions
GCP architecture center
My Other Series:
Terraform 101 - If you need to learn Terraform first
This series (you're here!) - Deep dive on landing zones
Your First Week Checklist
If you're starting tomorrow, here's your week 1 checklist:
Monday:
Tuesday:
Wednesday:
Thursday:
Friday:
Week 2 and beyond:
Follow the phases above
Iterate based on your specific needs
Don't aim for perfection - aim for progress
What I Learned About Landing Zones
After building dozens of landing zones across different organizations, cloud providers, and industries, here are the most important lessons I learned.
1. Landing Zones Are About People, Not Technology
The Mistake I Made:
Early in my career, I thought landing zones were a technical problem. I focused on perfect architectures, optimal network topologies, and comprehensive policies.
What I Learned:
Landing zones are about enabling teams. The technology serves the people, not the other way around.
Key Insights:
Developer experience matters more than perfect architecture
Self-service beats security reviews for common patterns
Clear documentation beats complex automation
Simple and working beats perfect and theoretical
Example:
At one company, I built a "perfect" landing zone with sophisticated policies and controls. Developers hated it - too complex, too many restrictions, too slow.
We simplified:
Reduced policies from 50 to 15 (kept essential ones)
Made self-service account creation
Improved documentation
Added Slack bot for common questions
Developer satisfaction went from 2.1/5 to 4.3/5. Security posture didn't change - we just made it easier to use.
2. Start Simple, Add Complexity Only When Needed
The Mistake I Made:
I tried to anticipate every future need and build for it upfront. Multi-region, disaster recovery, advanced networking, zero-trust architecture - all in v1.
What I Learned:
YAGNI (You Aren't Gonna Need It) applies to landing zones too.
Key Insights:
Start with single region, add multi-region when needed
Basic hub-spoke is enough initially
Don't build account vending until you're creating >5 accounts/week
Perfect network segmentation can wait
Example:
V1 (4 weeks to build):
Single region (us-east-1)
Simple hub-spoke (no firewall initially)
Basic security (encryption, MFA, logging)
Manual account creation (we created 2-3/month)
V2 (6 months later, after growth):
Multi-region (added eu-west-1 for GDPR)
Network firewall (traffic increased enough to justify)
Automated account vending (now creating 10+/month)
Advanced monitoring (scale required it)
Shipping V1 in 4 weeks delivered value immediately. V2 addressed real needs, not anticipated ones.
3. Brownfield Is Always Harder Than You Think
The Mistake I Made:
I consistently underestimated brownfield migration complexity. "We'll just move the resources to new accounts, should take a few weeks."
What I Learned:
Plan for 3x your estimate for brownfield migrations. Hidden dependencies, legacy tech debt, and risk aversion slow everything down.
Key Insights:
Discovery takes longer than you think (2-4 weeks minimum)
Every "simple" app has hidden dependencies
Teams resist change (even when new way is better)
You'll find undocumented resources
Rollback planning doubles the work
Example:
Migrating "simple" e-commerce application:
Estimated: 2 weeks
Actual: 7 weeks
Why:
Hidden dependency on legacy auth service
Hard-coded IP addresses in configs
Database migration needed downtime coordination
SSL certificates expired and had to be renewed
Team wanted extensive testing (weeks, not days)
4. Automation Is Non-Negotiable for Scale
The Mistake I Made:
At one organization, we managed 50 accounts manually. "It's working fine, why automate?"
Then we grew to 100 accounts. Manual processes collapsed. We spent 6 months playing catch-up on automation we should have built earlier.
What I Learned:
Automate from day one. Even if you only have 10 accounts, the ROI comes quickly.
What to Automate:
✅ Account/subscription creation
✅ Network connectivity setup
✅ Security baseline configuration
✅ Logging and monitoring enablement
✅ IAM role provisioning
✅ Compliance scanning
Manual processes don't scale beyond 50 accounts - period.
5. Security and Compliance Are Your Best Friends
The Mistake I Made:
I saw security and compliance teams as "blockers" who slowed down delivery.
What I Learned:
Security and compliance are your allies. They give you the business justification and budget for landing zones.
Key Insights:
Security incidents create urgency (sad but true)
Audit requirements force investment
Compliance frameworks provide structure
CISOs often become landing zone champions
Example:
At one company, platform team couldn't get funding for landing zone. "Nice to have, not critical."
Then: SOC2 audit failure + $250K penalty.
Suddenly: Landing zone budget approved in 48 hours. CISO became executive sponsor. Team of 3 engineers dedicated full-time.
Don't wait for the incident. Partner with security early.
6. Measure Everything, Prove ROI
The Mistake I Made:
Built amazing landing zone. Didn't track metrics. Couldn't prove value when budget review came. Almost got funding cut.
What I Learned:
Measure before and after. You need data to justify continued investment.
Metrics to Track:
Time to provision new account (hours)
Security incidents per month
Cloud spend trend (with tagging)
Developer satisfaction (quarterly survey)
Compliance audit findings
Platform team efficiency (accounts per engineer)
Example Dashboard:
Share this dashboard monthly with leadership. Visibility drives continued support.
7. Landing Zones Are Never "Done"
The Mistake I Made:
Treated landing zone as a project with an end date. "We'll build it in 6 months, then move on."
What I Learned:
Landing zones are products, not projects. They evolve with your organization.
Continuous Evolution:
New compliance requirements (add controls)
New cloud services (integrate into platform)
Security threats (update guardrails)
Team growth (add accounts, optimize)
Cost optimization (continuous improvement)
Developer feedback (improve experience)
Plan for 20-30% of platform team time dedicated to landing zone evolution, forever.
8. Community Resources Are Invaluable
The Mistake I Made:
Tried to build everything from scratch. "We're special, community solutions won't work for us."
Wasted months reinventing wheels that already existed.
What I Learned:
Leverage community resources. Very few problems are unique to your organization.
Where to Start:
AWS Control Tower / Azure Landing Zones / GCP Foundation Toolkit (don't build from scratch)
Terraform Registry modules (community-tested)
GitHub (learn from others' code)
AWS/Azure/GCP reference architectures
Cloud adoption frameworks
Customize, don't create: Start with proven patterns, customize for your needs.
9. The Best Time to Build Was Yesterday, The Second Best Time Is Now
The Pattern:
Every organization I've worked with says the same thing:
"I wish we'd built the landing zone 2 years earlier. It would have been so much easier."
The Truth:
If you're starting cloud: Build landing zone before first production deployment
If you have <50 accounts: Build landing zone now before technical debt compounds
If you have >50 accounts: Build landing zone yesterday (but now is second best)
The cost of waiting exceeds the cost of building by 10x or more.
10. Success Requires Executive Sponsorship
The Mistake I Made:
Tried to build landing zone as grassroots effort. Made progress until we needed budget, then hit wall.
What I Learned:
Get executive sponsor (CTO, CIO, or CISO) before you start. Landing zones require investment, and mid-level managers can't always approve it.
What Executive Sponsor Provides:
Budget for team and tools
Air cover for tough decisions
Communication to organization about why this matters
Tie-breaking when stakeholders disagree
Long-term commitment (landing zones are multi-year)
How to Get Executive Sponsor:
Articulate business problem (security, compliance, cost, velocity)
Quantify ROI (use framework from this article)
Show success stories from similar organizations
Make it about business outcomes, not technology
Conclusion: Your Landing Zone Journey Starts Here
Landing zones transformed how I think about cloud infrastructure. They turned cloud from a source of chaos and risk into a platform that enables businesses to move fast while staying secure and compliant.
The Core Insight:
You can't scale cloud without proper foundations. Just like you can't build a city without infrastructure (power, water, roads), you can't build cloud at scale without a landing zone.
The Choice:
You have two paths:
Path 1: Build Landing Zone First
Invest 8-16 weeks upfront
Deploy first workload to solid foundation
Scale confidently with automated guardrails
Sleep well knowing security and compliance are built-in
Path 2: Deploy First, Fix Later
Move fast initially (weeks)
Hit scaling problems at 50-100 accounts
Spend months retrofitting landing zone while keeping production running
Suffer security incidents and compliance failures along the way
Eventually build landing zone anyway (at 10x cost)
Every organization eventually builds a landing zone - either proactively or reactively after a crisis.
The only question is: Will you build it before or after the crisis?
My Recommendation:
If you're reading this and don't have a landing zone yet:
This week: Build the business case (use ROI framework from this article)
Next week: Present to leadership and get executive sponsor
Week 3: Assemble team and start design
Week 4: Begin implementation
If you have an existing landing zone:
Review against the components in this article - what are you missing?
Measure your current state (security, velocity, cost)
Identify top 3 improvements for next quarter
Plan incremental enhancements
The Journey Continues:
This article covered the "why" and "what" of landing zones. The next articles in this series dive deep into the "how":
Next: Design Principles and Architecture Patterns - Hub-spoke topology, management hierarchies, naming conventions
Then: Identity, Access, and Security Foundations - IAM strategy, RBAC, security baselines
By the end of this series, you'll have the knowledge to build production-ready landing zones across AWS, Azure, and GCP.
Let's build better cloud foundations together.
Series Navigation
Previous: ← Cloud Landing Zone 101 Series Overview
Full Series: See Table of Contents
Quick Reference
Key Concepts Covered
✅ What is a cloud landing zone ✅ Platform vs application landing zones ✅ Multi-cloud perspective (AWS, Azure, GCP) ✅ Core components (accounts, identity, network, security, logging, governance, automation) ✅ Business value and ROI calculation ✅ Greenfield vs brownfield adoption ✅ When you need a landing zone ✅ Getting started guide
Key Takeaways
Landing zones are foundations, not applications - They enable teams to move fast while staying secure
The cost of NOT having a landing zone is 10x the cost of building one - Security incidents, compliance failures, and operational chaos are expensive
Platform and application landing zones create clear boundaries - Platform team provides shared services, application teams deploy workloads
Landing zone concepts are cloud-agnostic - Same patterns apply to AWS, Azure, and GCP
Start simple, evolve continuously - Don't wait for perfection, ship value and iterate
Automation is non-negotiable - Manual processes don't scale beyond 50 accounts
Measure everything - Track security, velocity, and cost to prove ROI
Landing zones are products, not projects - Plan for continuous evolution
Related Articles in This Series
About This Article: Written December 2025, based on real-world experience building landing zones for organizations from startups to Fortune 500 enterprises across AWS, Azure, and GCP. All examples and patterns are production-tested.
Word Count: ~12,500 words
Last updated