Service Endpoints – Virtual Networking

The identity of a virtual network can be provided to the Azure service by using service endpoints. Many services support virtual network access, and with the service endpoint enabled, you can access these services in a secure manner. The communication from your virtual network to the Azure service is done via the Microsoft backbone network. For example, you can have a virtual machine deployed to a virtual network, and you can also have a storage account. On the storage account firewall, you need to allow the communication from the virtual network that the VM belongs to. Using a service endpoint, the VM will be able to communicate with the storage service securely using its private IP address as the source IP address, as shown in Figure 3.3.

FIGURE 3.3 Understanding service endpoints

Sometimes your virtual network address spaces might be overlapping, and it’s difficult to identify the traffic just based on the IP addresses. Chances are that the traffic is originating from a virtual network that has the same address space as of the virtual network that is supposed to access the service. The service endpoint mitigates this issue by creating an identity for your virtual network and sharing it with the Azure services. All you need to do is to add a virtual network security rule, and your resources will stay secured. This rule completely eliminates the public Internet access to the resources where service endpoints are added and allows only traffic originated from the virtual network. The key point here is that service endpoints can be used for secure communications only from the Azure virtual network; on-premises to Azure services is not supported.

Supported Services

Adding a service endpoint to a virtual network is an effortless process and several services including Azure Cosmos DB, KeyVault, Service Bus, SQL, Storage Accounts, and Azure Active Directory are supported. Let’s understand the list of supported services.

• Azure Storage: This is supported in all Azure regions and is generally available. Using this endpoint, you can establish an optimal route to the Azure Storage service. You can associate up to 100 virtual network rules to each storage account.
• Azure SQL Database and Azure Synapse Analytics (formerly Azure Data Warehouse): Service endpoints can be used to communicate with the databases in Azure SQL Database or databases in Azure SQL Data Warehouse in a secure manner. These endpoints are added to the firewall of the database to enable access from the subnets. This is generally available in all Azure regions.
• Azure Database for PostgreSQL and MySQL servers: This enables you to communicate from your virtual network to PostgreSQL and MySQL servers deployed in Azure. Generally this is available in all Azure regions.
• Azure Cosmos DB: Using service endpoints, you can let the resources deployed in your virtual network communicate with the Cosmos DB. This is supported in all Azure regions.
• Azure Key Vault: This is available in all Azure regions. By enabling service endpoints, you can limit the communication to the key vault. Only requests from the allowed subnets are permitted to access the key vault; the rest of the requests will be denied.
• Azure Service Bus and Event Hubs: Service endpoints for Service Bus and Event Hub facilitates secure access to messaging capabilities from workloads such as virtual machines that are deployed in the virtual network.

 It may take up to 15 minutes for the service endpoints to come up after adding them to a service. Each service has its own documentation page stating the steps for enabling service endpoints.

When you are using service endpoints, the traffic will still hit the supported services on their public endpoints, and the source of the traffic will be a private IP from the virtual network. If you would like to access these services using their private IP addresses, then you should consider using a private link. In the next section, we will cover private links.