A cloud landing zone is the part of a migration plan that gets skipped most often. Most cloud migrations do not fail because a workload could not be lifted and shifted. They fail because nobody designed the ground it landed on. Teams move VMs, databases, and applications into a subscription or account that was never built to hold them, and six months later they are untangling flat networks, inconsistent tagging, and IAM sprawl instead of shipping features. A landing zone is what prevents that mess, and it is the part of a migration plan that gets skipped most often.
What a Cloud Landing Zone Actually Is
A landing zone is the pre-built, governed environment that workloads move into, not the workloads themselves. On AWS that typically means an Organizations structure with multiple accounts, a Transit Gateway or hub and spoke VPC design, centralized logging, and a baseline set of Service Control Policies. On Azure it means a management group hierarchy, subscription vending, hub and spoke VNet peering, and policy assignments enforced through Azure Policy. On GCP it is a resource hierarchy under an organization node, shared VPC, and organization policy constraints. In every case, the point is the same: identity, network, logging, and guardrails exist before the first workload arrives, not after.
Why skipping it costs more than it saves
The appeal of skipping a landing zone is speed. Provision one account or subscription, drop the app in, move on. The cost shows up later as rework. Retrofitting centralized logging into an environment with a year of untagged resources is a project on its own. Renumbering a flat network to support segmentation after fifty workloads are already peered to it means downtime windows nobody budgeted for. IAM built ad hoc, one request at a time, tends to accumulate standing access that nobody remembers granting, which becomes the finding a SOC 2 auditor circles first. The rework is always more expensive than the design work would have been, and it happens under production pressure instead of on a planning timeline.
The five signals worth checking
A few patterns show up consistently when a migration plan has skipped landing zone design. First, if the plan has a single account or subscription for all environments, dev, staging, and production are not actually isolated no matter what naming convention is used. Second, if IAM roles are being created per request rather than from a small set of standard roles mapped to job functions, least-privilege access is not really happening, it is being simulated.
Third, if there is no answer to “where does this get logged and who reviews it,” centralized logging was treated as a follow-up task, which usually means it never gets built. Fourth, if network design has not addressed how workloads in different accounts or subscriptions will talk to each other, teams end up either over-peering everything or building point-to-point VPN connections that become unmanageable past a handful of workloads. Fifth, if Terraform or another IaC tool is not the source of truth for the foundational layer, environment drift is not a risk, it is a certainty.
Building it with Terraform instead of bolting it on
A cloud landing zone built through the console or portal is a landing zone that cannot be reliably reproduced for the next environment or audited for what changed and when. Modular Terraform, with environment-specific variable files and a clear separation between the landing zone modules and the application infrastructure that consumes them, gives you a foundation that can be versioned, reviewed, and rolled out consistently across dev, staging, and production. This also makes multi-cloud operations tractable. A team running EKS, AKS, and GKE workloads side by side does not need identical landing zones across clouds, but it does need equivalent guardrails, consistent tagging conventions, and IaC pipelines that treat each cloud’s foundation with the same rigor.
Sequencing it into a real migration
None of this means migration has to stall while the landing zone gets perfected. The sequence that works in practice is to build a minimal but complete cloud landing zone first, covering identity federation, logging, and network segmentation, migrate a low-risk workload to validate it, then iterate the landing zone based on what that migration surfaces before moving higher-value workloads. Discover the current state, architect the landing zone and target design, implement the foundation and then the workloads, and operate with the same guardrails going forward. Skipping straight to implementation on workloads without that architecture phase is exactly how flat networks and IAM sprawl happen in the first place.
If your migration plan does not have a clear answer for where workloads land before they move, that is worth fixing before the first server does. CloudevTech works with teams across AWS, Azure, and GCP to design and implement cloud landing zones as part of cloud modernization engagements, and we are happy to look at what you have planned so far. Book a consultation at https://cloudevtech.net/contact/ and we will walk through it with you.
#CloudMigration #Terraform #AWS #Azure #GCP #CloudModernization