PaaS Bicep Azure Networking

Building Resilient Networks with Azure Networking Services Part 5: Implementing VNet Service Endpoints & Private Link Services

Resilient Networking in Azure - Private Link & Service Endpoints

Introduction

As organisations increasingly adopt cloud services, securing connectivity to Azure services becomes paramount. In many scenarios, public endpoints are not sufficient when sensitive data and workload integrity are involved. Azure offers two powerful capabilities to provide secure, private access to its services:

  • Private Link: This enables the connection of your Virtual Network directly with Azure services (or your own PaaS offerings) via a private endpoint. With Private Link, your traffic remains on the Microsoft backbone, ensuring that communication never traverses the public internet.

  • Service Endpoints: These extend your virtual network’s private address space to Azure service resources. They provide a straightforward way to secure your direct connectivity back to Azure while still using the native public endpoint of the service.

In this post, we compare these two approaches, discuss their differences and appropriate use cases, and provide hands-on examples—both using the Azure Portal and Bicep templates—to help you integrate your network with Azure services securely.

  • How It Works:
    Private Link provisions a private IP address in your virtual network. This private endpoint acts as a network interface, mapping to the Azure service resource (for example, an Azure Storage account). Traffic between your VNet and the service flows entirely over the Microsoft backbone.

  • Benefits:

    • Provides granular control and enhanced security by isolating the service endpoint within your VNet.
    • Supports scenarios where connectivity must bypass the public internet entirely, which may be a compliance requirement.

  • Use Cases:

    • When you need to consume services such as Azure Storage, SQL Database, or your own custom PaaS, without exposing them to the public internet.
    • When you require integration with on-premises networks over VPN/ExpressRoute with minimal exposure.

Service Endpoints

  • How It Works:
    Service endpoints extend your VNet’s identity to Azure services over optimized routes, but the service itself still retains its public endpoint. Rules are enforced on the service side to ensure that only traffic from your VNet (or subnets) is accepted.

  • Benefits:

    • Simpler to set up and manage in many situations.
    • Provides improved network performance using the Microsoft backbone, with minimal configuration.

  • Use Cases:

    • When you want to secure access to Azure services with a minimal footprint and configuration overhead.
    • Situations where direct exposure to the service’s public endpoint is acceptable provided that traffic is restricted based on VNet or subnet membership.

In the sections below, we provide example implementations using both the Azure Portal and Bicep.

Azure Portal Implementation

  1. Create a Private Endpoint:

    • Sign in to the Azure Portal and navigate to your Azure Storage Account.
    • Under the Settings section, select Private endpoint connections. Click + Private endpoint.
    • Provide a name (e.g., StoragePrivateEndpoint), select your subscription, resource group, and region.
    • Choose the Virtual Network and subnet where the endpoint should reside.
    • Select the target sub-resource (e.g., blob for a Storage Account).
    • Configure DNS integration if needed, and review + create the private endpoint.

  2. Post-Deployment Verification:

    • Once deployed, review that the Storage Account now has a private endpoint. Direct traffic from your VNet to the Storage Account now happens over that private link.

Enabling Service Endpoints for an Azure Storage Account

  1. Configure Service Endpoints in Your VNet:
    • Navigate to your Virtual Network in the Azure Portal.
    • Under Settings, select Subnets and then select the subnet to which you wish to add the service endpoint.
    • Click Service endpoints and then + Add.
    • Choose the service type (e.g., Microsoft.Storage) and save the configuration.
    • Optionally, configure firewall rules on the Storage Account to accept connections only from the specified virtual network/subnets.

Bicep Implementation

Below are two Bicep templates: one to deploy a private endpoint to secure access to an Azure Storage account, and another to enable service endpoints on a subnet.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

// Parameters for Private Endpoint
@description('Name of the existing Storage Account')
param storageAccountName string = 'mystorageacct'

@description('Name of the Private Endpoint')
param privateEndpointName string = '${storageAccountName}-pe'

@description('Location for all resources')
param location string = resourceGroup().location

@description('Name of the existing Virtual Network')
param vnetName string = 'MyVNet'

@description('Name of the existing Subnet')
param subnetName string = 'PrivateEndpointSubnet'

// Reference storage account (assumed to exist)
resource storage 'Microsoft.Storage/storageAccounts@2021-02-01' existing = {
  name: storageAccountName
}

// Reference existing virtual network and subnet
resource vnet 'Microsoft.Network/virtualNetworks@2021-05-01' existing = {
  name: vnetName
}

resource subnet 'Microsoft.Network/virtualNetworks/subnets@2021-05-01' existing = {
  parent: vnet
  name: subnetName
}

// Create Private Endpoint for the Storage Account (Blob Service)
resource privateEndpoint 'Microsoft.Network/privateEndpoints@2021-05-01' = {
  name: privateEndpointName
  location: location
  properties: {
    subnet: {
      id: subnet.id
    }
    privateLinkServiceConnections: [
      {
        name: '${storageAccountName}-connection'
        properties: {
          privateLinkServiceId: storage.id
          groupIds: [
            'blob'
          ]
        }
      }
    ]
  }
}

Deployment Steps:

  1. Save the template as privateEndpoint.bicep.

  2. Deploy using:

    1
2
3

    az deployment group create \
  --resource-group MyResourceGroup \
  --template-file privateEndpoint.bicep

Bicep Template for Service Endpoints 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// Parameters for enabling service endpoints on a subnet
@description('Name of the Virtual Network')
param vnetName string = 'MyVNet'

@description('Name of the Subnet')
param subnetName string = 'EndpointSubnet'

// Reference the virtual network
resource vnet 'Microsoft.Network/virtualNetworks@2021-05-01' existing = {
  name: vnetName
}

// Update the subnet to enable Service Endpoints (e.g., for Microsoft.Storage)
resource subnetUpdate 'Microsoft.Network/virtualNetworks/subnets@2021-05-01' = {
  parent: vnet
  name: subnetName
  properties: {
    serviceEndpoints: [
      {
        service: 'Microsoft.Storage'
      }
    ]
  }
}

Deployment Steps:

  1. Save this template as serviceEndpoints.bicep.

  2. Deploy using:

    1
2
3

    az deployment group create \
  --resource-group MyResourceGroup \
  --template-file serviceEndpoints.bicep

This template updates a subnet in your existing Virtual Network to enable service endpoints for Microsoft.Storage, allowing secure and optimized connectivity to the Storage Account’s public endpoint.

Conclusion

Integrating with Azure services securely is a critical component of a resilient network architecture. With Private Link, you ensure that traffic remains completely private and isolated within your Virtual Network, while service endpoints offer a simpler method to secure your access to Azure resources by extending your VNet’s reach. Both approaches offer distinct advantages depending on your security, performance, and compliance requirements.

By implementing these solutions using either the intuitive Azure Portal or through Infrastructure-as-Code with Bicep, you can enhance the security and reliability of your network integrations with Azure services.

Learn More