Same Kubernetes, different defaults: know where the platforms diverge.

Topic	EKS	GKE
Hands-off compute	Auto Mode (managed Karpenter)	Autopilot (Pod-based billing)
Node autoscaling	Karpenter or Cluster Autoscaler	Cluster autoscaler, node auto-provisioning, Autopilot
Pod IPs	Real VPC IPs via ENIs: plan subnets	Alias IP secondary ranges: plan Pod range
Workload identity	Pod Identity or IRSA	Workload Identity Federation for GKE
Human access	IAM + access entries + RBAC	IAM + RBAC
Ingress and Gateway	AWS Load Balancer Controller, VPC Lattice	GKE Gateway controller
Control-plane upgrades	You trigger; version calendar and extended support	Release channels with automatic upgrades
Control-plane cost	Per-cluster hourly fee	Cluster management fee with a free-tier allowance

Portable

Workloads, Services, HPA, PDBs and probes behave identically.

Platform glue

Identity, ingress, storage classes, IP planning and upgrade tooling are where you rewrite things.

Verify prices

Fees and tiers change. Compare current pricing for your region and scale, including data transfer.

EKS and GKE side by side

For most application teams EKS and GKE feel the same. For the platform team the differences are in the platform glue. For hands-off compute, EKS offers Auto Mode and GKE offers Autopilot, with different billing models (nodes versus Pods). Node autoscaling is Karpenter or Cluster Autoscaler on EKS and cluster autoscaler, node auto-provisioning or Autopilot on GKE.

Networking differs most: EKS gives Pods real VPC IPs through ENIs, so you plan subnets and use prefix delegation or secondary CIDRs, while GKE VPC-native clusters use alias ranges you size per cluster. Workload identity is a first-class feature on both (Pod Identity or IRSA, Workload Identity Federation). EKS adds access entries for human access through IAM.

Operations differ in upgrade posture: GKE release channels automate control plane upgrades, while on EKS you trigger upgrades within the version calendar, with extended support as a paid safety valve. Pricing models also differ, so compare current figures.

Use this table to scope porting work if Shopwave ever moves a service between clouds: the Deployment and Service manifests move unchanged, and the identity, ingress and storage class pieces are what you rewrite. Deck 2 covers the GKE side in depth.