Azure subscription vs AWS account vs GCP project
All three are a billing boundary, so every cheat sheet lines them up in one neat row. That row is the single most misleading line in cloud.
New to cloud? CAMPUX is a free, build-first course. Start here →
An Azure subscription, an AWS account, and a GCP project are all the billing-and-quota boundary — the unit the bill and the API limits attach to, holding your resources and a payment method. That much maps. What doesn't map is how you use them: an Azure subscription is roomy and you run a few; an AWS account is a hard isolation boundary so mature teams run many; and a GCP project bills like a subscription but behaves like an Azure resource group, so companies run dozens. Match on the role, never on the count — that's the mistake that makes people build the wrong shape.
This is the first thing you meet on any cloud and the first thing the cheat sheets get wrong. They see "billing boundary" three times and draw one equals-sign. Then someone comes from Azure, spins up a single AWS account for their whole company the way they'd use one subscription, and six months later is untangling a blast radius nightmare because everything shares one wall. Let's get the mapping honest.
What each one actually is
Same job description on all three — a container that carries a bill, enforces quotas, and holds resources. The differences are in temperament.
Azure subscription
A subscription lives inside a Microsoft Entra tenant (your identity home) and holds resource groups, which hold the actual resources. It's a soft boundary: you can create several, group them under management groups, and identity is shared above them at the tenant. Companies typically run a small number — production, non-production, maybe one per department — because the resource group underneath does the fine-grained containing. A subscription is a floor of a building, not a room.
AWS account
An account is the heavyweight of the three. It's the strong isolation boundary on AWS — the default is that nothing crosses an account line without an explicit cross-account role — so the account is your blast radius. That strength is exactly why the modern AWS pattern is many accounts: one per team, per environment, per app, all rolled up under a single AWS Organization for billing and policy. An AWS account is closer to an entire Azure subscription plus its own identity walls. You make lots of them on purpose.
GCP project
Here's the one that breaks the row. A project is the billing and quota unit — so by the bill, it's a subscription. But in workflow it's the small container you drop one app or one environment into, IAM is set per project, and you spin them up freely. That's an Azure resource group, not a subscription. A company runs dozens or hundreds of projects, organized under folders. A GCP project is a subscription on the invoice and a resource group on the whiteboard.
| Trait | Azure subscription | AWS account | GCP project |
|---|---|---|---|
| Primary role | Billing + quota boundary | Billing + quota + strong isolation | Billing + quota boundary |
| Behaves day-to-day like | A floor (holds resource groups) | A whole building with locked doors | A room (holds one app/env) |
| Typical count per company | A few to a few dozen | Many (one per team/env) | Many (one per app/env) |
| Where identity lives | Above it, in the Entra tenant | Inside the account (+ Identity Center) | Above it, in the organization |
| Grouped under | Management groups | Organization + OUs | Organization + folders |
| Isolation strength | Soft (RBAC does the walls) | Hard (the default wall) | Medium (per-project IAM) |
A GCP project is a subscription on the invoice and a resource group on the whiteboard. Map it wrong and you'll build a tenth as many as you need.
Why the scale differs — and why you should care
The count isn't a stylistic quirk; it falls straight out of where each cloud puts its hard wall. AWS makes the account the isolation boundary, so to isolate two things — prod from dev, team A from team B — you give them separate accounts. Isolation demand drives account count up. Azure puts identity above the subscription and does fine-grained isolation with RBAC at resource-group scope, so you need fewer subscriptions. GCP splits the difference: cheap projects, per-project IAM, so you make one per workload.
Why care as a learner? Because the interview question isn't "what's the AWS equivalent of a subscription" — it's "how would you structure accounts for a company with three teams and two environments." Answer that with the right granularity and you sound like someone who's done it. Answer "one account, tag everything" and you don't.
Billing boundary is the only trait all three share. Don't carry any other assumption across the equals-sign: not the count, not the isolation strength, not where identity sits, not how big a thing you put inside one. If you're coming from Azure, the trap is treating an AWS account like a subscription (too few, too shared). If you're coming from AWS, the trap is treating a GCP project like an account (you'll under-provision projects). Map the role, re-learn the usage.
How they nest
Each boundary sits in a hierarchy, and the hierarchies rhyme even when the middle layer doesn't. Top to bottom:
- Azure: Tenant → management groups → subscription → resource group → resource.
- AWS: Organization → OUs → account → (tags, no native group) → resource.
- GCP: Organization → folders → project → resource.
Notice GCP has no layer between project and resource — because the project is the resource group. And AWS has no layer between account and resource at all, which is its own gotcha. The billing boundary sits one rung higher in the tree on Azure and AWS than it does in your mental model of GCP.
So how should you actually structure them?
Same principle on all three, different mechanics: separate by blast radius and by who pays. Production away from non-production so a dev mistake can't touch customers; teams or business units apart so cost is attributable and access is clean. On Azure that's a few subscriptions under management groups; on AWS it's many accounts under an organization; on GCP it's many projects under folders. The instinct — isolate what shouldn't share a fate or a bill — is identical. Only the size of the box you reach for changes.
If you're learning this for the first time, do it on Azure, where the subscription-and-resource-group split makes the two jobs (billing boundary vs resource container) visible as two separate things. Once you've felt that split, GCP collapsing them into the project and AWS dropping the container entirely both make immediate sense. That's the order we teach it in the subscriptions and groups class.
Common questions
Is an Azure subscription the same as an AWS account?
They play the same role — a billing and quota boundary that holds resources and attaches a payment method — so they're the closest match. But they're not used the same way. An Azure subscription is a soft boundary you can spin up freely, and one tenant commonly holds several. An AWS account is a harder security and blast-radius boundary, so mature organizations run many accounts under a single AWS Organization, one per team or environment. Same role, very different granularity.
Is a GCP project the same as an Azure subscription?
Only for billing. A GCP project is the billing and quota unit like a subscription, but in day-to-day use it behaves like an Azure resource group: it's the small container you drop one app or environment into, and companies run dozens or hundreds of them. So a GCP project is a subscription by the bill and a resource group by the workflow. Mapping it 1:1 to a subscription will make you build far too few of them.
How many subscriptions or accounts should a company have?
There's no fixed number, but the pattern is consistent: separate production from non-production, and separate teams or business units, so blast radius and billing are clean. On Azure that's a few subscriptions grouped under management groups; on AWS it's many accounts under an organization with organizational units; on GCP it's many projects under folders. The driver is isolation and cost attribution, not resource count.
Which is the security boundary — subscription, account, or project?
On AWS the account is the strong isolation boundary; crossing accounts requires explicit cross-account roles, which is why teams use many accounts. On Azure the subscription is a boundary but identity lives above it in the Entra tenant, so it's a softer line. On GCP the project is the isolation unit and IAM is set per project. If you want a hard wall, AWS gives it at the account and GCP at the project; on Azure you lean on RBAC scopes and separate subscriptions together.