You’ve successfully migrated your ERP system’s application and database servers to Azure VMs. Now, you’re looking to optimize costs and administration by leveraging Azure Platform as a Service (PaaS) offerings, particularly for storing large engineering diagrams. Security is paramount, as these diagrams contain proprietary information that must be protected from unauthorized access and restricted to specific systems. This post explores how virtual network service endpoints can help you achieve this.

Understanding Virtual Network Service Endpoints

Virtual network service endpoints extend your private Azure address space, providing a direct connection to supported Azure services. They enable you to secure your Azure resources by restricting access to only your virtual network, ensuring that service traffic remains on the Azure backbone and never traverses the public internet.

By default, many Azure services, including PaaS offerings like Azure SQL Database and Azure Storage, are designed for direct internet access, sporting public IP addresses. This inherent exposure creates a potential attack surface. Service endpoints address this by connecting specific PaaS services directly to your private virtual network, making them appear as if they reside within the same network. You then access these services using your private IP addresses. Importantly, adding service endpoints doesn’t remove the public endpoint; it simply redirects traffic.

Azure service endpoints are available for many services, such as:

• Azure Storage
• Azure SQL Database
• Azure Cosmos DB
• Azure Key Vault
• Azure Service Bus
• Azure Data Lake

Even for services like SQL Database, which require IP addresses to be added to its firewall for access, service endpoints are still valuable. They enhance security by restricting access to specific virtual networks, further isolating the database and reducing the attack surface.

How service endpoints work

Enabling a service endpoint involves two key steps:

1. Disable public access to the service: This is often done through firewall rules or network access restrictions.
2. Add the service endpoint to your virtual network: This establishes the private connection.

Once enabled, the service endpoint restricts traffic flow, allowing your Azure VMs to access the service directly via your private address space. Devices on public networks will be unable to access the service. Checking the effective routes on a deployed VM’s network interface card (NIC) will reveal the service endpoint as the “Next Hop Type.”

Example Route Table (Before Service Endpoint):

Example Route Table (After Adding Service Endpoints):

As you can see, all traffic for the specified service is now routed to the VirtualNetworkServiceEndpoint, keeping it within the Azure network.

Service endpoints and hybrid networks

By default, service resources secured with virtual network service endpoints are not accessible from on-premises networks. To enable access from on-premises, you’ll need to use Network Address Translation (NAT) IPs. If you use ExpressRoute for on-premises connectivity, you must identify the NAT IP addresses used by ExpressRoute (each circuit typically uses two) and add them to the IP firewall configuration of the Azure service resource (e.g., Azure Storage).

(Diagram showing on-premises access to Azure Storage via service endpoint and firewall configuration would be very helpful here)

This configuration allows on-premises devices to securely access Azure Storage resources via the ExpressRoute connection, while still leveraging the security benefits of the service endpoint. By combining service endpoints with proper firewall configurations, you can create a robust and secure hybrid cloud environment for your critical ERP data.

---