Why start with the hierarchy?
When you hear "just put it in another project" from a Google Cloud team, an AWS person tends to hear "another account" and an Azure person "another subscription". Both are close, but not the same. Before we compare individual services, you need the containers that services live in. Billing, permissions, quotas and policy all attach to these containers. Get the mapping wrong and the service tables in later levels will mislead you.
This level covers three things: the resource hierarchy, how you pay, and how to read the dated tables that make up the rest of the course.
The Google Cloud resource hierarchy
Google Cloud has three kinds of container, plus the resources inside them:
Organization (root node, tied to your company's domain / Cloud Identity)
├── Folder: Finance (optional; can hold projects and sub-folders)
│ ├── Project: fin-reporting-prod
│ │ └── Resources: VMs, buckets, datasets...
│ └── Project: fin-reporting-dev
└── Folder: Platform
└── Folder: Shared
└── Project: net-hub-prod
Cloud Billing account (sits beside the tree, not inside it)
└── linked to: fin-reporting-prod, fin-reporting-dev, net-hub-prod
Rules to remember:
- Every resource belongs to exactly one project. The project is where you enable APIs, where most quotas apply and where you draw your main isolation boundary.
- Folders are optional and can be nested. Use them for departments, legal entities or environments.
- Policies inherit downward. An IAM grant or organisation policy set on the organisation or a folder flows down to every project beneath it.
- Billing is a separate object. A Cloud Billing account can pay for many projects, but each project links to only one billing account at a time. A project with no active billing account can't use Google Cloud services, even free ones.
Gotcha: On AWS, the account is both the billing unit and the isolation boundary. Google Cloud separates the two. Moving a project to a different billing account changes who pays for it, not where it sits in the hierarchy.
Side by side with AWS and Azure
Table checked October 2026. Rows marked (judgement) are approximate matches, not exact ones.
| Job | Google Cloud | AWS | Azure |
|---|---|---|---|
| Root of the estate | Organization | AWS Organizations (root / management account) | Tenant root management group (Microsoft Entra tenant) |
| Group units for policy | Folder | Organizational unit (OU) | Management group |
| Main isolation and workload boundary | Project | Account | Subscription (judgement: resource groups sit one level lower) |
| Logical grouping inside the boundary | Labels (judgement) | Tags / resource groups | Resource group |
| Who pays | Cloud Billing account, linked to projects | Consolidated billing in the management account | Billing account / profile, linked to subscriptions |
| Guardrails | Organization policies | Service control policies | Azure Policy |
The row that trips people up is the resource group. Azure requires every resource to sit in a resource group inside a subscription. Google Cloud has no equivalent mandatory layer below the project, so teams usually make projects smaller and more numerous.
Regions and zones
A region is an independent geographic area, such as europe-west2 (London). A zone is an isolated location inside a region, such as europe-west2-a. That is the same model as AWS Regions and Availability Zones, and Azure regions and availability zones. Some services are zonal (a VM), some are regional, and some are global (a global load balancer). Google Cloud adds regions every year, so check the official locations page rather than relying on a remembered count.
How pricing works
The default is on-demand: pay as you go, billed per use. On top of that come three levers:
Lever What triggers it AWS / Azure nearest match
--------------------------- ---------------------------------- --------------------------------
Sustained use discounts Automatic. Eligible Compute Engine No direct equivalent
(SUDs) resources run >25% of a month
Committed use discounts You commit for 1 or 3 years: Reserved Instances / Savings Plans;
(CUDs) resource-based (vCPU, memory, GPU Azure Reservations / Savings Plan
in a region) or spend-based (judgement: terms differ)
(hourly spend, incl. flexible)
Free Tier + Free Trial Monthly free usage of 20+ products; AWS Free Tier; Azure free account
$300 credit for 90 days for new (judgement: amounts and durations
customers differ)
A worked example of SUDs: you run an eligible N2 VM for the whole month. With no commitment and no other discounts, Compute Engine lowers the bill automatically, by up to 20% for N2, N2D and C2, or up to 30% for N1 and M1/M2. The discount grows in steps as usage passes 25%, 50% and 75% of the month.
Pitfall: SUDs only apply to older series (N1, N2, N2D, C2, M1, M2 and sole-tenant nodes). E2, C3, N4 and other newer series get none, so when costing a modern fleet, plan around CUDs.
How support works
Google calls its support offering Customer Care:
| Tier | Fastest response | Notable extras |
|---|---|---|
| Basic | Billing support only | Included free |
| Standard | 4 hours (P2) | Technical support, paid |
| Enhanced | 1 hour (P1), 24/7 | Optional Technical Account Advisor service |
| Premium | 15 minutes (P1) | Assigned Technical Account Manager |
Paid tiers are priced mostly as a share of monthly spend with a minimum fee. Check the current pricing page before you budget. AWS (Business, Enterprise On-Ramp, Enterprise) and Azure (Standard, Professional Direct, Unified) are structured differently, so compare response times and named contacts rather than tier names.
How to read the tables in this course
Every category lesson has two tables. Read the equivalence table like this:
| Job | Google Cloud | AWS | Azure |
| Object storage | Cloud Storage | Amazon S3 | Blob Storage | <- direct match
| X | Service A | Service B (judgement)| Service C | <- close, but differs
| Y | Service D | No direct equivalent| Service E | <- you must compose or accept a gap
- Direct match: same job, broadly the same model. You still need to check limits and pricing units.
- (judgement): our assessment that this is the nearest fit. A note says where it breaks.
- No direct equivalent: nothing comparable exists as a single service.
- The date in the table header tells you when it was last checked. Services get renamed and retired, so recheck anything older than a few months before you commit.
Key takeaways
- Organisation, then folders, then projects, then resources. Every resource lives in exactly one project, and policies inherit downward.
- A billing account is separate from the tree. It can pay for many projects, but each project has one billing account at a time.
- Project ≈ AWS account ≈ Azure subscription. Folder ≈ OU ≈ management group. Google Cloud has no mandatory resource-group layer.
- Pricing is on-demand plus automatic SUDs (older series only), 1- or 3-year CUDs, the Free Tier and a $300, 90-day trial.
- Support runs Basic, Standard, Enhanced and Premium. Compare response times and named contacts, not tier names.
- In every table, tell direct matches from (judgement) and "no direct equivalent" rows, and check the date.