
Cargando...
Encrypted tunnels connecting your on-premises networks and remote users to AWS — reliably, securely, and at scale.
AWS VPN encompasses two distinct services: AWS Site-to-Site VPN, which creates encrypted IPsec tunnels between your on-premises network and AWS VPCs, and AWS Client VPN, which provides managed OpenVPN-based remote access for individual users. Both services integrate with Virtual Private Gateway (VGW) or AWS Transit Gateway (TGW) to enable flexible hybrid connectivity. AWS VPN is the foundational building block for secure hybrid architectures when dedicated connectivity (Direct Connect) is unavailable, cost-prohibitive, or needs an encrypted backup path.
Establish encrypted, private connectivity between AWS VPCs and on-premises data centers or remote users without requiring dedicated physical circuits.
Use When
Avoid When
Dual-tunnel redundancy (Site-to-Site VPN)
Two IPsec tunnels per connection, each in a different AZ endpoint — mandatory for production HA
BGP dynamic routing
Supports BGP for dynamic route propagation; static routing also available for simpler setups
Static routing
Alternative to BGP; routes must be manually configured and maintained
ECMP (Equal-Cost Multi-Path) routing
ONLY supported via Transit Gateway — NOT supported with Virtual Private Gateway. Enables aggregated throughput beyond 1.25 Gbps per tunnel.
Accelerated Site-to-Site VPN (via AWS Global Accelerator)
Routes VPN traffic through AWS Global Accelerator's anycast network for improved performance. Only available with Transit Gateway, NOT VGW.
Dead Peer Detection (DPD)
Detects tunnel failures and can trigger failover to the second tunnel
IKEv1 and IKEv2
Both Internet Key Exchange versions supported for Phase 1 negotiation
NAT Traversal (NAT-T)
Supported for customer gateways behind NAT devices
Certificate-based authentication (Client VPN)
Mutual TLS with ACM certificates
Active Directory / SAML authentication (Client VPN)
Integrates with AWS Managed Microsoft AD, on-premises AD, or SAML 2.0 IdPs
Split-tunnel mode (Client VPN)
Only routes AWS-bound traffic through the VPN; internet traffic goes directly — reduces bandwidth and cost
Full-tunnel mode (Client VPN)
All client traffic routed through VPN — required for strict security/compliance environments
CloudWatch monitoring
TunnelState, TunnelDataIn, TunnelDataOut metrics available for Site-to-Site VPN
VPN connection to Transit Gateway
Enables centralized hub-and-spoke VPN architecture across multiple VPCs and accounts
AWS VPN CloudHub
Pattern (not a separate service) — multiple customer gateways connected to a single VGW, enabling site-to-site communication between branch offices through AWS
Single VPC Site-to-Site VPN
high freqAttach a VGW to a single VPC, create a Customer Gateway representing the on-premises device, establish a VPN connection. Best for simple single-site connectivity. VGW supports up to 10 Gbps aggregate but does NOT support ECMP.
Centralized Hub-and-Spoke VPN with ECMP
high freqAttach multiple VPN connections to a Transit Gateway instead of individual VGWs. TGW supports ECMP across multiple VPN tunnels, enabling throughput beyond 1.25 Gbps per tunnel. Ideal for multi-VPC, multi-account, multi-site enterprise architectures. TGW is the scalability and centralization solution.
VPN over Direct Connect / VPN as DX Backup
high freqTwo patterns: (1) Run IPsec VPN over a Direct Connect public VIF for encrypted DX traffic. (2) Use Site-to-Site VPN as a failover backup when the primary Direct Connect circuit fails. The VPN path is less performant but provides resilience.
Accelerated Site-to-Site VPN
medium freqAccelerated VPN routes traffic through AWS Global Accelerator's anycast edge network, reducing latency and improving stability for geographically distant customer gateways. ONLY available when the VPN is attached to a Transit Gateway — not available with VGW.
Enterprise Remote Access with AD Authentication
medium freqClient VPN endpoint authenticates users against AWS Managed Microsoft AD or on-premises AD via AD Connector. Enables MFA and group-based authorization. Ideal for replacing legacy SSL VPN appliances.
AWS VPN CloudHub
medium freqConnect multiple branch offices (each with their own Customer Gateway) to a single Virtual Private Gateway. Branch offices can communicate with each other through the VGW hub. Requires BGP and non-overlapping BGP ASNs per branch. Cost-effective WAN replacement for small multi-site setups.
Certificate-Based Client VPN Authentication
low freqUse ACM to issue and manage server certificates for the Client VPN endpoint and optionally client certificates for mutual TLS authentication. Simplifies certificate lifecycle management.
Every Site-to-Site VPN connection has EXACTLY 2 IPsec tunnels — this is the AWS-provided redundancy mechanism. Both tunnels must be configured on your on-premises device to achieve true HA. If only one tunnel is configured and it fails, you lose connectivity entirely.
ECMP (Equal-Cost Multi-Path) for VPN throughput aggregation is ONLY supported with Transit Gateway — NOT with Virtual Private Gateway. If an exam question asks how to achieve VPN throughput greater than 1.25 Gbps, the answer involves TGW + multiple VPN connections with ECMP enabled.
Accelerated Site-to-Site VPN (using AWS Global Accelerator) is ONLY available when the VPN terminates on a Transit Gateway, NOT on a Virtual Private Gateway. This is a common trap in SAA and SAP questions about improving VPN performance for distant sites.
For migration scenarios, prioritize AVAILABILITY over performance optimization. A VPN with both tunnels active and a Direct Connect backup is more exam-correct than optimizing a single path. AWS exam questions repeatedly test that redundancy (dual tunnels, DX backup) is the right answer for hybrid connectivity resilience.
ECMP for VPN throughput aggregation requires Transit Gateway — Virtual Private Gateway does NOT support ECMP. This is the #1 architectural differentiator between VGW and TGW for VPN.
Accelerated Site-to-Site VPN (via Global Accelerator) is ONLY available with Transit Gateway, NOT Virtual Private Gateway. Cannot be retrofitted to existing connections — must create new.
In migration and hybrid architecture questions, ALWAYS prioritize availability/redundancy (dual tunnels, DX backup) over performance optimization. AWS exams consistently reward resilience-first design.
AWS VPN CloudHub is NOT a separate AWS service — it is an architectural PATTERN using a single VGW with multiple Customer Gateways. Branch offices can route traffic to each other through the VGW hub. This appears in exam questions as a cost-effective multi-site WAN solution.
Client VPN split-tunnel mode sends ONLY AWS-destined traffic through the VPN; full-tunnel mode sends ALL traffic through the VPN. Split-tunnel reduces bandwidth consumption and cost. Exam questions about optimizing Client VPN bandwidth or internet performance for remote users point to split-tunnel.
A Virtual Private Gateway can only be attached to ONE VPC at a time. To connect multiple VPCs to on-premises, you need either multiple VGWs (one per VPC) or a Transit Gateway (preferred, centralized approach). This distinction drives many architecture design questions.
For Client VPN high availability, associate the endpoint with subnets in MULTIPLE Availability Zones. Each subnet association is billed separately (per association-hour), so there is a cost trade-off. Exam questions may ask you to identify the HA configuration.
BGP route advertisements over Site-to-Site VPN have a limit of 100 routes. Exceeding this can cause BGP session instability. The solution is route summarization on the customer gateway device. This appears in troubleshooting and design questions.
VPN tunnel state metrics in CloudWatch (TunnelState: 0 = DOWN, 1 = UP) are critical for monitoring. Set CloudWatch Alarms on TunnelState to detect tunnel failures proactively. For security exams (SCS-C02), know that VPN flow logs are NOT natively available — use VPC Flow Logs on the VPC side instead.
Common Mistake
Transit Gateway provides high availability for VPN connections — using TGW means you don't need dual tunnels or redundant connections.
Correct
Transit Gateway provides SCALABILITY and CENTRALIZED ROUTING, not inherent availability. High availability for VPN still requires: (1) configuring BOTH tunnels on each VPN connection, (2) potentially using multiple VPN connections from different customer gateway devices, and (3) optionally pairing with Direct Connect for path diversity. TGW does not eliminate the need for redundancy planning.
This is one of the most common exam traps. Candidates conflate 'centralized' with 'highly available.' TGW is a routing hub — if your single VPN connection's both tunnels fail, TGW cannot help. Always think: redundancy at the VPN connection level is separate from routing architecture.
Common Mistake
Using stronger encryption (e.g., AES-256 vs AES-128) improves VPN connection reliability and reduces tunnel failures.
Correct
Encryption strength has NO impact on connection reliability or tunnel stability. Tunnel failures are caused by network issues (packet loss, MTU problems, ISP instability, Dead Peer Detection timeouts) — not encryption algorithm choice. AES-256 adds CPU overhead but does not make tunnels more or less stable. Reliability comes from dual-tunnel configuration, proper DPD settings, and network path quality.
Security-focused candidates over-index on encryption parameters. Exam questions testing this concept want you to recognize that availability/reliability is achieved through architectural redundancy (dual tunnels, backup paths), not cryptographic choices.
Common Mistake
A Virtual Private Gateway can be used to connect multiple VPCs to on-premises with centralized routing, just like Transit Gateway.
Correct
A VGW can only be attached to ONE VPC at a time and does NOT support ECMP or centralized routing across multiple VPCs. To connect multiple VPCs to on-premises through a single VPN endpoint, you MUST use Transit Gateway. VGW is a per-VPC gateway — it cannot route between VPCs or aggregate throughput via ECMP.
This misconception causes wrong answers on architecture design questions. The decision tree is: single VPC → VGW is fine; multiple VPCs or need for ECMP/centralized routing → Transit Gateway. Also remember: VGW does NOT support Accelerated VPN (requires TGW).
Common Mistake
Accelerated Site-to-Site VPN can be enabled on any existing VPN connection attached to a Virtual Private Gateway to improve performance.
Correct
Accelerated VPN is ONLY available for VPN connections attached to a Transit Gateway. It is NOT available for VPN connections using a Virtual Private Gateway. Additionally, you cannot convert an existing non-accelerated VPN connection to an accelerated one — you must create a new VPN connection with acceleration enabled.
Performance optimization questions for VPN will often list 'enable acceleration' as an option. If the architecture uses VGW, this option is a trap. The correct answer requires migrating to Transit Gateway first.
Common Mistake
During a hybrid cloud migration, you should optimize VPN performance first before establishing redundancy, since performance issues will slow the migration.
Correct
AWS best practice and exam guidance consistently prioritize AVAILABILITY over performance optimization during migrations. Establish redundant paths first (both VPN tunnels active, consider DX as backup), then optimize performance. A failed connection during migration is far more disruptive than a slower-but-reliable connection. This is tested directly in SAA and SAP migration scenario questions.
Migration scenario questions are designed to test whether candidates prioritize resilience over optimization. The exam answer will almost always favor the option that adds redundancy (e.g., 'configure both VPN tunnels and add a Direct Connect backup') over the option that improves speed of a single path.
Common Mistake
AWS Client VPN and Site-to-Site VPN are the same service with different names — both work the same way.
Correct
These are fundamentally different services: Site-to-Site VPN uses IPsec and connects NETWORKS (on-premises network ↔ VPC) using customer gateway devices. Client VPN uses OpenVPN/TLS and connects individual USER DEVICES to AWS or on-premises resources. They have different authentication methods, pricing models, use cases, and configuration requirements. Client VPN requires an OpenVPN-compatible client on each device.
Candidates who don't distinguish between the two will choose the wrong service in scenario questions. Key differentiator: 'remote employees need access' → Client VPN; 'branch office/data center connectivity' → Site-to-Site VPN.
VPN = 'Very Private Network' — Two Tunnels, Two AZs, True HA (always configure BOTH tunnels!)
TGW = 'The Gateway to Everything' — ECMP, Acceleration, Multi-VPC: all the VGW 'cannots' become TGW 'cans'
CGW vs VGW: CGW = 'Customer's Gateway' (your device), VGW = 'Virtual Gateway' (AWS side) — C for Customer, V for Virtual/AWS
CloudHub = 'Cloud as Hub' — one VGW, many spokes (CGWs), branches talk through AWS
Client VPN billing = 'Double Dip' — pay for the endpoint association AND pay per connected user
Accelerated VPN mnemonic: 'TGW + GA = Fast VPN' — Transit Gateway + Global Accelerator = Accelerated VPN (VGW cannot)
CertAI Tutor · CLF-C02, SAA-C03, SAP-C02, SCS-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns