Gateway API Across GKE, EKS, AKS & On-Prem

Table of Contents#

1. Why This Part Exists
2. The Shared Pattern — a Facade Over Each Provider's Own Load Balancer
3. GKE Gateway Controller — Architecture
4. GKE GatewayClasses — Regional vs. Global, Internal vs. External
5. A Worked Example: GKE Gateway HTTPS Load Balancer
6. Multi-Cluster Gateways on GKE — the Config Cluster Model
7. GKE Certificate Management and Cloud Armor Integration
8. AWS: Two Distinct Paths to Gateway API on EKS
9. AWS Load Balancer Controller's Gateway API Support
10. The VPC Lattice Gateway API Controller — Cross-Cluster Service Networking
11. A Worked Example: VPC Lattice Across Two EKS Clusters
12. The EKS TCPRoute/UDPRoute Gap — Real Workarounds
13. Azure AKS: Application Gateway for Containers (AGC)
14. The ALB Controller — Frontends, Associations, and Reconciliation
15. AGC Deployment Models — Managed vs. Bring Your Own
16. A Worked Example: AGC on AKS
17. On-Prem and Bare-Metal — No Managed Facade to Lean On
18. MetalLB — Layer 2 vs. BGP Mode
19. A Worked Example: Wiring Envoy Gateway to MetalLB
20. On-Prem TLS Without a Cloud-Managed Certificate
21. Identity and IAM Integration Per Provider
22. Cost Considerations Across Providers
23. Observability Per Provider
24. Validating a Provider-Specific Gateway API Deployment Before Production
25. GKE Inference Gateway — Model-Aware Routing for AI Workloads
26. Weighted Traffic Splitting — Does It Travel Cleanly Across Providers?
27. WAF Integration Per Provider
28. Cross-Provider Comparison Table
29. Version and Upgrade Considerations Per Provider
30. Multi-Cloud and Hybrid Gateway API Strategy
31. Migrating From Ingress on Each Provider — What Actually Differs
32. Testing Gateway API Configuration in CI/CD
33. A Provider Decision Framework — Beyond the Implementation Choice
34. Key Terms Glossary — This Chapter's Vocabulary in One Place
35. Disaster Recovery and Failover Considerations Per Provider
36. Common Mistakes
37. Worked Practice Problems
38. A Full Worked Reference Architecture: Hybrid Cloud-Plus-On-Prem
39. Summary and What's Next

Why This Part Exists#

Part 8 covered the Gateway API specification itself and Envoy Gateway as a deliberately provider-agnostic, purpose-built reference implementation — the mechanics were visible because nothing was hidden behind a cloud vendor's own abstraction. Real production Kubernetes, though, mostly runs on managed platforms — Part 5 already compared EKS, AKS, and GKE at survey depth, and Part 7 went deep on EKS specifically. This Part asks a narrower, more practical question: when a team runs Gateway API on one of these managed platforms instead of a self-managed Envoy Gateway installation, what actually changes?

The answer, previewed here and made concrete section by section: every cloud provider implements Gateway API as a facade over its own existing, proprietary load-balancing product — Google Cloud Load Balancing, AWS VPC Lattice (or, via a second path, Application Load Balancer), and Azure's Application Gateway for Containers, respectively. This buys real operational stability and deep integration with each cloud's own certificate management, WAF, and IAM — at the cost of real portability, since the exact Gateway/HTTPRoute YAML that works cleanly on one provider can hit a genuinely different capability ceiling on another. On-prem infrastructure has no such managed facade at all, which is its own, differently-shaped tradeoff covered later in this chapter.

This chapter deliberately follows Part 5's own three-provider structure (EKS, AKS, GKE) and Part 6's on-prem coverage, revisiting each one specifically through the Gateway API lens Part 8 established — a team who has already internalized Part 5's broader EKS-vs-AKS-vs-GKE tradeoffs will recognize several of this chapter's own framing choices as direct extensions of that earlier comparison, now narrowed specifically to ingress and service networking.

The Shared Pattern — a Facade Over Each Provider's Own Load Balancer#

Worth stating the shared architectural pattern once, explicitly, before diving into each provider's own specifics — every managed implementation covered in this chapter follows the identical shape, just with a different backing product underneath.

This is the single fact worth carrying through the rest of this chapter: a Gateway object on GKE does not provision an Envoy Proxy Deployment the way Part 8's chapter showed — it provisions a real Google Cloud Load Balancer, an external, fully-managed piece of Google's own infrastructure, entirely outside the Kubernetes cluster itself. The same is true on AWS (a VPC Lattice resource, or an Application Load Balancer, depending on which of the two paths covered later is used) and on AKS (an Application Gateway for Containers resource). The Kubernetes-native YAML is identical in shape to Part 8's; what actually gets built underneath it is not.

GKE Gateway Controller — Architecture#

GKE's own Gateway controller watches the same Gateway/HTTPRoute objects covered in Part 8 and translates them into Google Cloud's global external (or regional/internal) load-balancing infrastructure automatically — no separate data-plane Deployment to manage inside the cluster at all.

The GKE Gateway controller running as part of the GKE control plane itself, rather than as a workload inside the cluster, is worth naming explicitly — it means there is no equivalent to Envoy Gateway's own envoy-gateway Deployment to monitor, upgrade, or troubleshoot inside a GKE cluster. Backend traffic reaches Pods through NEGs (Network Endpoint Groups), GCP's own mechanism for a cloud load balancer to route directly to individual Pod IPs rather than through a Kubernetes Service's own iptables/IPVS layer — the same NEG-based data path GKE's Ingress controller already used before Gateway API, now reused underneath Gateway API's newer resource model.

GKE GatewayClasses — Regional vs. Global, Internal vs. External#

GKE installs several distinct GatewayClass objects automatically, each corresponding to a different Google Cloud Load Balancer topology — a team's choice of which GatewayClass to reference in its own Gateway object is really a choice of load-balancer topology.

The -mc suffix is the single detail worth memorizing out of this entire table, since it's the one that determines whether a Gateway provisions single-cluster or multi-cluster load-balancing infrastructure — a genuinely different operational model covered in its own section below. A team building a straightforward, single-cluster public HTTPS endpoint reaches for gke-l7-global-external-managed; a team needing an internal-only endpoint reachable only from within its own VPC reaches for gke-l7-rilb instead — the same internal-vs-external distinction this course's networking material has covered for plain cloud load balancers generally, now expressed as a GatewayClass choice.

A Worked Example: GKE Gateway HTTPS Load Balancer#

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: external-https
  namespace: gateway-infra
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: my-cert
      allowedRoutes:
        namespaces:
          from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: checkout-route
  namespace: checkout
spec:
  parentRefs:
    - name: external-https
      namespace: gateway-infra
  rules:
    - backendRefs:
        - name: checkout-svc
          port: 8080

This YAML is, deliberately, almost identical to Part 8's own Envoy Gateway worked example — the persona split, the parentRefs attachment, the shape of HTTPRoute rules, all unchanged, since that's the entire point of a standardized specification. The only line that actually differs in a way that changes what gets provisioned underneath is gatewayClassName — swap it for envoy-gateway and the identical YAML instead provisions an Envoy Proxy Deployment inside the cluster rather than a real Google Cloud Load Balancer outside it. This portability is genuinely real for the Core/Extended conformance tiers covered in Part 8 — it stops being real the moment a team reaches for a provider-specific policy extension, exactly as Part 8's conformance-tiers section warned.

Multi-Cluster Gateways on GKE — the Config Cluster Model#

GKE's multi-cluster Gateway model introduces one further concept beyond anything covered so far in this series: a config cluster, a single, designated cluster where multi-cluster Gateway and HTTPRoute objects are actually deployed, even though the load balancer they provision routes traffic across multiple GKE clusters.

This is worth understanding as a genuinely different operational model from anything a single-cluster Gateway implies: a platform team does not deploy the same Gateway/HTTPRoute YAML to every member cluster — it's deployed exactly once, to the config cluster, and the multi-cluster Gateway controller propagates the resulting load-balancing configuration to route traffic across every member cluster's backend Pods automatically. This directly enables the same active-active, multi-region availability pattern this course's Reliability & Architecture series covers generally, now expressed as a single Kubernetes-native Gateway object rather than hand-wired regional load balancers stitched together outside Kubernetes entirely. A newer extension of this same model, multi-cluster GKE Inference Gateway, applies the identical config-cluster pattern specifically to AI/ML inference workloads, adding model-aware routing on top of the same multi-cluster foundation.

GKE Certificate Management and Cloud Armor Integration#

GKE Gateway integrates directly with Google-managed TLS certificates and Cloud Armor (Google's WAF/DDoS protection product) through the same parametersRef/policy-attachment idiom Part 8 already established as a general Gateway API extension pattern.

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: cloud-armor-policy
  namespace: gateway-infra
spec:
  default:
    securityPolicy: my-cloud-armor-policy
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: external-https

Google-managed certificates deserve specific mention as a genuine operational simplification over the self-managed cert-manager + Let's Encrypt pattern this course's DevSecOps series otherwise recommends generally — a ManagedCertificate resource, referenced from a Gateway's listener, has Google automatically provision and rotate a publicly-trusted TLS certificate with zero further action, an option that simply doesn't exist for a self-managed Envoy Gateway installation, which always needs an explicit certificate source (a cert-manager Issuer, or a manually-managed Secret).

AWS: Two Distinct Paths to Gateway API on EKS#

Worth stating precisely, since conflating these two is a genuinely common source of confusion: AWS offers TWO separate, independently-chosen paths to Gateway API on EKS, backed by two completely different underlying AWS products.

Path 1 (AWS Load Balancer Controller) is the more traditional, single-cluster-oriented path — the same controller EKS teams have long used for Ingress-based ALB provisioning now also reaching general availability for Gateway API's HTTPRoute/GRPCRoute, provisioning a standard Application Load Balancer. Path 2 (the VPC Lattice Gateway API Controller) is architecturally different and more ambitious — it provisions AWS VPC Lattice resources, a genuinely newer AWS networking product built specifically for service-to-service connectivity across multiple clusters, VPCs, and even AWS accounts, not just north-south ingress into one cluster. A team's choice between these two paths should be driven by scope: single-cluster ingress needs point toward Path 1's simpler ALB model; genuine multi-cluster/multi-account service networking needs point toward Path 2's VPC Lattice model.

AWS Load Balancer Controller's Gateway API Support#

For the simpler, single-cluster case, the same AWS Load Balancer Controller a team may already be running for Ingress-based ALB provisioning also implements Gateway API's HTTPRoute and GRPCRoute directly against a standard Application Load Balancer:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: alb-gateway
spec:
  controllerName: gateway.k8s.aws/alb

This path's genuine appeal is operational continuity — a team already running the AWS Load Balancer Controller for Ingress doesn't need to adopt any new AWS product or controller at all to gain Gateway API's typed routing model; the same familiar ALB, provisioned the same way, now configured through Gateway API's persona-split resources instead of Ingress annotations. This is worth recommending as the default first choice for a team whose actual need is "modernize our EKS ingress configuration model," without also introducing VPC Lattice's genuinely larger conceptual surface for a need that doesn't call for it.

The VPC Lattice Gateway API Controller — Cross-Cluster Service Networking#

The second path, the AWS Gateway API Controller (a distinct, separately-installed open-source project, fully supported by AWS), provisions VPC Lattice resources instead — worth understanding VPC Lattice's own value proposition before evaluating it against Path 1.

VPC Lattice's actual value proposition, stated precisely: it solves service-to-service connectivity across organizational and network boundaries (separate VPCs, separate AWS accounts, separate clusters run by separate teams) without requiring VPC peering, Transit Gateway routes, or any of the traditional AWS networking plumbing that cross-account service communication otherwise demands. A service in one EKS cluster reaches a service in a completely separate cluster/account's service network the same way it would reach any other backend — through a Gateway/HTTPRoute, or, for genuinely cross-cluster backend resolution, through ServiceExport/ServiceImport objects that publish a Service from one cluster into the shared Lattice service network for another cluster to consume.

A Worked Example: VPC Lattice Across Two EKS Clusters#

# In the PROVIDER cluster — export a Service into the shared Lattice service network
apiVersion: application-networking.k8s.aws/v1alpha1
kind: ServiceExport
metadata:
  name: inventory-svc
  namespace: inventory
  annotations:
    application-networking.k8s.aws/federation: "amazon-vpc-lattice"
---
# In the CONSUMER cluster (different VPC/account) — a GRPCRoute referencing the exported Service
apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: inventory-grpc
  namespace: checkout
spec:
  parentRefs:
    - name: shared-service-network-gw
  rules:
    - backendRefs:
        - group: application-networking.k8s.aws
          kind: ServiceImport
          name: inventory-svc

Worth naming the concrete gRpc-specific constraint this chapter's research turned up: a GRPCRoute's sectionName must refer to an HTTPS listener on its parent Gateway — plain HTTP is not a valid parent listener for gRPC traffic through this controller, consistent with gRPC's own general expectation of running over TLS in production. A team designing cross-cluster gRPC service communication on VPC Lattice needs an HTTPS-listening Gateway in place from the start, not something that can be deferred until later.

A further detail worth knowing for the genuinely cross-account case specifically: VPC Lattice service networks are shared across AWS accounts through AWS Resource Access Manager (RAM), the same account-sharing primitive this course's own IaC series covers for sharing other AWS resources (subnets, Transit Gateway attachments) across accounts. A platform team owning the shared service network resource shares it via a RAM resource share to each consuming account, which then associates its own EKS cluster's VPC into that shared service network — the same account-boundary-respecting, explicit-consent pattern already familiar from this chapter's own ReferenceGrant discussion in Part 8, now expressed at the AWS account level rather than the Kubernetes namespace level. A team new to VPC Lattice should expect this RAM-sharing step as a genuine prerequisite, configured once by whichever account owns the shared service network, before any consuming account's cluster can actually import or export services across it.

The EKS TCPRoute/UDPRoute Gap — Real Workarounds#

Part 8 already flagged this gap in passing — worth resolving it concretely here, since it's the single most consequential EKS-specific limitation covered in this chapter: neither AWS path (ALB Controller nor the VPC Lattice controller) currently supports TCPRoute or UDPRoute.

Neither workaround is a "wrong" answer — the right one depends on whether the team's broader design already commits to Gateway API as the single, unified routing model for everything, or is comfortable mixing models by concern. A plain LoadBalancer Service (provisioning a Network Load Balancer directly, entirely outside Gateway API) is the simpler, lower-conceptual-overhead choice for a team with just one or two TCP/UDP workloads alongside an otherwise HTTP-centric Gateway API setup. Running a second, self-managed Envoy Gateway installation (from Part 8) specifically for TCP/UDP routing needs, alongside AWS's own Gateway API path for HTTP/gRPC, is the better fit for a team that wants Gateway API's own typed resource model to remain the single source of truth for every routing rule, TCP/UDP included — a genuine tradeoff worth stating explicitly to a team rather than defaulting silently to either option.

Azure AKS: Application Gateway for Containers (AGC)#

Azure's Gateway API story centers on Application Gateway for Containers (AGC) — explicitly positioned as the next-generation successor to the older AGIC (Application Gateway Ingress Controller), purpose-built for Kubernetes rather than AGIC's older approach of watching Kubernetes resources and slowly reconciling them against a traditional, VM-based Application Gateway.

The "runs outside the cluster, no pod CPU spent on TLS" detail is worth calling out as a genuine architectural distinction from Envoy Gateway's own model (Part 8) specifically: where Envoy Gateway's managed data plane is a real Pod consuming real cluster CPU/memory for every connection it terminates, AGC's actual traffic-handling infrastructure is entirely external to the cluster — the in-cluster ALB Controller is a small, lightweight reconciliation loop only, translating Kubernetes objects into AGC's own external configuration, never touching real traffic itself. This mirrors GKE's own control-plane-hosted, no-in-cluster-data-plane pattern more closely than it mirrors Envoy Gateway's in-cluster data-plane model.

The ALB Controller — Frontends, Associations, and Reconciliation#

AGC's own resource model introduces two Azure-specific concepts worth understanding by name: Frontends (the listeners and IP addresses actually accepting incoming traffic) and Associations (the link between the AGC resource itself and the AKS cluster's own VNet/subnet).

apiVersion: alb.networking.azure.io/v1
kind: ApplicationLoadBalancer
metadata:
  name: alb-prod
  namespace: gateway-infra
spec:
  associations:
    - prod-alb-association

These two concepts map onto ideas this chapter has already covered under different names for other providers, worth recognizing rather than treating as wholly novel: a Frontend is functionally AGC's own version of a Gateway's listeners field — the actual port/protocol/IP combination accepting traffic — while an Association is roughly analogous to GKE's config-cluster relationship, the explicit link tying the managed load-balancing resource to a specific cluster's own network. The ALB Controller watches both Gateway API objects and legacy Ingress objects simultaneously, reconciling both into the same underlying AGC configuration — a deliberate design choice easing a gradual, mixed-model migration rather than forcing an all-at-once cutover, directly useful for a team following this course's own Part 8 migration guidance at a pace that suits them.

AGC Deployment Models — Managed vs. Bring Your Own#

AGC offers a genuine choice a team should make deliberately, mirroring a tradeoff familiar from this course's own IaC series: who owns the lifecycle of the underlying cloud resource.

This is precisely the same "does the Kubernetes-native controller own the cloud resource's lifecycle, or does it stay a thin reconciliation layer against infrastructure the platform team already provisions through its normal IaC pipeline" choice this course's GitOps chapter (Part 3 of the Automation, CI/CD & GitOps series) already covers generally for any Kubernetes operator managing external cloud state. A platform team with an existing, mature Terraform-based provisioning pipeline for Azure infrastructure has a real, well-grounded reason to prefer BYO — keeping the AGC resource itself under the same IaC discipline and change-review process as every other piece of their Azure infrastructure, rather than letting a Kubernetes controller manage it out-of-band.

A Worked Example: AGC on AKS#

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: azure-alb-external
spec:
  controllerName: alb.networking.azure.io/alb-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gw
  namespace: gateway-infra
  annotations:
    alb.networking.azure.io/alb-namespace: gateway-infra
    alb.networking.azure.io/alb-name: alb-prod
spec:
  gatewayClassName: azure-alb-external
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: prod-tls-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: checkout-route
  namespace: checkout
spec:
  parentRefs:
    - name: production-gw
      namespace: gateway-infra
  rules:
    - backendRefs:
        - name: checkout-svc
          port: 8080

Worth reading this alongside the GKE and Envoy Gateway worked examples from earlier in this chapter and Part 8 respectively: the Gateway and HTTPRoute shapes are, once again, essentially unchanged — the two annotations tying this Gateway to a specific ApplicationLoadBalancer resource are the only genuinely AKS-specific detail in the entire manifest. This repeated pattern across every provider covered in this chapter is the concrete, worked-through payoff of Gateway API's standardization: an engineer fluent in the core spec from Part 8 can read and reason about any of these provider-specific manifests immediately, with the provider-specific surface area confined to a small, clearly-marked set of extension fields and annotations rather than requiring the whole manifest to be re-learned per platform.

On-Prem and Bare-Metal — No Managed Facade to Lean On#

Every provider covered so far in this chapter shares one property this section's subject genuinely lacks: a managed cloud load balancer to provision underneath the Gateway object. On bare-metal or self-hosted infrastructure (Part 6's own subject), there is no Google Cloud Load Balancer, VPC Lattice, or Application Gateway for Containers waiting to be provisioned — a Gateway's listener has to be backed by something a team stands up itself.

The concrete, easy-to-miss failure mode worth naming precisely: a plain Kubernetes cluster (kubeadm, k3s, or any of Part 6's other self-managed distributions) has no built-in implementation for Service type LoadBalancer at all — the External IP field simply stays Pending indefinitely, since nothing in a stock cluster knows how to actually provision one. This is exactly the same underlying gap that Envoy Gateway's own managed Envoy Proxy Deployment (Part 8) runs into on bare metal specifically: the Deployment itself comes up fine, but the Service fronting it, which the implementation expects to be of type LoadBalancer to receive real external traffic, has no external IP assigned without further action.

MetalLB — Layer 2 vs. BGP Mode#

MetalLB is the de facto standard solution to this exact gap — worth understanding its two distinct operating modes, since the choice between them is a real, environment-dependent decision, not a matter of preference.

Layer 2 mode's own real limitation is worth stating precisely, since it's a common point of confusion: only ONE node actually handles traffic for a given assigned IP at any moment — Layer 2 mode provides failover (a different node takes over the IP if the current owner fails) but not genuine load distribution across multiple nodes simultaneously. BGP mode is the answer when a team specifically needs traffic for one external IP spread across several nodes concurrently, at the cost of requiring BGP peering configuration on the surrounding physical network infrastructure — a real coordination dependency with a team's network engineers that Layer 2 mode avoids entirely.

A Worked Example: Wiring Envoy Gateway to MetalLB#

# 1. MetalLB IPAddressPool — the range of IPs MetalLB is allowed to assign
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: production-pool
  namespace: metallb-system
spec:
  addresses:
    - 10.10.20.100-10.10.20.150
---
# 2. L2Advertisement — advertise this pool via Layer 2 mode
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: production-pool-l2
  namespace: metallb-system
spec:
  ipAddressPools:
    - production-pool
---
# 3. EnvoyProxy CRD (from Part 8) — explicitly requesting a LoadBalancer Service
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: onprem-proxy-config
  namespace: envoy-gateway-system
spec:
  provider:
    type: Kubernetes
    kubernetes:
      envoyService:
        type: LoadBalancer

Reading this end to end: MetalLB's IPAddressPool and L2Advertisement do the actual work of turning a Pending LoadBalancer Service into one with a real, externally-reachable IP — the exact gap this chapter's previous section named — while the EnvoyProxy CRD (already introduced in Part 8) is what explicitly tells Envoy Gateway's managed Envoy Proxy Deployment to request a LoadBalancer-typed Service in the first place, rather than defaulting to ClusterIP. Once both pieces are in place, everything from Part 8 — GatewayClass, Gateway, HTTPRoute, the entire persona model — works completely unmodified on top of this now-functioning bare-metal foundation.

On-Prem TLS Without a Cloud-Managed Certificate#

A further concrete gap worth resolving explicitly: this chapter's GKE section highlighted Google-managed certificates as a genuine convenience unavailable to self-managed infrastructure — on-prem has no equivalent, and needs an explicit TLS certificate source.

The DNS-01-over-HTTP-01 recommendation deserves specific emphasis for on-prem environments particularly, worth stating precisely why: an HTTP-01 ACME challenge requires the certificate authority to reach the Gateway over the public internet to validate domain ownership — a real obstacle for an on-prem Gateway that's deliberately not publicly internet-reachable at all (an internal-only corporate service, for instance). A DNS-01 challenge instead proves domain ownership by creating a DNS TXT record, requiring no inbound internet reachability to the Gateway itself — the correct default for on-prem TLS automation via cert-manager, and the same underlying mechanism this course's DevSecOps series already covers for cert-manager generally, now specifically relevant because on-prem infrastructure can't lean on a cloud-managed certificate shortcut the way GKE can.

Identity and IAM Integration Per Provider#

Worth a dedicated section on a dimension this chapter hasn't yet covered explicitly: how each provider's Gateway API implementation integrates with that cloud's own identity system — directly relevant to any team also implementing the OIDC/workload-identity patterns this course's CI/CD & GitOps series covers for pipeline authentication.

The detail worth emphasizing across all three cloud providers: the Gateway API controller ITSELF needs cloud IAM permissions to provision the underlying load-balancing infrastructure, separate from and in addition to whatever identity the backend application Pods use. On EKS, the AWS Gateway API Controller (whichever path) runs under its own IAM role (via Pod Identity or IRSA, per Part 7) with permission to create/modify ALB or VPC Lattice resources — a real, auditable IAM boundary worth reviewing during any security assessment of the cluster, since a compromised Gateway API controller with overly broad IAM permissions could provision or modify load-balancing infrastructure well beyond its intended scope. The same reasoning applies to GKE's Gateway controller and AKS's ALB Controller, each needing scoped IAM/RBAC permissions over their respective cloud's load-balancing resources, distinct from any backend Pod's own workload identity.

Cost Considerations Across Providers#

Worth a direct, practical cost comparison, since "which Gateway API path costs less" is a genuinely common question this chapter's earlier sections haven't addressed head-on.

The multi-cluster GKE detail deserves the strongest emphasis in this table, since it's a genuine, non-obvious cost advantage: a single multi-cluster GKE Gateway serving three member clusters is billed as one load balancer, not three — a real, structural cost efficiency for a team already choosing GKE's multi-cluster model for availability reasons, worth factoring into any GKE-vs-EKS-vs-AKS total-cost-of-ownership comparison a platform team runs, alongside Part 5's own broader managed-Kubernetes cost comparison.

Observability Per Provider#

Part 8's Envoy Gateway observability section covered Prometheus-native metrics directly from the managed Envoy Proxy Deployment — worth clarifying explicitly that this does NOT carry over unmodified to the cloud-managed paths covered in this chapter, since none of them run an Envoy (or any userspace proxy) inside the cluster at all.

This is worth internalizing as a direct, practical consequence of this chapter's own opening "facade over the provider's own product" framing: a GKE Gateway's request metrics live in Cloud Monitoring, an EKS ALB's metrics live in CloudWatch, an AKS AGC's metrics live in Azure Monitor — none of them expose a /stats/prometheus endpoint the way Envoy Gateway's own managed data plane does, because none of them are actually running Envoy (or any proxy a team has direct access to) inside the cluster at all. A platform team standardizing observability tooling across a genuinely multi-cloud or hybrid (cloud-plus-on-prem) Gateway API deployment needs to bridge this gap explicitly — either ingesting each cloud's native metrics into a shared Grafana/Prometheus stack via that cloud's own exporter (a Cloud Monitoring-to-Prometheus bridge, a CloudWatch exporter), or accepting genuinely separate, per-provider observability tooling for the ingress layer specifically, even while application-level metrics remain unified.

Validating a Provider-Specific Gateway API Deployment Before Production#

Worth a closing, practical checklist synthesizing this chapter's own debugging guidance (Part 8's status-conditions section) with the provider-specific gaps this chapter has catalogued — a concrete sequence for validating any of the four provider paths before real production traffic depends on it.

Step 2 deserves the strongest emphasis of the five, since it's the step most commonly skipped by a team trusting kubectl get gateway output alone: a Gateway object reporting Programmed: True confirms the Kubernetes-side reconciliation succeeded, but the actual cloud resource — a real Google Cloud Load Balancer, a real AWS ALB or VPC Lattice service, a real AGC resource — is a separate piece of infrastructure worth confirming directly exists and is healthy in that cloud provider's own console or CLI, not inferred purely from Kubernetes-side status. This is the same "the Kubernetes object is a declaration; verify the real infrastructure it's supposed to represent actually matches" discipline this course has argued for consistently since Part 1's own CNI/CSI coverage, now applied specifically to the cloud-managed load-balancing facades this chapter has spent its length cataloging.

GKE Inference Gateway — Model-Aware Routing for AI Workloads#

Worth a dedicated closing look at the newest extension of GKE's own Gateway model, mentioned in passing earlier in this chapter's multi-cluster section: GKE Inference Gateway, purpose-built for routing traffic to AI/ML model-serving backends rather than general-purpose HTTP services.

The concrete distinction from standard HTTPRoute load balancing worth stating precisely: a generic HTTP load balancer treats every backend replica as interchangeable, routing by simple round-robin or least-connections — genuinely wrong for LLM inference workloads, where a request routed to a replica that already has relevant KV-cache state warmed for that request's context serves measurably faster than an identical request routed to a cold replica. GKE Inference Gateway extends the standard Gateway API model specifically to account for this — the same underlying Gateway/HTTPRoute resource model from Part 8, with an additional, purpose-built routing layer aware of model-serving-specific signals a generic Gateway API implementation has no visibility into at all. This is worth flagging as a genuinely emerging pattern rather than a mature, universally-adopted one — a team running LLM inference workloads at real production scale on GKE specifically is the concrete audience for this feature; a team running conventional HTTP/gRPC services has no need for it, and every other section of this chapter applies to them unmodified.

Weighted Traffic Splitting — Does It Travel Cleanly Across Providers?#

Part 8 covered HTTPRoute's native weight field on backendRefs as the mechanism a progressive-delivery tool like Argo Rollouts or Flagger drives during a canary rollout — worth directly checking whether that specific capability, genuinely important for any team running canary deployments, is one of the portable Core/Extended fields or a provider-specific gap.

rules:
  - backendRefs:
      - name: checkout-svc-stable
        port: 8080
        weight: 90
      - name: checkout-svc-canary
        port: 8080
        weight: 10

The reassuring finding worth stating directly: weighted traffic splitting via backendRefs.weight is a Core Gateway API field, and every provider covered in this chapter — GKE, both EKS paths, AKS's AGC, and on-prem Envoy Gateway — implements it identically, with the identical YAML shown above working unmodified across all of them. This matters concretely for any team running Argo Rollouts or Flagger (this course's CI/CD & GitOps series) against a multi-cloud or migrating-between-clouds environment: the progressive-delivery controller's own canary-weight-adjustment logic needs zero provider-specific branching, since it's driving the exact same standardized field regardless of which cloud (or on-prem) implementation sits underneath. This is worth calling out as one of the strongest concrete, testable proofs of this chapter's own "portable core" claim — not every capability travels this cleanly (TCPRoute on EKS, covered earlier, very much does not), but this specific, high-value one does.

WAF Integration Per Provider#

GKE's Cloud Armor integration, covered earlier in this chapter, is one instance of a broader pattern worth completing symmetrically for the other two cloud providers — each cloud's own Gateway API path integrates with that cloud's own native WAF product through the identical policy-attachment idiom.

The pattern worth internalizing across all four rows: WAF configuration is, without exception, an implementation-specific extension — never a Core or Extended Gateway API field — consistent with Part 8's own conformance-tiers framing that security/policy concerns beyond the core routing model are deliberately left to each implementation's own extension mechanism, rather than standardized centrally. A team designing a genuinely portable Gateway API strategy (per this chapter's own multi-cloud strategy section) should expect to maintain separate, provider-specific WAF configuration for each environment — there is no portable, cross-provider WAF policy expressible in vanilla Gateway API YAML today.

Cross-Provider Comparison Table#

Worth consolidating every provider covered across this chapter into one reference table, directly extending the implementation-comparison table from Part 8 with the provider dimension this chapter adds.

The TCPRoute/UDPRoute column is worth reading as this table's most consequential single finding: every cloud-managed path in this chapter lacks native TCPRoute/UDPRoute support, while the self-managed, on-prem Envoy Gateway path (from Part 8) supports both natively. This is a genuinely counter-intuitive result worth internalizing — the "simpler," fully self-managed option is, on this one specific dimension, more capable than any of the three cloud-managed facades, precisely because it isn't constrained by what each cloud's own underlying proprietary product happens to support yet.

Version and Upgrade Considerations Per Provider#

Worth a closing operational note tying back to Part 7's own upgrade-strategy discipline: each of the four paths covered in this chapter carries a genuinely different upgrade/versioning burden, worth planning for explicitly rather than discovering during an actual upgrade.

This upgrade-burden gradient tracks directly with the "managed facade vs. self-managed" spectrum this entire chapter has been organized around, worth stating as one final, unifying observation: GKE's Gateway controller requires zero action from a platform team to stay current, since Google upgrades it as an inseparable part of the GKE control plane itself — the same "the platform team doesn't own this layer's lifecycle" property that also explains GKE's earlier-covered Google-managed certificate convenience. The self-managed paths (EKS's controllers, and especially on-prem Envoy Gateway) require the platform team to track upstream releases, test upgrades in a non-production environment, and plan maintenance windows — the identical operational discipline this course's CI/CD & GitOps series already argues for regarding any self-hosted infrastructure generally, now applying specifically to whichever Gateway API layer a team has chosen to own themselves.

Multi-Cloud and Hybrid Gateway API Strategy#

Worth closing this chapter's provider survey with the practical question a genuinely multi-cloud or hybrid organization actually faces: can the same Gateway API design be reused unmodified across GKE, EKS, AKS, and on-prem clusters simultaneously?

The practical, honest answer, directly extending Part 8's own conformance-tiers framing: routing logic expressed purely in Core/Extended HTTPRoute/GRPCRoute fields genuinely is portable across every provider covered in this chapter — the same route rules, the same header matching, the same weighted traffic splitting, all work unmodified regardless of which gatewayClassName a Gateway references. What does NOT travel between providers is TLS certificate configuration (each provider's own certificate mechanism, per this chapter's own comparison table), any implementation-specific policy CRD (rate limiting, WAF, security policies — each provider's own extension), and, for EKS specifically, TCP/UDP routing entirely. A genuinely portable multi-cloud/hybrid Gateway API design keeps routing logic in the portable core, and treats every certificate reference and policy extension as an explicit, provider-specific overlay layered on top per environment — the same "portable core, provider-specific edges" discipline this course's IaC series already argues for generally with Terraform modules, now applied to Gateway API design specifically.

Migrating From Ingress on Each Provider — What Actually Differs#

Part 8 covered ingress2gateway as a provider-agnostic migration tool — worth closing the loop here with what genuinely differs about running that same migration on each specific managed platform, since the generic tool's output still needs provider-specific finishing.

The AKS case is worth calling out as the gentlest migration path covered in this chapter, precisely because of a detail already established earlier: the ALB Controller reconciles both legacy Ingress and Gateway API objects simultaneously against the same underlying AGC resource. A team can migrate one HTTPRoute at a time, leaving the rest of their traffic on the older Ingress object, with both coexisting cleanly during the transition — a meaningfully lower-risk cutover than a provider whose Gateway API controller has no equivalent dual-mode reconciliation. GKE and EKS migrations, by contrast, more commonly involve a cleaner cutpoint — validating the generated Gateway API resources in a non-production environment first (per Part 8's own migration discipline), then switching DNS or traffic weighting over in a single deliberate step.

Testing Gateway API Configuration in CI/CD#

Worth a closing, practical connection back to this course's own Automation, CI/CD & GitOps series: how does a platform team actually validate a Gateway/HTTPRoute change before it reaches production, given everything this chapter has established about provider-specific behavior?

The "same provider as production" detail deserves the strongest emphasis, and it's a direct, practical consequence of nearly everything this chapter has established: testing a GKE-bound HTTPRoute change against an on-prem Envoy Gateway test cluster would validate the portable Core/Extended routing logic correctly, but would tell a team nothing about whether the change actually provisions correctly against real Google Cloud Load Balancing infrastructure — exactly the kind of provider-specific gap (TLS certificate issuance, WAF attachment, TCPRoute support) this entire chapter has catalogued as NOT portable. A genuinely trustworthy CI pipeline for Gateway API changes needs an ephemeral test cluster on the same actual provider production runs on, not merely "a Kubernetes cluster somewhere" — the same principle this course's CI/CD & GitOps series already argues for staging environments generally, now made concrete for the specific case of provider-facade infrastructure this chapter has spent its length explaining.

A Provider Decision Framework — Beyond the Implementation Choice#

Part 8 closed with a decision framework for choosing an implementation (Envoy Gateway vs. Istio vs. Cilium, etc.). This chapter's own closing decision framework operates one level up — for a team that has already chosen a cloud provider (or is choosing between them), which Gateway API path within that provider fits their actual need.

Every branch in this flow maps directly to a section already covered in depth across this chapter — this is a navigation aid back into the chapter's own content, not a new argument. The recurring shape worth noticing across all three cloud providers: the deciding question is almost never "which is technically better" in the abstract, but "which matches a genuine, already-existing organizational need" — multi-cluster availability requirements, cross-account service boundaries, or an existing IaC discipline the team isn't willing to bypass.

Key Terms Glossary — This Chapter's Vocabulary in One Place#

This table deliberately mirrors the same closing-glossary pattern Part 8 already used, and the CI/CD & GitOps series' self-hosted runner chapter before that — a quick lookup aid for a chapter this dense in provider-specific terminology introduced across a short span.

Disaster Recovery and Failover Considerations Per Provider#

Worth a dedicated closing section on a dimension every platform team eventually has to answer: what happens to Gateway API-fronted traffic when an entire region, or an entire cluster, goes down — directly extending this course's own Reliability & Architecture series into the Gateway API context specifically.

The GKE multi-cluster model's failover property is worth the strongest emphasis in this section, since it's a genuinely different failure-handling shape from the other two cloud paths: because a multi-cluster Gateway is backed by one shared load balancer with visibility into all member clusters' backend health simultaneously, an entire cluster or region going unhealthy is handled by that same load balancer routing traffic to the remaining healthy clusters — no separate DNS failover mechanism, and no DNS TTL-driven propagation delay, is involved at all. The AWS ALB path and the AKS AGC path, by contrast, each provision one load-balancing resource scoped to a single cluster — genuine cross-region failover for either requires an additional layer on top (Route 53 health-check-driven DNS failover for AWS, Azure Traffic Manager or Front Door for AKS), introducing DNS propagation delay as a real, if usually modest, part of the actual failover time. VPC Lattice's cross-cluster service network sits in between — closer to GKE's model for the specific services actually exported/imported across the service network, though without GKE's own single-shared-LB simplicity for a general ingress endpoint. A platform team designing for genuine multi-region availability should weigh this real, structural difference alongside every other factor in this chapter's own provider comparison — it's not a minor operational detail, but a meaningful difference in actual failover latency during a real regional incident.

Common Mistakes#

Worked Practice Problems#

Problem 1: A platform team wants a single public HTTPS endpoint on GKE, provisioned once, routing traffic across three separate GKE clusters in different regions. Which GatewayClass family should they use, and where do they deploy the Gateway/HTTPRoute objects?

Answer: A multi-cluster GatewayClass — specifically gke-l7-global-external-managed-mc for a global, external endpoint (the -mc suffix is the detail that matters here). The Gateway and HTTPRoute objects are deployed exactly once, to the designated config cluster, not replicated to all three member clusters — the GKE multi-cluster Gateway controller propagates the resulting load-balancing configuration across all three clusters' backend Pods automatically from that single config-cluster deployment.

Problem 2: A team on EKS needs genuine cross-account service connectivity — Team A's cluster in Account 1 needs to reach Team B's service running in a completely separate cluster in Account 2, with no VPC peering already configured between the two accounts. Which of the two AWS Gateway API paths fits this need, and why?

Answer: The VPC Lattice Gateway API Controller (Path 2), not the AWS Load Balancer Controller (Path 1). VPC Lattice's entire value proposition is solving exactly this cross-account, cross-VPC service connectivity problem without requiring VPC peering or Transit Gateway routes — Team B exports its service via ServiceExport into the shared Lattice service network, and Team A's cluster consumes it via ServiceImport, referenced from a GRPCRoute or HTTPRoute. The ALB Controller path is scoped to single-cluster ingress and doesn't solve this cross-account problem at all.

Problem 3: A team building a custom binary TCP protocol service needs it exposed through their existing EKS Gateway API setup (currently using the ALB Controller path for their HTTP services). What are their realistic options, and what's the tradeoff between them?

Answer: Neither AWS Gateway API path supports TCPRoute today, so two realistic options exist: (1) provision a plain Kubernetes Service of type LoadBalancer for this one TCP service, entirely outside Gateway API, which is simpler but means this one service's routing lives outside the team's otherwise-unified Gateway API model; or (2) stand up a second, self-managed Envoy Gateway installation (from Part 8) specifically for TCP/UDP routing needs, keeping Gateway API as the single source of truth for all routing, at the cost of running and maintaining a second Gateway API implementation alongside AWS's own. The right choice depends on how many such TCP/UDP services exist and how much the team values a single unified routing model versus operational simplicity for a one-off need.

Problem 4: A platform team runs an internal-only, non-publicly-reachable Gateway on a bare-metal on-prem cluster and needs a real TLS certificate for it via cert-manager. Their first attempt, using an HTTP-01 ACME challenge, fails. Why, and what should they use instead?

Answer: HTTP-01 challenges require the certificate authority (Let's Encrypt, in the typical case) to reach the Gateway directly over the public internet to validate domain ownership — an internal-only Gateway, by definition, isn't publicly reachable, so the challenge can never complete. The fix is switching cert-manager's Issuer to a DNS-01 challenge instead, which proves domain ownership via a DNS TXT record and requires no inbound internet reachability to the Gateway at all — the correct default recommendation for on-prem/internal Gateway TLS automation.

Problem 5: An AKS platform team already manages all of their Azure infrastructure through a mature, long-standing Terraform pipeline with strict change-review requirements. Which AGC deployment model should they choose, and why, per this chapter's own framing?

Answer: Bring Your Own (BYO) — managing the Application Gateway for Containers resource, its Association, and its Frontends through their existing Terraform pipeline, with the in-cluster ALB Controller only reconciling routing configuration against infrastructure it doesn't own the lifecycle of. Letting the ALB Controller auto-manage the AGC resource's lifecycle would create a second, out-of-band infrastructure-management path sitting outside the team's existing IaC discipline and change-review process — exactly the mismatch this chapter's own GitOps-lifecycle-ownership framing warns against.

Problem 6: A platform team is designing for genuine multi-region availability and is comparing GKE's multi-cluster Gateway model against a single-cluster-per-region EKS ALB Controller setup with Route 53 failover on top. Which offers faster failover during a real regional outage, and why?

Answer: GKE's multi-cluster Gateway model offers meaningfully faster failover — because it's backed by ONE shared load balancer with direct visibility into all member clusters' backend health simultaneously, an unhealthy region is handled by that same load balancer routing traffic to remaining healthy clusters, with no separate DNS failover step and no DNS TTL-driven propagation delay. The EKS-with-Route-53 setup, by contrast, requires a genuinely separate DNS failover mechanism to detect the regional ALB's unhealthy state and update DNS records accordingly — introducing real, if usually modest, propagation delay as clients' own DNS caches and resolvers catch up to the change, on top of the health-check detection time itself.

Problem 7: A security-conscious platform team is auditing IAM permissions across their multi-cloud Gateway API deployment and wants to know: whose IAM identity actually provisions the underlying load-balancing infrastructure — the application team's, or something else?

Answer: The Gateway API controller's own IAM identity — on EKS, the AWS Gateway API Controller (whichever path) runs under its own IAM role via Pod Identity or IRSA, distinct from and in addition to whatever identity the backend application Pods themselves use. The same separation holds for GKE's Gateway controller and AKS's ALB Controller. This is worth auditing specifically, since an overly broad IAM role granted to the Gateway API controller itself — not to any application Pod — is the actual blast radius if that controller were ever compromised, a distinct risk surface from application-level workload identity that a security review needs to check separately.

Problem 8: A team validates a new GKE Gateway deployment by running kubectl get gateway and seeing Programmed: True. They declare the migration complete and cut production DNS over immediately. What did they skip, per this chapter's own validation checklist, and why does it matter?

Answer: They skipped confirming the actual underlying Google Cloud Load Balancer resource exists and is healthy in the GCP console/CLI directly — Programmed: True confirms the Kubernetes-side reconciliation succeeded, not that the real cloud infrastructure it represents is fully provisioned, healthy, and correctly serving traffic. This chapter's validation checklist treats that as a separate, necessary step precisely because the Kubernetes object is a declaration of intent, and the real infrastructure it's supposed to represent deserves independent confirmation before production traffic depends on it — skipping this step risks a DNS cutover onto infrastructure that looks correctly configured from Kubernetes' own point of view but isn't actually serving traffic correctly yet.

A Full Worked Reference Architecture: Hybrid Cloud-Plus-On-Prem#

Worth closing this chapter's provider survey with one realistic, composite scenario tying together material from across the entire chapter — a regulated organization (subject to real data-residency requirements, per this course's DevSecOps series) running its primary production workload on GKE, with an on-prem disaster-recovery site required to stay within a specific national border.

The architectural reasoning worth stating explicitly, since it ties together nearly every section of this chapter into one coherent design decision: GKE's own multi-cluster Gateway model (covered earlier in this chapter) already handles single-region failure within GKE itself, with no separate DNS failover needed — so the on-prem site in this design exists for a genuinely different failure mode entirely: total unavailability of the cloud provider itself, or a regulatory requirement that data must remain within infrastructure the organization directly controls, neither of which multi-region cloud redundancy alone satisfies. The on-prem site uses this chapter's own MetalLB-plus-Envoy-Gateway pattern, kept in a warm-or-cold standby state (periodically validated with real synthetic traffic, per this course's own DR-testing discipline elsewhere in the series) and activated via a DNS-level cutover only in the genuinely rare event the entire GKE deployment becomes unavailable — a deliberately different, coarser-grained failover trigger than GKE's own fine-grained, sub-region-level health-based routing.

This composite design is also the clearest illustration in this entire chapter of the "portable core, provider-specific edges" principle from this chapter's own multi-cloud strategy section: the HTTPRoute routing rules governing application traffic are, in principle, near-identical between the GKE primary and the on-prem DR site — the same Core/Extended Gateway API fields, expressing the same routing intent — while everything genuinely different (TLS certificate sourcing: Google-managed vs. cert-manager-plus-DNS-01; the underlying load-balancing infrastructure: Google Cloud Load Balancing vs. MetalLB-fronted Envoy) is confined to the small, clearly-bounded set of provider-specific fields this entire chapter has spent its length cataloging.

Summary and What's Next#

Every managed Kubernetes platform covered in this chapter implements the exact same Gateway API specification from Part 8 as a facade over its own pre-existing, proprietary load-balancing product — GKE over Google Cloud Load Balancing (with a genuinely native multi-cluster model built around a designated config cluster and -mc-suffixed GatewayClasses), AWS over either a traditional Application Load Balancer or, for genuine cross-cluster/cross-account service networking, VPC Lattice, and AKS over Application Gateway for Containers (with a deliberate managed-vs-BYO lifecycle choice mirroring this course's own IaC lifecycle-ownership guidance). Routing logic expressed in Gateway API's Core and Extended conformance tiers is genuinely portable across every one of these providers, verified concretely across this chapter's nearly-identical worked examples — what doesn't travel is TLS certificate mechanics, implementation-specific policy extensions, and, notably, TCP/UDP routing on EKS specifically, where neither AWS path currently implements TCPRoute/UDPRoute at all, a genuine capability gap only the self-managed Envoy Gateway path from Part 8 closes. On-prem and bare-metal infrastructure has no managed facade to lean on whatsoever — MetalLB fills the LoadBalancer-provisioning gap every cloud provider's own infrastructure closes automatically, and DNS-01 ACME challenges via cert-manager fill the certificate gap that GKE's Google-managed certificates close automatically — meaning an on-prem Gateway API deployment genuinely is more hands-on than any cloud-managed path, in direct exchange for the one capability (native TCPRoute/UDPRoute support) none of the cloud-managed paths in this chapter currently offer.

This closes the two-part Gateway API arc within this series, and with it, the full nine-part Kubernetes Deep Dive series. Part 1 established the control-plane fundamentals every later part built on; Parts 2-4 covered workloads, networking/storage, and service mesh; Parts 5-7 went from a three-way managed-platform comparison to full production depth on EKS specifically; Parts 8-9 closed the series on Kubernetes' own newest major networking model — the specification itself, its most architecturally instructive reference implementation, and the genuinely different shape it takes across every real place a production cluster actually runs.

The transferable skill this two-part arc was built to leave behind, echoing this course's own recurring theme: a standardized Kubernetes-native specification buys real, verifiable portability for its Core and Extended fields, and that portability is worth actively designing toward — keeping routing logic in the portable tier, and treating every certificate mechanism, policy extension, and provider-specific capability gap as a clearly-bounded, explicitly-documented edge, rather than letting provider-specific detail silently creep into the parts of a design that were meant to travel.