“이 두 네트워크를 어떻게 연결하지?”라는 질문의 답은 무엇과 무엇을 잇느냐에 달려 있습니다. Azure의 세 가지 연결 방식을 대상·속도·비용·보안 기준으로 비교하고, 상황별로 무엇을 골라야 하는지 정리했습니다.
- VNet 피어링 : Azure 가상 네트워크끼리 연결. 사설 백본, 빠르고 저지연.
- VPN Gateway : 온프레미스↔Azure를 인터넷 암호화 터널로 연결. 구축 쉬움, 대역폭 제한.
- ExpressRoute : 통신사 회선으로 Microsoft에 사설 직결. 최고 성능·안정성, 비용·기간 큼.
세 방식은 경쟁 상대가 아니라 “무엇을 연결하느냐”와 “얼마나 빠르고 안정적이어야 하느냐”에 따른 선택지입니다. Azure 안끼리인지 Azure 밖과인지가 1차 갈림길이고, 밖과 연결한다면 인터넷을 타도 되는지가 2차 갈림길입니다.
세 방식 한눈에 비교
| 기준 | VNet 피어링 | VPN Gateway | ExpressRoute |
|---|---|---|---|
| 연결 대상 | Azure VNet ↔ VNet | 온프레미스 ↔ Azure | 온프레미스 ↔ Azure |
| 경로 | Azure 사설 백본 | 공용 인터넷(암호화) | 통신사 사설 회선 |
| 대역폭 | 매우 높음 | SKU에 따라 제한 | 회선 등급까지 |
| 지연 | 매우 낮음 | 인터넷 변동에 좌우 | 낮고 안정적 |
| 구축 난이도 | 낮음 | 중간 | 높음(회선 계약) |
| 비용 | 전송량 과금 | 게이트웨이+전송 | 회선+게이트웨이(높음) |
| 적합 상황 | VNet 간 통신 | 중소 규모 하이브리드 | 규제·대용량·저지연 |
각 방식이 맞는 시나리오
VNet 피어링 — 허브-스포크 아키텍처에서 공유 서비스(허브)와 워크로드(스포크)를 잇거나, 리전 간 VNet을 연결(글로벌 피어링)할 때 표준입니다. Azure 백본만 쓰므로 별도 게이트웨이 없이도 빠르고, 설정이 단순합니다.
VPN Gateway — 사무실·데이터센터를 Azure와 연결하는 가장 접근성 높은 방법입니다. 기존 인터넷 회선 위에 IPsec 터널을 얹으므로 초기 비용이 낮고 빠르게 시작할 수 있습니다. 다만 대역폭과 지연이 인터넷 상황에 영향을 받습니다.
ExpressRoute — 금융·의료처럼 트래픽이 공용 인터넷을 타면 안 되거나, 대용량 데이터를 안정적으로 옮겨야 할 때 선택합니다. 지연이 낮고 대역폭이 예측 가능하지만, 통신사 회선 계약이 필요해 구축에 시간과 비용이 듭니다.
선택 기준 체크리스트
- 양쪽 모두 Azure VNet인가? → 그렇다면 VNet 피어링.
- 온프레미스와 연결해야 하나? → VPN Gateway 또는 ExpressRoute.
- 트래픽이 공용 인터넷을 타도 되나? → 되면 VPN, 안 되면 ExpressRoute.
- 대역폭·지연이 업무에 치명적인가? → 그렇다면 ExpressRoute를 검토.
- 빠르게 저비용으로 시작하나? → VPN Gateway로 시작해 필요 시 ExpressRoute로 승격.
Azure 안끼리면 VNet 피어링, 온프레미스와 간단히 잇는다면 VPN Gateway, 인터넷을 피하고 성능이 중요하면 ExpressRoute. 실무에선 VPN으로 시작해 요건이 커지면 ExpressRoute로 넘어가는 흐름이 흔합니다.
구성은 얼마나 다른가 (CLI 비교)
# VNet 피어링 (양방향 각각 생성 필요)
az network vnet peering create \
--resource-group rg-demo --name hub-to-spoke \
--vnet-name vnet-hub --remote-vnet vnet-spoke \
--allow-vnet-access
# VPN Gateway (게이트웨이 서브넷·공용 IP·게이트웨이 필요)
az network vnet-gateway create \
--resource-group rg-demo --name vpngw \
--vnet vnet-hub --gateway-type Vpn --vpn-type RouteBased --sku VpnGw1
# ExpressRoute (회선은 통신사와 계약 후 프로비저닝)
az network express-route create \
--resource-group rg-demo --name er-circuit \
--bandwidth 200 --provider "Equinix" --peering-location "Seoul" --sku-tier Standard
피어링은 명령 한두 줄이면 끝나지만, VPN은 게이트웨이 서브넷과 게이트웨이 배포(수십 분), ExpressRoute는 통신사 계약까지 필요합니다. 구축 난이도가 성능·안정성과 비례합니다.
흔한 실수
- 피어링이 전이된다고 착각한다 — A-B, B-C를 이어도 A와 C는 통신하지 못합니다. 스포크 간 통신은 허브의 게이트웨이·방화벽을 경유시켜야 합니다.
- 피어링을 한쪽만 만든다 — 피어링은 양방향 각각 생성해야 완전히 연결됩니다. 한쪽만 만들면 통신이 끊깁니다.
- 주소 공간이 겹친다 — 연결하려는 네트워크의 IP 대역이 겹치면 피어링·VPN 모두 실패합니다. 설계 단계에서 대역을 분리하세요.
- 게이트웨이 서브넷 이름을 바꾼다 — VPN·ExpressRoute 게이트웨이는 반드시
GatewaySubnet이라는 이름의 서브넷이 필요합니다. - ExpressRoute를 백업 없이 단일 회선으로 쓴다 — 회선 장애에 대비해 VPN을 페일오버 경로로 함께 두는 구성이 권장됩니다.
함께 쓰기도 한다
세 방식은 배타적이지 않습니다. 실무에서는 ExpressRoute를 주 경로로, VPN Gateway를 백업으로 두는 하이브리드 구성이 흔하고, 내부적으로는 여러 스포크 VNet을 허브에 피어링해 공유 게이트웨이를 함께 씁니다. 결국 “무엇을 잇고, 얼마나 안정적이어야 하며, 예산이 얼마인가”를 축으로 조합하면 됩니다.
자주 묻는 질문
- Q. VNet 피어링과 VPN Gateway는 언제 각각 쓰나요?
둘 다 Azure 안에 있고 사설 백본으로 빠르게 이으려면 피어링이 간단합니다. 온프레미스처럼 Azure 밖과 연결해야 하면 인터넷 암호화 터널을 맺는 VPN Gateway가 필요합니다. - Q. ExpressRoute는 왜 인터넷을 거치지 않나요?
통신사 회선으로 Microsoft 네트워크에 사설 직결하기 때문입니다. 공용 인터넷을 타지 않아 지연이 낮고 대역폭이 안정적이며, 규제·대용량 전송에 적합합니다. 대신 회선 비용과 구축 기간이 큽니다. - Q. VNet 피어링은 전이되나요?
기본적으로 전이되지 않습니다. A-B, B-C를 이어도 A와 C는 자동 통신하지 못합니다. 스포크 간 통신은 허브의 게이트웨이·방화벽을 경유시키거나 별도 라우팅을 구성해야 합니다. - Q. 처음 하이브리드를 구성한다면?
비용과 속도 면에서 VPN Gateway로 시작해 검증한 뒤, 성능·규제 요건이 커지면 ExpressRoute로 승격하는 경로가 위험이 적습니다.
정리하면, 연결 대상이 Azure 안인지 밖인지, 인터넷을 타도 되는지, 성능이 얼마나 중요한지 세 질문이면 답이 나옵니다. 대부분의 팀은 피어링과 VPN으로 충분하고, 성능·규제 요건이 임계점을 넘을 때 ExpressRoute를 더합니다.