A large enterprise is starting a cloud programme across dozens of business units with different regulatory obligations. What must the landing zone establish before the first workload, and what is the cost of getting it wrong?

What must be established first

These are the decisions that are effectively irreversible once workloads exist, because changing them later means migrating everything:

1. Account and subscription topology. The boundary of blast radius, billing, and policy. Usually one per workload per environment rather than one giant shared account, because accounts are the strongest isolation primitive the provider offers — and consolidating later is far harder than splitting early.

2. Identity and access model. Federation to the corporate directory, role definitions, the break-glass path, and the rule that human standing access to production is the exception rather than the default. Retrofitting identity means re-permissioning every resource.

3. Network topology and address space. IP allocation across regions and business units, connectivity back to on-premises, egress control points, and how workloads reach each other. Overlapping address space discovered after two business units have deployed is a genuinely expensive mistake, and it is common.

4. Data residency and sovereignty boundaries. Which regions may hold which classes of data, enforced by policy rather than by documentation. For an enterprise spanning jurisdictions this is the constraint most likely to invalidate a design after the fact.

5. Guardrails as preventive policy. Deny-by-default on public storage exposure, unencrypted volumes, regions outside the approved list, and resource types that are not sanctioned. Preventive controls scale; detective controls generate tickets nobody closes.

6. Tagging and cost allocation from the first resource. Retroactive tagging never fully happens, and without it, cost accountability is impossible — which means cost control is impossible.

7. Logging and audit pipeline. Centralised, in an account the workload teams cannot write to, with retention set by the longest applicable regulatory requirement.

The cost of getting it wrong

Each of these is a migration rather than a change once workloads exist:

• Wrong account topology → re-homing workloads, changing every identifier, redoing networking.
• Overlapping address space → renumbering live systems or deploying translation permanently.
• Missing tagging → cost attribution that is never fully recovered, and a FinOps programme that cannot start.
• Absent preventive guardrails → a backlog of findings that grows faster than remediation, and a compliance position that is defended by exception rather than by design.

The failure mode specific to large enterprises

The landing zone becomes a bottleneck. Central teams build a control framework so restrictive that business units cannot ship, so they obtain their own accounts outside it — and the organisation ends up with a beautifully governed empty landing zone and a shadow estate with no controls at all.

The counter is the paved road: make the compliant path faster than the alternative. A team that can provision a compliant environment in an hour through self-service will not go around the framework. A team facing a six-week intake process will.

The judgement being tested

Whether you recognise which decisions are irreversible and must be made early, versus which are reversible and should be deferred rather than debated for six months. The landing zone should settle identity, network, accounts, residency and guardrails — and deliberately leave application-level choices to the teams, because centralising those is what turns governance into an obstruction.