Cloud Landing Zones: Getting Governance Right From Day One

What a landing zone actually is

A landing zone is the pre-built, opinionated foundation your organization deploys workloads into — the account or subscription structure, identity model, network topology, logging pipeline, and policy guardrails that every future workload inherits automatically. It is not a single account with good intentions. It is a multi-account (AWS), multi-subscription (Azure), or multi-project (Google Cloud) scaffold that encodes your security and operational standards as code, so that the hundredth workload is as well-governed as the first.

The distinction that matters: a landing zone is built once, centrally, before teams start shipping. Everything provisioned afterward lands inside its guardrails by default. Get it right and governance is invisible — engineers move fast because the safe path is the default path. Skip it and you spend the next three years retrofitting controls onto live production, which is slow, risky, and political.

Account and subscription structure

Do not run everything in one account. A single blast radius means one compromised credential or one runaway automation touches everything. Instead, separate by purpose and by trust boundary.

• Management/organization account — billing, org policies, and the trail of audit logs. No workloads run here. Access is tightly restricted.
• Security/audit account — a write-only destination for logs and a read path for your security team. Even an admin in a workload account cannot tamper with logs stored here.
• Shared services — DNS, directory, CI/CD runners, golden images, and network hubs that many teams consume.
• Workload accounts — one set per application or team, split further by environment (dev, staging, production). Production credentials never live beside dev credentials.

Group these with organizational units (AWS OUs), management groups (Azure), or folders (GCP) so that a policy applied at the top cascades down. A realistic mid-market estate lands somewhere between 15 and 60 accounts. That sounds like a lot until the first incident, when clean isolation lets you quarantine one account without touching the rest.

Identity and SSO baseline

Identity is the new perimeter, and it belongs in the landing zone from hour one. The baseline we deploy for clients:

1. Single identity source. Federate every account to one identity provider — typically Entra ID or Okta — through SSO. Kill standalone cloud-native users. No one logs in with a long-lived account-local password.
2. No standing admin access. Human access to production is just-in-time and time-boxed. Engineers request elevation, it is granted for a defined window, and it expires. This is where privileged access management and a broader identity and access management program do the heavy lifting.
3. Roles, not users. Access is granted to roles mapped to identity-provider groups, so onboarding and offboarding happen in one place.
4. MFA everywhere, phishing-resistant where possible. Enforce at the identity provider, not per-application.
5. Break-glass accounts — two, monitored, alarmed on use, credentials sealed. These exist only for the day SSO itself is unavailable.

Getting identity right early avoids the single most common retrofit nightmare: hundreds of orphaned IAM users and access keys nobody can safely delete because no one remembers what depends on them.

Network topology

Design the network centrally so teams cannot each invent their own. A hub-and-spoke topology — an AWS Transit Gateway or Azure Virtual WAN hub with workload spokes — gives you one place to enforce inspection, egress control, and connectivity to on-premises.

• Allocate non-overlapping CIDR ranges from a central plan. Overlapping ranges discovered after the fact are one of the most expensive mistakes to unwind.
• Default to private. Databases and internal services get no public IP. Access is through private endpoints and a controlled ingress path.
• Route egress through a central inspection point so you can log and filter outbound traffic rather than letting every subnet reach the internet directly.
• Standardize how hybrid connectivity terminates. If you run a mix of on-premises and cloud, the landing zone is where that boundary is defined — see our approach to private cloud for how the two planes meet.

Guardrails and policy as code

Guardrails are the mechanism that keeps hundreds of engineers inside the lines without a human reviewing every change. Two kinds:

• Preventive — a policy that refuses the action. Service Control Policies (AWS), Azure Policy with deny effects, or Organization Policy (GCP) can block public S3 buckets, deny resource creation outside approved regions, or require encryption at rest. The request simply fails.
• Detective — a rule that watches and flags drift. AWS Config rules, Azure Policy audit effects, and continuous posture scanning catch the misconfiguration that slipped through and either alert or auto-remediate.

Write these as code (Terraform, CloudFormation, Bicep) and version them like any other software. Policy as code means a guardrail change goes through review, leaves an audit trail, and can be rolled back. It also means your controls are portable and reproducible across a second region or a newly acquired business unit. A common starting set of preventive guardrails:

• Deny disabling of logging and monitoring services.
• Require encryption at rest and in transit.
• Restrict resource creation to approved regions for data-residency reasons.
• Block public exposure of storage and databases by default.
• Enforce tagging so cost and ownership are always attributable.

Ongoing enforcement is where cloud security posture management earns its place — it continuously measures the live estate against these standards and surfaces the drift that inevitably appears.

Logging and security baseline

Centralized, tamper-resistant logging is non-negotiable and must exist before the first workload, because you cannot investigate what you never recorded.

• Turn on the cloud audit trail in every account — CloudTrail, Azure Activity Log, GCP Cloud Audit Logs — and ship it to the security account no workload admin can reach.
• Enable the native threat-detection service — GuardDuty, Microsoft Defender for Cloud, or Security Command Center — organization-wide, not account by account.
• Aggregate to your monitoring pipeline. Feed logs into a SIEM so cloud events correlate with endpoint and network signal rather than sitting in a silo.
• Baseline retention to meet your compliance obligations, and confirm logs are immutable — write-once storage or object lock.

Wire this into monitored managed detection and response so an alert becomes an investigation with an owner, not a line in a dashboard nobody reads.

Why retrofitting governance later is so painful

Teams routinely defer landing-zone work to "move fast now." The cost of that deferral compounds:

• Live blast radius. Adding isolation later means splitting running production across new accounts — network cutover, data migration, and downtime windows.
• Credential sprawl. Every month without SSO adds more long-lived keys you will eventually have to hunt down and rotate without breaking something.
• Retroactive guardrails break things. A deny policy applied to a mature estate will block resources that were quietly non-compliant for a year, forcing emergency exceptions that hollow out the policy.
• Missing evidence. When an auditor or an incident asks what happened six months ago, logging that was not enabled on day one cannot be recovered.

The economics favor building it first. IBM's Cost of a Data Breach research consistently ties higher breach costs to security complexity and misconfiguration — exactly the conditions an ungoverned, sprawling cloud creates. A landing zone is the cheapest insurance against that complexity.

Where to start

If you are early, build the landing zone before the workloads. If you are already running an ungoverned estate, do not boil the ocean: stand up the account structure and centralized logging first, federate identity next, then introduce guardrails in audit mode before flipping them to enforce. Our cloud infrastructure team runs this playbook for organizations at every stage — greenfield foundations and messy retrofits alike. Talk to us about a landing-zone assessment, and we will map your current state against a governed target and give you the sequenced plan to get there.