What is a cloud landing zone?

What it is

A cloud landing zone is the baseline environment you put in place before teams deploy workloads. It defines how accounts or projects are created, who can access them, how networks connect, where logs go, and which guardrails apply. Think of it as the shell and services for a new office: walls, power, a security desk and a mailroom exist before any tenant moves in. It is mostly code and process.

It spans several layers. The account or project hierarchy sits at the top, with an organization, folders or organizational units, and separate accounts for production, nonproduction, security and shared services. Identity comes next, usually single sign-on tied to your directory, with permission sets per group. Then network: a planned IP range, a shared connectivity hub, DNS, egress controls and private access to services. Logging, security tooling and cost controls run across all of it. Vendor blueprints such as AWS Control Tower, the Azure landing zone accelerator and Google Cloud folders save time, but they are only a start. Your naming rules, audit needs and finance tags still need to be encoded.

How it works

Start with the account and folder design. Decide which accounts are shared, which are per workload, and where production lives. Keep the tree shallow. A common pattern is a few organizational units: security, infrastructure, production and nonproduction. Guardrails inherit down from each unit.

Identity comes next. Connect your directory to the cloud identity service, create groups for job roles, and assign permission sets to groups. Avoid long-lived keys. Set up a break-glass account with strong controls and test it. For network, write an IP plan that leaves room to grow and does not overlap with on-premises ranges. Build a hub VPC or VNet for shared connectivity, then attach workload networks to it. Put DNS resolution and egress rules in the hub so teams do not repeat them.

Guardrails keep the environment inside policy. On AWS, service control policies block risky actions, and AWS Config rules detect drift. On Azure, Azure Policy and role assignments do the same work. On Google Cloud, organization policies and IAM conditions apply. Pick a small set for the first release: block public storage buckets, require encryption, prevent region sprawl. Add more after teams use it.

Deploy with infrastructure as code, such as Terraform or Bicep. Store it in Git, run it through a pipeline, and version every change. Build an account vending process so a new account or project comes from a template with the right baseline. Tag every resource with owner, environment, cost center and data class. Feed tags into budgets and cost reports. Without that, finance sees a bill with no clear owner.

Why it matters for a business

A landing zone turns security and finance rules into defaults. A new workload inherits logging, access controls and network policy without a review that starts from zero. That shortens the path from approval to a working environment. Auditors get a consistent story: here is how access is granted, here is where logs are kept, here is how exceptions are approved.

For operations, the value is repeatability. When every account is built the same way, runbooks work across environments and on-call staff spend less time guessing. Cost control improves because spend maps to accounts, projects and tags. It also sets the boundary between central IT and product teams: the central team owns identity, network hubs and guardrails, while product teams own their workloads inside those rails. That split works only when the landing zone is documented and the exception process is real.

Common mistakes

Treating the landing zone as a network project. A hub-and-spoke design is one part. Identity, logging, guardrails and cost tags matter just as much. If those are missing, teams create their own accounts and bypass the model.

Building too much before the first workload. Large blueprints with dozens of policies and custom modules take months and often miss real needs. Start with controls you can test, then add layers as workloads arrive. Another mistake is a deep folder tree with a special case for every team. Keep it simple and use tags for business details.

Skipping the IP plan. Overlapping ranges with on-premises or partner networks cause painful rework later. Reserve space, document it and treat it as a controlled asset. Do not leave the landing zone unowned. Name a team and a person who review changes, handle exceptions and keep the code current. Ignoring application teams is another trap. If the landing zone makes common tasks slower, teams will work around it. Test with a pilot workload and fix the template, not the exception list.

How to get started

Write a one page scope. List the clouds, the first three workloads, the compliance needs, the countries you operate in and the teams who will use it. Decide whether you need a full multi-account model now or a smaller start. Put the account hierarchy, identity groups and IP plan on one diagram before you write code.

Choose your deployment tool and first guardrails. Build a development landing zone and run a pilot workload end to end: account creation, access, network, logs, deployment and cost reporting. Time each step. Fix what hurts. Then promote the same code to production. Document the operating model too: who approves a new account, how exceptions are requested, how often the code is reviewed, and how logs are retained. Set a review every quarter, because clouds add services and controls.

You can build it in house, use vendor blueprints directly, or bring in help for the design phase. One option is the Cloudverg Discovery and roadmap sprint, a fixed price of $9,500 over two weeks, which ends with a target architecture, a phased roadmap and a fixed price for phase one. Compare that with a contractor or your own staff. The right choice depends on your design capacity and how soon the first workload must ship.

Frequently asked questions