AWS Client VPN Native Transit Gateway Attachment: Remote Access Without the VPN VPC

AWS Client VPN can now attach natively to AWS Transit Gateway. AWS announced the integration on April 23, 2026, and the practical impact is straightforward: remote users can reach multiple VPCs and on-premises networks without building a dedicated “VPN VPC” just to bridge traffic into Transit Gateway.

The security win is just as important. AWS says the new model preserves end-user source IP addresses and removes the IPv4 SNAT behavior that used to hide which remote user generated traffic. Anyone who has tried to trace VPN activity through flow logs knows why that matters.

What Changed

The old pattern created an endpoint in a VPC, associated subnets, routed traffic through that VPC, then connected that VPC to the rest of the network through Transit Gateway, peering, or other routing. It worked, but the architecture existed mostly to satisfy the service integration model.

Native Transit Gateway attachment removes that intermediate layer. Transit Gateway becomes the hub for Client VPN directly. That fits the hub-and-spoke design many AWS organizations already use for AWS VPC design patterns, centralized inspection, shared services, and hybrid connectivity.

Source IP preservation is the part I would sell to security first. If a developer connects from a Client VPN address and reaches a private workload, logs can show that client address instead of a translated address from the VPN VPC path.

The Numbers That Matter

Those facts are the reason this post should be published now, not next quarter. The dates are fresh, the limits are concrete, and the operational impact is clear enough for an engineer to act on today.

How It Works in Practice

Before migration, inventory route tables. You need routes from Client VPN toward VPCs and on-premises networks, and return routes back to the Client VPN CIDR through Transit Gateway. Most broken VPN designs are not authentication problems; they are asymmetric routing problems with better error messages than truth.

AWS lists a client IPv4 CIDR range with a netmask between /12 and /22, and for IPv6 AWS assigns a /56. That CIDR must not overlap with VPC, on-premises, or Transit Gateway CIDR blocks. If your organization has grown through acquisitions or unmanaged RFC1918 ranges, do the overlap audit before the change window.

For inspection-heavy environments, decide whether traffic should go through a centralized firewall VPC after it enters Transit Gateway. The direct attachment simplifies ingress, but it does not remove the need for inspection boundaries described in centralized AWS Network Firewall inspection.

Migration checklist

1. Confirm Transit Gateway has the required IPv4 or IPv6 CIDR blocks.
2. Pick a non-overlapping Client VPN IPv4 CIDR between /12 and /22.
3. Create the Client VPN endpoint with Transit Gateway association.
4. Add authorization rules for the destination networks.
5. Add return routes in Transit Gateway route tables and VPC route tables.
6. Validate source IP visibility in Transit Gateway flow logs.

Gotchas I Would Check First

• No additional integration charge does not mean free networking. Client VPN and Transit Gateway standard pricing still apply.
• Preserved source IPs make audits better, but security groups and NACLs need to allow the client CIDR.
• CIDR overlap is the migration killer. Find it before creating the endpoint.

Decision Guide

For related background, keep these existing BitsLovers posts close: AWS VPC design patterns, AWS PrivateLink patterns, centralized AWS Network Firewall inspection, multi-region AWS architecture.

Sources

• AWS What’s New
• AWS Networking Blog
• AWS Client VPN Transit Gateway docs

For most centralized AWS networks, the dedicated VPN VPC just lost its best reason to exist. Plan the routes carefully and take the simpler design.