VPC Lattice 기반 서비스 네트워크 재설계와 비용 최적화 사례

문제 상황

• ALB 규칙 증가, ECS Target Group 5개 제한, ALB 체인 확장 불가로 MFE 서빙 경로가 확장 한계에 도달
• 신규 EKS 클러스터와 기존 운영 계정·VPC 경계를 넘는 host/path 기반 라우팅, GitOps 반영, private subnet 유지 필요
• Lattice를 전 구간 라우터로 쓰는 방식과 ALB·CloudFront 진입점 직접 연결은 검증 결과 불가

구조와 흐름

• North-South와 East-West를 분리하고, ALB는 기존 진입점 유지, NLB는 계정 경계 통과, Kong은 L7 라우팅, VPC Lattice는 서비스 간 연결 담당
• Kong의 HTTPRoute는 ExternalName Service를 거쳐 Lattice 도메인으로 연결되며, Host 재작성과 X-Forwarded-Host 전달로 원본 도메인 보존
• GitOps 선언 1개에서 ArgoCD, AWS Gateway API Controller, external-dns가 연쇄적으로 라우팅과 DNS를 생성

선택 이유

• VPC Lattice는 서비스 네트워크로 여러 VPC·계정에서 공통 접근이 가능해, 진입점 수와 앱 수가 곱해지던 연결 구성을 줄일 수 있음
• NLB는 ALB 뒤에 둘 수 있는 고정 IP 경계 통과 수단이라 남은 선택지였고, Kong은 db-less Git 선언 반영과 중앙 관리에 적합
• Istio는 과도하게 무겁고, ALB 증설은 원인 구조를 바꾸지 못해 배제

성능/운영 포인트

• Lattice Service 79개를 14개로 통합해 월 고정비를 82% 절감
• HTTPRoute 1개가 Service 1개에만 매핑되는 컨트롤러 제약으로 인해 공유 HTTPRoute 중앙화, 규칙 길이 정렬, PR/CI 한도 검사 필요
• Target Group과 그룹 단위 RPS 모니터링으로 통합 후 처리량 한도 관리