Cloud Landing Zone Security Guide

Most cloud estates are secured after the fact: workloads arrive first, and guardrails, central logging and identity design are retrofitted into hundreds of accounts, subscriptions or projects that were never built to accept them. A landing zone reverses that order by establishing the hierarchy, identity, logging, network and policy foundations before the first workload lands. This guide compares the landing zone patterns published by AWS (Control Tower and Landing Zone Accelerator), Microsoft (Azure landing zones in the Cloud Adoption Framework) and Google Cloud (the enterprise foundations blueprint), and sets out the security components every landing zone needs whichever provider you use. It is for cloud platform teams, security architects and anyone about to build or rebuild a cloud foundation. Platform-wide posture and workload protection are covered in the Cloud Security Guide and the CNAPP Guide.

Key takeaways

A landing zone is an operating model, not a template. The deployment takes hours; the account vending, exception handling and policy change process are what keep it secure for years.
Isolate the control plane first. The top-level administrative account, tenant or organisation sits outside or above most guardrails, so it must hold no workloads and very few people.
Logs belong somewhere workloads cannot reach. Every reference design sends audit logs to a dedicated, locked-down logging account, subscription or project.
Use all three control types: preventive policies at the hierarchy, proactive checks in the deployment pipeline, and detective rules for what slips through.
Vend environments through code. New accounts, subscriptions and projects should arrive already placed in the right part of the hierarchy, with logging, network and identity attached.

What a landing zone is

AWS describes a landing zone as a multi-account environment based on security and compliance best practices, and the container for all organisational units, accounts, users and resources that you want subject to compliance regulation. Microsoft defines an Azure landing zone as an architecture for governing, securing and scaling a multi-subscription environment, made of a platform landing zone (shared governance, security and connectivity) and workload landing zones where application teams deploy within the platform's guardrails. Google Cloud calls it a cloud foundation, a modular configuration whose core elements are identity provisioning, resource hierarchy, network and security controls, built on an organisation resource and a billing account.

The common idea is the same: a hierarchy that carries inherited policy, a set of shared platform environments, and a repeatable way to create new workload environments inside it.

How the three providers compare

Component	AWS	Microsoft Azure	Google Cloud
Reference implementation	AWS Control Tower; Landing Zone Accelerator on AWS (LZA) deployed on top for regulated estates	Azure landing zone accelerators (infrastructure as code) or custom build	Enterprise foundations blueprint with the terraform-example-foundation repository
Isolation unit	Account	Subscription	Project
Hierarchy	Organisation root, organisational units (OUs)	Tenant root group, intermediate root, management groups	Organisation node, folders
Preventive guardrails	SCPs, RCPs, declarative policies	Azure Policy assignments at management group scope	Organization Policy constraints
Proactive checks	Control Tower proactive controls (CloudFormation hooks)	Policy checks in the deployment pipeline	Policy-as-code validation in the Cloud Build pipeline
Detective controls	AWS Config rules, Security Hub	Azure Policy compliance, Microsoft Defender for Cloud	Security Command Center
Central logging	Log Archive account	Management subscription with Azure Monitor Logs workspace	`prj-c-logging` with aggregated log sinks
Security tooling	Audit (security tooling) account	Security subscription for SIEM tooling such as Microsoft Sentinel	`prj-c-scc` for Security Command Center alerting
Shared network	Network account in an Infrastructure OU (LZA manages VPCs, Transit Gateway, Network Firewall)	Connectivity subscription (Virtual WAN or hub, Azure Firewall, private DNS zones)	Shared VPC host projects and hub in a networking folder
Environment vending	Account Factory	Subscription vending	Project factory through the infrastructure pipeline

For the policy engines themselves, see the AWS Organizations and SCPs Guide, the Azure Policy and Management Groups Guide and the Google Cloud Organization Policy Guide.

Designing the hierarchy

Group by control set, not organisation chart. AWS guidance recommends foundational OUs (Security, Infrastructure), Workloads, Sandbox, and procedural OUs for Policy Staging, Exceptions, Transitional and Suspended accounts. Azure's reference hierarchy puts Platform (Identity, Management, Connectivity, Security), Landing zones (Corp, Online, Local), Sandboxes and Decommissioned under an intermediate root. Google's blueprint uses bootstrap, common, networking, production, nonproduction and development folders.
Keep it shallow. Microsoft recommends three to four levels of management groups even though six are supported; AWS allows five OU levels. Deep trees make inherited policy hard to reason about.
Do not build on the root. Azure guidance is to create an intermediate root and limit policy assignments at the tenant root; set a default management group so new subscriptions do not land under the root. In AWS, set the OU new accounts are placed in.
Separate by connectivity need. Azure's Corp versus Online split (workloads that need the corporate network hub versus those that face the internet) is a useful pattern on any provider, because it lets network guardrails differ without per-workload exceptions.
Plan the exit route. A Suspended or Decommissioned area with restrictive policy holds accounts awaiting closure; cancelled subscriptions moved to Azure's Decommissioned management group are deleted 30 to 60 days later, and AWS closed accounts count against the quota until permanently closed.

Security components every landing zone needs

Component	Minimum security requirement	Threat addressed
Administrative root (management account, tenant root, organisation node)	No workloads; few named administrators with phishing-resistant MFA; break-glass accounts tested; changes logged centrally	Takeover of the whole estate; hierarchy changes (T1666 Modify Cloud Resource Hierarchy)
Identity	Single workforce identity provider federated to every environment; no local cloud users; root credentials removed or vaulted; workload identities short-lived	Valid cloud accounts (T1078.004); additional cloud credentials (T1098.001)
Central logging	Organisation-wide audit trail to a dedicated logging environment; immutable or write-once retention; read access limited to security	Log tampering and evidence loss (T1685 Disable or Modify Tools)
Security tooling	Threat detection and posture services enabled organisation-wide and administered from a delegated security environment	Undetected compromise
Network	Hub-and-spoke or shared VPC; centralised egress inspection; no public ingress by default; private access to platform services	Exposure and exfiltration
Guardrails	Deny unused Regions, disabling of logging and security tooling, public sharing of storage and images, and long-term keys	Activity in unused Regions (T1535); compute hijacking (T1496.001)
Key and secret management	Central KMS and secrets environments per environment tier, with separation of key administrators from data users	Key misuse; data encrypted for impact (T1486)
Backup and recovery	Backups in a separate account or subscription with its own credentials, immutability and restore testing	Ransomware and destructive actions
Deployment pipeline	Foundation changes only through version-controlled code, policy checks and reviewed merges; pipeline identity tightly scoped	Pipeline compromise; drift

Google's blueprint shows how far defaults can go: it applies Organization Policy constraints at the organisation node including iam.disableServiceAccountKeyCreation, compute.requireOsLogin, compute.vmExternalIpAccess (empty allow list), compute.skipDefaultNetworkCreation, sql.restrictPublicIp, storage.publicAccessPrevention and iam.allowedPolicyMemberDomains, and permits no inbound or outbound public internet traffic by default. AWS equivalents include declarative policies for IMDSv2, VPC Block Public Access and blocking public AMI and snapshot sharing.

Choosing an approach

Provider-managed service (AWS Control Tower): fastest route, with managed drift detection, mandatory controls and an Account Factory. Trade-off: you work within its structure and must not modify the resources and SCPs it owns. Control Tower 4.0 no longer requires a Security OU, giving more freedom over structure.
Accelerator on top (LZA, Azure accelerators): adds networking, security services and compliance-oriented configuration through configuration files or infrastructure as code. LZA supports AWS GovCloud (US) and other non-standard partitions. AWS notes the solution will not by itself make you compliant: you still map controls to your own obligations.
Terraform foundation (Google blueprint, or custom builds on any provider): the most transparent, everything is code you own and review. Trade-off: you own upgrades, testing and the bootstrap identity that holds the Terraform state.
Small organisation: take the provider service or accelerator with defaults, keep a minimal hierarchy (security, shared, production, non-production, sandbox) and spend effort on identity and logging rather than custom structure.
Large or regulated organisation: treat the landing zone as a product with a platform team, release process, Policy Staging area, an exceptions register and documented control mapping to frameworks such as ISO/IEC 27017; see the ISO/IEC 27017 Cloud Security Controls Guide.
Multi-cloud: agree the common requirements (identity provider, log destination, tagging, guardrail intent) once, then implement them per provider using native constructs. See the Multi-Cloud Identity Guide.

Implementing a landing zone

Set requirements. Regions allowed, data residency, regulatory frameworks, network connectivity to on-premises, identity provider, log retention and the minimum environment types.
Secure the top. Create the organisation or tenant hierarchy, protect the administrative root (MFA, break-glass, alerting) and, on AWS, enable centralised root access so member accounts carry no root credentials. See the Break-Glass Account Guide.
Bootstrap the pipeline. Create the deployment environment (Google's prj-b-seed and prj-b-cicd are an example) and the identity it uses, scoped to the foundation and protected as one of the most privileged identities you own.
Deploy shared platform environments: logging, security tooling, network hub, identity services, key management and backup.
Apply guardrails in audit mode first. Use Azure Policy Audit effect, AWS Allowed Images Settings audit_mode or detective controls, and a Policy Staging OU or test management group, before switching to deny.
Pilot with one real workload in non-production, fix friction, then open vending to more teams.
Automate vending. Each new account, subscription or project should be created by code, placed in the right OU, management group or folder, attached to the network and logging, and given role assignments at its own scope (Microsoft advises against giving workload teams RBAC at management group scope).
Roll back safely. Keep every foundation change in version control; roll back a guardrail by reverting the commit or detaching the policy from the affected scope, and keep a tested procedure for moving an environment into a restricted quarantine area during an incident.

Operating the landing zone over time

Version and upgrade deliberately. Control Tower landing zones carry a version (structural changes such as the optional Security OU arrived with version 4.0), and accelerators and Terraform foundations release regularly. Upgrade in a test organisation or tenant first, read the change notes for altered controls, then upgrade production in a change window.
Respect managed resources. Control Tower warns that modifying or deleting the resources its optional controls create can leave controls in an unknown state, and it deploys into accounts through CloudFormation StackSets. Add your own policies and stacks alongside rather than editing the managed ones.
Run an exceptions process. Every request to relax a guardrail should record the owner, business reason, compensating control and expiry, and be implemented by moving the environment to an Exceptions area or by a scoped policy exemption, never by editing the baseline for everyone. Google's blueprint, for example, relaxes a constraint at folder or project level, or uses tags to apply constraints conditionally.
Re-test guardrails after provider changes. New services and APIs appear constantly. Deny-list policies let them in by default, allow-list policies block them; declarative and configuration-based policies are designed to hold their setting as APIs change. Review new services before they are allowed in production areas.
Keep evidence ready. Policy compliance reports, drift reports and the vending log are what auditors and incident responders ask for first.

Where identity fits

A landing zone concentrates privilege. The pipeline identity that deploys the foundation, the Account Factory or subscription vending automation, and the exempted platform roles can change guardrails for the whole estate, so they need the strongest controls: workload identity federation rather than stored keys, narrow scope, and alerting on use outside the pipeline. Human administrators of the platform should get just-in-time elevation (Microsoft points to Privileged Identity Management for platform teams at management group scope). See the Cloud Workload Identity Guide and the Cloud PAM and CIEM Guide.

Detection and measurement

Hierarchy and policy changes: alert on changes to OUs, management groups, folders, policy assignments and organisation policy constraints, and on any environment moved out of a governed area.
Logging integrity: alert when an audit trail, diagnostic setting or log sink is stopped, deleted or redirected, and on reads of the log archive by non-security identities. See the Cloud Logging and Audit Trail Guide.
Drift: use Control Tower drift detection, Azure Policy compliance state and Terraform plan diffs to find manual changes.

Metric	What good looks like
Environments created outside vending	Zero; anything found is moved or closed
Environments sending audit logs to the central log store	100 percent
Guardrails in enforce (deny) mode versus audit only	Rising quarter on quarter
Open exceptions past their expiry date	Zero
Time from request to a ready, compliant workload environment	Hours, not weeks (slow vending drives shadow accounts)
Foundation changes made outside the pipeline	Zero

Common failure patterns

Workloads in the administrative root. On AWS the management account is exempt from SCPs and RCPs and Control Tower's preventive controls, so a workload there runs without guardrails.
Guardrails that do not cover what attackers do with stolen keys. The Amazon AWS Crypto-Mining Campaign 2025 had miners running within 10 minutes using compromised credentials, new IAM users and auto scaling groups. A landing zone that denies long-term IAM users and unused Regions and enables threat detection everywhere narrows that window.
Backups and data in the same blast radius. In the Codefinger S3 Ransomware 2025 campaign, stolen keys encrypted buckets with customer-provided keys and set lifecycle rules to delete data. Backups in a separate account with separate credentials, plus an organisation-wide control blocking SSE-C where it is unused, limit the damage.
The landing zone as a one-off project. Defaults age, provider services change, and without an owner the exceptions register grows until the guardrails mean little. See the Cloud Security Maturity Model.
Slow vending. When a new environment takes weeks, teams use personal or credit-card accounts that sit outside every control.
Brownfield left behind. Existing accounts and subscriptions are never enrolled or migrated, so the secure foundation covers only new work. Use a Transitional area with a dated migration plan.

Framework mapping

Framework	Reference	Landing zone element
NIST CSF 2.0	GV.PO-01, PR.PS-01, PR.AA-05, PR.IR-01, DE.CM-09	Policy enforced by hierarchy, configuration baselines, least privilege, environment isolation, organisation-wide monitoring
NIST SP 800-53 Rev. 5	SA-8, CM-2, CM-3, AC-6, SC-7, AU-6, AU-9	Secure design, baseline and change control, least privilege, boundary protection, log review and protection
CIS Controls v8.1	Control 4 (Secure Configuration), Control 6 (Access Control Management), Control 8 (Audit Log Management)	Guardrails, identity design, central logging
ISO/IEC 27001:2022 Annex A	A.5.23, A.8.9, A.8.15	Security for use of cloud services, configuration management, logging

Practitioner checklist

Document requirements for Regions, residency, frameworks, connectivity, identity and log retention before deploying anything.
Keep the administrative root free of workloads, with few administrators, phishing-resistant MFA and tested break-glass access.
Build a shallow hierarchy with sandbox, policy staging, exceptions and decommissioned areas, and a non-root default for new environments.
Send organisation-wide audit logs to a dedicated, access-restricted logging environment with immutable retention.
Enable threat detection and posture services everywhere from a delegated security environment.
Apply baseline guardrails (Regions, logging protection, public access, long-term keys) in audit mode, then enforce.
Vend every new environment through code, with network, logging and scoped role assignments attached.
Put foundation code, policies and the pipeline identity under the same review and protection as production.
Keep backups in a separate environment with separate credentials and test restores.
Review the exceptions register, drift reports and vending times every quarter.

Cloud Landing Zone Security Guide: Secure Foundations for New Cloud Estates