Landing Zone Design: [Organisation or platform name]
Design document for a cloud landing zone: the governed foundation of
resource hierarchy, identity, network, security guardrails, logging,
policy as code, cost management and environments into which every
workload is deployed. It includes a runbook for vending new accounts,
subscriptions or projects, the IaC repository layout, a compliance
mapping to CIS Benchmarks and the operating and change process.
Provider-neutral, with an equivalents table for AWS, Microsoft Azure
and Google Cloud. Design areas follow those published by the three
providers (Azure landing zone design areas, AWS multi-account and
Control Tower guidance, Google Cloud landing zone design). Replace
every [bracketed] value and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [LZD-001] |
| Landing zone name | [Name] |
| Provider and tenant or organisation | [Provider], [Organisation ID / tenant ID] |
| Implementation basis | [Provider reference implementation / Accelerator / Custom IaC] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@platform-lead] |
| Approvers/reviewers | [@security-architect], [@network-lead], [@finops-lead], [@enterprise-architect] |
| Primary regions | [Region 1], [Region 2] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Cloud adoption strategy], [Security architecture], [IaC repositories] |
Approvals
| Role | Name | Decision | Date |
|---|
| Platform owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Security | [@name] | [Decision] | YYYY-MM-DD |
| Network | [@name] | [Decision] | YYYY-MM-DD |
| Finance and FinOps | [@name] | [Decision] | YYYY-MM-DD |
| Architecture board | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved for first workloads; hub network and logging live |
| 1.1 | YYYY-MM-DD | [@name] | Example: Added regulated workloads branch with stricter guardrails |
Contents
1. Scope and design principles
1.1 Scope
| In scope | Out of scope |
|---|
| Example: Organisation hierarchy, identity federation, hub networking, central logging, guardrails, vending | Individual workload architectures |
| Example: Connectivity to two data centres and the corporate WAN | SaaS applications managed by business units |
| [Item] | [Item] |
1.2 Design principles
| ID | Principle | Consequence |
|---|
| LZP-001 (Example) | The unit of isolation is the account, subscription or project, not a resource group or folder | Each workload environment gets its own container; blast radius stays small |
| LZP-002 (Example) | Guardrails are inherited from the hierarchy, never configured per workload | Policies are attached to hierarchy nodes in section 3 |
| LZP-003 (Example) | Everything is deployed from code through a pipeline | No console changes in production; drift is detected and reverted |
| LZP-004 (Example) | Workload teams are autonomous inside guardrails | Teams own their resources; the platform owns shared services |
| LZP-005 (Example) | Design for the target scale from the start | Hierarchy, IP plan and quotas sized for [number] workloads |
| [LZP-NNN] | [Principle] | [Consequence] |
2. Provider equivalents
| Neutral term in this document | AWS | Microsoft Azure | Google Cloud |
|---|
| Organisation root | AWS Organizations, management account | Microsoft Entra tenant, tenant root management group | Organization resource |
| Hierarchy node | Organizational unit (OU) | Management group | Folder |
| Isolation container | Account | Subscription | Project |
| Preventive guardrail | Service control policy, resource control policy, Control Tower preventive control | Azure Policy with deny effect | Organization Policy constraint |
| Detective guardrail | AWS Config rules, Control Tower detective control | Azure Policy with audit effect, Defender for Cloud recommendations | Security Command Center findings |
| Managed landing zone service | AWS Control Tower, Landing Zone Accelerator on AWS | Azure landing zone reference implementations | Google Cloud setup and Cloud Foundation Fabric or blueprints |
| Vending mechanism | Account Factory, account vending pipeline | Subscription vending modules | Project factory |
| Hub network | Transit gateway with inspection VPC | Hub virtual network or Virtual WAN hub | Shared VPC host project or Network Connectivity Center hub |
| Central log store | Log archive account | Log Analytics workspace in the management subscription | Centralised log bucket via aggregated sinks |
| Federation | IAM Identity Center with external identity provider | Microsoft Entra ID | Cloud Identity or Google Workspace with external identity provider |
3. Resource hierarchy
The hierarchy groups isolation containers by the guardrails they need.
Policies attach at hierarchy nodes and are inherited by every container
below. Keep the depth to four levels or fewer below the root.
| Node | Purpose | Guardrail set | Who may create containers |
|---|
| Security (Example) | Log archive and security tooling | GRS-CORE, GRS-SECURITY | Platform team only |
| Infrastructure (Example) | Network hub, shared services | GRS-CORE, GRS-NETWORK | Platform team only |
| Workloads / Production (Example) | Production workload containers | GRS-CORE, GRS-PROD | Vending pipeline |
| Workloads / Non-production (Example) | Development and test containers | GRS-CORE | Vending pipeline |
| Workloads / Regulated production (Example) | In-scope regulated workloads | GRS-CORE, GRS-PROD, GRS-REG | Vending pipeline with security approval |
| Sandbox (Example) | Experiments, no connectivity to corporate network | GRS-CORE, GRS-SANDBOX (budget cap, no peering) | Self-service |
| Suspended (Example) | Containers awaiting closure | Deny all except read and billing | Platform team only |
| [Node] | [Purpose] | [Guardrail set] | [Creator] |
Naming convention for containers: [workload]-[environment]-[region code],
for example payments-prod-euw. Names are lower case, 30 characters or
fewer, and never reused after closure.
4. Identity and access
4.1 Human access
| Decision | Choice |
|---|
| Authoritative identity provider | Example: Corporate identity provider; no local cloud users except break-glass |
| Federation protocol | Example: SAML 2.0 or OpenID Connect, with automated user and group provisioning |
| Multi-factor authentication | Example: Phishing-resistant MFA required for all privileged roles |
| Permission model | Example: Roles assigned to groups, never to individuals; groups named [scope]-[role] |
| Privileged access | Example: Just-in-time elevation with approval and a maximum duration of 8 hours |
| Access reviews | Example: Quarterly for privileged roles, semi-annual for all others |
| Role ID | Role | Scope | Permissions summary | Assigned to |
|---|
| ROL-001 (Example) | Platform administrator | Organisation | Manage hierarchy, guardrails and shared services | Platform team group, just-in-time |
| ROL-002 (Example) | Workload operator | One container | Deploy and operate workload resources, no identity or network changes | Workload team group |
| ROL-003 (Example) | Read-only auditor | Organisation | Read configuration and logs | Audit group |
| ROL-004 (Example) | Security responder | Organisation | Read everything, isolate resources | Security operations group, just-in-time |
| [ROL-NNN] | [Role] | [Scope] | [Summary] | [Group] |
4.2 Machine access
Pipelines and workloads use short-lived credentials obtained through
workload identity federation or provider-managed identities. Record any
exception that needs a long-lived secret, with its owner, storage
location and rotation period.
4.3 Break-glass access
| Item | Design |
|---|
| Accounts | Example: Two break-glass identities per organisation root, not federated |
| Credential storage | Example: Hardware security keys in two separate safes; passwords split between two custodians |
| Use conditions | Example: Identity provider outage or lockout of all administrators |
| Alerting | Example: Any sign-in raises a critical alert to security operations and the platform lead |
| Testing | Example: Sign-in test every six months, recorded in the change log |
| Post-use actions | Example: Rotate credentials, review all actions taken, write an incident record |
5. Network topology and IP plan
5.1 Topology
| Decision | Choice | Rationale |
|---|
| Topology (Example) | Hub and spoke per region, hubs connected to each other | Central inspection and shared endpoints |
| Spoke-to-spoke traffic (Example) | Routed through the hub firewall, denied by default | East-west inspection and segmentation |
| Internet egress (Example) | Central egress through the hub with URL and threat filtering | Single control point |
| Internet ingress (Example) | Per-workload load balancer with web application firewall in the spoke | Workload ownership of public endpoints |
| DNS (Example) | Central private DNS zones in the hub, conditional forwarding to on-premises | Consistent name resolution |
| Private service access (Example) | Private endpoints for managed services; public endpoints denied by policy | Keep data paths private |
5.2 IP address plan
| Range | Size | Use | Region |
|---|
| Example: 10.100.0.0/14 | 262,144 addresses | All cloud address space, not used on premises | All |
| Example: 10.100.0.0/20 | 4,096 | Hub, region 1 | [Region 1] |
| Example: 10.101.0.0/16 | 65,536 | Spokes, region 1, allocated in /22 blocks | [Region 1] |
| Example: 10.102.0.0/20 | 4,096 | Hub, region 2 | [Region 2] |
| Example: 10.103.0.0/16 | 65,536 | Spokes, region 2, allocated in /22 blocks | [Region 2] |
| [Range] | [Size] | [Use] | [Region] |
Allocate spoke ranges through an IP address management tool integrated
with the vending pipeline (section 13). Never reuse a range until the
container that held it has been closed and its routes removed.
6. Connectivity
| Link ID | From | To | Type | Bandwidth | Redundancy | Owner |
|---|
| CON-001 (Example) | Data centre A | Hub region 1 | Dedicated private link | [10 Gbit/s] | Two links on separate devices | @network-lead |
| CON-002 (Example) | Data centre B | Hub region 1 | Site-to-site VPN | [1 Gbit/s] | Backup for CON-001 | @network-lead |
| CON-003 (Example) | Partner network | Partner spoke | Private connectivity with NAT | [500 Mbit/s] | Single, accepted risk RSK-004 | @integration-lead |
| [CON-NNN] | [From] | [To] | [Type] | [Bandwidth] | [Redundancy] | [@owner] |
State the routing model (static or dynamic, route advertisement limits),
how failover is tested and the expected failover time.
7. Security baseline and guardrails
7.1 Guardrail sets
| ID | Guardrail | Type | Set | Applied at | Response |
|---|
| GR-001 (Example) | Deny resource creation outside approved regions | Preventive | GRS-CORE | Root | Request blocked |
| GR-002 (Example) | Deny disabling or deleting central audit logging | Preventive | GRS-CORE | Root | Request blocked |
| GR-003 (Example) | Deny creation of long-lived user access keys | Preventive | GRS-CORE | Root | Request blocked |
| GR-004 (Example) | Deny public access to object storage unless tagged as approved public content | Preventive | GRS-PROD | Workloads / Production | Request blocked |
| GR-005 (Example) | Require encryption at rest with customer-managed keys | Preventive | GRS-REG | Regulated production | Request blocked |
| GR-006 (Example) | Detect security groups or firewall rules open to the internet on administrative ports | Detective | GRS-CORE | Root | Ticket to workload owner, fix within 7 days |
| GR-007 (Example) | Detect resources missing mandatory tags | Detective | GRS-CORE | Root | Weekly report, auto-tag where possible |
| GR-008 (Example) | Detect root or break-glass sign-in | Detective | GRS-CORE | Root | Critical alert to security operations |
| [GR-NNN] | [Guardrail] | [Preventive / Detective / Corrective] | [Set] | [Node] | [Response] |
7.2 Baseline services enabled in every container
| Service | Configuration | Owner |
|---|
| Audit logging of control-plane events (Example) | Enabled organisation-wide, delivered to the log archive | Platform team |
| Threat detection (Example) | Enabled in all regions, findings aggregated in the security tooling container | Security operations |
| Configuration recording and posture management (Example) | Enabled, benchmark checks from section 14 | Security operations |
| Key management (Example) | Customer-managed keys for regulated data, rotation yearly | Platform team |
| [Service] | [Configuration] | [Owner] |
8. Logging and monitoring
| Log type | Source | Destination | Retention | Access |
|---|
| Control-plane audit (Example) | All containers | Log archive, immutable storage | [1 year hot, 7 years archive] | Security and audit read-only |
| Network flow logs (Example) | Hub and spokes | Log archive | [90 days] | Network and security |
| Guardrail and posture findings (Example) | Posture service | Security tooling container | [1 year] | Security operations |
| Workload application logs (Example) | Workload containers | Workload log store, security copy for critical events | [Workload-defined, minimum 30 days] | Workload team, security |
| [Log type] | [Source] | [Destination] | [Retention] | [Access] |
Platform monitoring covers hub network health, private link status,
quota use, guardrail evaluation failures and pipeline failures. Route
platform alerts to the platform on-call rotation and security alerts to
security operations. Record each alert, its threshold and its runbook in
the platform runbook (dev/runbook).
9. Policy as code
| Item | Design |
|---|
| Policy language and tooling | Example: Provider-native policy definitions managed in IaC, with an open policy engine for pre-deployment checks |
| Repository | Example: platform-policies, protected main branch, two approvals including security |
| Testing | Example: Unit tests for each policy; deployment to the policy staging node before production |
| Rollout | Example: Audit mode for 14 days, review of findings, then enforcement |
| Pre-deployment checks | Example: Workload pipelines run the same rules against plans before apply |
| Exception handling | Example: Exemptions declared in code with expiry date, risk owner and ticket reference |
Every guardrail in section 7 has a policy file, a test and a named
owner. A guardrail with no code is a documented intention, not a control.
10. Cost management and tagging
| Tag key | Required | Allowed values | Purpose |
|---|
cost-centre (Example) | Yes | Finance cost centre codes | Allocation |
workload (Example) | Yes | Registered workload IDs | Showback, ownership |
environment (Example) | Yes | prod, test, dev, sandbox | Policy and reporting |
owner (Example) | Yes | Team distribution list | Contact for findings |
data-classification (Example) | Yes | public, internal, confidential, restricted | Security guardrails |
| [Tag] | [Yes / No] | [Values] | [Purpose] |
| Control | Design |
|---|
| Budgets (Example) | Created by vending for every container; alerts at 80 % and 100 % to the owner and FinOps |
| Anomaly detection (Example) | Daily anomaly detection with alerts above [a set percentage] day-on-day change |
| Shared cost allocation (Example) | Hub and shared services allocated by consumption share monthly |
| Sandbox limits (Example) | Hard budget action that stops resources at 100 % |
Review costs with the FinOps cost review (ops/finops-cost-review).
11. Environment strategy
| Environment | Purpose | Hierarchy node | Data allowed | Connectivity | Promotion gate |
|---|
| Sandbox (Example) | Learning and experiments | Sandbox | Synthetic only | Internet only | None |
| Development (Example) | Feature development | Non-production | Synthetic or masked | Hub, non-production routes | Automated tests |
| Test (Example) | Integration and performance tests | Non-production | Masked | Hub, non-production routes | Test sign-off |
| Production (Example) | Live service | Production or Regulated production | Real data | Hub, production routes | Change approval |
| [Environment] | [Purpose] | [Node] | [Data] | [Connectivity] | [Gate] |
12. IaC repositories
| Repository | Content | Pipeline | Approvers | State location |
|---|
platform-foundation (Example) | Hierarchy, organisation settings, log archive, security tooling | Plan on pull request, apply on merge | Platform and security | Dedicated state store in the platform container |
platform-network (Example) | Hubs, connectivity, DNS, firewall rules | Same, with change window | Network and security | Same |
platform-policies (Example) | Guardrail definitions and assignments | Staged rollout, section 9 | Security and platform | Same |
platform-vending (Example) | Vending modules and request definitions | Triggered by approved requests | Platform | Same |
| [Repository] | [Content] | [Pipeline] | [Approvers] | [State] |
13. Account and subscription vending runbook
13.1 Request intake
The workload team submits a request through [service portal]. The
request must contain the fields below; the pipeline rejects incomplete
requests.
| Field | Example | Used for |
|---|
| Workload ID | Example: WL-0142 payments | Naming, tags |
| Environments | Example: dev, test, prod | Number of containers |
| Business criticality and data classification | Example: Tier 1, confidential | Hierarchy placement, guardrails |
| Network needs | Example: Private connectivity to on-premises, /22 per environment | IP allocation, peering |
| Owner and cost centre | Example: @payments-lead, CC-4410 | Tags, budget alerts |
| Monthly budget | Example: [Value] per environment | Budget creation |
| Pipeline identity | Example: Repository payments-service | Federated deployment role |
13.2 Procedure
| Step | Actor | Action | Evidence |
|---|
| VND-01 | Workload team | Submit request with all fields | Request ticket |
| VND-02 | Pipeline | Validate fields, check naming and duplicates | Validation log |
| VND-03 | Approver per section 13.3 | Approve or reject | Approval record |
| VND-04 | Pipeline | Create container and place it in the hierarchy node for its classification | Container ID |
| VND-05 | Pipeline | Apply baseline: logging, threat detection, posture, key policy | Baseline run log |
| VND-06 | Pipeline | Allocate IP range from IPAM, create spoke, connect to hub | IPAM record, route table |
| VND-07 | Pipeline | Create groups and role assignments, federated pipeline identity | Role assignment list |
| VND-08 | Pipeline | Apply tags and create budget with alerts | Budget ID |
| VND-09 | Pipeline | Run post-provision checks (guardrails active, logs arriving, no public exposure) | Check report |
| VND-10 | Platform team | Hand over to the workload team with the onboarding guide | Handover message |
13.3 Approval rules and service level
| Request type | Approver | Target time from request to handover |
|---|
| Sandbox (Example) | Automatic | 1 hour |
| Non-production (Example) | Platform team | 1 working day |
| Production (Example) | Platform team and workload architect | 2 working days |
| Regulated production (Example) | Platform team and security | 5 working days |
13.4 Closure
To close a container: confirm with the owner, export required data, move
it to the Suspended node, remove network routes and release the IP range
after [30 days], then close it through the provider process. Keep the
audit logs for the full retention period.
14. Compliance mapping
The Center for Internet Security publishes CIS Benchmarks, consensus
configuration guides for each major provider (for example the AWS
Foundations, Microsoft Azure Foundations and Google Cloud Platform
Foundation benchmarks). Record the benchmark and version in use, map
each recommendation group to a guardrail and report the pass rate.
| Benchmark section (by topic) | Guardrails | Check method | Pass rate | Exceptions |
|---|
| Identity and access management (Example) | GR-003, ROL-001 to ROL-004 | Posture service, quarterly access review | [Value] | [EXC-NNN] |
| Logging (Example) | GR-002, section 8 | Posture service | [Value] | [EXC-NNN] |
| Monitoring and alerting (Example) | GR-008 | Alert test | [Value] | [EXC-NNN] |
| Networking (Example) | GR-006, section 5 | Posture service | [Value] | [EXC-NNN] |
| Storage and data protection (Example) | GR-004, GR-005 | Posture service | [Value] | [EXC-NNN] |
| [Topic] | [Guardrails] | [Method] | [Value] | [Exceptions] |
| Benchmark in use | Version | Profile level | Last assessed |
|---|
| [CIS benchmark for provider] | [Version] | [Level 1 / Level 2] | YYYY-MM-DD |
Map further obligations (data protection law, sector regulation,
customer contracts) in the Security architecture
(security/security-architecture).
15. Operations and change
| Activity | Cadence | Owner | Output |
|---|
| Guardrail findings triage (Example) | Daily | Security operations | Tickets to owners |
| Platform change advisory (Example) | Weekly | Platform lead | Approved change list |
| Quota and capacity review (Example) | Monthly | Platform team | Quota increase requests |
| Provider release review (Example) | Monthly | Platform architect | Backlog items for new features or deprecations |
| Break-glass test (Example) | Every six months | Security | Test record |
| Disaster recovery test of shared services (Example) | Yearly | Platform team | Test report |
| Design review of this document (Example) | Yearly or after major change | Architecture board | New version |
Changes to the hierarchy, identity federation, hub network or root-level
guardrails are major changes: they need an approved change request
(ops/change-request), a tested rollback and a communication to all
workload owners at least [5 working days] in advance.
15.1 Risks
| ID | Risk | Likelihood | Impact | Response | Owner |
|---|
| RSK-001 (Example) | A root-level guardrail blocks production deployments | Medium | High | Staged rollout, audit mode first | @platform-lead |
| RSK-002 (Example) | Identity provider outage locks out administrators | Low | High | Break-glass process, section 4.3 | @security-architect |
| RSK-003 (Example) | IP space exhausted in region 1 | Low | Medium | Unallocated part of the /14 held for growth, IPAM alerts at 70 % | @network-lead |
| RSK-004 (Example) | Partner link has no redundancy | Medium | Medium | Accepted until YYYY-MM-DD | @integration-lead |
| [RSK-NNN] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [@owner] |
16. Glossary and references
16.1 Glossary
| Term | Meaning |
|---|
| Landing zone | Governed, pre-configured cloud foundation into which workloads are deployed |
| Isolation container | AWS account, Azure subscription or Google Cloud project |
| Hierarchy node | Organisational unit, management group or folder that carries inherited policy |
| Guardrail | Preventive or detective control applied across many containers |
| Vending | Automated provisioning of a governed container on request |
| Break-glass | Emergency access path used only when normal access fails |
| IPAM | IP address management tool that tracks allocations |
16.2 References
| Reference | Version or date checked | Use |
|---|
| Microsoft Cloud Adoption Framework, Azure landing zone design areas, learn.microsoft.com | Page dated September 2025, checked YYYY-MM-DD | Design area coverage |
| Microsoft Cloud Adoption Framework, Subscription vending, learn.microsoft.com | Page dated December 2025, checked YYYY-MM-DD | Section 13 |
| AWS Control Tower User Guide, multi-account strategy for your landing zone, docs.aws.amazon.com | Current web edition | Hierarchy and OU pattern |
| Google Cloud Architecture Center, Landing zone design in Google Cloud, docs.cloud.google.com | Page updated January 2026 | Identity, hierarchy, network, security decisions |
| CIS Benchmarks, Center for Internet Security, cisecurity.org | Version per section 14 | Compliance mapping |
| [Internal standard] | [Version] | [Use] |
Standard and licence note
Structure aligned with the landing zone design areas published by
Microsoft (Cloud Adoption Framework for Azure), Amazon Web Services
(AWS Control Tower and Prescriptive Guidance multi-account guidance) and
Google Cloud (landing zone design in Google Cloud), and with the topics
covered by CIS Benchmarks. Product and framework names belong to their
publishers and are used for mapping only; CIS Benchmarks are referenced
by name and topic and no recommendation text is reproduced. This
template is original text written for this collection. Check the
current official documentation and benchmark versions before use.
Template licence: MIT.