Microsoft Azure — Subscriptions & Resource Groups

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers subscriptions & resource groups with production-ready configurations, best practices, and hands-on examples.

Why Azure Subscriptions Matter

Azure Subscriptions are the fundamental billing and access control boundary in Microsoft Azure. Each subscription represents a logical container for resources, with its own limits, quotas, and policies. Think of a subscription as a sandbox: you can have multiple subscriptions for different environments (dev, test, prod), departments, or cost centers. Without proper subscription design, you risk cost overruns, security breaches, and management chaos. For example, a single subscription can host up to 980 resource groups per region, but hitting that limit unexpectedly can block deployments. Always plan your subscription hierarchy using management groups to enforce governance at scale.

az account list --output table

Resource Groups: The Logical Container

Resource Groups are containers that hold related resources for an Azure solution. They share the same lifecycle, permissions, and policies. A resource group can contain resources from multiple regions, but it's best practice to colocate resources that share a common lifecycle. For example, a web app, its database, and storage account should be in the same resource group so you can deploy, update, and delete them together. Resource groups are not hierarchical; you cannot nest them. Each resource must belong to exactly one resource group, and moving resources between groups is possible but can cause downtime if not done carefully.

az group create --name prod-web-rg --location eastus

Subscription vs Resource Group: Hierarchy and Scope

Understanding the hierarchy is crucial: Management Group > Subscription > Resource Group > Resource. Subscriptions are the billing boundary, while resource groups are the management boundary. Policies and RBAC can be applied at any level, but they flow downward. For example, a policy applied at the subscription level affects all resource groups and resources within it. Resource groups cannot span subscriptions. When designing, consider that moving a resource between resource groups is allowed, but moving a resource group between subscriptions is not directly supported—you must move each resource individually. This has implications for reorganization and cost allocation.

az resource move --destination-group prod-db-rg \
  --ids /subscriptions/.../resourceGroups/prod-web-rg/providers/Microsoft.Sql/servers/mydb

Organizing Subscriptions for Production

For production workloads, use a hub-spoke subscription model. Create a 'connectivity' subscription for shared networking (VPN, ExpressRoute, firewall) and separate 'workload' subscriptions for each application or environment. This isolates blast radius: a misconfiguration in one workload doesn't affect others. Use Azure Policy to enforce tagging, region restrictions, and allowed SKUs across subscriptions. For example, require all resources to have a 'CostCenter' tag. This enables chargeback and cost analysis. Also, consider using Azure Blueprints to define a repeatable set of policies and resource groups for new subscriptions.

az policy assignment create --name 'require-costcenter-tag' \
  --policy /providers/Microsoft.Authorization/policyDefinitions/... \
  --scope /subscriptions/1234-5678-90ab-cdef \
  --params '{"tagName":{"value":"CostCenter"}}'

Resource Group Design Patterns

There are two common patterns: (1) Resource group per application component (e.g., web-rg, db-rg, cache-rg) and (2) Resource group per environment (e.g., prod-rg, staging-rg, dev-rg). The first pattern is better for microservices where each component has independent lifecycle. The second is simpler for monolithic apps. A hybrid approach is also common: use environment-level resource groups for shared infrastructure (networking, monitoring) and component-level groups for application services. Always use tags to add metadata like environment, owner, and cost center. This enables filtering and automation.

az group update --name prod-web-rg --tags Environment=Prod Owner=team-web CostCenter=12345

RBAC and Subscriptions/Resource Groups

Azure RBAC allows you to grant granular permissions at subscription or resource group scope. Common roles include Owner, Contributor, and Reader. For production, follow the principle of least privilege: assign Contributor at the resource group level, not subscription. Use custom roles for specific needs, like 'VM Operator' that can start/stop VMs but not delete them. Avoid assigning roles to individuals; use Azure AD groups instead. This simplifies management when team members change. Also, use Azure Privileged Identity Management (PIM) for just-in-time access to critical subscriptions.

az role assignment create --assignee 'team-web@contoso.com' \
  --role 'Contributor' \
  --scope /subscriptions/1234-5678-90ab-cdef/resourceGroups/prod-web-rg

Cost Management Across Subscriptions

Azure Cost Management provides tools to analyze and optimize spending across subscriptions. Use budgets and alerts to get notified when spending exceeds thresholds. Tag resources with cost center and environment to enable chargeback. For multi-subscription environments, use Azure Cost Management views that aggregate costs across subscriptions. Consider using Azure Reservations and Savings Plans for predictable workloads, but apply them at the management group scope to share benefits across subscriptions. Regularly review underutilized resources and use Azure Advisor recommendations to right-size VMs and databases.

az consumption budget create --budget-name 'prod-monthly' \
  --amount 10000 \
  --time-grain Monthly \
  --time-period start-date=2026-01-01 end-date=2026-12-31 \
  --scope /subscriptions/1234-5678-90ab-cdef \
  --notifications '{"thresholdType":"Actual","threshold":80,"enabled":true,"contactEmails":["finance@contoso.com"]}'

Automating Subscription and Resource Group Creation

For large organizations, manual creation of subscriptions and resource groups is error-prone and slow. Use Azure Blueprints or Terraform to define a standard set of resources, policies, and RBAC. For example, a blueprint can create a resource group with required tags, assign a policy to enforce encryption, and grant Contributor access to a team. Use Azure CLI or PowerShell in CI/CD pipelines to create subscriptions programmatically (requires appropriate permissions). Always use infrastructure as code (IaC) to ensure consistency and auditability. Store IaC in a version-controlled repository.

resource "azurerm_resource_group" "example" {
  name     = "prod-web-rg"
  location = "East US"
  tags = {
    Environment = "Production"
    CostCenter  = "12345"
  }
}

resource "azurerm_virtual_network" "example" {
  name                = "prod-web-vnet"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  address_space       = ["10.0.0.0/16"]
}

Monitoring and Auditing Subscriptions and Resource Groups

Use Azure Monitor and Azure Activity Log to track changes to subscriptions and resource groups. Set up alerts for critical events like resource deletion, role assignment changes, or policy violations. Use Azure Policy's 'audit' effect to log non-compliant resources without blocking them. For security, enable Azure Defender for Cloud to get recommendations and threat detection across subscriptions. Regularly review the Activity Log for suspicious activities. Export logs to Log Analytics or a SIEM for long-term retention and analysis.

az monitor activity-log alert create --name 'delete-resource-group' \
  --resource-group prod-monitoring-rg \
  --condition category=Administrative operationName=Microsoft.Resources/subscriptions/resourceGroups/delete \
  --action-groups /subscriptions/.../resourceGroups/prod-monitoring-rg/providers/microsoft.insights/actionGroups/ops-team

Disaster Recovery and Subscription Design

For disaster recovery, consider using paired regions (e.g., East US and West US). Design your subscription and resource group structure to support failover. For example, have a secondary subscription in the paired region with identical resource groups and resources. Use Azure Site Recovery to replicate VMs and databases. Test failover regularly. Also, consider using Azure Policy to enforce that critical resources have backups enabled. For multi-region deployments, use Azure Traffic Manager or Front Door to route traffic. Ensure that your subscription limits (e.g., vCPU quotas) are sufficient in the secondary region.

az vm list-usage --location eastus --output table

Common Pitfalls and How to Avoid Them

Common mistakes include: (1) Using a single subscription for everything, leading to hitting limits and security issues. (2) Not using resource groups, or putting all resources in one group, making management impossible. (3) Assigning Owner role at subscription scope to individuals. (4) Not tagging resources, making cost analysis difficult. (5) Ignoring policy enforcement until after deployment. To avoid these, start with a clear subscription and resource group design, enforce policies early, use IaC, and regularly audit your environment. Also, avoid moving resources between groups/subscriptions unless absolutely necessary.

az group list --query "[?tags.Environment==null].{Name:name, Location:location}" --output table

Next Steps: From Beginner to Production-Ready

Now that you understand subscriptions and resource groups, start by auditing your current Azure environment. Identify unused subscriptions and resource groups. Implement a naming convention and tagging strategy. Use Azure Policy to enforce compliance. Automate creation with Terraform or Bicep. Set up cost management and monitoring. Finally, document your subscription and resource group design in a runbook. This will save your team countless hours of troubleshooting and prevent costly mistakes. Remember, good architecture is proactive, not reactive.

az group export --name prod-web-rg --include-parameter-default-value > rg-template.json