Introduction

When it comes to ensuring resources can communicate to each other privately, Azure provides two ways to enable this. The first being service endpoint and the second being a private endpoint. This post will look into the benefits of service and private endpoints, the differences between them, and what criterias we should be looking out for when choosing one or the other.

Traffic between services in Azure

When two Azure resources communicate with each other, unless otherwise specified or configured, they will use the internet to do domain resolution and send data via the public network. This might not be the most secure thing to do as data might get intercepted at one point.

Service endpoints

Service endpoints allow public Azure resources to connect to another Azure resource in a vnet using the Azure backbone. For example, let’s say there’s a SQL server hosted publicly, called SQL01 and an app service that needs to communicate with it called APP01 in VNET01. If we want to ensure that traffic between APP01 and SQL01 are done via the Microsoft backbone, we would need to attach a service endpoint to the VNET. When creating a service endpoint, SQL01 will be communicating with APP01 via the Microsoft backbone which should allow it to be slightly more private.

Private endpoints

Private endpoints are very similar to Service endpoints but have the added benefit of providing the public resource a private IP in the VNET which will allow all communication to be done using the private IP. This will ensure that traffic does not leave the VNET and communication are done using the private IP addresses. In the background, Azure creates a network interface attached to the vnet which would provide the private IP for the resource. Whilst this is more secure than using a service endpoint, it does come with a bit of a price to it. Service endpoints are generally free whereas this one fhas a cost attached to it with different tiers depending on the amount of inbound and outbound data.