Microsoft announced on August 5, 2026 that Azure Private Link over IPv6 is available in public preview.

The capability lets IPv6 clients reach supported Azure platform services through an IPv6 private endpoint instead of moving the data-plane connection onto a public endpoint or translating the application back to IPv4.

The first preview supports Azure-native connections from a dual-stack virtual network and on-premises IPv6 connections over ExpressRoute through an Azure Virtual Network Routing Appliance.

For network teams, this is an important step toward private dual-stack architecture. It also arrives with a narrow preview scope that needs careful lab validation before any production plan is built around it.

What Changed?

Azure Private Link can now create an IPv6 private endpoint for a supported Azure PaaS resource.

The application continues to use the service's normal fully qualified domain name. Private DNS resolves that name to an IPv6 address on the private endpoint, and the data-plane connection stays on private Azure connectivity.

Microsoft documents two supported scenarios:

• An IPv6-enabled Azure virtual machine connects through an IPv6 private endpoint to a supported PaaS service.

• An on-premises IPv6 client crosses ExpressRoute, reaches a Virtual Network Routing Appliance, and continues to the IPv6 private endpoint.

The preview is not an IPv6 flag added to an existing IPv4-only design. It requires dual-stack network planning, preview registration, supported regions and services, correct private DNS, and explicit routing for the on-premises path.

Preview Regions and Services

The initial preview is limited to five Azure regions:

• West Central US

• East Asia

• UK South

• Central US

• North Europe

Supported services are:

• Azure Storage

• Azure SQL Database

• Azure Key Vault

• Azure Data Explorer

The destination PaaS resource and its private endpoint must be in the same region. Cross-region connectivity is not supported in this release.

This scope is small enough that teams should check every planned workload against the current documentation instead of assuming general Private Link availability also means IPv6 availability.

Subscription Registration Is Required

The subscription must be registered for the preview before an IPv6 private endpoint is created.

Microsoft documents the Microsoft.Network/SupportIPv6PrivateEndpoint feature flag, followed by registration of the Microsoft.Network resource provider.

Treat preview registration as a governed platform change. Record which subscriptions are enrolled, who approved the test, which resources are allowed, and when the configuration should be reviewed or removed.

A central platform subscription or an isolated non-production landing zone is a better starting point than enabling the preview broadly across production subscriptions.

The Network Must Be Dual Stack

The Azure virtual network and private endpoint subnet need both IPv4 and IPv6 address space.

Microsoft also requires the following policy settings for the preview:

• At virtual-network level: privateEndpointVNetPolicies set to Basic

• At subnet level: privateEndpointNetworkPolicies set to RouteTableEnabled

The client virtual machine needs an IPv6 address in the dual-stack virtual network.

Dual stack is valuable because it lets teams test the IPv6 path without removing the existing IPv4 path. It also creates two network paths that must be monitored and secured consistently.

Inventory network security, route tables, DNS, monitoring, service endpoints, private endpoints, and troubleshooting tools for both address families. A control that exists only for IPv4 is a gap, not a completed IPv6 migration.

Creating the IPv6 Private Endpoint

The private endpoint creation flow adds an IP version selection.

With Azure CLI, the relevant parameter is --ip-version-type IPv6.

The rest of the private endpoint still needs the target resource ID, group ID, connection name, virtual network, subnet, resource group, and region.

This is a good infrastructure-as-code candidate. The private endpoint, subnet policies, DNS zone links, and routes should be reviewed and reproduced together. A portal-only test may prove connectivity, but it does not prove the team can deploy the design consistently or recover it after a change.

DNS Is the First Validation Gate

Private Link depends on name resolution directing the service FQDN to the private endpoint.

For IPv6, the expected private answer is an AAAA record containing the private endpoint's IPv6 address.

Create the correct Private DNS zone for the service, link it to the relevant virtual network, associate it with the private endpoint, and verify the complete resolution path.

For an Azure Storage example, the standard blob service name should resolve through the Private Link name to the IPv6 address of the private endpoint.

Test DNS from every client location that matters:

• An Azure VM in the private endpoint virtual network

• A peered spoke virtual network

• An on-premises IPv6 client

• A management or jump-host network

• A client using the enterprise DNS forwarder chain

Do not validate only with an IP address. Applications normally connect using the PaaS FQDN because TLS certificates, SDK behavior, and service routing expect the hostname.

Azure-Native Connectivity Is the Simpler Pilot

The most direct preview scenario is an IPv6-enabled virtual machine and IPv6 private endpoint in Azure.

From the client, validate that the service FQDN returns the expected AAAA record and that the application reaches the data plane over TCP 443.

Capture more than a successful connection:

• Resolved hostname and IPv6 address

• Effective routes

• Connection latency

• Application authentication result

• Service-side logs

• Network monitoring evidence

• Behavior when IPv6 resolution or routing fails

• Comparison with the existing IPv4 private endpoint path

Start with a low-risk Storage account or Key Vault created specifically for the lab. A dedicated test resource makes route and DNS failures easier to isolate.

On-Premises Access Uses ExpressRoute and a Routing Appliance

The on-premises preview path is more specific.

An IPv6 client sends traffic over ExpressRoute into the Azure virtual network. A dual-stack Azure Virtual Network Routing Appliance forwards the traffic to the IPv6 private endpoint.

The design requires a user-defined route on the GatewaySubnet. The destination is the private endpoint IPv6 prefix, the next-hop type is Virtual appliance, and the next-hop address is the routing appliance's IPv6 address.

The routing appliance belongs in the ExpressRoute gateway virtual network and provides the IPv6 forwarding hop that the preview path requires.

This makes route symmetry and effective-route validation critical. Confirm the forward and return paths, gateway route propagation, subnet associations, and the exact prefixes advertised or routed.

A successful Azure-native test does not prove the on-premises design. DNS forwarding, ExpressRoute routing, the routing appliance, and the GatewaySubnet route table introduce separate failure modes.

Important Preview Limitations

Microsoft lists several restrictions that materially affect architecture decisions.

During the preview:

• Availability is limited to the documented regions and four PaaS services.

• The PaaS resource and private endpoint must be in the same region.

• On-premises access is limited to ExpressRoute.

• VPN, Virtual WAN, and customer network virtual appliance paths are not supported.

• Network security groups and application security groups with Private Link over IPv6 are not supported.

• The original client IPv6 address is not preserved in downstream service logs because implicit NAT translation exposes a VNet-side translated source address.

• The preview has no service-level agreement and is not recommended for production workloads.

The source-address limitation is especially important for security operations. If a team expects the PaaS audit trail to identify the original on-premises IPv6 client, the preview will not meet that requirement by itself.

Preserve identity and correlation at higher layers. Use Microsoft Entra authentication, application logs, request IDs, gateway telemetry, and ExpressRoute or network evidence to reconstruct the complete request path.

Security Does Not Become Automatic with IPv6

Private Link removes public data-plane exposure for the tested path, but the workload still needs identity, authorization, DNS protection, and operational monitoring.

Apply the same zero-trust questions used for IPv4:

• Which identity is calling the PaaS service?

• Which role permits the requested operation?

• Can public network access be disabled on the target service?

• Which DNS servers can answer the private zone?

• Which routes can reach the private endpoint subnet?

• Which logs prove the connection and application action?

• How is unauthorized access detected?

• What is the rollback path if the IPv6 route fails?

Because NSGs and ASGs are not supported for the preview path, do not copy an IPv4 security model and assume the same enforcement points exist.

Who Should Care?

Network architects should care because Private Link over IPv6 introduces a real private PaaS path for dual-stack Azure and ExpressRoute environments.

Platform teams should care because preview registration, subnet policy, private endpoints, DNS zones, routing, and service configuration should be deployed as one governed platform capability.

Security teams should care because NSG and ASG limitations plus source-address translation change the evidence and enforcement model.

Application teams should care because the service FQDN and TLS behavior remain central even when the resolved private endpoint address moves to IPv6.

Operations teams should care because DNS, effective routes, ExpressRoute, the routing appliance, service authentication, and fallback behavior all need end-to-end monitoring.

Practical Cloud Engineer Takeaway

Build an isolated Azure-native pilot before testing the ExpressRoute path.

Use a supported preview region and create:

• A dual-stack virtual network

• A dual-stack private endpoint subnet

• A small IPv6-enabled test VM

• One supported PaaS resource

• An IPv6 private endpoint

• The correct Private DNS zone and virtual-network link

Register the preview feature, apply the documented virtual-network and subnet policies, and create the private endpoint with the IPv6 IP version.

Then validate:

• The service FQDN returns the expected private AAAA record.

• TCP 443 reaches the service over the IPv6 private endpoint.

• Microsoft Entra or service authentication succeeds.

• Public network access behaves according to policy.

• Logs identify the translated source behavior documented by Microsoft.

• The IPv4 path remains understood during the dual-stack test.

• DNS and route failures produce clear alerts and a safe rollback.

Only after that path is repeatable through infrastructure as code should the team add ExpressRoute, a dual-stack Virtual Network Routing Appliance, the GatewaySubnet route, and on-premises DNS forwarding.

Keep the entire exercise non-production until Microsoft expands support and the service maturity matches the workload's requirements.

Bottom Line

Azure Private Link over IPv6 gives Azure customers a private IPv6 path to selected PaaS services without forcing the application data plane back onto a public endpoint.

The August 5 public preview supports Azure-native dual-stack connectivity and on-premises IPv6 connectivity over ExpressRoute through a Virtual Network Routing Appliance. The first service set is Azure Storage, Azure SQL Database, Azure Key Vault, and Azure Data Explorer in five regions.

The preview also has meaningful constraints: same-region placement, no VPN or Virtual WAN path, no NSG or ASG support, translated source addresses in service logs, and no production SLA.

The right next step is a small, infrastructure-as-code lab that proves AAAA resolution, IPv6 routing, private endpoint connectivity, identity, logging, failure handling, and rollback before the architecture is considered for wider use.

Sources

Microsoft announcement, published August 5, 2026: https://techcommunity.microsoft.com/blog/azurenetworkingblog/announcing-public-preview---azure-private-link-over-ipv6/4543978

Configure Azure Private Link over IPv6: https://learn.microsoft.com/azure/private-link/private-link-ipv6

Azure Virtual Network routing appliance overview: https://learn.microsoft.com/azure/virtual-network/virtual-network-routing-appliance-overview

---

Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.

Chriz Beyond Cloud with Chriz