--- title: "AWS Load Balancer Controller officially released, bringing support for Kubernetes Gateway API" type: "News" locale: "en" url: "https://longbridge.com/en/news/280860801.md" description: "Amazon Web Services officially announced support for the Kubernetes Gateway API, allowing teams to manage Application Load Balancer and Network Load Balancer through the Load Balancer Controller. The Gateway API, as the successor to the Ingress API, addresses the challenges of annotation configuration, provides type-safe Custom Resource Definitions (CRD), supports Layer 4 and Layer 7 routing, and enhances the capabilities of the AWS Gateway API" datetime: "2026-03-27T19:00:00.000Z" locales: - [zh-CN](https://longbridge.com/zh-CN/news/280860801.md) - [en](https://longbridge.com/en/news/280860801.md) - [zh-HK](https://longbridge.com/zh-HK/news/280860801.md) --- > Supported Languages: [简体中文](https://longbridge.com/zh-CN/news/280860801.md) | [繁體中文](https://longbridge.com/zh-HK/news/280860801.md) # AWS Load Balancer Controller officially released, bringing support for Kubernetes Gateway API Recently, Amazon Web Services officially released support for the Kubernetes Gateway API in its Load Balancer Controller. With this release, teams can manage Application Load Balancer and Network Load Balancer through it. The Gateway API is a standard specification maintained by Kubernetes SIG and is gaining increasing attention as the successor to the aging Ingress API. This is important because it addresses the problem of annotations. Before the Gateway API, users had to stuff JSON configurations into Kubernetes annotations to configure load balancers. There was no schema validation, no IDE support, only strings, which could cause issues at runtime. Now, with proper validation and GitOps-friendly YAML, users can achieve type-safe Custom Resource Definitions (CRD). Now, using Gateway API resources, users can handle Layer 4 routing (TCP, UDP, TLS via Network Load Balancer) and Layer 7 routing (HTTP, gRPC via Application Load Balancer) simultaneously. This enhances the coverage of the AWS Gateway API, as VPC Lattice has already provided support for east-west service mesh traffic. Together, they use the same Kubernetes-native API to cover north-south ingress and east-west service communication. The previous method involved stuffing target group attributes, health check configurations, and sticky settings into annotation strings. The new approach uses three CRDs: TargetGroupConfiguration, LoadBalancerConfiguration, and ListenerRuleConfiguration, which are validated upon activation rather than mysteriously failing at runtime. For example, configuring deregistration delay previously required parsing such annotations: Now it has become structured data: The Gateway API distributes responsibilities across three resources. Platform teams define GatewayClass (infrastructure templates), cluster operators configure Gateway (listeners, TLS, subnet allocation), and application developers create Routes (path-based routing, header matching). This can be clearly mapped to RBAC boundaries, allowing developers to route traffic without needing cluster administrator permissions. Image source: — API Gateway component Cross-namespace routing is now also achievable. The platform team configures a shared Gateway within a single namespace. Application teams create HTTPRoutes that reference it in different namespaces, and developers do not need to touch infrastructure layer settings such as security groups or VPC subnets; the controller automatically configures the load balancer. Amazon Web Services engineers Alexandra Huides and Zac Nixon wrote that the automatic TLS certificate discovery feature in AWS Certificate Manager has been extended to Gateway API listeners. When you specify a hostname, the controller queries ACM and attaches the matching certificate. Certificate rotation occurs automatically without the need to manually update the ARN. The Gateway API is not unique to Amazon Web Services. Google Cloud's GKE Gateway controller, NGINX, Envoy Gateway, Istio, and others implement the specification. Over 20 compliant controllers are listed. This release from Amazon Web Services marks the maturity of the specification; it reached v1.0 in October 2023 and will reach v1.3 in June 2025. Portability is important here. The core routing logic in Gateway, GatewayClass, and Route resources remains consistent across various implementations. The Amazon Web Services-specific CRDs (the three mentioned earlier) are still optional and isolated. You can write portable Kubernetes manifests and add specific cloud features as needed. The consistency test results included show which Gateway API features are effective and which are not. The controller supports HTTPRoute path matching, header-based routing, weighted traffic splitting, and TLS termination. There are some documented ALB limitations regarding edge cases of ReplacePrefixMatch. Teams already using Ingress resources do not need to migrate immediately. The controller still supports Ingress, which has not been deprecated. However, new projects may completely skip Ingress and start directly with the Gateway API. As clusters grow, better validation, clearer error messages, and role separation will yield satisfying returns. It is important to note that Gateway API resources require enabling the controller's feature flag. This covers enabling Gateway API support and installing CRDs. Teams running older controllers need to upgrade to v2.13.3+ for Layer 4 support and to v2.14.0+ for Layer 7 support. Additionally, in a discussion on Reddit, one respondent stated: Regarding this release, the announcement describes it as "modernizing Kubernetes deployment on AWS." The display of the controller shows that Gateway API support has evolved from the experimental Beta version in 2024 to this official release, and the community has been quite focused on this feature. For teams deeply using EKS, there is one less reason to add third-party ingress controllers to obtain Gateway API functionality. Whether this is important depends on how you weigh the technology stack supported by Amazon Web Services against adopting the best open-source tools. Disclaimer: This article is a translation by InfoQ and reproduction without permission is prohibited ### Related Stocks - [GraniteShares 2x Long AMZN Daily ETF (AMZZ.US)](https://longbridge.com/en/quote/AMZZ.US.md) - [Direxion Daily AMZN Bull 2X Shares (AMZU.US)](https://longbridge.com/en/quote/AMZU.US.md) - [Roundhill AMZN WeeklyPay ETF (AMZW.US)](https://longbridge.com/en/quote/AMZW.US.md) - [Global X Cloud Computing ETF (CLOU.US)](https://longbridge.com/en/quote/CLOU.US.md) - [Amazon.com, Inc. (AMZN.US)](https://longbridge.com/en/quote/AMZN.US.md) ## Related News & Research - [AWS introducing a new UK customer addendum](https://longbridge.com/en/news/281226104.md) - [Got $1,000? 1 artificial intelligence (AI) stock to buy and hold for the next decade and beyond](https://longbridge.com/en/news/281603890.md) - [Tianju Dihe Extends API Services Agreement with JD.com Unit](https://longbridge.com/en/news/281135618.md) - [GigaOm Names Check Point Software a Leader and Fast Mover in Application and API Security | CHKP Stock News](https://longbridge.com/en/news/281528543.md) - [K-Buddhism: "AI Sage", Can an AI awaken to its Original Nature? | AMZN Stock News](https://longbridge.com/en/news/281059138.md)