Multi-Cloud Landing Zones & Governance

A landing zone is a pre-configured, multi-account cloud environment that enforces security, identity, network, and compliance baselines before any application workload lands. It is infrastructure-as-policy: the goal is to make the compliant path the easy path.

Core Outcomes a Landing Zone Must Deliver

• Account isolation between workloads and environments
• Consistent identity and least-privilege access controls enforced by default
• Network segmentation with controlled egress and ingress
• Enforced security guardrails — preventative, detective, and (as of 2026) declarative/configuration-level
• Audit trails and observability from day one, not retrofitted
• Self-service account onboarding for teams without bypassing controls
• A defined data-residency and sovereignty posture, decided at design time rather than discovered during an audit

Organize cloud accounts into a hierarchy that reflects risk, compliance, and team boundaries — not feature boundaries.

Recommended Hierarchy

Structural Rules

• One account/subscription per environment per workload boundary — no mixing
• Security and log archive accounts owned by the platform team; never delegated
• Sandbox accounts must have hard billing caps and auto-expiry policies
• Never mix production and non-production workloads in the same account
• All new accounts created through the vending machine pipeline, never the console
• On Azure, decide up front whether any workloads need a path to Local/disconnected operation — retrofitting the Local management group later means re-homing subscriptions

Core Principles

• Centralize the identity provider — never create cloud-local users for humans
• Use short-lived credentials; eliminate long-lived access keys entirely
• Apply least privilege at every layer: org, account, resource, and action
• Separate duty between the platform team (account management) and application teams (workload IAM)
• MFA required for all human console access without exception

Role Tier Structure

Hub-and-Spoke Topology

All spoke VPCs/VNets connect to a hub that owns shared services. Spokes never peer directly with each other.

Egress Control Standards

IP Addressing Standards

• Allocate non-overlapping RFC 1918 ranges per environment tier at landing zone creation
• Reserve a /16 per tier to allow future spoke growth without re-addressing
• Maintain a central IPAM record (AWS VPC IPAM, Azure VNet Manager, or equivalent)
• Never reuse CIDR ranges previously routed to on-premises
• Enable VPC/VNet flow logs on all subnets at creation time, not retroactively

Security baselines are guardrails the landing zone enforces on every account automatically. Preventative guardrails block non-compliant actions; detective guardrails alert on non-compliant state; declarative guardrails continuously hold a service configuration in the desired state, even as the provider ships new APIs.

Preventative Guardrails

Detective Guardrails

Mandatory Logging

All accounts must ship the following to the centralized log archive account from day one:

• Management plane / audit events (CloudTrail, Activity Log, Cloud Audit Logs)
• VPC / VNet flow logs
• DNS query logs
• Authentication events: login, role assumption, privilege escalation
• Config change events
• AI agent tool-call and connector invocation logs, tagged with session ID (see §11)

Every major provider now ships more than one policy type, and picking the wrong one for a control objective either under-protects the environment or creates unnecessary operational friction. This section consolidates the current (2026) policy surface for each provider.

AWS — Three Policy Types, Three Jobs

Azure — Policy + the New Local Management Group

• Azure Policy (Deny / Audit / Modify / DeployIfNotExists effects) remains the primary preventative and remediation engine, assigned at management group scope and inherited downward.
• The ALZ platform library moved to Azure Verified Modules (AVM) as the recommended deployment mechanism over the older portal-based Accelerator UI — deploy via Terraform or Bicep AVM patterns, not manual console changes.
• The new Local management group (library release 2026.04.2) sits beneath Landing Zones alongside Corp and Online. It gives Azure Local clusters and disconnected-capable workloads a consistent governance home, and is inherited by the Sovereign Landing Zone automatically.
• Conditional Access policies in Microsoft Entra ID continue to carry identity-layer guardrails (MFA enforcement, device compliance, session controls) that Azure Policy does not cover.

GCP — Org Policy Constraints Plus IAM Deny Policies

• Org Policy Constraints remain the primary preventative control, applied at organization or folder level and inherited by projects.
• IAM Deny Policies are now a standard part of the organization schema in Cloud Foundation Fabric — they set explicit deny rules that no Allow policy can override, closing gaps that Org Policy constraints alone don't reach (for example, denying specific principals org-wide regardless of any grants made later).
• VPC Service Controls continue to define a service perimeter around sensitive data services (BigQuery, Cloud Storage, etc.), preventing exfiltration even by principals with valid IAM grants.

Through 2025 and into 2026, sovereign cloud requirements moved from a niche public-sector concern to a mainstream landing zone design input across regulated industries and EU-based organizations. Decide the sovereignty posture during the landing zone design phase — retrofitting it means re-platforming workloads.

Sovereignty Design Checklist

• Classify workloads by residency requirement (none / data-at-rest / data-in-use / full operational sovereignty) before choosing account, subscription, or project placement
• Confirm which control/support staff can access the environment — some sovereign tiers restrict this to in-region, vetted personnel
• Verify encryption key ownership and location (customer-managed keys, held in-region) for any workload with a residency requirement
• Treat sovereignty tier as an OU / management group / folder boundary, not a tag — tags are advisory, hierarchy boundaries are enforceable
• Re-validate sovereignty posture on every landing zone library upgrade — policy initiative names and scopes change between releases (as they did with the April 2026 SLZ refresh)

DNS Architecture

• Deploy private hosted zones per VPC/VNet; internal services resolve by name, never by IP
• Central DNS resolvers in the hub VPC/VNet handle cross-spoke and on-premises resolution
• Internal names must not resolve from the public internet (no split-horizon leakage)
• DNS over HTTPS is not permitted for workloads — all queries route through the controlled resolver

Private Endpoint Policy

• All PaaS services (object storage, databases, queues, key management) must use private endpoints
• Disable the public endpoint on every PaaS resource after the private endpoint is confirmed healthy
• Private endpoint DNS entries must be registered in the central private zone automatically at creation
• Do not rely on manual DNS record management — automate via IaC or an event-driven pipeline

AWS: Control Tower + Account Factory for Terraform

• AWS Control Tower landing zone v4.0 introduces a "Controls-Only" experience — you can now selectively disable individual service integrations (and Control Tower removes the associated managed resources cleanly) instead of an all-or-nothing deployment.
• Auto-enrollment can be configured so accounts moved into a registered OU automatically inherit baselines and controls, without a manual Account Factory step.
• Extend with Account Factory for Terraform (AFT) for IaC-managed account vending with customizations.
• Deploy an AWS Security Hub aggregator in the security account to consolidate cross-account findings.
• Enroll all new accounts via Control Tower Account Factory or auto-enrollment — never create accounts manually in the console.

Azure: Azure Landing Zones (ALZ) + Sovereign Landing Zone (SLZ)

• Microsoft's reference implementation now favors Azure Verified Modules (AVM)-based Terraform and Bicep deployment through the ALZ IaC Accelerator, over the earlier ALZ Portal accelerator.
• Management group hierarchy: Root → Platform → Landing Zones (Corp / Online / Local) → Sandbox.
• Built-in policy initiatives enforce logging, Defender for Cloud, encryption, and region restrictions automatically; SLZ layers sovereign control-level initiatives on top.
• Deploy via Azure DevOps or GitHub Actions pipelines using the library at its current release (2026.04.2 or later) — not the portal.

GCP: Cloud Foundation Fabric

• Google Cloud Foundation Fabric (GoogleCloudPlatform/cloud-foundation-fabric) is the reference Terraform implementation, with Fabric FAST as the stage-based, opinionated bootstrap path.
• Resource hierarchy: Organization → Folders (per environment) → Projects.
• Enforced via Org Policy Constraints applied at folder level, plus organization-level IAM Deny Policies, both inherited by all projects beneath.
• Use the Project Factory module (Terraform) for self-service project vending with guardrail inheritance.

Patterns Common to All Providers

By 2026, autonomous agent loops and MCP-connected tools became a routine workload type inside application landing zones — not a separate platform. The governance answer is not a new control plane; it's applying existing landing zone discipline (identity, network egress, secrets, audit logging) to a resource type that acts faster and less predictably than a human operator.

Guardrail Checklist for Agent-Accessible Accounts

• Every MCP server and connector is a governed, inventoried asset — approved before activation, not discovered after the fact
• Audit log every connector invocation with a session ID, correlated to the same log archive account used for human and CI/CD activity
• Apply budget and blast-radius limits (turn count, cost, duration) to autonomous loops the same way you'd apply quotas to a shared sandbox account
• No agent identity gets write access to production landing zone guardrails (SCP/RCP/Org Policy) — that remains a human-gated platform-team action
• Treat a bad agent-written memory or instruction as a security incident class, not a bug — it can bias every subsequent decision the agent makes

A landing zone without a governance loop decays. Establish clear ownership and a review cadence before day one.

Role Ownership

Review Cadence

Exception Process

1. Application team submits exception request with business justification and compensating controls
2. Security team reviews and classifies as accepted risk or rejected within 5 business days
3. Accepted exceptions are time-boxed (maximum 90 days) and tracked in a risk register
4. Exceptions automatically expire; teams must re-justify to extend