리프트 앤 시프트 마이그레이션을 수행할 때 Azure에서 다양한 유형의 대상을 접하게 됩니다. Azure의 대상 중 하나는 Azure VMware Solution(AVS)으로, Azure의 프라이빗 클라우드 오퍼링입니다. 기본적으로 전용 베어 메탈 서버의 vSphere 클러스터가 포함됩니다. AVS의 스토리지를 확장해야 하는 경우 Azure에는 여러 스토리지 옵션이 있습니다. 이 블로그에서는 퍼스트파티 오퍼링에 초점을 맞춥니다.

vSAN: 로컬 스토리지

이 유형의 스토리지는 베어 메탈 서버에 로컬로 연결된 디스크에서 제공됩니다. 이는 NVMe SSD로, 노드 자체에서 직접 제공되므로 가장 빠른 스토리지를 제공합니다.

저장소 크기는 클러스터에 배포하는 노드 수에 따라 달라집니다. 최소 3개에서 최대 16개의 노드를 단일 클러스터에 배포할 수 있습니다. 크기는 RAID 구성에 따라 달라집니다.

FTT는 클러스터가 실패를 견뎌내고 손실 없이 데이터를 유지할 수 있는 노드 수를 나타냅니다. FTT 속도가 높을수록 최소 호스트 요구 사항이 높아집니다.

RAID를 구성한 후 사용 가능한 공간이 무엇이든 vSAN에 여유 공간으로 25%를 유지해야 한다는 점을 명심하세요. 이는 호스트 장애, 업데이트 및 vSAN 정책 변경을 위한 것입니다. SLA 요구 사항을 충족하려면 25%의 여유 공간을 유지해야 합니다.

AVS 호스트에서 얻을 수 있는 사용 가능한 스토리지를 계산하려면 아래에 언급된 웹사이트를 사용할 수 있습니다. 이 예는 AV36P입니다. 여기에는 각각 3.2TB의 용량 디스크 3개가 있는 2개의 디스크 그룹이 있습니다.

관찰에 따르면 노드당 10~13TB의 사용 가능한 공간을 얻을 수 있습니다. AVS 노드가 있는 용량 디스크는 아래 스크린샷에서 찾을 수 있습니다.

이것은 두 개의 디스크 그룹으로 나뉩니다.

공간 요구 사항이 vSAN에서 얻을 수 있는 사용 가능한 공간보다 높으면 원격 스토리지를 선택하거나 추가 노드를 얻어서 vSAN을 확장해야 합니다. AVS의 노드는 연결된 스토리지와 함께 제공됩니다. 클러스터에서 노드를 추가하는 것은 비용이 많이 드는 옵션이므로 기본적으로 추가 노드를 추가하지 않고 스토리지를 확장하는 것을 의미하는 원격 스토리지 옵션을 확인할 수 있습니다.

AVS는 ANF나 Elastic SAN 등 자사에서 제공하는 다양한 형태를 지원하지만, Pure Storage와 같은 타사 스토리지도 지원합니다.

AVS를 사용한 Azure NetApp 파일

Azure NetApp Files는 VM 내부에서 NFS 공유를 마운트하는 데 사용할 수 있으며 vCenter에서 NFS 데이터 저장소로 사용할 수도 있습니다. AVS는 VNET이 아닌 별도의 베어 메탈 서버에 호스팅되므로 ANF 볼륨에 연결해야 하는 경우 AVS에 내장된 ExpressRoute를 통해 연결해야 합니다. ANF는 게이트웨이인 ExpressRoute 게이트웨이를 통해 ExpressRoute 회로에 연결된 별도의 VNET에 배포됩니다.

AVS와 ANF 간 데이터 전송은 내장된 ExpressRoute 연결을 통해 연결되므로 무료입니다.

아래 다이어그램은 연결 메커니즘을 보여줍니다.

AVS가 특정 구역에 배포되므로 데이터스토어에 대한 저지연 연결을 달성하기 위해 ANF도 동일한 구역에 배포해야 합니다. 이는 ANF를 특정 구역에 배치하는 가용성 구역 볼륨 그룹 배치 기능으로 달성할 수 있습니다.

AVS에서 ANF와의 연결은 데이터 저장소 트래픽을 처리하는 별도의 VMK를 통해 이루어지며 트래픽 격리를 제공합니다.

더 나은 처리량을 위해 고객은 FastPath 기능을 제공하는 Ultra VPN GW 또는 ErGw3Az SKU를 배포할 수 있습니다. FastPath가 활성화되면 게이트웨이를 우회하여 네트워크 트래픽을 AVS로 직접 전송합니다.

VM의 VMDK가 ANF에 배치된 경우, VM을 백업할 수 있는 클라우드 백업 플러그인을 활용할 수 있습니다. 이 도구는 현재 미리보기 상태이며 무료입니다.

AFS는 NFS 프로토콜도 제공하지만 현재는 데이터 저장소로 지원되지 않습니다.

AVS를 사용한 Azure Elastic SAN

ANF ​​외에도 Microsoft는 스토리지 요구 사항을 충족하는 퍼스트파티 솔루션인 Elastic SAN을 제공합니다. 이는 Azure NetApp Files보다 저렴하고 확장 가능합니다. Elastic SAN은 AVS에 데이터 저장소를 제공하는 데 사용할 수 있습니다. AVS에 매핑할 수 있는 iSCSI LUN을 얻고 해당 데이터 저장소에 VM을 만들 수 있습니다.

Elastic SAN은 VMFS 데이터 저장소로 노출됩니다.

기본적으로 Elastic SAN은 프리미엄 SKU로 제공됩니다. TB 단위로 기본 SKU를 구매하면 IOPS와 처리량이 증가합니다. 그러나 기본 SKU로 처리량과 IOPS 요구 사항이 충분한 경우 추가 스토리지를 추가할 수 있으며, 이는 더 저렴하고 IOPS와 처리량이 증가하지 않습니다.

위의 스크린샷에서 보듯이, 기본 크기는 IOPS와 처리량을 늘리는 반면, 더 저렴한 추가 용량은 IOPS/처리량에 영향을 미치지 않습니다.

Elastic SAN은 Azure Portal의 AVS 블레이드에 완전히 통합되어 있습니다. 동일한 블레이드에서 데이터스토어를 만들 수 있으므로 데이터스토어를 매핑하고 확장하기가 더 쉽습니다.

AVS 아키텍처의 스토리지 옵션을 다루었습니다. 이것이 새로운 기회에 맞춰 AVS의 크기를 정하는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

오늘 이 블로그에서는 퍼블릭 도메인과 네임 서버 토픽에 대해 논의하겠습니다. 관리자와 아키텍트에게 중요한 토픽 중 하나입니다. 또한, 이는 데이터 센터 종료 시나리오나 분할 및 인수 시 주요 토픽 중 하나입니다. 먼저 Azure 퍼블릭 DNS 존에 대해 이야기해 보겠습니다.

Azure 공용 DNS 영역:

이것은 Azure의 무기고에 있는 DNS 서비스 중 하나입니다.이름에서 알 수 있듯이 이것은 개인 이름 확인이 아닌 공개 이름 확인을 위한 DNS 서비스입니다.개인 DNS 이름 확인을 위해 개인 DNS 영역이 있습니다.따라서 기본적으로 GoDaddy와 같은 DNS 등록 기관에서 공개 도메인 이름을 소유하고 있고 해당 도메인 이름에 대한 자체 이름 서버를 관리해야 하는 경우 Azure Public DNS Zone 서비스를 사용할 수 있습니다.이름 서버는 도메인에 대한 모든 레코드가 호스팅되는 곳입니다.기본적으로 GoDaddy와 이러한 많은 도메인 등록 기관은 이름 서버를 무료로 제공합니다.예를 들어 GoDaddy 도메인을 소유한 경우 아래 스크린샷을 확인할 수 있으며 GoDaddy가 도메인 이름에 대한 이름 서버를 소유하고 있습니다.

레코드가 게시되면 DNS 전파를 제외하고 공개되기까지 24시간이 걸리는 도메인 등록 기관이 있습니다.또 다른 시나리오는 많은 등록 기관이 이메일을 사용하여 통신하고 지원이 때때로 지연되는 것입니다.따라서 마이그레이션 중에 레코드를 관리하는 데 시간이 걸립니다.또한 때로는 이름 서버의 가용성이 문제가 될 수 있습니다.이름 서버를 사용할 수 없으면 클라이언트가 IP 주소를 확인할 수 없습니다.이름 서버를 직접 호스팅하여 이름 서버의 소유권을 가질 수 있습니다.Azure Public DNS Zone은 고가용성이 내장되어 있고 100% SLA를 제공하는 관리형 서비스입니다
.그렇습니다.공개 DNS 영역은 글로벌 서비스이므로 100% SLA입니다.도메인의 이름 서버를 알고 싶다면 nslookup을 사용하여 이름 서버 레코드를 찾을 수 있습니다.

Azure Public DNS 존의 네임 서버는 아래와 같습니다. 이는 단지 예시일 뿐입니다. DNS 존을 만들면 도메인의 네임 서버 레코드를 받게 됩니다.

Microsoft.com과 azure.com도 Azure Public DNS Zone에 호스팅됩니다.

퍼블릭 DNS 존을 만들면 아래와 같습니다. 제공된 네 개의 네임 서버 레코드를 볼 수 있습니다. 이를 네임 서버 레코드로 사용하여 DNS 등록자에게 제공해야 합니다. 네임 서버를 기본 DNS 등록자의 NS 레코드에서 Azure의 NS 레코드로 변경하면 Azure 퍼블릭 DNS 존에 있는 레코드가 권한이 있고 활성화됩니다.

레코드를 만들 수 있습니다. 레코드 세트 섹션으로 가서 모든 레코드를 만드세요.

Azure Public DNS로 이름 서버를 마이그레이션하기 전에 Azure Public DNS Zone에 모든 레코드를 만들었는지 확인해야 합니다. 예를 들어 GoDaddy 또는 다른 공급자에 www.xyz.com 레코드를 만든 경우 Azure DNS Zone에 유사한 A 레코드를 만들었는지 확인해야 합니다.
Azure Public DNS Zone을 만들었다고 해서 퍼블릭 레지스트라에서 DNS 이름을 구매한 것은 아닙니다. Azure Public DNS Zone은 이름 서버 역할을 할 뿐입니다. 여전히 Godaddy, Squarespace, Namecheap 등과 같은 DNS 레지스트라에서 퍼블릭 도메인 이름을 소유해야 합니다. 여기서 Azure에서 도메인을 구매하는 또 다른 주제로 넘어갑니다.

Azure App Service 도메인:

Azure에서 직접 도메인을 구매할 수 있습니다. 이는 새 웹사이트를 배포하거나 새 프로젝트를 진행하는 경우 타사 등록 기관을 통해 도메인을 구매하고 싶지 않을 때 발생합니다. Microsoft는 ICANN에 등록된 등록 기관이지만 Microsoft는 최종 고객에게 직접 퍼블릭 도메인을 제공하지 않습니다. 이는 GoDaddy를 통해 라우팅됩니다. 따라서 Azure App Service Domain에서 도메인을 구매할 때마다 Azure에 비용을 지불하고 이 경우 GoDaddy와 직접 거래하지 않습니다.

Azure에서 구매하고 GoDaddy를 통해 구매하지 않는 이유는 무엇일까요? 조달 팀에 대한 의존성 없음, Azure에서 직접 도메인을 빠르게 배포하고 단일 공급업체(Microsoft)에 지불하는 것이 몇 가지 이유가 될 수 있습니다.

App Service Domain을 배포할 때마다 호스팅 레코드를 위해 Azure Public DNS와 통합됩니다. DNS 레코드 관리를 클릭하면 Azure DNS 페이지를 찾을 수 있습니다. 이름 서버 레코드는 처음부터 Azure DNS로 자동으로 업데이트됩니다.

위의 설명이 공용 DNS를 보다 효율적으로 배포하고 관리하는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

Azure Migrate Server Assessment를 사용한 Azure VMware 솔루션(AVS) 마이그레이션 및 용량 계획

https://www.youtube.com/watch?v=NoNG-hkksrA&ab_channel=HusamHilal

이 비디오에서는 Azure Migrate Server Assessment를 사용하여 Azure VMware Solution(AVS)에 대한 마이그레이션 및 용량 계획을 수행하는 단계를 안내합니다. 비디오 콘텐츠:
 00:00​ - 소개
 00:59​ - Azure Migrate Assessment 상위 수준 단계 
 02:37​ - 데모: Azure Migrate 프로젝트 만들기
 03:51​ - 데모: 온프레미스 VM 검색
 09:50​ - 데모: Azure Migrate Assessment 만들기
 11:53 - 데모: Azure Migrate Assessment 검토

평가 개요(Azure VMware 솔루션으로 마이그레이션)

https://docs.microsoft.com/en-us/azur...

일반적으로 사용 가능: Azure Migrate를 사용하여 Azure VMware 솔루션으로의 마이그레이션 계획 https://azure.microsoft.com/en-us/upd...

Azure VMware 솔루션(AVS) 평가 만들기

https://docs.microsoft.com/en-us/azur...

RVTools

https://www.robware.net/rvtools/

Azure 가격 계산기(Azure VMware 솔루션 검색)

https://azure.microsoft.com/en-us/pri...

Azure VMware 솔루션(AVS)과 Azure Application Gateway 통합

https://www.youtube.com/watch?v=BoQYvqzb6Y8&ab_channel=HusamHilal

이 비디오에서는 Azure Application Gateway를 Azure VMware Solution과 통합하는 사용 사례를 설명합니다. Azure Application Gateway는 Azure VMware Solution 내의 ESXi 호스트에서 호스팅되는 애플리케이션 및 워크로드에 대한 웹 트래픽 부하 분산 장치로 작동할 수 있습니다. 비디오 콘텐츠:
 0:00 - 소개
 0:52 - AVS의 부하 분산 장치 옵션
 1:40 - Azure App Gateway 구성 요소 및 트래픽 흐름
 3:11 - 데모: Azure Application Gateway 만들기
 7:05 - 데모: 예상 기능 테스트

이 비디오에서는 Azure VMware Solution(AVS) Private Cloud에 대한 vCenter CloudAdmin 및 NSX-T Admin의 비밀번호를 순환하기 위한 Azure Logic App 워크플로를 만드는 단계를 안내합니다. Azure Logic Apps는 최근에 릴리스된 리소스 작업 rotateVcenterPassword, rotateNSXTPassword를 호출하여 비밀번호를 재설정합니다. 또한 listAdminCredentials 리소스 작업은 검증 목적으로 실제 비밀번호 값을 검색하는 데 사용되었습니다

https://www.youtube.com/watch?v=cK1qY3knj88&ab_channel=HusamHilal

 00:00 - 소개 및 브리핑
 02:20 - 데모
 02:25 - Azure Logic App에 Azure 관리 ID 사용
 03:00 - Azure Logic App 시스템에 할당된 관리 ID에 권한 할당
 04:10 - Azure Logic App 워크플로 설계 및 빌드
 09:05 - 기존 vCenter CloudAdmin 및 NSX-T Manager 관리자 암호 가져오기
 10:00 - 워크플로 테스트 및 트리거
 11:19 - 새 암호의 값을 이전 값과 비교(확인)
 11:55 - 감사합니다

Azure VMware 솔루션(AVS) 관리형 SNAT 서비스를 사용하여 아웃바운드 인터넷 액세스 활성화

이 비디오에서는 관리형 SNAT 서비스를 사용하여 Azure VMware 솔루션 워크로드(VM)에 대한 아웃바운드 인터넷 액세스를 활성화하는 단계를 안내합니다. 

https://www.youtube.com/watch?v=1Jgg-Hj2trI&ab_channel=HusamHilal

Azure VMware 솔루션의 NSX Edge에 공용 IP 활성화

https://www.youtube.com/watch?v=Gr6z8pCqviA&ab_channel=HusamHilal

이 비디오에서는 VMware NSX-T Edge에서 Azure Public IP 기능을 사용하여 Azure VMware Solution에서 실행되는 VM으로 인터넷에서 인바운드 액세스를 활성화하는 단계를 안내합니다. 이는 NSX-T에서 DNAT 규칙을 구성하고 방화벽 정책을 사용하여 액세스를 보호하면 가능합니다

Azure 라우팅 테이블이란?

Azure에서 가상 네트워크를 만들 때마다 기본 서브넷이 VNET에 추가됩니다. 필요에 따라 VNET에 사용자 정의 서브넷을 추가할 수 있습니다. Azure VNET 에서 서브넷을 만들면 각 서브넷에 대한 Azure 경로 테이블이 생성됩니다. Azure는 이 경로 테이블 각각을 시스템 정의 경로로 자동으로 채웁니다. 이러한 경로 테이블은 실제로 트래픽을 전달하기 위해 서브넷 내에서 IP 경로 조회에 사용됩니다.

Azure 경로 유형

기본적으로 Azure 서브넷 라우팅 테이블에는 다음 두 가지 유형의 경로가 있습니다.

• 시스템 경로 : 모든 라우팅 테이블에 나타나는 몇 가지 기본 시스템 경로가 있습니다 .
• 선택적 시스템 경로 : 그러나 특정 서비스가 켜질 때만 서브넷 라우팅 테이블에 나타나는 일부 선택적 시스템 경로 도 있습니다 .
• 사용자 정의 경로/ 사용자 정의 경로

기본 시스템 경로:

이것들은 Azure가 서브넷 라우팅 테이블에 자동으로 채우는 경로입니다. 라우팅 테이블에서 이러한 경로를 삭제할 수는 없지만 사용자 정의 경로로 재정의할 수 있습니다.

Azure가 각 서브넷에 대해 만드는 기본 시스템 경로는 다음과 같습니다.

라우팅 테이블의 각 경로에는 주소 접두사와 해당 접두사에 대한 연관된 ​​다음 홉이 있습니다. 트래픽 라우팅은 목적지에 따라 수행됩니다. 서브넷을 떠나는 트래픽이 경로의 주소 접두사 내의 IP 주소로 전송될 때 접두사가 포함된 경로가 Azure에서 사용하는 경로입니다.

라우팅 테이블은 네트워킹 장치의 기존 라우팅 테이블과 유사하게 작동하지만, 다음 홉 유형이 더 이상 IP가 아니라는 점이 다릅니다. Azure 네트워킹은 소프트웨어로 정의되므로 Azure 네트워킹 세계에서는 다양한 다음 홉 유형이 사용됩니다.

Azure Next-Hop 유형

Azure 라우팅 테이블의 다양한 다음 홉 유형은 다음과 같습니다. 

• 가상 네트워크: Azure는 기본적으로 VNET의 서브넷 간 트래픽을 라우팅합니다. 따라서 다음 홉 유형이 가상 네트워크로 나열된 모든 다른 서브넷의 VNET 내의 각 서브넷 접두사에 대해 시스템 경로가 생성됩니다.
• 인터넷: 서브넷에서 인터넷으로 트래픽을 라우팅하는 데 사용됩니다. Azure는 가상 네트워크 내의 주소 범위에 지정되지 않은 모든 주소에 대한 트래픽을 인터넷으로 라우팅합니다. 단, 대상 주소가 Azure 서비스용인 경우는 예외입니다.
• 없음: 다음 홉 유형 None으로 가는 트래픽은 기본적으로 삭제됩니다. Azure는 다음 주소 접두사에 대한 기본 경로를 자동으로 만듭니다.
  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16: RFC 1918에서 개인용으로 예약됨.
  • 100.64.0.0/10: RFC 6598에 예약됨.

RFC1918 주소 범위 중 하나라도 가상 네트워크 내에서 사용되는 경우 Azure는 자동으로 다음 홉 유형을 없음에서 가상 네트워크로 변경합니다.

선택 시스템 경로:

일부 선택적 시스템 경로는 특정 Azure 서비스가 활성화되어 있는지에 따라 서브넷에 추가될 수도 있습니다. 이러한 경로는 활성화된 서비스 유형에 따라 특정 서브넷 또는 모든 서브넷에 추가될 수 있습니다.

선택적 시스템 경로 테이블의 예는 다음과 같습니다. 

• VNET 피어링: 피어링된 VNET의 라우팅 테이블에 VNET에 지정된 각 주소 범위에 대한 경로가 추가됩니다.
• 가상 네트워크 게이트웨이: 온프레미스에서 일부 BGP 경로를 수신하는 경우 해당 경로는 Azure에서 다음 홉을 가상 네트워크 게이트웨이로 사용하여 학습된 것으로 표시됩니다.
• 가상 네트워크 서비스 엔드포인트: 서비스 엔드포인트 는 특정 VNET 서브넷에서 다른 Azure 서비스(예: Azure Storage, Azure SQL)에 대한 개인 액세스를 제공하는 Azure 서비스입니다. Azure는 서비스에 서비스 엔드포인트를 활성화하면 특정 서비스의 공용 IP 주소를 경로 테이블에 추가합니다. 

사용자 정의 경로/ 사용자 정의 경로:

서브넷 라우팅 테이블에서 기본 시스템 경로를 삭제할 수는 없지만 사용자 정의 경로를 만들어서 이를 재정의할 수 있습니다.

넥스트홉 유형

사용자 정의 경로에 대해 다음과 같은 다음 홉 유형을 가질 수 있습니다. 

• 가상 어플라이언스:  네트워크 가상 어플라이언스 VM(예: VNET의 방화벽)을 사용하고 VNET 트래픽을 방화벽 인스턴스를 통해 라우팅하려는 경우 UDR을 만들고 Next-hop 유형을 Virtual Appliance로 정의할 수 있으며 Next-hop IP는 VM에서 사용되는 개인 IP입니다. 
• 가상 네트워크 게이트웨이:  다음 홉이 가상 네트워크 게이트웨이가 될 접두사에 대해 이를 지정합니다 .
• 없음: 패킷을 삭제할 접두사를 지정합니다.
• 가상 네트워크: 가상 네트워크 내에서 기본 라우팅을 재정의할 시기를 지정합니다.
• 인터넷:  주소 접두사로 향하는 트래픽을 인터넷에 명시적으로 라우팅하려는 경우 또는 Azure 백본 네트워크 내에 있는 공용 IP 주소를 사용하여 Azure 서비스로 향하는 트래픽을 원하는 경우 지정합니다.

Hello and welcome to today’s post! In this one, I will show how to create a Site-to-Site connection between an Azure Network and one that is On-Prem.

In order to complete these following steps, you will need to have some prerequisite:

• An Azure Virtual Network
• An Azure Windows Virtual Machine
• An up and running Windows Server

This is the plan for today’s post:

• Part 1: Create a Gateway subnet
• Part 2: Create a Network Gateway
• Part 3: Create a Local Network Gateway
• Part 4: Configure Server for connection
• Part 5: Create an Azure connection and verify connectivity

Part 1: Create a Gateway subnet

• Go to your Azure Virtual Network page. Under settings, click subnets.
• Click + Gateway subnet.

• Enter a subnet address range and click Save.

Part 2: Create a Network Gateway

• In the search bar, enter virtual network gateways and click on the choice given as shown below.

• Click Create.

• Enter the Name for the gateway.
• In the SKU field, enter VpnGw1.
• In the Virtual network field, select the appropriate network that you want to connect. That network is the same that contains the Gateway subnet that we created earlier.

• In the Public IP address field select Create new.
• In the Public IP address name, enter a name recognizable name.
• Click Review + Create, then Create.

Part 3: Create a Local Network Gateway

• In the search bar, type Local network gateways as shown below.

• Click Create

• Enter Name.
• Enter the IP address of your Router.
• Enter the Address Space of you local network.
• Click Review + Create, then Create.

Part 4: Configure Server for connection

Part 4.a: Add Remote Access feature

• In your server manager dashboard top bar, click Manage then Add Roles and Features.

• Click Next until the Server Roles page then check Remote Access.
• Click next until you get to Select Role services page.

• Check Routing. (DirectAccess and VPN (RAS) will be automatically selected.)

• Click Add Features then click next until you get to the confirmation page.

• Click Install

• When the installation is complete, click Close.

Part 4.b: Configure Routing and Remote Access

• On the top bar of the server manager, click Tools, then Routing and Remote Access.

• On the Routing and Remote Access, right click on the Server icon then click Configure and Enable Routing and Remote Access.

• Select Custom configuration, then click next.

• Check VPN access and LAN routing then click next.

• Click Finish.

• Click Start service.

Part 4.c: Create a new Network Interface

• Back on the Routing and Remote Access window, right click Network Interface, then New Demand-dial Interface.

• Enter a Name for the interface then click next.

• Select Connect using virtual networking (VPN) then click Next.

• Select IKEv2 then click next.

• Enter the public IP address of the Virtual Network Gateway that we created earlier then click Next.

• Check Route IP packets on this interface, then Next.

• Click Add.

• Enter the Cloud Destination address and Mask.
• Enter 10 for Metric, then click OK. (Metric specifies the priority)

• Click Finish

• Right Click on the newly created interface, then click Properties.

• In the Option tab, select Persistent connection

In the Security tab, select Use preshared key for authentication and enter a Key that we will use later, then click OK.

Part 5: Create an Azure connection and verify connectivity

• Back in Azure, search for Connections.

• Click Create

• Select Site-to-site (IPsec) for Connection type.
• Enter a Name for the connection and click Next.

• Select the appropriate Virtual network gateway and Local network gateway that we created at the beginning.
• In the Shared key field, enter the Preshared Key that we created earlier and click Review + create, then Create.

• After the deployment is complete, click Go to resource.

• Notice the status says Not Connected.

Back in the Server manager Routing and Remote Access window, right click the Interface that we created earlier and click Connect.

• Back in the Connection page on Azure, click Refresh and notice the status says Connected. (It might take a few minutes to update).

• Test the connection by Pinging the cloud machine with its private IPv4 address to test the connection. (Make sure the cloud machine firewall allows Pings from the internal network.)

This wraps up this post on Setting up a Site-to-Site connection between an on-prem network and an Azure network.

Thank you for reading!