NAT Gateway의 [리전별]과 [영역별]에 대해 알아봤습니다.

안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번 블로그에서는 NAT Gateway의 리전별과 영역별에 대해 알아봤습니다.

리전별 가용성 지원

2025년 11월 19일 NAT Gateway에서 리전별 가용성을 지원하기 시작했습니다.

Amazon Web Services(AWS), NAT 게이트웨이의 리전 가용성 모드 발표 이번 출시를 통해 워크로드 상태를 기반으로 가상 프라이빗 클라우드(VPC)의 가용 영역(AZ) 전체에 걸쳐 자동으로 확장되거나 축소되는 단일 NAT 게이트웨이를 생성하여 높은 가용성을 유지하면서 설치와 관리를 간소화할 수 있습니다.

https://aws.amazon.com/ko/about-aws/whats-new/2025/11/aws-nat-gateway-regional-availability/

이 업데이트를 통해 NAT Gateway 생성 시 가용성 모드 옵션이 추가되었으며, 이제 다음 두 가지 모드 중 하나를 선택할 수 있습니다.

• 리전별 (Regional)
• 영역별 (AZ)

가용성 모드

영역별 모드는 기존부터 사용해오던 방식입니다.

특정 서브넷을 지정하여 해당 서브넷이 속한 단일 가용 영역(AZ)에 NAT Gateway를 생성하는 방식입니다.

즉, NAT Gateway는 특정 AZ에 종속되며, 다른 AZ에서 사용하려면 별도의 NAT Gateway를 생성해야 합니다.

특징을 정리하면:

• AZ 단위 리소스
• 서브넷 기반으로 생성
• 멀티 AZ 구성 시 직접 NAT Gateway를 여러 개 생성해야 함

리전별 모드

리전별 모드는 이번 업데이트로 새롭게 추가된 방식입니다.

기존처럼 특정 서브넷에 종속되지 않고, 하나의 NAT Gateway가 리전 전체에 걸쳐 동작하는 것이 가장 큰 특징입니다.

즉, 여러 가용 영역(AZ)에 분산된 워크로드가 하나의 NAT Gateway를 공통으로 사용할 수 있습니다.

특징을 정리하면:

• 리전 단위 리소스
• 특정 AZ에 종속되지 않음
• 단일 NAT Gateway로 멀티 AZ 지원
• AWS가 자동으로 AZ 간 확장 및 장애 대응 처리

두 모드를 비교하면 다음과 같습니다.

일단 NAT Gateway를 생성해 보자

NAT Gatewayㄹ르 생성할 때 가용성 모드가 추가된 것을 확인할 수 있으며 여기서 리전별과 영역별을 선택할 수 있습니다. 리전별은 NAT Gateway는 Private Subnet에 생성할 수 없기 때문에 Private Subnet에 NAT Gateway를 생성하는 환경이라면 무조건 영역별을 선택해야 합니다.

이어서 EIP를 자동 할당할 것인지 수동 할당할 것인지 선택할 수 있습니다.

자동은 AWS가 퍼블릭 IP를 자동으로 할당하고 관리합니다. AWS가 EIP를 완전 관리하는 형태로 사용자가 직접 EIP를 지정할 수 없으며, 확장과 축소에 따라 사용되는 퍼블릭 IP가 변경될 수 있습니다.

외부 시스템과 연동하는 환경에서는 주의가 필요하며, NAT Gateway 생성 후 수동으로 변경할 수 없습니다.

마지막으로 수동은 고객이 EIP를 직접 할당할 수 있으며, 외부 연동 환경에 적합합니다.

NAT Gateway를 생성하면, 자동으로 IP가 할당되며, 초기에는 랜덤 가용 영역에 최소 1개의 NAT Gateway가 생성됩니다.

이어서 라우팅 테이블에 NAT Gateway를 추가합니다.

이어서 EC2 인스턴스에 접속해서 해당 NAT Gateway를 사용해서 인터넷과 통신하고 있는지 확인해 보면 해당 가용 영역에 할당된 EIP 주소가 출력될 것입니다.

sh-5.2$ curl checkip.amazonaws.com

NAT Gateway IP # NAT Gateway의 IP 주소가 출력

다음은 다른 가용 영역에 EC2 인스턴스를 생성합니다.

약 5분 정도의 시간이 지나자 자동으로 EC2 인스턴스와 동일한 가용 영역에 NAT Gateway가 생성되는 것을 확인할 수 있었습니다.

※ NAT Gateway가 새 가용 영역으로 배포되는 동안에도 EC2 인스턴스는 다른 가용 영역의 NAT Gateway를 통해 인터넷 통신을 할 수 있습니다. 이때 가용 영역 간 데이터 전송 비용이 발생할 수 있습니다.

NAT Gateway가 완전하 생성된 다음, IP 주소를 확인해 보면, EC2 인스턴스가 있는 가용 영역의 NAT Gateway IP 주소가 출력될 것입니다.

sh-5.2$ curl checkip.amazonaws.com

NAT Gateway IP # EC2 인스턴스가 있는 가용 영역의 NAT Gateway IP 주소가 출력

이제 NAT Gateway가 확장하는 것을 확인했으니, 축소되는 것을 확인해 봅시다. 특정 가용 영역에 있는 EC2 인스턴스를 삭제하고 약 30분 정도 기다리면 해당 가용 영역의 NAT Gateway가 삭제되는 것을 확인할 수 있습니다.

마무리

이번 업데이트를 통해 NAT Gateway는 단순히 프라이빗 서브넷에서 인터넷으로 나가기 위한 구성 요소를 넘어, 고가용성과 운영 복잡도를 AWS가 얼마나 대신 가져갈 수 있는지를 보여주는 방향으로 진화했습니다.

기존의 영역별(AZ) 모드는 비교적 명확한 구조를 가지고 있지만, 그만큼 사용자가 직접 신경 써야 할 부분도 많았습니다.
멀티 AZ 환경을 구성하려면 AZ마다 NAT Gateway를 생성해야 하고, 각각의 프라이빗 서브넷에 맞는 라우팅 테이블을 구성해야 하며, 장애 상황까지 고려해 아키텍처를 설계해야 했습니다. 즉, 고가용성을 얻기 위해서는 그에 상응하는 운영 부담을 감수해야 하는 구조였습니다.

반면, 이번에 추가된 리전별(Regional) 모드는 이러한 복잡도를 상당 부분 추상화합니다.
단일 NAT Gateway만 생성하면, 이후의 확장과 축소, 그리고 AZ 간 장애 대응은 AWS가 자동으로 처리합니다. 실습에서 확인했듯이 새로운 가용 영역에 워크로드가 생성되면 NAT Gateway가 자동으로 확장되고, 더 이상 사용되지 않으면 다시 축소되는 동작은 기존 방식에서는 직접 구현하기 어려운 부분이었습니다.

이러한 변화는 특히 다음과 같은 상황에서 큰 장점을 가집니다:

• 멀티 AZ 아키텍처를 기본으로 사용하는 환경
• 인프라를 빠르게 구성해야 하는 스타트업 또는 초기 단계 서비스
• 네트워크 구성보다 애플리케이션 개발에 집중하고 싶은 경우
• 운영 리소스를 최소화하고 싶은 팀

하지만 리전별 모드가 항상 최적의 선택은 아닙니다. 가장 중요한 고려 사항은 비용과 트래픽 흐름입니다.

리전별 NAT Gateway는 내부적으로 AZ 간 트래픽을 발생시킬 수 있으며, 이 경우 인터 AZ 데이터 전송 비용이 추가로 발생합니다. 실습에서도 확인했듯이, 특정 AZ에 NAT Gateway가 아직 생성되지 않은 상태에서는 다른 AZ의 NAT Gateway를 통해 통신하게 되고, 이 과정에서 비용이 발생할 수 있습니다.

또한, 특정 AZ 단위로 트래픽을 완전히 분리하거나, 네트워크 흐름을 정밀하게 제어해야 하는 환경에서는 여전히 영역별 모드가 더 적합할 수 있습니다.

예를 들어 금융 서비스나 규제 환경에서는 트래픽 경로의 명확성과 통제 가능성이 더 중요할 수 있습니다.

결국 이 기능의 핵심은 무조건 더 좋은 옵션이 아니라,
아키텍처 설계 시 선택할 수 있는 옵션이 하나 더 생겼다는 점에 있습니다.

정리해보면 다음과 같습니다:

• 리전별 모드 → 단순함, 자동화, 빠른 구성, 낮은 운영 부담
• 영역별 모드 → 정밀한 제어, 비용 최적화 가능, 명확한 트래픽 경로

이번 NAT Gateway의 변화는 단순한 기능 추가를 넘어,
고가용성을 직접 구현할 것인가, 아니면 AWS에 위임할 것인가라는 선택지를 확장해준 업데이트라고 볼 수 있습니다.