Enterprise landing zones
Sovereign landing zones, policy-as-code governance, and the platform engineering that keeps regulated Azure estates compliant and operable.
Vending, not provisioning by hand
A landing zone that scales is a repeatable path from "new workload request" to a compliant subscription: a management group placed in the right branch, policy assigned before the first resource lands, and guardrails — tags, budgets, allowed regions — enforced at vending time rather than audited after the fact. For sovereign estates the same pipeline also has to prove, continuously, that the policy assignment it created is still the one in force.
Vending places the subscription, attaches policy, and peers it into the hub in one pass — the audit trail is the pipeline run, not a change ticket.
Vending a workload subscription with guardrails attached
The pattern: create the management group, vend a subscription straight into it from the billing account scope, and assign a tagging policy before the subscription is handed over — so there's no window where a workload subscription exists without governance. Confirm resource and provider versions against Microsoft Learn before using this as-is; subscription vending in particular depends on your billing account type (MCA vs. EA).
Terraformresource "azurerm_management_group" "corp_sovereign" {
display_name = "corp-sovereign"
parent_management_group_id = data.azurerm_management_group.landing_zones.id
}
# Vend a new workload subscription straight into the Corp landing zone
resource "azurerm_subscription" "workload" {
subscription_name = "sov-corp-workload-01"
billing_scope_id = var.billing_account_scope
workload = "Production"
}
resource "azurerm_management_group_subscription_association" "workload_to_corp" {
management_group_id = azurerm_management_group.corp_sovereign.id
subscription_id = azurerm_subscription.workload.id
}
# Tag guardrail enforced at the moment of vending
data "azurerm_policy_definition" "require_tag" {
display_name = "Require a tag on resource groups"
}
resource "azurerm_policy_assignment" "require_tags" {
name = "require-cost-center-tag"
scope = azurerm_subscription.workload.id
policy_definition_id = data.azurerm_policy_definition.require_tag.id
}
Bicep
resource corpLandingZone 'Microsoft.Management/managementGroups@2023-04-01' = {
name: 'corp-sovereign'
properties: {
displayName: 'corp-sovereign'
details: {
parent: {
id: landingZonesManagementGroupId
}
}
}
}
resource requireTagAssignment 'Microsoft.Authorization/policyAssignments@2024-04-01' = {
name: 'require-cost-center-tag'
scope: subscription(workloadSubscriptionId)
properties: {
displayName: 'Require a tag on resource groups'
policyDefinitionId: requireTagPolicyDefinitionId
}
}
Latest on landing zones
The Sovereign Landing Zone Accelerator Just Adopted Built-In Policy — on a Repo Microsoft Says It's Archiving
v1.1.0 finally moves Sovereign Landing Zone onto Azure Policy's built-in initiatives. The repo shipping that improvement carries its own banner: archived in the first half of 2026 — a window that's already closed.
Read article →CAF Renamed Landing Zones on October 1 — Sovereign Landing Zone's Governance Page Is Still a Month Behind
CAF retired "application landing zone" for "workload landing zone" on October 1. Sovereign Landing Zone's governance page still uses the old term everywhere, including Azure Local disconnected mode.
Read article →Azure Enclave: Microsoft's Prefab Answer to "Build Us a Sovereign Landing Zone"
A new public preview promises to cut the time to deploy an isolated, policy-governed cloud environment from months to days. Here's what's proven and what isn't.
Read article →AKS Flex Nodes: The Data-Residency Pitch the Shared-Responsibility Table Doesn't Back Up
Pitched partly as a way to pin regulated workloads to on-premises hardware — Microsoft's own support policy hands you the network, the CNI, and the residency enforcement itself.
Read article →