GCP Overview — Google's Cloud Built on the Same Infrastructure That Runs Google

Four decisions, and everything downstream of them

Strip away the branding and Google Cloud rests on four choices. One tree. Nothing sits loose: resources hang off a project, projects hang off a folder or straight off the organization, and access policy is attached to whichever link in that chain you want it to cover. Global objects with regional parts. A network, a load balancer front end, an image, a bucket location - these are frequently one object that spans regions, rather than a regional object you build once per region and then federate. One API grammar. Every service is a REST and gRPC surface over resources with the same naming shape, the same verb set, and the same service.resource.verb permission strings. Externalised internals. A large share of the interesting services are Google's own production systems given a public API, which explains both what they can do and why their knobs are shaped the way they are.

Everything else - which database, which compute product, which messaging tier - follows from those four and is genuinely better learned per service. So this page deliberately stops where the service article starts. Each name below is a link, and the link is where the depth lives.

The tree, in one paragraph

Organization at the top, folders nested beneath it, projects beneath those, resources inside projects. The project is the node that carries weight: it is simultaneously where billing attaches, where quota is allocated, which APIs are switched on, and what gets destroyed when you delete the whole environment. Four boundaries that other platforms hand to four separate mechanisms happen to coincide on one object.

The comparison people need is against the AWS account, and the difference is mostly one of weight. An account is a heavy thing to create, so estates economise on them and then reach for Organizations, OUs and service control policies to carve the inside back up. A project is cheap enough that "give it its own project" is the ordinary answer to an isolation question, and the folder layer exists purely as somewhere to hang a policy that should cover a set of projects. The tradeoff runs the other way too: a project is a softer boundary than an account, and the org-level grant that quietly reaches into all of them is a failure mode with no AWS equivalent.

The full treatment - how allow policies inherit down the tree, why the inheritance is additive with no way to subtract, the project ID versus project number trap, and the argument for more projects rather than broader roles - is in GCP IAM and the resource hierarchy. The account-shaped version of the same problem is in the AWS overview.

Global by default, and the work it removes

This is the single most visible difference in day-to-day use. On most clouds the network is a regional construct: you create one per region, then you peer them, then you maintain the mesh and the route tables that hold the mesh together. On GCP a VPC is a global resource. Subnets are regional and live inside it, so expanding into a new region means adding a subnet, not building a second network and stitching it to the first. Instances in different continents sit on the same private address space with no peering object between them.

The same stance repeats up the stack. The external HTTP load balancer is a global resource fronted by a single anycast IP announced from Google's edge, so there is no per-region endpoint set and no DNS failover tier whose TTLs you have to reason about. Cloud Storage buckets can take a multi-region location. BigQuery datasets have a location that can be a multi-region. Spanner instance configurations name a set of regions rather than one. In each case the multi-region behaviour is a property you select at creation, not an architecture you assemble.

What that removes is an entire tier of glue: the inter-region network mesh, the health-checked DNS layer, the endpoint registry that tells clients which region to talk to. Teams arriving from another cloud routinely spend their first week looking for those components and are unsettled when they turn out not to exist.

The cost is symmetrical and worth stating plainly. A global object has a global blast radius. A firewall rule, a route, or a forwarding rule that is wrong is wrong everywhere at once, with no regional bulkhead to contain it, and changes to global objects are global control-plane operations whose propagation you can observe. The mechanics of the network side are in the VPC article; the multi-region serving and failover path is in GCP multi-region architecture, with the edge caching layer in Cloud CDN.

Most of it is Google's own infrastructure with an API on it

Google ran planet-scale systems internally for a decade before selling access to them, and the lineage is not marketing. Kubernetes is the open re-implementation of Borg's ideas, and GKE runs it on the platform Borg came from; Cloud Run schedules your containers onto Borg alongside Google's own workloads. Cloud Storage and effectively everything else that persists bytes sits on Colossus, the successor to GFS. BigQuery is Dremel with a billing model, and the reason its shuffle tier works at all is the Jupiter datacenter fabric underneath it. Cloud Spanner is the database Google built to run its own advertising system, with TrueTime exposed rather than hidden.

Three consequences follow, and only two of them are flattering.

Capability that looks implausible is simply older than you think. A globally consistent SQL database with real transactions, or a warehouse with no cluster to size and no vacuum to schedule, are not products someone specced and built to a launch date. They were load-bearing against Google's own traffic long before they had a public endpoint, which is why the hard scaling problems were solved against Google rather than against early customers.

The knobs are the internal system's knobs. BigQuery gives you no instance to size because Dremel never had one; you get slots, because slots are the internal unit. Spanner makes you think about split boundaries and interleaving because Spanner is split-shaped internally and always was. This is why GCP services often feel opinionated in a specific way - not under-configurable, but configurable along axes somebody else chose.

Where there was no internal system, there is no advantage. Plenty of the catalogue is an ordinary managed offering with nothing structural behind it, and those services are simply competent rather than remarkable. Being able to tell the two categories apart is most of what this page is for.

One API grammar, and what it buys automation

Every GCP resource has a canonical name in the same shape, every permission is service.resource.verb, every service is enabled or disabled per project, and slow creates return a long-running operation object with the same fields no matter which service produced it.

# One naming grammar, every service
//compute.googleapis.com/projects/acme-prod/zones/us-central1-a/instances/api-7
//pubsub.googleapis.com/projects/acme-prod/topics/orders
//bigquery.googleapis.com/projects/acme-prod/datasets/warehouse

# One permission grammar, every service
compute.instances.start    pubsub.topics.publish    bigquery.jobs.create

# A service does not exist in a project until the project turns it on
gcloud services enable spanner.googleapis.com --project=acme-prod
gcloud services list --enabled --project=acme-prod

# And every command is just an HTTP call you can read
gcloud compute instances list --format=json --log-http

The payoff is that tooling can be largely mechanical. gcloud, the client libraries and the Terraform provider are generated over the same service descriptors, which is why new services arrive with consistent coverage instead of each one growing a bespoke CLI. Config Connector can represent GCP resources as Kubernetes custom resources for the same reason: there is one uniform resource model to project into CRDs. You write one operation-waiter and one retry policy and they work across the estate. And because every action is an ordinary HTTP request against a documented resource, --log-http turns any mysterious console behaviour into a request you can read and replay.

Uniformity has a specific hazard, though: it makes unlike things look alike. Two create calls with identical shapes can differ by minutes in completion time, and a control plane that has returned success is not the same as every dependent service having observed the resource. Automation that treats "the API returned 200" as "the thing is usable" fails intermittently and in a way that reads like a permission problem. Enablement is the same trap in slower motion - a Terraform run that creates a resource in a project where the API was enabled seconds earlier can fail on a race that disappears on retry.

Zones, regions, and the live migration property

The geography is conventional: a zone is a failure domain, a region is a set of zones close enough for synchronous replication, and resources declare themselves zonal, regional or global. Regional variants of most primitives - regional persistent disks, regional managed instance groups, regional GKE control planes - handle the cross-zone replication for you rather than asking you to build it.

The genuinely unusual property is what happens when Google needs to service the physical host your VM is running on. On most platforms that is a scheduled event you receive notice about and handle by stopping and replacing the instance. Compute Engine instead live-migrates the running VM to another host. The instance keeps its memory, its disks and its IP; the guest is not restarted and does not need to know. Host maintenance behaviour is an explicit per-instance policy - MIGRATE or TERMINATE - and MIGRATE is the default for ordinary machine types.

Practically, this deletes a workflow other clouds require you to own: there is no rolling replacement to build for routine host patching, and a long-lived stateful VM is a less reckless idea here than elsewhere. But three caveats decide whether you can rely on it. Live migration handles host events, not zone events - it is not a substitute for spreading across zones, and treating it as one is the mistake it invites. The final memory copy involves a brief blackout, short enough to be invisible to most services and long enough to matter to latency-sensitive ones and to trip aggressive health checks. And several configurations cannot migrate at all: GPU-attached instances and certain confidential computing shapes fall back to terminate-and-restart semantics, which is precisely the class of expensive, long-running workload people assume is protected. Spot and preemptible instances sit outside the model entirely - they are reclaimed on short notice by design.

Data and analytics is the honest centre of gravity

If you ask where GCP is chosen on merit rather than on price or on an existing relationship, the answer is consistently the data platform, and the lineage argument above is why. BigQuery separates storage from compute as two independent services rather than as tiers of one cluster, so nobody sizes a warehouse. Pub/Sub is a globally addressable topic surface rather than a set of regional brokers you shard by hand. Dataflow runs the Beam model, whose batch and streaming semantics came out of Google's own FlumeJava and MillWheel work, so one pipeline definition covers both.

What makes the combination stick is not any one of them but the absence of seams between them. BigQuery reads Cloud Storage in place, Dataflow writes BigQuery natively, Datastream lands change data without an intermediate hop, Vertex AI trains against data that never leaves the warehouse, and all of it authorises through the same IAM surface rather than through per-product credentials. The tier of ETL machinery whose only job is moving bytes between engines mostly does not need to exist. Dataproc covers the case where you want Spark or the Hadoop ecosystem unchanged, and BI Engine the interactive serving layer on top.

The honest corollary: this strength is exactly why GCP so often shows up as somebody's second cloud. The data platform lands here while the applications stay where they already were, and the resulting architecture problem is not BigQuery - it is cross-cloud egress, identity federation and two sets of network controls that have to agree.

Quota is per project, per region, and it often starts at zero

Quota on GCP is dimensioned on the tuple of project, service, region and metric. Not the organization, not the billing account. Two projects in the same folder share nothing, which is the property that makes per-team projects safe and also the property that makes a fifty-project estate a fifty-times-repeated administrative task.

Two shapes exist and they fail differently. Allocation quotas cap how much of a thing can exist at once - CPUs of a family in a region, static addresses, disk capacity - and they fail loudly at create time, which is annoying but obvious. Rate quotas cap API calls over a window and surface as RESOURCE_EXHAUSTED in the middle of a system that was working ten minutes ago, usually because something started retrying. The second kind is the one that reaches production, because nothing during development generates the call volume that triggers it.

The specific surprise for newcomers is that a good number of quotas default to zero in regions and for resource families you have never used. Accelerators are the canonical case: a pipeline that runs happily in one region fails on its first deploy to another with a message that looks like a configuration error and is actually an empty quota bucket. Because the quota lives on the project and the recommended structure is many projects, the only workable answer is to make quota requests part of project provisioning itself - whatever factory or landing zone creates the project should file them - rather than letting each new project rediscover the same limits at the worst moment.

Fewer services, stronger opinions, smaller ecosystem

The catalogue is materially smaller than AWS's, and that is a real tradeoff in both directions rather than a deficiency to apologise for. For any given problem there are usually two or three plausible GCP services rather than seven, which makes the decision faster and makes it worse when your requirement is the one outside the intended shape.

The defaults are correspondingly more opinionated. GKE Autopilot removes node management rather than exposing it. Cloud Run bills by request and gives you a concurrency setting instead of a fleet. BigQuery has no cluster because the design does not admit one. Each of these is a decision Google made on your behalf, each is the right decision for the median workload, and each becomes a wall for the atypical one - where the escape hatch is generally "move to the less opinionated product", which is a rewrite rather than a setting.

The ecosystem gap is the cost that shows up in on-call and hiring rather than on the architecture diagram: fewer third-party integrations, fewer engineers who have run this in anger, and vendor tooling whose GCP support is a version behind its AWS support. Budget for it honestly. Google's record of retiring products is also a legitimate input to procurement conversations whatever one thinks of it on the merits - and the useful hedge is structural rather than emotional. A large part of the GCP data estate is managed open source: Dataproc is Spark and Hadoop, Composer is Airflow, Memorystore is Redis and Valkey, Dataflow runs Beam. Where the service is managed OSS, an exit is a migration. Where it is proprietary and structurally unique - Spanner, BigQuery - an exit is a rewrite, and that should be priced in at the point of the decision rather than discovered later.

Where the map goes next

Pick whichever layer you are actually building in and start there. Identity and structure: GCP IAM for the hierarchy, allow policies, service accounts and impersonation; VPC Service Controls for the data-exfiltration perimeter that IAM cannot express; and Cloud IAM for the vendor-neutral model underneath both. Networking: VPC, multi-region serving, Cloud CDN and Cloud Armor. Compute and containers: GKE, Cloud Run with its concurrency and autoscaling model, and Cloud Functions. Data: BigQuery, Spanner, Bigtable, Cloud SQL, Cloud Storage and Memorystore. Event plumbing: Pub/Sub, Eventarc, Workflows and Cloud Tasks. And for the substrate itself, Colossus is the clearest single illustration of why the platform behaves the way it does.