GCP Fundamentals: Resource Hierarchy and Core Services
How Google Cloud organizes resources into projects, folders, and organizations, and how its core services map onto the AWS and Azure building blocks you may already know.
Learning objectives
- Explain the organization-folder-project resource hierarchy and why every GCP resource ultimately belongs to a project
- Describe how IAM policies and billing attach at different levels of the hierarchy and inherit downward
- Map GCP's core compute, storage, networking, and database services onto their closest AWS and Azure equivalents
- Navigate the gcloud CLI to inspect and switch between projects and configurations
Every cloud provider needs some way to answer the question "who owns this resource, and who is allowed to touch it?" Google Cloud answers that question with a strict four-level tree: the Organization sits at the root, Folders sit underneath it as optional grouping nodes, Projects sit underneath folders (or directly under the organization), and every actual resource -- a VM, a storage bucket, a database -- belongs to exactly one project and nothing but a project. There is no such thing as a GCP resource that floats free of a project; the project is the fundamental unit of billing, quota, and API enablement in the entire platform.
The Organization node exists only if you're using Google Workspace or Cloud Identity to manage a company domain -- an individual developer experimenting with a personal Gmail account never sees one, and their projects simply have no organization ancestor at all. Folders are purely organizational sugar on top of that: a mid-size company might create folders for "Engineering," "Marketing," and "Finance," each folder containing the handful of projects that team owns, which makes it possible to apply one IAM policy or one organization constraint to an entire business unit at once instead of repeating it project by project.
This matters practically because of how IAM policies and certain organization policies propagate: a role granted at the organization level is inherited by every folder and every project underneath it, and a role granted at a folder level is inherited by every project in that folder. If you grant someone "Viewer" at the organization root, they can view every single resource in every single project across the entire company, which is exactly why production environments almost always grant broad roles high in the hierarchy only to a small number of platform-team accounts, and grant narrower, project-scoped roles to everyone else. Billing works similarly but separately: every project links to exactly one Billing Account, and that link is what determines which credit card or invoice absorbs the project's usage charges -- a project with no linked billing account can still exist, but most APIs refuse to activate until one is attached.
In daily work, almost everything you do with the gcloud CLI happens inside the context of "the current project," which is why gcloud config set project PROJECT_ID is usually the very first command run in any new terminal session or CI pipeline -- every subsequent command implicitly operates against whichever project is currently configured unless you override it explicitly with the --project flag.
💻 Code example
# Inspect the currently active gcloud configuration gcloud config list # List every project your account can see, with their numeric project numbers gcloud projects list # Switch the active project for all subsequent commands in this session gcloud config set project my-production-project # Create a folder-style grouping is an organization-level operation; most # developers instead just create a fresh project under an existing folder: gcloud projects create my-new-service-project \ --folder=123456789012 \ --name="My New Service" # Grant a user the Viewer role at the project level (not the org or folder) gcloud projects add-iam-policy-binding my-production-project \ --member="user:alice@example.com" \ --role="roles/viewer" # Confirm which billing account a project is linked to gcloud billing projects describe my-production-project
Most engineers arriving at GCP already have working muscle memory from AWS or Azure, and the fastest way to become productive is to translate that muscle memory directly rather than relearning cloud computing from zero. The underlying concepts -- virtual machines, object storage, managed relational databases, container orchestration -- are nearly identical across all three providers; what differs is naming, some default behaviors, and which pieces Google chooses to bundle together versus keep separate.
Compute Engine is GCP's answer to EC2: resizable virtual machines billed by the second, with machine types that are directly comparable to EC2 instance families, custom machine shapes that let you pick an arbitrary vCPU-to-memory ratio (something AWS doesn't offer as flexibly), and sustained-use discounts that apply automatically without any upfront reservation, unlike AWS Reserved Instances which require a commitment decision in advance.
Cloud Storage plays the role of S3: a globally-namespaced object store with storage classes for different access patterns, versioning, and lifecycle rules. The conceptual mapping is nearly one-to-one, down to the idea of buckets and objects, though Cloud Storage buckets are tied to specific locations or multi-regions at creation time in a way that's slightly more rigid than S3's region model.
GKE (Google Kubernetes Engine) corresponds to EKS on AWS or AKS on Azure, but with a meaningfully different reputation: Google originally created Kubernetes internally (as a descendant of its own Borg scheduler) before open-sourcing it, and GKE is widely regarded as the most mature and hands-off of the three managed Kubernetes offerings, with features like Autopilot mode that manage node provisioning entirely on your behalf.
BigQuery has no exact one-to-one match on either competitor -- it's closest in spirit to a combination of Redshift and Athena, a serverless data warehouse where you never provision or manage the underlying compute cluster at all, you simply submit SQL and pay for the bytes scanned.
Here is the comparison table worth keeping as a reference while the rest of this category gets into specifics:
| Category | GCP | AWS | Azure |
|---|---|---|---|
| Virtual machines | Compute Engine | EC2 | Virtual Machines |
| Object storage | Cloud Storage | S3 | Blob Storage |
| Managed Kubernetes | GKE | EKS | AKS |
| Serverless containers | Cloud Run | Fargate / App Runner | Container Apps |
| Relational database | Cloud SQL | RDS | Azure SQL Database |
| Data warehouse | BigQuery | Redshift / Athena | Synapse Analytics |
| Serverless functions | Cloud Functions | Lambda | Azure Functions |
| IAM | Cloud IAM | IAM | Entra ID (Azure AD) |
| CI/CD | Cloud Build | CodeBuild / CodePipeline | Azure Pipelines |
The rest of this category walks through the right-hand-side-GCP column of this table in depth, but keeping this map in view saves a lot of "wait, what's the GCP equivalent of X" moments along the way.
Q: What is the one rule every GCP resource obeys regarding the resource hierarchy?
A: Every resource belongs to exactly one project, and nothing exists outside of a project. Projects may optionally sit under folders, and folders may optionally sit under a single organization, but the project is the non-negotiable base unit for billing, quota, and API enablement.
Q: How do IAM roles behave as you move up or down the hierarchy?
A: Roles granted at a higher level (organization or folder) are inherited by everything beneath it. A role granted at the organization root applies to every folder and project under that organization, which is why broad roles are usually reserved for a small number of platform-team accounts at the top of the hierarchy.
Q: What's the closest GCP equivalent to AWS's EKS or Azure's AKS?
A: GKE (Google Kubernetes Engine), widely considered the most mature managed Kubernetes offering of the three, partly because Google originated Kubernetes internally before open-sourcing it.
Q: Why doesn't BigQuery map cleanly onto a single AWS or Azure service?
A: BigQuery is a fully serverless data warehouse with no cluster to provision or manage -- it sits somewhere between Redshift (data warehousing) and Athena (serverless query-on-demand), billing purely by bytes scanned rather than by a provisioned cluster size.
Want a visual for this concept?
Generate a diagram tailored to “GCP Fundamentals: Resource Hierarchy and Core Services” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →