Resource group vs GCP project vs AWS tags

Azure gives you a folder to drop your app into. GCP gives you the same thing under another name. AWS gives you nothing — and that missing box is where people get hurt.

New to cloud? CAMPUX is a free, build-first course. Start here →

An Azure resource group is a real container: every resource lives in exactly one, and you deploy, tag, apply RBAC, lock, and delete at that level. A GCP project does the same job in workflow. AWS has no native container — its "Resource Groups" feature is only a saved tag query, so nothing lives inside it and deleting it deletes nothing. On AWS you group with a tagging discipline plus a deployment stack. Match on the role, and know that AWS is the odd one out.

This is the second big leak in the cloud translation guide, and it's the one that quietly costs people the most. The billing boundary at least has a match on every cloud. The resource container doesn't. Two of the three clouds hand you a box to put an app in; the third asks you to invent one out of naming conventions. Cross over without noticing and your cost reports, your teardown story, and your access model all come out wrong.

What each one actually is

The job here is grouping — a place that says "these resources belong together, treat them as a unit." Azure and GCP give you a first-class object for it. AWS gives you a practice.

Azure resource group

The resource group is a hard container. Every resource you create lands in exactly one of them, and it can't live in zero or two. That single fact does a lot of work: you assign RBAC roles at the group scope, put a delete-lock on the group, report cost by group, and — the big one — delete the group and everything inside it goes with it. That's how teams tear down a whole environment in one action. A resource group is a folder with real walls.

GCP project

A GCP project gets you the same effect. It is the resource container: you drop one app or one environment into a project, IAM is set on the project, and deleting the project deletes everything in it. In day-to-day workflow that's an Azure resource group, near enough to swap the words. The only wrinkle is that a project also bills and sets quota like an Azure subscription, so it wears two hats at once — a nuance worth reading in the subscription vs account vs project breakdown. For the container question specifically, project maps to resource group.

AWS — the odd one out

AWS has no folder for your app. There is a feature literally named AWS Resource Groups, and it fools everyone coming from Azure, because it is not a container: it's a saved query over tags. Nothing lives inside it. Deleting it deletes none of your resources. So the AWS way to group is two things working together: (a) a disciplined tagging strategy — every resource stamped with app, env, owner, cost-center — and (b) optionally a CloudFormation or Terraform stack, which groups resources by deployment lifecycle so you can create and tear them down together. Accounts are the coarse grouping; tags are the fine grouping. There is no middle "folder for my app."

Two clouds give you a box. The third gives you a labelling habit and calls it a feature. That's the whole leak.

The leak — and it bites both directions

This one hurts whichever cloud you start from, which is what makes it worth a whole spoke.

Coming from Azure to AWS: you go looking for the folder to drop your app into and there isn't one. If you don't notice, you build an account with a thousand resources and no consistent grouping, and you can't answer "how much does this app cost" or "tear this environment down" without a spreadsheet and a prayer. The fix is to decide your tagging schema on day one and enforce it, and to let stacks own the delete story. A convention replaces the container — but only if you actually keep the convention.

Coming from AWS to Azure: you're used to grouping by tag, so you treat the resource group as a formality and dump everything into one big group. Now RBAC can't be scoped tightly, a delete-lock protects too much or too little, and one careless delete on the group takes down more than you meant. On Azure the resource group is the unit of blast radius — use it like one.

And yes, Azure has tags too

To be fair to the comparison: Azure has tags as well, and they're separate from resource groups. A tag is a key-value label you stick on a resource or a group, mostly for cost reporting and filtering, and a resource keeps its tags no matter which group holds it. So on Azure you get both — the resource group is the container, tags are the metadata layered on top. The point isn't that Azure lacks tags; it's that the container is the resource group. On AWS, with no container, tags are pressed into doing both jobs at once, which is why an AWS tagging strategy has to be so much more disciplined than an Azure one.

So how should you actually group things?

Same instinct on all three — put together what shares a fate, a bill, and an owner — but different mechanics. On Azure, make a resource group per app-and-environment and scope RBAC there; that's what we do in the subscriptions and groups class. On GCP, that same unit is a project. On AWS, write the tag schema first, apply it to everything, and let a CloudFormation or Terraform stack own each deployable unit so create and destroy stay clean. Cost people will thank you either way — this is the exact discipline that makes cost management and FinOps possible instead of guesswork.

If you're learning this for the first time, do it on Azure, where the container is a visible object you can click, create, and delete. Once the resource group is muscle memory, GCP's project reads across in a sentence and AWS's missing container makes sense as the thing you have to build yourself. That's the order we teach it — concepts first, from what the cloud even is onward.

Common questions