Earlier this month, VMware released a new version of HCX, the powerful multi-cloud migration solution. With the help of HCX, you can easily migrate your virtual workloads between private clouds and, more importantly, to public cloud environments like Azure VMware Solution(AVS). Additionally, when HCX is being used in conjunction with public cloud SDDCs like AVS, cloud migrations would be as easy as running a vMotion internally inside your data center. Sounds great, isn’t it!
It is also important to note that many enterprises are using only site-to-site VPN as the connectivity method for on-prem to public cloud infrastructure. Because of this, formal support of HCX over VPN underlay has been asked by many organizations and customers.
As cloud network engineers, we should ensure that name resolution functions properly both in on-premises environments and public cloud infrastructure. As part of the AZ-700 Study Guide, this blog post will discuss the deployment of DNS service on Azure. It is vital to set up the DNS service because, like Microsoft Azure, we still need to resolve FQDNs to respective IP addresses on public cloud infrastructure. In addition, we might also need to utilize DNS to discover services. Microsoft Azure provides both public and private DNS zone for Internet and internal name resolution. There is also a built-in Azure-provides DNS that works by default on vNets, and if needed, there are custom DNS zones available to use.
The previous AZ-700 Study Guide blog posts covered Site-to-Site VPN, Point-to-Site VPN, and Azure ExpressRoute. In this post, we will explore private IP addressing in Azure Virtual Networks(vNets). The fundamental building block of private networking in Azure is based on vNets. This construct is a Layer 3 networking construct and has CIDR-block attached to it. This CIDR-block represents the private IP address space that network components can use on your Azure infrastructure. Proper design and implementation of this private IP addressing are crucial due to its effect on all other networking design decisions and deployment in Azure.
In two previous posts, we covered Azure Site-to-Site VPN and Point-to-Site VPN. The next objective of AZ-700’s Hybrid networking is designing and deploying Azure ExpressRoute. ExpressRoute is a method to extend your On-Premises network into the Microsoft cloud with the help of ExpressRoute service providers. If you need a private/high-speed connection to access Microsoft cloud services like Azure or Office 365, ExpressRoute is the right solution. This connectivity method doesn’t use the public Internet, and thus it provides higher security, more bandwidth, and higher reliability than Site-to-Site VPN. Many organizations want to avoid public Internet for cloud extension in terms of networking, and here is where ExpressROute could shine as the proper solution. The private connection is provided by specific connectivity partners, and based on your location; you have few options to choose from.
In the previous blog post, we covered Azure Site-to-Ste VPN. As part of the Azure AZ-700 Study Guide, this blog post continues with another hybrid networking technology that allows client endpoints to connect to Azure vNet infrastructure. Besides connecting your headquarter and branch office networks to Azure, it is also vital to have an infrastructure to provide connectivity to your mobile users. Using Point-to-Site Virtual Private Network(P2S VPN), client endpoints can connect and use Azure services. You can implement P2S VPN on Route-based Azure VPN gateways and provide a secure connectivity option to your users.
Design and implement a hybrid networking infrastructure is part of every cloud adoption project. Organizations planning to embrace public cloud services and migrate resources to Azure usually need communication channels between the on-premises environments and Azure. One of the widely used technologies that provide the required communication channel is Site-to-Site Virtual Private Network (S2S VPN). To deploy such a communication channel, you will set up a VPN IPSec tunnel between an On-premise gateway and Azure VPN gateway. As part of the Azure AZ-700 Study Guide, in this blog post, we are going to explorer Azure S2S VPN
A few days ago, Microsoft introduced a brand new certificate titled Azure Network Engineer Associate. Since networking is one of the core elements of any cloud infrastructure, it is crucial to educate the Subject Matter Experts in planning, implementing, and maintaining Azure networking solutions. AZ-700: Designing and Implementing Microsoft Azure Networking Solutions exam should be taken and passed successfully to achieve this certificate. As a firm believer of certification programs and someone who has been working in the IT industry for quite a long time, I would recommend taking the training and AZ-700 exam to those who work with Azure networking. The reason behind believing in the certification programs is you will learn the required concepts based on a proven learning framework.
In the previous blogpost we went through Azure VMware Solution(AVS) IPSec VPN setup and to complete hybrid networking between on-prem and AVS we need to configure NSX-T gateway too. As we discussed the target architecture would look like the following diagram.
When it comes to connecting an on-premises VMware environment to Azure VMware Solution(AVS), ExpressRoute is the recommended & preferred connectivity method. But in some cases using a VPN tunnel is the only viable connectivity solution to AVS environment.
NSX-T Tier-0 or Tier-1 gateways could be used to connect on-premises VMware environment to AVS. On the Azure side, Virtual WAN(vWAN HUB) will be provide the transit connectivity through a ExpressRoute Gateway into AVS infrastructure. I am going to walk you through the configuration of both NSX-T Tier-1 GW and Azure Virtual WAN to have a complete setup.
When it come to setting up a hybrid cloud environments, one of the most important topics is networking. It is usually comes down to stretch on-prem network segments to the public cloud environment. This blog post is going to simply describe NSX-T architecture on AVS as the default networking and security stack. If you are new to AVS you can read Introduction to AVS blog post first, and then continue with this article.