How to set up a cloud landing zone that stays governable

A landing zone is the difference between a cloud estate that stays governable at 200 workloads and one that’s an ungovernable sprawl by workload 20. It’s laid before anything migrates, and it’s dramatically cheaper to build first than to retrofit under a live estate.

What a landing zone contains

Five things, set up once and consistently, so every workload you migrate lands in a well-run environment:

1. Account structure, isolation between environments and duties.
2. Identity, one human, one SSO identity, least privilege.
3. Network, planned, non-overlapping, segmented.
4. Guardrails, policies that make the insecure thing impossible.
5. Centralized logging, a tamper-resistant record of everything.

The names differ by provider, accounts and OUs on AWS, subscriptions and management groups on Azure, projects and folders on Google Cloud, but the shape is identical. Steps below in build order.

Step 1, Lay out the account structure

Do not run everything in one account. The proven baseline:

Account	Holds	Why separate
Management	The organization itself, billing	Touched rarely, by almost no one
Security / audit	Security tooling, read access everywhere	Investigators don’t depend on the accounts they investigate
Log archive	All audit logs, write-only from other accounts	Attackers (and admins) can’t rewrite history
Shared services	Networking hub, CI/CD, DNS	Used by all, owned by platform
Workload: production	The real thing	Tight change control
Workload: non-production	Dev/test/staging	Freedom to experiment, isolated blast radius

That’s the pattern the accelerators (below) create for you. The payoff is blast-radius isolation, a mistaken script in dev physically cannot delete production, because the credential doesn’t reach, plus per-environment billing you don’t have to reconstruct from tags. Accounts themselves cost nothing.

Step 2, Centralize identity

Kill shared logins and long-lived access keys on day one:

• Connect SSO from your existing identity provider (Google Workspace, Entra ID, Okta) to AWS IAM Identity Center, Azure Entra, or Google Cloud Identity. One place to grant access; one place to revoke it when someone leaves.
• Grant access through roles mapped to groups, not per-user permissions, starting from least privilege, the mechanics are in securing your first cloud account.
• MFA required for every human, hardware keys for anything privileged.
• Keep one documented break-glass credential (sealed, monitored, tested) for the day SSO itself is down.

Step 3, Plan the network before workloads arrive

Network mistakes are the most expensive to fix later, because fixing them means re-IPing live systems:

• Allocate each account’s VPC a CIDR block from one master plan, and make sure nothing overlaps your on-premise ranges, the VPN or Direct Connect back to the data centre depends on it during migration.
• Pick the interconnect pattern once: hub-and-spoke through a transit gateway (AWS), Virtual WAN (Azure), or a Shared VPC (Google Cloud). Ad-hoc peering between accounts turns into an unmanageable mesh by the tenth VPC.
• Within each workload VPC: public subnets only for load balancers and NAT, private subnets for everything else, spread across at least two availability zones.

A napkin CIDR plan, 10.0.0.0/16 prod, 10.1.0.0/16 non-prod, 10.2.0.0/16 shared, on-prem untouched at 192.168.0.0/16, takes an hour and prevents a month of pain.

Step 4, Install guardrails, not memos

Guardrails are org-wide policies, Service Control Policies on AWS, Azure Policy, Organization Policy on Google Cloud, that make the wrong thing impossible rather than discouraged. The baseline set:

Guardrail	What it prevents
Block public object storage, org-wide	The classic leaked-bucket breach
Enforce encryption at rest	Unencrypted databases and volumes
Deny disabling or deleting audit logs	Attackers covering their tracks
Restrict usable regions	Data landing in the wrong jurisdiction; surprise resources in regions nobody watches
Deny root/owner usage for daily work	Takeover of the all-powerful credential

Prefer preventive guardrails (the API call fails) over detective ones (an alert fires after the fact) wherever the platform allows. A policy that blocks public buckets outperforms any amount of training about them.

Step 5, Centralize logging from day one

Ship audit logs (CloudTrail, Azure Activity Log, Cloud Audit Logs), network flow logs, and configuration history from every account into the log-archive account, write-only for senders, read-only for the security account, alterable by no one else. Lifecycle-archive to cheap object storage after 90 days.

This is the record you’ll rely on in a breach, an outage, or an audit, and it’s your half of the shared responsibility model made provable. Logs enabled after the incident are worthless; this is why logging is part of the foundation, not a hardening task for later.

Use the provider’s accelerator, don’t hand-roll

Every provider ships a landing-zone accelerator that builds the pattern above:

Provider	Accelerator	Notes
AWS	Control Tower (+ Organizations)	Provisions the account structure, baseline guardrails, and log archive; new accounts arrive pre-governed
Azure	Azure Landing Zones (Cloud Adoption Framework)	Reference architectures with Bicep/Terraform implementations
Google Cloud	Cloud Foundation Fabric / FAST	Terraform blueprints for org, folders, networking, logging

With an accelerator, a solid baseline is days to two weeks, most of it deciding your CIDR plan and policy exceptions rather than building. Hand-rolling is only justified by a requirement the accelerator can’t express, which is rarer than it feels, and usually costs a month to discover.

One honest caveat: a three-person startup with one product doesn’t need six accounts on day one. A single account plus the first-account security checklist is a legitimate start, just adopt the landing zone before the second team or the first compliance requirement arrives, because that’s when retrofitting starts getting expensive.

FAQ

What is a cloud landing zone?

A pre-configured, secure, multi-account cloud foundation built before workloads arrive. It establishes account structure, centralized identity, a planned network, security guardrails, and centralized logging in one consistent pattern, so everything you migrate lands in a governed environment instead of accreting into a free-for-all.

Do I really need multiple accounts, or can I use one?

A three-person startup with one product can run a single, well-secured account for a while. Beyond that, more than one environment, more than one team, or any compliance obligation, use separate accounts. Accounts are free, and they buy blast-radius isolation (a dev mistake physically cannot touch prod), clean per-environment billing, and simple access boundaries that no amount of careful tagging replicates.

Should I build a landing zone by hand or use an accelerator?

Use the accelerator: AWS Control Tower, Azure Landing Zones (Cloud Adoption Framework), or Google Cloud Foundation Fabric FAST. They encode years of hard-won patterns for account structure, guardrails, and logging, and save weeks of work. Hand-roll only when you have a requirement the accelerator genuinely can’t express, rarer than it feels.

What does a landing zone cost to run?

The structure itself is nearly free, accounts, policies, and SSO cost nothing. The real line items are networking: a transit gateway attachment is ~$36/month per VPC plus data processing, each NAT gateway ~$32/month plus data, and log storage a few dollars once lifecycle rules archive to cheap object storage. A typical SMB landing zone runs tens to a few hundred dollars monthly, noise next to what workloads cost.

---

The landing zone is the least glamorous part of a migration and the one whose absence costs the most, two years later. If you’d like an experienced engineer to review your account structure, CIDR plan, and guardrails before workloads arrive, or to stand the landing zone up with you, talk to a Webisoft cloud engineer.