Cloud Architecture
Designing a landing zone before the first workload
Why project hierarchy, identity and network boundaries are cheaper to decide before migration waves begin than after.
CloudSight Analytics7 min read
A landing zone is the set of decisions every future workload inherits: how projects are organized, how identity is granted, where network boundaries sit, and what is logged. Those decisions are inexpensive to make deliberately and expensive to revisit once dozens of workloads depend on them.
What the landing zone has to settle
- Project and folder hierarchy, and what each boundary is actually for
- Identity model: who grants access, on what basis, and how it is reviewed
- Network topology, egress controls and hybrid connectivity
- Logging, audit retention and where those logs are analysed
- Policy guardrails that apply regardless of which team deploys
The common failure is treating the landing zone as infrastructure to be produced quickly so that migration can start. The landing zone is the migration's contract with the future. Written in Terraform, reviewed like application code, it becomes the artefact that keeps wave three as predictable as wave one.
Sequencing that tends to work
Establish the hierarchy and identity model first, because they constrain everything else. Add network topology once you know which workloads need hybrid connectivity. Add guardrails before the first team self-serves, not after the first incident. Then migrate — and treat any change to the landing zone as a reviewed change, not an ad-hoc console edit.