Video summary

Standard Service Endpoint Overview

Main summary

Key takeaways

Technology

Summary: Standard Service Endpoints (Azure) — what they are and why they matter

The video introduces standard service endpoints as a new capability for Azure networking (available in public preview at the time of recording). The speaker advises checking the official docs for the latest status.

Background: the “basic” service endpoint problem

  • Many Azure resources (e.g., VMs) live inside a VNet, typically divided into subnets.
  • Subnets commonly use RFC1918 private IP ranges such as:
    • 10.x
    • 172.16–31.x
    • 192.168.x
  • These private ranges are not internet-routable.
  • Azure PaaS services (e.g., Storage, SQL DB, Key Vault, Cosmos DB, PostgreSQL, etc.) usually expose:
    • a public endpoint, plus
    • firewalls to restrict access.
  • With traditional (“basic”) approaches, you generally cannot whitelist a subnet’s RFC1918 range in the PaaS firewall, because access requires an internet-routable address (often involving NAT / gateways).

How service endpoints help (baseline behavior)

A service endpoint is configured at the subnet level for a given PaaS type (example: Storage). Enabling it provides:

  1. A more direct / “enhanced” path from resources in that subnet to the target service.
  2. The service firewall can then allow access based on the VNet subnet identity, letting you whitelist the subnet rather than relying on RFC1918 routing that fails due to translation.

Key limitation of basic service endpoints (scalability)

  • A single VNet subnet ID can be associated with up to 500 PaaS resources (increased from 200).
  • This becomes difficult for scenarios such as an ISV needing to grant access across:
    • many customer subscriptions, and
    • many PaaS instances, especially as subnet-to-resource permissions multiply.

The new feature: Standard Service Endpoints

Core concept: “Network Identifier” based on a public IP

Standard service endpoints introduce a network identifier, which is a public IP address (either Azure-assigned or BYO).

Requirements:

  • The public IP must be in the same tenant and same region as the VNet/subnet where it will be used.

Relationship rules:

  • One network identifier per subnet (1:1 for subnet → network identifier).
  • The same public IP can be used by many subnets (up to 1:N), as long as they’re in the same tenant/region.

How standard vs basic is enabled

  • At the subnet level, you associate the public IP as a network identifier.
  • On each service endpoint type (e.g., Storage, Key Vault, SQL, Cosmos DB), you enable an option such as “use the network identifier.”
  • When selected, the service endpoint upgrades from basic to standard.

Practical benefit

Because access is anchored to the public IP network identifier, organizations can scale permission management by using:

  • one public IP per region (for the ISV / provider), and then
  • enabling that same network identifier across each customer environment / NSP rules.

Integration with NSP (Network Service Perimeters)

Why NSP matters for standard endpoints

Standard service endpoints work with Network Service Perimeters (NSP). The speaker’s workflow:

  1. Put the relevant PaaS services (example: Storage + Key Vault + Cosmos DB) into the same NSP.
  2. On the NSP policy, add inbound allow rules referencing the network identifier public IP.
  3. After the update, resources in the subnet(s) using the standard service endpoints can access those services via the NSP policy.

Supported services (at time of recording / preview)

At the time of the preview, NSP-compatible standard service endpoints are limited to:

  • Storage
  • SQL Database
  • Cosmos DB
  • Azure Key Vault

The speaker notes support will likely expand over time.

Management / UX highlights from the environment UI

A “new interface” allows managing service endpoints and network identifiers:

  • Bulk add service endpoints at the VNet level.
  • Bulk assign network identifiers to multiple selected subnets.

Operational note:

  • If you bulk-select multiple subnets, Azure may force them to use the same network identifier.
  • To use different identifiers, configure subsets separately.

Security / permissions and governance

  • Setting up standard service endpoints requires elevated permissions.
  • The docs mention an action such as: Microsoft.Network/.../joinServiceEndpointNetworkIdentifier
  • A custom RBAC role can be created if needed.
  • Preview gating: you must enable a preview feature allowing network identifiers for service endpoints.

Safety recommendation for public IP usage

Because the network identifier is just an IP and access rules apply broadly, the speaker recommends:

  • Use a dedicated set/pool of public IPs reserved only for network identifiers.
  • Avoid reusing the same IP for unrelated resources (e.g., a VM), to prevent unintended access.

Connectivity boundaries (what it does NOT support)

Standard service endpoints do not support transitive connectivity, so they won’t work for:

  • peered VNets
  • on-premises
  • other cases where private endpoints are typically needed

The speaker positions standard service endpoints as:

  • simpler than private endpoints (no DNS/routing complexity),
  • but less flexible due to fewer supported connectivity paths/services.

Cost model

  • Standard service endpoints are not free like basic service endpoints.
  • Billing described:
    • Charged per hour per VNet once you enable a standard service endpoint in at least one subnet.
    • Enabling additional standard service endpoints / subnets within the same VNet does not increase hourly metering (price stays the same).
  • Guidance: enable standard endpoints only for supported NSP-compatible services to avoid wasted cost (example: enabling unsupported services like “Postgress” would be useless).

Main speaker / source

  • Primary speaker: The narrator/author (“Hey everyone…”, unnamed in the subtitles).
  • Source referenced: Microsoft Azure documentation and docs links (mentioned multiple times; no specific author named).

Original video