A landing zone is the pre-configured, multi-account (or multi-subscription, or multi-compartment) environment your workloads land in — and skipping this step is the single most common reason enterprise migrations end up needing an expensive re-architecture 18 months later.
What a landing zone actually includes
At minimum: an account/subscription hierarchy, baseline identity and access management, network topology (hub-and-spoke or similar), centralized logging and monitoring, and guardrails enforced through policy-as-code rather than manual review.
None of this is workload-specific — it’s the shared foundation every subsequent application deployment builds on top of.
Why teams skip it
Under deadline pressure, it’s tempting to spin up a single account, migrate the first few applications, and “formalize governance later.” The problem is that retrofitting a multi-account structure after workloads are live means untangling IAM policies, re-architecting network paths, and coordinating downtime across every team that’s already deployed.
A minimum viable landing zone
You don’t need every enterprise landing zone feature on day one. A minimum viable version — account structure, centralized logging, a documented tagging standard, and SSO federation — takes most teams 3-6 weeks and prevents the majority of governance debt that accumulates during rushed migrations.
Leave a Reply