AWS Client VPN or Site-to-Site: Check Who Connects
Client VPN authenticates a device or user; Site-to-Site joins a gateway to AWS. Four checks settle which one your laptop or branch actually needs.
Four checks decide this, and none of them is the protocol name. Who opens the connection, what AWS authenticates, how the connection attaches to your network, and what routing and policy come with it. Answer those in order and the product choice usually makes itself; answer them after you have bought a design and you will end up defending a tunnel that solves the wrong half of the problem. None of the four asks you to pick a cipher, which is why a protocol-first design is usually a sign the requirements were never written down.
Run each check against the actual endpoint, client and address family you plan to use, not against the category. Managed VPN products differ from the OpenVPN and IPsec building blocks they resemble.
First, who opens the connection
If the thing that needs access is a laptop, a phone or a single administrator's workstation, the connection starts at a remote device and the design is remote-client access. If the thing that needs access is a branch full of machines behind one router, the connection starts at that router and the design is gateway-to-gateway. This is the check that settles most cases, and it is the one people skip when a vendor deck has already framed the conversation around ciphers.
Stop here if you cannot name the component that initiates. A design that tries to serve both cases with one tunnel tends to end up with a client session pretending to be a gateway.
Second, what AWS authenticates
With Client VPN, AWS authenticates the configured client or user identity: certificates, a directory, or a federated identity, depending on the setup. With Site-to-Site VPN, AWS authenticates the gateway peer identity. That difference is not cosmetic. One model scales by adding users and revoking their credentials; the other scales by trusting whatever sits behind a single gateway.
Gateway authentication does not authenticate every employee or application behind it, so keep application identities and resource-level access in place even when the tunnel itself is trusted. A branch whose router holds a valid peer identity should not automatically read as every desk in that building being authorized.
Third, how the connection attaches
Client VPN attaches through VPC subnet associations or a supported direct Transit Gateway attachment. Site-to-Site VPN attaches to an AWS VPN target, commonly a virtual private gateway or a Transit Gateway. The Client VPN architecture guide documents the Transit Gateway option, and its existence does not turn a laptop session into a branch gateway or remove the client authentication and authorization described above.
Check the attachment your account and Region actually support before you design routes around it, then check who owns that attachment. An option that exists in the documentation but sits on a network you cannot configure is not an option.
Fourth, what routing and policy come with it
Client VPN brings client connection management and authorization rules for the destination networks you permit. A connected user still needs the intended endpoint route, an authorization rule that allows it, and whatever access the resource itself requires. Site-to-Site VPN routes between networks represented by a customer gateway, using supported static routes or BGP depending on the design, so individual machines behind the branch router do not each need a client login.
Do not infer unsupported behaviour from the category in either direction. Remote-access VPNs are not universally incapable of carrying return traffic or supporting gateway arrangements, and IPsec is not automatically blocked by NAT — AWS documents NAT traversal and customer-gateway requirements, and the supported gateway configuration is the real constraint. Check the restrictions for your endpoint before you require connections initiated toward clients or forward a LAN behind one session. The same caution applies to address families: an endpoint that works over IPv4 does not imply an IPv6 path, so confirm the family your client or gateway will actually negotiate.
Site-to-Site VPN gives you two tunnels per connection, and that redundancy is a design task rather than a feature you can assume. Customer-gateway operation, route failover and test coverage all have to be planned; comparing one laptop session against an abstract VPN server proves nothing about either.
Where the two designs meet
The services are not exclusive, and the common production shape uses both: employees on Client VPN, branch networks on Site-to-Site, with explicit routes and access policy between the destinations that must talk. The table is a recap of the four checks, not a substitute for running them.
| Question | AWS Client VPN | AWS Site-to-Site VPN |
|---|---|---|
| Who establishes it? | A client on a remote device | A customer gateway device or appliance |
| What is authenticated? | The client or user identity | The gateway peer identity |
| How does it attach? | VPC subnet association or Transit Gateway | Virtual private gateway or Transit Gateway |
| What carries the path? | An OpenVPN-based client tunnel | IPsec tunnels to AWS endpoints |
One thing neither product replaces: TLS to an application whose encryption requirement extends past the VPN endpoint. If your compliance scope ends at the application, the tunnel is transport and the certificate is still the control.
Write the four answers down before the design review, one line each. When two of them disagree — say, a user-authenticated client design with a branch-sized routing requirement — that disagreement is the finding, and it is cheaper to see it now than during cutover.