Three clouds, three names that all mean roughly the same thing, and three implementations that are close enough to rhyme and different enough to bite you. This is the deep-dive I wished existed the last time I had to explain to a customer why their PrivateLink bill didn’t match their mental model — so here’s the mechanics, the genuine differences, and the gotchas, cloud by cloud.
The shared problem all three are solving: expose a service across a trust boundary — VPC to VPC, account to account, tenant to tenant — without peering, without touching the public internet, and without the N² routing mess that full-mesh peering creates at scale. All three clouds landed on a strikingly similar answer. None of them tunnel. None of them peer. All three terminate the connection at an interface object that lives inside your subnet, and let an internal SDN fabric do the real work of stitching it to the other side.
AWS PrivateLink: ENIs and Hyperplane
When you provision an Interface VPC Endpoint, AWS doesn’t give you a route to a remote CIDR. It gives you an ENI — one per subnet/AZ you select — with a private IP carved out of your own address space. Your instance resolves the service’s DNS name, gets that ENI’s IP back, and connects to it directly. As far as your route table is concerned, nothing remote is involved at all.
On the provider side, the pattern is a Network Load Balancer (or, for inline inspection use cases, a Gateway Load Balancer) fronting the actual service, exposed as a VPC Endpoint Service.
The traffic doesn’t actually flow through your ENI as a conventional hop. It’s intercepted at the Nitro/hypervisor layer by Hyperplane — the same internal distributed system that underpins NLB and NAT Gateway — which performs the SNAT/DNAT translation and forwards the packet across AWS’s internal backbone to the provider’s NLB. Your ENI is the address the connection is addressed to; Hyperplane is what actually moves the bytes.
This gives PrivateLink a star topology instead of a mesh: thousands of consumer VPCs can connect to one provider service with zero routing entries and zero CIDR-overlap risk, because there’s no peering relationship underneath to create one.
Gotchas worth knowing:
- Security groups on the endpoint ENI are evaluated in addition to whatever SG sits on the NLB target — a double enforcement point people forget, and a silent-deny trap.
- Endpoint policies (IAM-resource-policy-style JSON) are a separate control plane from security groups entirely. A request that clears the SG can still get denied by the endpoint policy, and vice versa.
- Cross-AZ data transfer through PrivateLink interface endpoints has been free since April 2022 — if you’re still budgeting for it, that line item is stale.
- DNS is the actual control-plane glue: AWS auto-creates a
vpce-xxxxhosted zone entry, and the optional private DNS feature lets the real service hostname (e.g.s3.region.amazonaws.com) resolve straight to the endpoint ENI, so existing application code doesn’t need to change at all.
Azure Private Link: NICs and an approval flow
Azure’s consumer-side primitive is the Private Endpoint — a read-only network interface Azure places in your subnet, with a dynamic private IP retained for the endpoint’s lifetime. It’s scoped tightly: one NIC maps to exactly one PaaS resource instance — one specific storage account, one SQL logical server, one Key Vault — not the service category as a whole. Connections are strictly unidirectional and TCP-only: the client initiates, the service can never push traffic back into your VNet.
On the provider side, you put your own service behind a Standard Azure Load Balancer to make it Private Link-capable, and consumers connect to it through a Private Endpoint in their own VNet, gated by an approval call flow you control.
The underlying SDN fabric doing the actual NAT/translation work isn’t documented with a public name the way Hyperplane is — but architecturally it has to be doing the same job: terminate at the NIC, translate, forward over Microsoft’s backbone.
Where Azure genuinely diverges, and where it bites:
- DNS is the dominant failure mode, full stop. Documentation calls it out directly: DNS correctness is the number one cause of Private Link failures, and the most common hybrid-DNS break is on-prem DNS not forwarding the
privatelink.*zones to the Azure DNS Private Resolver inbound endpoint. - There’s a real observability gap. NSG flow logs are unsupported for the private endpoint NIC itself — inbound traffic to the endpoint is invisible there, and visibility only exists at the source VM. The newer VNet flow logs (replacing NSG flow logs, which retire September 2027) add a
PrivateEndpointResourceIdfield that finally closes this — but until you’re on that, you have a blind spot exactly where a security team would want visibility. - You can’t even see the effective routes or SG rules on the endpoint NIC in the portal. Troubleshooting requires working blind in a way AWS doesn’t impose on you.
- There’s a hard ASG ceiling: no more than 50 members in an Application Security Group tied to the NSG on the private endpoint subnet, or connections start failing.
- One enterprise case study (Michelin, deploying Private Endpoints at global scale across a hub-and-spoke topology) reports the real operational cost isn’t the endpoint mechanics — it’s that every new Private Link zone addition means updating forwarding rules across the entire global DNS estate, and explaining to security teams why a public FQDN now quietly resolves to a private IP.
GCP Private Service Connect: two consumer modes and a third primitive nobody else has
GCP’s model splits into more pieces than the other two. On the consumer side you choose between an Endpoint — a forwarding rule with an internal IP, the direct equivalent of AWS/Azure’s model — or a Backend, where a PSC Network Endpoint Group sits behind your own GCP load balancer instead of being addressed directly. The Backend option buys you things the other clouds don’t expose as cleanly: your own domain and certificate in front of someone else’s managed service, consumer-controlled failover across regions, and centralized access control at the LB layer.
On the producer side, you publish a Service Attachment pointing at an internal load balancer, and consumers connect to it via forwarding rules.
The fabric underneath is Andromeda — Google’s SDN substrate, playing the same architectural role as Hyperplane. The packet path is genuinely instructive: traffic moves directly from the physical host running the client VM to the physical host running the producer’s load balancer VM. The source host makes the client-side load-balancing decision, wraps the packet in an Andromeda header identifying the destination VPC, and the destination host performs SNAT/DNAT on arrival. Same shape as Hyperplane, different name, same job.
The genuine architectural outlier: PSC interfaces. Unlike AWS and Azure, where the model is strictly client-initiates-only, GCP has a third primitive — PSC interfaces — that allows the producer to initiate connections back to the consumer, bidirectionally. This isn’t a minor naming difference; it breaks an assumption that holds everywhere else in this comparison.
Gotchas specific to PSC:
- Producers need to size a dedicated NAT subnet. Service attachments require a subnet with
purpose=PRIVATE_SERVICE_CONNECTfor NAT, and it needs to be sized for the expected number of consumer endpoints. AWS and Azure don’t expose an equivalent capacity-planning knob to the provider at all — Hyperplane and Azure’s fabric absorb this transparently. Undersize it on GCP and you silently cap how many consumers you can serve. - Global access has an asymmetric-change footgun. If a consumer attaches a PSC NEG configured for global access to a producer’s load balancer, and the producer later disables global access on their end, health checks break and traffic can get routed to unhealthy backends and dropped — with no warning at the point of the producer’s change.
- A documented Terraform trap: the Google provider, versions 4.76.0 through 4.81.x, could unintentionally delete and recreate service attachments on
terraform apply, silently closing existing PSC connections. Worth a pin in your provider version if you’re managing this as code. - Only the newer-generation Global External Application Load Balancers support PSC NEG backends — the classic LB generations don’t.
The one thing to take away
Strip the branding and all three converge on the same primitive: an interface object lives in your subnet, a hyperscale internal fabric (Hyperplane / Andromeda / Azure’s unnamed equivalent) does hypervisor-level NAT to stitch it to the other side, and none of it touches a route table or the public internet. That’s why CIDR overlap, the thing that makes VPC peering and transit gateways painful at scale, simply isn’t a constraint here — there’s no route exchange to collide.
Where they actually differ is at the edges. GCP trades simplicity for optionality: an extra consumer-side mode, a genuinely bidirectional primitive, and a producer-side NAT subnet you now have to capacity-plan. Azure trades that optionality for the sharpest DNS-dependency story of the three, plus a real observability gap that’s only now closing. AWS sits in the middle — the most “just works” of the three once your security groups and endpoint policies are both correctly wired, which is itself the most common way to get it wrong.
If you’re designing for production, the practical takeaway isn’t “which one is better” — it’s that the failure modes are cloud-specific even when the architecture isn’t. Test your DNS resolution path on Azure before you test anything else. Capacity-plan your NAT subnet on GCP before you onboard your tenth consumer. And on AWS, draw out your SG-and-endpoint-policy intersection before you assume a denied request is a routing problem.
Written by Paul Carvill
Enterprise → cloud → AI networking. I write the breakdowns I wish I’d had. New field notes roughly twice a month.