네트워크 레이어 설계의 핵심

클라우드 인프라의 뼈대인 VPC를 설계할 때, “가용영역(AZ)은 무조건 최대로 쓸수록 좋다"는 생각에 빠지기 쉽습니다. 하지만 실전 아키텍처에서는 비용, 성능, 관리 복잡성 사이의 균형점이 필요하다고 생각합니다.

AZ(Availability Zone) 전략: 3AZ? 2AZ?

대부분의 가이드에서는 고가용성(HA)을 위해 3개 이상의 AZ를 쓰라고 권장합니다. 하지만 실제 운영 환경, 특히 **EKS(Kubernetes)**를 운영할 때는 2개의 AZ가 더 효율적인 경우도 얼마든지 있습니다.

1. Topology Aware Routing(TAR)의 수학적 한계와 Fallback

Kubernetes의 Topology Aware Routing은 트래픽을 같은 AZ 내로 유지해 비용절감에 효율적입니다. 하지만 여기에는 ‘버그’처럼 보이는 기술적 **안전장치(Safeguard)**가 있습니다.

  • 비율 계산의 딜레마: K8s의 EndpointSlice 컨트롤러는 “각 AZ의 노드 CPU 용량 비율"과 “파드(엔드포인트)의 비율"이 일치하는지 항상 계산합니다. 특정 AZ에 노드가 추가되어 CPU 용량이 커졌는데 파드는 그대로라면, K8s는 해당 파드가 과부하될 것을 우려해 **TAR 힌트를 즉시 제거(Fallback)**해버립니다.

  • 1파드/AZ의 문제: 3개의 AZ에 파드가 각각 1개씩 있을 때, 어느 한 구역의 노드 리소스 비율이 조금만 틀어져도 수학적 균형이 깨져 TAR 기능이 꺼지게 됩니다. 결국 다시 모든 AZ로 트래픽이 퍼지는(Round-Robin) 상태가 되어 비용 절감 효과가 사라집니다. 안정적인 로컬 라우팅을 위해서는 각 AZ당 최소 2~3개 이상의 넉넉한 파드가 배치되어 오차 범위를 흡수할 수 있어야 합니다.

2. 리소스 낭비(Over-provisioning)와 비용

Istio의 Locality Load Balancing이나 K8s TAR를 쓴다는 것은 각 AZ를 독립적인 ‘섬’처럼 운영하겠다는 의미입니다.

  • 독립적 수용 능력: 특정 AZ에 트래픽 스파이크가 발생해도 다른 AZ로 트래픽을 넘기지 않으려면, 모든 AZ가 각각 피크 트래픽을 감당할 수 있는 잉여 자원을 상시 보유해야 합니다.
  • AZ 개수와 비용의 상관관계: 3개의 AZ를 쓰면 3개 구역 모두에 오버프로비저닝을 해야 하므로, 2개의 AZ를 쓸 때보다 ‘상시 대기’ 중인 잉여 파드 비용이 기하급수적으로 늘어납니다.

3. 전략적 선택: 2-AZ vs 3-AZ

무조건적인 표준보다는 서비스의 성격에 따른 트레이드오프를 고려해야 합니다.

고려 사항 2 Multi-AZ (실용적 선택) 3 Multi-AZ (표준 아키텍처)
비용 및 리소스 적은 파드로도 TAR 유지가 쉬워 효율적임 최소 유지 파드 수가 많아 비용 증가
운영 안정성 트래픽 비율 계산이 단순해 TAR 유지가 잘 됨 비대칭 상황 시 Fallback 발생 확률 높음
장애 복원력 1개 AZ 장애 시 남은 AZ가 100% 부담 (연쇄 장애 위험) 1개 AZ 장애 시 남은 AZ가 50%씩 분담 (안정적)

4. 가용성 측면의 현실적 타협

3,4개의 AZ를 써서 얻는 가용성상의 이점보다, 그로 인해 발생하는 복잡한 구성(6,8개의 서브넷, 수많은 라우팅 테이블 관리 등)의 리스크가 더 클 수 있습니다. 만약 2개 가용영역으로 부족할 정도의 가용성이 필요하다면, 차라리 멀티 리전(Multi-Region) 구성을 고려하는 것이 아키텍처적으로 더 안정적인 선택일 수 있습니다.

VPC Interconnect: Peering vs Transit Gateway

여러 VPC를 연결해야 할 때 가장 많이 고민하는 지점입니다.

항목 VPC Peering Transit Gateway (TGW)
비용 낮음 (연결 비용 없음) 높음 (시간당 과금 + 데이터 처리량)
성능 매우 우수 (지연 시간 최소) 보통 (중앙 집중형으로 인한 홉 증가)
복잡성 1:1 연결로 인해 연결 망이 커지면 관리 힘듦 중앙 집중형으로 관리 매우 편리
추천 상황 소수의 VPC 간 고성능 통신이 필요할 때 수십 개의 VPC와 온프레미스를 통합 관리할 때

실전 제언

규모가 아주 큰 엔터프라이즈가 아니라면, 성능과 비용 면에서 압도적인 VPC Peering을 우선 고려하세요. TGW는 편리하지만 비싼 “관리형 도구"입니다.

실전: 테라폼으로 2-AZ VPC 구축하기

지금까지 다룬 이론적 배경(2-AZ의 효율성, Peering vs TGW)을 바탕으로, 실제 테라폼 코드를 어떻게 작성하고 관리하는지 상세 가이드를 준비했습니다.

👉 다음 글: Terraform 실전: 2-AZ VPC와 서브넷 설계 (HCL Deep Dive)