VPC 라우팅과 게이트웨이

# VPC 라우팅과 게이트웨이 ## 소개글 > [!abstract] Introduction > [[VPC와 Subnet|서브넷]]으로 네트워크 공간을 분할한 뒤, 다음 과제는 트래픽의 흐름을 제어하는 것이다. VPC 내부의 서브넷 간 통신, 인터넷으로의 아웃바운드, 외부에서의 인바운드 — 이 모든 트래픽의 경로는 라우팅 테이블과 게이트웨이가 결정한다. 이 포스트에서는 라우팅 테이블의 작동 원리, Internet Gateway(IGW)의 NAT 메커니즘, NAT Gateway의 고가용성 설계, 그리고 IPv6 환경의 Egress-only IGW를 다룬다. ## 라우팅 테이블 ### 라우팅의 기본 원리 라우팅 테이블(*Route Table*)은 패킷의 목적지 IP 주소를 보고 다음 홉(*next hop*)을 결정하는 규칙의 집합이다. VPC를 생성하면 기본 라우팅 테이블(*Main Route Table*)이 자동으로 만들어지며, 명시적으로 다른 라우팅 테이블을 연결하지 않은 서브넷은 이 기본 테이블을 사용한다. 모든 VPC 라우팅 테이블에는 반드시 다음 경로가 포함된다. | 목적지 | 타겟 | 의미 | | :--- | :--- | :--- | | `10.0.0.0/16` (VPC CIDR) | `local` | VPC 내부 통신은 로컬 라우터가 처리 | 이 `local` 경로는 삭제하거나 수정할 수 없다. VPC 안의 모든 서브넷은 이 경로를 통해 서로 직접 통신할 수 있으며, 이것이 VPC가 하나의 논리적 네트워크로 동작하는 기반이다. ### 롱기스트 프리픽스 매치 AWS VPC 라우팅의 대원칙은 롱기스트 프리픽스 매치(*Longest Prefix Match*)다. 라우팅 테이블에 여러 경로가 매칭될 경우, 가장 구체적인(서브넷 마스크가 긴) 경로가 우선순위를 갖는다. 예를 들어, 라우팅 테이블에 다음 두 경로가 있다고 하자. | 목적지 | 타겟 | | :--- | :--- | | `10.0.0.0/16` | `local` | | `10.0.1.0/24` | `eni-abc123` | 목적지가 `10.0.1.5`인 패킷은 두 경로 모두에 매칭되지만, `/24`가 `/16`보다 더 구체적이므로 `eni-abc123`으로 전달된다. 이 원리를 활용하면 특정 서브넷의 트래픽만 가상 방화벽이나 검사 장비로 우회시키는 트래픽 엔지니어링이 가능하다. ### 퍼블릭 vs 프라이빗 라우팅 서브넷이 퍼블릭인지 프라이빗인지는 해당 서브넷에 연결된 라우팅 테이블의 기본 경로(`0.0.0.0/0`)가 어디를 가리키느냐로 결정된다. **퍼블릭 서브넷 라우팅 테이블:** | 목적지 | 타겟 | | :--- | :--- | | `10.0.0.0/16` | `local` | | `0.0.0.0/0` | `igw-xxxxxxxx` (Internet Gateway) | **프라이빗 서브넷 라우팅 테이블:** | 목적지 | 타겟 | | :------------ | :--------------------------- | | `10.0.0.0/16` | `local` | | `0.0.0.0/0` | `nat-xxxxxxxx` (NAT Gateway) | **데이터 서브넷 라우팅 테이블:** | 목적지 | 타겟 | | :--- | :--- | | `10.0.0.0/16` | `local` | | `pl-xxxxxxxx` (S3 Prefix List) | `vpce-xxxxxxxx` (Gateway Endpoint) | 데이터 서브넷에는 `0.0.0.0/0` 경로가 아예 없다. 인터넷으로의 경로 자체가 존재하지 않으므로, 라우팅 레벨에서 인터넷 접근이 차단된다. S3 같은 AWS 서비스에 접근할 때는 [[VPC Endpoint와 PrivateLink|Gateway Endpoint]]를 사용하여 인터넷을 완전히 우회한다. ## Internet Gateway (IGW) ### 동작 원리 IGW(Internet Gateway)는 VPC와 인터넷 사이의 논리적 관문이다. 물리적 라우터와 달리 IGW는 수평적으로 확장되는 고가용성 서비스로, 단일 실패 지점이 없으며 대역폭 제한도 사실상 존재하지 않는다. IGW의 핵심 기능은 퍼블릭 IP를 가진 인스턴스에 대한 1:1 정적 NAT[^nat-definition]다. 인스턴스는 VPC 내부에서 프라이빗 IP만 알고 있지만, IGW가 이를 퍼블릭 IP로 변환하여 인터넷과 통신한다. [^nat-definition]: NAT(Network Address Translation) — 사설 IP 주소를 공인 IP 주소로, 또는 그 반대로 변환하는 기술이다. 1:1 정적 NAT는 하나의 사설 IP가 하나의 고정된 공인 IP에 매핑되는 방식이다. ```mermaid sequenceDiagram participant EC2 as EC2 인스턴스 10.0.1.10 participant IGW as Internet Gateway participant WEB as 외부 웹 서버 203.0.113.50 EC2->>IGW: 출발: 10.0.1.10 → 203.0.113.50 Note over IGW: 소스 IP를 퍼블릭 IP로 변환 10.0.1.10 → 54.12.34.56 IGW->>WEB: 출발: 54.12.34.56 → 203.0.113.50 WEB->>IGW: 응답: 203.0.113.50 → 54.12.34.56 Note over IGW: 목적지 IP를 프라이빗 IP로 변환 54.12.34.56 → 10.0.1.10 IGW->>EC2: 응답: 203.0.113.50 → 10.0.1.10 ``` 인스턴스가 인터넷과 통신하려면 두 가지 조건이 충족되어야 한다. 첫째, 인스턴스에 퍼블릭 IP 또는 탄력적 IP(Elastic IP)가 할당되어 있어야 한다. 둘째, 해당 서브넷의 라우팅 테이블에 `0.0.0.0/0 → igw` 경로가 존재해야 한다. 두 조건 중 하나라도 빠지면 인터넷 통신은 불가능하다. ### IGW의 특성 IGW는 VPC당 하나만 연결할 수 있으며, 추가 비용이 발생하지 않는다. IGW 자체는 트래픽을 필터링하지 않으며, 트래픽 제어는 전적으로 [[Security Group]]과 [[NACL]]의 책임이다. IGW는 IPv4와 IPv6 트래픽을 모두 처리한다. ## NAT Gateway ### 필요성과 동작 원리 프라이빗 서브넷의 인스턴스는 퍼블릭 IP가 없으므로 IGW를 통해 직접 인터넷에 접근할 수 없다. 하지만 소프트웨어 패치 다운로드, 외부 API 호출 등 아웃바운드 인터넷 통신이 필요한 경우가 많다. 이때 사용하는 것이 NAT Gateway다. NAT Gateway는 퍼블릭 서브넷에 위치하며, 프라이빗 서브넷에서 오는 트래픽의 소스 IP를 자신의 탄력적 IP로 변환하여 인터넷으로 내보낸다. 외부에서 시작되는 인바운드 연결은 차단되므로, 프라이빗 서브넷의 인스턴스는 외부에 노출되지 않으면서 아웃바운드 통신만 수행할 수 있다. ```mermaid flowchart LR PRI["프라이빗 서브넷 10.0.2.10"] -->|"src: 10.0.2.10"| NAT["NAT Gateway EIP: 54.x.x.x"] NAT -->|"src: 54.x.x.x"| IGW["IGW"] IGW --> INET["인터넷"] INET -.->|"응답만 허용"| IGW IGW -.-> NAT NAT -.->|"dst: 10.0.2.10"| PRI ``` ### 고가용성 설계 NAT Gateway는 관리형 서비스로 높은 가용성을 제공하지만, 특정 AZ에 종속된다는 점을 반드시 인지해야 한다. 이것은 가장 흔한 VPC 설계 실수 중 하나다. **잘못된 구성:** AZ-A에만 NAT Gateway를 생성하고, AZ-B의 프라이빗 서브넷도 이 NAT Gateway를 공유하는 경우, AZ-A 장애 시 AZ-B의 인터넷 연결도 함께 단절된다. 이를 교차 AZ 장애(*cross-AZ failure*)라 한다. **올바른 구성:** 각 AZ마다 별도의 NAT Gateway를 생성하고, 해당 AZ의 프라이빗 서브넷은 자기 AZ의 NAT Gateway만 사용하도록 라우팅을 격리한다. ```mermaid flowchart TB subgraph AZA["가용 영역 A"] NAT_A["NAT GW-A EIP-A"] PRI_A["프라이빗 서브넷 A → NAT GW-A"] end subgraph AZB["가용 영역 B"] NAT_B["NAT GW-B EIP-B"] PRI_B["프라이빗 서브넷 B → NAT GW-B"] end NAT_A --> IGW["IGW"] NAT_B --> IGW IGW --> INET["인터넷"] ``` 이 구성은 AZ당 NAT Gateway 비용이 추가되지만(시간당 약 $0.045 × AZ 수), 교차 AZ 장애를 원천적으로 방지한다. ### 포트 고갈 문제 NAT Gateway는 단일 탄력적 IP에 대해 최대 약 55,000개의 동시 연결을 지원한다. 동일한 목적지 IP와 포트로의 연결이 이 한도를 초과하면 `ErrorPortAllocation` CloudWatch 지표가 발생하고 새로운 연결이 드롭된다. 대응 전략은 다음과 같다. 첫째, 하나의 NAT Gateway에 최대 8개의 탄력적 IP를 할당하여 포트 풀을 확장한다(8 × 55,000 ≈ 440,000 동시 연결). 둘째, `ErrorPortAllocation` 지표에 CloudWatch 알람을 설정하여 사전에 모니터링한다. 셋째, 대량의 S3 트래픽이 원인이라면 [[VPC Endpoint와 PrivateLink|Gateway Endpoint]]로 우회하여 NAT Gateway 부하를 줄인다. ### NAT Gateway 비용 구조 NAT Gateway는 VPC에서 비용 발생의 주요 원인 중 하나다. | 항목 | 비용 (us-east-1 기준) | | :--- | :--- | | 시간당 요금 | $0.045/시간 (≈ $32.4/월) | | 데이터 처리 | $0.045/GB | | AZ 간 데이터 전송 | $0.01/GB (추가) | 월 1TB의 데이터를 처리하는 NAT Gateway 하나의 비용은 약 $77.4(시간 요금 $32.4 + 처리 비용 $45)이다. 이 중 S3로 향하는 트래픽이 절반이라면, Gateway Endpoint를 사용하여 약 $22.5를 절감할 수 있다. 개발·테스트 환경처럼 고가용성이 덜 중요한 경우, `t4g.nano` EC2 인스턴스를 NAT 인스턴스로 활용하여 비용을 월 $3 수준으로 줄일 수 있다. 단, 이 경우 대역폭 제한과 수동 관리 부담이 따른다. ## Egress-only Internet Gateway (IPv6) ### IPv6 환경의 특수성 IPv6 환경에서는 모든 주소가 글로벌 유니캐스트 주소(*globally routable*)다. 즉 NAT 없이도 인터넷과 직접 통신할 수 있다. 그러나 프라이빗 서브넷의 보안 요구사항 — 외부에서 시작되는 접근 차단 — 은 여전히 필요하다. 이를 위해 AWS는 Egress-only Internet Gateway를 제공한다. 이 게이트웨이는 상태 저장 방화벽(*stateful firewall*)처럼 동작하여, 내부에서 시작된 통신의 응답 트래픽만 허용하고 외부에서 시작된 연결 시도는 차단한다. | 구성요소 | IPv4 | IPv6 | | :--- | :--- | :--- | | 퍼블릭 서브넷 인터넷 접근 | IGW | IGW | | 프라이빗 서브넷 아웃바운드 | NAT Gateway | Egress-only IGW | | 비용 | NAT GW: $0.045/시간 + $0.045/GB | Egress-only IGW: **무료** | Egress-only IGW는 추가 비용이 없으므로, IPv6 도입 시 NAT Gateway 비용을 완전히 제거할 수 있다. 이것이 IPv6 전환의 가장 직접적인 경제적 이점 중 하나다. ### Dual-Stack 전환 전략 IPv4에서 IPv6로의 즉시 전환은 현실적으로 어렵다. 대부분의 조직은 Dual-Stack 아키텍처 — VPC에 IPv4와 IPv6 CIDR을 모두 할당하는 방식 — 를 중간 단계로 채택한다. 외부 통신 시 IPv6를 우선 사용하도록 설정하면, NAT Gateway를 거치지 않고 Egress-only IGW를 통해 통신하므로 데이터 처리 비용을 절감할 수 있다. 2024년부터 AWS는 퍼블릭 IPv4 주소에 시간당 $0.005(월 약 $3.6)를 부과하기 시작했으므로, IPv6 전환의 경제적 동기는 더욱 강해지고 있다. ## 정리 라우팅 테이블과 게이트웨이는 VPC의 트래픽 흐름을 결정하는 핵심 제어 평면이다. 롱기스트 프리픽스 매치로 정밀한 트래픽 엔지니어링이 가능하며, IGW의 1:1 NAT와 NAT Gateway의 다대일 NAT가 퍼블릭·프라이빗 서브넷의 인터넷 접근을 각각 담당한다. NAT Gateway의 AZ 종속성과 포트 고갈은 설계 시 반드시 고려해야 할 제약이다. 트래픽 경로가 설정되었다면, 다음 단계는 그 트래픽을 누가 통과할 수 있는지를 제어하는 [[Security Group|보안 계층]]을 이해하는 것이다. --- ## 출처 - Amazon Web Services (2026) *Configure route tables.* Available at: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html - Amazon Web Services (2026) *Connect to the internet using an internet gateway.* Available at: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html - Amazon Web Services (2026) *NAT gateway use cases.* Available at: https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html - Amazon Web Services (2026) *Enable outbound IPv6 traffic using an egress-only internet gateway.* Available at: https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html - Amazon Web Services (2024) *New — AWS public IPv4 address charge.* Available at: https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/