What is a cloud landing zone, and what core capabilities does a well-designed one typically provide before any application workload is deployed onto it?

## What a landing zone is A cloud landing zone is a **pre-built, standardized foundation** that any new workload is deployed into, so that networking, identity, logging, and security controls are already correct before an application team writes a line of code. Concretely, it comprises: - a **standardized account or subscription hierarchy** — an organization root with dedicated accounts for functions like log archive and security/audit, a shared network/services account, and workload accounts split by environment or business unit; - a **baseline network topology**, typically hub-and-spoke or transit-gateway based, where a central hub provides shared egress, firewalling, and DNS while isolated spoke networks host individual workloads; - a **centralized identity model** built on a federated identity provider issuing role-scoped permission sets into every account, eliminating per-account local credentials; - **centralized, immutable logging** that funnels account activity and application logs into a dedicated log-archive account for audit; - **preventive and detective guardrails**, tiered by risk rather than applied uniformly to every workload. | Guardrail | Shape it takes | |---|---| | **Preventive** | policies blocking public storage buckets or restricting deployments to approved regions | | **Detective** | automated checks flagging unencrypted resources | ## How teams actually use one The mechanism by which teams actually use a landing zone is usually a self-service, automated pipeline: a team requests a new workload account through a service catalog, and infrastructure-as-code automation provisions an account that is - already wired into the org's SSO, - already tagged for cost allocation, - already peered to the shared network hub, - already subject to the baseline guardrails, all without a human manually configuring any of it. ## Why it exists This exists because, at scale, dozens or hundreds of teams provisioning cloud resources independently produces inconsistent security posture, duplicated effort reinventing the same networking and IAM decisions, and account sprawl that is hard to audit. A landing zone centralizes the foundational, largely undifferentiated decisions once, so the security and compliance function has a single place to enforce controls instead of chasing every account individually, and application teams can focus their effort on the parts of the system that actually differentiate their product. ## The trade-off The trade-off is centralization's classic cost: consistency and faster compliant onboarding in exchange for an upfront investment measured in weeks to months, and a central platform team that can become a bottleneck for changes to shared guardrails or exception requests. Guardrails that are too strict slow legitimate work across every team subject to them; guardrails that are too permissive defeat the purpose of having a landing zone at all. A landing zone also locks in architectural choices — such as a specific network topology — that become expensive to change once hundreds of workload accounts depend on them, so the initial design decisions carry outsized long-term weight. ## Failure modes Failure modes show up in a few recurring shapes. - **Guardrail drift** happens when exceptions are granted ad hoc without being tracked, eroding the property that the landing zone is a single source of truth for security posture. - **A central bottleneck** emerges when the platform team can't keep pace with the volume of provisioning or exception requests, so teams start routing around the landing zone entirely with shadow accounts, which defeats its purpose more thoroughly than any individual bad guardrail would. - **Under-scoping** shows up when a landing zone is designed for a single region or business unit and later breaks when the company expands to multiple regions or acquires a company with different compliance obligations, forcing a costly re-architecture. - **Blast radius.** Finally, because the hub network and central identity provider are shared dependencies for every workload account, an outage or misconfiguration in either has a blast radius spanning the entire cloud estate simultaneously, unlike a bug confined to one team's application. ## A worked scenario A concrete worked scenario: a company adopts a landing zone with an automated workload-account vending machine — a team files a request, automation deploys a new account already wired into SSO, tagged for cost allocation, guarded by policies blocking public buckets, and peered to the shared egress hub, cutting a previous six-week manual setup process to under a day, while security gets a single dashboard showing every account's baseline compliance without auditing each one by hand. Six months later, an urgent workload needs an exception to a mandatory guardrail for a legacy on-premises integration requiring a non-standard port; because the exception process is undocumented, an engineer edits the shared policy directly rather than filing a tracked request, silently weakening the guardrail for every account under that policy until a later audit catches the drift.