Azure Subscription Vending: Replacing the Shared Owner Subscription

The single-subscription bottleneck

A common starting point: someone creates one Azure subscription, names it "Production", and grants Owner to every engineer so nobody is blocked.

That is quick at first. As the team and the workload grow, the same problems tend to appear:

• Resource collisions. An experiment in one resource group can change or delete something another environment depends on, such as shared secrets or a staging database.
• Unclear cloud bills. When tags are applied inconsistently, nobody can say which environment or feature drove an increase on the invoice.
• No blast-radius isolation. A compromised developer laptop or token carries enough rights to delete production data and backups.

Why forking the reference accelerators is hard for small teams

The natural next step is to adopt Microsoft's Cloud Adoption Framework (CAF) reference implementations. They are well built, but they are written for enterprise operating models, and small teams often run into the same friction:

• Scope built for large estates. The reference implementations expose a large number of options and assume dedicated network and security teams running firewalls, hybrid DNS and connectivity hubs.
• Maintaining a fork. Once the reference code is forked and customised, taking upstream updates without breaking your own pipelines becomes ongoing platform engineering work.
• Competing with product work. A team without a dedicated platform engineer has to pull people off product delivery to configure and maintain it.

The pattern: a four-stage vending pipeline

Subscription vending separates "a team needs an environment" from "an administrator clicks through the portal". A request is written as configuration, reviewed in a pull request, and a pipeline creates and configures the subscription. This is the pattern VitCamp sets up in the Cloud Governance Foundation.

1. Intent declaration. A team submits a short request naming the workload, environment tier, technical owner and cost centre.
2. Programmatic vending. The pipeline calls the subscription alias API against your Microsoft Customer Agreement or Enterprise Agreement billing scope to create a new, separate subscription.
3. Management hierarchy. The subscription is placed under the target management group, so it inherits the policy assignments set at that scope.
4. Identity and cost ring-fence. Entra ID security groups receive scoped Contributor rights instead of standing Owner access, and a monthly budget with budget alerts is created for the subscription.

What happens behind the pipeline

The review happens on the pull request. Once it merges, the pipeline runs without anyone needing portal access:

• No long-lived pipeline secrets. The pipeline authenticates to Azure with OpenID Connect (OIDC) workload identity federation, so no service principal client secret is stored in repository secrets.
• Guardrails inherited by default. Because the subscription lands under a pre-configured management group, policies such as denying public network access on databases or denying resources without required tags apply before the first workload deployment.
• Cost allocation from the start. Required tags (Environment, CostCenter, Owner) are enforced by Azure Policy, so Cost Management views can be grouped by environment and owner.

Tradeoffs to plan for

Subscription vending solves the shared-subscription problem, but it brings three operational constraints of its own.

Default quotas on new subscriptions

New subscriptions start with default quotas, such as regional vCPU limits per VM family. When subscriptions are vended programmatically, build quota increase requests into the workflow so teams do not hit a regional limit in the middle of a release.

Sandboxes that outlive their purpose

When a new environment is easy to request, unused ones pile up unless they have an end date. A time-to-live (TTL) or expiry tag on sandbox subscriptions, checked by a scheduled job, reminds the owner and cleans up the sandbox unless someone renews it.

Shared DNS across subscriptions

Multiple subscriptions need shared name resolution for internal services and private endpoints. Before connectivity hubs or firewalls are needed, centrally owned Azure Private DNS zones linked to each spoke network cover this without adding hourly-billed network appliances.

What the pattern gives you

With vending in place, a new environment is a reviewed pull request rather than an administrator ticket. Sandboxes sit in their own subscriptions, so an experiment that goes wrong is contained away from staging and production.

The hierarchy, policies and pipeline live in your own repository. In the Cloud Governance Foundation, VitCamp hands this over with an Architecture Design Document (ADD), high-level diagrams and Day-2 operational runbooks, so your team owns and runs it.

Frequently asked questions