A landing zone is the set of decisions — accounts, identity, network, controls, cost attribution — that get made once, before any workload moves. It exists because every one of those decisions is cheap to make early and expensive to change once things are running on top of it.
Below: what it actually contains, why the order matters, what it looks like when it is skipped, how much is enough for a first migration, and what changes in Colombia and Mexico.
The word sounds like infrastructure and it is mostly governance. A landing zone is not a diagram of virtual networks: it is the answer to who can create what, where it goes, who pays for it, and how you find out when something drifts.
It gets built first because retrofitting it means touching everything already running.
The name comes from the idea that workloads should land somewhere prepared rather than on empty ground. Every provider publishes its own version — the vocabulary differs, the decisions do not — and the useful way to read any of them is as a list of questions that will be answered either deliberately now or accidentally later.
What it contains
Account and subscription structure: how environments and business units are separated. This is the decision that is hardest to reverse, because it determines the boundary of every permission and every bill.
Identity: who authenticates, against what directory, with what privilege model. If this is not resolved before the first workload, the first workload defines it by accident.
Network: address ranges, connectivity back to what stays on premises, egress control. Overlapping address ranges discovered after two migrations is a genuinely expensive problem.
Controls and logging: what is enforced automatically rather than reviewed. A policy that only exists in a document is not a control.
Cost attribution: the tagging scheme that lets a bill be read by owner. It costs nothing at the start and cannot be reconstructed retroactively.
Why the order matters
These five are not a checklist to work through in parallel. Identity constrains the account structure, the account structure constrains where controls attach, and the controls determine what the network is allowed to do.
Doing them out of order produces work that gets thrown away — a network built before the account boundaries are settled usually gets rebuilt.
It also produces false confidence. A team that has stood up connectivity feels well advanced, and has in fact done the part that is easiest to redo while leaving the part that is hardest still open.
A useful sequencing test: for each decision, ask what would have to be rebuilt if it changed six months from now. The ones with the longest answer go first, regardless of which is most urgent or most interesting to the team.
The two mistakes that produce a rebuild
The first is treating environment separation as a naming convention rather than a boundary. Development and production distinguished only by a label share every permission and every failure mode, and separating them afterwards means recreating resources rather than renaming them.
The second is choosing address ranges from whatever was free on the day. Two ranges that overlap are invisible until the moment two environments have to talk to each other, and by then both are carrying production traffic. Reserving a deliberate range for the whole cloud estate, larger than the current need, costs nothing and prevents the one problem in this list with no cheap remedy.
Both mistakes share a shape: they are made in an afternoon by someone solving an immediate problem, and they are paid for by a team that was not in the room.
What it looks like when it is skipped
The symptoms are recognisable. Nobody can say what a given environment costs, because resources were created without a tagging convention. Permissions were granted case by case and now nobody is willing to remove any of them. Two teams built the same shared service twice because there was no place to put a shared one.
And the finding that usually forces the issue: an audit asks who has administrative access to production and the answer takes three days to assemble.
None of these are cloud problems. They are the absence of decisions that a landing zone makes once, and every one of them gets more expensive with each workload added on top.
How much is enough for a first migration
The failure mode on the other side is a landing zone project that runs for six months and migrates nothing. The reference architectures published by the major providers describe a mature end state, not a starting point, and adopting all of it before the first workload is a way of never starting.
What genuinely has to be settled before workload one: the account boundaries, the identity model, the address ranges, and the tagging scheme. Those four are the ones that are painful to change later.
Everything else — the full policy set, the automated remediation, the platform team's self service — can arrive incrementally, and arrives better informed for having a real workload to observe.
What changes in Colombia and Mexico
Two things. Regional availability determines what can actually be deployed where, and it is worth verifying rather than assuming: not every service is present in every region, and latency to a distant region is a design constraint, not a footnote.
And data residency is read against the framework that applies — Habeas Data in Colombia, the federal data protection law in Mexico — plus whatever the sector regulator adds on top. In financial services and health that is usually the binding constraint on the account and network design, so it belongs in the landing zone rather than in a later compliance review.
The practical consequence is that residency and regional coverage should be confirmed before the account structure is drawn, because both can force a boundary that was not otherwise obvious.
Who builds it and who keeps it
It is usually built by a small team and then owned by nobody, which is the point at which it starts to decay. A landing zone is not a deliverable that is handed over; it is a product with a backlog.
The lightest arrangement that works is a named owner, a documented way to request an exception, and a periodic review of what has drifted. Without the exception path, teams route around the controls rather than argue with them, and the drift is invisible.
The review matters more than the initial build quality. A modest landing zone that is inspected quarterly ends up in better shape than an excellent one that nobody has looked at in a year.
Where to start
With an honest read of what is already in the cloud, because it is rarely nothing — most organisations have several accounts created ad hoc by individual teams, each of which will have to be brought under the new structure or deliberately left out.
A cloud readiness assessment establishes that baseline and sizes what has to be decided before the first migration, rather than after it. From there the cloud plan can be sequenced with the expensive decisions taken first.
Frequently asked questions
What is a cloud landing zone?
The set of decisions made once before any workload moves: account structure, identity, network, automated controls and cost attribution. It is mostly governance rather than infrastructure.
What has to be settled before the first workload?
Account boundaries, the identity model, address ranges and the tagging scheme. Those four are painful to change later; the rest can arrive incrementally.
How long should building one take?
Long enough to settle those four decisions, not long enough to migrate nothing. A six-month landing zone project with no workload moved is a recognised failure mode.
What happens if it is skipped?
Nobody can say what an environment costs, permissions accumulate case by case, shared services get built twice, and an access audit takes days to answer.
What changes in Colombia and Mexico?
Regional service availability, which is worth verifying rather than assuming, and data residency read against Habeas Data or the federal data protection law plus the sector regulator.
Who owns it after it is built?
It needs a named owner, a documented exception path and a periodic drift review. Without the exception path teams route around the controls and the drift becomes invisible.
