This chapter covers two critical network security mechanisms in Azure: Service Endpoints and Private Endpoints. These technologies control how Azure PaaS services (like Storage, SQL Database, and Key Vault) are accessed from your virtual networks. On the AZ-500 exam, approximately 10-15% of questions touch on network security controls, with a significant portion focusing on endpoint security. Understanding the differences, use cases, and security implications of Service Endpoints versus Private Endpoints is essential for designing secure Azure architectures and passing the exam.
Jump to a section
Imagine your company needs to access a secure warehouse (an Azure PaaS service). Service Endpoints are like giving your employees a toll-free number that routes their call through the public phone network but ensures the call is billed to your office. The warehouse sees the caller ID as your office's main number (your VNet's public IP), but the call still travels over the public phone lines. Anyone with the toll-free number could potentially reach the warehouse, though billing restricts access. Private Endpoints are like installing a direct private fiber line from your office to the warehouse. The warehouse now has an extension that is only reachable from your office's internal phone system (your VNet). No one outside your office can call that extension. The call never touches the public phone network. The warehouse receives the call as if it came from an internal desk (a private IP in your VNet). This eliminates exposure to the public network entirely. In cloud terms, Service Endpoints expose the service to your VNet via the service's public endpoint but with source NAT, while Private Endpoints place the service directly into your VNet with a private IP.
What Are Service Endpoints and Private Endpoints?
Azure Service Endpoints and Private Endpoints are two distinct technologies that secure access to Azure PaaS services from your virtual networks. Both aim to restrict network traffic to trusted sources, but they operate at different layers of the OSI model and provide different security guarantees.
Service Endpoints extend your virtual network identity to Azure services over the Azure backbone network. By enabling a service endpoint for a specific service (e.g., Microsoft.Storage) on a subnet, traffic from that subnet to the service is routed directly over the Azure backbone network instead of the public internet. The service sees the traffic as coming from the subnet's virtual network (VNet) identity, allowing you to configure service-level firewall rules that allow access only from specific VNets.
Private Endpoints use Azure Private Link to bring the service into your virtual network by assigning it a private IP address from your VNet address space. Traffic from your VNet to the service traverses the Microsoft backbone network entirely, never leaving the Azure network. The service is effectively an extension of your VNet, accessible only via private IP addresses.
How Service Endpoints Work Internally
When you enable a service endpoint on a subnet, Azure performs the following:
The subnet's route table is updated with a system route for the service's public IP prefix (e.g., 13.71.0.0/20 for Azure Storage in a region) pointing to the Microsoft.AzureServiceEndpoint next hop type.
Outbound traffic from the subnet to the service's public endpoints is redirected over the Azure backbone network.
The service sees the source IP address as the VNet's public IP address (or a public IP from the service's prefix) after NAT, NOT the private IP of the VM. However, the service can identify the VNet and subnet via the service endpoint's metadata.
Service-level firewalls (e.g., Storage firewall) can be configured to allow access only from specific VNets and subnets using the VNet ID and subnet ID, not IP addresses.
Key point: The traffic still reaches the service's public endpoint. The service does not have a private IP in your VNet. The security relies on the service's firewall rules to block traffic that does not come from an authorized VNet.
How Private Endpoints Work Internally
Private Endpoints use Azure Private Link to create a network interface (NIC) in your VNet with a private IP from your VNet's address space. The service is mapped to this private IP via a Private Link service (for custom services) or a Private Endpoint (for PaaS services). - Traffic from your VNet to the private IP is resolved via DNS: Azure Private DNS zones (e.g., privatelink.blob.core.windows.net) map the service's public FQDN to the private IP. - The traffic is encapsulated and sent over the Microsoft backbone to the service, which sees the source IP as the private IP of the originating VM (or the NAT IP if using a VPN/ExpressRoute). - The service can be configured to deny all public traffic, ensuring that only traffic from your VNet (or peered VNets) can reach it.
Private Endpoints operate at Layer 4 (TCP/UDP) and support multiple services including Storage, SQL Database, Cosmos DB, and more.
Key Components and Defaults
Service Endpoints: - Enabled per subnet per service type (e.g., Microsoft.Storage, Microsoft.Sql). - No additional cost. - Supported for services: Azure Storage, Azure SQL Database, Azure Cosmos DB, Azure Key Vault, Azure Service Bus, Azure Event Hubs, and more. - Default: Not enabled. Must be explicitly enabled on each subnet. - Service-level firewall rules use the VNet ID and subnet ID, not IP addresses.
Private Endpoints: - Created as a separate Azure resource with a NIC in a subnet. - Requires a Private DNS zone or custom DNS configuration to resolve the service FQDN to the private IP. - Costs: Private Endpoint itself is free, but data processing charges apply for traffic through Private Link. - Supported for all Azure PaaS services that support Private Link, plus custom services via Private Link service. - Default: Not created. Must be explicitly provisioned. - Can be associated with a private DNS zone to automatically update DNS records.
Configuration and Verification
Enable Service Endpoint on a subnet (Azure CLI):
az network vnet subnet update \
--resource-group MyRG \
--vnet-name MyVNet \
--name MySubnet \
--service-endpoints Microsoft.StorageVerify Service Endpoint route:
az network route-table list \
--resource-group MyRG \
--query "[?contains(subnets[].id, 'MySubnet')]"Create a Private Endpoint (Azure CLI):
az network private-endpoint create \
--resource-group MyRG \
--name MyPE \
--location eastus \
--vnet-name MyVNet \
--subnet MySubnet \
--private-connection-resource-id /subscriptions/.../providers/Microsoft.Storage/storageAccounts/mystorageaccount \
--group-id blob \
--connection-name MyConnectionVerify Private Endpoint DNS:
az network private-dns zone list --resource-group MyRG
az network private-dns record-set a list \
--resource-group MyRG \
--zone-name privatelink.blob.core.windows.netInteraction with Related Technologies
Network Security Groups (NSGs): Service Endpoint traffic is subject to NSG rules on the subnet. Private Endpoint traffic is also subject to NSG rules, but the Private Endpoint NIC itself cannot have NSGs applied.
Azure Firewall: Can inspect traffic to Service Endpoints if forced tunneling is configured. Private Endpoint traffic bypasses Azure Firewall unless explicitly routed.
VPN/ExpressRoute: Both technologies work with on-premises connectivity. For Private Endpoints, on-premises traffic must resolve the private IP via DNS or use a private DNS zone.
Azure DNS: Private Endpoints require DNS resolution to the private IP. Service Endpoints do not change DNS resolution.
Security Implications
Service Endpoints expose the service to the risk of data exfiltration if the service firewall is misconfigured. Since the service retains its public endpoint, any compromise of the service could allow data to be sent to unauthorized destinations. Private Endpoints eliminate the public endpoint entirely, reducing the attack surface. However, Private Endpoints require careful DNS management to prevent DNS spoofing.
Exam-Relevant Details
Service Endpoints are not supported for all Azure services; check the official list.
Private Endpoints support both inbound and outbound scenarios (via Private Link service for custom services).
Service Endpoints can be used with Azure SQL Database to restrict access to a VNet, but SQL Database still has a public endpoint. Private Endpoints for SQL Database remove the public endpoint.
Both can be used together? Yes, but it is not recommended because it creates overlapping security controls. Typically, choose one or the other.
For Storage accounts, Service Endpoints allow access from a VNet without exposing the storage to the internet. Private Endpoints provide the same but with a private IP.
The exam often tests the difference in terms of network path and source IP visibility.
Summary of Differences
| Feature | Service Endpoint | Private Endpoint | |---------|----------------|-----------------| | Network path | Azure backbone, but to public endpoint | Azure backbone, to private IP in VNet | | Source IP seen by service | VNet's public IP (NAT) | Private IP from VNet | | Service firewall rule | Based on VNet ID/subnet ID | Based on private IP address | | Public endpoint | Still exists | Can be disabled | | Data exfiltration risk | Higher (public endpoint) | Lower (no public endpoint) | | Cost | Free | Data processing charges | | DNS resolution | Unchanged | Must use private DNS zone |
Enable Service Endpoint on Subnet
Navigate to the subnet in the Azure portal, select 'Service Endpoints', and add the desired service (e.g., Microsoft.Storage). Azure automatically updates the subnet's route table with a system route for the service's IP prefixes. This route has a next hop type of 'Microsoft.AzureServiceEndpoint' and a priority lower than default routes. Traffic to the service's public IPs is now redirected over the Azure backbone. The subnet's effective routes will show this new route. At the packet level, the source IP is still the VM's public IP (or a public IP from the service's prefix after SNAT), but the service can identify the VNet via metadata. The service firewall must be configured to allow access from the VNet/subnet. Misconfiguration here is a common exam trap: enabling the endpoint alone does not secure access; you must also configure the service firewall.
Configure Service Firewall to Allow VNet
For an Azure Storage account, go to 'Firewalls and virtual networks', select 'Selected networks', and add the VNet and subnet under 'Virtual networks'. This creates a rule that allows traffic from that specific VNet/subnet. The rule is based on the VNet resource ID, not IP addresses. Traffic from other sources (including other VNets) is blocked unless explicitly allowed. This step is critical: without it, the service endpoint is ineffective. The exam often presents a scenario where a service endpoint is enabled but connectivity fails because the service firewall was not updated. The firewall rule can also allow specific public IPs, but for VNet access, you must use the VNet rule.
Create Private Endpoint Resource
In the Azure portal, go to 'Private Endpoints' and create a new resource. Specify the name, region (must match the VNet region), and the VNet/subnet where the private IP will be allocated. Then select the target resource (e.g., a storage account) and the sub-resource (e.g., 'blob'). This creates a network interface in the subnet with a private IP from the subnet's address range. The private endpoint is associated with a Private Link service on the target resource. The target resource's public endpoint remains accessible unless you disable it. The private endpoint NIC is automatically assigned a private IP from the subnet. You can also configure a static private IP if needed. The creation takes a few seconds.
Configure Private DNS Zone
To resolve the service's public FQDN (e.g., mystorageaccount.blob.core.windows.net) to the private IP, you need a Private DNS zone (e.g., privatelink.blob.core.windows.net). When creating the private endpoint, Azure can automatically create and link a private DNS zone to the VNet. Alternatively, you can manually create the zone and add an A record mapping the storage account's FQDN to the private IP. The zone must be linked to the VNet (or peered VNets) for DNS resolution to work. Without this, clients in the VNet will resolve the public IP and traffic will not use the private endpoint. The exam loves to test this: if DNS is not configured, traffic goes over the internet even with a private endpoint.
Disable Public Access (Optional)
For maximum security, you can disable public network access on the target resource. For a storage account, set 'Public network access' to 'Disabled'. This ensures that only traffic from private endpoints (or trusted Azure services) can reach the resource. Any attempt to access the public endpoint will be denied. This step is optional but recommended for data exfiltration prevention. The exam may ask: 'How do you ensure no internet traffic can reach the storage account?' The answer is to disable public access after configuring private endpoints. Note that some Azure services (like Azure SQL Database) allow you to deny public access while keeping the private endpoint active.
Enterprise Scenario 1: Secure Storage for Financial Data
A financial services company uses Azure Storage to store sensitive transaction logs. They need to ensure that no storage data ever traverses the public internet. They deploy Private Endpoints for each storage account (blob, file, queue, table) in their production VNet. Each storage account gets a private IP from the VNet's address space. They configure a private DNS zone (privatelink.blob.core.windows.net) linked to the VNet so that applications resolve the storage FQDN to the private IP. They also disable public network access on the storage accounts. To allow on-premises applications to access storage, they extend the private DNS zone to their on-premises DNS servers via conditional forwarding. Performance is excellent because traffic stays within the Microsoft backbone. Common issues: forgetting to link the private DNS zone to all peered VNets, causing resolution failures. Also, if an application uses a storage account's secondary endpoint (e.g., mystorageaccount-secondary.blob.core.windows.net), a separate private endpoint and DNS record are needed.
Scenario 2: Multi-Tier Web App with Service Endpoints
A SaaS company runs a multi-tier web application on Azure VMs. The web tier needs to access an Azure SQL Database. They enable a Service Endpoint for Microsoft.Sql on the web tier subnet. They then configure the SQL Database firewall to allow access only from that VNet/subnet. This ensures that SQL traffic from the web tier stays on the Azure backbone and does not go over the internet. However, the SQL Database still has a public endpoint. To further secure it, they also restrict public IP access to only their office public IPs for management. The downside: if the web tier VMs are compromised, an attacker could still potentially exfiltrate data to the SQL Database's public endpoint if they can bypass the firewall (e.g., by spoofing the VNet identity). This is a known limitation of Service Endpoints. Scaling: as the application grows, they add more subnets and enable service endpoints on each. They must update the SQL firewall rules for each new subnet. Misconfiguration: a common mistake is enabling the service endpoint but forgetting to add the subnet to the SQL firewall, causing connectivity failures.
Scenario 3: Hybrid Cloud with Private Link
A healthcare organization uses Azure Key Vault to store encryption keys. They have a hybrid environment with on-premises servers that need to access Key Vault. They deploy a Private Endpoint for Key Vault in a hub VNet connected to on-premises via ExpressRoute. They create a private DNS zone (privatelink.vaultcore.azure.net) and link it to the hub VNet. On-premises servers resolve the Key Vault FQDN via the ExpressRoute-connected DNS servers. This ensures that key access never traverses the internet. They also disable public access on Key Vault. Performance: latency is minimal. Issues: if the private DNS zone is not linked to spoke VNets, applications in spoke VNets cannot resolve the private IP. Also, if the on-premises DNS does not forward the privatelink zone correctly, traffic goes to the public endpoint and is denied.
What AZ-500 Tests on This Topic
AZ-500 objective 3.3: 'Implement network security' includes configuring and securing access to PaaS services. Specific sub-objectives: - 'Configure virtual network service endpoints' (3.3.2) - 'Configure private endpoints' (3.3.3)
The exam focuses on:
The difference in network path: Service Endpoints route traffic over the Azure backbone but still to the public endpoint. Private Endpoints route traffic to a private IP.
The source IP seen by the service: Service Endpoints show the VNet's public IP (after SNAT); Private Endpoints show the private IP of the client.
DNS requirements: Private Endpoints require private DNS zones; Service Endpoints do not change DNS.
Security: Private Endpoints can disable public access; Service Endpoints cannot.
Cost: Service Endpoints are free; Private Endpoints incur data processing charges.
Common Wrong Answers and Why
'Service Endpoints provide a private IP for the service.' This is false. Service Endpoints do not assign a private IP; they only route traffic over the backbone. The service still has a public endpoint. Candidates confuse 'private network path' with 'private IP'.
'Private Endpoints require a VPN or ExpressRoute.' False. Private Endpoints work within Azure VNets and can be accessed from on-premises via VPN/ExpressRoute, but they do not require them. The private IP is accessible from any connected network with proper DNS.
'Service Endpoints eliminate the public endpoint.' False. The public endpoint remains; only the firewall restricts access. Candidates think 'service endpoint' means the service is no longer public.
'You can use both Service Endpoints and Private Endpoints on the same subnet for the same service.' Technically possible but not recommended. The exam may test that they are mutually exclusive for a given service on a subnet? Actually, they can coexist, but the private endpoint takes precedence for DNS-resolved traffic. The exam likely expects you to choose one over the other.
Specific Numbers and Terms
Service Endpoint next hop type: 'Microsoft.AzureServiceEndpoint'
Private DNS zone naming: 'privatelink.<service>.azure.com' (e.g., privatelink.blob.core.windows.net)
Default route for Service Endpoints: system route with source 'ServiceEndpoint'
Private Endpoint NIC: created in the subnet, not manageable via NSGs on the NIC itself.
Supported services for Private Link: Azure Storage, Azure SQL Database, Azure Cosmos DB, Azure Key Vault, Azure Service Bus, Azure Event Hubs, Azure Data Lake Storage Gen2, Azure Database for MySQL/PostgreSQL/MariaDB, and many more.
Edge Cases and Exceptions
If a storage account has both a private endpoint and a service endpoint enabled, and the client resolves the public FQDN to the private IP via DNS, traffic goes to the private endpoint. If DNS resolves to the public IP, but the client is in a subnet with a service endpoint, traffic goes via the service endpoint path. The exam may test that the private endpoint takes precedence if DNS is configured.
For Azure SQL Database, a private endpoint does not automatically block public access; you must set 'Deny public network access' to 'Yes'.
Service Endpoints for Azure SQL Database require the SQL Server to be configured with 'Allow Azure Services' turned off, and VNet rules added.
Private Endpoints support service tags for network security groups? No, service tags are for service endpoints. Private Endpoints use private IPs.
How to Eliminate Wrong Answers
If the question asks about 'private IP assignment', the correct technology is Private Endpoint.
If the question asks about 'free' or 'no additional cost', it is Service Endpoint.
If the question mentions 'public endpoint still accessible', it is Service Endpoint.
If the question mentions 'DNS zone' or 'privatelink', it is Private Endpoint.
If the question involves 'data exfiltration prevention', Private Endpoint with public access disabled is the stronger answer.
Service Endpoints provide a secure path over the Azure backbone but do not assign a private IP; the service still has a public endpoint.
Private Endpoints assign a private IP to the service in your VNet, eliminating the need for a public endpoint.
Service Endpoints require configuring the service firewall with VNet rules; enabling the endpoint alone is insufficient.
Private Endpoints require a Private DNS zone to resolve the service FQDN to the private IP.
Private Endpoints support disabling public network access on the target resource for maximum security.
Service Endpoints are free, while Private Endpoints incur data processing charges.
Both can coexist on the same subnet, but it is not recommended; choose based on security requirements.
The exam frequently tests the difference in source IP visibility: Service Endpoints show the VNet's public IP, Private Endpoints show the client's private IP.
These come up on the exam all the time. Here's how to tell them apart.
Service Endpoints
Routes traffic over Azure backbone to service's public endpoint
Service sees source as VNet's public IP (after SNAT)
No private IP assigned; service retains public endpoint
Free of charge
Firewall rules based on VNet ID and subnet ID
Private Endpoints
Routes traffic to a private IP in your VNet via Private Link
Service sees source as client's private IP
Assigns a private IP from your VNet address space
Incurs data processing charges
Firewall rules based on private IP address; can disable public access
Mistake
Service Endpoints give the service a private IP in your VNet.
Correct
Service Endpoints do not assign a private IP. They route traffic over the Azure backbone to the service's public endpoint. The service still has a public IP. Private Endpoints assign a private IP from your VNet.
Mistake
Private Endpoints are always free.
Correct
Private Endpoints themselves are free, but data processed through Private Link incurs charges. Service Endpoints are completely free.
Mistake
You can apply NSGs directly to a Private Endpoint NIC.
Correct
NSGs cannot be applied directly to the network interface of a Private Endpoint. NSGs on the subnet still apply to traffic to/from the private endpoint.
Mistake
Enabling a Service Endpoint automatically secures the service.
Correct
Enabling a Service Endpoint only routes traffic over the backbone. You must also configure the service firewall to allow traffic from the VNet/subnet. Without that, the service is still accessible from the internet.
Mistake
Private Endpoints require a VPN or ExpressRoute to work.
Correct
Private Endpoints work within Azure VNets without any VPN. They can be accessed from on-premises via VPN/ExpressRoute, but that is optional.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Service Endpoints extend your VNet identity to Azure PaaS services over the Azure backbone, but the service retains its public endpoint. Traffic is routed to the service's public IP. Private Endpoints use Azure Private Link to give the service a private IP in your VNet, making it accessible only via private IP. The key differences: Private Endpoints assign a private IP, can disable public access, and incur costs; Service Endpoints do not assign a private IP, are free, and require firewall rules based on VNet ID.
No. Private Endpoints work within Azure VNets without any VPN. They are accessible from any resource in the same VNet, peered VNets, or from on-premises if connected via VPN/ExpressRoute with proper DNS resolution. The private IP is reachable over the Azure backbone.
Technically yes, but it is not recommended because it creates overlapping and potentially conflicting configurations. If both are configured, traffic that resolves the service FQDN to the private IP (via Private DNS) will use the Private Endpoint. Traffic that resolves to the public IP and originates from a subnet with a Service Endpoint will use the Service Endpoint path. For simplicity and security, choose one.
Use a Private Endpoint and then disable public network access on the storage account. In the storage account's networking blade, set 'Public network access' to 'Disabled'. This ensures that only traffic from private endpoints (or trusted Azure services) can reach the storage account. Additionally, configure a Private DNS zone so that clients resolve the storage FQDN to the private IP.
The traffic will still be routed over the Azure backbone, but the service's firewall will not have a rule allowing traffic from your VNet. By default, the service's firewall may block all traffic except from trusted Azure services, depending on the service. For example, Azure Storage by default allows all networks. So without a VNet rule, traffic from your subnet might be allowed or blocked depending on the default configuration. To secure access, you must add a VNet rule.
No. Private Endpoints are supported for many but not all Azure PaaS services. The supported services include Azure Storage, Azure SQL Database, Azure Cosmos DB, Azure Key Vault, Azure Service Bus, Azure Event Hubs, Azure Data Lake Storage Gen2, Azure Database for MySQL/PostgreSQL/MariaDB, and others. Always check the latest documentation for the full list.
You need a Private DNS zone (e.g., privatelink.blob.core.windows.net) linked to your VNet. When you create a Private Endpoint, you can have Azure automatically create and link the zone. Alternatively, manually create the zone, add an A record mapping the service's FQDN to the private IP, and link the zone to the VNet. Then, DNS queries from the VNet for the service FQDN will resolve to the private IP.
You've just covered Private Endpoints and Service Endpoints — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?