Azure Landing Zones with Terraform: Subscription Vending at Scale

The client was an energy group operating across 12 European countries, recently standardised on Azure after years of hybrid and on-premises operations. They had 140 Azure subscriptions created manually over three years, with inconsistent naming, wildly different policy configurations, and no automated guardrails. New subscription requests took 3–6 weeks to provision.

Our mandate: design and implement an Azure Landing Zone architecture that reduced new subscription provisioning to under 24 hours, enforced consistent security and networking baselines, and gave teams the autonomy they needed to move fast within safe boundaries.

What is Subscription Vending?

Subscription vending is the automation of subscription creation and baseline configuration. Instead of manual provisioning with ad-hoc configurations, teams submit a request (via a form or PR), and automation creates a subscription with pre-configured networking, IAM baselines, policies, and cost tags within minutes.

Management Group Hierarchy Design

The foundation of any Azure Landing Zone is the management group hierarchy — the organisational structure that determines how policies and RBAC propagate. We designed a five-level hierarchy: Tenant Root → Platform → Landing Zones → (Corp / Online / Sandbox) → subscriptions.

The key design decision was separating Platform subscriptions (connectivity hub, identity, management) from Landing Zone subscriptions (application workloads). Platform subscriptions are centrally managed with tight controls. Landing Zone subscriptions apply the appropriate policy tier based on workload classification.

The Subscription Vending Machine

The vending machine is a Terraform module that accepts a subscription specification as input and produces a fully configured subscription as output:

Subscription Vending Input → OutputInput (PR / Service Portal): workload_name: "payments-api" classification: "corp-production" business_unit: "financial-services" cost_centre: "FS-042" owner_email: "team@company.com" Outputs (automated in ~18 minutes): ✓ Subscription created and moved to correct MG ✓ Required tags applied ✓ Azure Policy initiatives assigned ✓ Hub-spoke networking peered ✓ Defender for Cloud enabled ✓ Log Analytics workspace connected ✓ Budget alert configured ✓ Owner RBAC assigned

Policy-as-Code at Scale

Azure Policy was the most complex component to design. The energy group had 14 regulatory requirements (ISO 27001, NIS2, GDPR, sector-specific ENTSO-E guidelines) that needed to be encoded as policy. We used Azure Policy initiatives to group related controls and applied them at management group level with remediation tasks for existing non-compliant resources.

Policy design followed a clear principle: Audit first, deny when proven. Every new policy started as Audit effect, generating a compliance dashboard showing scope. Only after confirming no legitimate use cases were blocked did we switch to Deny. This prevented the common failure mode where strict policies block legitimate work and get exceptions that undermine the entire framework.

Key Takeaways

Separate Platform and Landing Zone subscriptions in your management group hierarchy
Subscription vending via Terraform: from 3 weeks manual to 18 minutes automated
Apply policies at management group level; use inheritance to reduce duplication
Start policies as Audit before switching to Deny — prevents legitimate work from being blocked
Terraform Cloud workspaces align well with subscription-per-workspace for state isolation