Azure NAT Gateway란?
Azure NAT Gateway는 완전히 관리되고 복원력이 뛰어난 NAT(Network Address Translation) 서비스입니다. Azure NAT Gateway를 사용하면 프라이빗 서브넷의 모든 인스턴스가 완전히 비공개로 유지하면서 인터넷에 아웃바운드로 연결할 수 있습니다. 인터넷에서의 원치 않는 인바운드 연결은 NAT 게이트웨이를 통해 허용되지 않습니다. 아웃바운드 연결에 대한 응답 패킷으로 도착하는 패킷만 NAT 게이트웨이를 통과할 수 있습니다.
NAT Gateway는 동적 SNAT 포트 기능을 제공하여 아웃바운드 연결을 자동으로 스케일링하고 SNAT 포트 소모 위험을 줄입니다.
그림: Azure NAT Gateway
Azure NAT Gateway는 다음을 비롯한 많은 Azure 리소스에 대한 아웃바운드 연결을 제공합니다.
프라이빗 서브넷의 Azure 가상 머신 또는 가상 머신 스케일링 집합.
가상 네트워크 통합을 통한 Azure App Services 인스턴스(웹 애플리케이션, REST API, 모바일 백엔드).
Azure Databricks 또는 가상 네트워크 삽입 사용.
Azure NAT Gateway 혜택
간단한 설정
NAT 게이트웨이를 사용하여 의도적으로 배포를 간단하게 만들었습니다. NAT 게이트웨이를 서브넷 및 공용 IP 주소에 연결하고 바로 인터넷으로 아웃바운드 연결을 시작하면 됩니다. 유지 관리와 라우팅 구성이 전혀 필요하지 않습니다. 나중에 기존 구성에 영향을 주지 않고 더 많은 공용 IP 또는 서브넷을 추가할 수 있습니다.
다음 단계는 NAT 게이트웨이를 설정하는 방법의 예입니다.
비영역 또는 영역 NAT 게이트웨이를 만듭니다.
공용 IP 주소 또는 공용 IP 접두사를 할당합니다.
NAT 게이트웨이를 사용하도록 가상 네트워크 서브넷을 구성합니다.
필요한 경우 TCP(Transmission Control Protocol) 유휴 시간 제한을 수정합니다(선택 사항). 기본값을 변경하기 전에 타이머를 검토합니다.
보안
NAT Gateway는 제로 트러스트 네트워크 보안 모델을 기반으로 구축되었으며 기본적으로 안전합니다. NAT 게이트웨이를 사용하면 서브넷 내의 프라이빗 인스턴스는 인터넷에 연결하기 위해 공용 IP 주소가 필요하지 않습니다. 프라이빗 리소스는 NAT 게이트웨이의 고정 공용 IP 주소 또는 접두사로의 SNAT(원본 네트워크 주소 변환)를 통해 가상 네트워크 외부의 외부 원본에 연결할 수 있습니다. 공용 IP 접두사를 사용하여 아웃바운드 연결에 대한 연속 IP 집합을 제공할 수 있습니다. 이 예측 가능한 IP 목록을 기반으로 대상 방화벽 규칙을 구성할 수 있습니다.
복원력
Azure NAT Gateway는 완전히 관리되고 분산된 서비스입니다. VM 또는 단일 물리적 게이트웨이 디바이스와 같은 개별 컴퓨팅 인스턴스에 의존하지 않습니다. NAT 게이트웨이는 항상 여러 장애 도메인을 포함하고 있으므로 여러 오류를 서비스 중단 없이 유지할 수 있습니다. 소프트웨어 정의 네트워킹은 NAT 게이트웨이의 복원력을 높입니다.
확장성
NAT 게이트웨이는 생성 시 스케일 아웃됩니다. 램프 업 또는 스케일 아웃 작업은 필요하지 않습니다. Azure는 사용자를 대신하여 NAT 게이트웨이 작업을 관리합니다.
서브넷에 NAT 게이트웨이를 연결하면 해당 서브넷의 모든 프라이빗 리소스에 아웃바운드 연결을 제공할 수 있습니다. 가상 네트워크의 모든 서브넷은 동일한 NAT 게이트웨이 리소스를 사용할 수 있습니다. 아웃바운드 연결은 최대 16개의 공용 IP 주소 또는 /28 크기 공용 IP 접두사를 NAT 게이트웨이에 할당하여 스케일링할 수 있습니다. NAT 게이트웨이가 공용 IP 접두사에 연결되면 아웃바운드에 필요한 IP 주소 수로 자동 확장됩니다.
성능
Azure NAT Gateway는 소프트웨어 정의 네트워킹 서비스입니다. 각 NAT 게이트웨이는 아웃바운드 및 반환 트래픽 모두에 대해 최대 50Gbps의 데이터를 처리할 수 있습니다.
NAT 게이트웨이는 컴퓨팅 리소스의 네트워크 대역폭에 영향을 주지 않습니다. NAT Gateway의 성능에 대해 자세히 알아봅니다.
Azure NAT Gateway 기본 사항
아웃바운드 연결
NAT 게이트웨이는 아웃바운드 연결에 권장되는 방법입니다.
- 기본 아웃바운드 액세스 또는 부하 분산 장치 아웃바운드 규칙에서 NAT 게이트웨이에 대한 아웃바운드 액세스를 마이그레이션하려면 Azure NAT Gateway로 아웃바운드 액세스 마이그레이션을 참조하세요.
참고 항목
2025년 9월 30일에 새로운 배포에 대한 기본 아웃바운드 액세스가 사용 중지됩니다. 대신 NAT 게이트웨이와 같은 명시적 형식의 아웃바운드 연결을 사용하는 것이 좋습니다.
송신은 NAT 게이트웨이를 사용하여 서브넷 수준별로 정의됩니다. NAT 게이트웨이가 서브넷의 기본 인터넷 대상을 대체합니다.
트래픽 라우팅 구성 없이 NAT 게이트웨이를 사용할 수 있습니다.
NAT 게이트웨이를 사용하면 가상 네트워크에서 가상 네트워크 외부의 서비스로 흐름을 만들 수 있습니다. 인터넷에서 반환하는 트래픽은 활성 흐름에 대한 응답으로만 허용됩니다. 가상 네트워크 외부의 서비스는 NAT Gateway를 통해 인바운드 연결을 시작할 수 없습니다.
NAT 게이트웨이는 부하 분산 장치, 인스턴스 수준 공용 IP 주소, Azure Firewall을 비롯한 다른 아웃바운드 연결 방법보다 우선합니다.
다른 아웃바운드 연결 방법이 이미 있는 가상 네트워크에 NAT 게이트웨이를 구성하는 경우 이후 모든 아웃바운드 트래픽은 NAT 게이트웨이가 처리합니다. Azure Load Balancer의 기존 연결에 대한 트래픽 흐름은 감소하지 않습니다. 모든 새 연결은 NAT 게이트웨이를 사용합니다.
NAT 게이트웨이에는 기본 아웃바운드 액세스 및 부하 분산 장치의 아웃바운드 규칙과 동일한 SNAT 포트 고갈 제한 사항이 없습니다.
NAT 게이트웨이는 TCP 및 UDP(사용자 데이터그램 프로토콜) 프로토콜만 지원합니다. ICMP(Internet Control Message Protocol)는 지원되지 않습니다.
트래픽 경로
서브넷에는 대상 0.0.0.0/0이 있는 트래픽을 인터넷에 자동으로 라우팅하는 시스템 기본 경로가 있습니다. NAT 게이트웨이가 서브넷에 구성되면 서브넷에 있는 가상 머신에서 인터넷으로의 통신은 NAT 게이트웨이의 공용 IP를 사용하여 우선 순위가 지정됩니다.
0.0.0.0/0 트래픽에 대한 서브넷 경로 테이블에 UDR(사용자 정의 경로)을 만들 때 이 트래픽의 기본 인터넷 경로가 재정의됩니다. 0.0.0.0/0 트래픽을 가상 어플라이언스 또는 가상 네트워크 게이트웨이(VPN Gateway 및 ExpressRoute)에 다음 홉 유형으로 보내는 UDR은 대신 NAT 게이트웨이 연결을 인터넷으로 재정의합니다.
아웃바운드 연결은 다양한 라우팅 및 아웃바운드 연결 방법 중에서 이 우선 순위 순서를 따릅니다.
- 다음 홉에 대한 UDR 가상 어플라이언스 또는 가상 네트워크 게이트웨이 >> NAT Gateway >> 가상 머신의 인스턴스 수준 공용 IP 주소 >> 부하 분산 어플라이언스 아웃바운드 규칙 >> 기본 시스템이 인터넷으로 라우팅됩니다.
NAT 게이트웨이 구성
동일한 가상 네트워크 내의 여러 서브넷은 다른 NAT 게이트웨이 또는 동일한 NAT 게이트웨이를 사용할 수 있습니다.
여러 NAT 게이트웨이를 단일 서브넷에 연결할 수 없습니다.
NAT 게이트웨이는 여러 가상 네트워크에 걸쳐 있을 수 없습니다.
NAT 게이트웨이는 게이트웨이 서브넷에 배포할 수 없습니다.
NAT 게이트웨이 리소스는 다음과 같은 유형의 조합으로 최대 16개의 IP 주소를 사용할 수 있습니다.
공용 IP 주소.
공용 IP 접두사.
사용자 지정 IP 접두사(BYOIP)에서 파생된 공용 IP 주소 및 접두사에 대해 자세히 알아보려면 사용자 지정 IP 주소 접두사(BYOIP)를 참조하세요.
NAT 게이트웨이는 IPv6 공용 IP 주소 또는 IPv6 공용 IP 접두사에 연결할 수 없습니다.
NAT 게이트웨이는 아웃바운드 규칙을 사용하여 부하 분산 장치와 함께 사용하여 이중 스택 아웃바운드 연결을 제공할 수 있습니다. NAT Gateway 및 공용 부하 분산 장치를 사용하여 이중 스택 아웃바운드 연결을 참조하세요.
NAT 게이트웨이는 가상 머신 네트워크 인터페이스 또는 IP 구성을 통해 작동합니다. NAT 게이트웨이는 네트워크 인터페이스에서 여러 IP 구성을 SNAT할 수 있습니다.
NAT 게이트웨이는 허브 가상 네트워크의 Azure Firewall 서브넷에 연결하고 허브에 피어링된 스포크 가상 네트워크에서 아웃바운드 연결을 제공할 수 있습니다. 자세한 내용은 NAT 게이트웨이와의 Azure Firewall 통합을 참조하세요.
가용성 영역
NAT 게이트웨이는 특정 가용성 영역에서 만들거나 영역 없음일 수 있습니다.
NAT 게이트웨이는 영역 격리 시나리오를 만들 때 특정 영역에서 격리될 수 있습니다. 이 배포를 영역 배포라고 합니다. NAT 게이트웨이를 배포한 후에는 영역 선택을 변경할 수 없습니다.
NAT 게이트웨이는 기본적으로 영역 없음이 됩니다. 영역 없음 NAT 게이트웨이는 Azure에서 사용자에게 적합한 영역에 배치됩니다.
NAT 게이트웨이 및 기본 리소스
NAT 게이트웨이는 표준 공용 IP 주소 또는 공용 IP 접두사 리소스 또는 이 둘의 조합과 호환됩니다.
기본 부하 분산 장치 또는 기본 공용 IP와 같은 기본 리소스는 NAT 게이트웨이와 호환되지 않습니다. NAT 게이트웨이는 기본 리소스가 있는 서브넷에서 사용할 수 없습니다. NAT 게이트웨이를 사용하기 위해 기본 부하 분산 장치 및 기본 공용 IP를 표준으로 업그레이드할 수 있습니다.
기본 부하 분산 장치를 표준으로 업그레이드하려면 퍼블릭 기본 Azure Load Balancer 업그레이드를 참조하세요.
공용 IP를 기본에서 표준으로 업그레이드하려면 공용 IP 주소 업그레이드를 참조하세요.
가상 머신에 연결된 기본 공용 IP를 기본에서 표준으로 업그레이드하는 방법에 대한 자세한 내용은 가상 머신에 연결된 기본 공용 IP 업그레이드를 참조하세요.
연결 시간 제한 및 타이머
NAT 게이트웨이는 기존 연결로 인식되지 않는 연결 흐름에 대해 TCP 재설정(RST) 패킷을 보냅니다. NAT 게이트웨이 유휴 시간 제한에 도달했거나 이전에 연결을 닫은 경우 연결 흐름이 더 이상 존재하지 않을 수 있습니다.
존재하지 않는 연결 흐름의 트래픽 보낸 사람이 NAT 게이트웨이 TCP RST 패킷을 받으면 더 이상 연결을 사용할 수 없습니다.
연결이 닫히면 SNAT 포트를 동일한 대상 엔드포인트에 곧 다시 사용할 수 없습니다. NAT 게이트웨이에서 SNAT 포트를 정지(cool down) 상태로 전환해야 동일한 대상 엔드포인트에 연결하는 데 다시 사용할 수 있습니다.
TCP 트래픽에 대한 SNAT 포트 재사용(정지) 타이머 기간은 연결을 닫는 방법에 따라 달라집니다. 자세한 내용은 포트 재사용 타이머를 참조하세요.
사용되는 기본 TCP 유휴 시간 제한은 4분이며 최대 120분까지 늘릴 수 있습니다. 또한 흐름의 모든 활동에서 TCP keepalive를 포함하여 유휴 타이머를 다시 설정할 수도 있습니다. 자세한 내용은 유휴 시간 제한 타이머를 참조하세요.
UDP 트래픽에는 변경할 수 없는 4분의 유휴 시간 제한 타이머가 있습니다.
UDP 트래픽에는 65초의 포트 재사용 타이머가 있으며, 이 타이머는 포트가 동일한 대상 엔드포인트에서 재사용될 수 있기 전에 보류됩니다.
가격 책정 및 SLA(서비스 수준 계약)
Azure NAT Gateway 가격 책정은 NAT 게이트웨이 가격 책정을 참조하세요.
SLA에 대한 자세한 내용은 Azure NAT Gateway용 SLA를 참조하세요.
다음 단계
NAT 게이트웨이를 만들고 유효성을 검사하는 방법에 대한 자세한 내용은 빠른 시작: Azure Portal을 사용하여 NAT 게이트웨이 만들기를 참조하세요.
Azure NAT Gateway에 대한 자세한 내용에 대한 비디오를 보려면 Azure NAT 게이트웨이를 사용하여 아웃바운드 연결을 개선하는 방법을 참조하세요.
NAT 게이트웨이 리소스에 대한 자세한 내용은 NAT 게이트웨이 리소스를 참조하세요.
다음 모듈에서 Azure NAT Gateway에 대해 자세히 알아봅니다.
Azure NAT Gateway의 아키텍처 옵션에 대한 자세한 내용은 Azure NAT 게이트웨이의 Azure Well-Architected Framework 검토를 참조하세요.