GCP for AWS Engineers — Mental Model Shift

Everything you know from AWS transfers — but several core abstractions work differently. This guide focuses on the paradigm shifts, not the feature lists.

For a flat service-by-service mapping table and "when to choose which," see the companion doc gcp-vs-aws.md. This file is the conceptual/mental-model view; that one is the lookup table.

The Mental Model Shifts

1. Resource Hierarchy

In AWS, accounts group under AWS Organizations. In GCP, the same idea exists but the names — and a couple of the semantics — don't map one-to-one:

Project is the fundamental billing and IAM boundary in GCP. Every resource belongs to a project. A project has:

• A globally-unique project ID (you choose: my-company-prod-backend)
• An auto-generated project number (123456789)
• A billing account attached to it

graph TD
    classDef org fill:#4285f4,stroke:#2a56c6,color:#fff
    classDef folderProd fill:#e67e22,stroke:#d35400,color:#fff
    classDef folderDev fill:#3498db,stroke:#2980b9,color:#fff
    classDef projectProd fill:#2ecc71,stroke:#27ae60,color:#fff
    classDef projectDev fill:#3498db,stroke:#2980b9,color:#fff
    classDef resource fill:#7f8c8d,stroke:#616a6b,color:#fff

    subgraph ORGLEVEL["Organization level — one per Cloud Identity domain"]
        ORG["Organization: company.com<br/>root of the resource hierarchy<br/>org policies bind here"]:::org
    end

    subgraph FOLDERLEVEL["Folder level — groups projects, nestable"]
        FOLDER_P["Folder: Production<br/>(roughly an AWS OU)"]:::folderProd
        FOLDER_D["Folder: Development"]:::folderDev
    end

    subgraph PROJECTLEVEL["Project level — the real billing + IAM boundary"]
        PROJ1["Project: prod-backend<br/>ID: my-company-prod-backend<br/>Number: 123456789"]:::projectProd
        PROJ2["Project: prod-data"]:::projectProd
        PROJ3["Project: dev-backend"]:::projectDev
    end

    subgraph RESOURCELEVEL["Resources — inherit every ancestor's bindings"]
        RES1["GCE, GKE, GCS<br/>in prod-backend"]:::resource
        RES2["BigQuery, Cloud SQL<br/>in prod-data"]:::resource
    end

    ORG -->|"IAM binding + org policy<br/>inherited downward"| FOLDER_P
    ORG --> FOLDER_D
    FOLDER_P --> PROJ1
    FOLDER_P --> PROJ2
    FOLDER_D --> PROJ3
    PROJ1 --> RES1
    PROJ2 --> RES2

IAM policies inherit downward — a binding at Org level applies to all folders, projects, and resources under it. Unlike AWS (where SCPs are deny-based), GCP org policies are constraint-based (e.g., "only allow VMs in these regions").

To make that inheritance concrete, here's how GCP actually resolves a resource's effective IAM policy — the same walk-up-the-tree logic applies whether the resource is a GCS bucket, a Compute Engine VM, or a BigQuery dataset:

# Create a project under an org
gcloud projects create my-company-prod-backend \
  --name="Production Backend" \
  --organization=123456789

# Set active project for gcloud
gcloud config set project my-company-prod-backend

2. IAM — Additive Allow, Plus a Separate Deny

GCP IAM = member + role → resource. Three rule types:

The Critical Difference from AWS IAM

AWS: explicit Deny overrides Allow. You can grant * then deny specific actions.

GCP: standard IAM Allow bindings are additive. If one binding grants read and another grants write, the user has both, and no Allow binding can revoke a permission granted by another Allow binding at a higher level. GCP does have a separate mechanism for a hard override — IAM Deny policies — which always win over any Allow regardless of where it's granted; see security-compliance.md for how they actually work.

Allow: *
Deny: iam:DeleteRole

Policy Binding Example

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "serviceAccount:my-app@my-project.iam.gserviceaccount.com",
        "user:eng@company.com"
      ]
    },
    {
      "role": "roles/bigquery.dataViewer",
      "members": ["group:data-team@company.com"]
    }
  ]
}

# Grant a predefined role on a project
gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:my-app@my-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

# Grant on a specific resource (bucket)
gcloud storage buckets add-iam-policy-binding gs://my-bucket \
  --member="serviceAccount:my-app@my-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin"

Service Accounts = EC2 Instance Profiles

A GCE VM or GKE pod runs as a service account. The service account is both an identity (for IAM bindings) and a credential source (for GCP SDKs). Never use service account key files on GCE/GKE — use the metadata server.

# Create SA
gcloud iam service-accounts create my-app-sa \
  --display-name="My App"

# Attach to a GCE VM at creation
gcloud compute instances create my-vm \
  --service-account=my-app-sa@project.iam.gserviceaccount.com \
  --scopes=cloud-platform

Workload Identity = GCP's IRSA

GKE pods authenticate to GCP APIs without any key files via Workload Identity. A Kubernetes ServiceAccount is bound to a GCP Service Account.

graph LR
    classDef k8s fill:#326ce5,stroke:#1a4fb4,color:#fff
    classDef gcp fill:#4285f4,stroke:#2a56c6,color:#fff
    classDef api fill:#2ecc71,stroke:#27ae60,color:#fff

    POD["Pod"]:::k8s -->|"runs as"| KSA["K8s ServiceAccount<br/>my-k8s-sa"]:::k8s
    KSA -->|"bound to<br/>(Workload Identity)"| GSA["GCP Service Account<br/>my-app-sa@my-project.iam.gserviceaccount.com"]:::gcp
    GSA -->|"granted"| ROLES["IAM roles<br/>e.g. roles/storage.objectAdmin"]:::gcp
    ROLES --> APIS["GCP APIs<br/>Cloud Storage, BigQuery, ..."]:::api

gcloud iam service-accounts create my-app-sa --project=my-project

gcloud storage buckets add-iam-policy-binding gs://my-bucket \
  --member="serviceAccount:my-app-sa@my-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin"

gcloud iam service-accounts add-iam-policy-binding \
  my-app-sa@my-project.iam.gserviceaccount.com \
  --role="roles/iam.workloadIdentityUser" \
  --member="serviceAccount:my-project.svc.id.goog[default/my-k8s-sa]"

kubectl annotate serviceaccount my-k8s-sa \
  iam.gke.io/gcp-service-account=my-app-sa@my-project.iam.gserviceaccount.com

Pods using my-k8s-sa now automatically get GCP credentials. No secret files, no env vars.

3. Networking — The Biggest Paradigm Shift

Global VPC

graph TD
    classDef awsvpc fill:#e67e22,stroke:#ba6018,color:#fff
    classDef awssub fill:#f5b041,stroke:#ba6018,color:#000
    classDef gcpvpc fill:#4285f4,stroke:#2a56c6,color:#fff
    classDef gcpsub fill:#8ab4f8,stroke:#2a56c6,color:#000

    subgraph AWS["AWS — regions are siloed"]
        VPC1["VPC: us-east-1<br/>10.0.0.0/16"]:::awsvpc
        SUB1A["us-east-1a subnet (public)<br/>10.0.1.0/24"]:::awssub
        SUB1B["us-east-1b subnet (private)<br/>10.0.2.0/24"]:::awssub
        VPC2["VPC: eu-west-1<br/>10.1.0.0/16"]:::awsvpc
        SUB2["eu-west-1a subnet<br/>10.1.1.0/24"]:::awssub
        VPC1 --> SUB1A
        VPC1 --> SUB1B
        VPC2 --> SUB2
        VPC1 -.->|"needs Transit Gateway<br/>or VPC peering to talk"| VPC2
    end

    subgraph GCP["GCP — one VPC spans every region"]
        VPCG["VPC: my-vpc (global)"]:::gcpvpc
        SUBG1["us-central1 subnet<br/>10.0.1.0/24"]:::gcpsub
        SUBG2["europe-west1 subnet<br/>10.1.0.0/24"]:::gcpsub
        SUBG3["asia-east1 subnet<br/>10.2.0.0/24"]:::gcpsub
        VPCG --> SUBG1
        VPCG --> SUBG2
        VPCG --> SUBG3
        SUBG1 -->|"private IPs over<br/>Google's backbone<br/>no peering needed"| SUBG2
        SUBG2 <-.-> SUBG3
    end

A VM in us-central1 reaches a VM in europe-west1 using private IPs — traffic stays on Google's backbone, no peering to configure.

# Always use custom mode VPC (auto mode has fixed CIDRs you can't control)
gcloud compute networks create my-vpc --subnet-mode=custom

# Add subnets per region as you expand
gcloud compute networks subnets create us-subnet \
  --network=my-vpc --region=us-central1 --range=10.0.1.0/24

gcloud compute networks subnets create eu-subnet \
  --network=my-vpc --region=europe-west1 --range=10.1.0.0/24

Firewall Rules — Not SGs

AWS Security Groups attach to ENIs. GCP firewall rules are network-wide, applied to VMs by tag or service account:

# Tag-based (convenient but less secure — anyone with VM edit can change tags)
gcloud compute firewall-rules create allow-frontend-to-backend \
  --network=my-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --target-tags=backend \
  --source-tags=frontend \
  --rules=tcp:8080

# SA-based (more secure — tied to VM identity, not mutable metadata)
gcloud compute firewall-rules create allow-frontend-to-backend-sa \
  --network=my-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --target-service-accounts=backend-sa@project.iam.gserviceaccount.com \
  --source-service-accounts=frontend-sa@project.iam.gserviceaccount.com \
  --rules=tcp:8080

No "Public Subnet" Concept

In AWS, a public subnet routes to IGW. In GCP, there's no such routing concept:

• "Public" VM = has an external IP assigned
• "Private" VM = no external IP, uses Cloud NAT for outbound

# Cloud NAT = GCP's NAT Gateway
gcloud compute routers create my-router \
  --network=my-vpc --region=us-central1

gcloud compute routers nats create my-nat \
  --router=my-router \
  --region=us-central1 \
  --nat-all-subnet-ip-ranges \
  --auto-allocate-nat-external-ips

Cloud NAT is distributed — unlike AWS NAT Gateway (one per AZ), a single Cloud NAT is regional, auto-scales, and you never need to provision multiple for HA.

Multi-VPC Patterns

Shared VPC: One host project owns the VPC and subnets. Service projects (teams) deploy workloads into the host's subnets. Centralized networking, decentralized compute. Better than TGW for multi-team same-cloud scenarios.

4. GCP vs AWS — Pricing Quirks

5. CLI Quick Reference

# ── Auth ──────────────────────────────────────────────────────
aws configure                         → gcloud auth login
aws sts get-caller-identity           → gcloud auth list / gcloud config list

# ── Project (= AWS Account) ───────────────────────────────────
aws sts get-caller-identity           → gcloud config get-value project
                                        gcloud projects list

# ── Compute ───────────────────────────────────────────────────
aws ec2 describe-instances            → gcloud compute instances list
aws ec2 run-instances                 → gcloud compute instances create
aws ec2 terminate-instances           → gcloud compute instances delete
aws ec2 describe-images               → gcloud compute images list

# ── Storage ───────────────────────────────────────────────────
aws s3 ls                             → gsutil ls
aws s3 cp src s3://bucket/path        → gsutil cp src gs://bucket/path
aws s3 sync ./dir s3://bucket/        → gsutil rsync -r ./dir gs://bucket/

# ── Containers / K8s ──────────────────────────────────────────
aws eks update-kubeconfig             → gcloud container clusters get-credentials my-cluster --region us-central1
aws ecr get-login-password | docker login → gcloud auth configure-docker

# ── IAM ───────────────────────────────────────────────────────
aws iam list-roles                    → gcloud iam service-accounts list
aws sts assume-role                   → (transparent via Workload Identity)

# ── Logs ──────────────────────────────────────────────────────
aws logs filter-log-events            → gcloud logging read 'resource.type="k8s_container"'

# ── Secrets ───────────────────────────────────────────────────
aws secretsmanager get-secret-value   → gcloud secrets versions access latest --secret=my-secret

# ── Databases ─────────────────────────────────────────────────
aws rds describe-db-instances         → gcloud sql instances list

Learning Path for AWS Engineers

Week 1 — Core Concepts
  from-aws.md (this file)     mental model shift, IAM, networking
  gcp/README.md               VPC deep-dive, firewall rules, Cloud NAT

Week 2 — Compute & Containers
  gcp/compute.md              GCE vs EC2, custom VMs, Spot VMs
  gcp/gke.md                  GKE modes, Workload Identity, NEG

Week 3 — Storage & Data
  gcp/storage.md              GCS, Persistent Disk, Filestore
  gcp/databases.md            Cloud SQL, Spanner, Firestore, Bigtable
  gcp/bigquery.md             serverless analytics deep-dive

Week 4 — Application Services
  gcp/serverless.md           Cloud Run, Cloud Functions
  gcp/messaging.md            Pub/Sub, Cloud Tasks, Eventarc
  gcp/observability.md        Cloud Monitoring, Logging, Trace

Week 5 — Comparison & Scenarios
  gcp/gcp-vs-aws.md           when to choose which
  gcp/scenarios.md            7 real debugging scenarios

The two concepts that take the longest to internalize coming from AWS:

1. Global VPC — stop thinking about cross-region connectivity as something you configure
2. Additive IAM — design least-privilege from the start for standard Allow bindings; reach for a real IAM Deny policy (see security-compliance.md) only when you need a hard override no Allow can undo