What is a resource group, really?
Not a folder, not a billing bucket, not a security boundary — although it brushes against all three. A resource group is a lifecycle boundary, and once that clicks, half of Azure's organizational rules stop feeling arbitrary.
Almost everyone meets resource groups the same way: you go to create your first VM, Azure demands a resource group before it will let you continue, so you type my-rg, shrug, and move on. That shrug is the problem. The resource group is one of the few organizing ideas you cannot opt out of in Azure — every resource must live in exactly one — so it pays to actually understand what it is for rather than treating it as a required text box.
The definition, and the word that matters
Microsoft defines it plainly: "A resource group is a container that holds related resources for an Azure solution." True, but "container" is where people stop, and stopping there makes it sound like a folder. Keep reading to the sentence that carries the real meaning: "Generally, add resources sharing the same lifecycle to the same resource group so you can easily deploy, update, and delete them as a group."
There it is — lifecycle. The right question when deciding where a resource goes is not "what type of thing is this?" but "does this get created and destroyed together with those other things?" A web app, its App Service plan, its database, and its storage account are one application; they are born together and they should die together. That shared fate is what a resource group expresses.
Group by what dies together, not by what looks alike.
Why lifecycle is the whole point: delete
The clearest way to feel this is the delete button. Deleting a resource group deletes everything inside it, in the right order, in one action. That is not a footnote — it is the feature. Spin up an entire environment for a demo, a test, or a short-lived experiment, put it all in one resource group, and when you are done, delete the group and the whole thing evaporates with no orphaned disks quietly billing you for months.
This is also why "group by lifecycle" is not just tidiness advice. If you dump a long-lived production database into the same resource group as throwaway test resources, you have wired a permanent thing and a disposable thing to the same kill switch. The day someone cleans up the test junk by deleting the group, the database goes with it. Group by what dies together, and that accident becomes impossible.
What it is not
Half of understanding resource groups is clearing away what they are commonly mistaken for:
- Not a billing boundary. Billing rolls up to the subscription. You can slice a cost report by resource group, but the group is not what you pay against — tags and subscriptions do the real cost-allocation work.
- Not a hard security boundary. You can assign RBAC roles at the resource-group scope, and that is genuinely useful — a role granted there is inherited by everything inside. But the true isolation boundary in Azure is the subscription. Treat the resource group as a convenient place to apply access, not as a wall between tenants or environments.
- Not a region lock. This one surprises people: the resources inside a group can live in different regions. So what is the group's own location for? It is where Azure stores the group's metadata — the record of what is in it. Your VM can be in West Europe while its resource group's metadata sits in East US, and that is fine.
A resource belongs to exactly one resource group at a time. You can move resources between groups, but not all resource types support it, and a move is a real operation rather than a rename. Both rules feel less arbitrary once you see the group as a lifecycle unit: a thing can only share one "born and die together" story at a time.
A practical way to draw the lines
You do not need a grand taxonomy. A few honest questions do the job:
- Deploy together? If a set of resources ships as one infrastructure-as-code template, that template's output is a natural resource group.
- Delete together? If tearing down the app should take all of it, they belong together. If one piece must outlive the rest, it belongs elsewhere.
- Same environment and owner? Keep
prodanddevin separate groups even for the same app, so their lifecycles — and their blast radii — stay independent.
Do that and your groups start reading like sentences: this app, this environment, this lifecycle. The console stops looking like a junk drawer, your infrastructure-as-code maps cleanly onto real boundaries, and the scary delete button becomes a precise tool instead of a landmine. Not bad for the text box everyone used to shrug past.