It’s rare to find an organization today that isn’t adopting a cloud infrastructure for one or more of their applications. While some organizations prefer to build their cloud infrastructures themselves, leveraging a cloud provider who offers Infrastructure-as-a-Service (IaaS) and assistance to help manage the move to a modern datacenter is also a common path to reach this goal. One of the largest public cloud options, Microsoft Azure, is growing in popularity and is the basis of many infrastructure and cloud Dynamics offerings today.
Azure offers the ability to deploy applications as cloud workloads as well as migrate legacy systems via IaaS strategies. The key component of making this strategy work is continuing to provide reliable private connectivity to these services once they’ve been migrated. Azure allows for site-to-site VPNs, point-to-site VPNs, as well as the newly available express route connectivity option. In this article, we outline the benefits and limitations of the three strategies Azure offers for private connectivity.
In last month’s article, Setting up Microsoft Azure for Test and Development Environments, we mentioned Virtual Networks (VNets), overlays that are configurable with Azure that enable servers and services to communicate with one another. It’s safe to assume that if you’re going to have more than one server within Azure, you are going to need a VNet. You’ll also need a VNet if you’re planning on creating a cross-premises connection or hybrid solution, if you want to configure a DNS solution for your VMs, or if you want to use a persistent private IP address. If you initially deploy your VNet as a cloud-only network you’ll have to create a new VNet and recreate your VM’s on it, so make sure that you plan accordingly.
Option 1: Site-to-Site VPN
The first connectivity solution we’ll look at is the site-to-site VPN, as it is the most applicable of the three. The site-to-site option allows for direct network connectivity from your on-premise network to the cloud VNet (or VNets) that you’ve created. In order to configure a site-to-site VPN you’ll need to have an externally facing VPN device that is on the approved VPN device list, or a Windows Server configured with Routing and Remote Access Services (RRAS) enabled.
When creating VPNs, you’ll have the option of creating a static-routing VPN or a dynamic-routing VPN. A static-routing VPN is applicable if you only have one site that will be connecting to your VNet. If you have multiple sites that need to connect to the VNet, you’re deploying both a site-to-site VPN and a point-to-site VPN, or you want to create a VNet-to-VNet connection, you’ll need to choose a Dynamic Routing Gateway. Like many other items within Azure you cannot change the gateway type once you’ve created it. If you need to change from static to a dynamic gateway you’ll need to delete your gateway and recreate it. Also of note: if you’ve selected one of the options that requires a dynamic gateway, the portal will not… click here to read the rest of this article