본문으로 건너뛰기

Gateway API 도입 가이드

📌 기준 버전: Gateway API v1.4.0, Cilium v1.19.0, EKS 1.32, AWS LBC v3.0.0, Envoy Gateway v1.7.0

📅 작성일: 2025-02-12 | 수정일: 2026-02-14 | ⏱️ 읽는 시간: 약 13분

1. 개요​

2026년 3월 NGINX Ingress Controller의 공식 EOL(End-of-Life)을 앞두고, Kubernetes Gateway API로의 전환이 선택이 아닌 필수가 되었습니다. 이 가이드는 Gateway API의 아키텍처 이해부터 5개 주요 구현체(AWS LBC v3, Cilium, NGINX Gateway Fabric, Envoy Gateway, kGateway) 비교, Cilium ENI 모드 심화 구성, 단계별 마이그레이션 실행 전략, 성능 벤치마크 계획까지 포괄합니다.

1.1 이 문서의 대상​

  • NGINX Ingress Controller를 운영 중인 EKS 클러스터 관리자: EOL 대응 전략 수립
  • Gateway API 마이그레이션을 계획 중인 플랫폼 엔지니어: 기술 선정 및 PoC 수행
  • 트래픽 관리 아키텍처 현대화를 검토 중인 아키텍트: 장기 로드맵 설계
  • Cilium ENI 모드와 Gateway API 통합을 고려하는 네트워크 엔지니어: eBPF 기반 고성능 네트워킹

1.2 문서 구성​

📚 문서 구조
필수
1. 개요 — 문서 구조, 대상 독자2. NGINX Retirement — EOL 타임라인, 보안 위험3. Gateway API 아키텍처 — 3-Tier 모델, 역할 분리4. Gateway API 구현체 비교 — AWS Native vs Open Source, NGINX 매핑, 코드 예제6. 결론 — 권장사항, 로드맵
상황별
5. 벤치마크 계획 — 테스트 설계
읽기 전략
  • 빠른 이해: 섹션 1-3, 6 (약 10분)
  • 기술 선정: 섹션 1-4, 6 (약 20분)
  • 전체 마이그레이션: 전체 문서 + 하위 문서 (약 25분)

2. NGINX Ingress Controller Retirement — 왜 전환이 필수인가​

2.1 EOL 타임라인​

주요 이벤트 상세:

  • 2025년 3월: IngressNightmare (CVE-2025-1974) 발견 — Snippets 어노테이션을 통한 임의 NGINX 설정 주입 취약점으로 Kubernetes SIG Network의 retirement 논의가 가속화됨
  • 2025년 11월: Kubernetes SIG Network에서 NGINX Ingress Controller의 공식 retirement 발표. 유지보수 인력 부족(1-2명의 메인테이너)과 Gateway API 성숙도를 주요 이유로 명시
  • 2026년 3월: 공식 EOL — 보안 패치 및 버그 수정 완전 중단. 이후 운영 환경 사용 시 컴플라이언스 위반 가능성
필수 대응 사항

2026년 3월 이후 NGINX Ingress Controller 사용 시 보안 취약점 패치가 제공되지 않습니다. PCI-DSS, SOC 2, ISO 27001 등 보안 인증 유지를 위해서는 반드시 Gateway API 기반 솔루션으로 전환해야 합니다.

2.2 보안 취약점 분석​

IngressNightmare (CVE-2025-1974) 공격 시나리오:

IngressNightmare 공격 개요

Kubernetes 클러스터 내 Ingress NGINX Controller를 대상으로 한 비인증 원격 코드 실행(RCE) 공격 벡터. 외부 및 내부 공격자가 Malicious Admission Review를 통해 컨트롤러 Pod를 장악하고, 클러스터 내 전체 Pod에 접근 가능. (Source: Wiz Research)

위험도 평가:

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

기존 NGINX Ingress 환경에서는 nginx.ingress.kubernetes.io/configuration-snippet 및 nginx.ingress.kubernetes.io/server-snippet 어노테이션 사용을 즉시 금지하는 admission controller 정책 적용을 권장합니다.

2.3 취약점의 구조적 해결을 위한 Gateway API 도입​

Gateway API는 NGINX Ingress의 구조적 취약점을 근본적으로 해결합니다.

🔄 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 패턴

1. Configuration Snippet 주입 공격

NGINX Ingress는 annotations에 임의 문자열을 주입할 수 있어 심각한 보안 위험을 초래합니다:

# ❌ NGINX Ingress — 임의 문자열 주입 가능
annotations:
  nginx.ingress.kubernetes.io/configuration-snippet: |
    # 인접 서비스의 자격 증명 탈취 가능 (CVE-2021-25742)
    proxy_set_header Authorization "stolen-token";

2. 단일 리소스에 모든 권한 집중

  • Ingress 리소스 하나에 라우팅, TLS, 보안, 확장 설정이 혼재
  • 어노테이션 단위 RBAC 분리가 불가능 — 전체 Ingress 권한 또는 무권한
  • 개발자가 라우팅만 수정하려 해도 TLS/보안 설정 변경 권한까지 보유

3. 벤더 어노테이션 의존

  • 표준에 없는 기능은 벤더 고유 어노테이션으로 추가 → 이식성 상실
  • 어노테이션 간 충돌 시 디버깅 어려움
  • 100+ 벤더 어노테이션 관리 복잡성 증가

이러한 구조적 문제로 인해 NGINX Ingress는 프로덕션 보안 요구사항을 충족하기 어렵습니다.

활발한 커뮤니티 지원
  • 15개 이상의 프로덕션 구현체: AWS, Google Cloud, Cilium, Envoy, NGINX, Istio 등
  • 분기별 정규 릴리스: v1.4.0 기준 GA 리소스 포함
  • CNCF 공식 프로젝트: Kubernetes SIG Network 주도 개발

3. Gateway API — 차세대 트래픽 관리 표준​

3.1 Gateway API 아키텍처​

Gateway API 역할 기반 모델 — 출처: gateway-api.sigs.k8s.io

출처: Kubernetes Gateway API 공식 문서 — 3개의 역할(Infrastructure Provider, Cluster Operator, Application Developer)이 각각 GatewayClass, Gateway, HTTPRoute를 관리

상세 비교

NGINX Ingress와 Gateway API의 아키텍처 비교는 2.3 취약점의 구조적 해결을 위한 Gateway API 도입에서 탭별로 확인할 수 있습니다.

3.2 3-Tier 리소스 모델​

Gateway API는 다음과 같은 계층 구조로 책임을 분리합니다:

Gateway API 리소스 모델 — 출처: gateway-api.sigs.k8s.io

출처: Kubernetes Gateway API 공식 문서 — GatewayClass → Gateway → xRoute → Service 계층 구조

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

3.3 GA 현황 (v1.4.0)​

Gateway API는 Standard Channel과 Experimental Channel로 나뉘며, 리소스별 성숙도가 다릅니다:

✅ 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)
Experimental 채널 주의사항

Alpha 상태의 리소스는 API 호환성 보장이 없으며, 마이너 버전 업그레이드 시 필드 변경 또는 삭제 가능성이 있습니다. 프로덕션 환경에서는 Standard 채널의 GA/Beta 리소스만 사용하는 것을 권장합니다.

3.4 핵심 이점​

Gateway API의 6가지 핵심 이점을 시각적 다이어그램과 YAML 예제로 살펴봅니다.

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

3.5 기본 리소스 예제​

실제 프로덕션 환경에서 사용하는 Gateway API 리소스 배포 순서입니다:

Gateway API 리소스는 역할별로 분리 배포됩니다. 인프라 팀이 GatewayClass를, 플랫폼 팀이 Gateway를, 앱 팀이 HTTPRoute를 각각 관리합니다.

네이티브 Canary 배포

Gateway API는 weight 필드를 통해 어노테이션 없이 Canary 배포를 지원합니다. NGINX Ingress의 nginx.ingress.kubernetes.io/canary 어노테이션 조합보다 간결하고 이식성이 높습니다.

4. Gateway API 구현체 비교 - AWS Native vs Open Source​

이 섹션에서는 5가지 주요 Gateway API 구현체를 상세히 비교합니다. 각 솔루션의 특징, 강점, 약점을 파악하여 조직에 최적의 선택을 할 수 있도록 돕습니다.

4.1 솔루션 개요 비교​

다음 매트릭스는 5가지 Gateway API 구현체의 핵심 특징, 제약사항, 적합한 사용 사례를 비교합니다.

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

4.2 기능 비교 매트릭스​

다음은 5가지 솔루션의 종합 비교표입니다. 이 표를 통해 각 솔루션의 강점과 약점을 한눈에 파악할 수 있습니다.

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 기능 매핑​

NGINX Ingress Controller에서 사용하던 8가지 주요 기능을 각 Gateway API 구현체에서 어떻게 구현하는지 비교합니다.

🔀 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 구현 난이도 비교​

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

4.5 비용 영향 분석​

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 홉
비용 최적화 팁
  • WAF 기능이 3개 이상 필요하면 AWS Native가 비용 대비 효율적입니다. 단일 WebACL에 여러 규칙을 묶어 관리할 수 있습니다
  • 1-2개만 필요하면 오픈소스 솔루션(Cilium, Envoy Gateway)에서 추가 비용 없이 구현 가능합니다
  • 성능 민감 워크로드는 오픈소스가 유리합니다. WAF 규칙 평가 지연 없이 커널/eBPF 레벨에서 처리됩니다
  • Lambda Authorizer 사용 시 콜드스타트로 인한 p99 지연 급증에 주의하세요. Provisioned Concurrency 설정을 검토하세요

4.6 기능별 구현 코드 예제​

1. 인증 (Basic Auth 대체)​

# AWS LBC v3의 네이티브 JWT 검증
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: jwt-protected-route
  namespace: production
spec:
  parentRefs:
    - name: production-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      filters:
        - type: ExtensionRef
          extensionRef:
            group: eks.amazonaws.com
            kind: JWTAuthorizer
            name: cognito-authorizer
      backendRefs:
        - name: api-service
          port: 8080

---
# JWTAuthorizer CRD (LBC v3 확장)
apiVersion: eks.amazonaws.com/v1
kind: JWTAuthorizer
metadata:
  name: cognito-authorizer
spec:
  issuer: https://cognito-idp.us-west-2.amazonaws.com/us-west-2_ABC123
  audiences:
    - api-gateway-client
  claimsToHeaders:
    - claim: sub
      header: x-user-id
    - claim: email
      header: x-user-email

2. Rate Limiting​

제한 사항

AWS Native(LBC v3)는 게이트웨이 레벨의 네이티브 Rate Limiting을 지원하지 않습니다. AWS WAF Rate-based Rule을 사용하여 IP 기반 요청 제한을 구현합니다.

# ALB에 WAF Rate-based Rule 연결
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  annotations:
    # Rate limiting WAF ACL ARN
    aws.load-balancer.waf-acl-arn: arn:aws:wafv2:us-west-2:123456789012:regional/webacl/rate-limit/a1b2c3d4
spec:
  gatewayClassName: aws-alb
  listeners:
    - name: http
      port: 80
      protocol: HTTP

ACK(AWS Controllers for Kubernetes)로 WAF Rate-based Rule 생성:

ACK WAFv2 컨트롤러를 사용하면 WAF 리소스를 Kubernetes 매니페스트로 선언적 관리할 수 있습니다.

EKS Capabilities로 ACK 활성화 (권장):

EKS Capabilities(2025년 11월 GA)를 사용하면 ACK 컨트롤러를 AWS 완전 관리형으로 운영할 수 있습니다. 컨트롤러가 AWS 관리 인프라에서 실행되므로 워커 노드에 별도 Pod가 배포되지 않습니다.

# 1. IAM Capability Role 생성
aws iam create-role \
  --role-name EKS-ACK-Capability-Role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": { "Service": "eks.amazonaws.com" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "<ACCOUNT_ID>" }
      }
    }]
  }'

# WAFv2 권한 정책 연결
aws iam put-role-policy \
  --role-name EKS-ACK-Capability-Role \
  --policy-name ACK-WAFv2-Policy \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": ["wafv2:*"],
      "Resource": "*"
    }]
  }'

# 2. EKS 클러스터에 ACK Capability 생성
aws eks create-capability \
  --cluster-name my-eks-cluster \
  --capability-type ACK \
  --capability-configuration '{
    "capabilityRoleArn": "arn:aws:iam::<ACCOUNT_ID>:role/EKS-ACK-Capability-Role"
  }'

# 3. CRD 등록 확인
kubectl get crds | grep wafv2
대안: Helm으로 직접 설치 (비 EKS 환경)

EKS가 아닌 환경이나 컨트롤러를 직접 관리해야 하는 경우 Helm으로 설치할 수 있습니다.

helm install ack-wafv2-controller \
  oci://public.ecr.aws/aws-controllers-k8s/wafv2-chart \
  --namespace ack-system \
  --create-namespace \
  --set aws.region=ap-northeast-2

이 방식은 컨트롤러가 워커 노드에 Pod로 배포되며, IRSA(IAM Roles for Service Accounts)로 권한을 관리합니다.

# ACK WAFv2 WebACL - Rate-based Rule 정의
apiVersion: wafv2.services.k8s.aws/v1alpha1
kind: WebACL
metadata:
  name: rate-limit-acl
  namespace: production
spec:
  name: rate-limit-acl
  scope: REGIONAL
  defaultAction:
    allow: {}
  rules:
    - name: ip-rate-limit
      priority: 1
      action:
        block: {}
      statement:
        rateBasedStatement:
          limit: 500            # 5분간 최대 요청 수 (100~2,000,000,000)
          aggregateKeyType: IP  # IP 기반 집계
      visibilityConfig:
        sampledRequestsEnabled: true
        cloudWatchMetricsEnabled: true
        metricName: ip-rate-limit
  visibilityConfig:
    sampledRequestsEnabled: true
    cloudWatchMetricsEnabled: true
    metricName: rate-limit-acl
# 생성된 WebACL ARN을 Gateway에 연결
# WebACL 생성 후 status.ackResourceMetadata.arn 에서 ARN 확인:
#   kubectl get webacl rate-limit-acl -n production \
#     -o jsonpath='{.status.ackResourceMetadata.arn}'
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  annotations:
    aws.load-balancer.waf-acl-arn: <WebACL ARN>
spec:
  gatewayClassName: aws-alb
  listeners:
    - name: http
      port: 80
      protocol: HTTP
ACK WAFv2 컨트롤러 요구사항
  • ACK WAFv2 컨트롤러에 wafv2:CreateWebACL, wafv2:UpdateWebACL, wafv2:DeleteWebACL, wafv2:GetWebACL 등의 IAM 권한이 필요합니다
  • EKS Capabilities 사용 시: IAM Capability Role에 WAFv2 권한을 연결합니다. 컨트롤러는 AWS 관리 인프라에서 실행됩니다
  • Helm 설치 사용 시: IRSA(IAM Roles for Service Accounts) 또는 EKS Pod Identity를 통해 최소 권한을 부여하세요
  • WebACL과 ALB는 동일 리전에 있어야 합니다

3. IP 제어 (IP Allowlist)​

# ALB Ingress에 WAF 연결 (LBC v3)
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  annotations:
    aws.load-balancer.waf-acl-arn: arn:aws:wafv2:us-west-2:123456789012:regional/webacl/ip-allowlist/a1b2c3d4
spec:
  gatewayClassName: aws-alb
  listeners:
    - name: http
      port: 80
      protocol: HTTP

ACK(AWS Controllers for Kubernetes)로 WAF IP Allowlist 생성:

ACK WAFv2 컨트롤러를 사용하면 IPSet과 WebACL을 Kubernetes 매니페스트로 선언적 관리할 수 있습니다.

# 1. ACK WAFv2 IPSet - 허용할 IP 목록 정의
apiVersion: wafv2.services.k8s.aws/v1alpha1
kind: IPSet
metadata:
  name: allowed-ips
  namespace: production
spec:
  name: allowed-ips
  scope: REGIONAL
  ipAddressVersion: IPV4
  addresses:
    - "10.0.0.0/8"        # VPC 내부
    - "192.168.1.0/24"    # 사무실 네트워크
    - "203.0.113.100/32"  # 특정 허용 IP
# 2. ACK WAFv2 WebACL - IPSet 기반 Allowlist 규칙
# IPSet 생성 후 status.ackResourceMetadata.arn 에서 ARN 확인:
#   kubectl get ipset allowed-ips -n production \
#     -o jsonpath='{.status.ackResourceMetadata.arn}'
apiVersion: wafv2.services.k8s.aws/v1alpha1
kind: WebACL
metadata:
  name: ip-allowlist-acl
  namespace: production
spec:
  name: ip-allowlist-acl
  scope: REGIONAL
  defaultAction:
    block: {}  # 기본 차단, 허용 목록만 통과
  rules:
    - name: allow-trusted-ips
      priority: 1
      action:
        allow: {}
      statement:
        ipSetReferenceStatement:
          arn: <IPSet ARN>  # allowed-ips IPSet의 ARN
      visibilityConfig:
        sampledRequestsEnabled: true
        cloudWatchMetricsEnabled: true
        metricName: allow-trusted-ips
  visibilityConfig:
    sampledRequestsEnabled: true
    cloudWatchMetricsEnabled: true
    metricName: ip-allowlist-acl
# 3. 생성된 WebACL ARN을 Gateway에 연결
# WebACL 생성 후 status.ackResourceMetadata.arn 에서 ARN 확인:
#   kubectl get webacl ip-allowlist-acl -n production \
#     -o jsonpath='{.status.ackResourceMetadata.arn}'
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  annotations:
    aws.load-balancer.waf-acl-arn: <WebACL ARN>
spec:
  gatewayClassName: aws-alb
  listeners:
    - name: http
      port: 80
      protocol: HTTP
ACK WAFv2 IPSet 관리 팁
  • IPSet의 addresses 필드를 업데이트하면 ACK 컨트롤러가 자동으로 AWS WAF IPSet을 동기화합니다
  • GitOps(ArgoCD/Flux)와 결합하면 IP 변경을 PR 기반으로 관리할 수 있습니다
  • IPSet과 WebACL은 동일 리전에 있어야 하며, wafv2:*IPSet*, wafv2:*WebACL* 권한이 필요합니다 (EKS Capabilities: IAM Capability Role / Helm: IRSA)

4. URL Rewrite​

Gateway API 표준

URL Rewrite는 Gateway API v1 표준 기능으로, 모든 구현체에서 동일하게 작동합니다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-rewrite
  namespace: production
spec:
  parentRefs:
    - name: production-gateway
  rules:
    # /api/v1/users → /users
    - matches:
        - path:
            type: PathPrefix
            value: /api/v1
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /
      backendRefs:
        - name: api-service
          port: 8080

    # /old-api/users → /v2/users
    - matches:
        - path:
            type: PathPrefix
            value: /old-api
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /v2
      backendRefs:
        - name: api-service-v2
          port: 8080

5. Header 조작​

Gateway API 표준

Header 조작은 Gateway API v1 표준 기능으로, 모든 구현체에서 동일하게 작동합니다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: header-manipulation
spec:
  parentRefs:
    - name: production-gateway
  rules:
    - matches:
        - path:
            value: /api
      filters:
        # 요청 헤더 추가
        - type: RequestHeaderModifier
          requestHeaderModifier:
            add:
              - name: X-Custom-Header
                value: "gateway-api"
              - name: X-Forwarded-Proto
                value: "https"
            remove:
              - Authorization  # 기존 Authorization 제거
        # 응답 헤더 추가
        - type: ResponseHeaderModifier
          responseHeaderModifier:
            add:
              - name: X-Server
                value: "gateway-api"
              - name: Strict-Transport-Security
                value: "max-age=31536000; includeSubDomains"
      backendRefs:
        - name: api-service
          port: 8080
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: sticky-session
  annotations:
    aws.load-balancer.target-group.stickiness.enabled: "true"
    aws.load-balancer.target-group.stickiness.type: "lb_cookie"
    aws.load-balancer.target-group.stickiness.duration: "3600"
spec:
  parentRefs:
    - name: production-gateway
  rules:
    - backendRefs:
        - name: api-service
          port: 8080

7. 요청 본문 크기 제한​

제한 사항

AWS WAF Rule을 사용하여 요청 본문 크기를 제한합니다 (Console/CloudFormation 설정).

# ALB에 WAF Body Size Limit Rule 연결
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  annotations:
    aws.load-balancer.waf-acl-arn: arn:aws:wafv2:us-west-2:123456789012:regional/webacl/body-size-limit/a1b2c3d4
spec:
  gatewayClassName: aws-alb
  listeners:
    - name: http
      port: 80
      protocol: HTTP

ACK(AWS Controllers for Kubernetes)로 WAF Body Size Rule 생성:

ACK WAFv2 컨트롤러를 사용하면 Body Size 제한 규칙을 Kubernetes 매니페스트로 선언적 관리할 수 있습니다.

# ACK WAFv2 WebACL - Body Size Limit Rule 정의
apiVersion: wafv2.services.k8s.aws/v1alpha1
kind: WebACL
metadata:
  name: body-size-limit-acl
  namespace: production
spec:
  name: body-size-limit-acl
  scope: REGIONAL
  defaultAction:
    allow: {}
  rules:
    - name: block-large-body
      priority: 1
      action:
        block: {}
      statement:
        sizeConstraintStatement:
          fieldToMatch:
            body:
              oversizeHandling: MATCH  # 오버사이즈 본문도 매칭
          comparisonOperator: GT
          size: 10485760              # 10MB (바이트 단위)
          textTransformations:
            - priority: 0
              type: NONE
      visibilityConfig:
        sampledRequestsEnabled: true
        cloudWatchMetricsEnabled: true
        metricName: block-large-body
  visibilityConfig:
    sampledRequestsEnabled: true
    cloudWatchMetricsEnabled: true
    metricName: body-size-limit-acl
# 생성된 WebACL ARN을 Gateway에 연결
# WebACL 생성 후 status.ackResourceMetadata.arn 에서 ARN 확인:
#   kubectl get webacl body-size-limit-acl -n production \
#     -o jsonpath='{.status.ackResourceMetadata.arn}'
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  annotations:
    aws.load-balancer.waf-acl-arn: <WebACL ARN>
spec:
  gatewayClassName: aws-alb
  listeners:
    - name: http
      port: 80
      protocol: HTTP
단일 WebACL로 규칙 통합

IP Allowlist, Rate Limiting, Body Size 제한을 모두 사용한다면, 별도의 WebACL을 각각 만들 필요 없이 하나의 WebACL에 여러 규칙을 priority로 구분하여 통합할 수 있습니다. ALB당 WebACL은 하나만 연결 가능하므로 통합 관리가 필수입니다.

8. 커스텀 에러 페이지​

# ALB의 Fixed Response 액션 사용
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: error-response
  namespace: production
  annotations:
    # ALB action annotation으로 고정 응답 구성
    alb.ingress.kubernetes.io/actions.error-503: |
      {
        "type": "fixed-response",
        "fixedResponseConfig": {
          "contentType": "text/html",
          "statusCode": "503",
          "messageBody": "<html><body><h1>Service Under Maintenance</h1><p>Please try again later.</p></body></html>"
        }
      }
spec:
  parentRefs:
    - name: production-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /maintenance
      backendRefs:
        - name: error-503  # annotation에 정의된 액션 이름
          kind: Service
          port: 503

4.7 경로 선택 의사결정 트리​

다음 의사결정 트리를 통해 조직에 최적의 솔루션을 선택할 수 있습니다.

4.8 시나리오별 권장 경로​

다음은 일반적인 조직 시나리오에 따른 권장 솔루션입니다.

🎯 시나리오별 추천 솔루션
사용 사례에 따른 최적 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. 벤치마크 비교 계획​

5개 Gateway API 구현체의 객관적인 성능 비교를 위한 체계적인 벤치마크를 계획하고 있습니다. 처리량, 레이턴시, TLS 성능, L7 라우팅, 스케일링, 리소스 효율성, 장애 복구, gRPC 등 8개 시나리오를 동일한 EKS 환경에서 측정합니다.

벤치마크 상세 계획

테스트 환경 설계, 시나리오 상세, 측정 지표 및 실행 계획은 **Gateway API 구현체 성능 벤치마크 계획**에서 확인할 수 있습니다.

6. 결론 및 향후 로드맵​

6.1 결론​

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

위 표를 기반으로 조직 환경에 맞는 솔루션을 선택하세요.

AWS Native (LBC v3) — 운영 부담 최소화, ALB/NLB 관리형 특성 활용, SLA 보장, AWS WAF/Shield/ACM 통합. 성능보다 안정성과 자동 스케일링이 중요한 환경에 최적.

6.2 향후 확장 로드맵​

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

6.3 핵심 메시지​

정보

2026년 3월 NGINX Ingress EOL 이전에 마이그레이션을 완료하여 보안 위협을 원천 차단하세요.

Gateway API는 단순한 Ingress 대체가 아닌, 클라우드 네이티브 트래픽 관리의 미래입니다.

  • 역할 분리: 플랫폼 팀과 개발 팀의 명확한 책임 분리
  • 표준화: 벤더 종속성 없는 이식 가능한 구성
  • 확장성: East-West, 서비스 메시, AI 통합까지 확장

지금 시작하세요:

  1. 현재 Ingress 인벤토리 수집 — 마이그레이션 실행 전략 참조
  2. 워크로드에 맞는 솔루션 선택 (섹션 4)
  3. PoC 환경 구축 — 마이그레이션 실행 전략 참조
  4. 점진적 마이그레이션 실행 — 마이그레이션 실행 전략 참조

추가 리소스:

관련 문서​

하위 문서 (심화 가이드)​

이 가이드의 주제별 심화 내용은 별도 하위 문서로 제공됩니다.

관련 카테고리​

외부 참고 자료​