AWS Client VPN vs a bastion for reaching a peered VPC

One Client VPN endpoint can reach a VPC that is peered with its associated VPC, and you do not need a bastion to make that legitimate. The choice worth making is where the traffic changes hands: an endpoint route that lands in the association subnet and crosses the peering connection, or a host in the peered VPC that ends the session. Both paths work and they fail in different places, so the decision is about ownership and audit rather than about what AWS allows. Here is how I choose between them, and the four entries that make the routed path pass.

Two paths, one endpoint, different owners

On the routed path the client traffic reaches the endpoint, is translated to the address of the Client VPN network interface in the association subnet, and leaves that subnet across the A-to-B peering connection. VPC B terminates no VPN session; it sees ordinary traffic from VPC A, which is why its return route points at VPC A, not the client pool.

On the bastion path the client reaches a host first. A bastion in A still leaves the last hop crossing the peering connection, so you keep the peering work and add a session. A bastion in B still needs a path from the client, and when that path is the same endpoint route you have the routed design plus a hop. The bastion only removes work when it already exists, already has approval, and the thing behind it needs a session boundary rather than a network one.

Four entries make the routed path work

AWS documents this scenario on the Client VPN how-it-works page, and in practice it comes down to four entries owned by two or three teams. Ranges are illustrative; the peered range must be unique and the return range must match your plan.

Route and permission are separate controls. A correct endpoint route with no matching authorization rule gives the client nothing; an authorization rule for a destination the endpoint cannot route gives it a black hole. Both must name the same range.

The endpoint route points at a subnet in the endpoint's own VPC, never at the peering connection. The VPC route tables point at the peering connection, never at an instance or an interface. Copying a value between the two saves without complaint and routes nothing.

Because the association subnet translates the client source, B must route back to VPC A, not to the client pool. Sending the client range across the peering connection looks symmetric, passes review, and fails silently because B never sees a packet with a client source.

Security groups and the last metre of permission

Routing gets packets into B; B still decides. For an active same-Region peering connection, a security group in B can reference the group applied to the Client VPN association, keeping the rule narrow and surviving address changes. Where a group reference is not workable, allow the association subnet range explicitly instead of widening to 0.0.0.0/0, which turns a routing mistake into an unexplained timeout.

Then check what routing never touches: network ACLs on both subnets, the application's allow-list or token audience, and DNS. Peering does not copy private hosted zones, so the laptop can hold a working route to an address it cannot resolve, and a peering connection adds no trust to a certificate. Point the endpoint at a resolver that answers for B, then confirm the private name and the certificate match.

When the bastion is the honest answer

I keep three triggers for choosing a bastion on purpose. The peered VPC belongs to a team that will not add a return route for your range or will not accept a group reference. Access must be approved or recorded per session and the application cannot carry that itself. Or the last hop has to stay inside B because the service resolves only there and its TLS identity is pinned to an internal name.

None of that is a workaround for peering being non-transitive. Non-transitivity limits what resources in B may do: they cannot use A as transit to a third VPC that A is peered with. It never meant a VPN user cannot reach a directly peered VPC, and a bastion built to route around that misreading is a host to patch for no reason.

The reverse mistake costs more over time: funnel every team through the one bastion that already exists, then find that its security group, route table and patch window are the production dependency. Write down which trigger the host serves, and retire it when the trigger goes.

Transit Gateway and several associations change the arithmetic

If the endpoint is attached directly to a Transit Gateway rather than to a subnet, the model changes: clients are no longer translated to an interface address in an association subnet, and the gateway route tables must carry the client range plus the attachment that leads to the peered VPC. That is cleaner at scale, but the work moves from four entries into gateway route tables.

Several associations multiply the checks. The endpoint route belongs to the endpoint, yet every association subnet needs a route table with a real peering next hop. A session can succeed through one association while another has no return path, so test each one.

Verification order that finds the break quickly

Run these in order; each step can pass while the next one fails, and a client timeout almost never says which one broke.

1. Resolve the application name from the client and check the address is inside the peered range.
2. Connect, then read the endpoint connection log for the association that terminated the session.
3. On that association subnet, confirm the route table points the peered range at an active peering connection.
4. On the resource subnet in B, confirm a return entry for the interface range and matching group rules.
5. Test one permitted operation and one resource that must stay unreachable; the second catches debugging leftovers.
6. Reconnect after any split-tunnel route change, because a running tunnel will not pick up a new route set.

Two symptoms are worth memorising. A SYN that reaches B with no reply is almost always the missing return route. A connection that completes and then resets is usually the group, the ACL or the application. Neither shows up in the endpoint log as a cause, so keep the four entries with an owner beside each one.

If none of the three triggers holds, finish the routed path and record those four entries. If one holds, keep the bastion for that boundary only and leave the endpoint route for services that do not need a session in front of them.