This chapter dives deep into Azure Service Endpoints and Private Endpoints, two critical networking features for securing access to Azure PaaS services. You will learn the mechanisms, configuration, and when to use each. This topic is heavily tested on the AZ-104 exam, appearing in roughly 10-15% of networking questions, often in scenarios requiring secure access to Azure Storage or SQL Database. Mastery of these concepts is essential for designing secure and compliant Azure networks.
Jump to a section
Imagine a corporate office building in a secure campus. The building has two types of access for employees and visitors. Service Endpoints are like a dedicated employee entrance that is directly connected to the building's internal hallway, but the entrance is still on the public street—anyone on the street can see the door, but only employees with a badge can enter. This door is accessible from the public sidewalk, so traffic from the street can reach it, but the door only allows entry if the person has the right credentials. In contrast, Private Endpoints are like a private tunnel from the employee's home directly into the building's basement, completely bypassing the public street. No one on the street can see the tunnel entrance; it's entirely hidden. The tunnel is assigned a private IP address from the employee's home network, so the employee can access the building as if it were part of their own house. In Azure, Service Endpoints expose the service to your VNet over the Microsoft backbone but the service's endpoint remains a public IP. Private Endpoints give the service a private IP in your VNet, making it accessible only from within your network or peered networks, completely removing public internet exposure.
What Are Service Endpoints?
Service Endpoints extend your virtual network private address space and the identity of your VNet to Azure services over a direct connection. When you enable a service endpoint for a subnet, traffic from that subnet to the Azure service (e.g., Azure Storage, SQL Database) goes directly over the Microsoft Azure backbone network, not the public internet. This improves security and performance. The service endpoint does not assign a private IP to the service; instead, it uses the service's public IP address but routes traffic through the Microsoft backbone. The service sees the traffic as coming from the VNet's private IP address (via the endpoint), not the public IP of the VM.
How Service Endpoints Work Internally
When you enable a service endpoint for a subnet, Azure automatically adds a route to the subnet's route table. This route directs traffic destined to the service's public IP range to the Microsoft backbone. The source IP of the traffic is rewritten to the VNet's private IP (via NAT performed by Azure). The service then sees the request as originating from the VNet. This allows you to configure service-level firewall rules that restrict access to specific VNets. At the packet level, the source IP in the IP header is changed from the VM's private IP to the VNet's private IP? Actually, no: the source IP remains the VM's private IP, but the service endpoint ensures the traffic is routed through the Microsoft backbone and the service identifies the traffic as coming from the VNet. The service endpoint uses a feature called 'Virtual Network Service Endpoints' which leverages the Azure routing infrastructure to provide optimal routing and security.
Key Components and Defaults
Service endpoints are enabled at the subnet level. You must enable the endpoint for each service type (e.g., Microsoft.Storage, Microsoft.Sql).
No additional cost for using service endpoints within the same region. Cross-region traffic may incur charges.
Service endpoints support only Azure PaaS services. They do not support third-party services or services in other clouds.
The service endpoint does not change the public IP of the service. The service still has a public endpoint.
You can apply network security group (NSG) rules to the subnet to further restrict traffic.
For Azure Storage, you can configure firewalls and virtual networks to allow access only from specific VNets.
Service endpoints are not supported for all services. Check documentation for the list.
Configuration and Verification Commands
To enable a service endpoint on a subnet using Azure CLI:
az network vnet subnet update --resource-group MyRG --vnet-name MyVNet --name MySubnet --service-endpoints Microsoft.StorageTo verify the route table:
az network route-table list --resource-group MyRG --output tableTo check effective routes on a NIC:
az network nic show-effective-route-table --resource-group MyRG --name MyNICWhat Are Private Endpoints?
Private Endpoints bring the Azure service into your virtual network by creating a network interface with a private IP from your VNet. This effectively places the service on your network, making it accessible via private IP only. The service's public endpoint is not used. Traffic to the service stays entirely within the Microsoft network and never traverses the public internet. Private Endpoints use Azure Private Link, which is a technology that allows you to access Azure PaaS services over a private connection.
How Private Endpoints Work Internally
When you create a private endpoint, Azure deploys a network interface (NIC) in the specified subnet. This NIC gets a private IP address from the subnet's range. The private endpoint is associated with a private link service (e.g., Azure Storage account). DNS resolution is key: by default, Azure DNS zones are updated so that the service's FQDN resolves to the private IP address of the endpoint. For example, mystorageaccount.blob.core.windows.net will resolve to 10.0.0.4 instead of the public IP. This DNS resolution can be overridden with custom DNS servers. Traffic from a VM in the VNet to the storage account FQDN goes to the private IP, which routes through the Microsoft backbone to the storage service. The storage service sees the traffic as coming from the private IP of the endpoint.
Key Components and Defaults
Private Endpoints are created at the resource level (e.g., a specific storage account).
You must have a private link service to connect to. Azure PaaS services support Private Link.
The private endpoint is associated with a subnet. You can have multiple private endpoints in the same subnet.
DNS configuration is critical. Azure provides private DNS zones (e.g., privatelink.blob.core.windows.net) that you can link to your VNet.
Private endpoints incur additional costs based on the number of endpoints and data processed.
You can use network policies like NSGs on the subnet hosting the private endpoint, but NSGs are not supported on the private endpoint NIC itself.
Configuration and Verification Commands
To create a private endpoint using Azure CLI:
az network private-endpoint create --resource-group MyRG --name MyPE --location eastus --connection-name MyConnection --private-link-resource-id /subscriptions/.../providers/Microsoft.Storage/storageAccounts/mystorage --group-id blob --subnet /subscriptions/.../resourceGroups/MyRG/providers/Microsoft.Network/virtualNetworks/MyVNet/subnets/MySubnetTo verify DNS resolution:
nslookup mystorageaccount.blob.core.windows.netExpected output should show a private IP.
Interaction with Related Technologies
Azure DNS: Private Endpoints rely on private DNS zones for name resolution.
Network Security Groups (NSGs): Can be applied to the subnet where the private endpoint is deployed, but not directly to the endpoint NIC.
Azure Firewall: Can inspect traffic to private endpoints if you force-tunnel traffic through it.
VPN Gateway / ExpressRoute: Private endpoints are accessible from on-premises via VPN or ExpressRoute if DNS resolution is configured correctly.
Service Endpoints vs Private Endpoints: They are not mutually exclusive but serve different purposes. Service endpoints are simpler and free, but they do not remove public exposure. Private endpoints provide complete isolation but at a cost.
Identify Service to Secure
First, determine which Azure PaaS service you need to secure. Common examples are Azure Storage (blob, file, table, queue) and Azure SQL Database. For service endpoints, you need to know the service type (e.g., Microsoft.Storage). For private endpoints, you need the resource ID of the specific service instance. This step involves planning which resources will be accessed and from which VNets.
Enable Service Endpoint on Subnet
Navigate to the virtual network subnet in the Azure portal or use CLI/PowerShell. Enable the service endpoint for the desired service type. This adds a route to the subnet's route table that directs traffic to the service's public IP range via the Microsoft backbone. The route is automatically managed by Azure. No manual route configuration is needed. After enabling, any VM in the subnet can access the service directly over the backbone.
Configure Service Firewall
For the Azure service (e.g., storage account), configure the firewall to allow access only from the specific VNet/subnet. In the storage account's 'Firewalls and virtual networks' blade, add the VNet and subnet. This ensures that only traffic originating from that subnet is allowed. The service sees the source IP as the VNet's private IP due to the service endpoint. Without this step, the service endpoint is not leveraged for access control.
Create Private Endpoint Resource
In the Azure portal, search for 'Private Endpoint' and create a new resource. Specify the name, region, and resource group. In the 'Resource' tab, select the target service (e.g., 'Microsoft.Storage/storageAccounts') and the specific resource (e.g., a storage account). Choose the target sub-resource (e.g., 'blob'). In the 'Configuration' tab, select the VNet and subnet where the private endpoint NIC will be created. Optionally, integrate with a private DNS zone.
Configure DNS for Private Endpoint
To ensure that the service's FQDN resolves to the private IP, you need to configure DNS. Azure provides private DNS zones (e.g., privatelink.blob.core.windows.net). Link this zone to your VNet. Alternatively, you can manually add A records in your custom DNS server. Without proper DNS configuration, clients will resolve the public IP and bypass the private endpoint. Verify with nslookup or dig.
Scenario 1: Secure Access to Azure Storage from a Virtual Network
A financial services company needs to store sensitive transaction logs in Azure Blob Storage. Their application runs on VMs in a VNet. They want to ensure that all traffic to storage stays within the Azure backbone and that the storage account is not accessible from the public internet. They implement Service Endpoints for Microsoft.Storage on the subnet hosting the VMs. They then configure the storage account firewall to allow access only from that VNet. This solution is cost-effective and easy to manage. However, they later realize that they also need to access the storage from an on-premises data center via ExpressRoute. Service Endpoints do not support on-premises access because the source IP seen by the service is the VNet's private IP, but the traffic from on-premises does not originate from the VNet. They then deploy a Private Endpoint for the storage account, which allows on-premises traffic to reach the storage via the private IP (with proper DNS configuration). This hybrid approach solves both requirements.
Scenario 2: Isolating a SQL Database from Public Internet
A healthcare organization must comply with HIPAA regulations, requiring that their Azure SQL Database is not accessible from the public internet. They deploy a Private Endpoint for the SQL server in a subnet within their VNet. They disable public network access on the SQL server. Now, only resources within the VNet (or connected via VPN/ExpressRoute) can access the database. They also configure private DNS zones so that the SQL server FQDN resolves to the private IP. This setup ensures complete isolation. However, they must be careful with DNS caching: if a client previously resolved the public IP, it may continue to use the cached public IP. They flush DNS or use TTL settings to mitigate this.
Common Pitfalls in Production
Misconfigured DNS: The most common issue. If private DNS zones are not linked to the VNet, clients will resolve the public IP and bypass the private endpoint. Always verify with nslookup.
Overlapping IP Addresses: When using private endpoints, the subnet used for the endpoint must have available IP addresses. If the subnet is full, the endpoint creation fails.
Service Endpoint with Firewall Rules: If you enable a service endpoint but forget to configure the service firewall, the endpoint is not used for access control; the service remains publicly accessible. Always add the VNet to the service's firewall.
Cross-Region Traffic: Service endpoints are optimized for same-region traffic. Cross-region traffic may still go over the internet or incur higher latency. Private endpoints can be used across regions but with added cost.
What AZ-104 Tests
This topic falls under objective 'Configure and manage virtual networking' (4.1) and specifically 'Implement service endpoints and private endpoints'. The exam expects you to understand the differences, use cases, and configuration steps. You may be asked to choose between service endpoints and private endpoints for a given scenario. Common scenario: 'A company wants to ensure that traffic to Azure Storage from a VNet does not traverse the public internet.' The answer is either service endpoint or private endpoint, but the question may include constraints like cost or on-premises access.
Common Wrong Answers and Why
'Service endpoints remove the public endpoint': Wrong. Service endpoints do not remove the public endpoint; they only provide a direct route. The service still has a public IP. Private endpoints remove the public endpoint (if you disable public network access).
'Private endpoints are free': Wrong. Private endpoints incur costs for the endpoint and data processing. Service endpoints are free within the same region.
'Service endpoints require a VPN gateway': Wrong. Service endpoints work directly over the Azure backbone without any gateway.
'Private endpoints can be used with any Azure service': Wrong. Only services that support Azure Private Link can use private endpoints. Check documentation.
Key Numbers and Terms
Service endpoint: enabled at subnet level, supports multiple services, no additional cost.
Private endpoint: created as a resource, uses private IP, supports Private Link, incurs cost.
DNS: private endpoint relies on private DNS zones (privatelink.*).
Service endpoint: uses service's public IP but routes over backbone.
Edge Cases Tested
Cross-region access: Service endpoints are not recommended for cross-region; private endpoints can be used but with extra cost.
On-premises access: Service endpoints do not support on-premises; private endpoints do via VPN/ExpressRoute with proper DNS.
Multiple subnets: Each subnet must have the service endpoint enabled individually.
Multiple private endpoints: You can have multiple private endpoints for different services in the same subnet.
How to Eliminate Wrong Answers
If the question mentions 'remove public internet exposure', private endpoint is likely correct. If it mentions 'cost-effective' and 'within same region', service endpoint is likely. If it mentions 'on-premises connectivity', private endpoint is needed. Look for keywords like 'private IP', 'public endpoint', 'cost', 'VPN', 'ExpressRoute'.
Service endpoints are free and easy to configure at the subnet level.
Private endpoints provide complete isolation from public internet but cost money.
Service endpoints do not remove the public endpoint; private endpoints can if you disable public access.
DNS configuration is critical for private endpoints; use private DNS zones.
Service endpoints work only within the same region optimally; private endpoints work across regions.
Private endpoints require Azure Private Link support from the target service.
You can use both service and private endpoints for different services or different access patterns.
Always verify DNS resolution when troubleshooting private endpoint connectivity.
These come up on the exam all the time. Here's how to tell them apart.
Service Endpoints
Enabled at subnet level
No additional cost (same region)
Service retains public IP
Traffic routed over Azure backbone
Supports on-premises only via VPN/ExpressRoute with additional routing
Private Endpoints
Created as a separate resource
Incur costs for endpoint and data
Service gets a private IP in your VNet
Traffic remains private within Microsoft network
Supports on-premises via VPN/ExpressRoute with proper DNS
Mistake
Service endpoints assign a private IP to the Azure service.
Correct
Service endpoints do not assign a private IP; they route traffic over the Microsoft backbone but the service still uses its public IP. Private endpoints assign a private IP.
Mistake
Service endpoints eliminate the need for firewall rules on the service.
Correct
Service endpoints enable you to restrict access to your VNet via service firewall rules, but you must still configure those rules. Without them, the service remains publicly accessible.
Mistake
Private endpoints are only for Azure PaaS services.
Correct
Private endpoints can connect to any service that supports Azure Private Link, including third-party SaaS services and custom services behind a Private Link service.
Mistake
You can use NSGs on the private endpoint NIC directly.
Correct
You cannot apply NSGs directly to the private endpoint NIC. NSGs can be applied to the subnet where the endpoint is deployed, but they affect all resources in that subnet.
Mistake
Service endpoints and private endpoints are mutually exclusive.
Correct
They can coexist on the same subnet and even for the same service, but they serve different purposes. You might use both for different access scenarios.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, service endpoints are designed for traffic originating from a VNet. On-premises traffic does not come from a VNet, so it cannot use a service endpoint. To access Azure Storage from on-premises securely, use a private endpoint with a VPN or ExpressRoute connection.
No, service endpoints do not require DNS changes. The service's FQDN still resolves to its public IP. The endpoint only affects routing, not DNS resolution.
Yes, you can have both. For example, you might use a service endpoint for VMs in one subnet and a private endpoint for on-premises access. However, be careful with DNS: if you use private DNS, it will override public DNS, potentially breaking service endpoint traffic if not configured correctly.
By default, Azure creates a private DNS zone (e.g., privatelink.blob.core.windows.net) and links it to the VNet. The FQDN of the service (e.g., mystorageaccount.blob.core.windows.net) resolves to the private IP of the endpoint. If you use custom DNS, you must manually add the A record.
No, only a subset of Azure PaaS services support service endpoints. Examples include Azure Storage, Azure SQL Database, Azure Cosmos DB, Azure Key Vault, and Azure Service Bus. Check the latest documentation for the full list.
NSGs can be applied to the subnet where the private endpoint is deployed. However, NSGs are not supported on the private endpoint NIC itself. Traffic to the private endpoint is subject to the subnet's NSG rules.
If you disable public network access, the service becomes accessible only via private endpoints. Any traffic coming from the public internet (including service endpoint traffic) is blocked. This is a common configuration for complete isolation.
You've just covered Service Endpoints vs Private Endpoints — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?