Landing Zone

Expanded Definition

A landing zone is the prebuilt cloud foundation that teams deploy before any workload moves in. It establishes the operating model for the environment, usually by defining account or subscription structure, network boundaries, logging, security guardrails, and governance defaults. The point is not simply to “set up cloud,” but to create a repeatable baseline that workloads can inherit without every team designing its own controls from scratch.

The term is used most often in cloud strategy, platform engineering, and migration planning. A common misunderstanding is treating a landing zone as a one-time checklist rather than a living foundation. In practice, it has to evolve with identity patterns, network segmentation, telemetry needs, and policy changes as workloads and teams scale. Good landing zones also make boundaries explicit, so shared services, application environments, and production accounts do not blur together.

For cloud governance context, the NIST Cybersecurity Framework 2.0 is a useful authority because landing zones operationalise governance, protection, detection, response, and recovery in a repeatable cloud base.

Examples and Use Cases

Landing zones show up wherever organisations want to move faster without rebuilding security and governance for every new workload. Typical uses include:

• Separating development, test, and production into distinct cloud accounts or subscriptions with inherited guardrails.
• Creating standard network connectivity, such as shared egress, inspection points, and segmentation between application tiers.
• Defining central logging and monitoring so every workload lands in an environment with audit visibility already enabled.
• Preconfiguring identity and access patterns, such as role structure, federated access, and least-privilege defaults for platform and application teams.
• Providing a migration destination where legacy workloads can be moved into a controlled cloud baseline instead of a manually assembled target.

In larger programmes, a landing zone often becomes the shared platform product that application teams consume. That speeds delivery, but it also creates a tradeoff: the more standardised the baseline, the more carefully it must be designed to avoid becoming rigid or overly generic for specialised workloads.

For implementation detail around workload identity inside cloud foundations, SPIFFE workload identity specification is relevant when a landing zone includes service-to-service trust.

Security Implications

Landing zones matter because many cloud failures are really foundation failures. If logging is incomplete, segmentation is weak, or access patterns are inconsistent, every workload deployed into that environment inherits the same weakness. A poor landing zone can also create governance drift, where each team compensates with its own exceptions, making the cloud estate harder to audit and harder to secure.

Failure mechanism: the baseline is too permissive, inconsistently enforced, or incomplete, so workloads arrive with missing guardrails, weak visibility, and ad hoc trust relationships. That turns early design shortcuts into long-lived exposure.

Impact: organisations lose confidence in who can access what, where telemetry is available, and which controls are actually enforced. In migration programmes, that can delay go-live, increase rework, and leave production workloads running in a fragile state that is expensive to unwind later.

That is why landing zones are usually judged less by how quickly they are created and more by how consistently they are applied across environments. The visible symptom of a weak foundation is often not a single incident, but a pattern of exceptions, duplicated control logic, and unclear ownership.

Security, Operational and Governance Implications

A landing zone is both a security control plane and an operating model decision. It shapes how accounts are separated, how access is granted, how logs are retained, and how policy is enforced across new workloads. If those decisions are made late, the environment tends to grow around exceptions rather than standards, which makes governance slower and incident response less reliable.

Operationally, the best landing zones reduce friction by making secure defaults the easiest path for delivery teams. Governance-wise, they give security and platform teams a common reference point for ownership, approvals, and control inheritance. That is especially important in multi-team cloud estates, where inconsistent baselines create hidden variance that is difficult to spot until audit, outage, or compromise.

For cloud control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls aligns well with the account, logging, access, and configuration controls commonly embedded in a landing zone, while CIS Benchmarks help translate baseline hardening into concrete cloud and system configurations.

For practitioners, the key question is not whether a landing zone exists, but whether it actually represents the target operating model the organisation wants to scale.

Related resources from NHI Mgmt Group

• Who should own DNS changes when PKI and DNS teams both depend on the same zone?
• Who is accountable when a trusted SAP endpoint can be abused from the wrong network zone?
• How should teams govern shared zone proxies in a multi-zone mesh?
• Why do zone proxies create more governance risk than workload sidecars?