Client VPN and Verified Access
Lesson 2 of 3 in Hybrid and Private Connectivity.
Site-to-site connectivity joins networks. User access is a different problem, and AWS gives you two answers that differ in what they hand out.
AWS Client VPN hands out network access. It is a managed OpenVPN-compatible endpoint: the client authenticates, receives an address from the endpoint's client CIDR, and from then on routes traffic into your VPC subject to authorization rules — per-destination-CIDR grants that can be scoped to an Active Directory or SAML group. Authentication comes in three shapes, and the exam asks which: mutual (certificate) authentication for machines and non-federated users, Active Directory through AWS Directory Service, and SAML 2.0 federation through IAM Identity Center or an external provider. Split tunnel sends only VPC-bound traffic through the tunnel (and leaves the user's other traffic on their own path); full tunnel sends everything, which is heavier and sometimes exactly what a monitoring requirement wants. Connection logs go to CloudWatch Logs.
AWS Verified Access hands out nothing but the application. There is no tunnel and no client address on your network. Each application sits behind a Verified Access endpoint; the instance holds trust providers — an identity provider (IAM Identity Center or OIDC) and optionally device trust providers such as Jamf, CrowdStrike or JumpCloud — and every request is evaluated against a Cedar policy that reads the trust context. "Finance group, corporate-managed device, device risk low" is a sentence in the policy, and it is re-checked on the next request rather than at connect time.
That per-request evaluation is the value proposition the exam is testing. A VPN authorizes a session and then trusts the network; Verified Access authorizes a request and trusts nothing.
| AWS Client VPN | AWS Verified Access | |
|---|---|---|
Grants | an address on your network, plus routes | access to one application, per request |
Authenticates with | mutual certificates, Active Directory, or SAML 2.0 federation | an identity trust provider (IAM Identity Center or OIDC) and optionally device trust providers |
Authorizes with | authorization rules per destination CIDR, optionally by group | Cedar policies evaluated against the trust context on every request |
Knows about the device | that it holds a certificate | its posture — managed, patched, risk score — from the device provider |
When trust changes mid-session | the session continues until it disconnects or you revoke | the next request is denied; there is no session to outlive the decision |
Client software | a VPN client, configured and distributed | a browser, for HTTP(S) applications |
Logging | connection logs to CloudWatch Logs | access logs with the decision and context, deliverable in OCSF |
Reach for it when | users need network-level access — SSH, thick clients, several non-HTTP protocols, or a machine-to-network link | users need applications and you want per-request, identity- and device-aware authorization without a VPN |
A few Client VPN details that turn up as distractors. The client CIDR block must not overlap the VPC or any routed network, and it cannot be changed after the endpoint is created — a quietly painful fact. Authorization rules are mandatory: associating a subnet establishes the path, but until a rule grants a destination network (to everyone, or to a specific group), connected clients reach nothing. The endpoint also carries security groups, which apply to traffic leaving it into the VPC, so least privilege has two places to live. And a client connect handler — a Lambda invoked at connection time — lets you implement your own posture or risk checks before a connection is allowed, which is the closest Client VPN gets to Verified Access's device awareness.
For Verified Access, three design notes. Endpoints front an Application Load Balancer, a Network Load Balancer, or a network interface, so the application does not need to be rebuilt or made public. You can associate an AWS WAF web ACL with a Verified Access instance, which puts request inspection in front of the authorization decision. And because policies are Cedar, they are testable text in a repository rather than a console checkbox — the same reviewability you expect of IAM policies.
Choosing between them is usually a matter of reading the requirement for the word "application". "Contractors must reach the internal expenses app from their own laptops, and only from compliant devices" is Verified Access. "Our monitoring team needs SSH to instances and access to three subnets" is Client VPN — or, better for that specific example, Session Manager, which needs neither.
Key terms: AWS Client VPN, AWS Verified Access
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.