[이론] Amazon GWLB 구성 기본 개념

안녕하세요 서후아빠입니다. ^_^

이번 세션은 Amazon GWLB 구성에 필요한 최소한의 개념에 대해서 간단히 정리해 보았습니다.

---

개요

NLB와 ALB만 구성하면 소스 IP 추적이 어려워 트래픽 모니터링이 어렵다. GWLB를 사용하여 구성하면 어플라이언스 및 최종 대상에서 소스 IP에 대한 추적이 가능합니다.(단 NLB가 아닌 ALB로 구성 시에는 ALB에서 SNAT 처리를 하기 때문에 최종 대상에서 소스 IP에 대한 추적이 기본적으로는 불가능)

NLB+NLB vs GWLB+NLB

어플라이언스 장비를 인라인 방식으로 구성하는 경우와 GWLB로 구성하는 경우 IP 변화 비교

GWLB ~ 어플라이언스 구간 

GENEVE Protocol을 사용하여 암호화 통신

  - UDP를 통해 구현된 캡슐화 프로토콜이며 VXLAN(가상 확장 LAN)의 한계를 극복

  - OVN(Open Virtual Network, Logical Switch/Router Concept)의 기본 터널링 프로토콜로 GENEVE 채택

GENEVE Protocol 패킷 구조

GENEVE Protocol 통신은 PPP(Point-To Point Protocol) 연결 사용

  - PPP : 두 통신 노드 간의 직접 연결에 일반적으로 사용되는 데이터 링크 프로토콜(L2 계층, 인증/암호화를 통해 전송 및 데이터 압축 기능 제공)

GWLB 사용하는 이유

방화벽, 침입 탐지 및 방지 시스템, 심층 패킷 검사 시스템과 같은 가상 어플라이언스를 배포, 확장 및 관리

통합 운영으로 오버 헤드(운영인력 리소스 상승) 절감, 비용 절감 : Service A/B/C…, PRD/STG/DEV,…과 같이 비슷한 서비스를 묶어 통합 정책 관리가 가능함

심층적인 보안 솔루션 일원화 : Firewall, IPS, Web Filter, DNS Filter, AntiVirus, Etc

실시간 트래픽 분석 및 가시성 향상

기존에 사용한 솔루션일 경우 관리성 확보

보안장비 인라인 구성의 경우 보안장비 장애 시 조치가 어려운 반면, GWLB 구성은 Ingress 라우팅 테이블을 GWLB Endpoint에서 ELB로 연결하고, Outbound 라우팅 테이블도 IGW로 변경하는  즉시 서비스는 복구됨

어플라이언스 장비 장애시 긴급 연결 비교

GWLB 구성 시 참고사항 

어플라이언스 장비(예: 3rd Party Firewall) : GENEVE 프로토콜 지원

GWLB의 Target groups : GENEVE 프로토콜(UDP 6081)로 지정

GWLB의 Endpoint : 가용영역(AZ)별로 하나씩 생성

GWLB 속성의 "Cross-Zone Load Balancing(교차 영역 로드 밸런싱)" : Enable

TGW없이 인터넷과 통신할 때, GWLB를 사용하는 경우(VPC <-> GWLB <-> 인터넷) : VPC의 "ingress route"를 설정(IGW는 ingress route tables에 Edge 연결) 

TGW 사용하여 GWLB 구성하는 경우 : GWLB가 위치하는 VPC의 TGW Attachment에 대해서 Appliance 모드 활성화

  ※ Disable 시 비대칭 라우팅으로 인한 장애 발생(예: Appliance #1의 요청, Appliance #2의 응답)

TGW은 App이 연결되는 VPC와 어플라이언스가 연결되는 VPC를 각각 구분하여 라우팅 설정해야 하므로 라우팅 자동 연결 설정을 disabled

참고사항에 설명된 부분이 이해되지 않을 수 있지만 이어지는 실습을 참고하시면 그 뜻이 이해될 것입니다.