Regional NAT Gateway: 다중 가용 영역 환경에서의 실전 적용 가이드

기존 Amazon VPC Zonal NAT Gateway는 다중 가용 영역(Availability Zones, AZ) 환경에서 가용 영역별로 NAT를 생성하고 라우팅을 관리해야 하기 때문에, 가용 영역이 늘어날수록 운영 복잡도가 증가합니다. 2025년 11월 19일에 출시된 Regional NAT Gateway는 리전 단위로 NAT Gateway를 제공하고, 워크로드 분포에 따라 가용 영역으로 자동 확장/축소되는 방식으로 이러한 운영 부담을 줄일 수 있는 옵션을 제공합니다.

프로덕션 환경에 적용하기 전에 알아두어야 할 주요 특성들이 있습니다.

Internet Gatewat(IGW)가 없는 VPC는 Regional NAT Gateway 생성 불가
가용 영역에 Elastic network interfaces(ENI) 유무를 인식하여 확장이 트리거 됨
확장 중에는 일시적으로 서로 다른 가용 영역간 트래픽이 발생할 수 있음
Automatic 모드에서는 축소 후 재확장 시 Elastic IP(EIP)가 변경될 수 있음
퍼블릭/프라이빗 혼합 VPC에서는 퍼블릭 서브넷의 ENI도 확장 트리거가 됨

이 게시글에서는 실제 테스트를 통해 확인한 Regional NAT Gateway의 동작 방식과 고려사항을 중심으로 소개합니다.

기존 Zonal NAT Gateway의 운영 방식

<그림 1. VPC 생성 시 퍼블릭 서브넷 없이 Zonal NATGW 생성 불가>

Zonal NAT Gateway는 가용영역 단위로 동작하는 리소스입니다. 다중 가용 영역 환경에서는 다음과 같은 작업들이 필요합니다.

각 가용 영역마다 NAT Gateway를 퍼블릭 서브넷에 생성
프라이빗 서브넷의 라우팅 테이블에서 동일 가용 영역의 NAT Gateway를 지정하여 가용 영역의 affinity 유지
가용 영역 추가 시 NAT Gateway 생성, EIP 할당, 라우팅 테이블 수정

이러한 요구 조건은 다중 가용 영역 환경에서는 운영 복잡도와 변경관리 부담이 더 크게 느껴질 수 있습니다.

Regional NAT Gateway의 설계 방향

Regional NAT Gateway는 다음과 같은 방향으로 설계되었습니다.

NAT Gateway 및 라우팅 구성 단순화
가용 영역확장/축소 자동화
퍼블릭 서브넷 의존성 제거
Private-only VPC 아키텍처 지원
다중 가용 영역 고가용성 자동 보장

주요 차이점

1. AZ Affinity 관리 방식

Zonal NAT Gateway에서는 고객이 가용 영역별 라우팅 테이블을 직접 구성해야 가용 영역의 affinity를 유지할 수 있습니다. 구성 실수 시 서로 다른 가용 영역간의 트래픽이 발생할 수 있습니다.

Regional NAT Gateway에서는 모든 프라이빗 서브넷이 동일한 NAT Gateway ID로 라우팅하며, 가용 영역의 affinity는 AWS가 내부적으로 처리합니다. 라우팅 설계가 가용 영역 중심에서 VPC 단위의 패턴으로 바뀝니다.

2. 라우팅 구성

Zonal 환경에서는 가용 영역별로 route table을 분리하는 것이 일반적이며, 자주는 아니지만, NAT Gateway 변경 시마다 작업이 필요합니다.

Regional 환경에서는 여러 프라이빗 서브넷이 동일한 NAT Gateway를 대상으로 설정할 수 있어 표준 라우팅 템플릿 운영이 가능합니다.

3. 퍼블릭 서브넷 요구사항

<그림 2. Regional NATGW 생성 화면>

Regional NAT Gateway는 NAT Gateway 호스팅을 위한 퍼블릭 서브넷이 필수가 아니기 때문에, Private-only VPC 구성이 가능합니다. 다만 IGW는 여전히 필요합니다. 실제 테스트에서 IGW가 없는 VPC는 Regional NAT 생성 화면에서 선택 메뉴에 나타나지 않았습니다.

그리고 Regional NATGW 가 이미 존재하는 VPC 는 IGW 를 Detach 할 수 없습니다.

<그림 3. Regional NATGW 가 존재할 때 IGW Detach 불가>

퍼블릭 IP 할당 방식

Regional NAT Gateway는 두 가지 IP 할당 방식을 제공합니다.

1. 자동(Automatic) 모드

AWS가 퍼블릭 IP를 자동으로 할당하고 관리합니다. 고객이 EIP를 직접 지정할 수 없으며, 확장/축소에 따라 사용되는 퍼블릭 IP가 변경될 수 있습니다. 테스트에서 축소 후 재확장 시 새로운 EIP가 할당되는 것을 확인했습니다.

외부 시스템과 IP allowlist 기반으로 연동하는 환경에서는 주의가 필요합니다. 현재 VPC 생성 마법사에서는 EIP 옵션이 자동(Automatic)으로 고정되며, 생성 후 수동(Manual)으로 변경할 수 없습니다.

2. 수동(Manual) 모드

고객이 EIP를 직접 할당할 수 있어 고정된 출발지 IP를 제공할 수 있습니다. 외부 연동 환경에 적합합니다.

<그림 4. Regional NATGW EIP Manual 할당>

EIP 관리 측면에서의 차이

Zonal NAT Gateway: 가용 영역별로 EIP를 개별 할당하므로, 외부 연동 시 가용 영역 수만큼 IP를 등록해야 함
Regional NAT Gateway (Manual): 단일 Regional NAT Gateway에 EIP를 할당하면 모든 가용 영역의 트래픽이 해당 EIP 풀을 통해 나가므로, 소수의 고정 IP만 등록하면 됨

AZ 확장 시

Zonal NAT Gateway: 가용 영역 추가 시 NAT Gateway 생성, EIP 추가, 라우팅 수정 필요
Regional NAT Gateway (Manual): 가용 영역 추가 시에도 기존 설정 유지 가능

실제 동작 방식

VPC Wizard를 통한 생성

VPC Wizard에서 Regional을 선택하면 IGW가 자동 생성되고, Private 서브넷용 라우팅 테이블이 자동 구성됩니다. 초기에는 랜덤 가용 영역에 최소 1개의 NAT Gateway가 생성됩니다.

주의할 점

Wizard에서는 EIP 할당 옵션이 Automatic으로 고정됨
리소스 생성 후 Automatic에서 Manual로 변경 불가
수동 EIP가 필요하면 VPC를 먼저 생성한 후 NAT Gateway 콘솔에서 별도로 생성해야 함
VPC 삭제 시 Regional NAT Gateway는 자동 삭제되지 않음

<그림 5. VPC 생성 시 퍼블릭 서브넷 없이 Regional NATGW 생성 가능>

자동 확장/축소 동작

3개의 가용 영역에 private 서브넷이 있는 VPC에서 실제 수회 관찰한 결과

확장

VPC 최초 생성 시 무작위 AZ에 NAT Gateway 1개 생성
다른 AZ에 EC2(ENI) 생성 시 약 3~4분 후 해당 AZ에 NAT Gateway 생성 시작
완전 확장까지 약 15분 정도 소요 (최대 60분 가능)

<그림 6. Regional NATGW 확장 중 EC2 인터넷 통신 가능>

NAT Gateway가 새 AZ로 배포되는 동안에도 EC2는 다른 AZ의 NAT Gateway를 통해 인터넷 통신이 가능합니다. 이때 AZ 간 Data Transfer 비용이 발생할 수 있습니다.

축소

최초 랜덤 생성된 가용 영역의 NAT Gateway는 다른가용 영역의 NAT Gateway 생성 완료 후 약 30분 후 축소 시작
가용 영역에 마지막 ENI 리소스 제거 후 에도 약 30분 정도 후에 Regional NAT Gatway 축소가 시작됨
축소 후 해당 가용 영역에 다시 리소스가 생기면 NAT Gateway가 새로운 EIP와 함께 재 생성됨

<그림 7. Automatic Mode 사용 시 축소 후 재 생성된 NATGW의 EIP 변경>

퍼블릭/Private 혼합 VPC에서의 동작

테스트에서 확인한 중요한 특성

Regional NAT Gateway는 서브넷 타입을 구분하지 않고 가용 영역 단위로 ENI를 인식
퍼블릭 서브넷에 ENI가 생성되어도 해당 가용 영역 으로 NAT Gateway가 확장됨
퍼블릭 리소스는 NAT가 필요 없지만 Regional NAT Gateway 확장을 트리거 하게됨

Private 서브넷의 egress만 관리하려는 의도였더라도, 혼합 서브넷 VPC에서는 퍼블릭 리소스 변화가 NAT 확장/축소에 영향을 줍니다.

Zonal NAT Gateway 모니터링

기존 Zonal NAT Gateway에서는 각 가용 영역 마다 별도의 NAT Gateway 리소스 ID가 생성되어, Amazon CloudWatch에서 각 NAT Gateway를 개별적으로 모니터링했습니다. 예를 들어

nat-0abc123 (ap-northeast-2a)
nat-0def456 (ap-northeast-2b)
nat-0ghi789 (ap-northeast-2c)

각 리소스 ID별로 메트릭(BytesInFromSource, BytesOutToDestination, PacketsInFromSource 등)을 확인하고 알람을 설정했습니다.

Regional NAT Gateway 모니터링

Regional NAT Gateway에서는 단일 리소스 ID가 여러 가용 영역에 걸쳐 사용됩니다. CloudWatch 모니터링 시

리소스 ID는 통합: 하나의 NAT Gateway ID (예: nat-0xyz123)로 표시됨
AZ 차원(Dimension)으로 구분: CloudWatch 메트릭에서 AvailabilityZone 차원을 통해 AZ별 트래픽을 구분

메트릭 조회 방식: 리소스 ID + 가용 영역 조합으로 각 가용 영역의 NAT Gateway 활동을 모니터링

<그림 8. Regional NATGW CloudWatch 가용 영역 별 메트릭>

예를 들어, CloudWatch에서 가용 영역 a의 메트릭을 조회할 때

Namespace: AWS/NATGateway
MetricName: BytesOutToDestination
Dimensions:
  - NatGatewayId: nat-0xyz123
  - AvailabilityZone: ap-northeast-2a

이러한 변화로 인해 기존 Zonal NAT Gateway 기반으로 설정된 CloudWatch 알람이나 대시보드는 Regional NAT Gateway로 전환 시 수정이 필요합니다. 특히 가용 영역별 트래픽 패턴을 모니터링하는 경우, AvailabilityZone 차원을 명시적으로 추가해야 합니다.

가용 영역의 Affinity 및 서로 다른 가용 영역 간트래픽

1. 정상 동작 시

Manual 모드로 모든 가용 영역(a, b, c, d)에 IP를 할당한 상태에서는 각 가용 영역의 instance가 자동으로 같은 가용 영역의 NAT Gateway로 라우팅됩니다. 서로 다른 가용 영역간 데이터 통신 비용이 발생하지 않는 것이 설계 원칙입니다.

단, NATGW 가 확장 중에는 서로 다른 가용 영역간 데이터 통신이 일시적으로 발생하게 됩니다.

2. 특정 가용 영역에서 IP 할당 해제 시

NAT Gateway의 IP를 특정 가용 영역(예: b, d)에서 할당 해제하면, 해당 가용 영역의 instance들은 다른 활성화된 가용 영역의 NAT Gateway를 사용하게 됩니다. 이 경우 서로 다른 가용 영역간 데이터 통신 비용이 발생합니다.

3. 한 가용 영역에 여러 IP 사용 시

한 가용 영역에 여러 개의 IP를 사용해도 NAT Gateway의 기본 비용은 동일합니다. 추가되는 IP 비용만 발생하며, 기존 Zonal NAT Gateway의 Secondary IP 추가와 같은 개념입니다.

Zonal에서 Regional로 전환

기존 NAT Gateway의 EIP를 그대로 사용하면서 Regional NAT Gateway로 무중단 전환하는 것은 제약이 있습니다. NAT Gateway의 Primary EIP는 Disassociate가 불가능하며, NAT Gateway 삭제만이 Primary EIP를 해제할 수 있는 방법이기 때문입니다.

중단 시간을 최소화하는 방법

가용 영역별로 순차 작업: 삭제되는 가용 영역의 NAT Gateway 라우팅을 다른 가용 영역의 Zonal NAT Gateway로 임시 백업 설정 (cross-AZ data transfer 비용 일시적 발생)
기존 Zonal NAT Gateway 삭제 (예: 가용 영역 a)
EIP Disassociate 확인 후 Regional NAT Gateway Manual 리소스로 이동
Regional NAT Gateway 가용 영역 a에 해당 EIP 할당 (Edit IP address associations 메뉴)
서브넷 라우팅을 Regional NAT Gateway로 변경
다른 가용 영역에 대해 반복

이 방법으로 전체 서비스 중단을 최소화하여 가용 영역별로 순차 전환할 수 있습니다.

Regional NAT 적용 시나리오

Private-only VPC + 다중 가용 영역 오토스케일 워크로드

AWS Auto Scaling, Amazon EKS, AWS Batch처럼 가용 영역별 워크로드가 동적으로 변하는 환경에서 가용 영역별 NAT/라우팅 관리를 단순화하고 싶다면 Regional NAT Gateway가 적합할 수 있습니다.

혼합 서브넷 VPC 환경

퍼블릭 ENI가 NAT 확장 트리거가 될 수 있어, 확장/축소가 private workload에만 의해 결정되지 않을 수 있습니다. VPC를 역할 기준으로 분리하거나, 혼합 환경을 유지하되 NAT 확장/축소가 퍼블릭 변화에도 영향을 받는다는 점을 운영 문서에 반영하는 것이 좋습니다.

외부 연동(IP allowlist)이 필수인 환경

Automatic 모드는 축소/재확장 시 IP가 변경될 수 있어 주의가 필요합니다. 이런 환경에서는 Manual 모드 또는 Zonal NAT Gateway 유지를 고려할 수 있습니다.
또한, 2025-11-19 에 출시된 IPAM Allocation Policy 를 사용할 경우 고정된 IPAM 퍼블릭 IP Pool 에서 Automatic Mode Regional NATGW 를 운영하실 수 있습니다. (IPAM Free Tier로 가능)

* BYOIP나 Contiguous IPv4 를 IPAM Pool 로 생성하시어 이를 통해 IPAM Allocation Policy 를 생성한 후 Target Tab 에서 계정을 활성화 하시면 Regional NAT 가 해당 IP Pool 에서 EIP를 할당받아 확장/축소를 하게 되어 해당 Pool 의 CIDR 를 NATGW를 통한 외부통신에 고정적으로 사용할 수 있습니다.

<그림 9. IPAM Allocation Policy + Regional NAT Gateway Automatic 모드 결합 구성으로 고정 CIDR 를 NATGW EIP에 할당 가능>

보안 및 아키텍처 측면

퍼블릭 서브넷 제거로 네트워크 구조 단순화 및 네트워크 격리수준의 직관적 어필 가능
퍼블릭 리소스 오류 구성 위험 감소 및 공격 표면 최소화
Private-by-default 보안 아키텍처 구현 용이
다중 가용 영역 환경에서 일관된 퍼블릭 Ingress 차단 보안 정책 유지 가능

프로덕션 도입 전 체크리스트

IGW 사전 구성 확인
EIP 요구사항 확인 (Automatic vs Manual, IP allowlist 존재 여부)
확장/축소 시간 고려 (최대 60분 소요 가능)
확장 중 서로 다른가용 영역간 트래픽/비용 모니터링 계획
혼합 VPC의 경우 퍼블릭 ENI도 확장 트리거임을 운영 문서에 반영
가역적 전환 계획 (일부 서브넷만 먼저 전환하여 검증)
외부 연동, Flow Logs, 모니터링 검증

마치며

Regional NAT Gateway는 다중 가용 영역 환경에서 NATGW 운영의 복잡도를 줄일 수 있는 옵션입니다. 특히 Private-only VPC 환경에서 구조를 단순화하고 운영 오류 가능성을 줄이는 데 도움이 될 수 있습니다. 다만, Automatic 모드의 IP 변화 가능성, 확장 지연, 혼합 VPC에서의 확장 트리거 등은 환경에 따라 고려해야 할 사항들입니다. 프로덕션 도입 전에는 작은 범위로 라우팅을 전환하여 트래픽, 비용, 연동 요건을 충분히 검증하는 것을 권장합니다.

이 글은 실제 콘솔 테스트를 통해 확인한 동작 방식을 정리한 것이며, 더 자세한 내용은 Amazon VPC NAT Gateway 공식 문서와 Regional NAT Gateway 문서를 참고하세요.

AWS 기술 블로그