How-To

Network Connectivity in and to Azure: Private Link

Paul Schnackenburg details your current options for connecting workloads on-premises and in Azure and where each technology fits, giving you the right context for looking at Private Link, a recently released preview that completes the menu of possibilities you should consider.

• By Paul Schnackenburg
• 10/28/2019

Most businesses that I deal with are now hybrid, with some ICT systems running on-premises and some parts running in one or more public clouds. This situation brings with it many benefits around using the best of each world for the appropriate workload but also some challenges, particularly around networking and security.

In this article I'll look at what options you have today for connecting workloads on-premises and in Azure and where each technology fits, giving you the right context for looking at Private Link, a recently released preview that completes the menu of possibilities you should consider.

VPN
At the lower end of the spectrum and for many SMBs (along with larger businesses starting on their Azure journey) a very appropriate solution is a Site to Site (S2S) VPN. Here you'll connect a virtual network (vNet) in Azure, through a VPN gateway, to your on-premises networks. You'll need a router capable of creating IPsec/IKE connections and there's a list of tested devices, along with scripts and guides to make configuration easier.

The VPN gateway (here's a FAQ) comes in several different sizes from 100 Mbps to 1.25 Gbps, and if it grows into a critical part of your infrastructure you can run two of them (active – active) for redundancy and high availability. In regions that provide zone-redundancy (multiple datacenters with separate power, cooling and networking) you can host multiple gateways in separate zones. With a VPN gateway you can also offer Point to Site (P2S) connections from individual engineers' laptops to your vNet(s). Also note that BGP is supported (on all but the lowest SKU) if your network uses BGP for routing. You can route all traffic from your Azure resources to on-premises (forced tunneling) for inspection before internet access, which will make your security department happy and your network team cry tears of latency.

The challenge is that the traffic goes over the public internet which may be a security issue for your business, there's no SLA provided, and you must balance Azure traffic with any other traffic on your internet circuits.

ExpressRoute
The next step up, both in terms of price and capabilities, is ExpressRoute -- providing you a private link that's not traversing the internet, with an SLA and increased security.

ExpressRoute comes in speeds from 50 Mbps to 10 Gbps, and if that's not enough there's ExpressRoute Direct at 100 Gbps. The Premium flavor offers 10,000 routes (instead of 4000), the ability to connect more vNets (100 instead of 10), and the option to connect to other regions; for instance, you can have an ExpressRoute connection in Australia linked to a vNet in the U.S. with the traffic flowing over Azure's ultrafast backbone. Premium also offers Office 365 connectivity, which requires some thought and analysis of your on-premises networking infrastructure before Microsoft will allow it.

If on the other hand you'd like to connect two datacenters in two separate locations over Azure's network you can use two ExpressRoute connections and the Global Reach add-on to connect the two.

Each connection is actually two for redundancy. You'll need to work together with a telecom provider in your region to set up the Express Route connection. There are three flavors of connectivity, Cloud Exchange Co-location, Point-to-point Ethernet and Any-to-any (IPVPN) connections.

Application Connectivity Options
Azure Logic Apps are a low-code way to build automated and orchestrated business processes and workflows to connect apps, data and systems across clouds and on-premises. It has many connectors to facilitate easy configuration including options to connect to on-premises systems such as BizTalk, IBM DB2, MySQL, Oracle DB, SharePoint and Teradata along with others. You install an on-premises data gateway (no inbound firewall ports required) to facilitate the data flow.

Hybrid Connections lets you connect two networked applications, potentially behind firewalls or NATs, no matter where they're running. One of the use cases is App Service Hybrid Connections where your database with sensitive data resides on-premises but the Web site/application runs in Azure.

Service Endpoints
All Azure services are designed to be accessed from the internet (it's implicit in the word "Cloud") but that may be an issue for the security conscious. Take as an example a VM that you have running in a vNet in Azure that needs to access data stored in an Azure storage account. With proper credentials you can facilitate that connection, but it'll be routed through the default route called "internet" (0.0.0.0/0) which means anything outside your vNet, and that traffic will be on the public Azure backbone.

Instead, you can use Service Endpoints to have traffic go directly to that Platform-as-a-Service (PaaS) resource type. There are endpoints for a growing number of PaaS services including Storage, Azure SQL and many others. As an example, you could have PowerBI desktop running on a PC on-premises that needs to connect to an Azure SQL database. Normally that traffic would traverse the internet but if you have a S2S VPN or ExpressRoute, you can configure DNS with the private address of your Azure Firewall, and it'll forward the traffic via the service endpoint to Azure SQL.

Private Link
Now that we've looked at existing types of hybrid connectivity and Azure networking architecture and how they complement each other, let's look at the next tool in a cloud architects tool belt: Private Link.

As mentioned, this is an early preview of this new service, only available in a few regions and for a few services. It allows you to publish Azure PaaS services into your vNets with private IP addresses, making them fully routable on your vNets, and if you have a S2S VPN / ExpressRoute as in the above example you can connect directly to this DNS name for a private link to the Azure SQL database.

Private Link also solves a big problem for ISVs providing services in Azure -- with Private Link they can provide connectivity to their PaaS or Software-as-a-Service (SaaS) services (behind an Azure Standard Load balancer) without having to publish endpoints to the public internet. Note that unlike service endpoints, Private Link (here's an FAQ) only publishes a particular instance of a PaaS service, providing better security isolation than other cloud providers. It also helps where you need to connect applications in different vNets, but they have overlapping IP address spaces, blocking normal vNet peering.

Conclusion
So, in summary, for your own networks, Private Link offers the ability to present an instance of a particular PaaS service (say a single Azure SQL database) directly into your vNet, which you can then build NSG or Azure Firewall rules around. Service Endpoints scope traffic to a specific PaaS service, (all your Azure SQL databases) but can be restricted on a per region basis. And S2S VPN or ExpressRoute provide the overall connectivity that links your on-premises datacenters with Azure.

However, I think the real winners with Private Link are third-party ISVs, offering services in Azure that can now be securely published directly into your infrastructure with no internet connectivity required.