Hub-Spoke는 Hub VNet에 방화벽과 게이트웨이를 직접 두고 VNet Peering과 UDR로 트래픽 경로를 설계하는 방식입니다. Virtual WAN은 Microsoft가 관리하는 가상 허브가 라우팅과 연결을 대신 맡아 여러 리전, 지점, VPN 사용자를 any-to-any로 이어 줍니다. 리전과 지점이 적고 라우팅을 세밀하게 다뤄야 하면 Hub-Spoke, 리전과 지점이 많고 운영 부담을 줄이고 싶으면 Virtual WAN이 맞습니다.
1. Hub가 필요한 이유
VNet Peering은 두 VNet을 잇는 가장 간단한 방법이지만 전이(transitive)되지 않습니다. Spoke A와 Hub, Hub와 Spoke B를 각각 Peering해도 Spoke A에서 Spoke B로 바로 가지 못합니다. VNet이 늘어날수록 모든 VNet을 서로 Peering하는 풀 메시는 관리가 불가능해집니다.
그래서 방화벽, VPN·ExpressRoute 게이트웨이, DNS 같은 공용 기능을 가운데 Hub 하나에 모으고, 각 워크로드 VNet(Spoke)은 Hub에만 연결하는 구조를 씁니다. 이 Hub를 직접 만든 VNet으로 구성하면 전통적인 Hub-Spoke, Microsoft 관리형 가상 허브로 구성하면 Virtual WAN입니다. 앞서 정리한 Private Endpoint, VPN Gateway, Azure Firewall, Landing Zone의 연결(Connectivity) 구독이 모두 이 Hub 위에 올라갑니다.
2. 전통적인 Hub-Spoke

Spoke 간 트래픽과 인터넷 출구는 UDR로 Hub의 Azure Firewall을 거치고, 온프레미스는 Hub의 게이트웨이를 함께 쓰는 구성
Hub VNet은 일반 VNet이라 AzureFirewallSubnet, GatewaySubnet 같은 서브넷을 직접 만들고 원하는 리소스를 넣습니다. Spoke는 Hub와 Peering하고, Spoke 서브넷의 UDR에서 0.0.0.0/0과 다른 Spoke 대역의 다음 홉을 Azure Firewall 사설 IP로 지정해 Spoke 간 통신을 방화벽으로 꺾습니다. 온프레미스 연결은 Hub 쪽 Peering에서 게이트웨이 전송 허용, Spoke 쪽에서 원격 게이트웨이 사용을 켜서 Hub의 게이트웨이를 함께 씁니다.
장점은 라우팅과 보안을 원하는 만큼 세밀하게 다룰 수 있다는 점입니다. 대신 Spoke가 늘거나 리전이 추가될 때마다 Peering, UDR, 방화벽 규칙을 직접 맞춰야 하고, 리전 간 연결도 Hub끼리 Peering하고 경로를 따로 설계해야 합니다.
3. Virtual WAN

리전마다 가상 허브를 두면 허브끼리 자동으로 풀 메시가 되고, VNet, 지점, VPN 사용자, ExpressRoute가 any-to-any로 연결되는 구성
Virtual WAN은 가상 허브(Virtual Hub)를 리전마다 하나씩 만들고, 그 안에 VPN, ExpressRoute, P2S 게이트웨이와 Azure Firewall을 배포하는 방식입니다. 가상 허브는 Microsoft가 관리하는 VNet이라 서브넷을 직접 만들거나 UDR을 붙일 수 없고, 허브 라우터가 BGP로 경로를 주고받습니다. Standard 형식에서는 같은 Virtual WAN 안의 허브끼리 자동으로 풀 메시가 되어 리전 간, 지점 간, VPN과 ExpressRoute 간 전송이 따로 설계하지 않아도 됩니다.
Azure Firewall을 허브에 넣으면 보안 가상 허브(Secured virtual hub)가 되고, 라우팅 의도(Routing intent)를 켜면 인터넷 트래픽과 사설 트래픽을 허브의 방화벽으로 보내는 정책을 UDR 없이 설정할 수 있습니다.
| 기능 | Basic | Standard |
| Site-to-Site VPN | 가능 | 가능 |
| ExpressRoute | 불가 | 가능 |
| P2S(User VPN) | 불가 | 가능 |
| VNet 간, 허브 간 전송 | 불가 | 가능 |
| Azure Firewall, NVA | 불가 | 가능 |
Basic에서 Standard로 올릴 수는 있지만 반대로 내릴 수는 없습니다. 실무에서는 거의 Standard를 씁니다.
4. 비교
| 비교 항목 | Hub-Spoke | Virtual WAN |
| Hub | 직접 만든 VNet | Microsoft 관리형 가상 허브 |
| Spoke 연결 | VNet Peering | 허브 VNet 연결 |
| Spoke 간 통신 | UDR + 방화벽 또는 NVA 필요 | 허브 라우터가 기본 제공 |
| 리전 간 연결 | Hub 간 Peering, 경로 직접 설계 | 허브 간 자동 풀 메시 |
| VPN ↔ ExpressRoute 전송 | Route Server 등 추가 구성 필요 | 기본 지원 |
| 라우팅 제어 | UDR로 세밀하게 제어 | 라우팅 테이블, 라우팅 의도 |
| Hub에 넣을 수 있는 것 | 제한 없음 (DNS Resolver, Bastion 등) |
게이트웨이, Firewall, 지원 NVA만 |
| 비용 구조 | 리소스별 요금 | 허브 시간당 요금과 데이터 처리 요금 추가 |
가상 허브에는 DNS Private Resolver나 Bastion 같은 리소스를 직접 넣을 수 없습니다. Virtual WAN을 쓸 때는 이런 공용 서비스를 담는 공유 서비스 VNet을 하나 만들어 허브에 연결하는 방식이 일반적입니다.
5. 선택 기준
Microsoft CAF는 아래 기준으로 두 방식을 나눕니다.
| Hub-Spoke가 맞는 경우 | Virtual WAN이 맞는 경우 |
| 리전이 하나이거나 적고, 리전 간 풀 메시가 필요 없음 | 여러 리전에 배포하고 리전과 온프레미스 여러 곳을 전역으로 연결해야 함 |
| 리전당 지점이 적고 IPsec 터널이 30개 미만 | SD-WAN을 쓰거나 지점이 30곳 이상 |
| 네트워크 라우팅 정책을 직접 세밀하게 설정해야 함 | VPN과 ExpressRoute 사이 전이 라우팅이 필요함 |
제 경험으로는 한국 중부 한 리전에 VNet 몇 개와 IDC 한 곳을 붙이는 정도라면 Hub-Spoke가 이해하기 쉽고 비용도 예측하기 쉽습니다. 해외 리전이 추가되거나 전국 지점을 VPN으로 붙여야 하는 시점부터 Virtual WAN을 검토하는 편이 좋습니다.
6. Azure CLI로 만들어 보기
6.1 Hub-Spoke: Peering
RG=rg-hub
# Hub → Spoke: 게이트웨이 전송 허용
az network vnet peering create --resource-group $RG --name hub-to-spoke1 \
--vnet-name vnet-hub --remote-vnet vnet-spoke1 \
--allow-vnet-access --allow-forwarded-traffic --allow-gateway-transit
# Spoke → Hub: 원격 게이트웨이 사용
az network vnet peering create --resource-group $RG --name spoke1-to-hub \
--vnet-name vnet-spoke1 --remote-vnet vnet-hub \
--allow-vnet-access --allow-forwarded-traffic --use-remote-gateways
6.2 Virtual WAN: 허브와 VNet 연결
RG=rg-vwan
az network vwan create --resource-group $RG --name vwan-1nfra \
--location koreacentral --type Standard
# 허브 대역은 생성 후 바꿀 수 없음, /23 이상 권장
az network vhub create --resource-group $RG --name vhub-krc \
--vwan vwan-1nfra --location koreacentral \
--address-prefix 10.100.0.0/23 --sku Standard
az network vhub connection create --resource-group $RG --vhub-name vhub-krc \
--name conn-spoke1 --remote-vnet vnet-spoke1
허브 배포에는 30분 정도 걸립니다. 연결 후 Spoke VM의 유효 경로(Effective routes)에서 허브 대역과 다른 Spoke 대역 경로가 보이면 정상입니다.
7. 운영 시 주의점
| 항목 | 확인할 것 |
| 허브 대역 | 생성 후 바꿀 수 없습니다. 최소 /24, 권장 /23 이상, Azure Firewall을 최대 처리량까지 쓰려면 /22가 필요합니다. |
| 라우팅 인프라 단위 | 기본 2단위는 VNet 간 3 Gbps, VM 2,000대 기준입니다. 트래픽이 많으면 단위를 미리 올립니다(최대 50 Gbps). |
| BGP ASN | 65515, 65517~65520은 Azure 예약 ASN이라 온프레미스에서 쓸 수 없습니다. |
| Spoke의 UDR | 가상 허브에는 UDR을 붙일 수 없습니다. Spoke 서브넷에 UDR을 쓸 때는 게이트웨이 경로 전파를 켜 둡니다. |
| 허브 유지 관리 | 허브 라우터 유지 관리 중 허브 간 트래픽이 잠시 끊길 수 있어 TCP 타임아웃을 여유 있게 둡니다. |
| IPv6 | Virtual WAN 허브와 게이트웨이는 IPv6를 지원하지 않습니다. |
8. 정리
- VNet Peering은 전이되지 않아 Hub가 필요하고, Hub를 직접 만든 VNet으로 두면 Hub-Spoke, 관리형 가상 허브로 두면 Virtual WAN입니다.
- Hub-Spoke는 UDR과 방화벽으로 경로를 세밀하게 제어하고, Virtual WAN은 허브 간 풀 메시와 VPN·ExpressRoute 전송을 기본으로 제공합니다.
- 리전과 지점이 적으면 Hub-Spoke, 여러 리전과 30곳 이상의 지점을 묶어야 하면 Virtual WAN을 권합니다.
참고
'Cloud > Azure' 카테고리의 다른 글
| [Azure] Application Gateway 정리 (0) | 2026.09.25 |
|---|---|
| [Azure] Azure Load Balancer 정리 (0) | 2026.09.25 |
| [Azure] Azure Landing Zone 기본 구조 정리 (0) | 2026.09.24 |
| [Azure] Azure Firewall, NSG, WAF 역할 정리 (0) | 2026.09.24 |
| [Azure] VPN Gateway와 ExpressRoute 비교 (0) | 2026.09.24 |