Azure Private Link has started supporting IPv6, in public preview. The update lets you reach Azure PaaS services like Azure Storage and Azure SQL Database over IPv6-based connectivity, using IPv6 private endpoints from clients inside an Azure virtual network. For anyone running an IPv6 or dual-stack estate, this closes a long standing gap in the private connectivity story.
Why Private Link and IPv6 were overdue to meet
Private Link is how you expose PaaS services without dragging their traffic across the public internet. A private endpoint gives the service a private IP inside your virtual network, so clients connect over a private path rather than hitting a public endpoint. It became a default for secure, compliant access, especially in regulated environments where regulators want to see that traffic never leaves the tenant boundary.
The problem was that the private endpoints were IPv4 only. That is fine for plenty of orgs, but it is increasingly awkward for the ones that have committed to IPv6. Dual-stack environments, or networks slowly shedding IPv4, had no clean way to put Private Link in front of their PaaS workloads. IPv6 only clients simply had no private path to those services. This preview is the answer to that mismatch.
How it works in practice
The mechanics follow the familiar Private Link pattern, with an IPv6 twist. You place an IPv6 private endpoint in a dual-stack subnet, and you configure DNS for the target service so name resolution lands on that endpoint. Then IPv6 clients in the virtual network can reach the PaaS service over IPv6, staying on a private path the whole way.
The dual-stack requirement matters. Your virtual network needs to be running both protocol stacks for this to function, because IPv4 endpoints still exist and the control plane still does IPv4 bookkeeping. If you are already in a dual-stack deployment, this slots in naturally. If you are still entirely on IPv4, there is nothing to do yet, though preview is a good time to start watching how dual-stack gets introduced.
Being a public preview, availability is limited to a set of regions and is meant for non-production testing. Treat it as validation infrastructure, not as something to bolt onto a live environment. The region list will matter for planning, so check what is supported in your footprint before you invest.
What this unlocks for networking teams
The practical effect is that IPv6 only clients finally get a first class path to PaaS. Before this, anyone running IPv6 only compute either forced a dual-stack workaround, relied on public endpoints, or kept IPv4 around just to reach storage and databases. That carve out was expensive and it undercut the whole point of going IPv6 only.
It also signals where Azure is taking its networking roadmap. IPv6 support has been steadily filling in across the platform, and private endpoints landing on IPv6 is one of the bigger checkboxes. For enterprises with long term IPv6 mandates, usually driven by address exhaustion planning or compliance, this removes a blocker that would otherwise keep them tethered to IPv4.
What to keep an eye on
Preview features come with caveats, and this one is no different. Region coverage is limited, service coverage may not be uniform even within the preview, and DNS behavior for IPv6 endpoints is the kind of thing that bites in subtle ways. Test name resolution and routing carefully before you trust it.
Security thinking should not change much. Private Link is still a private path, and IPv6 does not weaken the isolation model. What does change is your visibility surface. If you run IDS or flow logging, make sure your tooling understands IPv6 flows and IPv6 endpoint traffic, otherwise a whole class of connections becomes invisible to monitoring.
Practical next steps
If you have a dual-stack virtual network and a test subscription, the fastest way to evaluate this is to deploy an IPv6 private endpoint to a PaaS service and confirm an IPv6 client can reach it over the private path. That single test tells you whether the mechanics behave the way the docs claim.
For planning purposes, treat this as the moment to stop assuming IPv6 and Private Link are mutually exclusive. If your network is heading toward IPv6 anyway, this removes one more reason to keep IPv4 around indefinitely. Start by checking which of your PaaS workloads are candidate for an IPv6 endpoint and which regions actually have the preview live.
Where this fits in the IPv6 story
IPv6 has been creeping through Azure for years, mostly in the network plumbing: subnets, peering, load balancers, and now private endpoints. Each piece on its own seems like a small checkbox, but together they decide when an organization can finally run IPv6 only. Private Link was the notable holdout because it sits at the boundary where your network meets an external service, which is exactly where protocol mismatches show up.
The comparison worth making is with what came before. Teams that needed both IPv6 and private access had two unappealing options. They could keep a small IPv4 island alive purely to carry PaaS traffic, which defeats the point of an IPv6 migration. Or they could fall back to public endpoints and eat the exposure and egress costs that Private Link was built to avoid. Both were tradeoffs, and neither scales. This preview removes the false choice.
That is the real headline, more than the region list or the preview caveats. Private access is no longer a blocker on the path to IPv6 only. It is a preview, so the work is not done, but the architectural wall that kept IPv4 attachment points alive has a door in it now.