AWS Load Balancer Controller Reaches GA with Kubernetes Gateway API Support

AWS has announced general availability support for Kubernetes Gateway API in its Load Balancer Controller, marking a significant evolution in how teams configure load balancing infrastructure for Kubernetes workloads on AWS. This release enables management of both Application Load Balancers (ALBs) and Network Load Balancers (NLBs) through the Gateway API specification, a Kubernetes SIG-maintained standard that's gaining traction as the successor to the aging Ingress API.

Technical Evolution: From Annotations to Structured Resources

The importance of this release lies in its departure from annotation-based configuration. Prior to Gateway API support, teams configured AWS load balancers by embedding complex JSON structures into Kubernetes annotations. This approach presented several challenges:

• No schema validation at apply time
• Limited IDE support and autocompletion
• Error-prone string-based configurations that could fail at runtime
• Poor GitOps compatibility due to the unstructured nature of annotations

The new approach introduces three Custom Resource Definitions (CRDs) that provide type-safe, structured configuration:

1. TargetGroupConfiguration: Manages target group attributes
2. LoadBalancerConfiguration: Defines load balancer settings
3. ListenerRuleConfiguration: Configures listener rules and routing logic

These CRDs validate configurations at apply time rather than failing mysteriously at runtime, significantly improving the developer experience and operational reliability.

Architecture and Resource Model

The AWS Load Balancer Controller implements the Gateway API specification through a three-layer resource model that aligns with different operational roles:

GatewayClass

Platform teams define GatewayClass resources to establish infrastructure templates. These act as blueprints for load balancer configurations, specifying the type of load balancer (ALB or NLB) and default parameters.

Gateway

Cluster operators configure Gateway resources to define listeners, TLS settings, subnet placement, and other infrastructure-level parameters. This resource represents the actual load balancer endpoint.

Routes

Application developers create Route resources (HTTPRoute, TCPRoute, UDPRoute, TLSRoute) to define traffic routing rules. These include path-based routing, header matching, weight-based traffic splitting, and other application-specific routing policies.

This separation of concerns maps cleanly to RBAC boundaries, allowing developers to manage routing without requiring cluster-admin privileges.

Layer 4 and Layer 7 Support

The GA release provides comprehensive support for both transport and application layer load balancing:

Layer 4 Support (Network Load Balancer)

• TCP and UDP traffic routing
• TLS passthrough
• Static IP address support
• Health checking capabilities

Layer 7 Support (Application Load Balancer)

• HTTP/1.1 and HTTP/2 traffic
• gRPC protocol support
• Path-based routing
• Header and cookie-based routing
• Query parameter matching
• TLS termination
• Web Application Firewall (WAF) integration

Cross-Namespace Routing

A significant improvement over the Ingress API is the support for cross-namespace routing. With this model:

1. Platform teams provision a shared Gateway within a single namespace
2. Application teams in separate namespaces create HTTPRoutes that reference the shared Gateway
3. The controller automatically configures the load balancer without requiring developers to manage infrastructure-level settings

This pattern enables better infrastructure sharing while maintaining clear separation of concerns between platform and application teams.

TLS Certificate Management

The GA release enhances TLS certificate management through automatic discovery from AWS Certificate Manager (ACM). When a Gateway resource specifies a hostname, the controller queries ACM and attaches the matching certificate automatically. Certificate rotation occurs seamlessly without requiring manual ARN updates in Kubernetes manifests.

Implementation Requirements and Migration Path

Teams adopting Gateway API support must meet several requirements:

• AWS Load Balancer Controller version 2.13.3 or later for Layer 4 support
• AWS Load Balancer Controller version 2.14.0 or later for Layer 7 support
• Gateway API feature flags enabled during installation
• Required CRDs installed in the cluster

The installation process involves enabling Gateway API support and installing the necessary CRDs. Detailed instructions are available in the AWS Load Balancer Controller documentation.

Importantly, existing Ingress resources remain fully supported and are not deprecated. Teams can continue using Ingress while gradually adopting Gateway API for new workloads.

Conformance and Feature Support

The v3.1.0 release includes conformance test results that clearly document which Gateway API features are supported. The controller supports:

• HTTPRoute path matching
• Header-based routing
• Weighted traffic splitting
• TLS termination
• Cross-namespace routing

Some edge cases around ReplacePrefixMatch have documented ALB limitations, which teams should consider when designing routing policies.

Portability and Cloud-Native Standards

Gateway API's value proposition extends beyond AWS-specific functionality. As a cloud-native standard, it enables portable Kubernetes manifests across multiple environments:

• Google Cloud's GKE Gateway controller
• NGINX Ingress Controller with Gateway API support
• Envoy Gateway
• Istio service mesh

The Kubernetes Gateway API implementations page lists over 20 conformant controllers. AWS joining GA signals the spec's maturity, which reached v1.0 in October 2023 and v1.3 in June 2025.

The portability story is strengthened by the separation between core Gateway API resources (Gateway, GatewayClass, Routes) and cloud-specific CRDs. Teams can write portable Kubernetes manifests and layer in cloud-specific features where needed.

Operational Considerations

RBAC Design

The Gateway API resource model enables fine-grained RBAC configuration. Platform teams can grant:

• GatewayClass management to infrastructure administrators
• Gateway configuration to cluster operators
• Route creation to application developers

This prevents developers from requiring cluster-admin privileges while still enabling them to manage traffic routing for their applications.

Monitoring and Observability

Teams should establish monitoring for Gateway API resources, including:

• Gateway resource status and conditions
• Route configuration validation
• Load balancer health check status
• Target group registration status

The AWS Load Balancer Controller emits standard Kubernetes events for configuration issues and integration with AWS services.

Performance Considerations

While Gateway API introduces additional abstractions, the performance impact is minimal compared to direct Ingress configuration. The controller translates Gateway API resources to AWS API calls with similar latency to annotation-based configurations.

Future Development and Community Engagement

Gateway API support in the AWS Load Balancer Controller progressed from experimental beta releases in 2024 to this GA launch, reflecting sustained community interest in the feature. The controller's GitHub repository shows active development and community contributions.

One limitation noted by community members is the lack of external certificate support beyond AWS Certificate Manager. This may be addressed in future releases as the implementation matures.

Conclusion

The general availability of Gateway API support in the AWS Load Balancer Controller represents a significant improvement in how teams configure load balancing infrastructure for Kubernetes workloads. By replacing error-prone annotations with structured, type-safe resources, AWS has enhanced both the developer experience and operational reliability.

For teams already invested in EKS, this release reduces the need to adopt third-party ingress controllers solely for Gateway API features. While the choice between AWS-supported solutions and best-of-breed open source tools depends on specific requirements, this GA release strengthens the case for staying within AWS's supported stack for Kubernetes networking.

As Kubernetes networking continues to evolve, Gateway API is positioned to become the standard approach for traffic management across cloud providers. AWS's commitment to this specification through general availability support further validates its importance in the cloud-native ecosystem.

For teams looking to adopt Gateway API, the AWS documentation provides comprehensive guides for installation and configuration.