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

문제 상황

• 아임웹의 마이크로 프론트엔드 서빙 경로가 ALB 리스너 규칙 한도와 ECS 서비스당 Target Group 5개 제한에 막힌 상황
• 기존 ALB 증설로는 규칙 증식 문제와 ALB 간 연결 제약을 해소할 수 없는 구조
• 신규 워크로드를 별도 EKS 계정으로 옮기면서 계정·VPC 경계를 넘는 L7 라우팅과 GitOps 반영이 필요했던 상황

선택 이유

• North-South와 East-West를 분리하고, 계정 경계는 NLB, L7 라우팅은 Kong, 서비스 간 연결은 VPC Lattice로 역할 분담
• VPC와 계정 경계를 넘어 서비스를 공통 접근시키는 Lattice의 서비스 네트워크 모델이 진입점 수 증가 문제를 완화
• Kong db-less 모드와 Gateway API 조합이 Git 선언 기반 라우팅 운영 요구와 맞물림

장단점

• Lattice 자체는 서비스 단위 과금이라 앱 1개당 Service 1개 구조에서는 고정비가 빠르게 증가
• 여러 앱을 1개 Service에 통합하면 고정비를 크게 줄일 수 있지만, hostname 적용 범위와 라우팅 규칙 설계 제약이 있음
• Gateway API Controller의 1 HTTPRoute = 1 Lattice Service 제약, prefix 매칭과 PathPrefix 의미 차이, 규칙 수 한도 관리가 필요

주의할 점

• Pod Ready, Lattice HEALTHY, 실제 요청 수용 가능 시점이 달라 무중단 이관을 위해 편입 시점 제어가 필요
• 카나리 배포에서는 Service selector 전환 시점 때문에 readiness gate가 누락될 수 있음
• 공유 Service에서는 앱 단위 지표 식별이 어려워 Target Group 차원의 모니터링이 함께 필요