The diagram below is the Part 1 topology with every AWS service swapped for its Google Cloud equivalent. The workloads in the cluster are identical; only the managed substrate underneath is Google's. The full mapping is in the table further down. Click any component to see the Google Cloud service in place, and what, if anything, changes.
The same topology, on Google Cloud
Same cluster profile as Part 1: one region in the UK (europe-west2), a private GKE cluster, the
ambient mesh and the one gateway in front of the model, on Google Cloud's managed services instead of AWS's.
Click any component, and its Google Cloud detail appears in the panel beside it (on a phone it opens as a card).
the Google Cloud architecture (Part 1 runs the live AWS build) dashed = best practice, not deployed ▸ Click any component to see the Google Cloud service in place of the AWS one.
AWS to Google Cloud, service by service
Everything above the managed substrate is unchanged. What changes is the cloud underneath the cluster, and it maps almost one for one:
| Layer | AWS (Part 1) | Google Cloud (this page) |
|---|---|---|
| Kubernetes | EKS 1.34 | GKE, private cluster |
| Edge load balancer | NLB, L4 TLS passthrough | External passthrough Network Load Balancer |
| Egress | NAT gateway | Cloud NAT |
| Network firewall | Security groups | VPC firewall rules |
| DNS allowlist | Route 53 DNS Firewall | Cloud DNS response policy |
| Key management | KMS | Cloud KMS, Cloud EKM for external keys |
| Secrets at rest | etcd envelope encryption, KMS | GKE application-layer secrets encryption, Cloud KMS |
| Object storage | S3 | Cloud Storage |
| Workload identity | IAM roles for service accounts (IRSA) | Workload Identity Federation for GKE |
| Node hardening | Amazon Linux 2023, IMDSv2 hop-limit 1 | Container-Optimized OS, Shielded Nodes, Workload Identity metadata |
| GPU node | g7e, RTX PRO 6000 96 GB | a2-ultragpu-1g, A100 80 GB |
| Region | eu-west-2 (London) | europe-west2 (London) |
| Backup | Velero to S3 | Velero to Cloud Storage, or Backup for GKE |
| Threat detection | GuardDuty | Security Command Center |
| Managed database, Keycloak | RDS Multi-AZ | Cloud SQL, regional HA |
| WAF | AWS WAF, or the gateway WAF | Cloud Armor, or the gateway WAF |
| Private API access | VPC endpoints, PrivateLink | Private Google Access, Private Service Connect |
Why it ports this cleanly
The security in Part 1 is not made of AWS services. Identity is SPIFFE from a Vault CA the mesh runs; the one
door is agentgateway; admission is Kyverno and Pod Security Admission; isolation is gVisor; provenance is
cosign. Every one of those is a Kubernetes workload that neither knows nor cares which cloud it sits on. The
cloud's own services are used only for the primitives underneath, the keys, the storage, the node image and the
load balancer, and each of those has a direct Google Cloud equivalent. So the move is a substrate swap, not a
redesign, and the claims hold the same way: data residency by keeping storage and inference in
europe-west2, key custody by unsealing Vault from Cloud KMS, traffic control by the same
default-deny network and the same one gateway.
The rest is Part 1
This page is deliberately short. The why of each layer, how a request reaches the model, the identity and policy planes, the full sovereignty argument and operational readiness are all in Part 1, and none of it changes with the cloud. Read them there. This page only shows the same diagram with the Google Cloud substrate in place of AWS.