Ask ten cloud architects what a landing zone is and you will get ten different answers. Some will describe it in terms of AWS account structure or Azure management group hierarchies. Others will talk about networking — hub-and-spoke topology, transit gateways, shared services VPCs. A few will mention governance and guardrails. Almost none will start with the question that actually matters: what decisions does this landing zone need to encode?

A cloud landing zone is not a technical artifact. It is the architectural expression of your organisation's governance model, applied to cloud infrastructure. The account structure reflects how you want to isolate risk and delegate accountability. The network topology reflects how you want to control data flows. The guardrails and policies reflect which decisions you want to centralise and which you want to delegate to teams. The choice of which shared services to include reflects your theory of platform value.

When you build a landing zone by starting with the accounts and networks, you end up encoding implicit governance decisions that will be painful and expensive to undo later. And you will need to undo them — because the implicit decisions are almost always wrong.

What Goes Wrong

The most common landing zone antipattern is what I call the "dev/test/prod" trap. The organisation structures its cloud accounts around environment lifecycle — a development account, a test account, a production account — sometimes with separate accounts per application tier. This mirrors how on-premises environments were structured and feels logical. It is not.

The environment lifecycle is the wrong primary dimension for cloud account structure. Account boundaries in cloud provide blast radius containment, IAM isolation, service quota separation, and billing attribution. Structuring accounts by environment instead of by team or workload means a compromise in the development account can expose credentials that have access to production. It means billing attribution is opaque. It means team autonomy is sacrificed in favour of environment purity.

A second failure mode is building guardrails reactively. Most organisations add Service Control Policies (in AWS) or Azure Policy assignments after workloads are already deployed — in response to an audit finding or a security incident. The result is a policy layer that is full of exceptions for pre-existing non-compliant resources, which undermines the entire purpose of policy as a guardrail.

A Governance-First Approach

The right way to design a landing zone starts with a governance model, not an account structure. Before you create a single AWS account or Azure subscription, answer these questions:

  • What is the unit of accountability for cloud spend and risk — a team, a product, a business unit?
  • Which security controls are mandatory and non-negotiable for all workloads?
  • Which networking decisions do you want to centralise, and which do you want teams to make independently?
  • How will you handle connectivity back to on-premises environments?
  • What is your data residency and sovereignty requirement, and how does that map to cloud regions and account boundaries?
  • How will you provide shared services — DNS, certificate management, logging, monitoring — without creating a centralised bottleneck?

Once you have clear answers to these questions, the account structure and network topology follow naturally. The governance model determines the architecture, not the other way around.

The Management Plane

One component of landing zone architecture that is consistently underinvested is the management plane — the accounts and tooling that control everything else. In AWS, this includes the management account, security tooling account, and log archive account. In Azure, it is the management group structure, the platform subscriptions, and the policy hierarchy.

The management plane is the most sensitive part of your cloud estate. A compromise here is a compromise of everything. Yet it receives a fraction of the architectural attention given to application workloads.

The management plane deserves dedicated security architecture — highly restricted access, hardware MFA requirements for break-glass accounts, no standing privilege for operational tasks, and full audit logging that cannot be tampered with by the accounts being managed. These controls need to be designed in from the start; retrofitting them into an existing estate is significantly more complex.

Shared Services: the Platform Trap

Every landing zone needs shared services — DNS resolution, certificate authorities, security tooling, and network egress controls. The architectural challenge is providing these services without creating a centralised bottleneck that slows down the teams the landing zone is supposed to enable.

The pattern that works at scale is a shared services model where the platform team provides the service but does not control every interaction with it. DNS is a good example. A centralised DNS resolver can forward queries to the authoritative DNS for each workload account — the workload team manages their zone, the platform team manages resolution policy. Neither team is dependent on the other for day-to-day operations.

The platform trap is when the platform team becomes the bottleneck for every shared service interaction. Teams wait weeks for DNS records, firewall rule changes, and certificate requests. This is a governance architecture failure, not a technology problem. The landing zone design should make team autonomy the default and centralised control the exception.

Evolution Over Time

A landing zone is not a one-time build. It is a living architecture that needs to evolve as the organisation's cloud posture matures and as new capabilities become available. The most important thing to build into your landing zone from the start is the capacity to change it — through automation, infrastructure-as-code, and a clear ownership model for the platform itself.

If your landing zone cannot be updated consistently across all accounts within hours, it is already a liability. Guardrail gaps and inconsistent configurations are the attack surface that adversaries exploit. The landing zone that enables your business is the one that can be maintained as rigorously as it was built.

Ergotech works with organisations at every stage of cloud maturity — from designing a landing zone from scratch to assessing and remediating an existing estate. Get in touch to discuss your cloud architecture.