Why Service Endpoint Policies Only Work for Azure Storage (And Why Everyone Gets Confused About This)

Let me tell you about a moment that happens to almost everyone working with Azure networking. You're designing a network, you discover service endpoints, and you think "Great! This keeps my traffic on Microsoft's backbone instead of the public internet." You enable them for Storage, SQL, maybe Key Vault. Everything makes sense.

Then you stumble across service endpoint policies and think "Oh cool, I can add more control to all these services!" You start setting them up for SQL Database and... wait. They don't work. You try Key Vault. Nope.

Turns out, service endpoint policies only work with Azure Storage.

And that's when the confusion sets in.

Why This Feels So Weird

Here's the thing: service endpoints support a bunch of different services. So naturally, you'd expect the policies that layer on top of them to work the same way across the board. It feels like finding out that seatbelts only work in the front seats of your car. Surely they should work everywhere, right?

But service endpoint policies weren't designed as a general feature. They were built to solve a very specific problem that Azure Storage had, and it didn't really exist in the same way for other services.

What Service Endpoints Actually Do (The Part Everyone Misunderstands)

First, let's clear up a common misconception: service endpoints don't create private connectivity. I know, I know. It feels like they should, given the name. But they're not like Private Link at all.

Think of service endpoints like this: when you enable one on a subnet, Azure basically attaches a note to your outbound traffic that says "Hey, this came from subnet X in virtual network Y." The destination service (like Azure Storage) receives that note and uses it to decide whether to let the request through.

The access decision is still happening at the service, not at your network boundary. You're not blocking traffic from leaving your network. You're giving the service enough information to make a smarter allow/deny decision. It's more like showing your employee badge to get into a building than building a private tunnel.

Enter Service Endpoint Policies (Storage's Special Power)

So if service endpoints are about telling a service "I'm coming from this trusted subnet," then service endpoint policies add: "...and I should only be allowed to reach these specific storage accounts."

See the difference? Instead of broadly saying "this subnet can access Azure Storage," you're saying "this subnet can access only storage account A, B, and C, and nothing else."

This is incredibly useful for storage because it means even if someone misconfigures something or a workload gets compromised, the blast radius is limited. That VM can only reach the storage accounts you explicitly allowed, not every storage account in existence.

Here's the catch: Azure Storage was explicitly built to understand and enforce these policies. The other services? They just... weren't. Make a mental note!

Why Storage Received This Treatment

Azure Storage has always been a bit different from other Azure services. Storage accounts:

• Have globally unique names with public endpoints

• Get accessed directly over the network constantly

• Are one of the most common sources of "oops, we accidentally exposed data" incidents

Microsoft saw customers struggling with this and built service endpoint policies as a middle ground. Not as airtight as Private Endpoints, but way better than nothing. This was especially valuable when you're modernizing an existing environment and can't flip everything to private connectivity overnight. Think of this as a targeted solution to a real pain point that customers truly experienced live and in the wild.

What About SQL and Key Vault?

You might be thinking "But SQL and Key Vault support service endpoints too! Why didn't they get policies?"

Great question. The short answer: they didn't need them.

Azure SQL Database already has server-level firewall rules and virtual network rules that let you scope access directly to specific subnets. It's a more mature, identity-aware access model that works really well.

Key Vault is even more identity-focused. It relies heavily on Entra ID (fka Azure AD) authentication, access policies, and RBAC. Network controls are an additional layer of security, not the primary gate. Adding service endpoint policies on top would be like putting a bike lock on a bank vault. It's just not addressing the real security problem.

Now, both services solve the "which specific resources can I access" question differently, and arguably better, than service endpoint policies ever could. These are the specific granularities you never really think about until you start digging in.

When Private Endpoints Are Actually the Answer

This is also why you'll notice Microsoft's current guidance pushes people toward Private Endpoints when they need strong isolation. Private Link creates an actual private IP in your virtual network and eliminates public exposure entirely. Private Endpoints are consistent across services, easier to reason about once you wrap your head around everything, and honestly they work better for most modern architectures.

Service endpoint policies still have a place, especially for Storage scenarios where you're incrementally tightening security. But they're not some magical feature you're missing out on everywhere else.

Show Me the Code

Alright, let's make this concrete. Here's how you'd create a service endpoint policy that only allows access to a specific storage account.

First, create the policy:

az network service-endpoint policy create \
  --name storagePolicy1 \
  --resource-group rg-network \
  --location eastus

Then define which storage account(s) you want to allow:

az network service-endpoint policy-definition create \
  --policy-name storagePolicy1 \
  --resource-group rg-network \
  --name allowStorage1 \
  --service Microsoft.Storage \
  --service-resources /subscriptions/<sub-id>/resourceGroups/rg-storage/providers/Microsoft.Storage/storageAccounts/storage1

Finally, attach the policy to a subnet (that already has the Storage service endpoint enabled):

az network vnet subnet update \
  --resource-group rg-network \
  --vnet-name vnet1 \
  --name subnet1 \
  --service-endpoint-policies storagePolicy1

The Mental Model That Makes This Click

Here's how I think about it now (after stubbing my toe a few times):

• Service endpoints answer: "Where is this traffic coming from?"

• Service endpoint policies answer: "Which storage accounts can that traffic reach?"

  
  

That second question was important enough specifically for Storage that Microsoft built dedicated functionality to layer on top. Other services answer that question through their own access control mechanisms (ones that are usually more sophisticated and tied to identity rather than just network origin). Once you stop thinking of service endpoint policies as a "missing feature" for other services and start seeing them as Storage's purpose-built safety net, everything makes a lot more sense.

You're Not Alone

If you initially expected this to work for SQL or Key Vault, welcome to the club (I'm also a member). Most of us made the same assumption at some point. The feature name sounds general, service endpoints work across multiple services, so why wouldn't the policies?

Now you know: it's not a gap in the platform. It's an intentional design that solved a specific problem in the way that made the most sense.

And hey, at least now you won't waste time trying to configure something that was never meant to work in the first place.

References:

• Virtual Network Service Endpoints

• Service Endpoint Policies

• Azure SQL Network Security

• Key Vault Network Security

• Private Endpoints