Q: When designing an enterprise multi-cloud or greenfield Kubernetes foundation, how do you evaluate Amazon EKS against Google Cloud GKE? In an executive or staff interview, contrast their networking architectures (IP allocation & CNI), autoscaling mechanisms, control plane upgrade safety, and operational total cost of ownership (TCO).

Amazon EKS utilizes the AWS VPC CNI plugin, assigning routable VPC IP addresses directly to each pod from the host subnet. This provides seamless direct communication with native AWS services (RDS, ElastiCache), but risks rapid subnet IP exhaustion unless engineers implement prefix delegation (`ENABLE_PREFIX_DELEGATION=true`) or secondary non-routable CGNAT CIDRs (100.64.0.0/10). Google GKE utilizes VPC-native clusters backed by Google Cloud Alias IPs and Dataplane V2 (eBPF-powered Cilium). GKE decouples Pod CIDRs from Node subnets at cluster creation without secondary ENI attachment overhead, virtually eliminating ENI allocation latency.

# Enable AWS VPC CNI prefix delegation to solve pod IP exhaustion
kubectl set env daemonset aws-node -n kube-system \
  ENABLE_PREFIX_DELEGATION=true \
  WARM_PREFIX_TARGET=1

# GKE VPC-native cluster creation with dedicated Pod & Service ranges
gcloud container clusters create prod-gke \
  --enable-ip-alias \
  --create-subnetwork name=gke-subnet,range=10.10.0.0/20 \
  --cluster-secondary-range-name=gke-pods,cluster-ipv4-cidr=10.20.0.0/16 \
  --services-secondary-range-name=gke-services,services-ipv4-cidr=10.30.0.0/20

AWS EKS traditionally relied on the Kubernetes Cluster Autoscaler (CAS) interacting with EC2 Auto Scaling Groups (ASGs). Modern EKS deployments bypass ASGs entirely using Karpenter, a high-velocity JIT provisioner that evaluates pending pod requirements and directly calls EC2 Fleet APIs to spin up optimal instances in under 45 seconds. Google GKE provides built-in Node Auto-Provisioning (NAP) based on CAS, as well as GKE Autopilot—a fully managed serverless Kubernetes mode where Google manages node provisioning, sizing, and OS hardening entirely behind the scenes, billing customers per pod CPU/RAM request rather than underlying VM capacity.

# Karpenter NodePool definition for AWS EKS
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default

GKE offers automated release channels (Rapid, Regular, Stable) with built-in maintenance windows and blue-green node pool upgrades. Google handles control plane patches and minor upgrades transparently, often rolling out security hotfixes within 24 hours of upstream CVE disclosure. AWS EKS provides a deliberate, manual upgrade lifecycle: operators must explicitly initiate control plane upgrades via AWS CLI or Terraform, followed by updating add-ons (VPC CNI, CoreDNS, kube-proxy) and rolling managed node groups. EKS provides greater operational control and predictability, but demands higher ongoing platform engineering maintenance.

# Initiating EKS minor version control plane upgrade via AWS CLI
aws eks update-cluster-version \
  --name prod-cluster \
  --kubernetes-version 1.32

Both clouds allow pods to assume cloud IAM roles without long-lived credentials. EKS offers modern EKS Pod Identity (daemon-based) or legacy IAM Roles for Service Accounts (IRSA using OIDC token projection). GKE pioneered this pattern with Workload Identity Federation, integrating seamlessly into Google Cloud IAM policies. GKE's implementation is natively integrated into Google Cloud SDKs, whereas AWS requires deploying the EKS Pod Identity Agent DaemonSet or configuring trust policies with OIDC thumbprints.