Amazon Web Services社は最近、AWS Load Balancer ControllerにおいてKubernetes Gateway APIの一般提供（GA）対応を開始した。このリリースにより、各チームはGateway API仕様を用いてApplication Load BalancerやNetwork Load Balancerを管理することが可能になった。Gateway APIはKubernetes SIGが管理する規格であり、老朽化したIngress APIの後継として注目を集めている。
この対応が重要なのは、従来のアノテーションの課題が解消されたためだ。Gateway API導入以前、利用者はKubernetesアノテーションにJSONを詰め込んでロードバランサーの設定を行っていた。スキーマの検証もIDEの支援もなく、単なる文字列として扱われるため、運用時に動作が破綻する可能性があった。現在は、適切な検証機能やGitOps運用に適したYAML形式を備えた型安全なカスタムリソース定義（CRD）が提供されている。
AWS Load Balancer Controllerは現在、Gateway APIリソースを利用してLayer 4のルート（TCP、UDP、TLSをNetwork Load Balancerで処理）とLayer 7のルート（HTTPやgRPCをApplication Load Balancerで処理）をともに管理できるようになった。これにより、AWSによるGateway API対応が完了した形となった。すでにVPC Latticeでは、サービスメッシュ内の東西方向の通信をGateway APIでサポートしていた。両者を組み合わせることで、北南方向のインバウンド通信と東西方向のサービス間通信を、同一のKubernetesネイティブAPIを用いて管理できるようになった。
従来の方法では、ターゲットグループの属性やヘルスチェックの設定、スティッキーセッションの構成などをアノテーション文字列に詰め込んでいた。新しい手法では、TargetGroupConfiguration、LoadBalancerConfiguration、ListenerRuleConfigurationの3種類のカスタムリソース定義（CRD）を用い、適用時に検証が行われるため、運用時に原因不明のエラーが発生することがなくなった。
例えば、deregistration delayの設定を行う場合、従来は次のようなアノテーションの解析が必要だった。
alb.ingress.kubernetes.io/target-group-attributes: | deregistration_delay.timeout_seconds=30, stickiness.enabled=true 現在は、構造化されたデータとして設定できる。
apiVersion: gateway.k8s.aws/v1beta1 kind: TargetGroupConfiguration spec: targetGroupAttributes: - key: deregistration_delay.timeout_seconds value: "30" - key: stickiness.enabled value: "true" Gateway APIは、役割を三つのリソースに分割している。プラットフォームチームはGatewayClass（基盤のテンプレート）を定義し、クラスター運用者がGateway（リスナー、TLS、サブネットの配置）を設定する。また、アプリ開発者はRoute（パスベースのルーティングやヘッダーマッチング）を作成する。この構造は、RBACの境界に明確に対応しており、開発者がトラフィックのルーティングを行う際にクラスタ管理者権限を必要としない。
（出典：Amazon Web Services社 Networking & Content Delivery公式ブログ「API Gateway Components」）
クロス namespaceルーティングも利用可能になった。プラットフォームチームは、一つのnamespace内に共有Gatewayを提供し、別namespaceのアプリケーションチームは、そのGatewayを参照するHTTPRouteを作成する。コントローラーがロードバランサーを自動的に設定するため、開発者がセキュリティグループやVPCサブネットといったインフラレベルの設定を扱う必要はなくなった。
Amazon Web Services社のエンジニア、Alexandra Huides氏とZac Nixon氏は、発表の中で、AWS Certificate Managerによる自動TLS証明書検出機能がGateway APIリスナーにも拡張されたと述べた。ホスト名を指定すると、コントローラーがACMを検索して一致する証明書を自動的に割り当てる。証明書のローテーションも、ARNを手動で更新する必要なく自動的に実施される。
Gateway APIは、Amazon Web Services社固有のものではない。Google Cloud社のGKE Gateway controllerやNGINX、Envoy Gateway、Istioなども、この仕様を実装している。Kubernetes Gateway API実装一覧ページには、20以上の準拠コントローラーが掲載されている。Amazon Web Services社によるGA対応は、この仕様が成熟したことを示している。Gateway APIは2023年10月にバージョン1.0へ到達し、2025年6月にはバージョン1.3となった。
ここで重要なのは、ポータビリティの実現である。Gateway、GatewayClass、Routeリソースに記述された中心的なルーティングロジックは、各実装間で一貫している。先述のようなAmazon Web Services社固有のCRD（三種類）は任意であり、他の部分から切り離されている。利用者は、移植性の高いKubernetesマニフェストを記述し、必要に応じてクラウド固有の機能を追加できる。
バージョン3.1.0のリリースには、Gateway API機能ごとの動作状況を示す適合テスト結果が含まれている。コントローラーはHTTPRouteのパスマッチング、ヘッダーによるルーティング、重み付けトラフィック分割、TLS終端処理をサポートしている。ReplacePrefixMatchのような一部の境界ケースについては、Application Load Balancerに特有の制限事項が文書化されている。
Ingressリソースを既に利用しているチームが直ちに移行する必要はない。コントローラーは引き続きIngressもサポートしており、非推奨となっていない。ただし、新規プロジェクトではIngressを使わずに最初からGateway APIを導入する動きが見込まれる。Gateway APIは、より適切な検証機能や明確なエラーメッセージ、役割分担の仕組みがあるため、クラスター規模が拡大するにつれてメリットが生まれる。
一点注意すべき点は、Gateway APIリソースを利用する際には、コントローラーの機能フラグを有効化する必要があることだ。インストールドキュメントには、Gateway APIサポートの有効化やCRDの導入手順が記載されている。古いバージョンのコントローラーを運用しているチームは、Layer 4サポートにv2.13.3以上、Layer 7サポートにはv2.14.0以上へのアップグレードが求められる。さらに、Redditのスレッド上では、次のような意見も述べられている。
残念ながら、外部証明書のサポートは依然として提供されていません。
今回の発表では、これを「AWSにおけるKubernetes導入の近代化」と位置付けている。コントローラーのGitHubリポジトリによれば、Gateway APIのサポートは2024年の実験的なベータリリースから一般提供（GA）に至るまで進展しており、この機能に対するコミュニティの根強い関心が示された。
EKSを活用するチームにとって、今回のリリースはGateway APIの機能を得るためだけにサードパーティ製Ingressコントローラーを追加する必要性を解消した形となる。これが重要かどうかは、AWS社のサポート対象スタックを重視するか、最良のオープンソースツールを導入するかという方針によって異なる。