Skip to main content

Gateway API Adoption Guide

Reference Versions: Gateway API v1.4.0, Cilium v1.19.0, EKS 1.32, AWS LBC v3.0.0, Envoy Gateway v1.7.0

Written: 2025-02-12 | Updated: 2026-02-14 | Reading time: ~13 min

1. Overview​

With the official EOL (End-of-Life) of NGINX Ingress Controller in March 2026, migrating to Kubernetes Gateway API has become mandatory rather than optional. This guide comprehensively covers Gateway API architecture, comparison of 5 major implementations (AWS LBC v3, Cilium, NGINX Gateway Fabric, Envoy Gateway, kGateway), Cilium ENI mode deep-dive configuration, step-by-step migration execution strategy, and performance benchmark plans.

1.1 Target Audience​

  • EKS cluster administrators running NGINX Ingress Controller: EOL response strategy
  • Platform engineers planning Gateway API migration: Technology selection and PoC
  • Architects reviewing traffic management modernization: Long-term roadmap design
  • Network engineers considering Cilium ENI mode + Gateway API integration: eBPF-based high-performance networking

1.2 Document Structure​

📚 문서 구조
필수
1. 개요 — 문서 구조, 대상 독자2. NGINX Retirement — EOL 타임라인, 보안 위험3. Gateway API 아키텍처 — 3-Tier 모델, 역할 분리4. Gateway API 구현체 비교 — AWS Native vs Open Source, NGINX 매핑, 코드 예제6. 결론 — 권장사항, 로드맵
상황별
5. 벤치마크 계획 — 테스트 설계
Reading Strategy
  • Quick understanding: Sections 1-3, 6 (~10 min)
  • Technology selection: Sections 1-4, 6 (~20 min)
  • Full migration: Entire document + sub-documents (~25 min)

2. NGINX Ingress Controller Retirement — Why Migration Is Mandatory​

2.1 EOL Timeline​

  • March 2025: IngressNightmare (CVE-2025-1974) discovered — Snippets annotation arbitrary NGINX config injection vulnerability accelerated retirement discussions
  • November 2025: Official retirement announcement by Kubernetes SIG Network. Cited insufficient maintainers (1-2) and Gateway API maturity
  • March 2026: Official EOL — Security patches and bug fixes completely cease
Mandatory Action

After March 2026, NGINX Ingress Controller receives no security vulnerability patches. For PCI-DSS, SOC 2, ISO 27001 compliance, migration to a Gateway API-based solution is required.

2.2 Security Vulnerability Analysis​

⚠️ NGINX Ingress 보안 위험 평가
알려진 취약점 및 영향 범위
Snippets 어노테이션을 통한 임의 설정 주입
CriticalCVSS: 9.8
영향 범위:전체 Ingress 트래픽 장악 가능
스키마 검증 부재로 인한 잘못된 설정 전파
HighCVSS: 7.5
영향 범위:서비스 중단, 보안 정책 우회
RBAC 권한 상승 공격 (네임스페이스 격리 무력화)
CriticalCVSS: 9.1
영향 범위:크로스 네임스페이스 권한 탈취
EOL 이후 패치 종료
CriticalCVSS: N/A
영향 범위:제로데이 취약점 대응 불가

2.3 Structural Resolution Through Gateway API​

Gateway API fundamentally resolves NGINX Ingress structural vulnerabilities through:

  • 3-Tier role separation eliminating snippet injection paths
  • CRD schema-based structural validation preventing arbitrary config injection
  • Policy Attachment pattern for safe extension with RBAC-controlled access
🔄 NGINX Ingress vs Gateway API 비교
아키텍처 및 설정 방식 차이
리소스 구조
NGINX Ingress단일 Ingress 리소스에 모든 설정 포함
Gateway API3개 리소스로 관심사 분리 (GatewayClass, Gateway, HTTPRoute)
설정 방식
NGINX Ingress비표준 어노테이션 (50개 이상)
Gateway API표준 CRD 필드
권한 관리
NGINX Ingress네임스페이스 레벨 Ingress 권한으로 모든 설정 제어 가능
Gateway API리소스별 RBAC 분리 (인프라/플랫폼/앱 팀)
컨트롤러 교체
NGINX Ingress전체 Ingress 재작성 필요
Gateway APIGatewayClass만 변경
확장성
NGINX IngressSnippet 주입 또는 커스텀 컨트롤러
Gateway APIPolicy Attachment 패턴

3. Gateway API — The Next-Generation Traffic Management Standard​

3.1 Architecture​

Gateway API separates responsibilities across three roles: Infrastructure Provider (GatewayClass), Cluster Operator (Gateway), and Application Developer (HTTPRoute).

3.2 3-Tier Resource Model​

👥 역할 기반 책임 분리
리소스별 관리 주체 및 변경 빈도
GatewayClass⏱ 분기별 1-2회
관리 주체:인프라 팀 (SRE, 클러스터 관리자)
책임 범위:컨트롤러 선택, 전역 정책, 비용 최적화
Gateway⏱ 월 1-2회
관리 주체:플랫폼 팀 (네트워크 엔지니어)
책임 범위:리스너 구성, TLS 인증서, 로드밸런서 설정
HTTPRoute⏱ 일 단위
관리 주체:애플리케이션 팀 (개발자)
책임 범위:서비스별 라우팅, Canary 배포, A/B 테스트
Service⏱ 배포 시마다
관리 주체:애플리케이션 팀 (개발자)
책임 범위:백엔드 엔드포인트 관리

3.3 GA Status (v1.4.0)​

✅ Gateway API GA 상태
리소스별 안정성 및 프로덕션 권장 여부
GatewayClassStandard
GA (v1)✅
컨트롤러 정의, 파라미터 참조
GatewayStandard
GA (v1)✅
리스너, TLS, 로드밸런서 설정
HTTPRouteStandard
GA (v1)✅
HTTP 라우팅, 헤더/쿼리 매칭
GRPCRouteStandard
GA (v1)✅
gRPC 서비스 메시 매칭
ReferenceGrantStandard
GA (v1beta1)✅
크로스 네임스페이스 참조 보안
BackendTLSPolicyStandard
Beta (v1alpha3)⚠️
백엔드 TLS 종단 (mTLS)
TLSRouteExperimental
Alpha (v1alpha2)❌
TLS Passthrough (SNI 라우팅)
TCPRouteExperimental
Alpha (v1alpha2)❌
L4 TCP 라우팅
UDPRouteExperimental
Alpha (v1alpha2)❌
L4 UDP 라우팅 (DNS, VoIP)

3.4 Key Benefits​

✕
🚫
기존 Ingress
단일 권한 모델
🏢 인프라 팀 → GatewayClass🔒
RBAC 격리
🔧 플랫폼 팀 → Gateway🔒
RBAC 격리
💻 앱 팀 → HTTPRoute🔒

4. Gateway API Implementation Comparison - AWS Native vs Open Source​

4.1 Solution Overview​

Gateway API 솔루션 개요 비교
5개 솔루션 · 5개 비교 카테고리
개요▶
클릭하여 펼치기
핵심 특징▶
클릭하여 펼치기
주요 제약사항▶
클릭하여 펼치기
적합한 사용 사례▶
클릭하여 펼치기
부적합 사례▶
클릭하여 펼치기

4.2 Feature Comparison Matrix​

Gateway API 솔루션 종합 비교
72개 비교 항목 · 10개 카테고리 · 5개 솔루션
기본 정보 (5개)▶
클릭하여 펼치기 · 5개 항목
Gateway API (6개)▶
클릭하여 펼치기 · 6개 항목
핵심 기능 (8개)▶
클릭하여 펼치기 · 8개 항목
보안 (4개)▶
클릭하여 펼치기 · 4개 항목
성능 (3개)▶
클릭하여 펼치기 · 3개 항목
운영 (5개)▶
클릭하여 펼치기 · 5개 항목
메시 통합 (4개)▶
클릭하여 펼치기 · 4개 항목
고급 기능 (6개)▶
클릭하여 펼치기 · 6개 항목
AI/ML (3개)▶
클릭하여 펼치기 · 3개 항목
관측성 (4개)▶
클릭하여 펼치기 · 4개 항목
비용 (5개)▶
클릭하여 펼치기 · 5개 항목
커뮤니티 (4개)▶
클릭하여 펼치기 · 4개 항목

4.3 NGINX Feature Mapping​

🔀 NGINX 기능 → Gateway API 매핑
구현체별 NGINX 기능 재현 방식
#NGINX 기능AWS NativeCiliumNGINX FabricEnvoy GWkGateway
1
Basic AuthLambda/JWTL7 PolicyOIDC PolicyExtAuthJWT/OIDC
2
IP AllowlistWAF IP Sets + SGCiliumNetworkPolicyNginxProxySecurityPolicyRouteOption
3
Rate LimitingWAF Rate RuleL7 Rate LimitNginxProxyBackendTrafficPolicyRouteOption
4
URL RewriteHTTPRoute FilterHTTPRoute FilterHTTPRoute FilterHTTPRoute FilterHTTPRoute Filter
5
Body SizeWAF Size Rule-NginxProxyClientTrafficPolicyRouteOption
6
Custom ErrorALB Fixed Response-Custom BackendDirect ResponseDirectResponse
7
Header RoutingHTTPRoute matchesHTTPRoute matchesHTTPRoute matchesHTTPRoute matchesHTTPRoute matches
8
Cookie AffinityTG Stickiness-Upstream ConfigSession PersistenceRouteOption

4.4 Implementation Difficulty​

⚖️ 구현 난이도 비교
기능별 구현체 난이도 평가
기능AWS NativeCiliumNGINX FabricEnvoy GWkGateway
Basic Auth
중간
중간
쉬움
중간
쉬움
IP Allowlist
쉬움
쉬움
쉬움
쉬움
쉬움
Rate Limiting
중간
중간
쉬움
쉬움
쉬움
URL Rewrite
쉬움
쉬움
쉬움
쉬움
쉬움
Body Size
중간
어려움
쉬움
쉬움
쉬움
Custom Error
쉬움
어려움
중간
쉬움
쉬움
Header Routing
쉬움
쉬움
쉬움
쉬움
쉬움
Cookie Affinity
쉬움
어려움
쉬움
중간
쉬움

4.5 Cost Impact Analysis​

AWS Native vs 오픈소스 비용 및 성능 영향 비교
기능별 추가 비용, 지연 오버헤드, 홉 증가 여부 종합 비교
기능
AWS Native 비용
오픈소스 비용
성능 영향
Basic Auth (JWT)
Lambda 실행 비용 ~$2-10/월 (100만 요청 기준)
없음 (자체 구현)
AWS: Lambda 호출로 +5-50ms (콜드스타트 시 +200ms) 오픈소스: Gateway 내장 처리, <1ms
⚠️ AWS: +1 홉 (ALB → Lambda Authorizer) 오픈소스: 추가 홉 없음
IP Allowlist
WAF IP Set + 규칙 $5 (Web ACL) + $1 (규칙) = $6/월
없음 (NetworkPolicy)
AWS: WAF 규칙 평가 +0.5-1ms 오픈소스: 커널/eBPF 레벨 처리, <0.1ms
✅ 양쪽 모두 추가 홉 없음 AWS: ALB에서 인라인 처리 오픈소스: 네트워크 레이어에서 처리
Rate Limiting
WAF Rate-Based Rule $5 (Web ACL) + $1 (규칙) + $0.60/백만 요청
없음 (L7 Policy)
AWS: WAF 규칙 평가 +0.5-1ms 오픈소스: Envoy/NGINX 프록시 처리, +1-2ms
⚠️ AWS: 추가 홉 없음 (ALB 인라인) 오픈소스: L7 프록시 미사용 시 프록시 홉 추가 가능
Body Size 제한
WAF Body Size Rule WAF 비용에 포함
없음 (Proxy Config)
AWS: WAF 본문 검사 +1-3ms (본문 크기에 비례) 오픈소스: Proxy buffer 설정, <1ms
✅ 양쪽 모두 추가 홉 없음 기존 경로에서 인라인 처리
전체 합산
WAF 전체: ~$20-100/월 (트래픽에 따라 변동)
없음 (컴퓨팅 리소스만 추가)
AWS: WAF 규칙 수에 비례하여 +1-5ms 누적 오픈소스: 프록시 경유 시 +2-5ms
⚠️ AWS: Lambda Auth 사용 시 최대 +1 홉 오픈소스: L7 프록시 구성 시 최대 +1 홉

4.7 Decision Tree​

4.8 Scenario Recommendations​

🎯 시나리오별 추천 솔루션
사용 사례에 따른 최적 Gateway API 구현체 선택 가이드
AWS 올인 + 운영 최소화
1순위AWS Native2순위Cilium
관리형, SLA 보장, 운영팀 규모 작음
고성능 + 관측성
1순위Cilium2순위Envoy GW
eBPF 최고 성능, Hubble Service Map
NGINX 경험 + 멀티클라우드
1순위NGINX Fabric2순위Envoy GW
기존 NGINX 지식 활용, 클라우드 중립
CNCF + 서비스 메시
1순위Envoy GW2순위kGateway
Istio 호환, CNCF 표준 준수
AI/ML + 통합 게이트웨이
1순위kGateway2순위Cilium
AI 라우팅, MCP Gateway, 미래 지향
금융/의료 보안
1순위AWS Native2순위Cilium
WAF, Shield, 감사 추적, 컴플라이언스
스타트업 + 비용 최적화
1순위Cilium2순위NGINX/Envoy
고정 비용, 벤더 종속 회피
하이브리드/멀티클러스터
1순위Cilium2순위kGateway
BGP Control Plane, 멀티사이트 메시
빠른 PoC (검증)
1순위AWS Native2순위NGINX Fabric
빠른 설정, 관리형, 검증된 안정성
장기 전략적 투자
1순위Cilium2순위Envoy GW
eBPF 미래 기술, CNCF 생태계

5. Benchmark Comparison Plan​

Benchmark Details

Test environment design, detailed scenarios, metrics and execution plans are available at Gateway API Implementation Performance Benchmark Plan.

6. Conclusion and Roadmap​

6.1 Conclusion​

🎯 Gateway API 구현체 선택 가이드
조직 요구사항에 맞는 최적 경로
AWS Native→ AWS 올인 조직
✓ 완전 관리형, 자동 스케일링, 제로 운영
Cilium→ 고성능 + 관측성 중시
✓ eBPF 최고 성능, Hubble 가시성, ENI 네이티브
NGINX Fabric→ NGINX 경험 활용
✓ 검증된 안정성, 익숙한 설정, 빠른 전환
Envoy Gateway→ CNCF 표준 + 서비스 메시
✓ L7 기능 풍부, Istio 통합, 확장성
kGateway→ AI/ML 통합 필요
✓ AI 라우팅, 엔터프라이즈 지원, Solo.io 생태계

6.2 Future Expansion Roadmap​

🗺️ 향후 확장 로드맵
Gateway API 생태계 진화 경로 — 클릭하여 상세 보기
🚀
현재
Now
1/4▼
📊
6개월 후
6 Months
2/4▼
🔗
1년 후
1 Year
3/4▼
🤖
2년 후
2 Years
4/4▼

6.3 Key Message​

info

Complete migration before the March 2026 NGINX Ingress EOL to eliminate security threats.

Gateway API is not just an Ingress replacement — it's the future of cloud-native traffic management.

  • Role separation: Clear responsibility division between platform and development teams
  • Standardization: Portable configuration without vendor lock-in
  • Extensibility: Scales to East-West, service mesh, and AI integration

Sub-documents (Deep-dive Guides)​

External References​