AZ-700 시험에서 VNet·서브넷·NAT Gateway 파트는 '이 시나리오에서 어떤 설계 결정을 내려야 하는가'를 묻습니다. CIDR 주소 공간이 겹치면 VNet Peering이 불가능하고, Reserved IP를 잘못 계산하면 서브넷이 예상보다 작아집니다. 대규모 아웃바운드에서 SNAT 포트가 부족해지는 상황을 NAT Gateway가 어떻게 해결하는지도 핵심 출제 포인트입니다.
VNet의 경계: 리전과 격리 단위
새 사무실을 열 때 건물 전체의 배선 구조를 먼저 설계하듯, Azure에서 무언가를 배포하기 전에 Virtual Network(VNet)를 먼저 만들어야 합니다. VNet은 단일 Azure 리전 안에서만 존재하고, 같은 VNet에 속한 리소스끼리는 별도 설정 없이도 통신할 수 있습니다.
리전 경계를 넘는 통신은 VNet Peering, VPN Gateway, ExpressRoute를 통해야 합니다. VNet 이름은 리소스 그룹 내에서만 고유하면 됩니다. Peering이 연결된 VNet은 리소스 그룹 이동이 불가능하므로, 이동이 필요하면 먼저 Peering을 제거해야 합니다.
VNet은 주소 공간(Address Space)을 여러 CIDR 블록으로 지정할 수 있습니다. 나중에 추가는 가능하지만 Peering이 걸린 상태에서 겹치는 CIDR 추가는 거부됩니다. 설계 초기에 충분한 여유 공간을 확보하는 것이 중요합니다.
서브넷 분할과 Reserved IP
층마다 다른 부서를 배치하는 사무용 빌딩처럼, VNet 안의 서브넷은 트래픽 분리와 정책 적용 단위가 됩니다. Azure는 각 서브넷의 첫 4개 IP와 마지막 1개 IP를 예약(Reserved)합니다. /27 서브넷(32개 주소)이라면 실제 사용 가능한 IP는 27개입니다.
서브넷 크기 선택 시 Reserved IP를 반드시 계산에 넣어야 합니다. 15대의 VM을 배치할 계획이라면 /27(27개 가용)으로 충분하지만, /26(59개 가용)을 선택하는 것이 현명합니다.
특정 Azure 서비스는 전용 서브넷을 요구합니다.
: Azure Firewall 전용, 최소 /26 권장 : VPN Gateway·ExpressRoute Gateway 전용 : Azure Bastion 전용, 최소 /26 필수
Subnet Delegation을 사용하면 특정 Azure PaaS 서비스(Azure Container Instances, App Service 등)가 해당 서브넷에 직접 NIC를 삽입할 수 있습니다. 하나의 서브넷에는 하나의 Delegation만 적용 가능합니다.
Public IP SKU: Basic과 Standard의 차이
회사 대표 전화번호가 항상 같아야 신뢰를 주듯, 클라우드 워크로드에서도 예측 가능한 공용 IP가 필요한 경우가 있습니다. Azure Public IP는 Basic과 Standard 두 가지 SKU로 나뉩니다.
Basic SKU는 Static 또는 Dynamic 할당을 지원하고 인바운드가 기본 열려 있습니다. Standard SKU는 Static 할당만 지원하고, NSG를 명시하지 않으면 인바운드가 기본 거부입니다. Zone-Redundant 및 Zonal 배포는 Standard SKU만 지원하며, Basic/Standard SKU는 각각 동일 등급의 Load Balancer에만 연결 가능합니다.
Standard Public IP는 기본값이 Zone-Redundant로 가용성 영역 장애 시에도 동일 IP를 유지합니다. 특정 Zone에만 고정하려면 Zonal로 명시해야 합니다. Basic SKU는 2025년 9월 30일에 폐기 예정입니다.
IPv6와 Dual-Stack도 AZ-700 범위입니다. VNet에 IPv4와 IPv6 주소 공간을 동시에 지정하면 Dual-Stack이 가능하며, Peering 시 양쪽 VNet 모두 IPv6 주소 공간이 있어야 IPv6 트래픽이 통합됩니다.
!Public IP SKU: Basic vs Standard
NAT Gateway: 아웃바운드 SNAT 풀 확장
공장 우편실에서 수십 명의 직원이 편지를 보낼 때 회사 대표 주소를 공용으로 쓰는 것처럼, 여러 VM이 인터넷으로 나갈 때 공인 IP 하나를 공유하면 SNAT 포트가 부족해지는 문제가 생깁니다.
NAT Gateway는 이 문제를 해결합니다. 최대 16개의 Public IP 또는 Public IP Prefix를 붙일 수 있고, IP당 64,512개의 SNAT 포트를 제공합니다. 16개 IP를 모두 사용하면 약 100만 개의 동시 아웃바운드 연결을 지원합니다.
NAT Gateway는 서브넷 단위로 연결합니다. 해당 서브넷의 모든 아웃바운드 트래픽이 NAT Gateway를 통과하며, 인바운드 연결은 처리하지 않습니다.
아웃바운드 방식 선택: NAT Gateway vs Load Balancer Outbound Rules vs 인스턴스 Public IP
식당에서 손님이 직접 주방에 돈을 내는 경우, 계산대를 거치는 경우, 카드 단말기 회사가 중간에서 처리하는 경우처럼 — 아웃바운드 방식도 세 가지 경로가 있습니다.
세 방식의 차이는 다음과 같습니다.
NAT Gateway: IP당 64,512 포트, 아웃바운드 전용, 서브넷 단위 적용, 동적 포트 할당으로 고갈 거의 없음 Load Balancer Outbound Rules: IP당 최대 64,512 포트를 백엔드 VM에 사전 배분, VM 수 증가 시 VM당 포트 감소 인스턴스 Public IP: VM NIC에 직접 연결, VM 독립적으로 64,512 포트, 인바운드와 아웃바운드 모두 처리
NAT Gateway가 연결된 서브넷에서는 Load Balancer Outbound Rules보다 NAT Gateway가 우선합니다.
IP 겹침 방지와 Peering 설계 함정
같은 주소를 쓰는 두 팀이 편지를 주고받을 수 없듯, CIDR이 겹치는 두 VNet은 Peering할 수 없습니다. 이것이 주소 공간 설계에서 가장 흔한 실수입니다.
온프레미스 네트워크(예: 10.0.0.0/8)와 Azure VNet이 겹치면 ExpressRoute나 VPN을 통한 하이브리드 연결이 불가능합니다. VNet을 만들기 전에 전사 IP 주소 관리(IPAM) 체계와 맞춰보는 것이 필수입니다.
Peering은 비전이(non-transitive)입니다. VNet A가 VNet B와, VNet B가 VNet C와 Peering되어 있어도 A↔C 통신은 자동으로 열리지 않습니다. A↔C를 직접 Peering하거나, 허브 VNet에서 'Allow Gateway Transit'과 'Use Remote Gateways' 옵션을 설정해야 합니다.
IPv6 Dual-Stack을 Peering 환경에서 쓸 때는 양쪽 VNet 모두 IPv6 CIDR이 있어야 합니다.
실무 시나리오: 서브넷 계획 실수와 아웃바운드 고갈
한 팀이 30대의 VM을 /27 서브넷 하나에 배치하려 했습니다. /27에서 Reserved IP 5개를 빼면 27개가 가용한데 VM이 30대이므로 3대는 IP를 받지 못합니다. /26(59개 가용)으로 서브넷을 처음부터 다시 만들어야 합니다.
수백 대의 VM이 단일 공인 IP를 통해 인터넷에 연결하는 구조에서 Load Balancer Outbound Rules를 쓰고 있었는데 SNAT 포트 고갈이 발생했습니다. NAT Gateway를 서브넷에 연결하면 포트를 동적으로 할당하기 때문에 고갈이 사실상 발생하지 않습니다.
시나리오 문제에서 'SNAT exhaustion', '아웃바운드 포트 부족', '대규모 VM 아웃바운드' 키워드가 나오면 NAT Gateway가 정답입니다.
시험 핵심 정리
"Reserved IP가 5개 → 실제 가용 주소 계산" -- 서브넷 크기에서 5를 빼서 계산 (/27 = 32 - 5 = 27개) "특정 Azure 서비스를 위한 전용 서브넷 이름" -- GatewaySubnet / AzureBastionSubnet / AzureFirewallSubnet "서비스가 서브넷에 NIC를 직접 삽입하려면" -- Subnet Delegation "아웃바운드 SNAT 포트 고갈 방지" -- NAT Gateway "NAT Gateway IP당 제공 SNAT 포트" -- 64,512개, 최대 16 IP 연결 가능 "아웃바운드 전용, 인바운드 불처리" -- NAT Gateway "LB Outbound Rules와 NAT Gateway가 동일 서브넷에 있으면" -- NAT Gateway 우선 "Standard Public IP 기본 보안 동작" -- 인바운드 기본 거부, NSG 명시 필요 "Zone-Redundant Public IP를 지원하는 SKU" -- Standard SKU만 지원 "CIDR 겹침이 생기면" -- VNet Peering 불가, 먼저 주소 공간 재설계 필요 "Peering 비전이성 해결 방법" -- 직접 Peering 추가 또는 허브에서 Gateway Transit 설정 "Dual-Stack Peering 조건" -- 양쪽 VNet 모두 IPv6 주소 공간 보유
VNet = 리전 단위 격리 경계, NAT Gateway = 대규모 아웃바운드 SNAT 풀, Subnet Delegation = PaaS NIC 삽입 허용