VPN — Site-to-Site, Client VPN, and ECMP

VPN on ANS-C01 is the budget-friendly, fast-to-deploy hybrid connectivity option that the Specialty exam expects you to wield with the same precision as Direct Connect. A representative question describes "a customer with 10 remote sites needing 1.5 Gbps aggregate to AWS, a corporate office with 200 remote workers requiring SAML-authenticated VPN access with split-tunnel, a regulatory requirement that the on-prem-to-AWS path is encrypted at IPsec layer even when traffic also crosses Direct Connect, and a need for sub-second failover during AWS-side maintenance — design the VPN layer in 60 seconds". That is a Network Engineer problem that pulls in Site-to-Site VPN with two IPsec tunnels per connection, IKEv2 with AES-256 modern defaults, BGP-vs-static routing trade-offs, ECMP across 4 VPN connections to a TGW for 1.5 Gbps aggregate (since each tunnel maxes at ~1.25 Gbps), Accelerated VPN through Global Accelerator's edge POPs, AWS Client VPN with OpenVPN and SAML federation, split-tunnel vs full-tunnel, VPN-over-Direct-Connect Public VIF for layered encryption, and DPD timeout tuning — and ANS-C01 routinely tests every one of those moving parts inside a single five-line scenario.

This topic is Domain 1 (Network Design, 30 percent of the exam) Task Statement 1.5 in its entirety, and overlaps with Domain 2 Task 2.1 (implementation). The official ANS-C01 exam guide lists the knowledge bullets verbatim: "Routing fundamentals (dynamic vs static, BGP)", "VPNs (security, accelerated VPN)", "Encapsulation and encryption technologies (GRE, IPsec)", "Layer 1 and types of hardware (LOA, colocation, Direct Connect)". Roughly 5 to 8 of the 65 exam questions touch this territory.

Why VPN Is the Specialty Exam's Resilience and Remote-Access Layer

VPN is the cheapest, fastest hybrid connectivity option — provisionable in minutes versus weeks for Direct Connect. The Specialty exam tests it because real-world Network Engineers use VPN for: (a) initial AWS migrations before DX is procured, (b) DX backup, (c) branch-office connectivity at low bandwidth, (d) remote-worker access via Client VPN, (e) multi-cloud connectivity (AWS-to-Azure, AWS-to-GCP). VPN is also the answer for IPsec layered encryption requirements over Direct Connect (VPN-over-DX) when MACsec is unavailable.

The mental model the exam rewards is "VPN is the Swiss Army knife of hybrid connectivity": pick the right blade for each job — Site-to-Site for branch and DX backup, Client VPN for users, ECMP across multiple Site-to-Site connections to scale beyond single-tunnel bandwidth, Accelerated VPN for distant sites, VPN-over-DX for layered encryption. ANS-C01 will reward this layered thinking with full-credit answers; candidates who think of VPN as "an IPsec tunnel" will be punished on every nuanced distractor.

Plain-Language Explanation: AWS VPN — Site-to-Site, Client VPN, and ECMP

VPN combines two distinct services (Site-to-Site for office-to-AWS, Client VPN for user-to-AWS), with multiple feature dimensions: tunnel design, IKE versions, routing options (static or BGP), accelerated mode, ECMP scaling, and authentication methods. Three analogies anchor the moving parts.

Analogy 1: The Armoured Convoy on a Public Highway

Imagine VPN as armoured trucks driving on the public highway.

The Site-to-Site VPN is a regularly scheduled armoured convoy between two warehouse hubs — your data centre and the AWS warehouse. The convoy uses two parallel routes (two IPsec tunnels) for redundancy; if one route is closed due to maintenance, the other carries the load. The trucks are armoured with bulletproof IPsec so that even highway robbers can't read the cargo.

The Customer Gateway is your dispatch office at your warehouse — it schedules the convoys, hands the AES-256 keys, and reads the GPS pins (BGP advertisements). The Virtual Private Gateway / Transit Gateway is the AWS receiving dock.

The Accelerated VPN is the fast-pass lane on the highway — the convoy enters the AWS-managed expressway (Global Accelerator's edge POPs) at the nearest entry ramp, drives the AWS backbone (private rails) most of the way, and exits at the destination AZ — much faster than the public highway.

ECMP is multiple convoys running in parallel to the same AWS dock — when you need 5 Gbps and one convoy can only carry 1.25 Gbps, you run 4 convoys simultaneously, each on a different parallel route, with the cargo distributed across them (5-tuple hash).

The Client VPN is the executive helicopter service — individual VIPs (remote workers) get airlifted directly into the AWS warehouse via secured helicopters (OpenVPN-based per-user tunnels), authenticated by certificate, badge (Active Directory), or signed letter (SAML).

Analogy 2: The Diplomatic Courier Service

A Site-to-Site VPN is a diplomatic courier route between two embassies. The pouch is sealed with diplomatic seals (IPsec), can't be opened in transit. Two tunnels = two parallel courier routes for redundancy. BGP routing is the GPS system that adapts to road closures (active/active or active/passive failover). Static routing is paper directions printed in advance — works if roads don't change, fails when there's a detour.

Accelerated VPN is the diplomatic helicopter route — couriers fly to the nearest helipad (Global Accelerator edge POP), then take the AWS-private flight network instead of public highways. Lower latency, but only works for embassies that have a TGW (not VGW).

ECMP is multiple parallel courier convoys sent at the same time, splitting the diplomatic mail across them.

Client VPN is the personal diplomatic courier for individual VIPs (remote workers). They authenticate with a certificate or SAML token, get a sealed badge, and travel solo through encrypted channels.

Analogy 3: The Submarine Pipe Network

A Site-to-Site VPN is an encrypted oil pipeline from your refinery to the AWS storage facility. IPsec encryption is the encrypted pipe lining; even if a saboteur taps it, they get only ciphertext. Two tunnels = two parallel pipes for redundancy. BGP routing is the smart valve system that auto-redirects flow on failure; static routing is fixed valves that need manual repositioning.

Accelerated VPN is the deep-sea pipeline upgrade that connects to AWS's private undersea cable network (Global Accelerator edge), reducing latency by avoiding the slow surface-shipping route.

ECMP is multiple parallel pipelines to the same AWS facility, each carrying a fraction of the total flow.

Client VPN is the personal pneumatic tube system for remote workers — each user gets their own tube, authenticated by username/cert/SAML.

Site-to-Site VPN Fundamentals

AWS Site-to-Site VPN establishes IPsec tunnels between an AWS endpoint (Virtual Private Gateway or Transit Gateway) and an on-premises Customer Gateway (CGW) device — typically a router or firewall.

Components

• Customer Gateway (CGW): an AWS-side resource representing your on-prem device. You provide the public IP of your device and (optionally) BGP ASN.
• Virtual Private Gateway (VGW) or Transit Gateway (TGW): the AWS-side endpoint terminating the VPN.
• VPN Connection: the resource binding CGW + VGW/TGW with two IPsec tunnels.

Two tunnels per connection — mandatory HA

Each Site-to-Site VPN connection comprises two IPsec tunnels, each terminating on different AWS endpoints (different physical infrastructure, different IP addresses). Both tunnels are active; the customer gateway must be configured to use both — otherwise, AWS-side maintenance on one endpoint causes a connectivity outage.

The tunnel endpoints have inside CIDR (IP-on-tunnel-link, /30) and outside CIDR (the public IP of the AWS endpoint).

Single-tunnel bandwidth limit

Each VPN tunnel has a maximum throughput of approximately 1.25 Gbps. This is a hard ceiling — driven by IPsec processing and network capacity at AWS endpoints. If you need more than 1.25 Gbps, you need ECMP across multiple VPN connections (covered below) or migration to Direct Connect.

IKE Versions and Tunnel Configuration

IKE version

• IKEv1 (legacy): supported but considered insecure for new deployments.
• IKEv2 (recommended): modern default, faster reconnection, supports MOBIKE for IP changes, robust against modern threats.

ANS-C01 expects IKEv2 as the recommended default; IKEv1 is the legacy fallback.

Authentication

• Pre-shared key (PSK): AWS auto-generates or customer provides; simple but key rotation is operationally manual.
• Certificate-based authentication: customer provides an ACM Private CA-issued certificate; AWS validates against the CA.

Encryption suite

Modern defaults (recommended):

• Phase 1: AES-256, SHA-2-256, DH group 14 or higher (group 21 = X25519 or P-521).
• Phase 2: AES-256, SHA-2-256, PFS DH group 14+.

Legacy weaker options (DES, SHA-1, DH group 2) are still supported but should be flagged as non-compliant.

DPD (Dead Peer Detection)

Dead Peer Detection is an IKE keepalive mechanism. Default DPD interval: 30 seconds; default DPD threshold: 3 missed (so failure detected at 90s). Tunable. Aggressive settings (10s interval, 2 misses = 20s) for fast failover; default for normal operation.

NAT-T (NAT Traversal)

NAT Traversal is required when the customer gateway sits behind a NAT (rare for production, common for SOHO setups). NAT-T encapsulates IPsec in UDP (port 4500) for NAT-friendly transit.

VGW vs TGW for VPN Termination

You can terminate a Site-to-Site VPN at either a Virtual Private Gateway or a Transit Gateway. The choice has major implications.

VGW (legacy)

• Attached to a single VPC.
• One VPN per VGW (typically; max 10 with a complex pattern).
• Does NOT support ECMP across multiple VPNs — single VPN to a VGW.
• Does NOT support Accelerated VPN — only TGW does.
• Suitable for: simple single-VPC hybrid in legacy deployments.

TGW (modern)

• Hub for multiple VPCs.
• Supports multiple VPN attachments for ECMP (active/active across many VPNs).
• Supports Accelerated VPN (anycast through Global Accelerator).
• Integrates with Direct Connect via Transit VIF.
• Suitable for: any multi-VPC, multi-region, or high-bandwidth hybrid.

Migration path

Most modern AWS networks are TGW-centric; new VPNs should always terminate on TGW unless there's a specific legacy reason. ANS-C01 questions about "modern multi-VPC hybrid" assume TGW.

Static Routing vs BGP Dynamic Routing

A VPN connection can use either static routing or BGP for the routing protocol. The choice has reliability and operational implications.

Static routing

• Configuration: customer specifies on-prem CIDRs in the VPN connection's static route list. AWS adds those CIDRs to the VPN route table; on-prem router has matching static route to AWS CIDR.
• Failover: when one tunnel fails, traffic continues on the other automatically (AWS handles), but route propagation does not adapt to dynamic conditions.
• Use cases: customer gateway does not support BGP, simple single-tunnel hybrid.

BGP dynamic routing

• Configuration: customer router runs BGP with AWS; on-prem CIDRs are advertised via BGP, AWS CIDRs are received via BGP.
• Failover: BGP convergence handles tunnel failures, route changes, and bandwidth-aware path selection (when ECMP).
• Use cases: required for ECMP, recommended for active/active, mandatory for Accelerated VPN.

When BGP is mandatory

• ECMP: BGP advertisements with equal AS-PATH on multiple VPN connections.
• Accelerated VPN: only supported with BGP.
• Active/active load sharing across two tunnels: BGP convergence required.

For modern deployments, BGP is the default. Static routing is the fallback for non-BGP-capable customer gateways.

Accelerated Site-to-Site VPN

Accelerated VPN routes IPsec tunnels through the AWS Global Accelerator anycast network — IPsec packets enter the Global Accelerator edge POP nearest the customer gateway, traverse the AWS backbone, and exit to the TGW.

Why it improves latency

Public-internet VPN paths add latency from BGP-routing inefficiencies, ISP congestion, and submarine cable jitter. Accelerated VPN's IPsec packets travel the AWS backbone for most of the trip — predictable latency, consistent throughput, fewer packet drops.

Requirements

• TGW termination (not VGW).
• BGP routing (not static).
• Customer gateway with a public IP (not behind NAT).
• Accelerated VPN flag set at VPN connection creation; cannot be enabled on existing VPN.

When to use

• Customer is geographically distant from the target AWS region (>50ms baseline latency).
• Latency-sensitive applications (real-time gaming, VoIP, financial trading) cross the VPN.
• Public internet latency is variable and SLA-relevant.

Cost

Accelerated VPN incurs an additional per-hour fee plus standard VPN data-transfer fees. The Global Accelerator portion has its own per-GB fee. For most modest-latency workloads, Accelerated VPN is overkill; for distant sites it can be transformative.

ECMP — Equal-Cost Multi-Path for Bandwidth Aggregation

A single VPN tunnel caps at ~1.25 Gbps. To exceed this, ECMP across multiple VPN connections to the same TGW is the canonical pattern.

How ECMP works

Multiple Site-to-Site VPN connections terminate on the same TGW, all with identical BGP attributes. AWS computes equal-cost paths and load-balances traffic across them via 5-tuple hash (source IP, source port, destination IP, destination port, protocol). 4 VPN connections × 1.25 Gbps each = 5 Gbps aggregate.

Requirements

• TGW termination (VGW does NOT support ECMP).
• BGP routing on each VPN connection.
• Identical BGP attributes (AS-PATH length, MED, etc.) across the connections; if attributes differ, BGP picks one path and ECMP doesn't apply.
• TGW VPN ECMP flag enabled on the TGW (default on for new TGWs).

Customer-side configuration

The customer's on-prem router must also be configured for ECMP — multiple BGP sessions to AWS, equal-weight installation in the routing table, and consistent 5-tuple hashing for symmetric distribution. Each VPN connection's two tunnels are independent (so 4 VPN connections = 8 tunnels total), but BGP-level ECMP treats each connection as a single equal-cost path.

Bandwidth scaling

• 1 VPN connection = 1.25 Gbps (single tunnel; or 2.5 Gbps if both tunnels active and ECMP-aware on customer side).
• 2 VPN connections = ~2.5 Gbps.
• 4 VPN connections = ~5 Gbps.
• 8 VPN connections = ~10 Gbps.

Beyond 10 Gbps, Direct Connect is more cost-effective. ANS-C01 will scenario this trade-off: "we need 8 Gbps; ECMP with 7 VPN connections, or a 10 Gbps Direct Connect?" — the answer depends on whether DX is feasible (location, regulatory).

AWS Client VPN — Remote Worker Access

AWS Client VPN is a managed OpenVPN-based service for individual users to access AWS VPCs (and optionally on-prem networks via the VPC).

Components

• Client VPN endpoint: regional endpoint, has a private DNS name (e.g. cvpn-endpoint-XXX.prod.clientvpn.us-east-1.amazonaws.com).
• Target subnets (VPC associations): one or more subnets in the VPC associated with the endpoint; clients reach resources in or routable from these subnets.
• Authorization rules: allow specific user groups to access specific destination CIDRs.
• Routes: routes from the endpoint to destinations (VPC subnets, on-prem CIDRs via VGW).

Authentication methods

• Mutual TLS (cert-based): clients present a certificate signed by a customer-owned CA.
• Active Directory (via AWS Directory Service): username/password against AD.
• SAML federation (via IdP like Okta, Azure AD): SAML 2.0 federation with the customer's IdP.

Authorization rules

After authentication, authorization rules govern which users can reach which destinations. Rules can be tied to AD groups or SAML attributes.

Split-tunnel vs full-tunnel

• Split-tunnel (default): only traffic destined to associated VPC/on-prem CIDRs goes through the VPN; everything else (e.g. user's general internet browsing) goes via the user's local internet. Reduces VPN load and improves user experience.
• Full-tunnel: ALL traffic from the user's device goes through the VPN. Useful for compliance scenarios where all user traffic must be inspected.

Connection logging

Client VPN logs connection events to CloudWatch Logs (per-endpoint configuration): connect, disconnect, authenticated, authorization-failed events.

VPN over Direct Connect — Layered Encryption

For scenarios requiring IPsec encryption layered on top of Direct Connect (e.g. compliance regimes that mandate IPsec end-to-end even when traversing private DX), you can run a Site-to-Site VPN through a Direct Connect Public VIF.

How it works

The VPN's outer IP packets traverse the Direct Connect Public VIF (which can carry traffic to AWS public endpoints, including VPN endpoint IPs). IPsec encrypts the inner traffic. The path is: customer router → DX Public VIF → AWS public network → VPN endpoint → VPC.

Why use it

• Compliance: certain regulatory regimes (FedRAMP, HIPAA, certain financial) mandate IPsec encryption regardless of underlying physical path.
• Belt-and-suspenders: layering encryption on top of MACsec-encrypted DX provides defense-in-depth.
• Pre-MACsec environments: when MACsec is unavailable (hosted DX, older DX locations), VPN-over-DX provides equivalent encryption.

Trade-offs

• Latency overhead: IPsec adds processing latency (typically 1–5ms per direction).
• Bandwidth overhead: IPsec headers reduce effective payload (~2-5%).
• Complexity: BGP for VPN AND BGP for DX, layered routing decisions.

For most enterprise scenarios, MACsec on dedicated DX is the cleaner answer. VPN-over-DX is for compliance-driven or hosted-DX-without-MACsec cases.

Tunnel Resilience Patterns

Dual-tunnel resiliency on Site-to-Site

The two tunnels per connection are independent — different AWS endpoints, different IP addresses. Customer gateway must terminate both for HA. AWS-side maintenance on one endpoint affects only one tunnel; the other carries traffic.

Tunnel endpoint IPs

AWS provides two tunnel endpoint IPs per VPN connection (one per tunnel). The customer gateway should be configured with both as IKE peers.

Tunnel maintenance windows

AWS performs occasional maintenance on tunnel endpoints (rare, usually during off-peak). Maintenance is per-tunnel, not both at once. Active customer gateways should ride out maintenance via the unaffected tunnel.

Static IP for AWS tunnel endpoints

AWS tunnel endpoint IPs are static for the VPN connection's lifetime. Customer firewalls can whitelist these IPs.

Customer gateway HA

For customer-side HA, deploy two customer gateways (separate physical devices, separate network paths) with separate VPN connections to the same TGW. ECMP across the two pairs of tunnels gives both bandwidth aggregation and customer-side device redundancy.

Common Traps Recap — VPN on ANS-C01

Trap 1: A single VPN connection delivers more than 1.25 Gbps per tunnel

Wrong. Each tunnel maxes at ~1.25 Gbps; total connection ~2.5 Gbps with both active.

Trap 2: ECMP works on VGW

Wrong. ECMP requires TGW, not VGW.

Trap 3: Accelerated VPN works with static routing

Wrong. Accelerated VPN requires BGP.

Trap 4: Both tunnels of a Site-to-Site VPN must be configured

Best practice yes, but technically you can use just one. Without both, AWS-side maintenance kills connectivity.

Trap 5: IKEv1 is recommended

Wrong. IKEv2 is the recommended modern default.

Trap 6: Client VPN supports certificate-only auth

Wrong. Client VPN supports cert, AD, and SAML.

Trap 7: Split-tunnel is always the default

Partial. Default for new endpoints; older endpoints default to full-tunnel.

Trap 8: VPN over DX adds no latency

Wrong. IPsec processing adds 1–5ms per direction.

Trap 9: Customer gateway can be NAT'd

Partial. Yes via NAT-T (UDP 4500), but introduces complexity. Public IP is preferred.

Trap 10: BGP is required for Site-to-Site VPN

Wrong. BGP is recommended; static routing is supported as fallback.

Trap 11: ECMP requires identical CGW IPs

Wrong. Different CGW IPs are fine; what's required is identical BGP attributes (AS-PATH, MED).

Trap 12: Client VPN can directly access on-prem networks

Partial. Yes if the VPC has VGW/TGW connectivity to on-prem, and authorization rules + routes are added to the Client VPN endpoint.

FAQ — VPN on ANS-C01

Q1: How do I architect 5 Gbps of VPN bandwidth to AWS?

A single VPN tunnel caps at ~1.25 Gbps. The canonical pattern: 4 Site-to-Site VPN connections to a Transit Gateway, each with BGP, with ECMP enabled on TGW. Each VPN connection contributes ~1.25 Gbps of usable bandwidth (using one of its two tunnels actively); 4 × 1.25 = 5 Gbps aggregate. Customer side: 4 separate BGP sessions, equal-weight installation, 5-tuple ECMP hash for symmetric outbound distribution. Alternative: migrate to Direct Connect (10 Gbps minimum dedicated); cost-vs-time-to-deploy decides. ANS-C01 will reward the ECMP pattern when the question disallows DX (e.g. "tomorrow morning" deadline, or "no colocation presence").

Q2: When should I use Site-to-Site VPN vs Direct Connect?

Use Site-to-Site VPN when (a) bandwidth need is below 5 Gbps with ECMP, (b) time-to-deploy is critical (hours vs weeks), (c) cost is a primary driver, (d) the workload tolerates public-internet latency variability. Use Direct Connect when (a) bandwidth exceeds VPN ECMP scaling (>5 Gbps), (b) latency must be predictable and low (<10ms), (c) regulatory regime forbids public-internet transit, (d) MACsec layer-2 encryption is required. Hybrid: use DX as primary with VPN as backup — best of both worlds. ANS-C01 will reward the hybrid pattern for "tier-1 production hybrid" and pure VPN for "branch office" or "bootstrap migration".

Q3: How does Accelerated VPN improve over standard Site-to-Site VPN?

Accelerated VPN routes IPsec tunnels through the AWS Global Accelerator anycast edge network instead of public internet. The customer gateway sends IPsec packets to the Global Accelerator anycast IP at the closest edge POP (often <10ms latency), and traffic traverses the AWS backbone to the TGW. Result: reduced latency variance, lower jitter, fewer packet drops. Most beneficial when the customer gateway is geographically distant from the target AWS region (>50ms baseline). Requirements: TGW (not VGW), BGP routing, additional per-hour fee. The Specialty answer for "real-time gaming on a VPN from Singapore to us-east-1": Accelerated VPN, definitely.

Q4: What is the difference between Client VPN and Site-to-Site VPN?

Site-to-Site VPN is router-to-router IPsec — connects an entire on-prem network to AWS, configured at the customer's edge router. Per-connection cost; supports ECMP, BGP, Accelerated mode. Best for branch-office or DC-to-AWS connectivity. Client VPN is per-user OpenVPN — individual remote workers authenticate (cert/AD/SAML), get a tunnel to AWS, and access VPC resources (and optionally on-prem via the VPC). Per-connection-hour cost. Best for remote worker access. Different services, different use cases. ANS-C01 will distinguish "remote workers" (Client VPN) from "branch office" (Site-to-Site).

Q5: How do split-tunnel and full-tunnel differ on Client VPN, and when do I use each?

Split-tunnel: only traffic to associated networks (VPC CIDRs, on-prem CIDRs in routes) goes through the VPN. The user's general internet browsing uses their local ISP. Reduces VPN load (cheaper, faster). Full-tunnel: ALL traffic from the user's device goes through the VPN. AWS sees and can inspect every packet. Higher VPN load, but useful for compliance ("all corporate traffic must be inspected by enterprise tools") or content filtering ("block social media for remote workers"). Default for new endpoints: split-tunnel. The Specialty answer for "remote worker performance optimization": split-tunnel. For "compliance traffic inspection": full-tunnel.

Q6: How does ECMP scale beyond what a single VPN connection can deliver?

ECMP (Equal-Cost Multi-Path) load-balances traffic across multiple equal-cost BGP paths via 5-tuple hash. Architecture: N Site-to-Site VPN connections terminating on the same TGW, all advertising the same prefixes with identical BGP attributes (same AS-PATH, MED). TGW computes N equal-cost paths and hashes flows across them. Since each VPN tunnel caps at 1.25 Gbps, N connections give roughly N × 1.25 Gbps aggregate. Customer side: N parallel BGP sessions, equal-weight installation, identical hashing. Limits: TGW-only (not VGW), BGP-required, all attributes must be identical. The exam scenario for "scale beyond single-VPN bandwidth without buying DX": ECMP across N VPN connections.

Q7: When should I use VPN over Direct Connect for layered encryption?

Use VPN over DX when (a) compliance regime requires IPsec encryption end-to-end regardless of physical path (FedRAMP, certain HIPAA scenarios), (b) MACsec is unavailable (hosted DX, older DX locations), (c) defense-in-depth is mandated (layer the IPsec on top of MACsec for max paranoia). Architecture: customer router → DX Public VIF → AWS public IP of VPN endpoint → IPsec tunnel → VGW/TGW → VPC. Trade-offs: 1-5ms additional latency for IPsec processing, 2-5% bandwidth overhead for headers, doubled BGP complexity. ANS-C01 scenarios: "compliance requires IPsec, customer has hosted DX (no MACsec)" → VPN over DX is the answer.

Q8: What does Dead Peer Detection (DPD) do for VPN failover?

DPD is an IKE keepalive protocol — each peer periodically (default 30 seconds) checks the other is alive. After 3 missed checks (default), the tunnel is declared dead and IPsec re-negotiation triggers. Default DPD detects failure in ~90 seconds — too slow for production-grade failover. Tune DPD on the customer gateway to aggressive settings: 10-second interval, 2 missed = 20-second detection. Combined with BGP convergence (~5–30 seconds), total failover time can be sub-30-seconds. The Specialty answer for "minimize VPN failover time": tune DPD aggressively + use BGP routing + use both tunnels actively.

Q9: What authentication options does AWS Client VPN support, and when do I pick each?

Three options: (a) Mutual certificate — clients present a cert signed by a customer-owned CA; AWS validates against the CA. Best for IoT or service-account scenarios. (b) Active Directory — username/password authenticated against AWS Directory Service or AD Connector. Best for traditional Windows-domain environments. (c) SAML federation — clients authenticate via the customer's IdP (Okta, Azure AD, OneLogin) and present SAML assertion to Client VPN. Best for modern SSO environments with MFA, conditional access. SAML is the most common modern choice. The Specialty answer for "remote workers with corporate SSO and MFA": SAML federation.

Q10: How do I architect VPN as backup to Direct Connect with automatic failover?

Architecture: primary path is Direct Connect (Private/Transit VIF) with BGP advertising on-prem prefixes. Secondary path is Site-to-Site VPN to the same VGW or TGW, also with BGP. Both BGP sessions advertise the same on-prem prefixes; AWS prefers the DX path because (a) Direct Connect's BGP advertisements have shorter AS-PATH by default, (b) you can explicitly AS-PATH-prepend the VPN advertisement to make it less preferred. On DX failure (BGP session drop or BFD timeout), AWS converges to VPN within seconds. On DX recovery, AWS reverts to DX automatically. Customer side: similar BGP setup with LOCAL_PREF preferring the DX path for outbound. Failover testing: shut the DX BGP session, verify VPN takes over, restore. ANS-C01 will reward this pattern as the "tier-1 hybrid with cost-effective backup" answer.

Further Reading and Related Operational Patterns

• AWS Site-to-Site VPN User Guide
• Accelerated Site-to-Site VPN
• AWS Client VPN Administrator Guide
• Transit Gateway VPN Attachments
• Site-to-Site VPN Tunnel Options
• Client VPN Authentication
• Customer Gateway Options

Once VPN architecture is in place, the natural next operational layers on ANS-C01 are: Direct Connect — VIF Types, LAG, MACsec, and BGP for the dedicated alternative or the primary-with-VPN-backup pattern; BGP Configuration — AS-Path Prepending, MED, Communities, and BFD for the routing-attribute deep-dive that traffic-engineers VPN paths; Transit Gateway — Routing Tables, Attachments, and Connect which is the modern VPN termination point and ECMP enabler; and Network Encryption — TLS, ACM, IPsec, and MACsec for the cryptographic deep-dive on every layer.

• Direct Connect — VIF Types, LAG, MACsec, and BGP — ANS-C01 Study Notes
• BGP Configuration — AS-Path Prepending, MED, Communities, and BFD — ANS-C01 Study Notes
• Transit Gateway — Routing Tables, Attachments, and Connect — ANS-C01 Study Notes
• Network Encryption — TLS, ACM, IPsec, and MACsec — ANS-C01 Study Notes