One Door, Many Rooms: What PrivateLink Tunnel Endpoints Actually Change

On 18 September 2026 AWS announced a new VPC endpoint type for PrivateLink: the tunnel endpoint. The one-line summary sounds like a convenience feature. Share a CIDR range instead of a list of resources. Done.

Read the documentation and it turns out to be something stranger and more interesting: PrivateLink has grown a tunnelling mode, and the consumer now owns a piece of the data plane.

The problem: PrivateLink is a catalogue, and some networks are not

PrivateLink has always been a deliberately narrow interface. You expose a service, the consumer gets an endpoint, and nothing else in your VPC becomes reachable. That narrowness is the point.

It also has a cost. AWS describes the old model plainly in the launch post: sharing resources with an external party, such as a vendor, meant creating a separate Resource Configuration for each resource. That works when the thing you share is a database or a service with a stable identity.

It works badly when the thing you share is a segment: a fleet of short-lived instances, a build farm, a scanning target range, a customer environment that a vendor needs to reach while it is being provisioned. The resources are ephemeral or not known in advance, and a catalogue that has to be edited every time one appears is a catalogue that is always out of date. The alternatives were the usual heavyweights: peering, a Transit Gateway attachment, a VPN. Each one gives the other side far more network than you meant to hand over, and each one drags in routing and overlapping-address conversations.

The challenge: a range is not a service

A CIDR range has no service identity. There is no listener to front, no load balancer to point at. Whatever PrivateLink does with a range, it cannot behave like the endpoint types we already know, where the consumer resolves a name and connects to an ENI.

So AWS did something different. From the documentation: a network segment is a set of CIDR ranges, shared as a resource configuration of type CIDR, and “tunnel endpoints require you to tunnel into another VPC using GENEVE encapsulation.” The consumer does not connect to the endpoint. The consumer wraps its traffic in a GENEVE packet and sends that to the endpoint.

The encapsulation is the consumer’s job, not something the service does for you.

The solution: how the tunnel works

The provider shares the segment as a CIDR-type resource configuration attached to a resource gateway. The announcement notes it travels through AWS Resource Access Manager, so the consumer account has to accept the resource share before it can use it. The consumer then creates a tunnel endpoint. A tunnel endpoint associates with exactly one CIDR-type resource configuration.

Consumer compute wraps traffic in GENEVE and sends it to the tunnel endpoint, which unwraps it and forwards the inner packet to the shared segment through the provider's resource gateway

The tunnel endpoint strips the GENEVE header and forwards the inner packet. Connections can only start from the consumer side.

The rules on the wire are specific, and they are where designs go wrong:

GENEVE over UDP, port 6081, VNI set to 0. Security groups on both the endpoint and the compute must allow UDP 6081.
The inner packet must be a layer 3 IP packet. Inside it, TCP carries regular application traffic; UDP is supported only for DNS queries.
The consumer sends its GENEVE traffic to the endpoint’s per-Availability Zone IP addresses. After creating the endpoint you describe its association to find them, then configure the GENEVE device on your compute. The docs suggest doing this in its own routing context or network namespace, which is good advice: you are putting a tunnel interface on a host that also does other things.
The endpoint’s subnets must sit in Availability Zones that overlap the resource gateway’s. AWS recommends at least two Availability Zones per endpoint for production.

On receipt, the endpoint removes the GENEVE header and forwards the inner packet, but only after checking that the destination lies inside the segment that was shared. Outside it, access is refused. That check is the security boundary. The provider does not hand over a route into its VPC; it hands over a filter.

DNS comes along for the ride

A tunnel endpoint can also resolve names in the provider’s VPC. You send a DNS query to the name server 169.254.168.253, inside the tunnel, as you would any other inner packet. Resolution then behaves as it would for a client in the remote VPC: it follows that VPC’s DHCP option set and respects its Route 53 private hosted zones or custom resolvers. Private DNS names for the endpoint itself are not supported.

For the ephemeral-fleet case this matters. The consumer does not need a list of addresses; it can ask the provider’s own resolver.

The one-way street

The documentation is blunt about direction: connections can only be initiated from the VPC that has the tunnel endpoint. The VPC sharing the segment cannot initiate connections back. For a vendor reaching into a customer environment, that is the behaviour you want. For anything symmetric, such as callbacks or health probes from the provider side, it is a design constraint to find out about on day one rather than at cut-over.

Address families are more flexible than you might expect. Outer and inner packets can differ, so IPv4 over IPv4, IPv6 over IPv4, IPv4 over IPv6 and IPv6 over IPv6 are all supported. The endpoint’s IP type sets the outer packet; the remote VPC’s IP type sets the inner one.

Who pays for what

The consumer pays for each hour a tunnel endpoint is provisioned and per GB of data processed. The provider, sharing the segment through a resource gateway, is billed per GB processed by the gateway under VPC Lattice pricing. Two meters on two sides of the same flow is worth modelling before you promise a vendor “free” access to your range. I am deliberately not quoting rates here; read them from the pricing pages for your Region.

As of this writing the feature is available in 28 Regions, including Frankfurt, Ireland, London, Paris, Stockholm and Zurich.

The footprint: what you are really adopting

Three judgement calls fall out of this.

You have adopted a data-plane component. A normal interface endpoint is something you create and forget. A tunnel endpoint needs a GENEVE device, a nameserver setting and a routing context on compute you operate. That compute is now a single point of tunnel termination for your traffic. Treat it with the same care as any appliance: more than one Availability Zone, health checks, and a plan for when the tunnel interface is the thing that is broken.

Segment sharing is a coarser grant than service sharing, by design. Giving a vendor a CIDR range is closer to giving them a subnet than giving them an API. The destination check keeps them inside the range, but everything inside the range is in play. If your range contains a database you forgot about, the tunnel will not remember it for you. Keep ranges narrow and dedicated; do not share a /16 because it was convenient.

It is the right tool for ephemeral estates and the wrong tool for stable services. If the thing you expose has a name and a port, the established endpoint types are simpler and put no tunnel on your hosts. Reach for the tunnel when the resources come and go faster than a catalogue can follow.

The deeper pattern is the same one running through most recent AWS networking launches: the boundary between “private connectivity” and “run a bit of the network yourself” is getting blurrier. That is not a complaint. It is a reason to read the wire-level rules, UDP 6081 and VNI 0 included, before the first vendor onboarding call rather than during it.