Subscription Vending: Automating New Workload Onboarding with IaC

The ticket comes in on a Monday. A team needs a new production subscription — they have a sprint starting Thursday. You know what this means: Management Group placement, VNet config, hub peering, RBAC assignments, a budget, and a diagnostic settings policy to wire it up to the SIEM. Each step is manual. Each step is yours.

Thursday comes and goes.

When your platform is growing fast enough that you’re fielding three or four of these requests a week, manual subscription provisioning stops being inconvenient and starts being the reason engineering velocity stalls. You aren’t a bottleneck because you’re slow — you’re a bottleneck because the process requires a human for every step.

Subscription Vending replaces that process with a pull request. When the vending machine runs, it doesn’t just create a billing entry. It places the subscription in the correct Management Group, peers its VNet to the hub, assigns mandatory RBAC roles, and wires up a budget. Your app teams get a fully configured environment. You get to approve a PR instead of running a script.

1. The PR-Based Vending Workflow

The goal is to move the conversation from “Can you create this for me?” to “Here is the code I want to run.”

PR-Based Vending Workflow

Define your workloads in a YAML or JSON file in a Git repository and you get a full audit trail automatically — who requested what, when, and what changed. Your team reviews and approves the PR. The automation handles the rest.

2. The Subscription Vending Machine

The vending machine is a modular IaC module that coordinates six deployment steps in sequence.

The Subscription Vending Machine Architecture

2.1: Creating the Subscription Alias

Use the Microsoft.Subscription/aliases resource to provision subscriptions programmatically. This resource is idempotent — run it twice with the same name and you get back the existing subscription, not a duplicate. That property matters when your pipeline retries on transient failures.

Bicep Pattern:

targetScope = 'tenant'

module subVend 'br/public:avm/ptn/lz/sub-vending:0.5.0' = {
  name: 'subVend-${workloadName}'
  params: {
    subscriptionAliasEnabled: true
    subscriptionBillingScope: '/providers/Microsoft.Billing/billingAccounts/12345/enrollmentAccounts/67890'
    subscriptionDisplayName: workloadName
    subscriptionWorkload: 'Production'
  }
}

3. Automation Patterns: The “90-Second Rule”

Here is the failure your pipeline will hit the first time: you create the subscription, immediately try to assign a role, and get a PrincipalNotFound or ScopeNotFound error. The subscription exists — Azure just hasn’t finished propagating it to Entra ID yet. That takes 60-90 seconds, and your IaC doesn’t know that.

This is the Identity Propagation Delay, and every subscription vending implementation hits it eventually.

Terraform Fix: Use the time_sleep resource to introduce a mandatory pause after subscription creation.

resource "time_sleep" "wait_for_subscription" {
  create_duration = "90s"
  depends_on      = [azurerm_subscription.workload]
}

4. Self-Service IPAM: Avoiding Overlaps

The hardest scaling problem in subscription vending is IP Address Management. Two teams pick 10.1.1.0/24. Both PRs get approved. VNet peering fails for one of them — silently, at apply time, after both subscriptions already exist.

Include a CIDR Overlap Check in your CI/CD pipeline. A Python script reads a central ipam.yaml file in the repo, validates the requested range against existing allocations, and blocks the PR if there’s a collision. Teams pick their own IPs; your pipeline enforces the global network plan. The conflict surfaces in a PR comment, not a 3am support ticket.

5. Security and Billing Guardrails

Vending time is the right time to apply mandatory controls — before there’s any workload running to object. Wire these in as non-optional outputs of the vending module:

RBAC: An “App Admin” group for the workload team.
Budget: A $500/month starting budget with automated alerts to your team. Adjust later if needed, but start with a guard rail.
Diagnostics: A DINE policy (from Article 4) that automatically connects the subscription to the hub’s Log Analytics Workspace. This is what prevents the 47-day gap from the opening of this article.

Key Takeaways

Git is your audit trail: Every subscription request, approval, and configuration change lives in a PR. When compliance asks who approved the production subscription in Q1, you have an answer.
Idempotency prevents incidents: Use aliases and AVM pattern modules so your pipeline can re-run safely on retries without duplicating resources.
Wait for propagation: Include a 90-second pause after subscription creation. Skip it and your first role assignment will fail.
Catch CIDR collisions in the PR: IPAM validation at PR time surfaces conflicts before any infrastructure exists. IPAM validation after terraform apply is too late.

Next Steps:

Read Centralized Monitoring: Log Analytics, Diagnostic Settings, and Azure Monitor Workbooks to monitor the traffic and costs generated by these vended subscriptions.
Read CI/CD Pipeline for Your Landing Zone: Deploying Azure Verified Modules with GitHub Actions to see the complete GitHub Actions pipeline that powers the vending machine.