Landing zones: the decisions worth slowing down for

Almost every painful cloud estate we are asked to take over was painful for the same reason: the account structure, network layout and identity model were decided in the first fortnight by whoever needed to ship something, and never revisited. Compute is easy to change later. These three are not.

What actually gets expensive to change?

A rule of thumb: if undoing a decision means touching every workload at once, it belongs in the landing zone and deserves a week of argument now rather than a migration later.

• Account and subscription boundaries — these define your blast radius.
• IP address planning — overlapping CIDRs are how peering plans die.
• Identity and role design — retrofitting least privilege is brutal.
• Tagging and cost allocation — untagged spend is unattributable spend.

The counter-argument is real: you cannot design a landing zone properly before you know what you are running. That is why we time-box the design to two weeks, build it as code, and accept that some of it will be rebuilt — cheaply, because it is code.

Build it as code, or you will not rebuild it at all.

A landing zone assembled by hand in a console is a landing zone nobody dares touch. Ours go into Terraform from the first commit, with the whole environment reproducible in under an hour. That is the difference between a foundation and a monument.

If you are inheriting an estate rather than starting one, the same logic applies in reverse: find out which of these four decisions is already wrong, price the cost of fixing it now against the cost of living with it, and be honest that the second number grows every quarter. That assessment is the first thing we do on any takeover, and it is usually the most valuable.