CL-002·CL Track·Advanced·8–40 hrs saved

Design a Cloud Landing Zone That Ships Workloads — Not One Teams Route Around to Meet a Deadline

An AI-assisted workflow to design, review, and document a secure cloud landing zone sized to your actual workloads, risks, and operating maturity — not a copied provider reference architecture.

4Phases

14Prompts

8–40Hours saved

9Deliverables

Executive Brief

Your Challenge

You're standing up cloud, and every team is quietly building its own version of the foundation — their own accounts, networks, identity roles, logging, tags, and pipelines. The result is a fragmented environment where security controls vary by workload, privileged access can't be governed, logs are scattered, costs can't be allocated, and every new workload means repeating the same design work from scratch. Exceptions become permanent, platform teams become bottlenecks, and teams bypass standards to hit delivery dates.

Common Obstacles

The two failure modes sit at opposite extremes. Underbuild, and production workloads run without the identity, logging, recovery, and cost controls they need — the gaps only surface during an incident or an audit. Overbuild, and you get months of design without a single workload delivered: complex account hierarchies, excessive policy restrictions, unnecessary multi-region or multi-cloud architecture, and a platform the organization cannot actually operate. Copying a provider reference architecture wholesale produces controls that don't reflect your real risk, and treating the landing zone as a network project ignores identity, governance, cost, and operations entirely.

The ABME Approach

This workflow uses AI to design the landing zone in the right order: define objectives and design principles first, scope the minimum viable landing zone, then work capability domain by domain — organization hierarchy, identity and privileged access, network and connectivity, security policy, logging, data protection, backup and recovery, automation, cost, onboarding, and operating model. Each capability gets an owner, mandatory versus optional controls, a validation method, and a maturity target. The prompt pack drives the design and thirteen follow-ups; a production-readiness checklist, responsibility matrix, and risk register turn the output into something an accountable human can review and approve — because an AI-generated design is never production security approval.

Insight Summary

A landing zone is complete enough for production not when the foundational resources are deployed, but when identity, access, network, security, logging, cost, recovery, automation, ownership, and exception processes work together as an operating system for cloud adoption.

phase-1

Design for actual workloads and risks, not for a perfectly controlled cloud before any workload can move. The purpose is the minimum safe, scalable, repeatable foundation — overengineering delays delivery as surely as underbuilding endangers production.

phase-1

Build the hierarchy around security and lifecycle requirements, not the current org chart. Organizational structures change more frequently than the boundaries you're actually enforcing.

phase-2

Identity is the primary security boundary. Permanent broad administrative access is the single largest blast-radius risk — a compromised standing admin identity can affect every cloud environment at once.

phase-2

Private networking does not replace identity and authorization controls, and encryption alone does not satisfy data protection. Assuming otherwise creates false confidence that surfaces during an incident.

phase-3

A control without an exception process encourages shadow workarounds; an exception without an expiration date becomes undocumented permanent architecture. Make exceptions visible and time-bound or they defeat the policy.

tactical

Backup is not recovery. Break-glass access you haven't tested may fail when needed. Test restores and emergency access as deliberately as you test the happy path.

The Journey

Three phases; each lists the tools you'll use there.

Define Scope, Principles, and the Minimum Viable Zone

Establish objectives, design principles, and the smallest safe foundation before designing any capability.

Gather cloud strategy, workload portfolio, regulatory obligations, and existing environment
Define landing-zone objectives and design principles
Determine the minimum viable landing zone versus deferred capabilities
Select the organizational and container model
Assign ownership for each platform capability

Prerequisites Checklist

Design the Capability Domains with AI

Use the prompt pack to design hierarchy, identity, network, security policy, logging, and data protection domain by domain.

Run the primary prompt with requirements and existing-environment context
Apply follow-up prompts per capability domain
Design identity, privileged access, and network topology
Build the security-policy framework with enforcement modes and exceptions
Design centralized logging, encryption, keys, and secrets

Cloud Landing Zone Prompt Pack capability-domains-reference policy-framework-reference Responsibility Matrix Landing-Zone Requirements Template

Validate, Approve, and Operationalize

Prove the controls work, assign ownership, and gate production on human review across every discipline.

Run the landing-zone validation plan across every capability
Complete the production-readiness checklist by domain
Populate the risk register and resolve critical blockers
Confirm human security, network, identity, operations, finance, and compliance review

Landing-Zone Validation Plan Production Readiness Checklist Landing-Zone Risk Register

Govern and Mature the Platform

Establish review cadences, metrics, and a roadmap so the landing zone evolves without disruptive redesign.

Set governance standards and review cadences
Track landing-zone metrics for risk and friction
Advance capabilities against the maturity model
Reassess after incidents, provider changes, mergers, or regulatory change

Suggested Review Cadence

What's Inside the Execution Layer

Numbered deliverables grouped by phase. Membership unlocks every tool.

2. PHASE 2Prompt Packprotected

Cloud Landing Zone Prompt Pack

One comprehensive primary prompt and thirteen targeted follow-ups that design and review a secure cloud landing zone capability by capability.

Use this to

Generate a full landing-zone design adapted to your requirements
Drill into individual capability domains with focused follow-ups
Assess an existing landing zone and build a phased roadmap

Included with membership — $20/mo

Primary Prompt

Start here with your requirements and existing-environment context.

You are a senior cloud architect, cloud security architect, platform engineer, identity architect, network architect, and cloud governance advisor.

I will provide some or all of the following:
• Cloud-adoption objectives
• Target cloud providers
• Workload portfolio
• Business criticality
• Data classifications
• Security standards
• Regulatory requirements
• Identity architecture
• Network architecture
• Existing cloud environment
• Current accounts, subscriptions, or projects
• Existing organizational hierarchy
• Existing security policies
• Logging requirements
• Security operations requirements
• Backup requirements
• Recovery objectives
• Cost allocation requirements
• Infrastructure-as-code standards
• CI/CD platforms
• Operating model
• Support model
• Skills inventory
• Provider contracts
• Regional restrictions
• Migration roadmap
• Audit findings
• Known cloud risks

Your task is to design a secure, scalable, operable, and governable cloud landing zone.

Do not copy a generic provider reference architecture without adapting it to the supplied requirements.

Do not begin by selecting specific services unless the provider and requirements justify them.

First:

1. Summarize:
• Business drivers
• Workload scope
• Cloud providers
• Security requirements
• Compliance requirements
• Operational requirements
• Financial requirements
• Organizational constraints

2. Separate:
• Confirmed facts
• Reported observations
• Inferences
• Assumptions
• Unknowns

3. Identify missing evidence that materially affects the design.

4. Define landing-zone design principles.

5. Define the minimum viable landing zone.

6. Identify capabilities that can be implemented later.

7. Assess the current environment across:
• Organization and hierarchy
• Identity
• Privileged access
• Network
• DNS
• Connectivity
• Security policy
• Logging
• Security operations
• Encryption
• Key management
• Secrets
• Backup
• Disaster recovery
• Infrastructure-as-Code
• CI/CD
• Cost management
• Workload onboarding
• Operations
• Governance

Then design:

• Organizational hierarchy
• Account, subscription, or project model
• Production and nonproduction separation
• Sandbox strategy
• Shared-services model
• Identity and federation
• Privileged-access model
• Service and workload identities
• Network topology
• IP address management
• DNS
• Hybrid connectivity
• Internet ingress
• Internet egress
• Private service access
• Network segmentation
• Security baseline
• Policy hierarchy
• Policy enforcement
• Exception management
• Logging architecture
• Security monitoring
• Vulnerability management
• Encryption
• Key management
• Secrets management
• Certificate management
• Backup baseline
• Disaster recovery baseline
• Infrastructure-as-Code model
• CI/CD controls
• Drift detection
• Naming and tagging
• Cost allocation
• Budgets and alerts
• Workload onboarding
• Service catalog
• Operating model
• Responsibility matrix
• Support and incident response

For each capability provide:
• Objective
• Requirements
• Recommended design
• Mandatory controls
• Optional controls
• Owner
• Dependencies
• Implementation complexity
• Risks
• Validation method
• Evidence produced
• Maturity target

Requirements:
• Apply least privilege.
• Separate routine and privileged access.
• Identify all broad permanent access.
• Do not assume private networking replaces identity controls.
• Do not assume encryption alone satisfies data protection.
• Do not recommend customer-managed keys without operational justification.
• Do not recommend multi-region or multi-cloud without requirements.
• Do not centralize every workload function.
• Preserve appropriate workload-team autonomy.
• Define production and nonproduction separation.
• Define log protection and access.
• Define policy exceptions and expiration.
• Define cost ownership.
• Define backup and recovery ownership.
• Define emergency access.
• Define infrastructure change controls.
• Identify provider limits or design assumptions requiring validation.
• Identify where a proof of concept is required.
• State when requirements conflict.
• State when evidence is insufficient.
• Require human security, network, identity, operations, finance, and compliance review.

Then produce:
1. Executive summary.
2. Landing-zone objectives.
3. Scope and assumptions.
4. Design principles.
5. Minimum viable landing zone.
6. Target resource hierarchy.
7. Account, subscription, or project model.
8. Identity and privileged-access design.
9. Network and connectivity design.
10. Security-policy framework.
11. Logging and security-operations design.
12. Data-protection design.
13. Backup and recovery baseline.
14. Infrastructure-as-code and CI/CD model.
15. Naming, tagging, and cost-management design.
16. Workload-onboarding process.
17. Cloud operating model.
18. Responsibility matrix.
19. Implementation roadmap.
20. Validation plan.
21. Risk register.
22. Exceptions requiring decision.
23. Open questions.
24. Approval recommendation.

Design the Resource Hierarchy

To design the organizational hierarchy in depth.

Design the cloud organizational hierarchy.

Account for:
• Production
• Nonproduction
• Platform services
• Security services
• Shared services
• Sandboxes
• Business units
• Regulated workloads
• Regions
• Billing
• Policy inheritance
• Access delegation
• Acquisitions
• Quarantine
• Decommissioning

Explain why each hierarchy level exists and avoid unnecessary nesting.

Design the Account or Subscription Model

To compare container-separation options and pick a standard pattern.

Design the account, subscription, or project strategy.

Compare separation by:
• Workload
• Environment
• Business unit
• Region
• Data classification
• Customer
• Product
• Lifecycle

For each option assess:
• Isolation
• Cost allocation
• Policy
• Access
• Limits
• Operational overhead
• Scalability
• Migration complexity

Recommend a standard pattern and approved exceptions.

Design Landing-Zone Identity

To design identity, federation, and privileged access.

Design the identity and access model for the landing zone.

Include:
• Federation
• Single sign-on
• Multi-factor authentication
• Conditional access
• Privileged identities
• Just-in-time elevation
• Break-glass accounts
• Service identities
• Workload identities
• Guest access
• Role design
• Access reviews
• Joiner, mover, and leaver processes
• Logging
• Emergency access

Identify all permanent privileged access and recommend reductions.

Design the Cloud Network

To design network topology and connectivity.

Design the landing-zone network architecture.

Include:
• Address management
• Hub-and-spoke or alternative topology
• Transit routing
• Hybrid connectivity
• DNS
• Segmentation
• Internet ingress
• Internet egress
• Firewalls
• DDoS protection
• Web application protection
• Private endpoints
• Remote administration
• Third-party connectivity
• Network monitoring
• Resilience

Explain which functions should be centralized and which should remain distributed.

Design Security Policies

To build the policy framework and rollout plan.

Create the landing-zone security-policy framework.

Classify policies as:
• Preventive
• Detective
• Corrective

For each policy define:
• Control objective
• Scope
• Enforcement mode
• Owner
• Exception process
• Validation
• Evidence
• Operational impact
• Rollout plan

Begin new policies in audit mode where impact is uncertain.

Design Central Logging

To design centralized logging and SIEM integration.

Design centralized cloud logging.

Include:
• Identity logs
• Administrative activity
• Policy changes
• Network logs
• Firewall logs
• DNS logs where required
• Key and secret access
• Storage access
• Security findings
• Workload logs
• Backup activity
• Deployment activity

Define:
• Destination
• Retention
• Immutability
• Encryption
• Access
• Cost controls
• Privacy
• SIEM integration
• Alert ownership

Design Key and Secret Management

To design keys, secrets, and certificates.

Design the key, secret, and certificate-management model.

Assess:
• Provider-managed keys
• Customer-managed keys
• Key ownership
• Rotation
• Separation of duties
• Secret storage
• Workload retrieval
• CI/CD access
• Certificate issuance
• Renewal
• Revocation
• Logging
• Emergency access
• Recovery

Do not recommend customer-managed keys without explaining the operational requirement and failure implications.

Design Infrastructure-as-Code Governance

To design the IaC operating model.

Design the infrastructure-as-code operating model.

Include:
• Repository structure
• Module strategy
• State management
• Branch protection
• Code review
• Testing
• Security scanning
• Policy validation
• Deployment identities
• Environment promotion
• Approval
• Rollback
• Emergency changes
• Drift detection
• Versioning
• Module ownership

Design Workload Onboarding

To create a repeatable onboarding workflow.

Create a workload-onboarding workflow.

Collect:
• Business owner
• Technical owner
• Criticality
• Data classification
• Compliance scope
• Identity
• Connectivity
• Public exposure
• Recovery requirements
• Cost center
• Logging
• Monitoring
• Backup
• Deployment model
• Support model
• Exceptions

Define intake, architecture, provisioning, validation, handover, and production approval.

Assess an Existing Landing Zone

When reviewing or redesigning an existing foundation.

Assess the existing cloud landing zone.

Rate each capability as:
• Ready
• Partially ready
• Not ready
• Not applicable
• Unable to assess

Review:
• Resource hierarchy
• Identity
• Privileged access
• Network
• DNS
• Connectivity
• Policy
• Logging
• Security operations
• Encryption
• Keys
• Secrets
• Backup
• Recovery
• Infrastructure-as-Code
• CI/CD
• Tagging
• Cost management
• Onboarding
• Operations
• Governance

Identify critical production blockers.

Create a Landing-Zone Roadmap

To produce a phased implementation roadmap.

Create a phased landing-zone implementation roadmap.

Separate:
• Immediate production blockers
• Minimum viable landing zone
• Near-term governance capabilities
• Operational maturity improvements
• Long-term platform automation

For each phase include:
• Capabilities
• Dependencies
• Owners
• Risks
• Validation
• Success criteria
• Workloads enabled

Create a Responsibility Matrix

To assign ownership across teams.

Create a responsibility matrix for the landing zone.

Include:
• Platform team
• Security
• Identity
• Network
• Operations
• FinOps
• Compliance
• Workload teams
• Application owners
• Service desk
• Incident response

Cover design, implementation, operation, approval, exception, incident, and recovery responsibilities.

3. PHASE 2Matrixprotected

Responsibility Matrix

A RACI-style ownership map assigning each landing-zone capability to the accountable, responsible, consulted, and informed teams so no platform function is unowned.

Use this to

Assign accountability for each platform capability
Clarify platform-versus-workload ownership boundaries
Confirm ownership before production approval

Included with membership — $20/mo

Reference rows from the blueprint — downloads ship as an empty skeleton

Capability	Platform Team	Security Team	Workload Team	FinOps	Operations
Organization hierarchy	Accountable	Consulted	Informed	Consulted	Informed
Workload application security	Consulted	Consulted	Accountable	Informed	Consulted
Central logging	Responsible	Accountable	Responsible for workload logs	Informed	Consulted
Cost allocation	Consulted	Informed	Responsible	Accountable	Informed
Backup configuration	Provides platform	Defines baseline	Accountable for workload	Informed	Consulted
Incident response	Supports platform	Leads security incidents	Leads application incidents	Informed	Responsible for coordination

4. PHASE 3Matrixprotected

Landing-Zone Risk Register

A structured register of landing-zone risks with probability, impact, mitigation, and owner so critical blockers are tracked and accepted deliberately.

Use this to

Track design and operational risks with owners
Prioritize mitigations by probability and impact
Support risk acceptance before production approval

Included with membership — $20/mo

Reference rows from the blueprint — downloads ship as an empty skeleton

Risk	Probability	Impact	Mitigation	Owner
Policy enforcement blocks approved workload	Medium	High	Audit rollout and exception testing	Cloud Governance
Central firewall becomes bottleneck	Medium	High	Capacity model and performance testing	Network Team
Logging cost exceeds budget	High	Medium	Tiered retention and filtering	Security Operations
Excessive centralization delays onboarding	Medium	High	Delegated self-service patterns	Platform Team
Privileged access process fails during outage	Low	Critical	Break-glass testing	Identity Team
IaC state is compromised	Low	Critical	Encryption, restricted access, backup	Platform Engineering

5. PHASE 2Templateprotected

Landing-Zone Requirements Template

A structured intake for capturing landing-zone requirements across organization, identity, network, security, and operations before design begins.

Use this to

Capture requirements per capability area
Feed concrete requirements into the primary prompt
Align stakeholders on scope before design

Included with membership — $20/mo

Organization

Capture tenant, environment-separation, cost-reporting, workload-type, and sandbox requirements. Example items: Support one enterprise tenant; Separate production and nonproduction; Allow business-unit cost reporting; Support regulated and nonregulated workloads; Permit controlled sandbox use.

[Organization requirements]

Identity

Capture federation, MFA, privileged-access, and emergency-access requirements. Example items: Use corporate federation; Require multi-factor authentication; Use time-bound privileged access; Prohibit routine use of permanent owner-level access; Provide emergency accounts.

[Identity requirements]

Network

Capture connectivity, private-access, egress, ingress, and address requirements. Example items: Connect to two data centers; Support private database access; Centralize internet egress for regulated workloads; Permit distributed ingress for approved applications; Prevent overlapping cloud address ranges.

[Network requirements]

Security

Capture logging, SOC integration, region, encryption, exposure, and exception requirements. Example items: Centralize administrative and identity logs; Integrate alerts with the security operations center; Restrict deployment to approved regions; Require encryption; Govern public exposure; Track policy exceptions.

[Security requirements]

Operations

Capture IaC, ownership metadata, budget, recovery, and support requirements. Example items: Deploy platform components through infrastructure-as-code; Require resource ownership metadata; Establish workload budgets; Define backup and recovery standards; Provide production support ownership.

[Operations requirements]

8. PHASE 4Matrixprotected

Suggested Review Cadence

A cadence schedule mapping each governance review item to the interval it should run, so ongoing landing-zone ownership does not lapse after deployment.

Use this to

Schedule recurring landing-zone reviews by interval
Assign what is reviewed monthly, quarterly, semiannually, and annually
Trigger ad-hoc reviews after material events

Included with membership — $20/mo

Reference rows from the blueprint — downloads ship as an empty skeleton

Cadence	Review Items
Monthly	Critical security findings; Permanent privileged access; Policy exceptions; Public resources; Logging failures; Backup failures; Cost anomalies; Platform incidents
Quarterly	Access assignments; Policy effectiveness; Network capacity; Cost allocation; Landing-zone roadmap; Workload onboarding; Recovery testing; Platform-team capacity
Semiannually	Resource hierarchy; Identity architecture; Network design; Logging retention; Service catalog; Operating model; Skills; Provider roadmap changes
Annually	Landing-zone strategy; Regulatory alignment; Provider contracts; Multi-region requirements; Cloud exit considerations; Platform maturity; Major redesign needs

RubricReview immediately after a material security incident, provider change, merger, regulatory change, or major workload expansion.

🔒 The full execution layer — every checklist, matrix, and the prompt pack — is included with ABME membership.

Unlock Full Blueprint

Full Playbook

Overviewpublic

A cloud landing zone is the governed foundation into which cloud workloads are deployed.

It establishes the organizational, identity, network, security, operational, financial, and automation controls required to use cloud services consistently and responsibly.

A landing zone is not merely:

A virtual network
A subscription or account
A collection of security tools
A naming standard
A Terraform repository
A provider reference architecture copied without modification

A complete landing zone defines how the organization will:

Structure cloud resources
Separate environments and responsibilities
Authenticate users and services
Control privileged access
Connect cloud and on-premises environments
Apply security policies
Collect and protect logs
Detect and respond to threats
Manage encryption and secrets
Deploy infrastructure
Allocate and control cost
Back up and recover workloads
Grant exceptions
Onboard workloads
Operate the platform
Demonstrate compliance
Evolve the environment safely

The purpose of a landing zone is not to create a perfectly controlled cloud environment before any workload can move. The purpose is to establish the minimum safe, scalable, and repeatable foundation needed for the workloads and risks the organization expects to support.

This workflow uses AI to help design, review, and document a secure cloud landing zone based on business requirements, workload characteristics, regulatory obligations, operating maturity, and target cloud platforms. The goal is to answer: “What cloud foundation must exist so workloads can be deployed, secured, operated, and governed consistently without rebuilding core controls for every project?”

Business Problempublic

Organizations frequently begin cloud adoption with isolated projects. Individual teams may create their own accounts, subscriptions, projects, networks, identity roles, logging, security controls, naming, tags, deployment pipelines, backup methods, and cost models.

This creates a fragmented environment where:

Security controls vary by workload.
Privileged access is difficult to govern.
Logs are incomplete or dispersed.
Network connectivity is inconsistent.
Resource ownership is unclear.
Costs cannot be allocated.
Policies are applied manually.
Backup and recovery are inconsistent.
Incident response is slow.
Workload onboarding requires repeated design work.
Exceptions become permanent.
Compliance evidence is difficult to assemble.
Platform teams become bottlenecks.
Teams bypass standards to meet delivery deadlines.

At the opposite extreme, organizations may overengineer the landing zone. This can result in:

Months of design without workload delivery
Complex account hierarchies
Excessive policy restrictions
Slow onboarding
High operational overhead
Controls that do not reflect actual risk
Unnecessary multi-region or multi-cloud architecture
Large consulting dependency
A platform teams cannot maintain

A secure landing zone should balance security, agility, standardization, autonomy, cost, operational capability, regulatory obligations, and workload needs.

Typical Use Casespublic

Use this workflow when:

Beginning cloud adoption
Redesigning an existing cloud foundation
Preparing for production workload migration
Establishing a cloud center of excellence
Creating an enterprise cloud platform
Consolidating cloud accounts or subscriptions
Correcting uncontrolled cloud growth
Designing a regulated cloud environment
Building a multi-account or multi-subscription structure
Preparing for an audit
Integrating cloud logging with a security operations center
Standardizing workload onboarding
Establishing infrastructure-as-code
Designing cloud network segmentation
Defining cloud identity and privileged access
Implementing cloud cost allocation
Creating policy-as-code controls
Preparing a cloud operating model
Reviewing a provider-created landing-zone design
Acquiring or merging another cloud environment
Supporting multiple development teams
Establishing isolated environments for customers, regions, or business units

Do NOT Use This Workflow Whenpublic

This workflow is not intended to:

Copy a cloud-provider reference architecture without adaptation
Create controls unrelated to actual workload risk
Replace formal threat modeling
Replace detailed network design
Replace identity architecture
Replace regulatory or legal review
Guarantee compliance
Require every provider service in the initial implementation
Build a multi-cloud landing zone without a business requirement
Treat policy enforcement as a substitute for operational ownership
Treat landing-zone deployment as a one-time project
Assume production and nonproduction require identical controls
Centralize every technical decision
Allow unlimited team autonomy without guardrails
Block all exceptions
Embed permanent credentials in automation
Make the platform team responsible for every workload
Create a design that the organization cannot operate
Approve production use without human security and operational review

A landing zone should be proportional to business risk, workload needs, and organizational maturity.

Expected Outcomepublic

After completing this workflow, you should have:

Landing-zone objectives
Scope and design principles
Organizational resource hierarchy
Account, subscription, or project model
Environment-separation strategy
Identity architecture
Privileged-access model
Network topology
Connectivity design
DNS strategy
Security-control baseline
Policy hierarchy
Logging and monitoring architecture
Security-operations integration
Encryption and key-management design
Secrets-management design
Backup and recovery baseline
Infrastructure-as-code model
CI/CD controls
Resource naming and tagging standards
Cost allocation and budget controls
Workload-onboarding process
Exception-management process
Operating model
Responsibility matrix
Implementation roadmap
Validation plan
Risk register
Open questions

🔒 The complete playbook — reference models, worked examples, and operational guidance — is included with ABME membership.

Unlock Full Blueprint

Landing-Zone Objectivesprotected

A complete landing-zone design should answer:

What workloads will the platform support?
Which business units, regions, or customers require separation?
Which cloud providers are in scope?
How will resource ownership be organized?
How will production be separated from nonproduction?
How will users authenticate?
How will service identities be managed?
How will privileged access be approved and monitored?
How will cloud environments connect to users, partners, and on-premises systems?
Where will security inspection occur?
Which policies must be enforced centrally?
Which decisions may be delegated to workload teams?
How will logs be collected and protected?
How will security incidents be detected and investigated?
How will encryption keys and secrets be managed?
How will infrastructure be deployed and changed?
How will resources be named and tagged?
How will cost be assigned and controlled?
How will backup and recovery be governed?
How will workloads be onboarded?
How will exceptions be requested and expired?
Who owns each platform capability?
How will the landing zone be tested and improved?
What is the minimum viable landing zone?
Which capabilities can be introduced later?

Landing-Zone Design Principlesprotected

Recommended principles include:

Identity is the primary security boundary.
Privileged access is separate from routine access.
Production and nonproduction are separated.
Workload ownership is explicit.
Policies are automated where practical.
Infrastructure changes are version-controlled.
Logs are centralized and protected.
Security controls are risk-based.
Network access is deny-by-default where appropriate.
Public exposure is intentional and reviewed.
Resources are tagged and attributable.
Exceptions are documented and time-bound.
Platform services are reusable.
Workload teams retain appropriate autonomy.
Recovery is designed, not assumed.
Cost is visible to owners.
The platform can evolve without disruptive redesign.
Controls are validated continuously.
Provider-native capabilities are used where appropriate.
Portability is not pursued at the expense of usability without a requirement.

Landing-Zone Scopeprotected

A landing zone may include:

Organizational hierarchy
Resource containers
Identity integration
Privileged-access management
Network architecture
Hybrid connectivity
DNS
Internet ingress and egress
Firewall services
Private endpoints
Security policies
Encryption
Key management
Secret management
Logging
Metrics
Tracing
Security monitoring
Threat detection
Vulnerability management
Backup
Disaster recovery
Infrastructure-as-code
CI/CD
Artifact repositories
Configuration standards
Cost allocation
Budgets
Naming
Tagging
Workload onboarding
Exception management
Support processes
Incident response
Compliance reporting
Platform documentation

Landing-Zone Capability Domainsprotected

Organization and Resource Hierarchy

Define how resources are grouped for governance, billing, access, policy, environment, business unit, region, data classification, workload ownership, and lifecycle. The hierarchy should support control and delegation without excessive nesting.

Provider constructs may include: Azure tenants, management groups, subscriptions, and resource groups
AWS Organizations, organizational units, accounts, and resources
Google Cloud organizations, folders, projects, and resources

Identity and Access Management

Define the authoritative identity model.

Identity provider
Federation
Single sign-on
Multi-factor authentication
Conditional access
Workforce identities
Guest identities
Service identities
Workload identities
Privileged identities
Break-glass access
Role design
Group management
Access review
Joiner, mover, and leaver processes
Identity logging

Network Architecture

Define the network foundation.

Address spaces
Network segmentation
Shared network services
Hub-and-spoke or equivalent topology
Transit architecture
Routing
DNS
Hybrid connectivity
Internet ingress
Internet egress
Firewalls
Web application protection
DDoS protection
Private endpoints
Service-to-service access
Third-party connectivity
Remote administration
Network monitoring

Security Governance

Define the security and policy governance model.

Security baseline
Policy hierarchy
Mandatory controls
Advisory controls
Exceptions
Vulnerability management
Threat detection
Configuration management
Security review triggers
Security ownership
Risk acceptance
Compliance mapping

Logging and Monitoring

Define observability and evidence collection.

Platform logs
Identity logs
Administrative activity
Network logs
Workload logs
Security alerts
Metrics
Traces
Retention
Immutability
Access
Cost controls
Security information and event management integration
Alert routing
Time synchronization

Data Protection

Define data protection controls.

Data classification
Encryption at rest
Encryption in transit
Key ownership
Key rotation
Customer-managed keys
Provider-managed keys
Secret storage
Certificate management
Backup
Recovery
Data residency
Retention
Secure deletion

Platform Automation

Define automation and delivery controls.

Infrastructure-as-code
Source control
Code review
Deployment pipelines
State management
Policy-as-code
Configuration validation
Artifact management
Testing
Approval
Rollback
Drift detection
Emergency change

Financial Management

Define cost governance.

Billing structure
Cost allocation
Tags or labels
Budgets
Alerts
Forecasting
Commitment management
Chargeback or showback
Anomaly detection
Resource ownership
Nonproduction scheduling
Cost exception process

Operations

Define the operational model.

Platform ownership
Workload ownership
Support model
On-call expectations
Incident response
Change management
Service requests
Patch responsibility
Backup responsibility
Recovery responsibility
Capacity management
Problem management
Documentation
Service-level objectives

Organization and Container Designprotected

Organizational Hierarchy Design

A resource hierarchy should support separation, policy inheritance, access delegation, billing, reporting, lifecycle, and audit.

Common top-level groupings include:

Platform
Security
Shared services
Production
Nonproduction
Sandbox
Business units
Regulated workloads
Acquisitions
Suspended or quarantine

Avoid hierarchy models based only on the current organization chart. Organizational structures change more frequently than security and lifecycle requirements.

Example Resource Hierarchy

Organization or Tenant
│
├── Platform
│   ├── Identity Services
│   ├── Network Services
│   ├── Logging and Security
│   └── Automation
│
├── Production
│   ├── Regulated
│   ├── Customer-Facing
│   └── Internal
│
├── Nonproduction
│   ├── Development
│   ├── Test
│   └── Preproduction
│
├── Sandbox
│
└── Decommissioned or Quarantine

The exact implementation should reflect provider capabilities and organizational requirements.

Account, Subscription, or Project Strategy

Separate resource containers may be created by workload, environment, business unit, region, data classification, customer, product, lifecycle, or billing owner.

Common patterns include:

Workload and Environment Separation. Example: Workload A production, Workload A nonproduction, Workload B production, Workload B nonproduction. Benefits: clear ownership, strong environment separation, cost visibility, easier policy application. Risks: container proliferation, increased administration, shared-service complexity.

Business Unit Separation. Benefits: delegated administration, cost ownership, organizational alignment. Risks: duplicated platform services, inconsistent controls, cross-unit integration complexity.

Shared Environment Containers. Benefits: lower administrative overhead, simpler initial design. Risks: weaker isolation, shared limits, complex access, poor cost allocation, larger blast radius.

The container strategy should be documented and repeatable.

Production and Nonproduction Separation

Production and nonproduction should generally be separated through one or more of: accounts, subscriptions, projects, networks, identity roles, deployment pipelines, secrets, logging, approval processes, and administrative boundaries.

Production credentials should not be routinely available in development environments. Nonproduction should not become a path to production access.

Sandbox Strategy

Sandboxes support learning, prototyping, proofs of concept, service evaluation, and temporary testing.

Sandbox controls should include:

Limited data classifications
No production credentials
Budget limits
Automatic expiration where practical
Restricted networking
Approved regions
Prohibited services where necessary
Ownership
Resource cleanup
Logging
Clear promotion restrictions

Prototype resources should not silently become production.

Identity and Privileged Accessprotected

Identity Architecture

The landing zone should establish one authoritative identity model. Assess:

Corporate identity provider
Cloud-native identities
Federation
Directory synchronization
External users
Contractors
Partners
Customers
Service accounts
Managed identities
Workload identities
Device trust
Administrative identities

Avoid unnecessary standalone cloud users where federated identities are available.

Privileged Access Model

Privileged access should define:

Separate administrative identities
Multi-factor authentication
Just-in-time access
Time-bound elevation
Approval
Session monitoring
Access logging
Role eligibility
Emergency access
Access reviews
Privileged workstation requirements
Credential protection
Segregation of duties

Permanent broad administrative access should be minimized.

Break-Glass Access

Emergency access should include:

Limited number of accounts
Strong credentials
Protected storage
Exclusion from ordinary dependency paths where justified
Monitoring
Alerting
Defined use criteria
Post-use review
Regular validation
Documented ownership

Break-glass accounts should not be used for routine administration.

Role Design

Roles should follow least privilege. Define:

Platform administrator
Security administrator
Identity administrator
Network administrator
Billing administrator
Workload owner
Workload operator
Developer
Auditor
Read-only support
Incident responder

Avoid creating broad custom roles without lifecycle ownership.

Service and Workload Identities

Service identities should:

Be nonhuman
Use managed identity capabilities where available
Avoid long-lived credentials
Have defined owners
Have least-privilege access
Be restricted by environment
Be logged
Be rotated where credentials are unavoidable
Be removed when workloads are retired

Access Reviews

Review privileged roles, guest users, inactive accounts, service identities, high-risk permissions, cross-account access, third-party access, emergency accounts, and workload-owner access. The review cadence should reflect access risk.

Network and Connectivityprotected

Network Topology

Common models include hub-and-spoke, shared VPC or equivalent, transit network, mesh, isolated workload networks, regional hubs, and a global network backbone.

The topology should support segmentation, central services, scalable routing, inspection, hybrid connectivity, regional requirements, workload autonomy, and failure isolation.

Hub-and-Spoke Design

A hub may contain hybrid connectivity, firewalls, DNS, bastion or secure administration, network inspection, shared ingress, shared egress, and transit routing.

Spokes may contain individual workloads, environments, business units, and data zones.

Risks include hub bottlenecks, excessive centralization, complex routing, a large failure domain, and high data-transfer cost.

IP Address Management

Define address allocation, reserved ranges, regional ranges, environment ranges, on-premises compatibility, overlap prevention, acquisition handling, container networks, Kubernetes ranges, private endpoint ranges, documentation, and ownership. Overlapping address spaces can delay migration and merger integration.

DNS Architecture

Define public DNS ownership, private DNS, hybrid name resolution, conditional forwarding, split-horizon DNS, service discovery, private endpoint resolution, zone ownership, change process, logging, and resilience. DNS should not be treated as an implementation detail.

Hybrid Connectivity

Options may include site-to-site VPN, dedicated private circuits, provider interconnects, SD-WAN integration, partner connectivity, and internet-based encrypted tunnels.

Assess bandwidth, latency, redundancy, routing, encryption, failover, provider diversity, monitoring, capacity, cost, and recovery. Production-critical hybrid workloads should not rely on an untested single connection.

Internet Ingress

Define approved public-entry patterns, load balancing, web application firewall, DDoS protection, TLS termination, certificate management, authentication, rate limiting, API protection, logging, origin protection, and health checks. Public IP creation should be governed.

Internet Egress

Define centralized or distributed egress, network address translation, firewall inspection, domain filtering, proxy use, egress logging, static addresses, third-party allowlists, data-loss controls, cost, and high availability. Uncontrolled egress creates security, compliance, and cost risk.

Private Endpoints and Service Access

Use private connectivity where justified for databases, storage, key management, secrets, internal APIs, and management services.

Assess DNS complexity, routing, policy support, cost, regional availability, operational support, and service limitations. Private endpoints do not remove the need for identity and authorization controls.

Network Segmentation

Segmentation may be based on environment, workload, data classification, trust level, region, customer, administrative function, and shared services. Segmentation should reduce meaningful risk without creating unmanageable complexity.

Security Policy Frameworkprotected

Preventive

Block noncompliant deployment.

Prohibit public storage
Restrict regions
Require encryption
Prohibit unmanaged identities
Restrict resource types

Detective

Identify noncompliance after deployment.

Missing tags
Weak configuration
Expired certificates
Disabled logging

Corrective

Automatically remediate conditions. Corrective actions should be tested carefully to avoid disrupting workloads.

Enable logging
Apply retention
Remove public access
Quarantine resources

Policy Hierarchy, Enforcement, and Exceptionsprotected

Policy Hierarchy

Policies may apply at organization, tenant, management group, organizational unit, folder, account, subscription, project, resource group, and resource levels.

Document policy owner, scope, enforcement mode, exceptions, remediation, testing, evidence, and review cadence.

Policy Enforcement Modes

Example Mandatory Policies

Potential mandatory policies include:

Approved regions
Required resource ownership
Required cost-center tag
Encryption enabled
Diagnostic logging enabled
Public access restricted
Strong TLS
No unmanaged administrative accounts
Approved virtual-machine images
Approved network patterns
Backup required for designated services
Key rotation
Security-monitoring integration

Policies should reflect actual requirements and provider capabilities.

Exception Management

Every exception should include control, business justification, technical justification, risk, compensating controls, owner, approver, start date, expiration date, review date, remediation plan, and monitoring. Exceptions should not become undocumented permanent architecture.

Logging and Security Operationsprotected

Logging Architecture

Collect logs for identity activity, administrative actions, policy changes, network flows, firewall activity, DNS where appropriate, key and secret access, storage access, security findings, platform health, workload activity, backup operations, deployment activity, and billing and cost changes.

Logging Requirements

Define required sources, destination, retention, immutability, encryption, access, segregation of duties, time synchronization, parsing, searchability, export, cost controls, legal hold, and privacy.

Centralized Logging

Benefits: consistent retention, security analysis, incident investigation, cross-workload correlation, compliance evidence. Risks: high ingestion cost, central-service dependency, sensitive-data concentration, access complexity, regional restrictions. Not every log requires the same retention or destination.

Security Operations Integration

Define security alert sources, SIEM integration, detection rules, alert severity, triage ownership, escalation, incident creation, evidence retention, response automation, threat intelligence, and testing. Security tools without response ownership provide limited value.

Vulnerability Management

The landing zone should define responsibility for virtual machines, containers, images, functions, managed services, dependencies, network appliances, infrastructure-as-code, and configuration findings.

Define scanning, severity, ownership, service-level expectations, exceptions, validation, and reporting.

Configuration Management

Use policy, infrastructure-as-code, approved templates, security baselines, image standards, continuous assessment, and drift detection. Manual configuration should be minimized for repeatable platform components.

Data Protection, Backup, and Recoveryprotected

Encryption

Define requirements for data at rest, data in transit, backups, logs, snapshots, replication, administrative access, and external connections. Document when provider-managed keys are sufficient and when customer-managed keys are required.

Key Management

Define key ownership, key hierarchy, rotation, access, logging, backup, recovery, region, separation of duties, destruction, revocation, availability, and emergency access. Customer-managed keys introduce operational responsibility and availability dependencies.

Secrets Management

Secrets should be stored in approved services. Define secret owners, access, rotation, expiration, retrieval, logging, environment separation, emergency rotation, application integration, CI/CD integration, and removal.

Avoid source-code secrets, pipeline-variable sprawl, shared passwords, long-lived service-account keys, secrets in logs, and secrets in infrastructure state.

Certificate Management

Define certificate authority, issuance, renewal, deployment, monitoring, private keys, revocation, external certificates, internal certificates, ownership, and emergency replacement. Manual certificate renewal is a common source of avoidable outages.

Backup Baseline

Define workloads requiring backup, native service recovery capabilities, backup frequency, retention, immutability, encryption, cross-region or cross-account copies, access, monitoring, restore testing, ownership, and legal retention. Backup requirements should be based on business recovery needs.

Disaster Recovery Baseline

Define recovery-time objectives, recovery-point objectives, regional strategy, data replication, infrastructure recreation, dependency recovery, identity availability, DNS failover, connectivity failover, operational authority, testing, and communication. A multi-region design is not automatically required for every workload.

Automation and Deliveryprotected

Infrastructure-as-Code

The landing zone should be deployed through version-controlled automation where practical. Define languages and frameworks, repository structure, module ownership, state management, secrets handling, environment promotion, code review, testing, security scanning, policy validation, deployment identity, rollback, emergency change, drift detection, and versioning.

Infrastructure Module Strategy

Reusable modules may include account or subscription provisioning, network spokes, logging, monitoring, key management, workload identity, backup, budget controls, policy assignment, and deployment pipelines. Modules should provide guardrails without preventing justified workload requirements.

CI/CD Security

Landing-zone pipelines should define source-control protection, required reviews, signed artifacts where appropriate, deployment identities, least privilege, environment approvals, secret retrieval, policy checks, security scanning, change evidence, rollback, emergency deployment, and audit logs. Pipelines should not rely on permanent owner-level credentials.

Drift Detection

Detect changes made outside approved automation. Define scope, frequency, alerting, ownership, automatic remediation, exception handling, emergency changes, and reconciliation. Not all drift should be automatically reversed.

Naming, Tagging, and Cost Managementprotected

Naming Standards

Naming standards should be consistent, searchable, automatable, provider-compatible, stable, and short enough for service limits. Names may include organization, workload, environment, region, resource type, and instance number. Avoid encoding information likely to change, such as current owner names.

Tagging and Labeling

Required metadata may include business owner, technical owner, cost center, workload, environment, data classification, criticality, managed by, expiration, backup class, recovery class, and compliance scope. Define required tags, allowed values, inheritance, validation, enforcement, exceptions, and reporting.

Cost Management

The landing zone should establish billing ownership, cost allocation, budgets, alerts, forecasting, anomaly detection, showback or chargeback, commitment management, resource optimization, nonproduction schedules, orphan detection, cost reporting, and approval thresholds.

Budget Controls

Budgets should be defined by account, subscription, project, workload, environment, business unit, and cost center. Budget alerts should route to accountable owners. Budget alerts alone do not prevent overspending.

Onboarding, Service Catalog, and Operating Modelprotected

Workload Onboarding

A repeatable onboarding process should collect business owner, technical owner, criticality, data classification, recovery requirements, connectivity, identity, public exposure, cost center, compliance scope, logging, monitoring, backup, deployment model, support model, and exceptions.

Workload Onboarding Stages

Service Catalog

A cloud service catalog may include approved patterns for virtual machines, managed databases, containers, Kubernetes, serverless functions, storage, messaging, APIs, internet-facing applications, internal applications, data analytics, machine learning, secrets, and backup.

Each pattern should document intended use, security controls, deployment method, cost considerations, support model, limitations, and required approvals.

Cloud Operating Model

The landing zone should define who owns organizational hierarchy, identity integration, privileged access, network, DNS, connectivity, security policy, logging, security monitoring, infrastructure modules, cost management, backup, recovery, platform support, workload support, exceptions, and vendor escalation.

Minimum Viable Landing Zoneprotected

A minimum viable production landing zone may include:

Organizational hierarchy
Federated identity
Multi-factor authentication
Privileged-access controls
Production separation
Network architecture
Hybrid connectivity where required
Central logging
Security monitoring
Mandatory policies
Encryption baseline
Secrets management
Infrastructure-as-code
Resource ownership tags
Cost budgets
Backup baseline
Incident-response ownership
Workload-onboarding process

Capabilities can mature over time, but critical gaps should not be deferred without risk acceptance.

Maturity Modelprotected

Level 1 — Initial

Manual setup
Limited standards
Broad access
Inconsistent logging
Unclear ownership

Level 2 — Repeatable

Standard resource structures
Basic identity integration
Initial policies
Shared templates
Basic cost allocation

Level 3 — Governed

Automated provisioning
Central logging
Security monitoring
Enforced policies
Formal exceptions
Defined operating model

Level 4 — Measured

Continuous compliance
Cost optimization
Access reviews
Drift detection
Recovery testing
Service-level metrics

Level 5 — Optimized

Self-service platform
Automated evidence
Risk-based controls
Policy feedback
Integrated developer experience
Continuous improvement

Example Landing-Zone Design Summaryprotected

The organization should implement a hierarchical landing zone with separate platform, production, nonproduction, sandbox, and quarantine areas.

Production workloads should use separate subscriptions, accounts, or projects from nonproduction workloads. Shared identity, network, logging, security, and automation services should be centrally governed. Workload teams should receive delegated access within approved resource boundaries rather than broad platform-level access.

The minimum viable landing zone should prioritize:

Federated identity
Privileged-access controls
Production separation
Hybrid connectivity
DNS
Central logging
Security monitoring
Policy enforcement
Secrets management
Infrastructure-as-code
Cost allocation
Backup ownership
Workload onboarding

Advanced capabilities such as automated remediation, self-service catalogs, and comprehensive chargeback may be introduced after the production foundation is stable.

Example Resource Hierarchy (Enterprise)protected

Enterprise Cloud Organization
│
├── Core Platform
│   ├── Identity
│   ├── Network
│   ├── Logging and Security
│   └── Automation
│
├── Production
│   ├── Regulated
│   ├── Customer-Facing
│   └── Internal
│
├── Nonproduction
│   ├── Development
│   ├── Testing
│   └── Preproduction
│
├── Sandbox
│
└── Quarantine and Retirement

Example Findingsprotected

LZ-001 — Permanent Broad Administrative Access

Category: Identity and Privileged Access · Severity: Critical · Confidence: Confirmed

Evidence: Multiple users hold permanent organization-level or tenant-level administrator permissions for routine operational work.

Risk: A compromised identity or accidental action could affect all cloud environments.

Required Action:

Separate routine and privileged identities.
Replace standing access with eligible, time-bound elevation.
Require multi-factor authentication.
Require approval for the highest-risk roles.
Monitor every activation.
Maintain limited emergency accounts.

Owner: Identity and Security Teams

Validation:

Review role assignments.
Test elevation.
Confirm alerting.
Perform emergency-access exercise.

LZ-002 — Production and Development Share a Resource Container

Category: Organization and Isolation · Severity: High · Confidence: Confirmed

Risk: Development users, policies, budgets, service limits, and deployment automation may affect production resources.

Required Action: Create separate production and nonproduction resource containers and deployment identities.

Validation: Confirm access, network, policy, billing, and deployment separation.

LZ-003 — Logs Are Stored Only Within Workload Accounts

Category: Logging and Security Operations · Severity: High · Confidence: High

Risk: A compromised workload administrator may alter or remove evidence needed for investigation.

Required Action: Export required administrative and security logs to a centrally controlled destination with restricted deletion access.

Validation: Test ingestion, access, retention, and deletion controls.

Metricsprotected

Useful landing-zone metrics include:

Accounts, subscriptions, or projects compliant with hierarchy standards
Percentage of users using federation
Permanent privileged-role count
Privileged activations
Privileged access-review completion
Resources with required tags
Resources with public exposure
Policy-compliance rate
Policy exceptions
Exceptions past expiration
Required logs ingested
Security alerts with assigned owners
Mean time to triage
Secrets past rotation date
Backup coverage
Restore-test success
Infrastructure deployed through code
Drift findings
Deployment failure rate
Budget-alert response
Unallocated cloud cost
Workload-onboarding cycle time
Platform-service availability
Landing-zone incidents
Audit findings
Workload-team satisfaction

Metrics should identify risk and friction rather than reward excessive control.

Governance Recommendationsprotected

Define landing-zone ownership, resource hierarchy standards, account or subscription creation, identity standards, privileged-access standards, service identity standards, network standards, public-exposure approval, security baseline, policy lifecycle, exception process, logging requirements, retention, security operations integration, encryption standards, key management, secret management, backup requirements, recovery testing, infrastructure-as-code, CI/CD security, naming, tagging, cost ownership, workload onboarding, production approval, emergency change, audit evidence, review cadence, provider change management, and AI-assisted design validation.

Automation Opportunitiesprotected

Landing-zone requirements collection
Resource hierarchy design
Policy catalog creation
Identity-role analysis
Network-control review
Logging coverage analysis
Landing-zone maturity assessment
Workload-onboarding automation
Exception tracking
Cost-allocation validation
Infrastructure-as-code documentation
Compliance evidence generation
Production-readiness review
Platform roadmap generation
A mature automated workflow could: collect organizational and workload requirements; inspect existing cloud hierarchy and controls; compare current state to approved standards; identify policy, identity, network, logging, and cost gaps; generate proposed infrastructure changes; run policy and security validation; require human approval; deploy through controlled pipelines; validate post-deployment state; produce audit evidence; track exceptions and expiration; reassess continuously.

Pro Tipsprotected

Design for actual workloads and risks.
Establish identity before broad deployment.
Separate routine and privileged administration.
Separate production and nonproduction.
Keep the hierarchy understandable.
Use policies progressively.
Begin uncertain policies in audit mode.
Make exceptions visible and temporary.
Centralize evidence, not every technical decision.
Preserve workload-team autonomy within guardrails.
Treat DNS as a foundational service.
Design ingress and egress intentionally.
Use private access where it provides measurable value.
Protect centralized logs from workload administrators.
Define security-response ownership.
Use customer-managed keys only where justified.
Eliminate long-lived service credentials where possible.
Deploy platform components through version-controlled automation.
Protect infrastructure state.
Detect drift.
Require resource ownership metadata.
Configure cost controls before scale.
Test backup restores.
Test emergency access.
Create a repeatable workload-onboarding process.
Build the minimum viable landing zone first.
Mature controls based on evidence.
Require human validation of AI-generated designs.

Common Mistakesprotected

Copying a Reference Architecture — Provider reference architectures are starting points, not finished enterprise designs.
Building Too Much Before the First Workload — Controls should be prioritized according to actual workload risk and migration sequence.
Building Too Little for Production — Production workloads require identity, logging, security, ownership, recovery, and cost controls.
Treating the Landing Zone as a Network Project — Network architecture is only one landing-zone domain.
Granting Permanent Administrator Access — Broad standing privileges increase the blast radius of identity compromise.
Using One Account or Subscription for Everything — This weakens separation, billing, policy, and ownership.
Creating Excessive Resource Containers — Over-segmentation creates administrative and connectivity complexity.
Applying Policies in Enforce Mode Immediately — Untested policies can block deployment or disrupt existing workloads.
Ignoring Policy Exceptions — A control without an exception process encourages shadow workarounds.
Centralizing Every Function — Excessive centralization slows delivery and creates bottlenecks.
Delegating Without Guardrails — Uncontrolled autonomy creates inconsistent security and cost.
Assuming Private Networks Are Secure by Default — Identity, authorization, configuration, monitoring, and data protection remain necessary.
Collecting Every Log Indefinitely — Excessive logging creates high cost and privacy risk.
Using Customer-Managed Keys Everywhere — Customer-managed keys add operational complexity and potential outage dependencies.
Storing Secrets in CI/CD Variables Indefinitely — Use approved secrets-management integration and short-lived identities where possible.
Treating Backup as Recovery — Restore capability must be tested.
Ignoring DNS — DNS design failures can prevent otherwise correct migrations.
Failing to Assign Cost Ownership — Unowned cloud consumption is difficult to optimize.
Creating IaC Without Governance — Automation can reproduce insecure architecture faster.
Failing to Test Emergency Access — An untested break-glass process may fail when needed.
Treating Landing-Zone Deployment as Completion — The landing zone requires ongoing ownership, maintenance, review, and improvement.

Security Considerationsprotected

Landing-zone designs contain sensitive information such as identity architecture, privileged-access paths, network topology, firewall design, security policies, logging destinations, key ownership, emergency-access processes, recovery architecture, provider account structure, internal addresses, and audit findings.
Before sharing information with an AI system: Remove passwords.
Remove tokens.
Remove private keys.
Remove active connection strings.
Remove emergency-account credentials.
Sanitize IP addresses and hostnames where required.
Remove customer or employee data.
Follow vulnerability-handling procedures.
Follow architecture-classification requirements.
Confirm the AI platform is approved.
Confirm data-retention and model-training settings.
Restrict distribution of the generated design.
An AI-generated landing-zone design must not be treated as production security approval.

Brian Diamond

Founder, BrianOnAI

Twenty-five years designing, operating, and governing enterprise infrastructure — from MSP operations across dozens of client environments to enterprise infrastructure leadership. This blueprint codifies the operating model he's implemented in production, not theory.

Related Blueprints

Perform an Application Architecture Review Identify and Prioritize Technical Debt Review a Technical Design Modernize a Legacy Application Build and Maintain Development Prompts Assess Cloud Readiness and Select a Migration Strategy Design Cloud Identity and Access Controls Design Cloud Network Architecture Estimate and Optimize Cloud Costs Plan and Execute a Cloud Workload Migration Design Cloud Backup and Disaster Recovery Review Cloud Security and Configuration

⚠ Normalization Warnings — 14 for review

RESTRUCTURE: The doc contains ~40 flat H1 capability sections. To avoid rendering a flat list of 40+ sections, they were grouped into thematic body/group parents (Organization and Container Design, Identity and Privileged Access, Network and Connectivity, Policy Hierarchy/Enforcement/Exceptions, Logging and Security Operations, Data Protection/Backup/Recovery, Automation and Delivery, Naming/Tagging/Cost, Onboarding/Catalog/Operating Model). Confirm grouping boundaries.
CLASSIFICATION TO CONFIRM: 'Landing-Zone Capability Domains' (H1 with H2 subsections, each a Define-list) classified as body/reference — it is a domain catalog the reader consults. Alternative: body/prose group. Chose reference for consult-not-complete tell.
CLASSIFICATION TO CONFIRM: 'Security Policy Framework' (Preventive/Detective/Corrective) and 'Policy Enforcement Modes' (Audit/Enforce/Remediate) classified as body/reference tiered models. 'Maturity Model' and 'Workload Onboarding Stages' also reference. Confirm.
RESTRUCTURE: 'Primary Prompt' and 'Follow-Up Prompts' (two source H1s, 13 follow-ups) combined into one prompt_pack tool with 14 prompts; 'when' guidance lines are editorial additions, prompt text verbatim.
CLASSIFICATION TO CONFIRM: 'Prerequisites' classified as a checklist TOOL (gather-before-start items are completable). Alternative: body/prose.
CLASSIFICATION TO CONFIRM: 'Example Landing-Zone Requirements' classified as a template TOOL ('Landing-Zone Requirements Template') with sections per area; the doc's example items were placed in guidance as examples. Alternative: body/example. Confirm — this is a borderline example-vs-template call.
CLASSIFICATION TO CONFIRM: 'Landing-Zone Validation Plan' and 'Production Readiness Checklist' classified as checklist TOOLS (verifiable/completable items). Validation Plan alternative: body/reference. Chose tool because items are testable pass/fail.
MATRIX: 'Responsibility Matrix', 'Landing-Zone Risk Register', and 'Suggested Review Cadence' built as matrix tools from the doc's own tables/lists; example_rows verbatim; rubric empty except review-cadence trigger note which is verbatim from the doc.
'Suggested Review Cadence' was a set of H2 lists rather than a table; constructed a two-column cadence/items matrix from the doc's own groupings — confirm the matrix shaping vs. keeping as reference.
Three 'Example Finding' H1s (LZ-001/002/003) consolidated into one body/example section 'Example Findings' preserving all fields verbatim.
Two 'Example Resource Hierarchy' sections retained separately as body/example with ASCII trees reconstructed from the run-together source text (original had no line breaks in extraction) — confirm tree structure matches intent.
playbook.common_mistakes items carry the source H2 title plus its one-line body joined with an em dash; playbook.security_considerations and automation_opportunities flatten sub-lists into single entries where the source used intro+list — confirm acceptable flattening.
stats.deliverables=9 counts the nine tools. stats.prompts=14 counts primary + 13 follow-ups. Confirm counting convention.
Overlay headline/insights/exec_brief are written per voice rules from doc content; diff against any hand-authored overlay before publishing.

SEO Block

Title tag: Design a Secure Cloud Landing Zone | ABME (41 chars)
Meta: Design a secure, scalable cloud landing zone sized to real workloads — identity, network, policy, logging, cost, and recovery that teams actually use. (150 chars)
Schema: HowTo · noindex: false
Related: cl-001, cl-003, cl-004, cl-005, cl-006, cl-007, cl-008, cl-009, cl-010, ai-003, ai-007, ai-008, ai-009, ai-010
Keywords: cloud landing zone, secure landing zone design, azure landing zone, aws landing zone, cloud governance, minimum viable landing zone, cloud resource hierarchy, privileged access management cloud, cloud policy as code, cloud operating model, landing zone maturity model, cloud identity architecture

Copied