Azure Subscriptions and Management Groups

An Azure subscription is a logical container that holds your Azure resources—like virtual machines, databases, and storage accounts. Think of it as a billing boundary: each subscription has its own payment method, spending limits, and cost reports. But it's also an access boundary: you can assign different administrators to different subscriptions. For example, a company might have a 'Development' subscription for dev/test workloads and a 'Production' subscription for live applications. This separation ensures that changes in dev don't affect prod, and costs are tracked separately.

When you sign up for Azure, you create at least one subscription. Each subscription is associated with an Azure account (a Microsoft Entra ID tenant). The subscription defines: - Billing: You pay for all resources in the subscription under one invoice. - Access: RBAC roles assigned at the subscription level apply to all resources inside. - Limits: There are subscription-level quotas (e.g., max 25 VM cores per region). - Offer type: Different offers (Pay-As-You-Go, Free Trial, Enterprise Agreement) have different pricing and features.

You can have multiple subscriptions under one account. For instance, a startup might use a Free Trial subscription for learning, then create a Pay-As-You-Go subscription for production. Each subscription can have its own administrators and policies.

Management groups are containers that help you manage access, policy, and compliance across multiple subscriptions. They form a tree structure: you can have a root management group (assigned to your Entra ID tenant) and nest other management groups under it. For example:

Root (Tenant Root Group)
├── Production
│   ├── Prod-Subscription-1
│   └── Prod-Subscription-2
├── Development
│   ├── Dev-Subscription-1
│   └── Dev-Subscription-2
└── Sandbox
    └── Sandbox-Subscription-1

Management groups work by inheritance. Any RBAC role assignment or Azure Policy assignment made at a management group automatically applies to all subscriptions and resources under it. For example, if you assign the 'Reader' role to a security team at the 'Production' management group, they can read all resources in Prod-Subscription-1 and Prod-Subscription-2. Similarly, a policy that restricts allowed VM sizes at the root group applies to all subscriptions.

Management groups are free. Subscriptions have no cost for the container itself, but you pay for the resources inside. Different subscription offers have different pricing models (e.g., Pay-As-You-Go vs. Reserved Instances).

In on-premises, you might have separate departments with their own budgets and servers. Subscriptions are like those department budgets—each has its own cost center. Management groups are like the corporate hierarchy that lets you apply company-wide policies (e.g., all servers must use encryption) without configuring each department individually.

Portal:

CLI:

# List subscriptions
az account list --output table

# Create a management group
az account management-group create --name "Production" --display-name "Production"

# Add subscription to management group
az account management-group subscription add --name "Production" --subscription "sub-id"

PowerShell:

# Get subscriptions
Get-AzSubscription

# Create management group
New-AzManagementGroup -GroupName "Production" -DisplayName "Production"

# Add subscription
New-AzManagementGroupSubscription -GroupName "Production" -SubscriptionId "sub-id"

Scenario 1: Cost Tracking A company wants to track costs by department. They create one subscription per department (e.g., Marketing, Engineering, Sales). Each subscription has its own budget alert. Management groups are used to group subscriptions by division (e.g., 'Americas' contains all US subscriptions). This allows the CFO to view total cost per division.

Scenario 2: Policy Enforcement An enterprise must ensure all resources are in a specific region (e.g., US East). They create a policy at the root management group that restricts allowed locations. All subscriptions inherit this policy, so no resource can be created outside US East. If a new subscription is added, it automatically gets the policy.

Scenario 3: Access Control A company has a central IT team that needs read-only access to all subscriptions. Instead of assigning the 'Reader' role to each subscription, they assign it at the root management group. Now the team can see all resources across the entire organization.

Scenario 1: Multi-National Corporation with Regional Compliance A global company must comply with GDPR in Europe and CCPA in California. They create a management group hierarchy: Root > Regions > Departments. Under the 'Europe' management group, they assign a policy that restricts data residency to European regions. Under the 'Americas' management group, they assign a policy that restricts data to US regions. Each regional management group contains subscriptions for departments like HR, Finance, and IT. When a new subscription is created for a new European subsidiary, it is placed under the 'Europe' management group and automatically inherits the data residency policy. The company saves thousands of hours by not manually configuring each subscription. If they had skipped management groups, they would have had to assign policies to each subscription individually—a nightmare at scale.

Scenario 2: Startup with Cost Optimization A startup uses separate subscriptions for development, testing, and production. They create a 'Development' management group containing Dev and Test subscriptions, and a 'Production' management group containing Prod subscriptions. They assign a policy at the 'Development' group that prevents using expensive VM sizes (e.g., anything larger than Standard_D4s_v3). This keeps dev costs low. The production group has no such restriction. They also assign the 'Contributor' role to developers at the 'Development' group so they can create resources freely, but only 'Reader' access to production. This setup ensures developers cannot accidentally modify production resources. When the startup grows, they can easily add more subscriptions under the same management groups.

What Goes Wrong When Set Up Incorrectly - Too deep hierarchy: If you create 6 levels of management groups, policy evaluation can become complex and slow. Also, RBAC assignments at deep levels are harder to troubleshoot. - Inherited policy blocks operations: If you assign a policy at root that denies all resources in a region, and then create a subscription that needs that region, you must either exclude the subscription from the policy or modify the policy. This can cause deployment failures. - Accidental root-level Owner: Assigning 'Owner' at the root management group gives that user full control over all subscriptions, including billing and deletion. If a disgruntled employee gets this role, they could delete everything. Always use the principle of least privilege.