Microsoft AZ-104: Subscription Design for Azure Estates
Azure subscriptions are more than billing containers. They are policy, RBAC, quota, deployment, lifecycle, and operational boundaries. Microsoft’s current landing-zone guidance treats subscriptions as foundational scale units and recommends “subscription democratization”: platform teams provide governed subscriptions to workload teams, and workload teams operate inside those guardrails. A scalable estate therefore needs subscription patterns that are easy to vend, place in management groups, budget, secure, and retire.
Subscription design should start with workload and operating-model boundaries rather than arbitrary resource counts. Environment separation, regulatory boundaries, product ownership, regional architecture, quotas, delegated administration, and lifecycle can all justify distinct subscriptions. Conversely, splitting every tiny component into its own subscription can create unnecessary overhead for networking, identity, billing, and policy.
Subscription architecture belongs inside Azure Architecture in Practice.
Use subscriptions as management boundaries
Current Cloud Adoption Framework guidance describes subscriptions as foundational units for organizing and managing Azure resources.
Azure landing zones should provide subscriptions with inherited governance and a clear owner rather than letting teams build in whichever shared subscription has space.
A subscription should be large enough to contain a coherent workload environment and small enough to keep access, policy, quota, and lifecycle understandable.
Separate major environments
Microsoft recommends separate subscriptions for application development environments in many landing-zone scenarios because this isolates policy, RBAC, quota, and failure impact.
Production and nonproduction often have different controls, budgets, support expectations, and administrators.
A single subscription can still be appropriate where environments cannot be separated or share tightly coupled services, but that should be an explicit exception.
Align ownership with subscription scope
The subscription owner should correspond to the team accountable for the workload and its cost.
Cost governance is easier when each subscription has clear product, business, environment, and operational ownership.
Shared platform subscriptions should have central owners; workload subscriptions should have delegated workload ownership within platform guardrails.
Place subscriptions through management groups
Management groups provide the inherited policy and access context around subscriptions.
Design subscription types together with the management-group archetypes that will receive them.
A self-service vending process should place the subscription into the correct branch automatically instead of leaving new subscriptions under the tenant root.
Use separate subscriptions for platform functions
Connectivity, identity, management, and security services often deserve dedicated platform subscriptions because they have different administrators, budgets, and blast radius from application workloads.
This separation also makes shared costs and privileged access easier to review.
Do not put application workloads in the same subscription merely because the central team already owns a firewall or Log Analytics workspace there.
Account for service and quota limits
Subscriptions are also quota and service-limit boundaries for many Azure services.
High-scale products may need additional subscriptions to distribute limits, deployment scale, or regional capacity.
Designing additional subscriptions after a quota becomes an outage risk is harder than planning scale units before the workload grows.
Use subscription vending as a product
A mature platform team can automate subscription creation, naming, tags, management-group placement, standard RBAC groups, budgets, Policy, monitoring, and network onboarding.
Landing-zone patterns demonstrate the value of returning an environment that is ready for compliant deployment instead of handing teams an empty subscription and a long checklist.
Measure vending time and adoption friction; slow provisioning encourages shadow Azure use.
Plan lifecycle and decommissioning
Subscriptions created for migrations, sandboxes, mergers, or temporary programs should have an owner and end state.
Decommissioning should remove workloads, preserve required data, close network and identity dependencies, reconcile commitments, and move or cancel the subscription under controlled governance.
Do not let empty subscriptions remain indefinitely with active role assignments, public IPs, or monitoring costs.
Keep billing hierarchy separate from technical hierarchy
Azure billing constructs and Microsoft Entra tenant/management-group hierarchy solve related but different problems.
Governance architecture should not distort subscription placement solely to make billing reports easier when Cost Management can report across billing scopes and tags.
For AZ-305, scalable subscription design is workload/environment boundary → owner → management-group placement → policy/RBAC → cost/quota → lifecycle automation.
Subscription design also affects incident blast radius. A compromised workload administrator in one subscription should not automatically gain equivalent access to unrelated applications. Separate scopes, groups, managed identities, and network permissions so a workload boundary has real security value.
Regional designs can use one subscription across regions or multiple subscriptions depending on ownership and operational needs. Do not create a subscription per region merely because resources are regional; create one where the region represents a distinct control, regulatory, lifecycle, or scale boundary.
Shared services should expose well-defined consumption patterns. Workload subscriptions can use central DNS, ExpressRoute, Firewall, logging, or identity without receiving broad Contributor access to the platform subscription that hosts them.
Review the subscription portfolio periodically. Mergers, product transfers, platform modernization, or retired workloads can leave subscriptions in the wrong management group with obsolete access. Estate hygiene is part of subscription architecture, not just account administration.
Subscription vending should be treated as an internal product with documented service levels. Teams should know what information they provide, how long provisioning takes, which policies and networks are included, and who owns the result. Fast, predictable vending reduces incentives to reuse unsuitable shared subscriptions.
Environment isolation is one of the strongest reasons to split subscriptions. Development teams can receive broader deployment autonomy in nonproduction while production remains more tightly governed. Budget alerts, Defender settings, policy effects, and privileged access can differ without complicated resource-level exceptions.
Regulated workloads may require dedicated subscriptions for data residency, encryption ownership, logging, or compliance controls. The subscription can then sit in a management-group branch that inherits the appropriate initiatives and access model.
Shared services should be consumed through explicit interfaces rather than through broad cross-subscription Contributor access. Central DNS, network hubs, firewalls, Key Vaults, or monitoring services can expose the minimum permissions workload teams need, preserving platform ownership.
Quota planning matters during migrations and rapid growth. Large estates can hit subscription-level quotas for compute, networking, public IPs, or managed services. A subscription pattern should let the organization add another scale unit without redesigning governance.
Cost ownership should be decided before resources arrive. The subscription should have business owner, technical owner, cost center, and environment metadata from day one. Retrofitting accountability after months of shared spend is difficult and often politically contentious.
Subscription moves between tenants are a different problem from moves between management groups. Tenant changes can affect identity, RBAC, managed identities, Key Vault, and service integrations. Treat tenant migration as a major architecture project, not a routine resource-organization change.
Sandbox subscriptions should be isolated enough to permit experimentation without weakening production controls. Apply budget limits, limited connectivity, expiration, and data restrictions so “sandbox” does not become a permanent ungoverned production environment.
Subscription decommissioning should include role cleanup, network detachment, private DNS, policy exemptions, budgets, reservations, monitoring, backup retention, and data preservation. Closing the billing object is the final step, not the first.
The subscription portfolio should be reviewed periodically for orphans, empty subscriptions, duplicate functions, and mismatched ownership. A scalable Azure estate is continuously curated rather than allowed to accumulate subscriptions indefinitely.
Network topology can influence subscription boundaries. A connectivity subscription can centralize Virtual WAN, ExpressRoute, VPN, Firewall, and DNS while workload subscriptions consume those services through peering and delegated interfaces. This preserves clear ownership without requiring every workload to operate its own hub.
Security tooling often benefits from a dedicated platform subscription as well. Sentinel, Defender configuration, automation, or shared logging can be centrally owned while still ingesting or governing workload-subscription data through supported cross-subscription patterns.
Policy assignments and exemptions should follow the subscription lifecycle. When a workload moves from sandbox to production or from acquisition quarantine into the normal estate, update the policy archetype rather than piling more exceptions onto the old subscription context.
Subscription naming should be human-readable but not overloaded with every attribute. Use stable naming plus tags or inventory metadata for owner, cost center, environment, and lifecycle so a rename is not required every time the business changes.
A strong subscription architecture makes scaling routine: new workloads receive isolated, governed landing zones quickly, shared services remain centrally operated, and the hierarchy can grow without giving one team administrative control over unrelated estates.
Subscription design should include identity administration. Workload teams can receive role-assignment authority inside their subscription while platform policy remains protected at the management-group layer. This supports workload autonomy without letting application administrators rewrite enterprise governance.
Cross-subscription dependencies should be documented. A workload can reside in its own subscription while depending on central DNS, networking, logging, secrets, or private endpoints. Service ownership and support paths need to cross that boundary cleanly during incidents.
Budgets should be created at subscription provisioning so cost visibility exists from the first resource. Forecast alerts can catch an unexpected large deployment before finance receives a monthly invoice.
For migrations, create target subscriptions early enough to validate quotas, RBAC, policy, networking, and observability before moving production data. Subscription design should be part of migration planning, not an administrative task left until cutover week.
Reviewing the estate as a portfolio lets platform teams retire stale subscriptions, consolidate unnecessary ones, and split overloaded ones before governance or quota pressure becomes an outage.