VPC Lattice 6개월 써보니 보이는 것들

처음에 기대했던 것

작년 가을, 우리 팀은 VPC를 5개 운영 중이었다. 메인 워크로드 VPC, 데이터 분석 VPC, 사내 도구 VPC, 보안 격리 VPC, 그리고 신규 사업 VPC. 각 VPC끼리 서비스를 호출해야 하는 케이스가 슬슬 늘어나면서 PrivateLink와 Transit Gateway가 거미줄처럼 얽혀 있었다. 어떤 서비스가 어디에 노출돼 있는지 추적하는 게 자체로 일이었다. 이 시점에 VPC Lattice를 도입하기로 결정했고, 지금은 약 6개월째 운영 중이다. 잘한 결정인지 묻는다면 솔직히 반반이다.

이 글은 칭찬도 비판도 섞인 후기다. 도입을 검토 중인 분이라면 좀 도움이 될 것 같다.

마케팅 페이지만 보면 정말 끌린다. VPC끼리 서비스를 노출하는데 NLB나 PrivateLink Endpoint를 일일이 만들 필요가 없고, IAM 기반 인증까지 붙여준다. mTLS도 받쳐준다고 했다. 우리 팀은 특히 이걸 보고 결정했다. "VPC 토폴로지를 신경 쓰지 않고 서비스만 노출하면 된다" — 이게 가능하면 운영 부담이 확 줄어들 거라고 생각했다.

도입 결정이 빨랐던 건 사실이다. PoC는 한 주 정도 했는데, 단순 케이스에서는 진짜 잘 돌아갔다. Service Network 만들고, 각 VPC를 association 시키고, 서비스 등록하면 끝이었다. 너무 쉬워서 뭔가 함정이 있을 거라고 생각은 했는데, 그 함정이 운영 들어가서 본격적으로 보이기 시작했다.

잘한 점부터

먼저 칭찬할 부분. PrivateLink Endpoint를 안 만들어도 되는 건 진짜다. 5개 VPC가 메시처럼 통신해야 했을 때, 기존 PrivateLink 방식이라면 endpoint를 N×M으로 만들어야 했다. 매번 누가 무엇에 접근해야 하는지 검토하고, 보안팀에 승인 받고, Terraform으로 정의하고. Lattice는 Service Network 하나에 VPC들을 association 시키면 끝난다. 운영 부담이 체감으로 줄었다.

그리고 IAM 기반 auth policy. 이건 정말 매끄럽게 동작한다. 호출 측 IAM principal을 기반으로 서비스 단위 인가를 걸 수 있어서, 별도 토큰 발급 인프라가 필요 없어졌다. 데이터 분석팀에서 메인 워크로드 API 호출할 때 매번 시크릿 매니저로 토큰 갱신하던 걸 IAM SigV4로 다 걷어냈다. 좋다.

작년 5월에 GA된 TLS Passthrough 덕분에 mTLS 엔드 투 엔드도 가능해졌다. 우리는 PCI 영역 일부를 Lattice 경유로 바꿨는데, SNI 기반 라우팅 + TLS 패스스루로 내부 인증서 검증을 그대로 유지할 수 있었다. 이거 없었으면 PCI 쪽은 Lattice 못 쓸 뻔했다.

그런데 아쉬운 점

여기서부터 솔직한 얘기. 첫 번째는 비용이다. Lattice는 시간당 + 처리 데이터 GB당 과금인데, 트래픽이 많은 서비스에서는 PrivateLink보다 비싸진다. 우리 케이스에서 분석팀 ETL이 메인 DB API를 호출하는 경로가 있었는데, 일 트래픽이 늘면서 한 달 지나서 보니 NLB+PrivateLink 시절보다 약 1.7배 비용이 나왔다. 이건 운영 시작 후 한참 뒤에 알게 됐다. 비용 산정할 때는 시간당 요금만 보지 말고, GB당 처리 비용을 트래픽 추정치에 곱해서 봐야 한다.

두 번째는 디버깅이 답답하다. 어디서 문제가 났는지 추적하기가 어렵다. 호출이 실패하면 IAM auth policy 거부인지, target group 헬스체크 실패인지, listener rule mismatch인지, 클라이언트 SDK SigV4 서명 문제인지 분간이 안 갈 때가 많다. 액세스 로그를 S3로 보내놓긴 했는데, 로그에 찍히는 정보가 ALB 액세스 로그만큼 친절하지 않다. 새벽에 한 번 멘탈 나간 적이 있는데, 결국 원인은 target group의 health check path가 우리 앱에 없어서 unhealthy 상태였던 건데 이걸 알아내는 데 두 시간 걸렸다. 콘솔에서 "왜 unhealthy냐"를 빠르게 보여주는 UI가 좀 부족하다.

세 번째는 Terraform 지원이 더디다는 점. 작년 봄에 TLS Passthrough가 GA 됐는데, Terraform AWS provider에서 vpclattice_listener의 TLS_PASSTHROUGH 프로토콜이 한동안 지원이 안 됐다. 임시로 콘솔에서 만들고 import 하는 식으로 우회했는데, 이런 게 "신기능 빨리 따라가는 팀"에는 꽤 거슬린다. 지금은 거의 다 따라잡힌 것 같지만, AWS의 다른 신기능과 마찬가지로 IaC 도구 지원에는 시차가 있다.

네 번째는 멀티 리전. 같은 리전 안에서는 VPC를 가로질러도 잘 동작하는데, 리전을 넘는 케이스는 Lattice가 직접 풀어주지 않는다. 결국 리전간 통신은 다른 방식(VPC peering + Transit Gateway 등)이 필요하고, Lattice는 리전 안 트래픽만 정리해주는 도구로 봐야 한다. 우리도 처음에 이걸 헷갈렸다.

그래서 누구한테 추천하나

곰곰이 생각해 보면 Lattice가 빛나는 케이스는 정해져 있다.

VPC가 3개 이상이고 서로 서비스 호출이 빈번하면, 운영 부담 측면에서 확실히 이득이다. 반대로 VPC가 1~2개고 트래픽이 큰 단순한 토폴로지라면, NLB+PrivateLink가 비용 면에서 나을 수 있다.

조직 내에서 IAM 기반 인가를 일관되게 가져가고 싶다면 좋다. 호출 측 principal로 인가를 거는 걸 별도 인프라 없이 해주니까.

반면 트래픽이 매우 큰 데이터 파이프라인이라면 비용 시뮬레이션을 꼭 먼저 해 봐야 한다. 처리 데이터 GB당 과금이 누적되면 무섭다.

6개월 지나서 결론

우리 팀에서는 절반의 워크로드를 Lattice로 옮겼고, 나머지 절반은 그대로 PrivateLink로 두기로 했다. 모두를 Lattice로 통일하는 게 처음 목표였는데, 비용/지연/디버깅을 따져보니 그 결정이 일률적으로 맞지는 않았다. 도구는 도구일 뿐, 모든 케이스를 풀어주지 않는다는 평범한 결론이다.

추천하지 않는다는 얘기는 아니다. 다만 마케팅 페이지의 "복잡한 토폴로지를 단순화"라는 말만 보고 들어가면 운영하면서 후회할 수 있다. PoC를 단순 케이스로 빨리 끝내지 말고, 진짜 운영 시나리오 — 헬스체크 실패, IAM 거부, 큰 트래픽 — 를 다 한 번씩 시뮬레이션 해 보고 들어가는 걸 권한다.

다음에는 Lattice의 액세스 로그를 OpenSearch로 가공해서 보고 있는 방식을 따로 정리해보려고 한다. 이게 디버깅 답답함을 어느 정도 해소해줬다.