Securely connecting to Azure resources is an important topic. Azure is a public cloud offering, meaning you connect to its services over the public Internet. However, you may not want your application traffic connecting over the public Internet. Azure networking provides several different methods for securely connecting to resources. In this article, you will learn about two approaches: Azure private endpoint and service endpoint.
What is a virtual network?
A virtual network (VNet) is a private network in your Azure tenant. VNets enable different Azure resources (primarily virtual machines) to communicate with each other, the Internet, and potentially on-premises networks.
VNets use RFC 1918 IP address ranges, much like your on-premises networks. If you plan on connecting to your on-premises networks in a hybrid scenario, these IP address ranges cannot overlap. You can connect different Azure VNets using peering so resources in each network can communicate with each other. You also define subnets in each VNet, which are portions of the virtual network’s address space divided into smaller segments.
Virtual machines have one or more network interface cards (NICs) that exist in the same region as the virtual network. You assign an IP address (either statically or dynamically) from a subnet in the virtual network. This action allows the virtual machine to communicate with other resources in the virtual network (and any peered network).
What is a private endpoint?
While resources like virtual machines have a presence in a virtual network through virtual NICs, other services like storage account services, databases, and key vaults do not. If you have a virtual machine resource accessing these services, those VMs connect using the service’s public IP addresses.
However, you can bring these services into your virtual network using a private endpoint. A private endpoint is a virtual network interface that connects to the Azure service. This network interface uses a dynamically assigned private IP address from the virtual network address range. The network interface resource keeps the same private IP address for the entire lifecycle of the private endpoint.
The private endpoint allows a network resource, like a virtual machine, to access the PaaS service via the private IP address. The connection to the service is then private and secured by Azure Private Link.
Private Endpoint example
The image below shows the architectural relationship between a private endpoint and a virtual network. There is a virtual network using the address range 10.10.0.0/16. Inside this virtual network are two subnets, SubnetA (10.10.5.0/24) and SubnetB (10.10.6.0/24).
One or more virtual machines reside in SubnetA. A storage account has a private endpoint with an IP address of 10.10.6.5 inside SubnetB. The virtual machines inside SubnetA access the storage account through the storage account’s private endpoint IP address located in SubnetB.
Resources in other networks can access the storage account through the private endpoint IP address. On the left, you can see peered virtual networks or an on-premises network in a hybrid scenario using a VPN or Express Route.
For most resources, you can create and manage private endpoints from within the target resource. For example, navigate to an existing storage account, then go to Security + networking > Networking. From here, select the Private endpoint connections tab. Here you can create new or view existing private endpoints.
The private endpoint resource also generates a network interface resource. This network interface is a separate resource, just like you would see with a virtual machine. The private endpoint’s network interface retrieves an available IP address from the assigned subnet. You can view the IP address configuration by going to the network interface and selecting Settings > IP configurations. You can view the virtual network, subnet, and private IP address.
Note that while the private IP address is dynamic, this IP address will not change until the resource is deleted.
DNS configuration
Before deploying a private endpoint, you connect to the Azure resource using the publicly available endpoint. This public endpoint uses an Internet-resolvable domain name where you do not need to manage the DNS naming.
When using a private endpoint, you need to connect to the same Azure service but use the private endpoint IP address. The intimate endpoint connection requires separate DNS settings to resolve the private IP address to the resource name.
The first option is to create a forwarder in your existing DNS infrastructure. The private endpoint already contains the resource’s FQDN and private IP address, so you need to create an A record for clients to resolve the FQDN to the private IP address.
Another option is to use private DNS zones from Azure. Private DNS zones provide domain name resolution within a virtual network without a custom DNS solution. You link the private DNS zones to each virtual network to provide DNS services to that network.
Private DNS zones provide separate DNS zone names for each Azure service. For example, if you configured a private DNS zone for the storage account blob service in the previous image, the DNS zones name is privatelink.blob.core.windows.net. Check out the Microsoft documentation here to see more of the private DNS zone names for all Azure services.
If you need to query an Azure private DNS zone from an on-premises environment, another option is the Azure DNS Private Resolver. You can create conditional forwards in your on-premises network to send DNS queries to the private resolver in Azure. This solution is currently in preview, and you can read more in this announcement from Microsoft.
Private Endpoint Notes
With a basic understanding of private endpoints, here are some additional notes and considerations regarding private endpoints.
- Azure deploys private endpoints to the same region and subscription as the virtual network.
- You can create multiple private endpoints on the same or different subnets within the same virtual network.
- Clients initiate connections to the private endpoint and related service, but the service cannot establish a connection to the client. Connections are single direction only.
- Once you establish a private endpoint for a resource instance, you can disable public access to the resource as an additional security measure.
What is a service endpoint?
Service endpoints provide a secure, direct connection to Azure services. This direct connection uses the Azure backbone network, which is a global network supporting Microsoft’s business- and consumer-critical services.
While private endpoints are associated with a specific instance of an Azure service (like a storage account), service endpoints apply to all instances of a target service, not just ones you create. Service endpoints direct VNet traffic off the public Internet and to the Azure backbone network. You enable service endpoints for each Azure service on a subnet in a virtual network.
The compute resources on your private virtual network use their private IP address as the source address when connecting to the Azure service. However, the compute resources connect to the public IP addresses of the Azure services. This public connection is different from a private endpoint, where the compute resources connect to a private IP address associated with a specific instance of the Azure service.
You no longer need to reserve public IP addresses on outbound firewalls when you enable service endpoints on a subnet. Without service endpoints, a compute resource, like a virtual machine, uses the public IP address on the firewall as the source IP address. With the service endpoint enabled, the source IP address switches to the private IP address of the virtual machine.
Review the image below representing service endpoints in action. In this example, you have enabled a service endpoint for the Microsoft.SQL service on SubnetA. A virtual machine in SubnetA uses its private IP address to access a SQL server hosting several databases. The virtual machine connects using the public IP addresses associated with the Microsoft.SQL service.
Notice that Subnet B does not have service endpoints enabled for its subnet for the Microsoft.SQL service. Compute resources in this subnet use the public IP address for the virtual network to connect to the public IP address of the Azure service.
Enabling Service Endpoints
You enable service endpoints on a per-subnet basis, and subnets support more than one type of service endpoint enablement. Here is an example of a subnet with the Microsoft.Sql service enabled.
Service Endpoint policies
As previously discussed, service endpoints apply to all instances of the Azure resource, not just the ones you create. If you want to limit virtual network traffic to specific instances or regions of a resource, you need a service endpoint policy. Service endpoint policies enable outbound virtual network traffic filtering to service endpoint-enabled resources.
Service endpoint policies are a separate resource, and you assign policies at the subnet level. The policy contains definitions that specify an existing Azure resource. Service endpoints currently only apply to Azure Storage accounts.
Service Endpoint notes
With a basic understanding of service endpoints, here are some additional notes and considerations regarding service endpoints.
- Service endpoints work with any compute resource instance running within the enabled subnet.
- You can enable multiple service endpoints on a subnet.
- You can limit access to specific regions of a service endpoint-enabled service with service tags.
- Does not require custom DNS changes like private endpoints.
Summary
While private endpoints and service endpoints provide a more secure connection to Azure resources, each has different use cases. Private endpoints apply to a single instance of a resource, while service endpoints apply to all service instances. With private endpoints, clients connect to a private IP address linked to the resource. With service endpoints, clients still connect to the public IP address of the service. Private endpoints require custom DNS changes while service endpoints do not.
To see more comparisons between these two solutions, check out Compare Private Endpoints and Service Endpoints from Microsoft Docs. Which service do you use and why? Leave a comment down below!
Enjoyed this article? Check our more of my Azure content here!
