The Empty VPC: Client VPN Finally Speaks Native Transit Gateway

Somewhere in your AWS Organization there is a VPC called something like vpc-remote-access-prod-01. No application has ever run in it. No EC2 instance has ever billed an hour in it. It exists because, until this spring, AWS Client VPN could not talk to your network without it. It is scaffolding — and like most scaffolding that stays up for the better part of a decade, everyone has stopped seeing it.

In April 2026, AWS quietly made that VPC unnecessary. AWS Client VPN now attaches natively to AWS Transit Gateway, no hosting VPC required. On the surface it reads like a convenience release. It is not. It removes a NAT boundary that has been quietly destroying user-level visibility in every flow log your security team reads, and it moves remote-access segmentation to the place it always belonged: the Transit Gateway route table.

The problem: remote access was always a tenant, never a peer

Client VPN’s original design has a constraint baked so deep that most architectures formed around it without questioning it: an endpoint had to be associated with subnets in exactly one VPC. Those target network associations materialised as ENIs, and every remote user’s packet entered your network through them.

For a single-VPC shop, fine. But nobody runs a single VPC. The moment your estate grew into the standard hub-and-spoke — application VPCs, shared services, Direct Connect back to on-premises — remote access needed to reach everything, and the only way in was to give the endpoint a home. So we built the hosting VPC: a VPC whose entire purpose was to hold VPN ENIs and a Transit Gateway attachment. Three route tables to keep in agreement — the Client VPN route table, the hosting VPC’s subnet route tables, and the Transit Gateway route table — for every destination you wanted a human to reach.

That was the visible tax. The invisible one was worse.

The challenge: NAT ate your audit trail

Traffic leaving those association ENIs was source-NATed. In AWS’s own words from the launch deep-dive, traffic “appears to originate from the Client VPN endpoint ENI IP address rather than the actual client.”

Sit with what that means operationally. The client CIDR you so carefully allocated — the one that tells you Alice is 10.255.1.7 and Bob is 10.255.3.44 — evaporated at the first hop. Every VPC flow log, every security group evaluation, every IDS alert downstream of the endpoint saw the same handful of ENI addresses. “Which contractor touched the finance database over VPN last Tuesday?” became a correlation project across Client VPN connection logs and flow logs with overlapping timestamps, instead of a grep.

The workarounds all made it worse. Want per-team segmentation? The established pattern, as AWS notes, was to deploy separate Client VPN endpoints per business unit — endpoint sprawl, each with its own associations, certificate story, and route tables drifting slowly apart. Want tighter security groups? You couldn’t reference users — the source was always the endpoint’s ENIs, so rules degenerated into “allow the VPN range”, which is to say, allow everyone.

None of this was misconfiguration. It was the architecture. The obvious fix — make the endpoint a first-class citizen of the transit hub — was simply not on the menu.

The solution: the endpoint becomes an attachment

Now it is. The Transit Gateway documentation lists Client VPN endpoints as a native attachment type, alongside VPCs, Direct Connect gateways, peering, and VPNs. The endpoint plugs into the hub directly. The hosting VPC, its subnets, its ENI choreography and its route tables — gone.

The mechanics worth knowing before you build:

Routing works like Transit Gateway, not like old Client VPN. The Transit Gateway route table associated with your Client VPN attachment carries the routes to your destination networks, propagated or static. Return traffic works by propagating the endpoint’s client CIDR into the route tables of your spoke attachments. If you run split-tunnel — and you should — you still add routes on the Client VPN side so clients know what to send into the tunnel.

Addressing is stricter, deliberately. You bring an IPv4 client CIDR between /12 and /22, and it must not overlap your VPCs, your on-premises ranges, or the Transit Gateway CIDR. IPv6 is friendlier: a /56 is assigned automatically. This is the cost of being a real routing citizen: your remote users now occupy honest address space in the hub’s routing domain, so it has to be planned like address space, not like a NAT pool nobody sees.

Availability zones are explicit. The endpoint runs in at least two AZs (AWS assigns two automatically if you don’t choose), and you pay per-AZ hourly. Pick the AZs where your traffic actually egresses; this is now part of your resilience posture rather than an accident of whichever subnets the hosting VPC happened to have.

And the headline: no more SNAT. Original client IP addresses are preserved end-to-end for IPv4. Alice arrives at the workload as 10.255.1.7 — in the security group evaluation, in the VPC flow log, in the Transit Gateway flow log, in whatever your SIEM ingests. Attribution stops being forensics and becomes reading.

Segmentation also comes home. If you’ve read my piece on Transit Gateway segmentation, you know the hub’s route tables are where isolation policy belongs: associate an attachment with a route table that can only reach what it should. A Client VPN attachment is now just another attachment, so the same machinery applies — one endpoint, segmented at the hub, instead of an endpoint per business unit. Per AWS, the integration is available in all Regions where Client VPN is offered, and there are no new charges beyond standard Client VPN and Transit Gateway pricing — you’re still paying the hub’s per-attachment hourly rate and data processing, as ever.

Migration has one trap worth respecting. You can’t convert an existing endpoint in place: you stand up a new Transit Gateway-attached endpoint alongside the old one, rebuild routes, and cut users over. The trap is in your security groups. Rules that today reference the endpoint’s security group or the hosting VPC’s ranges will silently stop matching once traffic arrives with real client IPs — update them to reference the client CIDR (or better, tighter slices of it) before cutover, test with a pilot group, and only then decommission the scaffolding.

The footprint

Three things this leaves behind, beyond one deleted VPC.

Count your scaffolding. The hosting VPC survived the better part of a decade not because it was good but because it was invisible. Walk your estate and ask which other resources exist purely to compensate for a service boundary — inspection VPCs you no longer need, proxy fleets that outlived their reason, NAT layers whose only function is regret. Scaffolding is a smell: each piece is a place where your architecture is apologising for a primitive that didn’t exist yet.

Identity should survive the path. The SNAT here was never a security control; it was an implementation detail that cost you attribution. Any time a packet’s origin is rewritten between a human and a workload, some future incident review pays for it. Design so that the answer to “who did this” is in the packet, not in a join across three log systems.

Watch what AWS promotes. There is a pattern to AWS networking’s evolution: the community builds a workaround, the workaround becomes doctrine, and then AWS absorbs it as a primitive — VPC peering meshes became Transit Gateway, VGW sprawl became Direct Connect gateway, and now the hosting VPC becomes a native attachment. The lesson for architects is to treat today’s canonical workaround as tomorrow’s deprecation notice, and to keep the seams in your design where the primitives are most likely to arrive.

The best network designs are the ones with the fewest apologies in them. As of this spring, yours needs one less.