Microsoft has several offerings for private connectivity from and to your Virtual Network. Which one should you choose?
Azure Platform as a Service offerings are great. Who does not love components that you can build up and break down quickly, can scale up or down in no time at all and allow you to focus on what is important: bringing value to the business?
However, having your cloud components accessible from the internet might not be what you want for many security reasons. Even if you use Virtual Network Integration, IP restrictions and connection strings you are potentially vulnerable to DDOS attacks, losing security keys and credentials, IP spoofing and many other security pathways. All these vulnerabilities can be solved in different ways, but it is a lot of work setting them up and probably not cheap to keep them running.
Microsoft has also recognized this fact and is working on adding private connectivity from your Azure Virtual Network to many Azure PaaS offerings with Azure Private Link. Azure Private Link simplifies the network architecture and secures the connection between endpoints in Azure by eliminating data exposure to the public internet.
What is Azure Private Link?
The simplest way to explain a Private Link is a private IP address inside of your Virtual Network that allows access to Azure PaaS resources. As seen in the image below the Azure SQL Server only allows traffic from that one Private endpoint in the Virtual Network.
A complete Private Link service consists of a few resources.
- An Azure Private Endpoint is a network interface that connects you privately and securely to a service powered by Azure Private Link. Private Endpoint uses a private IP address from your Virtual Network, effectively bringing the service into your Virtual Network. This part is configurable in the PaaS component. The Private Endpoint will also have a network interface associated with it.
- The Azure Private Link service refers to your own service that is managed by Private Link. It effectively manages the communication to and from the PaaS component.
- I recommend having a private DNS zone. The private DNS zone resolves the fully qualified domain name (for example yourwebappname.privatelink.azurewebsites.net) to the allocated private IP address (for example 10.1.1.1). More about this later.
Network traffic will not leave your Virtual Network. No communication with the Internet is made to get to your PaaS resources.
What Services support Private Link
Many PaaS components support Private Link. For example, storage services like Azure Cosmos DB, Azure SQL Database and Azure database for PostgreSQL. Many cloud computing services also have support like Azure Event Grid, Azure Web Apps and Azure Automation. For an up-to-date availability overview of the services with Private Link support, please check: https://docs.microsoft.com/en-us/azure/private-link/private-link-overview#availability.
Costs and considerations
A Private Link does not come with any costs by itself. However, some resources that a Private Link needs to function have costs. First there is the Private endpoint, which at the time of writing, charges 0.009 Euro per hour, which results in about 6.5 Euro per month. You also need a Private DNS zone, which will set you back 0.422 Euro per zone per month at the time of writing. Then for the variable cost: each GB of data processed there is also a cost of 0.009 Euro. These figures will probably not break the bank for you. Since pricing is subject to change, please consult https://azure.microsoft.com/pricing/ for an up-to-date price check.
In total a Private Link would not even cost eight Euro per month when it processes 100 GB of data.
Private Link vs Service Endpoints
Azure Service Endpoints and Azure Private Link seem to overlap quite a bit. While it is true that they both allow traffic from a specific Virtual Network to a PaaS offering, the way they achieve it is different.
When comparing Private Link to a Service Endpoint, it should be noted that a Private Link is a bit more complex. A Private Link needs some other resources to be useful, like a private DNS. While you do not need to have a private DNS to communicate with the resource behind the Private Link, it is useful to know how to do it, as you sometimes do have to and often want to. For example, when you are connecting to a Private Link resource using a fully qualified domain name (FQDN) as part of the connection string, it is important to correctly configure your DNS settings to resolve to the allocated private IP address. This is not complicated necessarily, but if you are unfamiliar with these kind of networking resources it might take a little while to get the hang of it.
With Service Endpoints, the PaaS service is still separate from your Virtual Network and traffic is leaving your Virtual Network to access the PaaS service. However, the PaaS service is configured to be able to identify traffic coming from your virtual network and allow that, without the need to configure public IP’s on your Virtual Network to allow filtering.
With Private Link however, all traffic to the service can be routed through the Private endpoint, so no gateways, NAT devices, ExpressRoute or VPN connections, or public IP addresses are needed. Private Link traffic stays within your Virtual Network.
While trying to secure an Azure PostgreSQL server with Private Link we came across some behavior we did not expect. Even though we had a Private Link configured for the server, we could still resolve a public IP address. After some research we found that specifically for Azure PostgreSQL, communication through both Private Link and normal public access are supported simultaneously. You could have a Private Link configured, but when you configure the server to allow public network access and add your IP address as a Firewall rule you are able to connect via public access. These particulars will be mentioned in the Microsoft documentation at https://docs.microsoft.com/, so always read the documentation before starting with private endpoints.