A landing zone is the set of accounts, guardrails, networks and logging that is put in place before the first workload arrives. Done first, it is a few weeks of work. Retrofitted after two years of ad hoc accounts, it is a painful project.
Applies toAWS, Azure, OCI
Built withCode (Terraform)
First versionA few weeks
AvoidsSprawl, surprise bills, audit gaps
Reference architecture
The same structure in every cloud
Scroll sideways to see the whole diagram →Shown for AWS and Azure. OCI follows the same pattern with tenancies, compartments and policies.
Part
What it does
1 One identity
People sign in once through your identity provider and get roles in each cloud. No local cloud users, no shared passwords.
Accounts per environment
Production, non-production and sandbox live in separate accounts or subscriptions. A mistake in a sandbox cannot touch production.
Guardrails
Policies that cannot be switched off by project teams: approved regions only, encryption on, logging on, no public storage buckets.
2 Network hub
All workload networks connect through a hub with a firewall and shared internet egress. Clouds are linked privately only where there is a real need.
3 Central logging
Audit logs and security alerts from every account and every cloud flow to one place that project teams cannot alter.
What a first landing zone includes
Area
What we set up
Accounts
Account or subscription structure, naming, and a request process for new ones
Identity
Single sign-on, role design, break-glass accounts, multi-factor authentication everywhere
Guardrails
Region limits, encryption, logging, tagging rules, blocked public access
Network
Hub-and-spoke design, IP address plan that does not clash with on-premises, private links
Security and logging
Central audit logs, threat detection, alert routing to your team
Cost
Mandatory tags, budgets and alerts per account, monthly cost report by team
Is multi-cloud right for you?
Good reasons: a service only one provider offers well, a regulator or customer that requires a second provider, or an acquisition that arrived on a different cloud.
Weak reasons: a general wish to avoid lock-in. Every extra cloud doubles the skills, tools and guardrails you have to maintain.
Our usual advice: pick one primary public cloud, build the landing zone properly, and add a second only for a specific need.
Typical tools
Cloud
Building blocks
AWS
Organizations, Control Tower, service control policies, IAM Identity Center, Transit Gateway, CloudTrail, Security Hub
Azure
Management groups, Azure landing zone accelerators, Azure Policy, Entra ID, hub VNet with Azure Firewall, Microsoft Defender for Cloud
OCI
Tenancy and compartments, IAM policies, OCI landing zone templates, Cloud Guard
All
Terraform for everything, so the landing zone is reviewed and versioned like code
Send us a VM inventory export (RVTools is fine) and a line on what is driving the change. We will come back with a plain first view: what could move where, in what order, and roughly what it would cost to run.