🔥 VPC 설계 패턴: 3-tier, Hub-and-Spoke, 그 외

섹션 2의 9편을 다 읽고 화이트보드에 부품을 죽 나열한 적이 있다. VPC, Subnet, Route Table, IGW, NAT, SG, NACL, Peering, TGW, Endpoint. 카드 열 장을 책상 위에 늘어놓고, 이 카드들을 어떻게 한 그림으로 모을지 매번 미뤄두었던 부분이다.

면접 자료나 기술 블로그에서 "3-tier 아키텍처", "Hub-and-Spoke", "CIDR 계획" 같은 단어는 자주 본다. 그런데 콘솔 사이드바에 그런 메뉴는 없다. 라우팅 테이블도 SG도 다 같은 메뉴에 들어 있는데, 이 단어들은 어디에서 만들어지는 건지 한 번도 정리한 적이 없었다.

부품 9편을 거꾸로 세는 정리는 도움이 안 된다. 도움이 되는 건 언제 어떤 형태로 그어야 하는가의 결정선이다. 결정선은 결국 한 가지 질문 위에 있다. VPC 한 개로 끝나는가, 두 개부터 어떻게 잇는가.

한 VPC 안의 세 계층: 3-tier

운영에 들어간 거의 모든 단순 워크로드는 한 VPC 안에 세 계층을 그어 시작한다. 위쪽에 Subnet: Public과 Private의 진짜 차이에서 본 Public Subnet 한 줄, 가운데 Private app subnet 한 줄, 아래에 데이터 저장소만을 위한 Private subnet 한 줄. 이 세 계층이 표준 3-tier 구조이다.

위 계층의 일은 단순하다. Application Load Balancer 한 대, 또는 Bastion 한 대. 인터넷에서 들어오는 요청을 받는 경계. 가운데 계층에는 EC2나 컨테이너에서 도는 애플리케이션 서버. ALB가 이 층의 ENI들에 트래픽을 분산해 넘긴다. 아래 계층은 RDS·ElastiCache 같은 데이터 저장소만 두는 영역이고, 인터넷이 닿는 라우트가 한 줄도 그어지지 않는다.

세 계층이 진짜 의미를 갖는 부분은 각 계층의 SG가 다음 계층의 SG만 source로 적는다는 한 가지 규칙이다. ALB의 SG는 외부에서 80/443을 받지만, 그 트래픽은 app SG의 SG ID를 source로 적은 한 줄을 통해서만 app 계층에 닿는다. app SG는 데이터 SG에 sg-xxxx 참조 한 줄로만 닿는다. CIDR 대신 SG 참조: Security Group: 인스턴스 레벨 방화벽에서 본 패턴이다.

3-AZ × 3 계층 구조면 subnet 9장이 된다. AZ당 3장씩 한 줄로 함께 다루고, 각 줄이 라우팅 테이블: 패킷이 어디로 가는지에서 본 라우팅 카드 한 장과 함께 동작한다. Public 계층의 카드만 0.0.0.0/0 → IGW를, Private app 계층의 카드는 0.0.0.0/0 → AZ별 NAT GW를, 데이터 계층의 카드는 0.0.0.0/0 행 자체를 두지 않는다. 데이터 계층이 인터넷을 모르는 상태가 isolated subnet의 정의다.

3-tier가 모든 워크로드의 답은 아니다. 단일 인스턴스에서 도는 서비스나 한 사람이 운영하는 사이드 프로젝트라면 데이터 계층까지 따로 그을 필요가 없다. RDS 한 대를 app subnet에 두고 SG로 막는 그림이 보통 더 단순하다. 데이터 계층 분리가 의미 있는 경우는 컴플라이언스가 데이터 격리를 명시하거나, 데이터 저장소의 SG 룰이 app과 다른 운영 정책을 따라야 할 때다.

VPC가 두 개부터: Hub-and-Spoke

서비스가 자라기 시작하면 VPC 한 개로 부족해지는 시점이 온다. 환경 분리(dev / staging / prod)를 계정 단위로 나누거나, 팀별로 격리된 VPC를 갖거나, 인수한 회사의 네트워크를 합치거나. 이유는 다르지만 결과는 같다. VPC 두 개를 어떻게 잇느냐가 다음 결정선이다.

VPC Peering과 Transit Gateway: VPC를 잇는 두 방법에서 본 임계점은 분명하다. VPC 5개 미만이면 Peering 메쉬가 더 싸고, 6~20개 회색 지대를 지나면 TGW가 사실상 기본값. Hub-and-Spoke는 VPC가 6개 이상으로 늘기 시작하는 시점에서 부품 한 개의 이름이 아니라 조직 차원의 토폴로지가 된다.

조직 차원이라는 말의 뜻은 이렇다. AWS Organizations 안에 Network 계정을 따로 하나 그어 둔다. 그 계정에 TGW 한 대, 그리고 두세 개의 공용 인프라 VPC가 산다. 워크로드 계정의 모든 VPC는 자기 계정의 attachment를 TGW에 꽂는다. spoke가 늘어도 hub의 구성은 같다.

공용 인프라 VPC는 보통 셋이다. 첫째 Egress VPC. NAT Gateway가 모여 있는 영역이고, 모든 spoke의 outbound 인터넷 트래픽이 TGW를 지나 이 VPC의 NAT를 거친다. 둘째 Inspection VPC. Gateway Load Balancer 뒤에 IDS·IPS·third-party 방화벽 어플라이언스를 배치해 inter-VPC 트래픽을 검사하는 역할. 셋째 Shared Services VPC. Active Directory, 사내 CI 러너, ECR pull-through cache처럼 모든 spoke가 같이 쓰는 자원을 둔다.

Hub-and-Spoke가 AWS의 공식 권장이라는 점도 한 번 짚을 만하다. AWS Well-Architected Framework Reliability Pillar의 REL02-BP04는 "Prefer hub-and-spoke topologies over many-to-many mesh"라는 한 줄로 못들어 있다 (verified 2026-04-26). 마케팅 권유가 아니라 운영 단순성이 fault domain 분리에 기여한다는 결론에서 나온 항목이다.

그런데 이 권장 다음에 한 가지 사실이 따라온다. TGW attachment 시간당 $0.05 + 데이터 처리 $0.02/GB(예시 리전 기준)는 spoke가 늘 때마다 곱해지고, 모든 inter-VPC 트래픽에 붙는다. dev 환경의 사실상 0에 가까운 트래픽에도 AWS는 attachment 시간당 비용을 그대로 부과한다. 6개 미만의 VPC에서 hub를 그어 두면, 같은 트래픽 패턴을 Peering으로 풀었을 때보다 매달 더 많은 청구서가 발생한다는 뜻이다. 언제 hub를 그을지는 토폴로지의 멋이 아니라 VPC 개수의 함수다.

CIDR 계획: IPAM과 reservation

Peering이든 TGW든 한 가지 함정에서 똑같은 결과로 끝난다. CIDR overlap. 두 VPC의 CIDR이 한 비트라도 겹치면 VPC Peering과 Transit Gateway: VPC를 잇는 두 방법에서 본 그림처럼 Peering은 즉시 fail, TGW는 attach는 받지만 prefix가 propagate되지 않는 silent 실패로 끝난다.

이 함정은 VPC를 처음 그을 때 막아야 한다. 이미 운영 중인 VPC 두 개의 CIDR이 겹쳐 있다는 사실을 hub를 그으면서 알게 되면, 한쪽 VPC의 primary CIDR을 바꿀 수 없다는 VPC란 무엇인가: 가상 네트워크의 경계의 한 줄이 AWS는 그 비용을 청구서에 그대로 추가한다. VPC를 다시 만들고 워크로드를 마이그레이션하는 길 외에는 답을 찾기 어렵다.

조직 단위 CIDR 계획이 들어서는 단계다. 보통 RFC 1918의 한 큰 블록(예: 10.0.0.0/8) 하나를 organization-wide로 reserve하고, 그 안을 사업부 / 환경 / 리전 단위로 잘라 쪼갠다. 한 사업부에 /12, 그 안을 환경별로 /14, 그 안을 리전별로 /16, 마지막에 한 VPC가 /18이나 /20을 받는 식의 계층. 어느 사업부의 어떤 환경이 어느 CIDR 블록을 갖는지는 organization 표 한 장에 적혀 있어야 한다.

이 계획을 손으로 표 관리하는 단계에서 AWS VPC IP Address Manager(IPAM) 가 들어선다. 2021년 12월 출시된 이 서비스는 IPv4·IPv6 주소 풀의 계층을 미리 만들어 두고, VPC를 새로 만들 때 그 풀에서만 CIDR을 할당받도록 강제하는 도구다. 풀 안에 자유 CIDR이 없으면 VPC 생성 자체가 실패한다. 같은 풀에서 두 사람이 같은 블록을 할당받지 않는다는 invariant가 도구 자체가 그 invariant를 강제한다.

IPAM은 두 tier로 나뉜다. 무료 한도는 organization-wide public IP insights를 무료로 주고, conflict detection·monitoring·BYOIP·Advanced 풀 같은 organization-wide 핵심 기능은 Advanced tier에서 사용할 수 있다. Advanced tier의 가격은 active IP address 한 개당 시간당 $0.00027(약 월 $0.20)다 (verified 2026-04-26, 공식 pricing 페이지). 한 organization이 보유한 active IP가 1만 개라면 월 $2,000 정도가 된다. 그 1만 IP 안에 CIDR overlap 사고 한 번이 일어났을 때의 마이그레이션 비용을 떠올리면, 이 한 줄을 비싸다고 느낄 환경은 드물다.

Isolated · Egress · Inspection · Shared Services: 보조 VPC 네 가지

세 가지 큰 패턴 외에 운영에서 자주 마주치는 보조 패턴 네 개를 한 줄씩 쓰면 이렇다.

Isolated VPC: 인터넷이 한 줄도 그어지지 않은 VPC. PCI 결제 처리, 내부 분석 워크로드처럼 외부와 닿을 일이 정말로 없는 워크로드를 두는 환경. NAT도 IGW도 없고, 외부 자원이 필요하면 VPC Endpoint: S3·DynamoDB에 나가지 않고 접근하기의 PrivateLink만 쓴다.

Egress VPC: 인터넷에 나가는 통로만 모아둔 VPC. NAT Gateway 한 묶음을 이 VPC에 두고, 모든 spoke VPC는 자기 NAT를 두지 않은 채 TGW를 통해 이 VPC의 NAT를 공유한다. NAT 시간당 비용을 spoke 수만큼 곱하지 않는 가장 흔한 비용 절감 패턴.

Inspection VPC: 모든 inter-VPC, on-premises ↔ VPC, VPC ↔ 인터넷 트래픽이 한 곳을 지나도록 강제하는 VPC. Gateway Load Balancer가 받는 트래픽을 IDS·IPS·third-party 방화벽 어플라이언스가 검사한다. AWS 매니지드 옵션으로는 AWS Network Firewall이 같은 역할을 맡을 수 있지만, third-party 어플라이언스를 쓸 때는 GWLB가 표준이다.

Shared Services VPC: Active Directory, 사내 CI 러너, ECR pull-through cache, 공용 모니터링 같은 모든 spoke가 똑같이 쓰는 자원만을 위한 VPC. 이 자원들을 spoke마다 복제하지 않고 한 곳에 두면 운영도 단순하고 비용도 spoke 수만큼 곱해지지 않는다.

결정의 기준은 부품이 아니라 임계점

섹션 2의 책상에 마지막으로 남는 한 줄은 부품 9개의 이름이 아니었다. VPC가 한 개인지 두 개부터인지, 데이터 계층이 따로 격리되어야 하는지 아닌지, NAT 한 묶음을 spoke마다 둘지 한 곳에 모을지: 결정선은 매번 임계점에 있다. 임계점은 보통 숫자 한두 개에서 결정한다. VPC 5개 미만, 트래픽 GB의 어느 한 줄이 NAT 청구서의 절반을 넘는 경우, organization 안의 active IP 1만 개를 넘기는 경우.

다음 섹션은 그 임계점이 어디에 있는지를 숫자로 보여 주는 도구로 넘어간다. CloudWatch와 그 주변. 부품을 그어 둔 다음 그 부품이 지금 어디에 있는지 확인하는 단계다.