Amazon ANS-C01: Hybrid Connectivity: VPN and Direct Connect — Study Guide
Part of the AWS Advanced Networking Specialty ANS-C01 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Core concepts
Hybrid connectivity in AWS is the combination of privately provisioned network circuits and encrypted IP tunnels to extend on‑premises networks into the AWS cloud. Site‑to‑Site VPN provides IPsec tunnels (IKEv1/IKEv2) terminated on a Virtual Private Gateway (VGW) or Transit Gateway; AWS provisions two independent tunnels per VPN connection for resiliency and supports BGP for dynamic routing or static routes if required. Client VPN is an OpenVPN‑based managed endpoint that supports mutual certificate authentication (ACM Private CA or uploaded client certificates) or SAML federation for user identity, route propagation into a VPC or Transit Gateway, and client‑side split‑tunnelling to limit traffic passing into AWS.
AWS Direct Connect offers a dedicated physical connection between your premises and AWS. Connections may be dedicated (provisioned with AWS) or hosted (provisioned by a partner); you can aggregate multiple connections using a Link Aggregation Group (LAG) to present a single logical interface and increase bandwidth; Direct Connect supports private virtual interfaces (private VIF) to VPCs, public VIF for AWS public endpoints, and transit VIF to a Direct Connect Gateway for multi‑Region or Transit Gateway connectivity. For data protection on the physical link, MACsec is available at supported locations to provide layer‑2 frame encryption between the customer edge and the AWS edge, and encryption in flight at layer 3 remains the responsibility of IPsec or TLS endpoints.
Reliability and routing require explicit control of failover and path selection. BGP attributes (local‑preference, AS path prepending) are used to prefer Direct Connect over VPN for low latency and high throughput, with Site‑to‑Site VPN or a secondary DX connection acting as an automatic backup. When end‑to‑end TLS is required, or when applications require client source IP preservation and very large numbers of long‑lived TCP connections (for example gRPC over TLS on port 443), use TCP/TLS passthrough patterns such as a Network Load Balancer (NLB) or direct public endpoints on EKS nodes with appropriate security controls; when termination at the edge is acceptable, Application Load Balancer (ALB) supports HTTP/2 and gRPC and terminates TLS, inserting X‑Forwarded‑For headers so backend pods can log client IPs.
Key services and configuration
When creating Site‑to‑Site VPN, you use the EC2 CreateVpnConnection API (aws ec2 create-vpn-connection) and typically attach the resulting vpn‑connection to a virtual private gateway (create-vpn-gateway and attach-vpn-gateway) or to a transit gateway by specifying transit-gateway-id. Configure the customer gateway device with the generated tunnel parameters: IKE version, encryption algorithms (AES‑GCM), hashing (SHA‑2), Diffie‑Hellman group, lifetime, and the pre‑shared key. For dynamic routing, enable BGP and set up the BGP neighbor ASN and IP; for faster detection of failover at the router layer use BFD where supported between on‑prem devices and the AWS edge.
Client VPN endpoints are created via the EC2 CreateClientVpnEndpoint API (aws ec2 create-client-vpn-endpoint). You provide a server certificate from ACM, an authentication option (certificate or SAML), and associate the endpoint with one or more VPC subnets to create elastic network interfaces. Use authorize-client-vpn-ingress to open allowed networks per authorization rule and create-client-vpn-route to push routes into the VPC. For large user populations and conditional access, integrate Client VPN with AWS Directory Service or SAML identity providers, and scale concurrently by assigning sufficient CIDR address ranges to the Client VPN endpoint.
Direct Connect provisioning uses the Direct Connect APIs such as create-connection or, for partner connections, the partner provisions a hosted connection and you use allocate-hosted-connection or accept-virtual-interface APIs. To aggregate physical links, call create-lag and then create-private-virtual-interface or create-transit-virtual-interface to attach a virtual interface to a VPC or Direct Connect Gateway. For MACsec, work with the partner or AWS ordering portal to request MACsec on the connection; configuration includes key exchange and matching cipher suite on the customer edge switch, and operational commands are usually coordinated at provisioning time. For multi‑VPC architectures, prefer a Direct Connect Gateway with a transit VIF to connect to a Transit Gateway — this scales better than creating many private VIFs and allows centralized routing through TGW route tables.
Design patterns and trade-offs
Choose an active‑active architecture for high throughput and low failover time by placing two Direct Connect connections in different locations, advertising identical prefixes with BGP and using LAG for link bundling within a site. Active‑active with BGP multipath gives superior performance and true load sharing; however, that requires symmetric routing, compatible on‑prem BGP, and careful AS‑path and local‑preference tuning. Use Site‑to‑Site VPN as an automatic active‑passive backup because IPsec tunnels are resilient and globally reachable, but expect higher jitter, lower throughput, and longer failover times compared to Direct Connect. Where deterministic, low‑latency connectivity is mandatory, a second DX connection is preferable despite higher cost.
For application‑level TLS requirements, design choices depend on whether the load balancer is allowed to see decrypted traffic. If end‑to‑end mutual TLS is required, terminate TLS at the backend by using an NLB in TCP/TLS passthrough mode and let Kubernetes Ingress pods handle mTLS; use target type ip for EKS so pods can scale and Cluster Autoscaler can add nodes without changing NLB configuration, and enable proxy protocol v2 if you need the original client source IP at the pod. If TLS termination at the ALB is acceptable, use ALB with HTTPS listener, configure certificates in ACM, enable HTTP/2 for gRPC support, and rely on X‑Forwarded‑For for client IPs; ALB gives path‑based routing to multiple target groups for URL‑based dispatch.
For multi‑account, multi‑VPC connectivity where granular security and scale are required, a hub‑and‑spoke pattern with Transit Gateway and a centralized Direct Connect Gateway provides the best scale. Attach each business‑unit VPC to a Transit Gateway (TGW) and associate the TGW with a Direct Connect Gateway through a transit VIF. Use TGW route tables to enforce segregation and use resource‑level policies, Security Groups, and Network ACLs for granular controls. The trade‑off is operational complexity in managing TGW route tables and the need to design IAM and account boundaries carefully.
Common pitfalls and decision criteria
A frequent mistake is relying on a single VIF per VPC without considering VIF limits and the operational complexity as the number of VPCs grows; use Direct Connect Gateway and transit VIFs when you anticipate many VPCs or multiple Regions. Another common pitfall is assuming VPN and Direct Connect behave identically: IPsec rekeys, MTU implications, and per‑tunnel throughput differences mean VPN is a reliable backup but not a performance equivalent. Misconfiguring TLS termination and downstream client IP expectations is another source of errors — choose NLB passthrough for true end‑to‑end TLS with mTLS, or ALB termination and X‑Forwarded‑For processing if the edge can terminate TLS.
Finally, monitoring and visibility are essential. Enable CloudWatch metrics for Direct Connect (ConnectionBpsEgress/Ingress), flow logs for VPC visibility, and use CloudWatch alarms to trigger automation to shift traffic or notify network engineers. For forensic traffic attribution when multiple business units share bandwidth on a LAG, correlate VIF statistics and VPC flow logs and consider per‑VPC bandwidth controls at the edge to avoid noisy neighbor issues.
Practical Problem: Use-Case Scenario
Company: Meridian Medical Analytics. Challenge: Meridian operates a global fleet of medical imaging devices that use gRPC over TCP port 443 to upload high‑volume encrypted streams to a backend hosted in an Amazon EKS cluster in us-east-1. The devices require mutual TLS for two‑way client authentication and thousands of concurrent, long‑lived connections. The EKS cluster scales automatically with Cluster Autoscaler and HPA. Meridian needs deterministic low latency from their primary datacenter and automatic failover to the cloud VPN.
Approach:
- Provision a Network Load Balancer (NLB) in front of the EKS service with TCP listeners on port 443 and target type set to IP so pod endpoints can be targets directly; configure the NLB for TLS passthrough (do not terminate TLS at the NLB) so mutual TLS is negotiated with the backend pods. Use aws elbv2 create-load-balancer and create-listener to configure the NLB and target groups.
- Configure EKS pod containers (Ingress or sidecar) to terminate mutual TLS using server and client certificates from a private CA (ACM Private CA for issuing server certs; client certs provisioned to devices). Ensure pods support HTTP/2 gRPC and scale via HPA and Cluster Autoscaler; use target group deregistration delay tuned for long‑lived connections.
- For on‑prem connectivity, provision a Direct Connect dedicated connection (create-connection) aggregated with a LAG if multiple physical circuits are available, and create a private virtual interface (create-private-virtual-interface) to a Direct Connect Gateway attached to your Transit Gateway for routing to the EKS VPC. Enable MACsec at provisioning if the carrier and location support it to secure layer‑2 transport.
- Implement Site‑to‑Site VPN (aws ec2 create-vpn-connection to a Transit Gateway) as an automatic failover path; control failover with BGP attributes by preferring Direct Connect (higher local‑preference) and letting VPN inherit lower preference. Use BFD where supported for faster path failure detection. Monitor Direct Connect and VPN metrics in CloudWatch and set alarms to trigger traffic engineering changes or notifications.
AWS rationale: The NLB TCP passthrough preserves end‑to‑end mutual TLS so device client certs are validated by backend pods, which satisfies the requirement that traffic not be decrypted at the edge. Target type IP and NLB support scale for thousands of concurrent long‑lived connections while preserving client IP with proxy protocol or by reading client IP from the TLS session if needed. Direct Connect provides deterministic, high‑bandwidth connectivity to us‑east‑1 with LAG for capacity and MACsec for physical link encryption; Site‑to‑Site VPN provides a globally reachable, encrypted backup path with BGP‑mediated failover. This design balances security, performance, and scalability while aligning with AWS Direct Connect and VPN configuration best practices.
← VPC Design and Advanced Networking · All domains · Transit Gateway and Network Topology →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →