--- title: AWS VPN Decision Guide (2026): Client VPN vs Site-to-Site vs Verified Access vs Direct Connect description: A 280-user SaaS ops team cut Client VPN connection-hours ~62% after moving 34 HTTPS apps to Verified Access — Site-to-Site on TGW stayed for the colo; full-tunnel Client VPN had been burning ~$1.1k/mo in idle connection fees. url: https://www.factualminds.com/blog/aws-vpn-client-site-to-site-vs-verified-access-decision-guide-2026/ datePublished: 2026-07-10T00:00:00.000Z dateModified: 2026-07-10T00:00:00.000Z author: palaniappan-p category: Security & Compliance tags: aws, aws-vpn, client-vpn, site-to-site-vpn, verified-access, transit-gateway, network-security, hybrid-cloud --- # AWS VPN Decision Guide (2026): Client VPN vs Site-to-Site vs Verified Access vs Direct Connect > A 280-user SaaS ops team cut Client VPN connection-hours ~62% after moving 34 HTTPS apps to Verified Access — Site-to-Site on TGW stayed for the colo; full-tunnel Client VPN had been burning ~$1.1k/mo in idle connection fees. **AWS VPN** is not one product — it is a family. **Site-to-Site VPN** connects networks; **Client VPN** connects people to subnets; **Verified Access** connects people to applications. Teams that collapse those into “just turn on VPN” usually overpay and over-privilege. This is the **2026 path-selection guide**. It is **not** the [Verified Access ZTNA how-to](/blog/aws-verified-access-ztna-zero-trust-network/), **not** [Outposts / Local Zones placement](/blog/aws-hybrid-edge-integration-outposts-local-zones-wavelength-2026/), and **not** a VPC peering tutorial ([production VPC practices](/blog/aws-vpc-networking-best-practices-for-production/) cover that layer). Artifacts: [connectivity decision matrix](https://www.factualminds.com/examples/architecture-blog-2026/aws-vpn-decision/connectivity-path-decision-matrix.md), [Client VPN hardening checklist](https://www.factualminds.com/examples/architecture-blog-2026/aws-vpn-decision/client-vpn-hardening-checklist.md), [cost worksheet](https://www.factualminds.com/examples/architecture-blog-2026/aws-vpn-decision/vpn-cost-worksheet.csv), [architecture diagram (draw.io)](https://www.factualminds.com/examples/architecture-blog-2026/aws-vpn-decision/aws-vpn-decision-architecture.drawio). > **Benchmark silhouette (not a cited client)** — **B2B SaaS**, **~280** remote users, **1** colo with Site-to-Site to TGW, Client VPN full-tunnel for “everything.” Modeled Client VPN spend ≈ **$1.1k/mo** (endpoint + connection hours per [AWS VPN pricing](https://aws.amazon.com/vpn/pricing/) shape). After moving **34** HTTPS internal apps to **Verified Access** and switching remaining Client VPN to **split-tunnel**: connection-hours **−62%**, colo Site-to-Site unchanged. Lesson: **apps ≠ subnets ≠ sites**. ## Four paths in one table | Need | Default AWS path | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | Datacenter / branch ↔ VPC | **Site-to-Site VPN** (TGW if multi-VPC) | | Lossy internet path to AWS | **Accelerated Site-to-Site** on TGW ([Accelerated VPN rules](https://docs.aws.amazon.com/vpn/latest/s2svpn/accelerated-vpn.html)) | | Humans → HTTPS apps | **Verified Access** | | Humans → thick client / broad CIDR | **Client VPN** | | Steady high bandwidth / predictable latency | **Direct Connect** (+ VPN backup) | **Opinionated take:** Design **Site-to-Site for sites** and **Verified Access for apps** before you grow Client VPN. Client VPN is the residual bucket — not the architecture. Walk [connectivity-path-decision-matrix.md](https://www.factualminds.com/examples/architecture-blog-2026/aws-vpn-decision/connectivity-path-decision-matrix.md) before buying another endpoint. ## Reference architecture ``` On-prem / colo ──► Site-to-Site VPN ──► Transit Gateway ──► VPCs │ │ └── Accelerated? (TGW only; Global Accelerator edge) Laptops (HTTPS apps) ──► Verified Access endpoints ──► ALB / app Laptops (thick / RDP) ──► Client VPN endpoint ──► VPC subnets (prefer split-tunnel) ``` AWS documents Client VPN as an elastic OpenVPN-compatible service: default scale toward **2,000** concurrent connections (higher via limit increase), dual-AZ subnet associations for HA, and **split-tunnel vs full-tunnel** routing ([Client VPN overview](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/what-is.html), [WFH scaling patterns](https://aws.amazon.com/blogs/networking-and-content-delivery/using-aws-client-vpn-to-scale-your-work-from-home-capacity/)). ## Site-to-Site — VGW, TGW, and acceleration - **VGW:** fine for one VPC. - **TGW:** multi-VPC, ECMP across tunnels, centralized security appliances, **Accelerated VPN**. - **Accelerated VPN:** TGW-only; create new connection (cannot flip existing); NAT-T required; not for DX public VIF ([FAQ](https://aws.amazon.com/vpn/faqs/), [hybrid connectivity whitepaper](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-accelerated-site-to-site-vpn-aws-transit-gateway-single-aws-region.html)). For placement of Outposts/Local Zones and DX service-link sizing, see the [hybrid edge post](/blog/aws-hybrid-edge-integration-outposts-local-zones-wavelength-2026/) — use Site-to-Site as the **backup path**, not the only path, when DX is primary. ## Client VPN — cost and hardening Pricing has two hourly meters: **endpoint association** and **active connection**, plus data transfer and often **public IPv4 / EIP** charges when an IGW is present ([pricing](https://aws.amazon.com/vpn/pricing/), [what is Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/what-is.html)). Use [client-vpn-hardening-checklist.md](https://www.factualminds.com/examples/architecture-blog-2026/aws-vpn-decision/client-vpn-hardening-checklist.md): 1. Dual-AZ associations 2. Non-overlapping client CIDR sized ~**2×** concurrency 3. Split-tunnel by default 4. Tight authorization rules 5. Connection logging + cost alarms Fill [vpn-cost-worksheet.csv](https://www.factualminds.com/examples/architecture-blog-2026/aws-vpn-decision/vpn-cost-worksheet.csv) with your Region rates before executive quotes. For attachment-level VPC economics, see [VPC pricing guide](/blog/amazon-vpc-pricing-endpoints-peering-transit-gateway/). ## Verified Access — link, do not re-implement When the problem is **workforce access to internal HTTPS (and increasingly TCP) apps**, follow [Verified Access in production](/blog/aws-verified-access-ztna-zero-trust-network/). This post only decides **when** that path wins over Client VPN. For console-only private access patterns, see [Management Console private access](/blog/aws-management-console-private-access/). For VDI-heavy workforces, see [WorkSpaces remote workforce](/blog/aws-vdi-secure-remote-workforce-workspaces-2026/). ## What broke — full-tunnel as default > **What broke** — Week of a marketing all-hands. **~220** concurrent Client VPN sessions, full-tunnel. Connection-hour spike plus hairpinned SaaS traffic through the VPC NAT. Detection: Cost anomaly + user complaints about Zoom quality. Fix: split-tunnel + move internal HTTPS tools to Verified Access. Site-to-Site to colo never needed to change. ## What to Do This Week 1. Inventory every use of “VPN” as site, person→subnet, or person→app. 2. Score paths with the decision matrix; write the primary choice in the architecture RFC. 3. If Client VPN is primary for HTTPS apps, schedule a Verified Access pilot for the top 10 apps. 4. Enable cost alarms on Client VPN endpoint + connection hours; run the worksheet. ## What This Post Doesn't Cover - Cedar policy authoring for Verified Access (dedicated post) - Customer gateway vendor CLI for every firewall brand - SD-WAN appliance deep-dives on TGW - AWS Cloud WAN global fabric design - MCP / agent tooling (already covered: [AWS MCP Server GA](/blog/aws-mcp-server-ga-agent-toolkit-serverless-plugin/)) ## FAQ ### When should we NOT use AWS Client VPN? Skip Client VPN as the primary path for HTTPS-only internal apps — use Verified Access instead. Skip full-tunnel for every laptop unless policy requires it; split-tunnel usually cuts cost and hairpin latency. Client VPN remains for thick clients, broad subnet access, and transitional coexistence. ### When should we NOT use Accelerated Site-to-Site VPN? Acceleration requires a Transit Gateway attachment — not Virtual Private Gateway. You cannot toggle acceleration on an existing connection; recreate it. Do not pair Accelerated VPN with a Direct Connect public VIF. Certificate-based auth may conflict with Global Accelerator fragmentation limits — verify CGW support for IKE fragmentation. ### How is this different from the Verified Access ZTNA post? That post is the how-to for Verified Access (trust providers, Cedar, Client VPN migration playbook). This post is the path-selection guide across Site-to-Site, Client VPN, Verified Access, and when to graduate to Direct Connect. ### Site-to-Site on VGW or Transit Gateway? VGW for a single VPC starter. TGW when you have multiple VPCs/accounts, need ECMP across tunnels, centralized inspection, or Accelerated VPN. TGW adds attachment and data-processing charges — model them in the cost worksheet. ### What could go wrong with Client VPN at scale? Overlapping client CIDR with VPC, undersized client CIDR (need ~2× concurrent connections), single-AZ subnet association, and authorization rules that grant entire VPC CIDR to every group. Also surprise public IPv4/EIP charges when the VPC has an Internet Gateway. ### Does Site-to-Site replace Client VPN for remote employees? No. Site-to-Site connects networks (sites, colo, SD-WAN). Client VPN and Verified Access connect people. Mixing them without a matrix is how you get dual tunnels and double cost. --- *Source: https://www.factualminds.com/blog/aws-vpn-client-site-to-site-vs-verified-access-decision-guide-2026/*