Azure VNet이란 무엇인가: Subnet, NSG, Route Table 개념 정리

VNet은 Azure 클라우드 안에서 사용자가 논리적으로 격리된 네트워크를 정의하고, 리소스 간 통신 경로를 직접 설계할 수 있게 해주는 핵심 네트워크 서비스입니다.

핵심 요약

• VNet은 Azure 리전 안에서 사용자가 정의하는 가상 네트워크입니다.
• Subnet은 VNet 안에서 리소스를 논리적으로 분리하는 IP 주소 범위입니다.
• NSG(Network Security Group)는 Subnet 또는 NIC 단위로 트래픽을 필터링하는 방화벽 규칙입니다.
• Route Table(UDR)은 트래픽이 어디로 가야 하는지 결정하는 라우팅 규칙입니다.
• 실무에서는 용도별 Subnet을 분리하고, NSG로 트래픽을 제어하는 것이 기본 설계입니다.

1. 왜 VNet이 필요한가

Azure에서 VM, App Service, AKS 같은 리소스를 생성하면, 이 리소스들은 어딘가의 네트워크 안에 존재해야 합니다.

VNet이 없다면 모든 리소스가 같은 네트워크에 섞여 있게 됩니다. 이 경우 다음 문제가 생깁니다.

• 서로 다른 서비스 간 네트워크 격리가 불가능합니다.
• 외부 인터넷에 노출되면 안 되는 리소스를 보호하기 어렵습니다.
• 온프레미스 네트워크와의 연결 시 IP 충돌이 발생할 수 있습니다.

VNet은 이런 문제를 해결하기 위해 사용자가 직접 네트워크 경계를 정의하고, 리소스 간 통신 규칙을 설계할 수 있게 해줍니다.

2. VNet이란 무엇인가

VNet(Virtual Network)은 Azure 리전 안에서 사용자가 정의하는 논리적으로 격리된 가상 네트워크입니다.

핵심 특성:

특성	설명
범위	하나의 Azure 리전에 속합니다
Address Space	생성 시 IP 주소 범위(CIDR 블록)를 하나 이상 지정합니다
격리	다른 VNet과 기본적으로 통신이 차단됩니다
제어	Subnet, NSG, Route Table, Service Endpoint 등으로 트래픽을 제어합니다

VNet을 생성할 때는 Address Space를 지정해야 합니다. 예를 들어 10.0.0.0/16으로 설정하면 약 65,000개의 IP 주소를 사용할 수 있습니다. AWS VPC와 달리 Azure VNet은 여러 개의 Address Space를 추가할 수 있습니다.

# Azure CLI로 VNet 생성
az network vnet create \
  --resource-group myResourceGroup \
  --name myVNet \
  --address-prefix 10.0.0.0/16 \
  --location koreacentral

Tip
Azure VNet은 생성 후에도 Address Space를 추가하거나 변경할 수 있습니다. 다만 이미 Subnet이 할당된 범위를 축소하는 것은 불가능합니다. AWS VPC보다 유연하지만, 온프레미스 연결을 고려해 처음부터 충돌 없는 범위를 설계하는 것이 좋습니다.

AWS VPC와의 주요 차이점

Azure VNet을 처음 접하는 AWS 경험자를 위해 핵심 차이를 정리합니다.

기준	AWS VPC	Azure VNet
Subnet 범위	AZ(가용 영역) 단위	리전 전체 (AZ에 종속되지 않음)
기본 라우팅	Subnet 간 통신에 Route Table 필요	같은 VNet 내 Subnet 간 자동 라우팅
방화벽	Security Group + NACL	NSG (Subnet 또는 NIC 단위)
Address Space 변경	제한적 (Secondary CIDR 추가 가능)	자유롭게 추가/변경 가능
Internet 연결	IGW 연결 + Route Table 설정 필요	기본적으로 아웃바운드 인터넷 가능

3. 핵심 구성 요소

VNet을 구성하는 핵심 요소는 다음과 같습니다.

구성 요소	역할
Subnet	VNet 안에서 리소스를 논리적으로 분리하는 IP 주소 범위
NSG (Network Security Group)	Subnet 또는 NIC 단위의 인바운드/아웃바운드 방화벽
Route Table (UDR)	트래픽의 목적지를 결정하는 사용자 정의 라우팅 규칙
NAT Gateway	Subnet에서 외부 인터넷으로 나가는 아웃바운드 전용 경로
Service Endpoint	VNet에서 Azure PaaS 서비스로의 직접 연결
Private Endpoint	Azure PaaS 서비스를 VNet 내부 IP로 접근

이 글에서는 Subnet, NSG, Route Table을 중심으로 설명합니다. Service Endpoint와 Private Endpoint는 별도 글에서 다룹니다.

4. Subnet

4.1 Subnet이란

Subnet은 VNet의 Address Space를 더 작은 단위로 나눈 것입니다. AWS와 달리 Azure Subnet은 특정 가용 영역(AZ)에 종속되지 않습니다. 하나의 Subnet이 리전 내 모든 AZ에 걸쳐 존재합니다.

예를 들어 VNet이 10.0.0.0/16이라면:

Subnet	CIDR	용도
frontend-subnet	10.0.1.0/24	Application Gateway, Load Balancer
app-subnet	10.0.2.0/24	VM, App Service Environment
db-subnet	10.0.3.0/24	Azure SQL MI, PostgreSQL Flexible
AzureBastionSubnet	10.0.4.0/26	Azure Bastion (이름 고정)
GatewaySubnet	10.0.5.0/27	VPN Gateway, ExpressRoute (이름 고정)

주의
Azure에는 이름이 고정된 특수 Subnet이 있습니다. AzureBastionSubnet, GatewaySubnet, AzureFirewallSubnet 등은 정확한 이름을 사용해야 하며, 각각 최소 CIDR 크기 요구사항이 있습니다.

4.2 Azure Subnet의 특징

AWS와 비교했을 때 Azure Subnet의 가장 큰 차이점은 다음과 같습니다.

1. AZ 독립적: Subnet이 특정 AZ에 종속되지 않으므로, Multi-AZ 구성을 위해 Subnet을 복제할 필요가 없습니다.
2. 예약 IP: 각 Subnet에서 처음 4개와 마지막 1개 IP가 Azure에 의해 예약됩니다. /24 Subnet이면 사용 가능한 IP는 251개입니다.
3. 자동 라우팅: 같은 VNet 내 Subnet 간 통신은 별도 Route Table 설정 없이 자동으로 가능합니다.

# Subnet 생성
az network vnet subnet create \
  --resource-group myResourceGroup \
  --vnet-name myVNet \
  --name app-subnet \
  --address-prefixes 10.0.2.0/24

4.3 Subnet 설계 시 고려사항

• 용도별로 Subnet을 분리하면 NSG 관리가 쉬워집니다.
• Azure 서비스 중 전용 Subnet을 요구하는 것이 있습니다 (예: Azure SQL Managed Instance는 /27 이상 필요).
• CIDR 블록은 향후 확장을 고려해 여유 있게 잡습니다. 가장 작은 Subnet은 /29(8개 IP, 사용 가능 3개)입니다.
• 온프레미스 네트워크와 VPN/ExpressRoute로 연결할 경우 IP 대역 충돌을 피해야 합니다.

5. NSG (Network Security Group)

5.1 NSG란

NSG는 Azure에서 네트워크 트래픽을 필터링하는 방화벽 규칙 모음입니다. Subnet 단위 또는 NIC(네트워크 인터페이스) 단위로 연결할 수 있습니다.

AWS에서는 Security Group(인스턴스 단위)과 NACL(Subnet 단위)이 분리되어 있지만, Azure에서는 NSG 하나로 두 레벨 모두 커버합니다.

5.2 NSG 규칙 구조

각 NSG 규칙은 다음 요소로 구성됩니다.

요소	설명
Priority	100~4096 사이 숫자. 낮을수록 먼저 평가
Source / Destination	IP, CIDR, Service Tag, ASG
Protocol	TCP, UDP, ICMP, Any
Port Range	단일 포트 또는 범위
Action	Allow 또는 Deny
Direction	Inbound 또는 Outbound

5.3 기본 규칙

NSG를 생성하면 기본 규칙이 자동으로 포함됩니다.

인바운드 기본 규칙:

Priority	이름	Source	Destination	Action
65000	AllowVnetInBound	VirtualNetwork	VirtualNetwork	Allow
65001	AllowAzureLoadBalancerInBound	AzureLoadBalancer	Any	Allow
65500	DenyAllInBound	Any	Any	Deny

아웃바운드 기본 규칙:

Priority	이름	Source	Destination	Action
65000	AllowVnetOutBound	VirtualNetwork	VirtualNetwork	Allow
65001	AllowInternetOutBound	Any	Internet	Allow
65500	DenyAllOutBound	Any	Any	Deny

기본적으로 VNet 내부 통신은 허용되고, 아웃바운드 인터넷은 허용되지만, 인바운드 인터넷은 차단됩니다.

Security Note
기본 아웃바운드 규칙(AllowInternetOutBound)은 모든 아웃바운드 트래픽을 허용합니다. 보안이 중요한 환경에서는 이 규칙보다 높은 우선순위로 Deny 규칙을 추가하고, 필요한 목적지만 명시적으로 허용하는 것이 좋습니다.

5.4 Service Tag 활용

Azure NSG의 강력한 기능 중 하나는 Service Tag입니다. IP 주소를 직접 관리하지 않고도 Azure 서비스의 IP 범위를 참조할 수 있습니다.

자주 사용하는 Service Tag:

Service Tag	설명
VirtualNetwork	VNet 내부 + Peered VNet + 온프레미스
AzureLoadBalancer	Azure Load Balancer 헬스 체크
Internet	VNet 외부의 모든 공용 IP
Storage	Azure Storage 서비스 IP 범위
Sql	Azure SQL Database IP 범위
AzureKeyVault	Key Vault 서비스 IP 범위

# NSG 규칙 추가 예시: Storage Service Tag 사용
az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name myNSG \
  --name AllowStorage \
  --priority 200 \
  --direction Outbound \
  --access Allow \
  --protocol Tcp \
  --destination-port-ranges 443 \
  --destination-address-prefixes Storage

5.5 NSG vs AWS Security Group / NACL

기준	Azure NSG	AWS Security Group	AWS NACL
적용 단위	Subnet 또는 NIC	인스턴스 (ENI)	Subnet
상태	Stateful	Stateful	Stateless
Deny 규칙	지원	미지원 (Allow만)	지원
우선순위	숫자 기반 (낮을수록 우선)	모든 규칙 평가	숫자 기반
기본 동작	마지막에 Deny All	마지막에 Deny All	마지막에 Deny All

Azure NSG는 AWS의 Security Group과 NACL의 기능을 하나로 합친 것으로 볼 수 있습니다. Stateful이면서도 Deny 규칙을 지원하므로 더 세밀한 제어가 가능합니다.

6. Route Table (UDR)

6.1 Route Table이란

Azure에서는 VNet 내 Subnet 간 통신, 인터넷 통신 등에 대해 시스템 라우트(System Route)가 자동으로 생성됩니다. 사용자 정의 라우트(UDR, User-Defined Route)는 이 기본 라우팅을 재정의할 때 사용합니다.

azure-vnet-routing

AWS에서는 모든 Subnet에 Route Table을 명시적으로 연결해야 하지만, Azure에서는 시스템 라우트가 기본으로 동작하므로 UDR은 기본 동작을 변경할 때만 필요합니다.

6.2 시스템 라우트 (기본 라우팅)

Azure가 자동으로 생성하는 라우트:

Destination	Next Hop	설명
VNet Address Space	VNet	VNet 내부 통신
0.0.0.0/0	Internet	인터넷 아웃바운드
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16	None	RFC 1918 사설 IP 차단

Tip
Azure는 기본적으로 아웃바운드 인터넷 연결을 제공합니다. AWS처럼 Internet Gateway를 별도로 연결할 필요가 없습니다. 다만 2026년 3월 31일부터 새로 생성되는 VNet에 대해 기본 아웃바운드 액세스(Default Outbound Access)가 폐지됩니다. 이후에는 NAT Gateway, Public IP, 또는 Azure Firewall 등 명시적인 아웃바운드 방법을 구성해야 합니다. 기존 VNet의 리소스는 폐지 이후에도 계속 동작합니다.

6.3 UDR 사용 사례

UDR이 필요한 대표적인 상황:

1. NVA(Network Virtual Appliance) 경유: 모든 트래픽을 방화벽 VM이나 Azure Firewall을 통해 검사
2. 강제 터널링(Forced Tunneling): 인터넷 트래픽을 온프레미스로 보내 기업 방화벽을 통과시킴
3. Subnet 간 트래픽 제어: 특정 Subnet의 트래픽을 Azure Firewall로 라우팅

Route Table 생성:

az network route-table create \
  --resource-group myResourceGroup \
  --name myRouteTable \
  --location koreacentral

사용자 정의 라우트 추가 (NVA 경유):

az network route-table route create \
  --resource-group myResourceGroup \
  --route-table-name myRouteTable \
  --name ToInternet \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.10.4

Subnet에 Route Table 연결:

az network vnet subnet update \
  --resource-group myResourceGroup \
  --vnet-name myVNet \
  --name app-subnet \
  --route-table myRouteTable

6.4 Next Hop 유형

Next Hop Type	설명
VirtualNetworkGateway	VPN Gateway 또는 ExpressRoute로 전달
VnetLocal	VNet 내부 통신
Internet	인터넷으로 직접 전달
VirtualAppliance	NVA(방화벽 VM 등)의 IP로 전달
None	트래픽 차단 (블랙홀)

7. 전체 구조 예시

일반적인 3-Tier 아키텍처에서 Azure VNet 구조는 다음과 같습니다.

azure-vnet-structure

VNet (10.0.0.0/16) - Korea Central
├── frontend-subnet (10.0.1.0/24)
│   └── Application Gateway (WAF v2)
├── app-subnet (10.0.2.0/24)
│   ├── VM Scale Set (Application)
│   └── NAT Gateway (아웃바운드)
├── db-subnet (10.0.3.0/24)
│   └── Azure SQL Managed Instance
├── AzureBastionSubnet (10.0.4.0/26)
│   └── Azure Bastion (관리 접근)
└── GatewaySubnet (10.0.5.0/27)
    └── VPN Gateway (온프레미스 연결)

트래픽 흐름:

1. 사용자 → Application Gateway (frontend-subnet) → VM Scale Set (app-subnet)
2. VM Scale Set → Azure SQL MI (db-subnet) — NSG로 443/1433 포트만 허용
3. VM Scale Set → 외부 API: NAT Gateway → 인터넷
4. 관리자 → Azure Bastion → VM (SSH/RDP, Public IP 불필요)
5. 온프레미스 → VPN Gateway → VNet 내부 리소스

8. 실무 사용 사례

사례 1: 스타트업 웹 서비스 (단일 VNet)

팀원 5명의 스타트업에서 웹 서비스를 운영한다고 가정합니다.

• frontend-subnet: Application Gateway + WAF로 외부 트래픽 수신
• app-subnet: VM Scale Set 또는 App Service Environment에서 애플리케이션 실행
• db-subnet: Azure Database for PostgreSQL Flexible Server

이 구조를 선택한 이유: - Application Gateway의 WAF 기능으로 OWASP Top 10 공격을 필터링할 수 있습니다. - App 계층과 DB 계층을 분리하면 NSG로 DB 접근을 App Subnet에서만 허용할 수 있습니다. - Azure Bastion을 사용하면 VM에 Public IP를 부여하지 않고도 관리 접근이 가능합니다.

사례 2: 엔터프라이즈 Hub-Spoke 구조

대규모 조직에서는 Hub-Spoke 토폴로지를 사용합니다.

• Hub VNet: Azure Firewall, VPN Gateway, 공유 서비스 (DNS, AD)
• Spoke VNet 1: 프로덕션 워크로드
• Spoke VNet 2: 개발/테스트 환경
• Spoke VNet 3: 데이터 분석 워크로드

Hub와 Spoke는 VNet Peering으로 연결하고, 모든 Spoke의 인터넷 트래픽은 Hub의 Azure Firewall을 경유하도록 UDR을 설정합니다. 이렇게 하면 중앙에서 네트워크 정책을 일괄 관리할 수 있습니다.

사례 3: 하이브리드 연결

• GatewaySubnet: ExpressRoute 또는 Site-to-Site VPN으로 온프레미스 연결
• app-subnet: 온프레미스 DB에 접근하는 애플리케이션
• 강제 터널링으로 인터넷 트래픽을 온프레미스 방화벽 경유

9. 보안 고려사항

Security Note
VNet 설계 시 보안은 네트워크 계층에서 시작됩니다. 아래 원칙을 기본으로 적용하는 것이 좋습니다.

• Subnet 분리: 용도별로 Subnet을 나누고, NSG로 Subnet 간 트래픽을 제한합니다.
• Public IP 최소화: Azure Bastion을 사용하면 VM에 Public IP를 부여하지 않아도 됩니다.
• NSG 기본 원칙: 인바운드는 필요한 포트만 허용, 아웃바운드도 필요한 목적지만 허용합니다.
• Service Endpoint / Private Endpoint: Azure PaaS 서비스 접근 시 인터넷을 경유하지 않도록 설정합니다.
• VNet Flow Logs: NSG Flow Logs를 활성화하여 트래픽을 기록하고 이상 패턴을 탐지합니다.
• DDoS Protection: 프로덕션 환경에서는 Azure DDoS Protection Standard를 검토합니다.

Zero Trust 관점에서의 VNet 설계

전통적인 네트워크 보안은 "경계 안은 신뢰"하는 모델이었습니다. Azure에서는 다음과 같이 Zero Trust 원칙을 적용할 수 있습니다.

1. 마이크로 세그멘테이션: Subnet 단위가 아닌 NIC 단위로 NSG를 적용하여 리소스별 접근 제어
2. Private Endpoint: PaaS 서비스도 VNet 내부 IP로만 접근 가능하게 설정
3. Just-In-Time Access: Azure Bastion + JIT VM Access로 관리 포트를 상시 열어두지 않음
4. 네트워크 감사: NSG Flow Logs + Azure Monitor로 모든 통신을 기록

10. 비용/운영 고려사항

주의
VNet 자체는 무료이지만, VNet 안에서 사용하는 일부 리소스는 비용이 발생합니다.

리소스	비용 발생 여부
VNet	무료
Subnet	무료
NSG	무료
Route Table (UDR)	무료
NAT Gateway	시간당 약 $0.045 + GB당 약 $0.045 (리전별 상이)
Public IP (Standard)	시간당 약 $0.005
VNet Peering	GB당 인바운드/아웃바운드 각각 과금 (같은 리전 내 과금, Global Peering은 $0.035/GB, 리전별 상이)
Azure Bastion	Basic SKU 시간당 약 $0.19
VPN Gateway	SKU별 시간당 과금
Azure Firewall	Standard 시간당 약 $1.25 + GB당 과금 (공식 Pricing 페이지에서 최신 가격 확인 권장)

운영 관점:

• VNet Address Space는 변경 가능하지만, 온프레미스 연결이 있는 경우 변경 시 VPN 재설정이 필요할 수 있습니다.
• VNet Peering은 양쪽 VNet 모두에서 설정해야 합니다. 한쪽만 설정하면 통신이 되지 않습니다.
• NSG Flow Logs를 활성화하면 Storage Account 또는 Log Analytics 비용이 발생합니다.
• Hub-Spoke 구조에서 Azure Firewall은 가장 큰 비용 요소가 될 수 있습니다. 소규모 환경에서는 NVA나 NSG만으로 충분할 수 있습니다.

11. 자주 하는 실수

1. Address Space를 온프레미스와 겹치게 설정하는 것: VPN이나 ExpressRoute 연결 시 라우팅 충돌이 발생합니다. 연결 전에 IP 대역 계획을 수립해야 합니다.
2. 모든 리소스에 Public IP를 부여하는 것: Azure Bastion, NAT Gateway, Private Endpoint를 활용하면 대부분의 리소스에 Public IP가 필요 없습니다.
3. NSG 없이 Subnet을 운영하는 것: 기본적으로 VNet 내부 통신이 모두 허용되므로, Subnet 간 접근 제어가 없으면 lateral movement 위험이 있습니다.
4. 특수 Subnet 이름을 잘못 지정하는 것: GatewaySubnet, AzureBastionSubnet, AzureFirewallSubnet은 정확한 이름을 사용해야 합니다. 이름이 다르면 서비스 배포가 실패합니다.
5. VNet Peering을 한쪽만 설정하는 것: Peering은 양방향으로 설정해야 통신이 가능합니다. 한쪽만 설정하면 연결 상태가 "Initiated"로 남습니다.
6. Subnet CIDR을 너무 작게 잡는 것: Azure 서비스 중 많은 IP를 요구하는 것이 있습니다. 예를 들어 AKS는 노드당 30개 이상의 IP를 사용할 수 있습니다.

12. 정리

• VNet은 Azure에서 네트워크를 설계하는 기본 단위이며, 리전 단위로 생성됩니다.
• Subnet은 AZ에 종속되지 않으며, 같은 VNet 내 Subnet 간 통신은 자동으로 라우팅됩니다.
• NSG는 Subnet 또는 NIC 단위로 적용되며, Stateful + Deny 규칙을 지원합니다.
• Route Table(UDR)은 기본 시스템 라우트를 재정의할 때 사용합니다.
• 실무에서는 용도별 Subnet 분리 + NSG + Private Endpoint 조합이 기본 보안 설계입니다.
• Hub-Spoke 구조는 대규모 환경에서 네트워크 정책을 중앙 관리하는 표준 패턴입니다.

참고 문서

• Azure 공식 문서: Virtual Network란 무엇인가
• Azure 공식 문서: Virtual Network FAQ
• Azure 공식 문서: NSG 개요
• Azure 공식 문서: Virtual Network 트래픽 라우팅
• Azure Well-Architected Framework: Virtual Network