태그 보관물: GWLB

AWS, Cloud, IT

Inspecting Direct Connect Traffic with AWS GWLB: Asymmetric AZ Drops and a Lambda Failover

댓글 남기기

레거시 IPS를 대신할 검사 지점이 필요했던 상황

IDC와 AWS가 DX(Direct Connect)로 연결된 하이브리드 환경에서 AWS GWLB 기반의 IPS 인라인 검사를 DX 구간에 넣은 기록입니다. GWLB 엔드포인트가 한 AZ에만 놓이는 특성 때문에 가용성과 비대칭 트래픽 문제를 차례로 겪었습니다. EventBridge와 Lambda로 라우팅 테이블의 다음 홉을 바꾸는 방식으로 마무리했습니다.

기존에 쓰던 레거시 IPS가 수명을 다하면서, 보안 요건상 AWS 쪽에 IPS를 새로 구성해야 했습니다. DX를 거쳐 오가는 트래픽을 빠짐없이 검사하는 것이 목표였습니다.

AWS에서 서드파티 보안 어플라이언스를 트래픽 경로에 끼워 넣는 관리형 수단이 GWLB(Gateway Load Balancer)입니다. GWLB는 원래 패킷을 Geneve(UDP 6081)로 감싸 어플라이언스에 넘기고, 검사를 마친 패킷을 돌려받아 원래 경로로 보냅니다. Cisco IPS를 새로 도입하는 만큼 Geneve 지원 여부부터 확인했고, 지원 사양임을 확인한 뒤 설계에 들어갔습니다.

기존 네트워크를 건드리지 않는 배치

기존 네트워크 구조를 크게 바꾸면 여러 계정의 VPC에 영향이 갈 수 있었습니다. TGW 같은 공용 구간은 형상 변경을 최소화하고, 변경은 DX 진입 구간에 모았습니다.

  • 진입 구간 VPC: IDC에서 DX를 거쳐 AWS로 들어오는 구간의 VPC에 GWLB 엔드포인트를 두었습니다.
  • Inspection VPC: 별도 VPC를 만들어 GWLB와 GWLB 엔드포인트 서비스를 두고, 그 뒤에 IPS를 연결했습니다.
  • 라우팅: 진입 구간 VPC의 라우팅 테이블에서 다음 홉을 GWLB 엔드포인트로 지정했습니다. GWLB 엔드포인트가 있는 서브넷의 라우팅 테이블은 외부로 나가는 기존 경로를 그대로 유지했습니다.

이렇게 하면 DX를 거치는 인바운드·아웃바운드 패킷이 모두 GWLB 엔드포인트로 넘어가고, GWLB를 거쳐 IPS에서 검사됩니다. IPS 검사를 마친 패킷은 엔드포인트가 있는 서브넷으로 되돌아와 원래대로 라우팅됩니다.

AWS GWLB 검사 구성도: IDC에서 DX로 들어온 트래픽이 진입 구간 VPC의 GWLB 엔드포인트를 거쳐 Inspection VPC의 Cisco IPS에서 검사된 뒤 기존 경로로 돌아가는 구조
DX 진입 구간 VPC에 GWLB 엔드포인트를 두고, 별도 Inspection VPC에서 IPS로 검사하는 AWS GWLB 배치입니다.

AWS GWLB 엔드포인트가 한 AZ에만 놓이는 문제

ALB나 NLB는 구성할 때 여러 AZ를 함께 선택해 가용성을 확보할 수 있습니다. GWLB 엔드포인트는 그와 달리 서브넷 하나, 즉 AZ 하나에만 만들어집니다.

라우팅 테이블의 한 경로에는 다음 홉을 하나만 지정할 수 있습니다. GWLB 엔드포인트를 다음 홉으로 지정하면 모든 트래픽이 그 엔드포인트의 AZ 하나로만 흐릅니다. AZ 하나에 문제가 생기면 DX 구간 전체가 영향을 받는 구조였습니다.

AZ별 라우팅 분리가 부른 비대칭 드롭

첫 번째 대응은 라우팅 테이블을 AZ별로 나누고, AZ마다 GWLB 엔드포인트를 만들어 각각 지정하는 방식이었습니다. AZ 하나가 빠져도 이론상으로는 나머지 AZ가 트래픽을 받습니다.

그런데 왕복 경로가 서로 다른 AZ를 지나는 경우가 생겼습니다. C존에서 출발한 연결은 C존 엔드포인트를 거쳐 DX로 나가고, IDC에서 SYN을 처리합니다. SYN/ACK가 A존으로 돌아오면 C존에서 SYN을 본 IPS와는 다른 경로로 검사됩니다. A존 경로의 IPS 세션 테이블에는 이 연결의 SYN 기록이 없으므로, 비대칭 트래픽으로 판단해 드롭했습니다.

상태 기반(stateful) 검사 장비는 한 연결의 양방향 패킷을 같은 장비가 봐야 합니다. AZ별로 경로를 나누면 이 전제가 깨지므로, AZ별 라우팅 분리는 이 구성에 맞지 않는 방법이었습니다.

AWS GWLB 엔드포인트를 AZ별로 나눴을 때 C존에서 나간 SYN의 응답이 A존으로 돌아와 IPS가 드롭하는 비대칭 흐름과 EventBridge·Lambda 다음 홉 전환 보완 개념도
AZ별 경로 분리가 상태 기반 IPS의 비대칭 드롭을 부른 흐름과, 엔드포인트 하나를 유지하며 장애 때만 다음 홉을 바꾸는 보완 방식입니다.

EventBridge와 Lambda로 만든 다음 홉 전환

그래서 가용성은 라우팅 분리 대신 자동화로 확보했습니다. AZ 단위의 트래픽 이상을 감시하는 EventBridge 규칙을 만들었습니다. EventBridge가 이상을 감지하면 트리거용 Lambda가 실행됩니다. Lambda는 다시 라우팅 테이블의 다음 홉을 다른 AZ의 GWLB 엔드포인트로 바꾸는 Lambda를 호출해 경로를 전환합니다.

평소에는 모든 트래픽이 엔드포인트 하나와 같은 IPS 경로를 지나므로 대칭이 유지됩니다. AZ에 이상이 생길 때만 경로가 통째로 옮겨 갑니다. AZ를 전환하는 순간 진행 중이던 연결은 새 경로의 IPS에 세션 기록이 없으므로 끊길 수 있다는 점도 감안해야 합니다.

지금 다시 설계한다면 먼저 볼 AWS 기능

이 구성은 당시 요건과 제약 안에서 고른 방법입니다. 같은 문제를 다시 다룬다면 아래 기능이 구조에 맞는지 먼저 확인해 볼 만합니다.

  • VGW 인그레스 라우팅의 GWLB 엔드포인트 지정: 2023년 8월부터 가상 프라이빗 게이트웨이(VGW) 라우팅 테이블에서 GWLB 엔드포인트를 다음 홉으로 지정할 수 있습니다. DX나 Site-to-Site VPN으로 들어오는 트래픽을 VGW 경계에서 바로 검사 경로로 보낼 수 있습니다.
  • TGW appliance mode: 트래픽이 TGW의 VPC 연결을 거쳐 검사 VPC로 간다면 이 기능을 먼저 봅니다. TGW가 한 연결의 왕복 트래픽을 같은 AZ의 연결로 보내 비대칭을 막아 줍니다.
  • GWLB 교차 영역 부하 분산: 기본값은 꺼져 있고, 켜면 다른 AZ의 어플라이언스로도 트래픽을 보낼 수 있습니다. AZ 하나에 엔드포인트가 놓이는 제약은 그래도 남습니다.

정리

GWLB는 패킷 검사 어플라이언스를 AWS 트래픽 경로에 넣으려면 사실상 필수인 구성 요소입니다. IPS 검사를 우회하거나 루프를 도는 트래픽이 라우팅 변경 하나로도 생길 수 있어, 흐름 전체를 신중하게 검토해야 했습니다.

이번 AWS GWLB 구성에서 얻은 가장 큰 교훈은 대칭성입니다. IPS 같은 상태 기반 장비를 쓰는 한, 가용성을 위해 경로를 나누는 순간 왕복 경로가 갈라질 수 있습니다. AZ 이중화 같은 가용성 설계는 대칭을 깨지 않는 범위 안에서 해야 했습니다.

참고

관련 포스트:

참고 문서: AWS Gateway Load Balancer 개요 · GWLB 속성(교차 영역 부하 분산) · VGW 인그레스 라우팅의 GWLB 지원 · GWLB와 TGW 중앙 검사 아키텍처(appliance mode) · Cisco Threat Defense의 GWLB·Geneve 구성