Our existing subscriptions contain non-server workloads deployed by the DevOps team. That team does not want to deploy or support virtual machines, so they would prefer the server team to own that responsibility. I'm considering creating a separate server-focused subscription for each environment, with access limited to the server team and its deployment pipelines, rather than placing VMs in the same subscriptions as application workloads. Has anyone used this model, and what are the advantages or drawbacks compared with handling the separation through management groups, RBAC, and resource groups?
5 Answers
You may not need separate subscriptions just because different teams support different resource types. Keep the subscriptions aligned to workload boundaries, then use management-group inheritance and RBAC to give the server team the permissions it needs, such as VM management and login roles. This preserves least privilege without creating a large collection of narrowly specialized subscriptions.
Another workable pattern is to make deployments pipeline-controlled. Teams get access to the appropriate repositories and self-service workflows, while only pipeline identities can modify infrastructure. Portal access can be limited to a small group through just-in-time elevation. Whether the resources live in a dedicated subscription or resource group, ownership and lifecycle rules should be expressed in code and reviewed through pull requests.
There’s no rule that says subscriptions must be divided only by application. A dedicated subscription can be reasonable when it provides a clear security, billing, ownership, or lifecycle boundary. Just be aware that each subscription has quotas for certain VM SKUs and related services, so check those limits and request increases if necessary. Management groups and RBAC can also provide separation without moving everything into separate subscriptions.
A hybrid model often works best. Use application subscriptions for workloads with clear ownership and independent lifecycles, while allowing team-owned subscriptions for general-purpose operational use cases. Even then, a substantial or cloud-native workload should usually get its own subscription instead of being placed beside unrelated resources. The important part is that the subscription has a clearly accountable owner for support, security, and billing.
A common approach is to organize subscriptions around applications and environments rather than resource types. If an application uses both VMs and containers, they stay together because the team responsible for the application supports the entire workload. Separating every VM into a server subscription can mix unrelated lifecycles and make ownership, security, and management more complicated.
That makes sense for cloud-native applications. I’m mainly wondering whether a separate subscription is more practical for lift-and-shift servers or very small workloads that don’t have a broader application boundary.