지역 간 및 다중 클라우드 연결

이 문서는 여러 지역에 걸쳐 Azure 워크로드를 연결하고 AWS(Amazon Web Services) 및 Google Cloud와 같은 다른 클라우드 공급자에 대한 연결을 확장하는 데 도움이 됩니다.

이 문서에서 다루는 내용

이 문서에서는 지역 간에 Azure VNet(가상 네트워크)을 연결하고 다른 클라우드에서 실행되는 워크로드에 대한 네트워크 경로를 설정하기 위한 디자인 결정에 대해 설명합니다. 지역 간 및 다중 클라우드 시나리오에 전역 VNet 피어링, Virtual WAN, ExpressRoute Global Reach, 사이트 간 VPN 및 Azure Route Server 사용하는 경우를 알아봅니다.

이 문서가 필요한 사람

다음 조건 중 하나 이상이 적용되는 경우 이 문서를 참조하세요.

  • 아키텍처는 여러 Azure 지역에 걸쳐 있으며 지역 간에 프라이빗 연결이 필요합니다.
  • Azure 워크로드를 AWS, Google Cloud 또는 다른 외부 네트워크에 연결해야 합니다.
  • 전역 VNet 피어링, Virtual WAN, ExpressRoute Global Reach, 사이트 간 VPN 또는 Azure Route Server를 비교해야 합니다.
  • 재해 복구, 글로벌 확장 또는 다중 클라우드 작업을 위한 복원력 있는 연결을 설계해야 합니다.

팁 (조언)

시나리오 경로를 따라가시겠습니까? 페이지 맨 위에서 시나리오를 선택하여 맞춤형 지침을 확인합니다. 다음 핵심 지침은 모든 판독기에게 적용됩니다.

리프트 앤 시프트 포커스: 마이그레이션이 여러 Azure 지역에 걸쳐 있거나 다른 클라우드에 연결하는 경우에만 읽기 경로에 이 문서를 포함합니다. 대부분의 리프트 앤 시프트 프로젝트는 단일 지역으로 시작하고 재해 복구 또는 지리적 확장이 우선 순위가 되면 나중에 지역 간 연결을 추가합니다.

현대화 포커스: 현대화에 다중 지역 문서에서 다루는 것 이상으로 명시적 지역 간 프라이빗 연결이 필요한 경우 이 문서를 포함합니다. 서로 다른 지역의 스포크 간에 직접 통신 경로가 필요하거나 활성-활성 배포에 지역 허브 간 프라이빗 피어링이 필요한 경우 이 지침이 필요합니다.

클라우드 간 중점: 이 문서는 핵심 설계 결정을 내리는 기준입니다. 클라우드 간 전송 아키텍처에 대한 허브 및 스포크 간 및 Virtual WAN 중에서 선택하기 전에 읽습니다. 이 문서를 사용하여 기존 다중 클라우드 토폴로지를 검색하고, AWS 또는 Google Cloud와 Azure 간에 서비스를 매핑하고, 마이그레이션 중에 다른 클라우드에 남아 있는 워크로드에 Azure 연결하는 방법을 정의합니다.

Azure 서비스 및 기능

Azure 지역 간 및 다중 클라우드 연결을 위한 여러 서비스를 제공합니다. 각 서비스는 다양한 규모, 대역폭 및 관리 요구 사항을 해결합니다.

서비스 제공하는 내용 사용 시기
전역 VNet 피어링 다른 Azure 지역에 있는 VNet 간의 대기 시간이 짧은 프라이빗 연결입니다. 트래픽은 Microsoft 백본 네트워크를 통해 전송됩니다. 대역폭은 게이트웨이가 아닌 VM(가상 머신) SKU에 의해서만 제한됩니다. 게이트웨이 어플라이언스 없이 서로 다른 지역에 있는 두 VNet 간의 직접 통신
Azure Virtual WAN(표준 계층) 모든 지역에서 VNet, 지사 및 원격 사용자를 연결하는 Microsoft에서 관리하는 글로벌 트랜짓 허브입니다. 연결된 모든 네트워크 간에 전이적 라우팅을 제공합니다. 개별 피어링 연결을 관리하지 않고도 임의의 지점 간 연결이 필요한 여러 리전과 지사를 보유한 조직
클라우드 익스체인지를 통한 ExpressRoute 타사 교환 공급자(예: Equinix 또는 Megaport)를 통한 전용 클라우드 간 연결입니다. AWS 또는 Google Cloud에 대한 프라이빗, 높은 대역폭 연결을 제공합니다. 트래픽이 공용 인터넷을 트래버스해서는 안 되는 대역폭 SLA 요구 사항이 있는 다중 클라우드 아키텍처입니다.
다른 클라우드에 대한 사이트 간 VPN Azure VPN Gateway 다른 클라우드 공급자의 VPN Gateway(AWS Virtual Private Gateway 또는 Google Cloud VPN) 간의 암호화된 IPsec 터널입니다. 전용 회로가 정당화되지 않는 테스트, 개발 또는 프로덕션 시나리오를 위한 다중 클라우드 연결
Azure Route Server VNet과 NVA(네트워크 가상 어플라이언스) 간의 동적 BGP 경로 교환을 사용하도록 설정합니다. NVA 학습 경로를 Azure SDN 라우팅 패브릭에 삽입합니다. 허브 VNet에서 타사 NVA를 사용한 사용자 지정 라우팅 또는 BGP가 Azure 연결된 네트워크에 전파되어야 하는 복잡한 다중 클라우드 라우팅입니다.

글로벌 VNet 피어링 작동 방식

글로벌 VNet 피어링에서는 서로 다른 Azure 지역에 있는 두 가상 네트워크 간에 직접 링크를 만듭니다. 링크는 Microsoft 백본을 통해 완전히 실행되며 공용 인터넷을 통과하지 않습니다. 피어링 관계를 구성한 후 각 VNet의 리소스는 동일한 네트워크에 있는 것처럼 개인 IP 주소를 사용하여 통신할 수 있습니다.

게이트웨이 기반 접근 방식과 달리 피어링에서는 단일 초크 지점을 도입하지 않습니다. 피어링된 VNet 간의 대역폭은 양쪽의 VM SKU에 따라 확장됩니다. 처리량을 제한하는 전용 게이트웨이 어플라이언스는 없습니다. 이 설계를 통해 글로벌 VNet 피어링은 소수의 VNet 간의 지역 간 통신에 가장 낮은 대기 시간 옵션을 제공합니다.

그러나 피어링은 설계상 추이적이지 않습니다. VNet A가 VNet B와 피어링되고 VNet B가 VNet C와 피어되는 경우 VNet A의 트래픽은 VNet B를 통해 VNet C에 연결할 수 없습니다. 직접 통신이 필요한 각 VNet 쌍에는 자체 피어링 링크가 필요합니다. 허브 및 스포크 간 모델에서는 일반적으로 지역 허브 VNet끼리 서로 피어링하고, UDR(사용자 정의 경로) 또는 NVA를 사용하여 지역 간 스포크 간 트래픽이 허브를 통해 전달되도록 라우팅함을 의미합니다.

Virtual WAN 글로벌 전송

Azure Virtual WAN(표준 계층)는 지역 허브 간에 피어링을 수동으로 구성할 필요가 없습니다. 여러 지역에 Virtual WAN 허브를 배포하는 경우 Microsoft 백본을 통해 허브 간 연결을 자동으로 설정합니다. 한 허브에서 학습된 경로는 다른 모든 허브로 전파되어 애니투애니 전송 패브릭을 형성합니다.

이 자동 라우팅은 미국 동부의 허브에 연결된 스포크 VNet이 추가 피어링 또는 경로 테이블 구성 없이 서유럽의 허브에 연결된 스포크 VNet에 연결할 수 있음을 의미합니다. 또한 Virtual WAN 지점(사이트 간 VPN 또는 ExpressRoute를 통해 연결됨) 및 원격 사용자(지점 및 사이트 간 VPN을 통해 연결됨)로 이 전이성을 확장합니다. 그 결과 완전히 메시된 글로벌 Microsoft 관리형 네트워크가 생성됩니다.

지역 간 트래픽 검사를 위해 보안 가상 허브에서 라우팅 의도 를 사용하도록 설정합니다. 라우팅 의도는 허브 간 트래픽이 Azure Firewall을 거치도록 강제하여, 각 허브에 개별 NVA를 배포하고 관리할 필요 없이 모든 지역에서 중앙 집중식 가시성과 정책 적용을 제공합니다.

선택 방법

다음 의사 결정 테이블을 사용하여 시나리오에 적합한 연결 방법을 선택합니다.

지역 간 연결 옵션

전역 VNet 피어링, Virtual WAN 허브 간 전송 및 클라우드 간 VPN 경로를 비롯한 지역 간 연결 패턴을 보여 주는 다이어그램

사용자 시나리오 권장되는 접근 방식 이유
서로 다른 지역의 두 VNet에 직접 통신이 필요합니다. 전역 VNet 피어링 인터넷 경로에 비해 대기 시간이 짧고 게이트웨이 병목 현상이 없으며 구성이 간단합니다. VM SKU를 사용하여 대역폭 크기를 조정합니다.
많은 지역, 많은 지사, 관리형 트랜짓 필요 Azure Virtual WAN(표준 계층) 연결된 모든 허브 간에 전이적 임의 간 라우팅을 제공합니다. Microsoft 라우팅 인프라를 관리합니다.
Azure 통해 온-프레미스 사이트를 서로 연결 ExpressRoute Global Reach 온-프레미스 트래픽이 Microsoft 백본을 트래버스할 수 있도록 두 ExpressRoute 회로를 연결합니다. Azure VNet들을 거쳐 트래픽을 우회시킬 필요가 없습니다.
지역 허브의 사용자 지정 라우팅 또는 타사 NVA Azure Route Server NVA와 Azure 간의 동적 BGP 피어링을 사용하도록 설정합니다. NVA에서 학습한 경로는 스포크 VNet에 자동으로 삽입됩니다.

다중 클라우드 연결 옵션

사용자 시나리오 권장되는 접근 방식 이유
클라우드 간 트래픽에 필요한 높은 대역폭 및 SLA 클라우드 Exchange 공급자를 통한 ExpressRoute 예측 가능한 대기 시간으로 전용 용량을 제공합니다. 교환 공급자는 ExpressRoute 회로를 다른 클라우드의 직접 연결 서비스에 연결합니다.
예산 제한, 테스트 또는 낮은 처리량 워크로드 사이트 간 VPN: 회로 비용 없이 기존 인터넷 연결을 사용합니다. 대역폭 요구 사항이 크지 않을 때 적합합니다.
하이브리드 플러스 다중 클라우드(온-프레미스, Azure 및 다른 클라우드) ExpressRoute Global Reach + 클라우드 Exchange 온-프레미스와 Azure 간 전송을 위한 Global Reach와 Azure와 다른 클라우드 간 연결을 위한 클라우드 교환을 결합하여 통합된 프라이빗 백본을 구축합니다.

디자인 고려 사항

대부분의 리프트 앤 시프트 마이그레이션의 경우 지역 간 연결은 일일 요구 사항 대신 향후 확장 고려 사항입니다. 초기 배포는 단일 Azure 지역을 대상으로 할 가능성이 높습니다.

향후 확장을 계획하는 경우:

  • 전역 VNet 피어링: 두 번째 Azure 지역을 추가할 때 지역 허브 VNet 간에 글로벌 VNet 피어링을 사용합니다. 이 방법은 게이트웨이 어플라이언스를 배포하지 않고 대기 시간이 짧은 프라이빗 연결을 제공합니다. 트래픽은 Microsoft 백본망 내에 유지되며 VM SKU에 따라 확장됩니다.
  • 복잡성 유예: 환경이 두 개 이상의 지역으로 확장되거나 지사 연결 요구 사항이 추가되기 전까지는 Virtual WAN 또는 ExpressRoute Global Reach 배포를 피하세요.
  • DR 준비: 현재 지역 간 연결이 필요하지 않더라도 재해 복구가 필요한 워크로드를 문서화하고 필요할 때 신속하게 배포할 수 있도록 피어링 토폴로지를 미리 계획합니다.

현대화된 아키텍처는 지역 간에 active-active 배포를 사용합니다. 지역 간 피어링을 사용하면 애플리케이션 계층이 지역 경계에 걸쳐 있는 경우 직접 스포크 간 통신이 가능합니다.

현대화를 위한 주요 디자인 결정 사항:

  • active-active를 위한 지역 간 피어링: 주 지역과 백업 지역의 허브 VNet을 피어링하여 양방향 트래픽 흐름이 가능하도록 합니다. ContosoBiz 및 ContosoCare 스포크의 애플리케이션 팀은 허브 피어링 경로를 통해 두 지역의 리소스에 연결할 수 있습니다.
  • 허브를 통한 라우팅: 글로벌 VNet 피어링이 전이적이지 않으므로 지역 허브 NVA 또는 Azure Firewall 통해 지역 간 스포크 트래픽을 라우팅합니다. UDR(사용자 정의 경로)을 사용하여 서로 다른 지역의 스포크 간 트래픽이 검사를 위해 허브 방화벽을 통해 라우팅되도록 합니다.
  • 선택적 피어링: 모든 스포크에 지역 간 연결이 필요한 것은 아닙니다. 허브 VNet끼리만 피어링하고 경로 전파를 사용하여 active-active 워크로드에 참여하는 특정 스포크 VNet에 도달합니다.

이 문서에서는 다중 클라우드 연결 아키텍처를 디자인합니다. Azure 인프라를 계획하기 전에 기존 클라우드 토폴로지와 공급자 간에 서비스를 매핑해야 합니다.

클라우드 간 검색 워크플로

  1. 기존 토폴로지 검색: AWS 및 Google Cloud Network Intelligence Center에서 워크로드 검색을 사용하여 현재 VPC(가상 프라이빗 클라우드) 토폴로지, 피어링 관계 및 트래픽 흐름 패턴을 매핑합니다.
  2. 트래픽 흐름을 식별합니다. AWS 또는 Google 클라우드 환경에서 VPC 간 통신, 인터넷 인바운드 및 아웃바운드 경로 및 분기-클라우드 연결을 문서화합니다.
  3. 서비스를 Azure 동등한 항목에 매핑: 연결 디자인에 대한 키 매핑은 다음과 같습니다.
AWS /Google Cloud 서비스 Azure에 해당
전송 게이트웨이 Azure 가상 WAN
VPC / VPC 네트워크 Azure 가상 네트워크
보안 그룹/방화벽 규칙 NSG(네트워크 보안 그룹)

AWS-Azure 및 Google Cloud-Azure 서비스 매핑에 대한 자세한 내용은 클라우드 간 검색 검사 목록을 참조하세요.

연결 아키텍처 결정

검색 및 서비스 매핑을 완료한 후 다음을 결정합니다.

  • 전송 모델: VPC, 분기, 지역 또는 클라우드 에지가 여러 개 있는 경우 Virtual WAN 선택합니다. Virtual WAN은 관리형 애니투애니 라우팅을 통해 AWS Transit Gateway에 해당하는 Azure 서비스를 제공합니다.
  • 클라우드 간 VPN: Virtual WAN 허브(또는 허브 VNet)에서 AWS Virtual Private Gateway 및 Google Cloud VPN으로 VPN Gateway 연결을 배포합니다. 암호화된 클라우드 간 통신에 IPsec 터널을 사용합니다.
  • 유지되는 애플리케이션: 마이그레이션 중에 AWS 또는 Google Cloud에 남아 있는 워크로드를 식별합니다. 이러한 워크로드는 마이그레이션이 완료될 때까지 클라우드 간 VPN 터널을 통해 지속적인 연결이 필요합니다.

사전 요구 사항

지역 간 또는 다중 클라우드 연결을 구현하기 전에 다음 요구 사항을 확인합니다.

  • VNet이 배포된 두 개 이상의 Azure 지역: 워크로드가 여러 지역에 이미 있거나 계획되어 있어야 합니다. VNet 계획 지침은 VNet 및 서브넷 문서를 참조하세요.
  • 허브-스포크 또는 Virtual WAN 토폴로지: 지역 간 디자인은 각 지역의 설정된 토폴로지에서 빌드됩니다. 허브-스포크 문서 또는 Virtual WAN 문서를 참조하세요.
  • ExpressRoute 회로(Global Reach의 경우): 온-프레미스 사이트를 연결하려는 경우 각 위치에 기존 ExpressRoute 회로가 필요합니다. 하이브리드 연결 문서를 참조하세요.
  • 클라우드 간 계정 액세스: 다중 클라우드 VPN 또는 교환 연결의 경우 연결의 원격 쪽을 구성하려면 다른 클라우드 공급자의 네트워킹 콘솔에 대한 관리 액세스 권한이 필요합니다.

보안 고려 사항

지역 간 및 다중 클라우드 연결은 단일 지역 배포에 존재하지 않는 특정 보안 문제를 소개합니다.

지역 간 트래픽 검사

전역 VNet 피어링이 전이적이지 않습니다. 피어된 VNet 간의 트래픽은 방화벽 또는 검사 지점을 통과하지 않고 직접 흐릅니다. 지역 간 트래픽을 검사해야 하는 경우 NVA(네트워크 가상 어플라이언스) 또는 각 지역 허브의 Azure Firewall 통해 라우팅합니다.

Virtual WAN의 경우 보안 가상 허브에서 프라이빗 트래픽 정책을 적용한 라우팅 의도를 활성화합니다. Routing Intent는 Azure Firewall Manager에서 관리하는 방화벽을 통해 허브 간 트래픽이 전달되도록 강제하며, 이를 통해 중앙 집중식 교차 지역 트래픽 검사를 제공합니다. 이 구성에는 표준 Virtual WAN 계층이 필요합니다.

클라우드 간 연결 암호화

다른 클라우드에 대한 사이트 및 사이트 간의 VPN 터널은 기본적으로 암호화됩니다(IPsec/IKE). 그러나 클라우드 교환을 통한 ExpressRoute 연결은 프라이빗이지만 네트워크 계층에서 암호화되지는 않습니다. ExpressRoute를 통해 암호화가 필요한 경우 ExpressRoute Direct 회로에 MACsec을 배포하거나 애플리케이션 계층 TLS 암호화를 사용합니다.

VPN 오버레이 없이 클라우드 교환을 통과하는 클라우드 간 트래픽의 경우 ExpressRoute 경로 내에 NVA 기반 IPsec 터널을 배포하는 것이 좋습니다. 이 방법은 전용 회로의 대역폭 및 대기 시간 이점을 포기하지 않고 암호화를 추가합니다. 또는 각 서비스 엔드포인트가 ID의 유효성을 검사하고 기본 전송에 관계없이 데이터를 암호화할 수 있도록 애플리케이션 계층에서 mTLS(상호 TLS)를 사용합니다. 선택은 네트워크 계층(모든 트래픽) 암호화가 필요한지 또는 애플리케이션 계층에서 암호화를 적용할 수 있는지에 따라 달라집니다.

비용 고려 사항

모든 지역 간 연결에는 데이터 전송 요금이 발생합니다. 전역 VNet 피어링, Virtual WAN 허브 간 트래픽 및 VPN Gateway 지역 간 터널에는 모두 송신 기준 요금이 적용됩니다. 요금은 영역 쌍에 따라 다릅니다.

  • 동일 대륙 내 (예를 들어, 미국 동부에서 미국 서부까지): GB당 요율이 더 낮으며, 일반적으로 해당 지역의 표준 데이터 송신 요금 범위입니다.
  • 대륙 간 (예: 미국 동부에서 서유럽까지): 긴 백본 거리와 대륙 간 용량으로 인해 GB당 속도가 높습니다.

Virtual WAN 허브에 연결된 각 스포크 VNet 또는 분기에 대한 연결 단위 요금과 Azure Firewall 실행하는 보안 허브를 통해 전송되는 트래픽에 대한 데이터 처리 요금을 추가합니다. 이 계층화된 가격 책정은 Virtual WAN 몇 개의 지역과 스포크만 있는 아키텍처에 대해 간단한 글로벌 VNet 피어링보다 더 많은 비용이 들 수 있지만 수십 개의 지점과 지역이 연결될 때 대규모로 더 나은 단위 경제성을 제공합니다.

다중 클라우드 연결의 경우 클라우드 교환을 통한 ExpressRoute는 교환 공급자의 포트 요금 및 교차 연결 요금과 Azure ExpressRoute 회로 요금 및 다른 클라우드의 직접 연결 요금을 발생합니다. 사이트간 VPN은 회로 비용을 방지하지만 여전히 Azure 나가는 데이터에 대한 표준 송신 요금이 발생합니다.

지침: 가능하면 동일한 지역에서 트래픽이 많은 워크로드를 공동 배치합니다. 일반적으로 트래픽량이 적은 제어 평면 동기화, 비동기 복제 및 재해 복구 장애 조치를 위해 지역 간 경로를 예약합니다.

재해 복구 패턴

지역 간 연결은 DR(재해 복구)의 기초입니다. 선택한 패턴은 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)를 결정합니다.

Active-active

두 지역 모두 프로덕션 트래픽을 동시에 제공합니다. 전역 부하 분산 장치(예: Azure Front Door 또는 Azure Traffic Manager)는 지역 간에 요청을 분산합니다. 한 지역이 실패하면 트래픽은 중단을 최소화하면서 남은 지역으로 이동합니다. 이 패턴은 가장 낮은 RTO(초~분)를 제공하지만 두 지역 모두에서 전체 인프라와 양방향 데이터 동기화가 필요하므로 비용과 복잡성이 증가합니다.

Active-passive

한 지역은 프로덕션 트래픽을 제공하고 두 번째 지역은 미리 배포된(하지만 잠재적으로 축소된) 인프라를 사용하여 대기 상태로 유지됩니다. 복제는 수동 지역의 데이터를 최신 상태로 유지합니다. 실패하면 수동 지역을 승격하고 트래픽을 리디렉션합니다. RTO는 수동 리소스를 확장하고 DNS 또는 부하 분산 장치 장애 조치(failover)를 완료하는 데 걸리는 시간(일반적으로 분에서 수십 분)에 따라 달라집니다.

파일럿 라이트

보조 리전에 데이터베이스 복제가 이루어지고 핵심 네트워킹이 배포되어 있지만 활성 컴퓨트 리소스는 없는 최소 구성입니다. 장애 조치 시 애플리케이션의 컴퓨팅 리소스를 배포하거나 확장 또는 축소하고 트래픽을 전환합니다. 이 패턴은 안정적인 상태 비용을 최소화하지만, 지역이 트래픽을 처리하기 전에 컴퓨팅 리소스를 시작해야 하기 때문에 RTO가 증가합니다.

모든 패턴에서 지역 간 연결(전역 VNet 피어링 또는 허브 간 Virtual WAN)은 복제 트래픽에 대한 프라이빗 데이터 경로를 제공합니다. DR 런북에 경로 전파 지연이 반영되어 있는지 확인하고, 보조 리전의 NSG(네트워크 보안 그룹) 규칙이 장애 조치 트래픽을 허용하는지 검증하세요.

키 제약 조건

제약 조건 영향
전역 VNet 피어링이 전이적이지 않습니다. VNet A가 VNet B에 피어되고 VNet B가 VNet C에 피어로 연결되었다고 해서 A가 C에 도달할 수 있는 것은 아닙니다. A를 C에 직접 피어링하거나 Virtual WAN 같은 전송 솔루션을 사용해야 합니다.
Virtual WAN 기본 계층에 전이성이 없음 기본 Virtual WAN VNet 간 전이적 연결을 지원하지 않습니다. 지역 간 전송에 표준 계층을 사용합니다.
ExpressRoute Global Reach에는 지역 간 연결에 프리미엄 SKU가 필요합니다. 다른 지정학적 지역(예: 미국 및 유럽)의 회로에는 프리미엄 추가 기능이 필요합니다. 표준 SKU 회로는 동일한 지정학적 경계 내에서만 연결됩니다.
AWS용으로 권장되는 액티브-액티브 VPN 게이트웨이 AWS Virtual Private Gateway는 VPN 연결당 두 개의 터널을 만듭니다. 사용 가능한 모든 터널을 사용하고 비대칭 라우팅을 방지하도록 활성-활성 모드에서 Azure VPN Gateway 구성합니다.

자세히 알아보기

다음 단계

팁 (조언)

직접 탐색하시겠습니까? 개요 탐색기로 돌아가서 기능별로 다음 문서를 찾습니다.

리프트 앤 시프트 과정의 다음 단계:

다중 지역 네트워킹: 마이그레이션이 한 지역을 넘어 확장되는 경우 다중 리전 연결 및 장애 조치(failover)를 계획합니다.

현대화 과정의 다음 단계:

네트워크 모니터링 및 관찰 가능성: 프로덕션 준비 상태를 위해 지역 전체에서 관찰 가능성을 사용하도록 설정합니다.

멀티클라우드 여정의 다음 단계:

Virtual WAN 토폴로지: 다중 클라우드 및 멀티브랜치 연결을 위한 전송 허브로 Virtual WAN 사용합니다.