A concise, practical setup to cover all major VPN and access scenarios using AWS-native services and two small add‑ons.
Core idea: Rely mainly on AWS Client VPN, AWS Site‑to‑Site VPN, and Transit Gateway. Use PrivateLink/VPC Peering for internal service traffic. Add Tailscale and Cloudflare Access only where extra flexibility or simplicity is needed.
Goal: Provide secure, identity-based access for users working remotely or externally.
Service: AWS Client VPN (managed TLS-based, integrates with IAM/SAML/AD).
How it works: Users connect via AWS VPN client, authenticate with SSO, and get only the routes you define.
Quick setup: Create endpoint → associate subnets → authorize routes/groups → attach security groups.
Key notes:
Split-tunnel for better performance.
Use SSO groups to control access.
Separate auth groups for partners.
When not to use: If users only need web app access — prefer Cloudflare Access.
Goal: Maintain an always-on private link between on-prem networks and AWS.
Service: AWS Site‑to‑Site VPN (IPsec/IKEv2). Use Transit Gateway (TGW) for multiple VPCs.
How it works: On-prem gateways (e.g., StrongSwan, Cisco) connect via IPsec tunnels to AWS gateways. Routes sync both ways.
Key notes:
Use BGP for dynamic routing and failover.
Deploy redundant tunnels across AZs.
Combine with Direct Connect if consistent bandwidth is critical.
Goal: Securely connect multiple AWS regions or external clouds.
Service: Transit Gateway (hub‑and‑spoke) with VPN attachments for non‑AWS peers, or VPC Peering for simple pairs.
Key notes:
Avoid overlapping CIDRs; plan subnets early.
TGW simplifies routing and isolation but adds cost.
Peering is cheaper for small, fixed pairs.
Goal: Enable fast, private communication between AWS services without VPN tunnels.
Service: VPC Peering for flat links or AWS PrivateLink for exposing specific services.
Key notes:
Peering: Simple, 1:1 trusted connection.
PrivateLink: Publish one service privately to many consumers.
Minimal latency, no keys, native IAM controls.
Goal: Let developers, CI/CD jobs, or temporary environments connect quickly with SSO.
Add‑on: Tailscale on EC2 or endpoints for lightweight WireGuard mesh networking.
Why it helps: Removes manual setup, works behind NAT, supports ephemeral keys for CI/CD. Perfect for dev/test access without changing AWS routing.
Goal: Allow browser‑based, SSO‑protected access to specific internal apps without VPN clients.
Add‑on: Cloudflare Access with a Cloudflare Tunnel from AWS.
How it works: Tunnel proxies traffic to apps after SSO validation — no network exposure or client setup.
When to use: Great for partners, admin panels, or non‑technical staff.
Use Case | Primary Choice | Optional Add‑On |
Remote users & partners | AWS Client VPN | Cloudflare Access (web‑only) or Tailscale (devs) |
Office/datacenter ↔ AWS | Site‑to‑Site VPN | Transit Gateway for many VPCs / Direct Connect for steady bandwidth |
Multi‑VPC / Cloud | Transit Gateway | VPC Peering for small pairs |
Service ↔ Service | PrivateLink / VPC Peering | — |
Dev / Temporary | Tailscale | — |
App‑only Access | Cloudflare Access | — |
Overlapping CIDRs: Plan early — overlaps break routing.
Too many peer links: Move to Transit Gateway beyond 3‑4 VPCs.
Excessive full‑tunnel use: Use split‑tunnel unless required.
Shared access between roles: Separate partner and employee groups.
Unclear routing visibility: Use CloudWatch metrics and flow logs to monitor tunnels.
AWS Client VPN — remote & partner access.
AWS Site‑to‑Site VPN + TGW — hybrid and multi‑VPC.
PrivateLink / Peering — internal services.
Tailscale — developer and temporary access.
Cloudflare Access — zero‑trust, app‑level access.
Together these few components cover every practical VPN and secure access scenario in an AWS‑centric environment.