프라이빗 서브넷의 인스턴스는 퍼블릭 IP가 없으므로 인터넷 게이트웨이를 통해 직접 인터넷에 접근할 수 없습니다. 그러나 소프트웨어 패치 다운로드, 외부 API 호출 등 아웃바운드 인터넷 통신이 필수적입니다. NAT 게이트웨이는 이러한 통신을 안전하게 중개하면서, 관리형 서비스로서의 고가용성을 제공합니다. 이 글에서는 NAT 게이트웨이의 동작 원리, AZ별 고가용성 설계, 포트 고갈 문제와 해결책, 그리고 비용 최적화 전략을 살펴봅니다.
NAT Gateway
필요성과 동작 원리
프라이빗 서브넷의 인스턴스는 퍼블릭 IP가 없으므로 인터넷 게이트웨이를 통해 직접 인터넷에 접근할 수 없다. 하지만 소프트웨어 패치 다운로드, 외부 API 호출 등 아웃바운드 인터넷 통신이 필요한 경우가 많다. 이때 사용하는 것이 NAT 게이트웨이(NAT Gateway)다.
NAT 게이트웨이는 퍼블릭 서브넷에 위치하며, 프라이빗 서브넷에서 오는 트래픽의 소스 IP를 자신의 탄력적 IP로 변환하여 인터넷으로 내보낸다. 외부에서 시작되는 인바운드 연결은 차단되므로, 프라이빗 서브넷의 인스턴스는 외부에 노출되지 않으면서 아웃바운드 통신만 수행할 수 있다.
고가용성 설계
NAT 게이트웨이는 관리형 서비스로 높은 가용성을 제공하지만, 특정 가용 구역(AZ)에 종속된다는 점을 반드시 인지해야 한다. 이것은 가장 흔한 VPC 설계 실수 중 하나다.
- 잘못된 구성: AZ-A에만 NAT 게이트웨이를 생성하고, AZ-B의 프라이빗 서브넷도 이 NAT 게이트웨이를 공유하는 경우, AZ-A 장애 시 AZ-B의 인터넷 연결도 함께 단절된다. 이를 교차 AZ 장애(cross-AZ failure)라 한다.
- 올바른 구성: 각 AZ마다 별도의 NAT 게이트웨이를 생성하고, 해당 AZ의 프라이빗 서브넷은 자기 AZ의 NAT 게이트웨이만 사용하도록 라우팅을 격리한다.
이 구성은 AZ당 NAT 게이트웨이 비용이 추가되지만(시간당 약 $0.045 × AZ 수), 교차 AZ 장애를 원천적으로 방지한다.
포트 고갈 문제
NAT 게이트웨이는 단일 탄력적 IP에 대해 최대 약 55,000개의 동시 연결을 지원한다. 동일한 목적지 IP와 포트로의 연결이 이 한도를 초과하면 ErrorPortAllocation CloudWatch 지표가 발생하고 새로운 연결이 드롭된다.
대응 전략은 다음과 같다. 첫째, 하나의 NAT 게이트웨이에 최대 8개의 탄력적 IP를 할당하여 포트 풀을 확장한다(8 × 55,000 ≈ 440,000 동시 연결). 둘째, ErrorPortAllocation 지표에 CloudWatch 알람을 설정하여 사전에 모니터링한다. 셋째, 대량의 S3 트래픽이 원인이라면 게이트웨이 엔드포인트로 우회하여 NAT 게이트웨이 부하를 줄인다.
NAT Gateway 비용 구조
NAT Gateway는 VPC에서 비용 발생의 주요 원인 중 하나다.
| 항목 | 비용 (us-east-1 기준) |
|---|---|
| 시간당 요금 | 32.4/월) |
| 데이터 처리 | $0.045/GB |
| AZ 간 데이터 전송 | $0.01/GB (추가) |
월 1TB의 데이터를 처리하는 NAT 게이트웨이 하나의 비용은 약 32.4 + 처리 비용 22.5를 절감할 수 있다.
개발·테스트 환경처럼 고가용성이 덜 중요한 경우, t4g.nano EC2 인스턴스를 NAT 인스턴스로 활용하여 비용을 월 $3 수준으로 줄일 수 있다. 단, 이 경우 대역폭 제한과 수동 관리 부담이 따른다.
출처
- 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) Configure route tables. Available at: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html