디자인 1단계: 온-프레미스 사이트를 사용한 커넥트성
온-프레미스 데이터 센터를 사용하는 커넥트성은 Azure VMware Solution 네트워킹에 가장 중요한 디자인 영역입니다. 해결해야 하는 주요 요구 사항은 다음과 같습니다.
- 높은 처리량: 온-프레미스 vSphere 환경 및 재해 복구 솔루션에서 마이그레이션하려면 온-프레미스 사이트와 Azure VMware Solution 프라이빗 클라우드 간에 대량의 데이터를 신속하게 이동해야 합니다.
- 짧은 대기 시간: 분산 애플리케이션은 Azure VMware Solution 가상 머신과 온-프레미스 시스템 간의 연결에 짧은 대기 시간이 필요할 수 있습니다.
- 성능 예측 가능성: 예측 가능한 처리량 및 대기 시간을 달성하기 위해 Azure VMware Solution에 배포된 중요 비즈니스용 애플리케이션에는 온-프레미스 사이트와 Microsoft 네트워크 간에 전용 연결 서비스(Azure ExpressRoute)가 필요할 수 있습니다.
이 문서에서는 온-프레미스 사이트와의 연결을 위해 Azure VMware Solution에서 지원하는 옵션을 설명합니다.
옵션은 이전에 나열된 주요 요구 사항을 충족하는 기능을 줄이는 순서대로 표시됩니다. 옵션은 dis카드ed여야 하며, 다음 옵션은 특정 시나리오의 협상할 수 없는 제약 조건과 충돌하는 경우에만 고려해야 합니다.
이 순서도는 Azure VMware Solution에 대한 하이브리드 연결 옵션을 선택하는 프로세스를 요약합니다.
ExpressRoute Global Reach
ExpressRoute Global Reach는 Azure VMware Solution에서 지원하는 기본 하이브리드 연결 옵션입니다. Azure VMware Solution 프라이빗 클라우드와 고객 관리 ExpressRoute 회로에 연결된 원격 사이트 간의 계층 3 연결은 복잡성을 최소화합니다. 고객 관리 ExpressRoute 회로를 사용하여 Azure 네이티브 서비스에 연결할 수도 있습니다. 보안을 개선하거나 대역폭을 예약하기 위해 Azure VMware Solution 트래픽 전용으로 별도의 고객 관리 회로를 배포할 수도 있습니다.
다음 다이어그램에서는 온-프레미스 사이트와의 연결에 Global Reach를 사용하는 네트워크 토폴로지를 보여 줍니다. Azure VMware Solution 프라이빗 클라우드와 온-프레미스 사이트 간의 트래픽은 Azure 가상 네트워크를 트래버스하지 않습니다.
참고 항목
최대 복원력을 위해 서로 다른 피어링 위치에 있는 두 개의 고객 관리 ExpressRoute 회로를 사용하여 온-프레미스 데이터 센터를 Microsoft 백본에 연결해야 합니다. 이 경우 각 고객 관리 ExpressRoute 회로는 Azure VMware Solution 프라이빗 클라우드(및 Azure Virtual Networks)에 대한 Global Reach 연결이 있어야 합니다. 복원력 있는 ExpressRoute 구현에 대한 지침은 이 문서를 검토하세요.
Global Reach를 사용하여 Azure VMware Solution 프라이빗 클라우드를 고객 관리 ExpressRoute 회로에 연결하는 방법에 대한 지침은 Azure VMware Solution에 온-프레미스 환경 피어를 참조하세요.
Global Reach 연결은 다음 세 가지 주요 요구 사항을 완벽하게 해결합니다.
- 높은 처리량: ExpressRoute를 사용하면 전용 회선을 통해 온-프레미스에서 Microsoft 네트워크에 연결할 수 있습니다(공급자 기반 ExpressRoute의 경우 최대 10Gbps, ExpressRoute Direct의 경우 100Gbps).
- 짧은 대기 시간: Global Reach를 사용하면 Microsoft 네트워크의 가장자리에서 Azure VMware Solution vSphere 클러스터로 트래픽을 직접 라우팅할 수 있습니다. Global Reach는 온-프레미스 사이트와 프라이빗 클라우드 간의 네트워크 홉 수를 최소화합니다.
- 예측 가능한 성능: ExpressRoute Global Reach를 사용하는 경우 정체 문제가 경험하지 않는 링크를 통해 트래픽이 라우팅됩니다(최대 프로비전된 용량까지). 따라서 Azure VMware Solution에서 실행되는 가상 머신과 온-프레미스 호스트 간의 RTT(왕복 시간)는 시간이 지남에 따라 일정하게 기본.
다음 제약 조건 중 하나 이상이 적용되는 시나리오에서는 Global Reach를 사용할 수 없습니다.
ExpressRoute Global Reach는 Azure VMware Solution 프라이빗 클라우드의 Azure 지역 또는 고객 관리 ExpressRoute 회로의 meet-me 위치에서 사용할 수 없습니다. 이 제한에 대한 해결 방법이 없습니다. Global Reach 가용성에 대한 최신 정보는 ExpressRoute Global Reach 정보를 참조하세요.
협상할 수 없는 네트워크 보안 요구 사항이 있습니다. 방화벽 디바이스를 고객 관리 ExpressRoute 회로의 온-프레미스 쪽에 배포할 수 없는 경우 Global Reach를 사용하면 관리 네트워크(vCenter Server 및 NSX-T 관리)를 비롯한 모든 Azure VMware Solution 네트워크 세그먼트가 회로에 연결된 전체 네트워크에 노출됩니다. 이 문제가 발생하는 가장 일반적인 시나리오는 MPLS 네트워크 서비스(ExpressRoute 모든 연결 모델이라고도 함)를 기반으로 고객 관리 ExpressRoute 회로를 구현하는 경우입니다. 이 시나리오는 다음과 같습니다.
MPLS IPVPN을 기반으로 ExpressRoute 연결을 구현하는 경우 단일 위치에 방화벽을 배포하여 Azure VMware Solution을 오가는 모든 트래픽을 검사하는 것은 불가능합니다. 일반적으로 MPLS 네트워크를 사용하는 조직은 모든 사이트(소규모 지점, 사무실 또는 저장소일 수 있는)가 아닌 대규모 데이터 센터에 방화벽을 배포합니다.
IPSec VPN
Azure의 전송 가상 네트워크를 통해 트래픽을 라우팅하여 Azure VMware Solution 프라이빗 클라우드와 온-프레미스 사이트 간의 연결을 구현할 수 있습니다. 전송 네트워크는 관리되는 ExpressRoute 회로를 통해 Azure VMware Solution 프라이빗 클라우드에 연결됩니다. 전송 가상 네트워크는 다음과 같이 IPSec VPN을 통해 온-프레미스 사이트에 연결됩니다.
VPN 디바이스가 방화벽 기능을 제공하지 않는 경우 방화벽을 통해 트래픽을 라우팅하여 온-프레미스 사이트와 Azure VMware Solution 프라이빗 클라우드(다이어그램의 파선) 간의 연결에 대한 보안 정책을 적용할 수 있습니다. 이 구성에는 이 문서의 Azure에서 가상 디바이스를 호스트할 위치 결정 섹션에서 설명한 대로 라우팅 의도가 있는 Azure Virtual WAN이 필요합니다.
온-프레미스 사이트와 전송 가상 네트워크 간에 IPSec 연결을 구현하기 전에 다음 세 가지 디자인 결정을 내려야 합니다.
- IPSec 터널의 언더레이로 사용할 네트워크 서비스를 결정합니다. 사용 가능한 옵션은 인터넷 연결, ExpressRoute Microsoft 피어링 및 ExpressRoute 프라이빗 피어링입니다.
- Azure 쪽에서 IPSec 터널을 종료하는 가상 디바이스를 호스트할 위치를 결정합니다. 사용 가능한 옵션에는 고객 관리형 가상 네트워크 및 Virtual WAN 허브가 포함됩니다.
- Azure 쪽에서 IPSec 터널을 종료하는 가상 디바이스를 결정합니다. 또한 디바이스 선택은 IPSec 터널과 Azure VMware Solution 관리 회로 간의 트래픽 라우팅에 필요한 Azure 구성을 결정합니다. 사용 가능한 옵션은 네이티브 Azure VPN Gateway 및 타사 IPSec NVA(네트워크 가상 어플라이언스)입니다.
이 순서도는 의사 결정 프로세스를 요약합니다.
이러한 결정을 내리기 위한 기준은 다음 섹션에 설명되어 있습니다.
언더레이 네트워크 서비스 선택
여기에 제시된 순서대로 VPN 언더레이에 대한 세 가지 옵션을 고려하는 것이 좋습니다.
인터넷 연결. 전송 가상 네트워크에서 호스트되는 VPN 디바이스에 할당된 공용 IP 주소는 IPSec 터널의 원격 엔드포인트 역할을 합니다. 복잡성과 비용이 낮기 때문에 항상 성능(달성 가능한 IPSec 처리량)에 대한 인터넷 연결을 테스트하고 평가해야 합니다. 관찰된 성능이 너무 낮거나 일관성이 없는 경우에만 이 옵션을 해제해야 합니다. 다음 다이어그램에서는 이 옵션을 보여 줍니다.
ExpressRoute Microsoft 피어링. 이 옵션은 전용 링크를 통해 Azure 퍼블릭 엔드포인트에 계층 3 연결을 제공합니다. 인터넷 연결과 마찬가지로 IPSec 터널의 원격 엔드포인트 역할을 하고 전송 가상 네트워크에서 호스트되는 VPN 디바이스의 공용 IP에 연결할 수 있습니다. Microsoft 피어링의 라우팅 요구 사항을 충족할 수 없는 경우에만 이 옵션을 해제해야 합니다. 다음 다이어그램에서는 이 옵션을 보여 줍니다.
ExpressRoute 개인 피어링. 이 옵션은 전용 링크를 통해 온-프레미스 사이트와 Azure 가상 네트워크 간에 계층 3 연결을 제공합니다. 따라서 온-프레미스 사이트에서 가상 네트워크에 호스트되는 VPN 디바이스의 개인 IP 주소로 IPSec 터널을 설정할 수 있습니다. ExpressRoute 게이트웨이가 데이터 경로에 있으므로 ExpressRoute 프라이빗 피어링에 대역폭 제한이 발생할 수 있습니다. ExpressRoute FastPath를 사용하여 이 문제를 해결할 수 있습니다. 또한 프라이빗 피어링에는 온-프레미스 쪽에서 더 복잡한 라우팅 구성이 필요합니다. 자세한 내용은 ExpressRoute 개인 피어링을 통해 사이트 및 사이트 간의 VPN 연결 구성을 참조하세요. 다음 다이어그램에서는 이 옵션을 보여 줍니다.
Azure에서 가상 디바이스를 호스트할 위치 결정
사용 가능한 옵션에는 고객 관리형 가상 네트워크 및 Virtual WAN 허브가 포함됩니다. 이 결정을 내리려면 기존 Azure 환경의 특성(있는 경우)과 관리 노력 감소와 특정 요구 사항에 맞게 구성을 조정하는 기능의 우선 순위를 지정하는 방법을 고려합니다. 다음은 몇 가지 주요 고려 사항입니다.
- Azure VMware Solution 연결에 기존 Azure 네트워크 인프라를 사용해야 합니다. 고객 관리형 허브-스포크 네트워크가 Azure VMware Solution 프라이빗 클라우드와 동일한 지역에 이미 있는 경우 기존 허브에 IPSec 종료 디바이스를 배포해야 합니다. Virtual WAN을 기반으로 하는 허브-스포크 네트워크가 Azure VMware Solution 프라이빗 클라우드와 동일한 지역에 있는 경우 IPSec 종료에 Virtual WAN 허브를 사용해야 합니다.
- 고객 관리형 허브-스포크 네트워크에서 IPSec 터널과 ExpressRoute 관리 회로 간에 트래픽을 라우팅하려면 허브 가상 네트워크에 Azure Route Server 인스턴스를 배포하고 분기 간 트래픽을 허용하도록 구성해야 합니다. 가상 네트워크에 배포된 방화벽 디바이스를 통해 Azure VMware Solution 프라이빗 클라우드와 온-프레미스 사이트 간에 트래픽을 라우팅할 수 없습니다.
- Virtual WAN 허브는 기본적으로 온-프레미스 사이트에 연결된 IPSec 터널과 Azure VMware Solution 관리 ExpressRoute 회로 간의 라우팅 트래픽을 지원합니다.
- Virtual WAN을 사용하는 경우 트래픽 검사를 위해 라우팅 의도 및 라우팅 정책을 구성할 수 있습니다. Virtual WAN에서 지원하는 Azure Firewall 또는 타사 보안 솔루션을 사용할 수 있습니다. 라우팅 의도의 지역 가용성 및 제한 사항을 검토하는 것이 좋습니다.
IPSec 터널을 종료하는 가상 디바이스 결정
온-프레미스 사이트에 대한 연결을 제공하는 IPSec 터널은 Azure VPN Gateway 또는 타사 NVA에 의해 종료될 수 있습니다. 이 결정을 내리려면 기존 Azure 환경의 특성(있는 경우)과 관리 노력 감소와 특정 요구 사항에 맞게 구성을 조정하는 기능의 우선 순위를 지정하는 방법을 고려합니다. 다음은 몇 가지 주요 고려 사항입니다.
Virtual WAN을 기반으로 하는 고객 관리형 및 허브-스포크 네트워크인 허브-스포크 네트워크 모두에서 Azure VPN Gateway를 사용하여 온-프레미스 사이트에 연결된 IPSec 터널을 종료할 수 있습니다. 플랫폼 관리형이므로 Azure VPN Gateway에는 최소한의 관리 작업이 필요합니다. 다른 연결 시나리오를 지원하는 경우에도 기존 게이트웨이를 사용할 수 있습니다. 지원되는 설정 및 예상 성능에 대한 정보는 다음 문서를 검토해야 합니다.
타사 NVA는 일반적으로 다음과 같은 상황에서 온-프레미스 사이트에서 터널을 종료하는 데 사용됩니다.
- NVA는 Azure 및 온-프레미스 사이트에 모두 배포되는 SDWAN 솔루션의 CPE(고객 프레미스 장비)입니다.
- NVA는 온-프레미스 사이트와 Azure VMware Solution 간의 연결에 필요한 보안 정책을 적용하는 방화벽입니다.
타사 디바이스를 사용하면 네이티브 VPN 게이트웨이에서 지원하지 않는 고급 네트워크 기능에 더 많은 유연성과 액세스 권한을 제공할 수 있지만 복잡성이 증가합니다. 고가용성이 사용자의 책임이 됩니다. 여러 인스턴스를 배포해야 합니다.
ExpressRoute 프라이빗 피어링을 통해 전송
ExpressRoute 프라이빗 피어링은 엔터프라이즈 시나리오에서 온-프레미스 사이트를 Azure 가상 네트워크(또는 허브-스포크 네트워크)에 연결하는 데 가장 일반적인 선택입니다. Azure 가상 네트워크 또는 허브-스포크 토폴로지의 허브 가상 네트워크에는 ExpressRoute 회로에 대한 연결로 구성된 ExpressRoute 게이트웨이가 포함되어 있습니다. 이 구성은 가상 네트워크(또는 전체 허브-스포크 네트워크)와 온-프레미스 사이트의 네트워크 간에 계층 3 연결을 제공합니다. 그러나 관리되는 ExpressRoute 회로를 통해 동일한 가상 네트워크(또는 허브 가상 네트워크)에 연결된 Azure VMware Solution 프라이빗 클라우드에 계층 3 연결을 기본적으로 제공하지는 않습니다. (참조) ExpressRoute Global Reach 및 Azure VMware Solution 프라이빗 클라우드.)
Azure 가상 네트워크에 더 많은 라우팅 디바이스를 배포하여 이 제한을 해결할 수 있습니다. 이렇게 하면 가상 네트워크에서 호스트되는 방화벽 NVA를 통해 트래픽을 라우팅할 수 있습니다.
ExpressRoute 개인 피어링을 통해 전송하는 것이 바람직해 보일 수 있지만 복잡성을 더하고 성능에 영향을 줍니다. ExpressRoute Global Reach 및 IPSec VPN(이전 섹션에서 설명)을 적용할 수 없는 경우에만 고려해야 합니다.
다음 두 가지 구현 옵션이 있습니다.
- 단일 가상 네트워크. 이 옵션을 사용하면 고객 관리형 및 Azure VMware Solution 관리 회로가 동일한 ExpressRoute 게이트웨이에 연결됩니다.
- 보조 전송 가상 네트워크. 이 옵션을 사용하면 온-프레미스 사이트에 대한 연결을 제공하는 고객 관리 ExpressRoute 회로가 허브 가상 네트워크의 (일반적으로 기존) ExpressRoute 게이트웨이에 연결됩니다. Azure VMware Solution 관리 회로는 보조 전송 가상 네트워크에 배포된 다른 ExpressRoute 게이트웨이에 연결됩니다.
다음 섹션에서는 다음을 비롯한 두 가지 구현 옵션에 대한 세부 정보를 제공합니다.
- 성능, 비용(필요한 Azure 리소스) 및 관리 오버헤드 간의 절충
- 컨트롤 플레인 구현(온-프레미스 사이트와 프라이빗 클라우드 간에 경로를 교환하는 방법).
- 데이터 평면 구현(네트워크 패킷이 온-프레미스 사이트와 프라이빗 클라우드 간에 라우팅되는 방법).
단일 가상 네트워크
단일 가상 네트워크 접근 방식을 사용하는 경우 Azure VMware Solution 프라이빗 클라우드의 관리 회로와 고객 소유 회로는 모두 동일한 ExpressRoute 게이트웨이(일반적으로 허브 네트워크)에 연결됩니다. 프라이빗 클라우드와 온-프레미스 사이트 간의 트래픽은 허브 네트워크에 배포된 방화벽 NVA를 통해 라우팅될 수 있습니다. 단일 가상 네트워크 아키텍처는 다음과 같습니다.
컨트롤 플레인 및 데이터 평면은 여기에 설명된 대로 구현됩니다.
컨트롤 플레인입니다. Azure 가상 네트워크에 배포된 ExpressRoute 게이트웨이는 Azure VMware Solution 관리 회로와 고객 관리 ExpressRoute 회로 간에 경로를 전파할 수 없습니다. 분기 간 설정을 사용하도록 설정된 Azure Route Server는 두 회로 모두에서 Azure VMware Solution 프라이빗 클라우드의 주소 공간(관리 네트워크 및 워크로드 세그먼트) 및 온-프레미스 주소 공간을 포함하는 슈퍼넷에 대한 경로를 삽입하는 데 사용됩니다.
정확한 접두사는 이미 Azure VMware Solution 프라이빗 클라우드 및 온-프레미스 사이트에 의해 반대 방향으로 발표되어 있으므로 이러한 주소 공간을 구성하는 정확한 접두사 대신 슈퍼넷을 발표해야 합니다. 온-프레미스 사이트의 네트워크 구성과 호환되는 경우 RFC 1918 접두사만큼 큰 슈퍼넷을 사용할 수 있습니다. 대부분의 경우 Azure VMware Solution 프라이빗 클라우드의 주소 공간 및 온-프레미스 주소 공간을 포함하는 가장 작은 슈퍼넷을 대신 사용해야 합니다. 이렇게 하면 온-프레미스 사이트의 라우팅 구성과 충돌할 위험이 최소화됩니다.
슈퍼넷에 대한 경로는 BGP 지원 NVA에서 시작됩니다. NVA는 Azure Route Server를 사용하여 BPG 세션을 설정하도록 구성됩니다. NVA는 컨트롤 플레인의 일부일 뿐이며 온-프레미스 사이트와 Azure VMware Solution 프라이빗 클라우드 간에 실제 트래픽을 라우팅하지 않습니다. 컨트롤 플레인 구현은 이전 그림의 파선으로 표시됩니다.
데이터 평면. 앞에서 설명한 컨트롤 플레인 구현은 ExpressRoute 게이트웨이에 다음 트래픽을 끌어들입니다.
- Azure VMware Solution 프라이빗 클라우드로 향하는 온-프레미스 사이트의 트래픽입니다.
- 온-프레미스 사이트로 향하는 Azure VMware Solution 프라이빗 클라우드의 트래픽입니다.
GatewaySubnet에 UDR이 적용되지 않으면 트래픽은 온-프레미스 사이트와 Azure VMware Solution 프라이빗 클라우드 간에 직접 흐릅니다. GatewaySubnet에 UDR을 적용하여 트래픽을 중간 다음 홉으로 라우팅할 수 있습니다. 온-프레미스 사이트와 프라이빗 클라우드 간의 연결에 네트워크 보안 정책을 적용하는 방화벽 NVA가 일반적인 예입니다. 데이터 평면 구현은 이전 그림의 실선으로 표시됩니다.
보조 가상 네트워크
보조 가상 네트워크를 사용하여 Azure VMware Solution 프라이빗 클라우드의 관리 회로에만 연결된 두 번째 ExpressRoute 게이트웨이를 호스트할 수 있습니다. 이 방법을 사용하는 경우 프라이빗 클라우드의 관리 회로와 고객 관리 회로가 다른 ExpressRoute 게이트웨이에 연결됩니다. 두 개의 Azure Route Server 인스턴스는 각 회로에 대한 적절한 경로를 알리고 프라이빗 클라우드와 온-프레미스 사이트 간의 경로 전파를 제어하는 데 사용됩니다. 이전 섹션에서 설명한 단일 가상 네트워크 옵션과 마찬가지로 슈퍼넷을 발표할 필요가 없습니다. GatewaySubnet의 UDR에 대한 관리 오버헤드도 줄어듭니다. 이 방법을 사용하면 허브 가상 네트워크의 방화벽 NVA를 통해 프라이빗 클라우드와 온-프레미스 사이트 간에 트래픽을 라우팅할 수 있습니다. 보조 가상 네트워크 구현은 다음 다이어그램에 나와 있습니다.
컨트롤 플레인 및 데이터 평면은 여기에 설명된 대로 구현됩니다.
컨트롤 플레인입니다. Azure VMware Solution 프라이빗 클라우드의 관리 회로와 고객 소유 회로 간에 경로 전파를 사용하도록 설정하려면 각 가상 네트워크에 Azure Route Server 인스턴스가 필요합니다. 두 Azure Route Server 인스턴스가 BGP 인접성을 설정할 수 없으므로 BGP 지원 NVA는 경로 간에 전파해야 합니다. 고가용성을 위해 두 개 이상의 NVA 인스턴스를 배포해야 합니다. 더 많은 인스턴스를 추가하여 처리량을 늘릴 수 있습니다. BGP 지원 NVA에는 서로 다른 서브넷에 연결된 두 개의 NIC가 있어야 합니다. 두 경로 서버(보조 가상 네트워크 및 허브 가상 네트워크)에 대한 BGP 세션은 서로 다른 NIC를 통해 설정되어야 합니다.
Azure VMware Solution 프라이빗 클라우드 및 온-프레미스 사이트에서 시작된 경로는 ExpressRoute 회로를 통해 학습됩니다. AS 경로에는 ASN 65515(ExpressRoute 게이트웨이에서 사용하는 Azure 예약 ASN) 및 ASN 12076(모든 피어링 위치에서 Microsoft Enterprise 에지 라우터에서 사용하는 Microsoft 소유 ASN)이 포함됩니다. BGP 지원 NVA는 경로가 BGP 루프 검색에 의해 삭제되지 않도록 AS 경로를 제거해야 합니다. 필요한 BGP 구성에 대한 자세한 내용은 Global Reach 없이 AVS에 대한 ExpressRoute 연결 구현을 참조 하세요. 컨트롤 플레인 구현은 이전 다이어그램의 파선으로 표시됩니다.
데이터 평면. 보조 가상 네트워크에서 Azure VMware Solution 프라이빗 클라우드와 온-프레미스 사이트 간의 트래픽은 BGP 지원 NVA를 통해 라우팅됩니다. Azure VMware Solution 프라이빗 클라우드와의 트래픽은 보조 가상 네트워크의 경로 서버와 함께 BGP 세션에 사용되는 NIC를 통해 NVA를 나가거나 입력합니다. 온-프레미스 사이트 간 트래픽은 허브 가상 네트워크의 경로 서버와 함께 BGP 세션에 사용되는 NIC를 통해 NVA를 나가거나 입력합니다. 이 NIC는 다음과 같은 사용자 지정 경로 테이블에 연결된 서브넷에 연결됩니다.
- 루프를 방지하기 위해 경로 서버에서 BGP 경로 학습을 사용하지 않도록 설정합니다.
- 데이터 경로에 허브 네트워크의 방화벽을 삽입합니다.
트래픽이 허브 방화벽을 통해 대칭적으로 라우팅되도록 하려면 Azure VMware Solution 프라이빗 클라우드에서 사용되는 모든 접두사에 대한 UDR을 허브의 GatewaySubnet에 구성해야 합니다. 자세한 내용은 Global Reach 없이 AVS에 대한 ExpressRoute 연결 구현을 참조 하세요. 데이터 평면 구현은 이전 다이어그램의 실선으로 표시됩니다.
다음 단계
Azure VMware Solution과 Azure 가상 네트워크 간의 연결에 대해 알아봅니다.