Service Endpoints: When and How
Compare service endpoints with private endpoints, configure service endpoint policies, and know when to choose each approach for securing Azure PaaS access.
Service Endpoints: When and How
Service endpoints provide a simpler, free way to secure traffic between your VNet and Azure PaaS services. They don’t give you a private IP — instead, they optimise the route and enable service firewalls to restrict access to your VNet only.
🎬 Video coming soon
Service Endpoints vs Private Endpoints
Service Endpoints vs Private Endpoints
~10:00Service endpoints create a shortcut from your VNet to Azure services — traffic takes the fast lane (Microsoft backbone) instead of the internet. The service keeps its public IP but recognises traffic from your VNet. Simpler than Private Link but less secure.
Service Endpoints vs Private Endpoints
| Feature | Service Endpoints | Private Endpoints |
|---|---|---|
| IP address used | Public IP of the service (optimised route) | Private IP in your VNet |
| DNS changes needed | No — same FQDN, same public IP | Yes — must configure private DNS zone |
| On-premises access | No — only from VNet subnets | Yes — via VPN/ER with proper DNS |
| Cross-region | No — same region as VNet | Yes — PE can be in different region |
| Cost | Free | Per-hour + per-GB processed |
| Setup complexity | Simple — enable on subnet + configure service firewall | Medium — PE, DNS zone, DNS links |
| Service firewall | Restrict to specific VNet/subnet | Can disable public access entirely |
| NSG filtering | Service tag-based only | Full NSG support on PE traffic |
| Data exfiltration protection | Limited (service endpoint policies for Storage) | Better — PE maps to specific resource |
| Supported services | Storage, SQL, Key Vault, Cosmos DB, Service Bus, Event Hubs, etc. | Broader — almost all Azure PaaS services |
When to Choose Service Endpoints vs Private Endpoints
Use this decision shortcut for the exam:
Choose Service Endpoints when:
- All access is from Azure VNets only (no on-premises)
- Cost sensitivity is high (service endpoints are free)
- You need a quick, simple setup with minimal DNS changes
- The service supports service endpoints (Storage, SQL, Key Vault, etc.)
Choose Private Endpoints when:
- On-premises servers need to reach the Azure service
- You need zero-trust: no public IP exposure at all
- Data exfiltration protection per-resource is required
- Cross-region or cross-tenant access is needed
Exam shortcut: If the question mentions on-premises access or “no public IP,” the answer is always private endpoint. If it mentions “free” or “simple Azure-only,” it is likely service endpoint.
Exam Tip — When to Choose Which:
- Private endpoints when: you need on-premises access, cross-region access, full private IP, or compliance requires no public IP exposure.
- Service endpoints when: you want a simple, free solution for VNet-to-PaaS traffic without on-premises access needs, and the service supports it.
Private endpoints are the strategic direction. Service endpoints are a valid, simpler option for less demanding scenarios.
Creating Service Endpoints
Step 1: Enable on the subnet Select which services to enable (e.g., Microsoft.Sql, Microsoft.Storage, Microsoft.KeyVault). This adds an optimised route for traffic to that service — traffic goes over Microsoft’s backbone instead of the internet.
Step 2: Configure the service firewall On the Azure service (e.g., Storage Account), add a virtual network rule allowing traffic from the specific VNet/subnet. Optionally deny all other traffic.
🏪 Sam’s scenario: Harbour Retail has a Storage Account used by VMs in the workload subnet. Sam:
- Enables the
Microsoft.Storageservice endpoint on the workload subnet - On the Storage Account, adds a virtual network rule for that subnet
- Sets the default action to “Deny” — only the workload subnet can access the storage
Now VMs in the subnet reach Storage over the backbone, and all other access (internet, other VNets) is blocked.
Service Endpoint Policies
Service endpoint policies restrict which specific resources a subnet can access through service endpoints. Without policies, a service endpoint to Microsoft.Storage allows access to all storage accounts — including ones in other subscriptions.
Data exfiltration scenario: An attacker compromises a VM and uses the service endpoint to copy data to their own storage account (which is also an Azure Storage account). Service endpoint policies prevent this by restricting access to named accounts only.
Current limitations:
- Only supported for Azure Storage
- You specify allowed resource IDs (storage account resource IDs)
- Traffic to unlisted resources is denied through the service endpoint
Example policy: “VMs in subnet-workload can only access storageaccount1 and storageaccount2 via the Microsoft.Storage service endpoint. Traffic to any other storage account is denied.”
Exam Tip: Service endpoint policies are limited to Azure Storage. If the exam asks about restricting which specific resources a subnet can access via service endpoints, and the service isn’t Storage, the answer is “not supported — use private endpoints instead.”
Key Takeaways
- Service endpoints provide optimised routing and service firewall integration — no private IP
- They’re free and simple but don’t support on-premises access
- Private endpoints give you a private IP, DNS-based resolution, and on-premises access
- Service endpoint policies prevent data exfiltration but only for Azure Storage
- Private endpoints are the strategic direction; service endpoints are valid for simple scenarios
Test Your Knowledge
Sam wants to secure his Storage Account so only VMs in a specific subnet can access it, but he doesn't need on-premises access and wants a free solution. What should he use?
Aisha needs on-premises servers to access Azure SQL Database privately. Should she use a service endpoint or private endpoint?
Next up: NSGs and Application Security Groups — Start Domain 5 with the fundamental building blocks of Azure network security.