AWS recently shipped general availability support for Kubernetes Gateway API in its Load Balancer Controller. With this release, the company allows teams to manage Application Load Balancers and Network Load Balancers through the Gateway API specification, a Kubernetes SIG-maintained standard that’s been gaining traction as the successor to the aging Ingress API.
This matters because it dumps annotation challenges. Before the Gateway API, users configured load balancers by cramming JSON into Kubernetes annotations. No schema validation, no IDE support, just strings that could break at runtime. Now users get type-safe Custom Resource Definitions (CRDs) with proper validation and GitOps-friendly YAML.
The AWS Load Balancer Controller now handles both Layer 4 routes (TCP, UDP, TLS via Network Load Balancer) and Layer 7 routes (HTTP, gRPC via Application Load Balancer) using Gateway API resources. This completes AWS’s Gateway API coverage, as VPC Lattice already supported it for east-west service mesh traffic. Together, they cover north-south ingress and east-west service communication using the same Kubernetes-native API.
The old way looked like this: stuff target-group attributes, health-check configs, and stickiness settings into annotation strings. The new approach uses three CRDs: TargetGroupConfiguration, LoadBalancerConfiguration, and ListenerRuleConfiguration that validate at apply time instead of failing mysteriously at runtime.
Example: configuring deregistration delay used to require parsing this annotation:
alb.ingress.kubernetes.io/target-group-attributes: |
deregistration_delay.timeout_seconds=30,
stickiness.enabled=true
Now it’s structured data:
apiVersion: gateway.k8s.aws/v1beta1
kind: TargetGroupConfiguration
spec:
targetGroupAttributes:
- key: deregistration_delay.timeout_seconds
value: "30"
- key: stickiness.enabled
value: "true"
Gateway API splits responsibilities across three resources. Platform teams define GatewayClass (infrastructure templates), cluster operators configure Gateway (listeners, TLS, subnet placement), and app developers create Routes (path-based routing, header matching). This maps cleanly to RBAC boundaries; developers don’t need cluster-admin to route traffic.
(Source: AWS Networking & Content Delivery blog post – API Gateway Components)
Cross-namespace routing works now, too. A platform team provisions a shared Gateway within a single namespace. Application teams in separate namespaces create HTTPRoutes that reference them. The controller automatically configures the load balancer without requiring developers to touch infrastructure-level settings such as security groups or VPC subnets.
AWS engineers Alexandra Huides and Zac Nixon wrote in the announcement that automatic TLS certificate discovery from AWS Certificate Manager extends to Gateway API listeners. When you specify a hostname, the controller queries ACM and attaches the matching certificate. Certificate rotation happens automatically without manual ARN updates.
Gateway API isn’t AWS-specific. Google Cloud’s GKE Gateway controller, NGINX, Envoy Gateway, Istio, and others all implement the spec. The Kubernetes Gateway API implementations page lists 20+ conformant controllers. AWS joining GA signals the spec’s maturity; it reached v1.0 in October 2023 and v1.3 in June 2025.
The portability story matters here. Core routing logic in Gateway, GatewayClass, and Route resources stays consistent across implementations. AWS-specific CRDs (the three mentioned earlier) remain optional and isolated. You can write portable Kubernetes manifests and layer in cloud-specific features where needed.
The v3.1.0 release includes conformance test results showing which Gateway API features work and which don’t. The controller supports HTTPRoute path matching, header-based routing, weighted traffic splitting, and TLS termination. Some edge cases around ReplacePrefixMatch have documented ALB limitations.
Teams already using Ingress resources don’t need to migrate immediately. The controller still supports Ingress; it’s not deprecated. But new projects might skip Ingress entirely and start with the Gateway API. The better validation, clearer error messages, and role separation pay off as clusters grow.
One catch is that Gateway API resources require the controller’s feature flags to be enabled. The installation docs cover enabling Gateway API support and installing the CRDs. Teams running older controller versions need to upgrade to v2.13.3+ for Layer 4 support and to v2.14.0+ for Layer 7 support. In addition, a respondent on a Reddit thread stated:
Bummer, still no external cert support.
The announcement positions this as “modernizing Kubernetes deployments on AWS.” The controller’s GitHub repository shows Gateway API support progressed from experimental beta releases in 2024 to this GA launch, reflecting sustained community interest in the feature.
For teams deep in EKS, this release removes a reason to bolt on third-party ingress controllers just to get Gateway API features. Whether that matters depends on how much you value staying in AWS’s supported stack versus adopting best-of-breed open source tools.
