Cloud landing zone and account vending
Cohash builds AWS and Azure landing zones as code. First comes the organization or management group hierarchy, then identity federation, central logging, the network hub and preventive guardrails. After that we add account or subscription vending, so teams request a new environment through a pull request. We usually use Control Tower with Account Factory for Terraform on AWS, and the Azure Verified Modules for platform landing zones on Azure.
- 01Hierarchy and guardrail design
- 02Identity and access
- 03Logging, security and network hub
- 04Vending pipeline
- 05Migrate existing accounts
The story
Told without the client's name or anything that could identify them.
A media company's cloud team created accounts and subscriptions by hand, so each one arrived with different settings and new environments were a long wait. Logs lived in each account, guardrails were written in a wiki rather than enforced, and the Azure side still depended on Blueprints and the archived enterprise-scale module. We designed the organizational unit and management group hierarchy around environments and risk, federated access through Entra ID, and built central logging, security tooling and a hub network as code. Account Factory for Terraform on AWS and a subscription vending module on Azure now create environments from a pull request. Existing accounts were enrolled with guardrails in audit mode first, and Blueprint assignments were converted to deployment stacks.
why it was urgentAzure Blueprints retires on 31 January 2027, with a phased retirement that began 31 July 2026. Microsoft archived the caf-enterprise-scale Terraform module on 15 September 2026 and points users to Azure Verified Modules for platform landing zones. Teams on either have a dated reason to rebuild their foundation.
- openIt takes weeks to get a new account or subscription, and no two show up configured the same way.
- recurringLogs live in each account, so an incident means asking every team for access.
- blockedYour Azure landing zone still depends on Blueprints or the archived enterprise-scale module.
- openThe guardrails exist, in a wiki. No service control policy or Azure Policy actually enforces them.
The estate, before and after
Before: accounts and subscriptions created by hand
Each account or subscription was set up by hand with its own logging and access. Guardrails lived in a wiki, and the Azure foundation relied on Blueprints and the archived enterprise-scale module.
Read the diagram as text
- Environment requests → Manual account setup: request
- Guardrail wiki → Manual account setup: reference
- Manual account setup → AWS accounts: click setup
- Manual account setup → Azure subscriptions: click setup
- Azure Blueprints → Azure subscriptions: assignments
After: a landing zone with vending as code
A pull request triggers Account Factory for Terraform or subscription vending, which places the new environment under the right hierarchy level with guardrails and baselines applied. Logs flow to a central archive and access is federated through Entra ID.
Read the diagram as text
- Vending pull request → Vending pipeline: trigger
- Vending pipeline → AWS Control Tower OUs: new account
- Vending pipeline → Azure management groups: new subscription
- Guardrails → AWS Control Tower OUs: SCPs
- Guardrails → Azure management groups: policy
- Entra ID → AWS Control Tower OUs: permission sets
- Entra ID → Azure management groups: role assignments
- AWS Control Tower OUs → Log archive: org trail
- Azure management groups → Log archive: log export
- AWS Control Tower OUs → Hub network: peering
- Log archive → Security tooling: findings
How we run it, phase by phase.
5 phases take you from Accounts and subscriptions created by hand to Governed landing zone with account vending. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Hierarchy and guardrail design
We design the AWS organizational units or Azure management groups around environments and risk. Then, level by level, we pick the preventive controls, meaning SCPs or Azure Policy deny effects, and the detective controls that sit alongside them.
- phase 02
Identity and access
We federate the cloud with Entra ID or Okta, map groups to permission sets or Azure roles, and set up break-glass accounts that alert on use.
- phase 03
Logging, security and network hub
Central log archive and security tooling accounts or subscriptions, organization-wide CloudTrail or activity log export, and a hub network with egress, DNS and on-premises connectivity.
- phase 04
Vending pipeline
On AWS we use Account Factory for Terraform, on Azure a subscription vending module. Either way it starts with a pull request carrying owner, cost center and environment, and it ends with baseline customizations applied.
- phase 05
Migrate existing accounts
Enroll existing accounts, or move subscriptions under the new hierarchy. Fix guardrail violations in audit mode first, then turn on enforcement. Convert Blueprint assignments to deployment stacks.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
New environments come from a pull request
Teams request an account or subscription with owner, cost center and environment in a pull request, and vending applies the same baseline customizations every time.
- result 02
Guardrails are enforced, not documented
Service control policies and Azure Policy deny effects apply by level of the hierarchy, and each control ran in audit mode against existing accounts before enforcement.
- result 03
Logs are in one place
We set up organization-wide CloudTrail and activity log export into a central log archive. An incident no longer starts with asking each team for access.
- result 04
Access is federated with break-glass alerting
We mapped Entra ID groups to permission sets and Azure roles, and break-glass accounts alert whenever they're used.
- result 05
Nothing depends on Blueprints
Blueprint assignments were converted to deployment stacks and the archived enterprise-scale module was replaced with Azure Verified Modules ahead of the 31 January 2027 retirement.
Risks we plan for
-
Guardrails that block real work
Switch a deny policy on without an audit period and deployments break. Each control runs in audit mode against existing accounts first.
-
Network design locked in too early
IP ranges and hub topology are painful to change once workloads sit on them. The address plan leaves room for on-premises ranges, mergers and regions you haven't opened yet.
-
A landing zone nobody can change
Click-built or vendor-only setups drift. Everything, including guardrails, lives in code with a named platform owner.
Where AI helps, and where it needs guardrails
Microsoft publishes an Azure Blueprints migration skill for GitHub Copilot that helps convert artifacts to deployment stacks, and it warns that the output has to be reviewed. We use tools like that for first drafts. Landing zones need a pattern for AI workloads now as well. Model endpoints stay in approved regions, agent identities get their own accounts or subscriptions, and MCP servers are reachable only through the hub.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- design01
Landing zone architecture with hierarchy, guardrails and network design
yours to keep - design02
Landing zone code in Terraform, Bicep or both, with pipelines
yours to keep - code03
Account or subscription vending pipeline with baseline customizations
yours to keep - document04
Identity federation and break-glass procedure
yours to keep - plan05
Migration plan for existing accounts, subscriptions and Blueprint assignments
yours to keep
Platforms and services on this move
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Break-glass accounts
- Emergency admin accounts excluded from normal access policies. You only use them when everything else has failed, and you watch them closely.in context →
- 02Drift
- When a live configuration slowly wanders away from what you intended, often through emergency edits nobody tracked.in context →
- 03Egress
- Data leaving a cloud provider's network. Getting data in is free. Getting it out is billed by the gigabyte.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Should we use Control Tower or build our own on AWS?
Usually Control Tower with Account Factory for Terraform. AWS keeps the core controls maintained and AFT gives you GitOps vending. A custom build only earns its keep when you need controls or account structures that Control Tower can't express.
02What replaces Azure Blueprints?
Microsoft recommends deployment stacks, with template specs as another option. Landing zones built on the old enterprise-scale module should move to Azure Verified Modules for platform landing zones.
03Can we keep our existing accounts?
Yes. Existing AWS accounts can be enrolled in Control Tower and Azure subscriptions moved under new management groups. Guardrail findings are fixed in audit mode before enforcement.
04How long does a landing zone take?
Mostly on what's already there. The number of accounts or subscriptions, the connectivity you need and the controls your compliance team asks for all move the date. A greenfield foundation goes faster than enrolling a big existing estate.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case study
Apache Airflow 2 to Airflow 3
Upgrading self-managed Apache Airflow 2, now past end of life, to Airflow 3, and fixing removed features, auth and scheduling changes before DAGs move.
read the case study773f6e72 - 01Microsoft Learn: Azure Blueprints overview and retirementlearn.microsoft.com ↗
- 02GitHub: terraform-azurerm-caf-enterprise-scale (archived 15 Sep 2026)github.com ↗
- 03AWS: Account Factory for Terraform overviewdocs.aws.amazon.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it