What a landing zone costs you when you build it wrong.
The structures we inherit most often
Three patterns appear repeatedly when we take over a cloud estate that has been running for two or more years. The first is the single-account monolith: all environments, all teams, all services in one AWS account or Azure subscription, separated by naming convention and the assumption that no one misconfigures a security group. The second is the flat network: a VPC or VNet with no subnet segmentation, direct peering between production and development, and a NAT gateway shared by workloads with very different blast radii. The third is the missing guardrail layer: no Service Control Policies, no Azure Policy, no organisation-level budget alerts. Every team has access to something they should not.
These patterns are not the result of bad engineering. They are the result of landing zones built by teams who were moving fast and had not yet crossed the scale threshold where the structure becomes a liability. That threshold is typically somewhere between 15 and 30 engineers, or between one and three teams operating production services. Below the threshold, structure is overhead. Above it, the absence of structure is the overhead.
What retrofit actually costs
Retrofitting a landing zone onto a running estate is not a technical project. It is a coordination project with technical dependencies. Every change to account structure, network topology, or identity model touches something that a team is already depending on. The migration sequence matters more than the destination architecture.
On the estates we have migrated, the work breaks down roughly like this. Account structure and billing reorganisation: 2 to 3 weeks, mostly coordination with finance and the cloud vendor. Network re-architecture — re-subnetting, replacing NAT gateways with VPC endpoints, wiring PrivateLink: 4 to 6 weeks with 2 to 4 planned maintenance windows and a non-zero probability of an unplanned outage. Security baseline deployment — SCPs, Azure Policy, IAM cleanup, secrets rotation: 3 to 4 weeks, which surfaces 20 to 40 individual findings that need resolution. Identity migration from long-lived keys to short-lived role assumption: 2 to 3 weeks minimum.
Total: 11 to 16 weeks of sustained platform team effort, during which the team delivers few new features. On a team of 3 to 5 platform engineers, that is the full team capacity for a quarter. The same landing zone built correctly from the start takes 3 to 5 weeks.
The five decisions that matter at day zero
One: account hierarchy. Decide how you will separate environments (prod, non-prod), business units, and security boundaries into separate accounts or subscriptions. The AWS Organizations or Azure Management Group hierarchy is harder to change than almost anything else in the estate.
Two: network topology. Decide on hub-and-spoke or mesh before you create the first VPC. Decide which services will use VPC endpoints and PrivateLink rather than public endpoints. Changing this later is measured in maintenance windows and application rework.
Three: identity model. Decide on a single identity provider, federated across all accounts, from the start. No human user has long-lived access keys. The migration from long-lived keys to short-lived role assumption is the most disruption-prone part of any retrofit.
Four: billing and tagging. Decide on the cost allocation model and tag schema before you create the first resource. The tagging policy session takes two hours. The retroactive tagging project takes three months.
Five: security baseline. Deploy SCPs or Azure Policy from the organisation root on day one. The set of things you cannot do by accident is more valuable early than any individual guardrail added later.
"The landing zone built wrong at 20 engineers costs 14 weeks of platform capacity to fix at 80. Built right from the start, it costs four."
Maikel Vlasman / Cloud Architect
What correct looks like for EU mid-market
For a team of 20 to 100 engineers with 2 to 6 product lines, the right landing zone is not the AWS or Azure reference architecture without modification. The reference architectures assume capabilities that most mid-market teams do not have: a dedicated security team, 24/7 SOC, dedicated FinOps function.
What works: three account tiers (management, security, workloads), with workload accounts split by environment and by product line above a certain team size. A single transit VPC for shared services. VPC endpoints for all AWS service traffic that supports them. OIDC federation for CI/CD identity, replacing deploy keys entirely. SCPs that prevent public S3 buckets and disable unused regions. A cost allocation model that separates shared infrastructure from workload spend from the first billing cycle.
For EU companies operating under NIS2 or DORA, two additional controls belong in the landing zone from day one: an immutable audit log architecture with a write-protected destination, and an account structure that makes it possible to generate an ICT dependency map automatically. Both are much cheaper to build into the structure than to retrofit once the estate is running.