IDC와 AWS Cloud가 DX로 연결된 하이브리드 클라우드 환경이었고 기존 Legacy IPS가 도태됨에 따라 보안 요건에 의해 AWS Cloud에 IPS 구성이 필요한 상황 이었습니다.

그에 따라 GWLB*를 검토하였고 신규 도입되는 Cisco IPS의 Geneve Protocol** 지원 여부를 검토 하였으며 다행히 지원이 가능한 스펙인 것을 확인했습니다.

설계 단계에서 기존 Network Architecture를 크게 변경시킬 경우 여러 account의 VPC에 영향이 있을 가능성이 있어 TGW등의 형상 변경은 최소화 하는 방향으로 진행하였고 IDC에서 DX를 거쳐 AWS로 진입하는 구간의 VPC에 GWLB Endpoint를 위치 시키고 별도의 Inspection VPC를 구성하여 해당 VPC에 GWLB와 GWLB Endpoint Service를 위치 시켰습니다.

그리고 진입구간 VPC의 라우팅 테이블에 Next hop을 GWLB Endpoint로 지정하고 GWLB Endpoint가 위치한 서브넷의 라우팅 테이블은 외부로 트래픽 처리가 되도록 기존 구성을 유지 시켰습니다.

이로서 DX를 거치는 모든 inbound/outbound 패킷은 GWLB Endpoint로 전달 되어 GWLB를 통해 IPS로 Inspection 되도록 하였고 Inspection이 끝난 패킷은 다시 GWLB Endpoint가 위치한 서브넷으로 되돌아와 정상적으로 라우팅 처리 되도록 하였습니다.

ALB, NLB 등과 GWLB의 구성상 차이점은 ALB 등은 Endpoint 구성시 AZ를 복수 선택하여 가용성 유지가 가능했지만 GWLB는 Endpoint 구성시 AZ를 1개만 선택이 가능했습니다.
라우팅테이블의 Nexthop에 GWLB Endpoint를 지정할 경우 1개의 AZ로만 트래픽이 흐르게 되어 구조상 가용성 유지에 문제가 발생하였습니다.

이를 해결하기 위해 AZ 단위로 라우팅 테이블 분리하고 각 AZ별로 GWLB Endpoint를 생성 후 지정하였지만 예를 들어 AWS Cloud C존에서 출발한 트래픽이 DX를 거쳐 IDC 통해 SYN 처리 후 SYN/ACK 처리시 A존으로 인입 된 후 IPS에 도달 하게 되면 세션 테이블과 불일치 하며 Asymmetric 트래픽을 Drop 처리 하는 현상이 발생 하였습니다.

결국 AZ단위 라우팅 테이블 분리는 적절하지 않은 구성이었고 가용성 확보를 위해 AZ 단위 트래픽 이상을 감시하는 Event Bridge 를 구성하고 Trigger용 Lambda와 라우팅테이블 Nexthop을 변경 하는 Lambda를 개발하여 보완 하였습니다.

패킷 감시용 어플라이언스를 사용하기 위해서는 필수적인 LB이지만 트래픽 흐름의 누수나 루프가 발생하지 않는지에 대한 신중한 검토가 필요한 구성이었습니다.

* GWLB(GateWay Load Balancer) : L3 기반 트래픽을 Geneve Protocol을 이용하여 타겟 그룹으로 전달 하여 Inspection 처리
https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/gateway/introduction.html
https://aws.amazon.com/ko/blogs/korea/introducing-aws-gateway-load-balancer-easy-deployment-scalability-and-high-availability-for-partner-appliances/

** Geneve Protocol(Generic Network Virtualization Encapsulation) : 과거 VXLAN과 같은 개념의 표준화된 Protocol로 UDP 6081 포트를 통해 Ethernet Frame을 캡슐화 하여 전달
https://www.redhat.com/en/blog/what-geneve
https://aws-hyoh.tistory.com/246