Azure Standard Service Endpoints in 2026 and Where They Fit
In this article
“Which PaaS resources can this subnet reach, and who can reach mine” sounds like one question. Azure answers it with at least four different features, each solving a different half, and the newest of them arrived quietly this autumn.
Standard service endpoints extend classic service endpoints with a network identifier and Network Security Perimeter integration. They are worth understanding, and they are worth understanding precisely, because the problem they solve is not the problem most teams think they have.
Status, 24 October 2026. Microsoft’s documentation is inconsistent on this feature. The standard service endpoint overview under Private Link, updated 15 October, has an Important callout reading “Standard service endpoint is generally available”, and lists all four services as generally available in all regions. The virtual network service endpoints overview, updated 7 October, still lists the same feature under Public Preview. The network security perimeter overview adds a third answer: perimeter association is generally available for Storage and Key Vault but Public Preview for SQL Database and Cosmos DB. Since a standard service endpoint needs both halves, the lower of the two statuses is the one that governs your design. Verify the state for your specific service and region before treating it as a production dependency.
What a classic service endpoint actually does
Worth restating, because the new feature only makes sense against it.
A classic service endpoint changes the source address your subnet presents to an Azure service. Without one, traffic from your VM to a storage account leaves with an Azure public IP as its source. With one enabled, the source becomes the VM’s private IPv4 address, and the service learns the identity of your virtual network. You then write a virtual network rule on the storage account that says “allow this subnet”.
Two consequences that catch people. The switch closes existing TCP connections to that service, so it is a maintenance-window change rather than a toggle. And any firewall rule on the service that allowed your old Azure public IP stops working the moment you enable it.
Classic service endpoints are free, cover roughly ten services, and have one structural weakness: every subnet you want to allow is another entry in that resource’s ACL. Ten subnets across four VNets and six storage accounts is a lot of entries to keep correct, and services enforce their own limits on how many they will hold.
What standard service endpoints add
A network identifier, which is a public IP address used purely as a label. Microsoft is explicit that “the public IP address is only used as method of identification of the traffic connecting directly to the virtual network to the service”. No traffic passes through it.
The configuration runs in four steps. Create a public IP. Associate it as the network identifier on the service endpoints of your subnets. Put the PaaS resources inside a Network Security Perimeter. Add IP-based inbound rules on the perimeter that match the identifier.
The payoff is arithmetic. One public IP can be the identifier for every subnet in a region and subscription, and can be reused across subscriptions in the same tenant. A single identifier can stand for many VNets and many subnets, so adding a subnet no longer means touching service-side access rules. Microsoft’s stated benefit is “thousands of connections without hitting resource provider throttles”.
Four services are supported today: Storage, Key Vault, SQL Database and Cosmos DB. Classic endpoints cover about ten, and Private Link covers more than seventy.
What the comparison table says
Microsoft’s own comparison table makes the boundary unusually clear:
| Capability | Basic service endpoint | Standard service endpoint | Private Link |
|---|---|---|---|
| Private connectivity, no public endpoint exposed | Not supported | Not supported | Supported |
| On-premises connectivity | Not supported | Not supported | Supported |
| Data exfiltration protection | Not supported | Not supported | Supported |
| Scalable solution | Not supported | Supported | Supported |
| Service availability | about 10 services | 4 services | 70+ services |
| Pricing | Free | Paid | Paid |
Standard service endpoints move exactly one row from “not supported” to “supported”, and that row is scale. Network Security Perimeter does add real central access control, so the point is not that there is no security value. The point is that three specific properties are unchanged: the public endpoint still exists, on-premises still cannot reach the service privately, and the standard service endpoint itself does not give you Private Link style exfiltration protection on the path from your subnet. The perimeter can still restrict public inbound and outbound traffic for the resources associated with it.
The feature arrives wearing Network Security Perimeter branding, and perimeters sound like isolation. What you are buying is centralised, scalable management of who may reach your PaaS resources. If your actual requirement is that the resource stop having a public endpoint at all, this is not the feature, and Private Link still is.
It is also the first version of this that costs money. Classic service endpoints are free, and Microsoft’s comparison marks standard service endpoints as a paid capability. The Private Link pricing page now lists a separate “Standard service endpoint” meter charged per virtual network per hour, so the bill scales with how many virtual networks you enable it on rather than with how much traffic crosses it. Check the rate against your own agreement before committing to a rollout.
Where endpoint policies fit, and why they are a different control
Standard service endpoints answer “which networks may reach my resource”. That is an ingress question, answered at the resource.
The opposite question is egress: of all the storage accounts in Azure, which ones may my subnet reach? A service endpoint on its own does nothing here. An NSG service tag does a little and not enough, because Storage.westeurope permits traffic to any storage account in the region, including one in a tenant you have never heard of.
Service endpoint policies are the control that closes it. You attach a policy to a subnet listing the storage accounts, resource groups or subscriptions that subnet may reach. Everything else is denied.
Keep this apart from what the perimeter does, because the two controls sit on different paths. A service endpoint policy governs traffic leaving an IaaS subnet, and only towards Azure Storage. A Network Security Perimeter in enforced mode governs traffic leaving the PaaS resources associated with it, through outbound FQDN rules, and Microsoft positions that as preventing exfiltration to unauthorised destinations. So the “not supported” in the exfiltration row is a statement about the subnet-to-service path that standard service endpoints add. It is not a claim that the perimeter around the resource does nothing.
Several details decide whether you can actually deploy them:
They are allow-only. The moment a policy is attached to a subnet, every storage account not named in it becomes unreachable from that subnet, which is the point and also the outage if you have not enumerated your dependencies. Microsoft’s own warning is that Azure services deployed into your virtual network reach storage accounts for their own infrastructure needs, and restricting a policy to your resources can break them.
Applying one upgrades the Storage service endpoint scope from regional to global. That is a quiet but significant change in what the subnet is doing.
They are Azure Storage only, which is the single biggest constraint. Classic storage accounts are denied outright. Managed Azure services other than SQL Managed Instance are unsupported, which rules out App Service Environment, API Management, Redis, Application Gateway, VPN Gateway and Azure Firewall subnets.
And there is no centralised logging for them, so a policy denial is diagnosed from the service side rather than the network side.
Where ASGs do not fit
Application security groups come up in these conversations and do not belong in them.
An ASG is a label you attach to network interfaces so NSG rules can name a group of VMs instead of an address range. It is a tool for making east-west rules between workloads readable and maintainable as the address plan changes. It has no notion of a PaaS resource, because PaaS resources do not have NICs in your virtual network.
The one place the confusion resolves is Private Link. A private endpoint does put a NIC in your subnet, and from that point the resource is addressable like any other private IP. If your goal is to write workload-shaped rules about who may reach a PaaS resource, Private Link is what makes ASGs relevant to the question at all.
A decision table
| Your actual requirement | The control that answers it |
|---|---|
| Stop this resource having a reachable public endpoint | Private Link, with a private endpoint |
| Reach the resource from on-premises over ExpressRoute or VPN | Private Link |
| Stop this subnet reaching storage accounts we do not own | Service endpoint policies, Storage only |
| Allow many subnets and VNets to reach PaaS without per-subnet ACLs | Standard service endpoints with a Network Security Perimeter |
| Allow one subnet to reach one PaaS resource, cheaply | Classic service endpoint and a virtual network rule |
| Keep outbound traffic to a service off the forced-tunnel path | Any service endpoint, classic or standard |
| Write readable rules between workloads inside the VNet | Application security groups with NSGs |
The constraints that decide the design
If standard service endpoints look right, these are the ones that will shape the rollout.
All service endpoints in a subnet must reference the same network identifier. The configuration fails otherwise, so the identifier is a subnet-level decision rather than a per-service one.
Adding or changing a network identifier on an existing service endpoint resets active flows. Microsoft compares it to the original move onto service endpoints and recommends a maintenance window, which is the right instinct.
Identifier reuse stops at the tenant and the region. Cross-subscription within one tenant and region is supported. Cross-tenant is not, and cross-region is not. Public IPs must be unique per region and cannot overlap. Separately, a VNet in one region reaching a PaaS resource in another is supported for Cosmos DB, Key Vault and Storage, and not for SQL Database.
Perimeter limits are low enough to plan against, and Microsoft separates them into two kinds. Recommended limits: 100 perimeters per subscription, 200 profiles per perimeter, 1,000 associated PaaS resources per perimeter. One hard limit: 200 rule elements per profile, counted separately for inbound and outbound. The standard service endpoint page adds 200 IP prefixes per perimeter. A large environment will be split across several perimeters by necessity rather than by preference, and the rule-element ceiling is the one to size against first, because it is the only number in that list Microsoft does not describe as a recommendation.
Network Security Perimeter supports allow rules only. There are no deny rules, so every path has to be permitted.
The permission is specific: Microsoft.Network/publicIPAddresses/joinServiceEndpointNetworkIdentifier/action, which is in Network Contributor and above. If you run a tight custom-role model, this needs adding on purpose.
One documentation caveat is worth testing rather than interpreting. The generic network security perimeter limitations table still states that service endpoint traffic is not supported, and warns that it can be denied even when an inbound rule allows 0.0.0.0/0. That sits awkwardly against the standard service endpoint documentation, which is built on exactly that combination and walks through it step by step in the portal and PowerShell guides. The limitation does not say whether it refers only to classic service endpoints without a network identifier. Until Microsoft qualifies it, validate the specific service and traffic path outside production before the design depends on it.
Microsoft’s own advice before enforcing a perimeter is to leave resource associations in transition mode, renamed from learning mode, and watch the diagnostic logs for one to two weeks. That is sound, and it is the step most likely to be skipped under delivery pressure.
What I would do
For a new design where the requirement is genuine isolation, Private Link remains the answer, and Microsoft’s own recommendation on the classic endpoints page still reads “Microsoft recommends use of Azure Private Link and private endpoints for secure and private access”. Nothing about this release changes that.
Standard service endpoints earn their place in one specific situation: you already run service endpoints at scale, the ACL churn on your PaaS resources has become an operational tax, and the resources are among the four supported. That is a real problem and this is a real fix for it.
What I would avoid is treating the perimeter branding as an upgrade in posture. The table says what it says. If a security requirement drove the conversation, the answer is that this feature does not satisfy it, and the conversation goes back to private endpoints and the DNS work they bring with them.
One last thing worth putting in the design document: this is the first service endpoint that bills. A control that used to be free and is now marked paid changes how it should be applied, and “enable it everywhere because it costs nothing” stops being true.
Looking for Azure architecture guidance?
We design and build Azure foundations that scale: landing zones, networking, identity, and governance tailored to your organisation.
