A landing zone is the foundation on which everything you build in the cloud rests. It is the pre-configured, governed environment that sets up identity, networking, security, and guardrails before the first workload arrives, so that teams can move quickly without each one reinventing the basics or quietly introducing risk. A well-designed landing zone accelerates safe adoption across the organisation; a poorly designed or absent one leaves you with a sprawl of inconsistent accounts that becomes harder to govern with every passing month.
Why the foundation comes first
The cost of getting the foundation wrong compounds. If teams start deploying into the cloud before identity, network segmentation, and guardrails are in place, you accumulate technical and security debt that is painful to unwind later. Retrofitting consistent controls onto dozens of accounts that each grew their own way is far harder than establishing the pattern up front. The landing zone exists precisely to front-load these decisions so that the safe path is the default path from day one.
For leadership, the landing zone is a strategic enabler rather than a piece of plumbing. It determines how fast teams can adopt the cloud, how confidently security can sign off on new workloads, and how much standing risk the organisation carries. Investing in it early is what allows the cloud programme to scale without the governance team becoming a bottleneck or the security team becoming a source of constant friction.
Account structure and isolation
A core element of any landing zone is how environments and workloads are separated. Rather than running everything in one large account, mature designs use multiple accounts or subscriptions organised into a hierarchy, isolating production from non-production and separating workloads with different risk profiles. This isolation limits blast radius: a mistake or compromise in one account cannot easily spread to others. It also makes cost allocation, access control, and policy application cleaner, because boundaries align with ownership.
The structure should reflect the organisation's reality without becoming so granular that it is unmanageable. A clear hierarchy with sensible groupings lets you apply policies at the right level and inherit them downward, so that a control set once and applied broadly protects every account beneath it. Getting this structure right early avoids painful reorganisations later.
Identity and access at the foundation
Identity is the new perimeter, and the landing zone is where that perimeter is established. Centralised identity, federated from the organisation's identity provider, ensures that people authenticate consistently and that access can be granted and revoked centrally. Role-based access aligned to job function, combined with the principle of least privilege, keeps standing permissions minimal. Where possible, elevated access should be granted just in time rather than held permanently, reducing the standing risk that comes with broad administrative rights.
Designing identity well at the landing zone level pays dividends throughout the cloud estate. Every account inherits the same authentication model and the same access patterns, so security can reason about who can do what across the whole environment rather than account by account. This consistency is one of the strongest arguments for establishing the landing zone before workloads proliferate.
Network design and connectivity
Networking in the landing zone establishes how accounts connect to each other, to on-premises systems, and to the internet. A well-designed network provides segmentation so that workloads are isolated by default and connectivity is granted deliberately, controlled egress so that outbound traffic is inspected rather than unrestricted, and a clear model for hybrid connectivity where it is needed. Centralising shared network services, such as inspection and routing, avoids duplicating them in every account and keeps the security posture consistent.
The aim is a network that is secure by default and easy to extend safely. Teams should be able to deploy into a segment that already has the right boundaries, rather than designing their own networking and inevitably leaving gaps. The landing zone makes the secure network pattern the standard, which removes a whole class of misconfiguration risk.
Guardrails, policy, and cost control
Guardrails are the policies that constrain what teams can do, applied automatically so that the safe path is enforced rather than merely recommended. Preventive guardrails block disallowed actions, such as deploying into unapproved regions or creating publicly accessible storage. Detective guardrails flag configurations that drift from policy so they can be corrected. Together they let teams move freely within a safe envelope, giving them autonomy without giving up control. Cost guardrails, including budgets, tagging standards, and alerts, prevent runaway spend and keep accountability for cost aligned with ownership.
The balance to strike is between freedom and control. Too few guardrails and the environment becomes risky and inconsistent; too many and teams feel trapped and route around the controls. The best landing zones make the guardrails feel like sensible defaults rather than obstacles, enforcing the things that genuinely matter while leaving teams room to work.
Treating the landing zone as a product
A landing zone is not built once and forgotten. The cloud platforms evolve, security requirements change, and the organisation's needs grow, so the landing zone needs an owner, a roadmap, and a way to evolve safely. Defining it as code allows changes to be reviewed, tested, and rolled out consistently across the estate. Onboarding new teams should be self-service, with a clear path to request a new account that arrives pre-configured with the standard controls, so that the platform team enables rather than gatekeeps.
Run this way, the landing zone becomes a living product that improves over time and scales with the organisation. It turns cloud adoption from a series of bespoke, risky projects into a repeatable, governed process where every new workload starts from a secure, consistent foundation.
- Establish the landing zone before workloads arrive so the secure path is the default from the start.
- Design an account hierarchy that isolates production from non-production and separates workloads by risk.
- Centralise identity with federation, least privilege, and just-in-time elevation for sensitive access.
- Build a segmented network that is secure by default with controlled egress and shared inspection.
- Apply preventive and detective guardrails, including cost controls and tagging standards.
- Define the landing zone as code with an owner, a roadmap, and self-service onboarding.
Common pitfalls
The most common pitfall is deferring the landing zone and letting teams adopt the cloud ad hoc, which produces inconsistent accounts that are painful to govern later. Another is over-engineering the design so heavily that it becomes a bottleneck, with every new account requiring lengthy central involvement. Some organisations apply guardrails so restrictively that teams circumvent them, defeating the purpose. Others build the landing zone once and never maintain it, so it drifts out of step with current security practice and the evolving cloud platform. A maintained, code-defined, product-managed landing zone avoids all of these.
A well-designed landing zone gives every team a secure, consistent foundation, turning cloud adoption into a process that scales safely rather than a source of accumulating risk. Need support applying this approach? Email sales@halfteck.com.