From AWS to GCP: Mental Models and Architecture Mapping for DevOps Engineers

When DevOps engineers familiar with AWS first encounter Google Cloud Platform (GCP), the biggest friction rarely comes from terminology mapping—it stems from conflicting underlying architectural assumptions.

While both platforms provide virtual machines, managed containers, object storage, and identity management, their foundational mental models differ sharply across resource boundaries, permission inheritance, and network topology. Applying AWS operational instincts directly to GCP not only risks unintended permission overwrites in Terraform, but can also lead to misjudgments in network planning and Kubernetes integration.

Core Architecture Mapping Overview

Before diving into specific mechanisms, the table below highlights the architectural dimensions with the highest “cognitive friction” in day-to-day DevOps operations:

1. Resource Hierarchy and IAM: The Downward-Inheriting Union Model

A Project Is Not an AWS Account

In AWS, the fundamental isolation boundary is the AWS Account. AWS Organizations groups accounts using Organizational Units (OUs) and restricts maximum allowable permissions from the top down using Service Control Policies (SCPs), but each account maintains an independent IAM system.

GCP, by contrast, enforces a strict tree-like structure: the Resource Hierarchy governs the relationship of Organization → Folder → Project → Underlying Resources.

 AWS Model:
 [Organization] --> [OU] --> [AWS Account]
                               +-- Role / User / Resources

 GCP Model:
 [Organization]
   +-- [Folder]
         +-- [Project] (Resource Container & Billing Unit)
               +-- Compute Engine / GKE / Cloud Storage

In GCP, a Project is the container for billing, quotas, enabled APIs, and default networking. The core distinction lies in how permissions flow:

• Attachment point: AWS IAM policies attach primarily to identities (Users, Roles); GCP Allow Policies attach to nodes in the resource hierarchy, defining “which Principal holds which Role on this node.”
• Downward inheritance: Permissions granted at a parent level (such as a Folder) automatically propagate down to all child Projects and resources.
• Union rule: Under GCP’s permission inheritance model, effective permissions on a resource are the union of the policy attached to the resource itself and all policies attached to its ancestors. Consequently, a child resource cannot revoke permissions granted at a parent level. To block inherited access, you must enforce an IAM Deny Policy or apply Organization Policies at the organization level.

Service Accounts vs. IAM Roles

In AWS, an IAM Role acts like a “hat”: an EC2 instance wears it via an Instance Profile, a Lambda function wears it via an Execution Role, and a developer wears it via AssumeRole.

GCP completely decouples identity from permissions into two distinct primitives:

1. Role: A pure collection of permissions (e.g., roles/storage.objectViewer). A Role is not an identity and cannot be “assumed.”
2. Service Account (SA): A machine identity with an email address format (e.g., deployer@PROJECT_ID.iam.gserviceaccount.com).

The fundamental architectural differences between the two are outlined below:

In production operations, follow these two best practices:

• Revoke excessive default SA permissions: The Compute Engine Default SA created automatically often carries the overly permissive Editor role. Disable automatic role granting via Organization Policies, and provision dedicated, least-privilege service accounts instead.
• Eliminate long-lived key files: Avoid downloading Service Account JSON keys. Instead, use attached identities, IAM Impersonation (acting as a Service Account, similar to AWS AssumeRole), or Workload Identity Federation (swapping an AWS IAM Role directly for a short-lived GCP token when integrating across clouds).

Terraform IAM Pitfalls and Local Authentication

In AWS Terraform, aws_iam_role_policy_attachment manages only the association between a specific policy and a role, leaving other existing bindings untouched. In contrast, the GCP Provider offers three distinct IAM resource types with varying levels of granularity (see google_project_iam), each with vastly different behaviors and blast radii:

# 1. google_project_iam_binding (Authoritative over a single role)
# Controls the exclusive member list for a given role. If someone manually adds a member via the Console, the next `terraform apply` will purge them!
resource "google_project_iam_binding" "editor_binding" {
  project = var.project_id
  role    = "roles/editor"
  members = ["serviceAccount:${google_service_account.admin.email}"]
}

# 2. google_project_iam_member (Safest: Additive)
# Adds a single binding without affecting other members under this role or out-of-band Console configurations.
resource "google_project_iam_member" "deployer_ar_writer" {
  project = var.project_id
  role    = "roles/artifactregistry.writer"
  member  = "serviceAccount:${google_service_account.deployer.email}"
}

When writing IaC for existing projects, always default to google_project_iam_member to avoid unintended access revocation caused by authoritative iam_binding or globally authoritative iam_policy resources.

2. Networking: Global VPCs, Shared VPCs, and Software-Defined Perimeters

Global VPCs and Regional Subnets

An AWS VPC is confined to a single Region, and each Subnet resides within a specific Availability Zone (AZ). Routing between two cross-region VPCs requires VPC Peering or a Transit Gateway.

In GCP, a VPC is a global resource, whereas subnets are regional resources:

 AWS Architecture (Regional VPC):
 [Region: us-east-1]         [Region: ap-northeast-1]
 +-----------------------+   +-----------------------+
 | VPC: 10.0.0.0/16      |   | VPC: 10.1.0.0/16      |
 |  +-- Subnet AZ-a      |<->|  +-- Subnet AZ-a      |
 |  +-- Subnet AZ-b      |   |  +-- Subnet AZ-b      |
 +-----------------------+   +-----------------------+
 (Cross-region requires Peering or Transit Gateway)

 GCP Architecture (Global VPC):
 +---------------------------------------------------+
 | Global VPC Network                                |
 |  +-- Region: us-central1 (Subnet: 10.128.0.0/20)  |
 |  +-- Region: asia-east1  (Subnet: 10.140.0.0/20)  |
 |                                                   |
 |        <--- Direct Internal Routing --->          |
 +---------------------------------------------------+

This architecture introduces three fundamental shifts:

1. Native cross-region internal communication: A VM in asia-east1 and a VM in us-central1 communicate directly via internal IP addresses as long as they reside in the same VPC. Traffic traverses Google’s global private fiber backbone without requiring VPC peering.
2. Subnets span all zones: Subnets are not tied to a specific zone. You only need to allocate a single subnet per region; all zones in that region automatically share this address space.
3. No public vs. private subnet distinction: GCP has no Internet Gateway (IGW) resource. Whether a VM can reach the public internet depends entirely on whether it is assigned an external public IP, or whether Cloud NAT is configured for that region.

Firewall Mechanisms and Demystifying the Three Types of “Tags”

AWS uses a two-tier model: stateful Security Groups attached to ENIs (allow-only) paired with stateless NACLs attached to subnets (supporting allow/deny with rule evaluation order).

GCP collapses both into a single system: VPC Firewall Rules:

• Stateful connection tracking: Return traffic is automatically allowed.
• Both Allow and Deny supported: Rules are evaluated based on Priority (0 to 65535, where lower numbers indicate higher priority).
• Target selectors: Rules target instances using Network Tags (plain text strings) or Target Service Accounts.

resource "google_compute_firewall" "allow_lb_to_web" {
  name                    = "allow-lb-to-web"
  network                 = google_compute_network.main.id
  direction               = "INGRESS"
  priority                = 1000
  source_ranges           = ["35.191.0.0/16", "130.211.0.0/22"] # Google LB probe and GFE-to-backend source ranges
  target_service_accounts = [google_service_account.web.email]

  allow {
    protocol = "tcp"
    ports    = ["8080"]
  }
}

While AWS relies on a single tagging mechanism, GCP splits the concept into three distinct, non-interchangeable mechanisms:

In security-sensitive environments, always configure firewall rules using Target Service Accounts instead of Network Tags to prevent instances from bypassing network perimeters through arbitrary tag modifications.

Private Connectivity and Load Balancing Architectures

AWS unifies private, non-internet-routable communication under VPC Endpoints. GCP separates private access into three distinct mechanisms based on the target architecture:

1. Private Google Access: Enabled with a single toggle at the subnet level, allowing VMs with only internal IP addresses to reach Google APIs (such as GCS and BigQuery) completely free of charge, without provisioning dedicated endpoint network interfaces.
2. Private Service Connect (PSC): The direct equivalent of AWS PrivateLink, providing custom internal IP endpoints to connect securely to third-party SaaS providers or private services published across VPCs.
3. Private Services Access (PSA): Implemented as VPC Peering to connect directly to dedicated internal subnets hosting Google-managed services (such as Cloud SQL and Memorystore). Cloud SQL now recommends PSC for private IP connectivity (the console default for new projects), making PSA the earlier-generation mechanism.

For egress and load balancing:

• Cloud NAT: AWS NAT Gateways are tied to specific AZs, traditionally requiring one gateway per AZ for high availability (a Regional NAT Gateway that expands across AZs automatically became available in November 2025). GCP’s Cloud NAT is a distributed, software-defined service configured directly on a regional Cloud Router, eliminating the need to manage proxy VMs.
• Cloud Load Balancing: AWS ALB and NLB are regional resources. GCP provides the Global External Application Load Balancer, fronted by a single Anycast IP. Global user traffic enters Google’s private backbone at the edge PoP nearest to the client and is automatically routed to backends across multiple regions, delivering built-in multi-region failover.

3. Kubernetes: GKE vs. EKS Cloud Integrations

For Certified Kubernetes Administrators (CKAs), core Kubernetes constructs such as kubectl, Deployment, and Service translate seamlessly. The key differences lie in how each platform integrates with the underlying cloud control plane.

Standard vs. Autopilot Modes

EKS manages compute fleets using Managed Node Groups, Karpenter, or Fargate. GKE offers two cluster operation modes at creation time:

Under GKE Autopilot, operational thinking changes significantly: resource requests directly dictate infrastructure spend; Google assumes all node maintenance duties; and observability shifts entirely to Cloud Logging and kubectl describe.

VPC-Native Clusters and Secondary IP Ranges

In AWS EKS, the AWS VPC CNI assigns Pod IPs directly from the primary subnet address space, often leading to subnet CIDR exhaustion as clusters scale.

GKE defaults to a VPC-Native architecture leveraging Alias IPs:

 GCP Subnet CIDR Layout for GKE:
 +---------------------------------------------------+
 | Primary CIDR: 10.0.0.0/24      (Node VMs)         |
 | Secondary CIDR 1: 10.4.0.0/14  (Pods)             |
 | Secondary CIDR 2: 10.8.0.0/20  (Services)         |
 +---------------------------------------------------+

Because secondary ranges are natively routable across the entire VPC, Google Cloud Load Balancers can bypass NodePorts and kube-proxy entirely using Network Endpoint Groups (NEGs). Traffic routes directly to Pod IPs (Container-Native Load Balancing), significantly reducing network hops and latency.

Workload Identity Federation for GKE

In AWS EKS, pods accessing AWS APIs historically relied on IRSA (requiring an IAM OIDC Provider and Trust Policies), with EKS Pod Identity as the more recent option.

GCP’s equivalent solution is Workload Identity Federation for GKE. When enabled, the GKE Metadata Server intercepts credential requests on nodes and exchanges the Kubernetes ServiceAccount (KSA) token for a short-lived GCP access token.

GCP’s current best practice is to grant IAM roles directly to the KSA principal using the following URI format:

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME

This principal can be bound directly as a member in any GCP resource IAM policy, removing the need to provision an intermediate GCP Service Account.

Automatic Rolling Upgrades via Release Channels

In EKS, Kubernetes version upgrades require operators to manually trigger control plane and node group updates.

GKE introduces Release Channels (Rapid, Regular, Stable, plus Extended for long-term support on Standard clusters) by default:

• Both control planes and worker nodes undergo automatic rolling upgrades.
• The core operational responsibility for DevOps shifts to: establishing robust PodDisruptionBudgets (PDBs), proactively migrating workloads before API deprecations, and configuring Maintenance Windows and exclusion periods to ensure automatic upgrades do not disrupt core business operations.

4. Serverless Boundaries: Unified Workloads on Cloud Run

While AWS splinters serverless compute across Lambda (pure functions), App Runner (simplified containers), and ECS on Fargate (full containerized tasks), GCP unifies these workloads under Cloud Run.

The core value proposition of Cloud Run is that a single standard Docker container image and a unified IAM model can handle multiple execution patterns:

Standalone Cloud Functions have now been fully folded into the Cloud Run functions family. For operations teams running stateless workloads, Cloud Run delivers serverless execution without the operational overhead of managing Kubernetes clusters or nodes.

5. Operational Boundaries: Audit Logging, API Ecosystem, and Billing

Audit Logging Mechanisms (vs. CloudTrail)

GCP’s Cloud Audit Logs enforces clear architectural boundaries around costs and enablement:

• Admin Activity and System Event logs: Always enabled, retained for 400 days free of charge (written to the _Required log bucket), and cannot be manually disabled. Every resource creation, modification, and deletion is recorded automatically.
• Data Access logs: Track data-plane API calls (such as reading Cloud Storage objects). They are disabled by default (except for BigQuery) and incur log ingestion and storage charges once enabled.

The API Ecosystem and Committed Use Discounts (CUDs)

1. APIs require explicit enablement; disabling them is destructive: AWS accounts enable all services by default. In GCP, each Project must explicitly enable APIs before use (e.g., container.googleapis.com), typically managed declaratively in Terraform via google_project_service. Critically, disabling an API (such as disabling the Cloud Run API) is a destructive operation that permanently deletes all existing instances and resources managed under that service within the project.
2. Flexible cross-service discounts (CUDs): While AWS Savings Plans come in Compute, EC2 Instance, and SageMaker variants, GCP’s Committed Use Discounts (CUDs) provide both resource-based commitments for Compute Engine and Spend-based Flexible CUDs. The latter applies commitments simultaneously across Compute Engine, GKE, and Cloud Run, offering greater purchasing flexibility for mixed architectures.