Cloud Native Operations

한국어

English

한국어

English

Appearance

GWLB·GENEVE: 대칭 검사 경로와 장애 검증 ​

검토 기준: AWS Gateway Load Balancer·PrivateLink·TGW·NAT 공식 문서, RFC 8926, 제조사 GWLB 통합 문서. 마지막 업데이트: 2026년 10월 15일

GWLB(Gateway Load Balancer)는 원래 IP 흐름을 GENEVE 호환 보안 장비에 분배하는 서비스입니다. GWLBE(Gateway Load Balancer endpoint)는 소비 VPC의 route target이며, 보안 정책 자체는 장비에 있습니다. 이 장은 Palo Alto·Fortinet 선택 이후 실제 검사 경로·세션·장애를 검증하기 위한 가이드입니다. Route 표와 수용 기준은 설계 예시이며 완성된 IaC나 실제 배포 결과가 아닙니다. S24 S27

1. 구성 요소와 책임 ​

구성 요소역할확인할 점
GWLBIP flow를 target에 전달AZ, target group, stickiness·failover
GENEVE target group장비 등록과 health·속성GENEVE port 6081, 지원 IP target·instance target
Appliance해제·검사·재캡슐화정책·세션·라이선스·metadata·MTU
Endpoint service공급 GWLB를 소비 VPC에 노출allowed principals·acceptance·소유 계정
GWLBE소비 VPC의 zonal route targetsubnet·AZ·endpoint 상태·route
TGW appliance modeflow별 inspection attachment ENI/AZ를 양방향에 일관되게 선택검사 VPC attachment에 적용한 실제 상태

Endpoint service의 principals·연결 acceptance는 연결 생성의 경계이고, 세션의 앱 인가나 장비 정책을 대신하지 않습니다. 서로 다른 계정의 AZ 이름 문자열보다 AZ ID로 물리적 AZ를 대조합니다. GWLB endpoint의 생성·제약은 PrivateLink 가이드를 확인합니다.

GWLB에는 ALB식 security group을 붙이지 않습니다. GWLBE도 SG를 지원하지 않습니다. ELB API의 SG는 ALB/NLB에, VPC endpoint API의 SG는 interface endpoint에 해당합니다. 장비·워크로드 ENI의 SG, NACL, 실제 route와 장비 정책을 검토합니다. S39 S40

2. GENEVE는 검사 transport이며 암호화가 아니다 ​

text
Outer IP
  └─ UDP destination port 6081
      └─ GENEVE header + options / AWS metadata
          └─ Original encapsulated traffic

RFC 8926은 GENEVE header·VNI·가변 option과 UDP transport를 정의합니다. AWS GWLB는 Option Class 0x0108의 TLV metadata를 사용하며, 장비는 TLV 쌍을 처리하고 GWLB는 이 metadata로 반환 GWLBE를 선택합니다. 지원 integration에서 필요한 metadata를 보존합니다. “일반 GENEVE를 지원한다”만으로 GWLB 호환성을 입증하지 않습니다. S31 S42 S29

GENEVE는 TLS·IPsec처럼 payload를 암호화하지 않습니다. 동일 포트라도 Cilium overlay와 GWLB encapsulation은 목적·처리 경로가 다릅니다. TLS payload 검사는 장비의 별도 복호화 정책 또는 종료 지점의 통제가 필요합니다. S31 S24

3. AZ별 egress 논리 흐름 ​

아래는 중앙 egress의 한 방향 논리 흐름입니다. 실제 TGW·GWLBE·장비·NAT는 AZ별로 선택되며 응답은 같은 세션의 일관된 검사 경로로 돌아와야 합니다.

TGW attachment subnet, endpoint subnet와 NAT subnet의 route table이 서로 다른 역할을 맡습니다. “모든 subnet의 0.0.0.0/0을 GWLBE”로 바꾸면 검사 후 트래픽이 다시 GWLBE로 들어가 loop가 생길 수 있습니다. AWS의 TGW 검사와 NAT 결합 가이드를 함께 검토합니다. S29 S30

4. 중앙 검사 route 검토 표 ​

다음 표는 중앙 IPv4 egress와 VPC 간 검사에 대한 한 가지 패턴입니다. 실제 CIDR·AZ·endpoint·attachment ID, prefix 우선순위와 existing route를 확인한 뒤 설계합니다. “소비 VPC”가 곧 “모든 방향 검사”를 뜻하지 않습니다.

위치선택한 목적지예시 next hop / 확인 목적
Spoke workload subnet다른 spoke CIDR, 외부 defaultTGW
Spoke가 연결된 TGW route table검사 대상 spoke/외부Inspection VPC attachment
Inspection VPC의 TGW attachment subnet검사 대상 목적지해당 AZ의 GWLBE
GWLBE subnetspoke CIDRTGW
GWLBE subnet외부 0.0.0.0/0해당 AZ NAT Gateway
NAT subnet외부 0.0.0.0/0Internet Gateway
NAT subnet반환할 spoke CIDR검사 GWLBE
Inspection attachment가 연결된 TGW route tablespoke CIDR해당 spoke attachment; 다시 검사 attachment로 보내지 않음

요청은 검사 후 NAT로, 응답은 NAT의 역변환 후 검사를 거쳐 TGW로 돌아오는 구조입니다. NAT subnet의 return route를 빠뜨리면 요청만 검사하거나 stateful 세션이 끊길 수 있습니다. NAT 위치를 다른 곳으로 변경하면 tuple·route 설계도 다시 검토합니다. S29 S30

중앙 검사 attachment에서 TGW appliance mode를 확인합니다. 이는 flow별 inspection attachment ENI/AZ를 양방향에 일관되게 선택하며, TGW의 기본 origin-AZ 선호를 대신해 cross-AZ 라우팅을 허용합니다. 같은 firewall instance의 세션 복제까지 제공하지 않습니다. GWLB target 선택과 별도로 검증합니다. S29 S25 S32

Internet ingress는 별도의 설계다 ​

인터넷 ingress 삽입에는 Internet Gateway edge-associated route table, 보호 subnet route, GWLBE subnet route와 return path를 함께 설계해야 합니다. ALB·IGW·GWLBE를 순서 없이 나열한 그림은 충분하지 않습니다. AWS 문서는 IGW/VGW를 대상으로 한 gateway route table의 제약을 설명합니다. ALB의 proxy front/backend 연결도 각각의 flow로 추적합니다. S28

5. 중앙 경로 밖의 트래픽 ​

경로왜 별도 검증하는가보완 기준 제안
같은 노드의 Pod 통신VPC/TGW까지 나오지 않을 수 있음CNI·NetworkPolicy·서비스 인가
VPC local·다른 subnetdefault route보다 구체적인 local route지원되는 local route 설계 또는 CNI·SG
Peering·별도 TGW attachment중앙 검사 route와 다를 수 있음실제 effective route와 연결 목록
PrivateLink·gateway endpointpublic egress default와 다른 경로IAM·endpoint/resource policy·앱 인가
IPv6·NAT64·proxyIPv4 0.0.0.0/0만으로 포괄 불가각 서비스·장비의 지원과 ::/0 경로
관리·health check데이터 검사와 목적이 다름제한된 관리/health 소스와 기록

VPC local route는 제한된 조건에서 appliance로 재지정할 수 있지만, “불가능”이나 “자동으로 중앙화”라고 일반화하지 않습니다. 현재 route 유형·지원 target·CIDR 제약을 확인합니다. S28

EKS에서는 Pod/노드 IP·CNI SNAT·Security Groups for Pods 모드가 관측과 경로에 영향을 줍니다. Pod 정책과 VPC 검사 route를 한 설정으로 취급하지 않습니다. S33 S34 S44

6. Stickiness와 idle timeout ​

기본 GWLB stickiness는 source/destination IP, source/destination port와 protocol의 5-tuple입니다. 지원 설정으로 3-tuple(IP 쌍+protocol) 또는 2-tuple(IP 쌍)을 선택할 수 있지만, TGW appliance mode를 켠 구성에는 2/3-tuple이 지원되지 않습니다. 이 중앙 검사 패턴은 5-tuple을 사용합니다. reduced-tuple은 특정 target에 부하를 집중시킬 수 있으므로 선택 모드의 제약과 용량을 확인합니다. S25

TCP idle timeout 기본값은 350초이며, 5-tuple stickiness에서는 지원 범위 60–6000초로 변경할 수 있습니다. UDP idle timeout은 고정 120초입니다. 2/3-tuple에서 TCP timeout 변경을 지원한다고 가정하지 않습니다. 장비·NAT·앱·TGW와 target ENI의 TcpEstablishedTimeout도 독립적으로 확인합니다. GWLB timeout이 ENI timeout보다 길면 연결 추적의 불일치로 drop이 발생할 수 있습니다. S24

TCP timeout 후의 새 SYN은 새 flow로 처리되지만, 이전 연결의 data packet은 drop됩니다. UDP timeout 후 packet은 새 flow가 될 수 있습니다. timeout 연장과 여러 장비의 세션 상태 공유는 별개입니다. keepalive·idle 후 재개·장시간 gRPC/WebSocket·UDP를 시험합니다. S24

7. Health·failover·fail open을 정확히 구분 ​

상태/설정AWS 문서의 동작운영에서 검증할 점
하나의 target unhealthy새 flow는 사용 가능한 healthy target 선택기존 flow의 configured failover
target_failover.on_unhealthy=no_rebalance기존 flow의 target 유지unhealthy target에서 blackhole 가능
target_failover.on_unhealthy=rebalance기존 flow를 다른 target에 재분배독립 장비에서 세션 유실 가능
deregistration failoveron_deregistration에 따라 처리drain·scale-in·upgrade
모든 target unhealthyflow별 unhealthy target을 임의 선택해 reset/timeout까지 유지; AWS는 해당 target이 healthy가 될 때까지 drop된다고 설명문서상 결과 검증; health만 실패했는데 전달되는 경우는 PoC 가설
등록된 target 없음새 flow의 전달 대상 없음; drop 검증empty fleet 알림·복구, 기존 draining flow 구분

target_failover.on_unhealthy와 target_failover.on_deregistration은 같은 값으로 설정해야 합니다. no_rebalance가 기본값입니다. Health check는 TCP·HTTP·HTTPS를 지원하고 실제 protocol·port·path를 장비와 맞춰야 합니다. S25 S26

현재 AWS 문서는 send_tcp_reset.on_unhealthy.enabled와 send_tcp_reset.on_deregistration.enabled도 제공합니다. 기본값은 false이며, TCP에만 적용하고 5-tuple(stickiness.enabled=false)과 no_rebalance가 필요합니다. rebalance 또는 reduced-tuple과 함께 켤 수 없습니다. RST를 받은 client의 재연결·재시도·업무 중복 처리를 시험하며, 이를 무중단 세션 이전으로 설명하지 않습니다. deregistration의 drain 시간도 확인합니다. S25

모든 target이 unhealthy일 때 GWLB가 장비를 직접 우회하지는 않습니다. AWS는 flow별 target 임의 선택과, 선택된 target이 healthy가 될 때까지 traffic drop을 설명합니다. 결정은 AZ별로 독립적이며 cross-zone을 끈 경우 각 AZ의 대상 집합을 확인합니다. cross-zone은 선택 가능한 대상을 넓히며 기존/신규 flow의 동작 구분은 그대로 필요합니다. S26

과거 배치 블로그의 “fail-open mode”는 기존 flow가 실패한 target을 유지하는 문맥입니다. 이를 가용성 보장이나 직접 우회 기능으로 해석하지 않고 장비 자체의 fail-open과도 구분합니다. health만 실패했는데 전달되는 경우는 실험할 가설이며 문서가 보장하는 복구 동작이 아닙니다. S32 S25 S26

Cross-zone load balancing은 남은 AZ의 healthy target을 사용할 선택지를 제공하지만 state 복제·zonal endpoint 복구를 제공하지 않습니다. cross-AZ 비용·용량·session disruption과 함께 검토하고, GWLBE 또는 AZ 손실을 target 손실과 별도로 시험합니다. 과거 배치 블로그의 “GWLB는 RST를 보내지 않는다”는 설명보다 현재 target group 속성 문서를 우선합니다. S24 S25 S27 S32

8. MTU·fragment·NACL·health 경로 ​

AWS는 GWLB의 최대 packet 크기를 8500 bytes로 설명하고, GENEVE가 68 bytes를 추가한다고 안내합니다. GWLB는 fragmentation이나 Path MTU Discovery를 대신하지 않습니다. 큰 workload MTU가 TGW·NAT·장비까지 모두 통과한다는 뜻은 아닙니다. S24 S32

검토할 항목:

  • 실제 전체 경로의 MTU, 장비 GENEVE interface의 여유, TCP MSS 처리.
  • 큰 packet·UDP datagram·TLS/HTTP2·업로드·fragment의 처리 결과.
  • 외부 UDP 6081과 내부 payload protocol을 구분한 SG·NACL·장비 정책.
  • TCP/HTTP/HTTPS health port의 도달성·응답과 실제 검사 canary.
  • stateless NACL의 request·return port와 실제 outer tuple.
  • IPv6 지원·encapsulation·ICMP/ICMPv6 필요 조건을 현재 제품별로 확인.

포트가 열린 사실이나 healthy 상태 하나로 정상 검사를 입증하지 않습니다. S26 S32

9. 승인된 환경에서 수행할 읽기 전용 점검 ​

아래는 AWS CLI 읽기 전용 명령 예시입니다. Region과 실제 소유 리소스 ID를 명시하며 shell 변수에는 조사 대상을 직접 설정합니다. 이번 조사에서는 실행하지 않았습니다.

bash
aws elbv2 describe-load-balancer-attributes \
  --region "$INSPECTION_REGION" --load-balancer-arn "$INSPECTION_GWLB_ARN"

aws elbv2 describe-target-group-attributes \
  --region "$INSPECTION_REGION" --target-group-arn "$INSPECTION_TARGET_GROUP_ARN"

aws elbv2 describe-target-health \
  --region "$INSPECTION_REGION" --target-group-arn "$INSPECTION_TARGET_GROUP_ARN"

aws ec2 describe-vpc-endpoints \
  --region "$INSPECTION_REGION" --vpc-endpoint-ids "$INSPECTION_ENDPOINT_ID"

aws ec2 describe-route-tables \
  --region "$INSPECTION_REGION" --route-table-ids "$INSPECTION_ROUTE_TABLE_ID"

aws ec2 describe-transit-gateway-vpc-attachments \
  --region "$INSPECTION_REGION" \
  --transit-gateway-attachment-ids "$INSPECTION_TGW_ATTACHMENT_ID"

로드 밸런서 속성의 cross-zone, target group의 stickiness·failover, target health, endpoint state·AZ, route·association, attachment의 ApplianceModeSupport를 비교합니다. TGW route table association·propagation·effective route는 별도 조회해야 하며, 위 여섯 명령만으로 대칭성을 증명하지 않습니다.

10. 장애 실험과 수용 기준 ​

다음은 격리된 승인 환경에서 수행할 검증 계획입니다.

실험반드시 기록할 결과
정상 허용·거부 canaryrequest/response 5-tuple, target, 정책/profile, 앱 결과
한 target health 실패기존/신규 세션, no_rebalance·rebalance 차이
모든 target unhealthy실제 unhealthy 전달, 검사 여부·오류; 직접 우회로 오해하지 않음
fleet 비움새 flow drop·기존 drain 구분·알림·복구
TCP RST 기능5-tuple·no_rebalance 제약, client 재연결·재시도
AZ·endpoint 경로 손실endpoint와 target 장애 차이, failover·복구
scale-in·rolling upgradedrain, 세션 끊김, 등록 준비·정책 일관성
NAT·route 변경변환 전후 tuple, return path·loop
MTU·idle·IPv6큰 packet·장시간 세션·지원 경로별 결과
중앙 경로 밖 통신local·endpoint·peering·Pod 경로와 보완 통제

수용 기준은 정상 업무 SLO, 실제 검사·차단 증거, 기존/신규 세션 동작, N-1 용량, 우회 경로 설명, rollback·복구 담당자를 함께 포함하도록 제안합니다. 이번 문서 보강은 실환경 배포·장애 주입·성능 측정을 수행하지 않았습니다.

다음 학습 ​

참고 자료와 조사 기준 ​

아래 공식 자료는 2026-10-15에 조회했습니다. 변경 시 해당 제품·브랜치의 최신 경보와 제약을 다시 확인합니다.