네트워크 케이블로 연결된 미니어처 라우터들이 AWS VPC 라우팅과 게이트웨이 경로를 상징하는 이미지
글 요약
VPC 라우팅은 AWS 네트워크의 심장입니다. Internet Gateway, NAT Gateway, Transit Gateway 각각의 라우트 동작 방식과 우선순위를 명확히 이해해야 다운타임을 막을 수 있습니다. 이 글에서는 실무에서 자주 마주치는 라우팅 오류 사례와 해결 노하우, 그리고 게이트웨이별 비교 분석까지 한 번에 정리합니다.
“라우트 테이블은 만들었는데 왜 트래픽이 안 흐를까?”
VPC 라우팅 우선순위와 게이트웨이별 동작 차이를 모르면, 멀티 VPC 환경에서 한 번에 수십 개 서브넷이 통신 불능 상태에 빠질 수 있습니다. 이 글에서 IGW·NAT Gateway·Transit Gateway 라우팅의 실전 경로 분석과 흔한 실패 사례 해결법을 한 번에 정리합니다.
AWS에서 VPC를 처음 다루는 엔지니어라면 라우트 테이블을 단순한 설정 항목 정도로 생각하는 분들이 많습니다. 하지만 실제 운영 환경에서 가장 많은 장애가 라우팅 실수에서 비롯되더라고요. 게이트웨이를 만들었더라도 라우트 테이블에 연결하지 않으면 그건 그냥 공치사 같은 존재가 됩니다.
특히 Transit Gateway를 도입한 대규모 구성에서는 라우트 전파(route propagation)와 정적 경로(static route)가 뒤섞이면서 디버깅이 매우 복잡해집니다. 오늘은 핵심 게이트웨이 세 가지의 라우팅 동작을 차근차근 풀어보고, 실무에서 자주 보이는 실패 사례와 해결 노하우를 함께 나눠볼게요.
목차
📌 이 글의 핵심 정리
- VPC 라우팅은 가장 구체적인 prefix 매칭 우선순위로 동작하며, Internet Gateway·NAT Gateway·Transit Gateway 모두 라우트 테이블에 명시적으로 연결해야 비로소 작동합니다.
- NAT Gateway는 아웃바운드 전용이며, 인바운드 인터넷 접속이 필요한 워크로드는 반드시 별도의 퍼블릭 서브넷과 Internet Gateway 조합으로 구성해야 합니다.
- Transit Gateway는 라우트 전파를 활성화해야 자동으로 경로가 공유되며, 전파 없이 수동으로 만든 정적 경로만 등록하면 피어링 VPC 간 통신이 단절됩니다.
- 가장 흔한 실패 사례는 게이트웨이 생성 후 라우트 테이블 미연결이며, VPC Reachability Analyzer로 즉시 진단할 수 있습니다.
AWS VPC 라우팅 핵심 구조와 라우트 테이블 원리
라우트 테이블은 VPC의 교통 정리 담당
VPC를 만들면 자동으로 Main Route Table이 생성되고, 여기에 VPC CIDR 블록에 대한 로컬 라우트(local route)가 기본으로 들어갑니다. 이 로컬 라우트는 VPC 내부 통신을 담당하며 삭제하거나 변경할 수 없습니다. 모든 서브넷은 반드시 하나의 라우트 테이블과 연결되어야 하고, 명시적으로 다른 라우트 테이블을 지정하지 않은 서브넷은 자동으로 Main Route Table을 사용하게 됩니다.
라우팅 매칭은 가장 구체적인 prefix(longest prefix match) 원칙을 따릅니다. 예를 들어 라우트 테이블에 10.0.0.0/16 → local과 10.0.1.0/24 → igw-id가 동시에 있다면, 10.0.1.5에서 나가는 트래픽은 더 구체적인 /24 규칙을 따라 Internet Gateway로 향합니다. 이 우선순위 개념을 모르면 라우팅 디버깅에서 길을 잃기 쉽습니다.
target 지정 방식의 두 가지 종류
라우트 테이블에서 게이트웨이를 지정할 때는 두 가지 방법이 있습니다. 첫 번째는 라우트 전파(route propagation)으로, Transit Gateway나 VPN 같은 게이트웨이가 자동으로 경로를 라우트 테이블에 추가해 주는 방식입니다. 두 번째는 수동 정적 경로로, 운영자가 직접 목적지와 target을 입력하는 방식입니다. 둘 다 모르고 섞어 쓰면 같은 prefix가 중복 등록되어 우선순위가 꼬이는 사고가 발생합니다.
Internet Gateway 라우팅 실전 구성
AWS VPC 라우팅에서 사용하는 네트워크 게이트웨이 하드웨어의 측면 근접 사진
퍼블릭 서브넷을 만드는 진짜 조건
Internet Gateway(IGW)는 VPC에 attach한 후, 해당 VPC의 라우트 테이블에서 target으로 지정되어야 실제 트래픽을 처리합니다. 흔한 오해가 “서브넷 이름이 public이면 자동으로 인터넷 된다”라는 것인데, 실제로는 라우트 테이블에 0.0.0.0/0 → igw-id 라우트가 있어야만 그 서브넷이 퍼블릭으로 동작합니다.
인스턴스 단위에서도 Elastic IP 또는 퍼블릭 IP가 할당되어 있어야 인바운드 접속이 가능합니다. 사설 IP만 있는 인스턴스는 라우트 테이블이 IGW를 가리키더라도 외부에서 직접 접근할 수 없습니다. 이게 바로 “라우트는 있는데 외부 접속이 안 된다”는 문의의 단골 원인입니다.
IPv6 환경의 Egress-only Internet Gateway
IPv6를 함께 쓰는 환경이라면 Egress-only Internet Gateway를 알아둘 필요가 있습니다. IPv6는 주소 공간이 워낙 크기 때문에 모든 인스턴스에 글로벌 유니캐스트 주소가 부여되며, 기본적으로 양방향 통신이 됩니다. egress-only IGW는 아웃바운드만 허용하고 인바운드는 막아주기 때문에, IPv6에서 NAT 없이 사설 서브넷 효과를 내는 유일한 방법입니다.
💡 IGW 라우팅 꿀팁
- 서브넷 라우트 테이블에서 0.0.0.0/0이 IGW와 NAT Gateway 양쪽을 동시에 가리키도록 설정하지 마세요. 더 구체적인 prefix가 항상 우선되므로 의도치 않은 경로 우회가 발생합니다.
- 라우트 테이블 변경 직후에는 VPC Reachability Analyzer로 즉시 경로를 검증하는 습관을 들이세요. 콘솔에서 보는 라우트와 실제 트래픽 경로가 다를 수 있습니다.
NAT Gateway 동작 방식과 우선순위
NAT Gateway의 두 단계 라우팅 구조
NAT Gateway는 사실 두 단계의 라우팅이 필요합니다. 첫 번째는 사설 서브넷의 라우트 테이블에서 0.0.0.0/0 → nat-gw-id로 아웃바운드를 보내는 것이고, 두 번째는 NAT Gateway가 위치하는 퍼블릭 서브넷의 라우트 테이블에서 0.0.0.0/0 → igw-id로 최종 외부 트래픽을 전달하는 것입니다. 두 단계 중 하나라도 빠져버리면 사설 서브넷의 인스턴스는 외부 통신이 불가능해집니다.
NAT Gateway vs NAT Instance 비교
| 항목 | NAT Gateway | NAT Instance |
|---|---|---|
| 관리 방식 | AWS 완전 관리형 | EC2 직접 관리 |
| 가용성 | 단일 AZ 기본, 다중 AZ 구성 가능 | 운영자 스크립트에 의존 |
| 대역폭 | 최대 100 Gbps | 인스턴스 타입에 종속 |
| 비용 | 시간당 + 처리량 기반 | 인스턴스 비용만 |
NAT Gateway의 한계와 우회 전략
NAT Gateway는 아웃바운드 전용이라는 한계가 명확합니다. 외부에서 인바운드로 접속하려면 ALB, VPN, Direct Connect 같은 별도 경로가 필요합니다. 또한 단일 AZ에 배치된 NAT Gateway가 속한 AZ가 통째로 장애가 나면 다른 AZ의 사설 서브넷도 외부 접속이 끊어지므로, 각 AZ마다 별도 NAT Gateway를 두는 구성이 사실상 표준입니다.
⚠️ NAT Gateway 라우팅 주의
- NAT Gateway를 단일 AZ에만 배치하면 해당 AZ 장애 시 다른 AZ 워크로드도 외부 통신 불능 상태에 빠집니다. 반드시 AZ별로 분리 배치하세요.
- NAT Gateway가 사용하는 Elastic IP를 라우트 테이블에 직접 등록하지 마세요. target은 항상 NAT Gateway 리소스 ID를 지정해야 합니다.
Transit Gateway 멀티 VPC 경로 설계
Transit Gateway의 두 가지 라우트 테이블
Transit Gateway(TGW)는 자체 라우트 테이블을 갖고 있고, VPC attachment가 이 라우트 테이블과 연결되어 경로가 학습됩니다. 여기서 핵심은 두 가지 분리된 라우트 테이블입니다. 첫 번째는 TGW 라우트 테이블로 attachment 간 경로를 결정하고, 두 번째는 VPC 서브넷 라우트 테이블로 서브넷에서 TGW로 나가는 경로를 결정합니다. 둘 다 따로따로 설정해야 통신이 성립합니다.
라우트 전파와 정적 경로의 결합
대규모 멀티 VPC 환경에서는 라우트 전파(route propagation)를 적극 활용하는 것이 유지보수의 핵심입니다. TGW attachment에서 전파를 활성화하면 VPC CIDR이 자동으로 TGW 라우트 테이블에 등록되고, 반대 방향으로 TGW 라우트 테이블의 경로가 VPC 서브넷 라우트 테이블로도 자동 전파됩니다. 수십 개 VPC를 일일이 정적으로 등록하는 비효율을 없애주는 기능이죠.
다만 전파만으로는 부족한 경우가 있습니다. 예를 들어 중앙 방화벽 VPC를 통과시키는 Hub-and-Spoke 구조에서는 일반 VPC가 중앙 VPC만 학습하도록 라우트를 제한해야 하고, 이때는 정적 경로와 전파를 조합해 구성합니다. TGW 라우트 테이블에서 attachment별 라우트를 분리해 관리하는 것이 운영 노하우의 핵심입니다.
VPC 라우팅 실패 사례와 해결 노하우
실무에서 가장 많이 보는 라우팅 장애
한 금융사 운영팀에서 실제로 겪은 사례입니다. 신규 서비스를 배포하면서 NAT Gateway는 새로 만들었지만 사설 서브넷의 라우트 테이블에는 0.0.0.0/0 라우트가 IGW를 가리키도록 그대로 둔 채 배포해버린 케이스였어요. 인스턴스에서 outbound API 호출이 전부 타임아웃으로 떨어졌고, 로그를 추적해보니 패킷은 IGW로 갔지만 인바운드 응답이 사설 IP로 들어오지 못해 통신이 성립되지 않았습니다.
이 장애의 본질은 “게이트웨이 생성 ≠ 라우트 테이블 갱신”이라는 AWS 특유의 분리된 설계를 한 번에 처리하지 못한 데 있습니다.
전문가의 해결 노하우
해결책은 단순하지만, 적용 방식이 중요합니다. 첫째, VPC Reachability Analyzer를 사용해 출발지-목적지 IP 쌍으로 실제 경로를 시각화합니다. 콘솔에서 라우트 테이블만 보는 것과 실제로 패킷이 도달하는 경로가 다른 경우가 종종 있거든요. 둘째, 라우트 테이블 변경은 항상 Terraform/CloudFormation 같은 IaC로 단일 트랜잭션에 묶어 처리합니다. 스크립트 중간에 실패하면 라우트 테이블과 게이트웨이가 불일치한 상태가 남기 때문입니다.
셋째, Transit Gateway 환경이라면 VPC attachment 생성 시 라우트 전파 propagation을 기본 활성화로 두세요. 운영 초기에는 정적 경로만 사용하다가 VPC가 늘어날수록 정적 경로 누락이 반복되는 패턴이 정말 많습니다. 넷째, CloudWatch 로그에서 VPC Flow Logs를 활성화해 REJECT되는 트래픽 패턴을 주기적으로 모니터링하는 것도 라우팅 장애를 조기 발견하는 노하우입니다.
💡 라우팅 디버깅 꿀팁
- Reachability Analyzer 결과가 “Not reachable”이면 라우트 테이블 → 보안그룹 → NACL 순서로 의심 지점을 좁혀가세요. 이 세 단계가 VPC 트래픽의 삼종 세트입니다.
- Transit Gateway 운영 시에는 TGW 라우트 테이블을 attachment 단위로 시각화한 다이어그램을 항상 최신 상태로 유지하는 것이 사고 대응 속도를 좌우합니다.
AWS 라우팅 솔루션 비교 분석
핵심 게이트웨이 3종 한눈에 비교
Internet Gateway · NAT Gateway · Transit Gateway 상세 비교
| 구분 | Internet Gateway | NAT Gateway | Transit Gateway |
|---|---|---|---|
| 주 용도 | VPC ↔ 인터넷 양방향 | 사설 서브넷의 아웃바운드 전용 | VPC·VPN·DX 간 허브 라우팅 |
| 트래픽 방향 | Inbound + Outbound | Outbound only | VPC/VPN 간 양방향 |
| 스케일 | VPC당 1개, 가용성 자동 | AZ별 1개 권장 | 리전당 1개, 다중 TGW 가능 |
| 라우트 전파 | 수동 등록 | 수동 등록 | 자동 전파 지원 |
| 비용 구조 | 무료 | 시간당 + GB당 과금 | attachment당 + 데이터 처리량 |
VPC Peering vs Transit Gateway
VPC Peering은 두 VPC 간 1:1 연결만 지원하기 때문에 VPC가 N개일 때 N×(N-1)/2 개의 피어링이 필요합니다. 반면 Transit Gateway는 하나의 허브에 모든 VPC를 연결하는 스타 토폴로지를 지원해 N개 VPC 연결에 필요한 링크 수를 N개로 줄여줍니다. VPC가 5개 이상이면 관리 복잡도와 비용 측면에서 Transit Gateway가 압도적으로 유리합니다.
Direct Connect vs Transit Gateway
Direct Connect는 온프레미스 ↔ AWS 전용선이고, Transit Gateway는 AWS 내부 VPC/VPN 허브입니다. 이 둘은 경쟁 관계가 아니라 Transit Gateway에 Direct Connect Gateway를 연결해 모든 VPC로 전용선 트래픽을 분산시키는 형태로 결합합니다. 단순 VPN만 쓸지, Transit Gateway + Direct Connect 조합으로 갈지는 트래픽 규모와 안정성 요구 수준에 따라 결정합니다.
자주 묻는 질문
Q. NAT Gateway 없이 사설 서브넷에서 인터넷 아웃바운드만 처리하려면 어떻게 하나요?
A. NAT Gateway가 사실상 유일한 관리형 옵션입니다. NAT Instance로 대체할 수는 있지만 패치 관리, 스케일링, HA 구성을 모두 직접 해야 하므로 운영 부담이 큽니다.
Q. Transit Gateway 라우트 전파와 정적 경로를 동시에 쓸 수 있나요?
A. 네, 가능합니다. 일반 VPC는 자동 전파로 처리하고, 중앙 방화벽 VPC나 특수 경로는 정적 경로로 override하는 패턴이 가장 흔한 운영 방식입니다.
Q. 라우트 테이블은 VPC당 몇 개까지 만들 수 있나요?
A. 기본 한도 내에서 VPC당 수백 개의 라우트 테이블 생성이 가능하며, 서브넷은 그중 하나에만 연결됩니다. 계정 한도는 AWS Support를 통해 상향 조정할 수 있습니다.
Q. 동일 VPC 안에서 Internet Gateway 라우트와 NAT Gateway 라우트가 동시에 있으면 어떻게 되나요?
A. longest prefix match 원칙에 따라 더 구체적인 라우트가 우선하고, 동일한 prefix라면 라우트 테이블에 먼저 등록된 항목이 적용됩니다. 의도치 않은 혼선을 막기 위해 하나의 서브넷에는 한 방향의 기본 라우트만 두는 것이 안전합니다.
VPC 라우팅은 결국 “게이트웨이를 만든다”와 “라우트 테이블을 연결한다”가 별개의 작업이라는 점을 얼마나 빨리 체득하느냐가 운영 안정성의 핵심입니다. Reachability Analyzer와 VPC Flow Logs를 일상적인 진단 도구로 자리 잡게 만들고, Transit Gateway 환경이라면 라우트 전파를 기본 활성화로 두는 것만으로도 상당수의 라우팅 장애를 예방할 수 있습니다. 오늘 정리한 비교표와 실패 사례가 실제 아키텍처 설계와 트러블슈팅에 도움이 되셨길 바랍니다.
면책조항
본 글은 AWS 공식 문서와 일반적인 클라우드 운영 경험을 바탕으로 작성된 참고용 가이드입니다. 실제 서비스에 적용하기 전에는 반드시 최신 AWS 공식 문서를 확인하시고, 사내 보안 정책과 아키텍처 가이드라인에 부합하는지 검토하시기 바랍니다. 글에서 제시된 비용 수치와 한도는 AWS 요금 정책과 계정 한도에 따라 변동될 수 있으며, 본 콘텐츠는 어떠한 보증도 제공하지 않습니다.
