Azure Resource Groups and Subscriptions, Explained Properly

Azure's organizational model trips up almost everyone coming from a single-account mental model. Two concepts do the heavy lifting: subscriptions and resource groups - and they solve different problems.

Subscription: the billing and hard-isolation boundary

A subscription is where billing, quotas, and the strongest access-control boundary live. Two subscriptions are, for most practical purposes, two separate environments - separate spending limits, separate default network isolation, separate blast radius if something goes wrong. Enterprises typically run multiple subscriptions on purpose: one per environment (dev/test/prod), one per business unit, or one per major project, precisely so a runaway cost or a misconfigured resource in one can't spill into another.

Resource group: the lifecycle boundary

A resource group is a logical container within a subscription - and the deliberate design idea is that everything in a resource group shares a lifecycle. If you'd delete everything in the group together (tear down a whole application's infrastructure at once, for instance), it belongs in the same resource group. If two resources have genuinely independent lifecycles - a shared logging workspace used by five different applications, for example - they usually don't belong in the same group as any one of those applications.

The mistake I see most often

Treating a resource group like a folder for "things I made this week" rather than a real lifecycle unit. That works fine until someone runs a cleanup script scoped to a resource group and takes out a shared resource nobody realized was in there. The fix is cheap: name resource groups after what they represent (rg-payments-prod, not rg-malik-test), and ask "would I delete all of this together?" before adding a new resource to an existing group.

How this maps to IAM

Azure RBAC role assignments can be scoped at the subscription level or the resource group level (or lower). Scoping access at the resource group level - rather than subscription-wide - is usually the right default: it gives a team exactly the blast radius their job requires, and no more.