Cloud Landing Zones

Landing zones built for AI workloads, on all three clouds.

The same five layers — identity, network, security, data and AI — expressed natively on Azure, AWS and Google Cloud, delivered as code, and governed by policy from the root of the hierarchy down.

Reference architectures

Three clouds, one request path

Each diagram follows a request from the edge through identity and the hub network into a workload spoke and its data. The security plane observes every layer; infrastructure as code deploys all of it.

Microsoft Azure

Management-group hierarchy with policy inherited from the root, a Virtual WAN hub per region, and every PaaS and model endpoint reachable only through Private Link.

Text description of the diagram

Management groups: Tenant Root Group → Platform, Landing Zones, Sandbox.

Edge: Front Door + WAF — DDoS Network Protection
Identity: Entra ID — PIM · Conditional Access
Network: Virtual WAN hub-spoke — Azure Firewall · Private Link
Workload: App spoke — AKS · App Service; Azure AI Foundry attached via Private Link
Data: Microsoft Purview — Storage · SQL via private endpoint

Security plane: Defender for Cloud · Sentinel, across every layer. IaC: Bicep + Terraform (Azure Policy as code · subscription vending).

Download reference architecture

AWS

Control Tower organization with OUs separating security, shared infrastructure and workloads, Transit Gateway routing through an inspection VPC, and Bedrock reached over interface endpoints.

Text description of the diagram

Organizational units: Organization root → Security OU, Infrastructure OU, Workloads OU.

Edge: CloudFront + AWS WAF — Shield · ALB in ingress VPC
Identity: IAM Identity Center — Permission sets · SCPs
Network: Transit Gateway hub-spoke — Inspection VPC · PrivateLink
Workload: Workload account — EKS · Lambda; Amazon Bedrock attached via VPC endpoint
Data: Macie + Lake Formation — S3 · Glue Data Catalog

Security plane: Security Hub · GuardDuty, across every layer. IaC: Terraform + CDK (Account Factory · SCPs as code).

Download reference architecture

Google Cloud

Folder hierarchy with organization policies at the root, Shared VPC host projects joined through Network Connectivity Center, and Vertex AI inside a VPC Service Controls perimeter.

Text description of the diagram

Folders: Organization → Common, Production, Non-production.

Edge: Cloud Load Balancing — Cloud Armor WAF policies
Identity: Cloud Identity — IAM · Workforce Identity Federation
Network: Shared VPC hub-spoke — NCC · Private Service Connect
Workload: Service project — GKE · Cloud Run; Vertex AI attached via PSC endpoint
Data: Dataplex — BigQuery · VPC Service Controls

Security plane: Security Command Center, across every layer. IaC: Terraform (Org policies · project factory).

Download reference architecture

Layer by layer

How the layers map across clouds

Same control objective, native service on each cloud. We design to the objective and implement with the native service, so nothing depends on a cross-cloud abstraction you then have to operate.

Landing-zone layers compared across Microsoft Azure, AWS and Google Cloud
Layer	Microsoft Azure	AWS	Google Cloud
Hierarchy	Management groups + subscriptions	Organizations OUs + accounts (Control Tower)	Organization → folders → projects
Guardrails	Azure Policy (deny / deployIfNotExists)	Service control policies + Config rules	Organization policy constraints
Identity	Entra ID, PIM, Conditional Access	IAM Identity Center, permission sets	Cloud Identity, IAM, Workforce Identity Federation
Edge	Front Door + WAF, DDoS Network Protection	CloudFront + AWS WAF, Shield	Cloud Load Balancing + Cloud Armor
Network hub	Virtual WAN hub, Azure Firewall	Transit Gateway, inspection VPC	Shared VPC, Network Connectivity Center
Private connectivity	Private Link / private endpoints	PrivateLink interface endpoints	Private Service Connect
Security posture	Defender for Cloud, Microsoft Sentinel	Security Hub, GuardDuty	Security Command Center
Data governance	Microsoft Purview	Macie + Lake Formation	Dataplex, VPC Service Controls
AI platform	Azure AI Foundry	Amazon Bedrock	Vertex AI
Key management	Key Vault (customer-managed keys)	AWS KMS (customer-managed keys)	Cloud KMS (CMEK)
IaC	Bicep + Terraform	Terraform + CDK	Terraform

How we deliver

Code, policy and vending — then the AI controls

A landing zone is only as good as the path for the next workload. We hand over modules, guardrails and a vending pipeline your platform team runs without us.

IaC modules

One module per box on the diagram

Hierarchy, identity, hub network, spoke, security baseline and AI endpoints ship as versioned Bicep, Terraform or CDK modules in your repository, with plan output reviewed in the PR before any apply.

Policy-as-code guardrails

Deny by default, at the root

Azure Policy, service control policies and organization policy constraints are authored as code, assigned at the top of the hierarchy and tested in CI against known-bad fixtures before they reach production scopes.

Account & subscription vending

New workloads land pre-governed

A pull request against the vending module creates the subscription, account or project, peers it to the hub, applies tags, budgets and baseline policies, and grants access through groups — never to individuals.

AI control · private endpoints

Model APIs never touch the internet

Azure AI Foundry, Bedrock and Vertex AI are reached only through Private Link, VPC interface endpoints or Private Service Connect, with public network access disabled by policy.

AI control · ledger logging

Every prompt and response on the record

An inference gateway in the spoke hashes each prompt and response, writes the entry to the decision ledger and ships payloads to a retention-locked store, so any output can be replayed and audited.

AI control · key management

Your keys, your revocation

Model artefacts, vector stores, logs and fine-tuning data are encrypted with customer-managed keys in Key Vault, KMS or Cloud KMS; rotating or disabling a key is a tested runbook, not an escalation.

Land AI workloads on a zone you can defend

We assess your current hierarchy, network and identity against the reference architecture, then deliver the modules, guardrails and vending pipeline to close the gaps — in your repositories, under your change control.