Application Landing Zone Model Selection
Every few weeks in an enterprise engagement, the same conversation happens. A team wants a subscription vended, another team argues they should share an existing one, and nobody has a clear framework for why. The platform team makes a judgment call, the decision doesn't get documented, and six months later there's either a subscription proliferation problem or a compliance gap that requires painful remediation.
I wrote this to stop that cycle. The choice between landing a workload in a shared subscription versus vending a dedicated one has clear criteria. Once you actually lay them out, most cases aren't ambiguous. What makes it feel hard is that the wrong choice in either direction has real consequences. Over-vending subscriptions to teams that can't operate them creates abandoned subs and a governance mess. Under-vending forces regulated workloads into a shared boundary where they shouldn't be.
The core principle I come back to: use the lightest model that genuinely satisfies the security, compliance, blast-radius, and operational requirements. A shared subscription is not a compromise. It's the right answer for a large portion of workloads. Subscription vending exists for when that model genuinely cannot meet your needs.
The Two Models
Both models inherit platform guardrails from the management group hierarchy — Azure Policy, RBAC baselines, Defender for Cloud, centralised logging. The difference is isolation depth, provisioning speed, and who owns what operationally.
Model A — Shared Subscription
The application lands inside an existing Corp or Online subscription. Platform creates a new Resource Group and a new delegated subnet within the existing spoke VNet. RBAC is scoped to the RG.
| Property | Value |
|---|---|
| Isolation boundary | Resource Group + Subnet |
| Network | New /28–/24 subnet within existing spoke VNet, peered to hub |
| RBAC | RG-scoped role assignments; no sub-level Owner for app teams |
| Billing | Shared cost centre; tag-based chargeback mandatory |
| Provisioning lead time | Hours to 1–2 days |
| Platform team involvement | Low — IaC template + IPAM subnet request |
| Quota pool | Shared with co-tenants in the subscription |
| Policy scope | Inherited; no per-workload Policy customisation |
Model B — Subscription Vending
A net-new subscription is provisioned via the vending pipeline, placed under the appropriate management group, and handed to the application team with its own spoke VNet peered back to the hub.
| Property | Value |
|---|---|
| Isolation boundary | Subscription (strongest Azure isolation unit) |
| Network | Dedicated spoke VNet, new CIDR from IPAM, hub-peered |
| RBAC | App team can hold Contributor / Owner at sub level |
| Billing | Dedicated cost centre; clean spend isolation |
| Provisioning lead time | 1–5 business days (pipeline + approvals) |
| Platform team involvement | Moderate — vending pipeline, IPAM, peering, MG placement |
| Quota pool | Dedicated, independent from other workloads |
| Policy scope | Inherited + targeted exemptions requestable at sub level |
Decision Dimensions
A single hard requirement in the Model B column is sufficient. Don't let convenience arguments override it.
| Dimension | Model A — Shared Sub | Model B — Subscription Vending |
|---|---|---|
| Blast Radius | Contained to the RG. Quota exhaustion or sub-level policy misconfig by a neighbour affects all RGs in the subscription. | Full subscription boundary. Resource and quota events fully isolated. |
| Compliance Scope | Shares the subscription's posture. Cannot isolate PCI-DSS CDE, HIPAA BAA, or IL4+ without impacting all co-tenants. | ✅ Preferred. Dedicated compliance scope. Mandatory for PCI, HIPAA, SOX, FedRAMP. |
| RBAC Isolation | RG-scoped roles only. No Owner at sub level. Cannot create sub-scoped resources (Policy, Budget, Management Locks). | Full autonomy at subscription scope. Team can create locks, budgets, and custom Policy assignments. |
| Network Isolation | Shares VNet address space. NSG + ASG provide intra-subnet segmentation. No VNet-level peering control. | Dedicated VNet and CIDR. Full control over peering, Private DNS, NSG/UDR topology. |
| Quota & Limits | ⚠️ Risk. vCPUs, Public IPs, Storage accounts all shared. A noisy neighbour can exhaust quota for everyone. | Dedicated quota envelope. No noisy-neighbour contention. Essential for GPU, HPC, SAP. |
| Cost Attribution | Requires disciplined tagging. Works, but demands governance maturity. | ✅ Native sub-level cost centre. Zero tagging required for top-level separation. |
| Policy Customisation | Inherits all subscription policies. Exemptions only if platform team adds them globally. | Team can request targeted Policy exemptions or assignments at sub scope via vending pipeline. |
| Provisioning Speed | ✅ Fast. Hours to 1 day. No approval chain beyond IPAM request. | Days. Pipeline trigger, IPAM, VNet peering, MG placement, billing scope, approval gates. Slower — but done once per workload lifetime. |
| Operational Overhead | Low for app team. Platform manages routing, NSG baselines, VNet peering. | Higher. Team owns VNet, NSGs, UDRs, Private DNS, and sub-level health. Requires cloud maturity. |
| Dev / Test Environments | ✅ Recommended. RGs per environment in same or separate shared sub. Fast to create and delete. | Acceptable if compliance requires environment-level sub separation. Overkill for pure dev/test. |
| Third-Party Vendor Access | ❌ Caution. External vendor in a shared sub exposes neighbouring workloads. | ✅ Preferred. Dedicated sub limits blast radius of vendor-side compromise. Clean revocation path. |
| Subscription Limit Risk | Low — no new subscription consumed. | Consumes one subscription per workload/environment. EA limits typically 2,000–5,000; platform team must track. |
Decision Flow
Work through these top to bottom. A single "Model B" trigger is sufficient — don't revisit earlier answers once you've hit one.
One thing I try to enforce in architecture review boards: teams must not self-select Model B for the perception of autonomy or to sidestep platform governance. Model B carries ongoing operational obligations. If the team can't demonstrate ownership of VNet operations, NSG management, and sub-level health alerting, a shared sub with platform-managed networking is safer for everyone.
Application Archetypes
Model A — Shared Subscription
| Workload | Management Group | Why |
|---|---|---|
| Legacy Lift-and-Shift (IaaS VMs) | Corp | Simple rehosted workloads. No unique compliance scope, predictable footprint. Shared sub keeps migration velocity high. |
| Internal LOB Applications | Corp | HR portals, finance tooling, intranet apps. Low external exposure, standard data classification, modest resource needs. |
| Dev / Test / UAT Environments | Sandbox | Short-lived, non-production. Fast provisioning matters more than isolation. No compliance scope. Auto-shutdown via Policy. |
| Internet-Facing Web / API (Standard) | Online | Customer-facing apps without cardholder or health data. Front Door / WAF in hub. Subnet separation sufficient for single teams. |
| Innovation / PoC Labs | Sandbox | Short-lived experiments with no production data. No hub connectivity. Hard budget ceiling. Speed of experimentation is the driver. |
Model B — Subscription Vending
| Workload | Management Group | Why |
|---|---|---|
| PCI-DSS Cardholder Data Environment | Corp › PCI-DSS | CDE must be isolated at subscription level to limit QSA audit scope and apply dedicated Defender for Cloud policies. No exceptions. |
| HIPAA / PHI Workloads | Corp › HIPAA | BAA-bounded environment requires sub-level isolation. Enables HITRUST/HIPAA initiative without affecting other workloads. |
| SAP / Oracle ERP Systems | Corp › SAP | Extreme resource requirements (Mv2, M-series, Ultra Disk) exhaust shared quota. Vendor support may mandate subscription isolation. |
| AI / ML Platforms (GPU, Azure OpenAI) | Corp or Data | GPU VM SKUs and OpenAI TPM quotas are tightly constrained per subscription. One AI team can exhaust regional GPU quota for every co-tenant. |
| Enterprise AKS Platform (multi-team) | Corp / Online | Large shared clusters need sub-level quota control, dedicated Private DNS for service mesh, and independent upgrade policies. |
| Enterprise Data Platform (Databricks / Synapse / Fabric) | Corp › Data | Data platforms span many services and generate significant cost. Sub vending provides a clean data landing zone boundary with dedicated data governance policies. |
| Azure Virtual Desktop / VDI | Corp | Microsoft's own AVD ESLZ guidance prescribes a dedicated subscription. Shared sub leads to quota contention and complex NSG management. |
| Third-Party / Vendor-Managed Apps | Corp / Online | External vendor credentials in a shared sub is non-negotiable from an InfoSec standpoint. Dedicated sub limits blast radius of any vendor-side compromise. |
| Security / SOC Tooling (Sentinel, MDI) | Platform › Security | SoD requirement — security telemetry must be separated from operational resources. Platform-managed or dedicated sub only. |
Things I've Gotten Wrong
"Start in shared, migrate to dedicated later"
I've made this call before and it cost more than it saved. The usual scenario: the app "doesn't need its own sub yet" and lands in a shared corp sub. Six months later it's handling regulated data, the team has grown, and now Private Endpoints need to be recreated, firewall rules re-established, RBAC re-scoped, and policy exemptions re-filed in the new subscription. If the workload will clearly need Model B within 18 months, start there. The provisioning time is a one-time cost. The migration isn't.
Splitting regulated data paths across RGs to satisfy auditors
If an API sometimes handles PCI data, the entire workload is in scope. I've seen teams try to convince QSAs that two RGs in the same shared subscription represent a compliance boundary. It doesn't work. Use Model B and scope the entire workload inside it.
Vending subscriptions to teams that can't operate them
The subscription vending pipeline should not be a self-service machine with no questions asked. I've inherited environments with 40+ subscriptions, half of which were created "for a PoC" and never decommissioned. Nobody responding to Defender alerts, no NSG reviews, no budget oversight. Before vending, the team should be able to name who owns VNet operations, where NSG flow logs go, and what the decommission plan looks like.
IPv4 exhaustion accelerated by Model A
If your IPAM pool for existing spoke VNets is nearly full, every Model A deployment adds a subnet and accelerates the problem. I've hit this in engagements where the original network design didn't account for growth. In that situation, Model B (new spoke, new CIDR) is the right choice even for workloads that would otherwise qualify for Model A. Check available address space before you decide.
Granting RBAC at management group scope during onboarding
This is a specific mistake I've seen in vending pipelines: granting the app team Contributor at the MG scope "for convenience." That assignment silently applies to every current and future subscription under that MG. Always scope RBAC to the specific subscription or resource group during vending — never to the MG.
Edge Cases
Mixed-classification apps
If a single application sometimes handles regulated data (an API that touches PCI data, for example), treat the entire workload as in scope. Put it in Model B under the most restrictive classification's compliance MG. Don't try to split data paths across RGs in a shared sub to satisfy auditors.
Legacy apps with Active Directory RBAC dependencies
Many IaaS lifts carry assumptions from on-prem AGDLP models. Validate whether the app requires domain-joined VMs with line-of-sight to Domain Controllers in the Identity subscription. If the team expects AD-level admin access, Model B prevents them from accidentally acquiring that access path and exposing neighbouring workloads.
Microservices with different compliance tiers
Deploy each compliance tier in its own subscription via Model B, but use a shared subscription (Model A) for non-sensitive services. Use Private Endpoints across subscriptions to keep inter-service traffic on the backbone. This minimises subscription proliferation while correctly scoping each regulated component.
Start-up / innovation squads within the enterprise
Use a dedicated Sandbox or Corp subscription via Model B for the production path, but place non-prod experiments in a Sandbox MG shared sub (Model A) with no connectivity to corp networks and a hard budget ceiling.
Governance Controls
Model A — Required Controls
- Mandatory tagging policy at RG scope:
environment,application,cost-centre,data-classification - RG-level Delete Lock on all production resource groups
- NSG flow logs enabled on all subnets, shipped to central Log Analytics via diagnostic settings
- No Public IP creation without platform approval (Policy enforced)
- Service Endpoints or Private Endpoints for all PaaS resource connections — no public endpoints in Corp MG
- Subnet delegation documented in IPAM with owning application team contact
- RBAC: RG-scoped Contributor for app team; Reader for audit team; no Owner at sub scope for app teams
- Budget alert at RG scope with thresholds at 80% and 100% of monthly estimate
Model B — Required Controls
- Subscription placed in correct management group by vending pipeline — no manual re-parenting post-provision
- Dedicated spoke VNet peered to hub via vending pipeline — no manual peering by app team
- IPAM registration mandatory — CIDR block allocated from enterprise pool, not self-assigned
- Subscription-level Budget alert configured at provisioning time, hard-coded in the vending template
- Defender for Cloud standard tier auto-enabled across all plans via Policy
- Diagnostic settings: Subscription Activity Log to central platform-owned Log Analytics Workspace
- App team designated owner(s) must acknowledge subscription operational responsibilities in onboarding checklist
- Subscription naming convention:
sub-{app}-{env}-{region} - Quarterly subscription review cadence — teams that do not respond within 30 days trigger escalation
- Decommission path documented at provisioning time — no orphaned subscriptions; retired subs moved to Decommissioned MG
- Private DNS zone ownership documented at provisioning — app team or platform team, not both
Migration Paths
| Transition | Description | Effort |
|---|---|---|
| Model A → Model B | Provision new sub via vending, re-deploy via IaC into new VNet/subnet, migrate data (Storage, SQL), re-establish Private Endpoints and DNS, update hub firewall rules, decommission old RG. Stateful services carry the most risk. | High |
| Model B → Model A | Triggered by app decommission or consolidation. Only valid if compliance requirements are removed and the target shared sub has sufficient quota. Use Decommissioned MG pattern to retire the source sub cleanly. | Medium |
| Model A → Model A (cross-sub) | Move RG to new subscription (az resource move). Re-establish RBAC assignments. Verify Policy compliance in the target sub. Some resource types (AKS, Recovery Services Vault) do not support cross-subscription moves natively. | Low–Medium |
| Greenfield — new app | Run the decision flowchart before any IaC is written. Resist "start in shared and move later" for workloads that will clearly need Model B. Migration cost almost always exceeds the provisioning time saved. | Low (if planned) |
One thing I'm strict about: never use az account move to transfer a subscription between EA billing accounts as a substitute for the vending pipeline. This bypasses management group placement, breaks policy inheritance, and creates orphaned role assignments. All subscription creation goes through the vending pipeline.
Management Group × Model Placement
The full management group hierarchy design is covered in Management Group Hierarchy. This table focuses specifically on where each combination of model and workload type belongs.
| Target MG | Workload Characteristics | Compatible Models | Notes |
|---|---|---|---|
| Corp | Standard internal workloads, Private Endpoints only, hybrid-connected | Model A ✅ Model B ✅ | Default placement. Model A lands RG+Subnet here; Model B vends a dedicated sub placed here. |
| Online | Internet-facing apps, SaaS platforms, external APIs | Model A ✅ Model B ✅ | Allows Public IPs and Front Door integration. WAF enforcement at MG level. No on-prem route injection. |
| Corp › PCI-DSS | Cardholder data, payment processing | Model B only | Sub boundary defines CDE scope. Custom MG must exist before vending. |
| Corp › HIPAA | PHI, EHR/EMR systems, claims processing | Model B only | HITRUST/HIPAA initiative assigned at MG scope. All subs here inherit PHI controls. |
| Corp › SAP | SAP HANA, S/4HANA, Oracle on Azure | Model B only | SAP-specific VM SKU policies live here. Prevents M-series quota drain by non-SAP workloads. |
| Corp › Data | Data Lake, Databricks, Synapse, Fabric, ML Feature Stores | Model B only | Data governance and analytics networking isolation. Teams get subs via vending under this MG. |
| Sandbox | Dev/test, PoC, experimentation | Model A preferred | No hub connectivity, hard budget ceiling, loose policies. Fast provisioning trumps isolation. |
| Decommissioned | Subscriptions in wind-down | N/A | Deny-All policy prevents new resource creation. Billing continues until subscription is cancelled. |
The key constraint I enforce in the vending pipeline: target MG must be a mandatory dropdown field in the subscription request form, constrained to the approved set of MG options. The MG must be provisioned with its policy assignments before the first subscription is placed under it.
When to create a custom child management group
The test I use: would this set of subscriptions need a meaningfully different Azure Policy assignment that cannot be added to an existing parent MG without incorrectly affecting workloads that shouldn't inherit those policies?
That's a high bar. Most scenarios that look like they need a new MG actually need a new subscription (for workload isolation) or a policy assignment at subscription scope (for workload-specific controls). The scenarios that genuinely clear the bar:
- PCI-DSS CDE — strict egress, JIT access, and encryption policies that must not bleed into non-PCI workloads
- HIPAA / PHI — HITRUST/HIPAA initiative that should apply consistently across all PHI subscriptions without imposing healthcare controls on everything else
- SAP / Oracle ERP — specific VM SKU policies that prevent non-SAP teams from consuming M-series quota (justified when you have five or more SAP subscriptions)
- Enterprise Data Platform — Purview integration, analytics networking policies, and storage controls distinct from standard application policies
- IoT / OT — OT workloads need separate network segmentation from corporate IT by regulatory frameworks; dedicated MG enforces restrictions that must not inherit to standard Corp workloads
- FedRAMP / CMMC — these initiatives are entirely incompatible with non-government workloads sharing the same MG
What rarely clears the bar: business unit MGs (BUs need different RBAC and cost attribution, not different Policy postures), SDLC environment MGs (Dev/Test/Prod should share the same policy posture — CAF explicitly discourages this pattern), and per-platform-tool MGs (one Data MG with multiple subscriptions is always better than separate Databricks MG, Snowflake MG, etc.).
Quick Reference Matrix
| Scenario | Model A — Shared Sub | Model B — Sub Vending |
|---|---|---|
| Compliance: None / Standard | ✅ Recommended | Not required |
| Compliance: PCI · HIPAA · SOX · IL4+ | ❌ Not permitted | ✅ Mandatory |
| Team maturity: Small / low cloud ops | ✅ Recommended | ⚠️ Ops risk |
| Team maturity: Mature DevOps / Platform Eng | Acceptable | ✅ Recommended |
| Scale: Small–medium, predictable | ✅ Recommended | Optional |
| Scale: HPC / SAP / GPU / burst-heavy | ❌ Quota risk | ✅ Mandatory |
| External vendor / third-party Azure access | ❌ Not permitted | ✅ Mandatory |
| Cost: Tag-based chargeback acceptable | ✅ Recommended | Optional |
| Cost: Requires dedicated P&L split | ⚠️ Possible but complex | ✅ Recommended |
| Provisioning: Needed within 1–2 days | ✅ Achievable | ⚠️ Pipeline lead time |
| Environment: Dev / Test / PoC / Sandbox | ✅ Recommended | Overkill |
| Environment: Production, regulated | Context-dependent | ✅ Recommended |
| Workload: Technology Platform (AVD, VMware) | ❌ Not suitable | ✅ Mandatory |
| Modernisation roadmap within 18 months | ⚠️ Avoid — migration cost | ✅ Start here |
| Per-team or per-app management group | ❌ Anti-pattern | ❌ Anti-pattern |
| SDLC environment management groups | ❌ Anti-pattern | ❌ Anti-pattern |
One signal I use to check if the framework is working: if 70–80% of new workloads consistently land in Model B, either teams are selecting it for autonomy, or the shared subscription model isn't being served well by the platform team. Review the distribution quarterly.