Azure subscriptions are more than just billing containers; they’re fundamental organizational units that dictate resource deployment, access control, and cost management.
Let’s see how this plays out. Imagine you’re setting up a new project with a separate team. You’d create a new subscription for them. This isn’t just to give them their own bill; it’s because policies, role-based access control (RBAC), and resource locks are all applied at the subscription level. If a policy prevents specific virtual machine sizes, that restriction applies to all resources within that subscription. Similarly, if you grant a developer contributor access to Subscription A, they can deploy and manage anything there, but nothing in Subscription B.
Here’s a typical scenario: you have a "Development" subscription, a "Staging" subscription, and a "Production" subscription.
{
"subscriptionId": "12345678-abcd-efgh-1234-567890abcdef",
"displayName": "Development Environment",
"state": "Enabled",
"tenantId": "abcdef01-2345-6789-abcd-ef0123456789"
}
This JSON snippet represents a single Azure subscription. The subscriptionId is the unique identifier, displayName is what you see in the portal, state indicates if it’s active, and tenantId links it to your Azure Active Directory (now Microsoft Entra ID).
When you create a resource, say a virtual machine, it must be deployed into a subscription.
az vm create \
--resource-group MyDevResourceGroup \
--name MyDevVM \
--image Ubuntu2204 \
--subscription "12345678-abcd-efgh-1234-567890abcdef"
The --subscription flag here is crucial. Without it, the az CLI would default to whatever subscription is currently set in your active profile. This is where things can go wrong if you’re not careful – accidentally deploying a production-sized VM into your development subscription.
The core problem Azure subscriptions solve is providing a boundary for management and governance. You can have multiple subscriptions under a single "Management Group." Management Groups allow you to apply policies and RBAC at a higher level, inheriting down to all subscriptions within them. This is how large organizations manage thousands of subscriptions efficiently.
Consider a scenario where you need to enforce a company-wide policy that all virtual machines must have a specific tag for cost allocation. You can apply this policy to a Management Group that contains all your development and production subscriptions.
{
"properties": {
"displayName": "Enforce Cost Allocation Tag",
"policyType": "Custom",
"mode": "Indexed",
"description": "Requires the 'CostCenter' tag to be present on all virtual machines.",
"metadata": {
"version": "1.0.0",
"category": "Tags"
},
"parameters": {
"tagName": {
"type": "String",
"metadata": {
"displayName": "Tag Name",
"description": "Name of the tag to enforce"
},
"defaultValue": "CostCenter"
}
},
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
{
"field": "[concat('tags[', parameters('tagName'), ']')]",
"exists": "false"
}
]
},
"then": {
"effect": "deny"
}
}
}
}
This policy definition, when assigned to a management group or subscription, will prevent the creation of any virtual machine that doesn’t have the CostCenter tag.
The billing aspect is tied directly to subscriptions. Each subscription has an associated "Billing Scope," which is typically an Enterprise Agreement (EA) enrollment, a Pay-As-You-Go (PAYG) subscription, or a Microsoft Customer Agreement (MCA) invoice. Costs incurred by resources within a subscription are aggregated and billed to that scope. This allows for chargeback and showback scenarios within an organization.
Here’s the part that often trips people up: the "cost" of a subscription itself is usually zero. You don’t pay for the subscription object. You pay for the resources deployed within it. However, some specific resource types (like certain Azure Active Directory premium features or Azure Reserved Instances) might have associated costs that are tied directly to the subscription’s billing.
The actual levers you control are primarily within the "Subscription" blade in the Azure portal or via Azure CLI/PowerShell. You can:
- Create/Delete Subscriptions: Essential for isolating environments or teams.
- Manage Access (RBAC): Granting or revoking permissions at the subscription level.
- Apply Policies: Enforcing governance rules like allowed regions, VM sizes, or required tags.
- Set Resource Locks: Preventing accidental deletion or modification of critical resources.
- Monitor Costs: Viewing cost analysis and budgets per subscription.
- Transfer Ownership: Moving a subscription between different billing scopes or Azure AD tenants.
One key aspect often overlooked is that subscriptions are tied to an Azure AD (Microsoft Entra ID) tenant. While you can move subscriptions between tenants, it’s a complex operation and usually indicates a fundamental organizational change. Resources within a subscription are authenticated and authorized against the AAD tenant that owns the subscription. If you need to grant access to users from a different AAD tenant, you’ll typically use B2B collaboration features, not change the subscription’s home tenant.
The next logical step after mastering subscription management is understanding how to organize them for effective governance at scale, which leads to exploring Azure Management Groups.