Cargando...
Cargando...
Master every pattern for connecting your data center to AWS — and never miss an exam question about it.
Hybrid connectivity patterns define how on-premises infrastructure securely and reliably communicates with AWS resources. Understanding when to use Site-to-Site VPN, AWS Direct Connect, Transit Gateway, or combinations thereof is a cornerstone of AWS networking exams across Solutions Architect, Advanced Networking, and SysOps tracks. The right pattern depends on latency, bandwidth, cost, redundancy, and compliance requirements — and exams test your ability to reason through these trade-offs under realistic scenario constraints.
Exam questions present a business scenario (e.g., 'low latency required', 'cost-sensitive', 'backup path needed') and expect you to select the correct hybrid connectivity pattern — knowing the strengths, weaknesses, and combinations of each option is what separates passing from failing scores.
AWS Site-to-Site VPN
An encrypted IPsec tunnel established over the public internet between a Customer Gateway (CGW) on-premises and a Virtual Private Gateway (VGW) or Transit Gateway (TGW) on the AWS side. Supports static or dynamic routing (BGP). Each VPN connection consists of two tunnels for high availability. Traffic traverses the public internet, so latency is variable.
Quick setup (minutes to hours), budget-conscious scenarios, backup/failover path for Direct Connect, branch offices with modest bandwidth needs, or when consistent low latency is NOT a hard requirement.
Variable latency and throughput limited by internet conditions; not suitable for latency-sensitive workloads or very high throughput; per-hour connection cost plus data transfer charges apply.
AWS Direct Connect (DX)
A dedicated private network connection from on-premises to AWS via an AWS Direct Connect location (colocation facility). Provides consistent network performance, reduced bandwidth costs for high-volume transfers, and does NOT traverse the public internet. Supports Private Virtual Interfaces (Private VIF) to VPCs, Public VIFs to AWS public services, and Transit VIFs to Transit Gateway. Available in 1 Gbps, 10 Gbps, and 100 Gbps hosted or dedicated connection speeds.
Consistent low latency, high throughput requirements, regulatory/compliance mandates for private connectivity, large data transfer volumes where per-GB savings outweigh DX port costs, or hybrid workloads requiring predictable performance.
Provisioning takes weeks; higher baseline cost (port-hour + data transfer pricing); single DX connection is a single point of failure — must be combined with a second DX or VPN for resilience.
Direct Connect + Site-to-Site VPN (Backup/Redundancy Pattern)
Primary traffic flows over Direct Connect for performance; a Site-to-Site VPN over the public internet serves as an automatic failover path. BGP routing is used to prefer DX (higher local preference or lower MED) and fall back to VPN when DX fails. This is the AWS-recommended high-availability architecture for mission-critical hybrid workloads.
Production workloads that require both consistent performance AND high availability; regulated industries where downtime is unacceptable; any scenario where a single DX connection is present without a second DX.
Operational complexity of managing two connection types; VPN failover may introduce latency spike during transition; both connection costs apply simultaneously.
AWS Transit Gateway (TGW) with VPN or Direct Connect
Transit Gateway acts as a regional network hub that simplifies connectivity between multiple VPCs and on-premises networks. Instead of creating a full mesh of VPN or DX connections to each VPC, on-premises connects once to TGW via VPN or Direct Connect Transit VIF, and TGW routes to all attached VPCs. Supports inter-region peering and centralized routing policies.
Organizations with many VPCs (5+) that all need on-premises access; hub-and-spoke network topology; centralized security inspection (e.g., firewall appliance in a shared services VPC); multi-account AWS environments using AWS Organizations.
Additional per-attachment and per-GB data processing charges on top of VPN/DX costs; adds a routing hop; requires careful route table design to avoid unintended connectivity between VPCs.
Direct Connect Gateway (DXGW)
A globally available resource that allows a single Direct Connect connection to reach VPCs in multiple AWS Regions (up to the allowed number of VGW or TGW associations per DXGW). Eliminates the need for separate DX connections per region. Works with Private VIFs and Transit VIFs.
Multi-region architectures where on-premises needs low-latency access to VPCs across different AWS Regions using a single DX connection; global enterprises with one or two DX locations serving worldwide AWS footprint.
Does NOT allow VPC-to-VPC routing through DXGW (only on-premises ↔ VPC); inter-region data transfer charges still apply; limited number of VGW/TGW associations per DXGW.
AWS VPN CloudHub
A hub-and-spoke VPN pattern where multiple branch offices (each with their own Customer Gateway) connect to a single Virtual Private Gateway. Branch offices can communicate with each other through the VGW hub in addition to reaching the VPC. Uses BGP and requires each branch to advertise unique ASNs and non-overlapping IP ranges.
Organizations with multiple branch offices that need both AWS VPC access AND branch-to-branch communication over a low-cost VPN fabric; replacing or augmenting MPLS for branch interconnection.
Traffic between branches traverses the public internet (encrypted); VGW is a potential bottleneck; not suitable for high-bandwidth branch-to-branch workloads; all branches must have non-overlapping CIDR ranges.
AWS Managed VPN with Accelerated Site-to-Site VPN
An enhanced VPN option that uses AWS Global Accelerator to route VPN traffic from the customer's on-premises location to the nearest AWS edge location, then over AWS's private global backbone to the target region. Reduces latency and improves reliability compared to standard internet-based VPN.
Geographically distant on-premises locations where standard internet routing introduces high latency; situations where Direct Connect is not yet provisioned but performance beyond standard VPN is needed.
Additional hourly and data transfer charges for Global Accelerator on top of standard VPN costs; still encrypted over a managed path — not a true private connection like Direct Connect.
AWS Private Link for Hybrid (PrivateLink + Direct Connect/VPN)
AWS PrivateLink enables private connectivity to AWS services (S3, DynamoDB, SaaS) or customer-owned services via Interface VPC Endpoints. When combined with Direct Connect Private VIF or VPN, on-premises clients can access AWS services without traversing the public internet, keeping all traffic on private IP space.
Compliance requirements that prohibit any traffic to AWS services (S3, SQS, etc.) from touching the public internet; accessing third-party SaaS products privately; exposing on-premises services to AWS consumers without VPC peering.
Interface endpoints have per-hour and per-GB charges; requires careful DNS configuration (Private Hosted Zones or on-premises DNS forwarding) to resolve endpoint DNS names to private IPs from on-premises.
• STEP 1 — What is the primary requirement?
→ 'Consistent low latency / high throughput / private connection' → Direct Connect (DX)
→ 'Quick setup / low cost / acceptable variable latency' → Site-to-Site VPN
→ 'Both performance AND resilience' → DX primary + VPN backup
• STEP 2 — How many VPCs need on-premises access?
→ 1–4 VPCs in one region → VGW per VPC (simple)
→ 5+ VPCs OR multi-account → Transit Gateway (hub-and-spoke)
→ Multi-region VPCs from single DX → Direct Connect Gateway (DXGW)
• STEP 3 — Is there a redundancy requirement?
→ Single DX only → Add VPN as backup (DX + VPN pattern)
→ Maximum resilience → Two DX connections from separate providers + VPN
→ Multiple branch offices needing inter-branch comms → VPN CloudHub
• STEP 4 — Is internet avoidance required for AWS service access?
→ Yes (S3, SQS, etc. must stay private) → Interface VPC Endpoints via PrivateLink over DX/VPN
→ No → Gateway Endpoints (S3/DynamoDB, free) or public endpoints
• STEP 5 — Is geography/latency optimization needed for VPN?
→ On-premises is far from AWS region → Accelerated Site-to-Site VPN
→ On-premises is near an AWS Direct Connect location → Standard DX
A single Direct Connect connection has NO built-in redundancy. AWS explicitly recommends a second DX connection OR a Site-to-Site VPN as a backup. Any exam scenario asking for 'high availability hybrid connectivity' that offers only a single DX option is a trap — the correct answer always includes a redundant path.
Direct Connect Gateway (DXGW) does NOT route traffic between VPCs — it only facilitates on-premises ↔ VPC connectivity across regions. If a question asks how VPCs in different regions communicate through a DXGW, the answer is: they don't. VPC-to-VPC routing requires Transit Gateway peering or VPC peering separately.
Transit VIF (Virtual Interface) is required to connect Direct Connect to Transit Gateway. Private VIF connects DX to a VGW (single VPC or DXGW). Public VIF connects DX to AWS public services (S3, DynamoDB public endpoints, etc.). Mixing these up on exams is extremely common.
For on-premises access to S3 or DynamoDB over Direct Connect without using public IP space, you need a Gateway VPC Endpoint (free, no data processing charge) OR an Interface Endpoint via PrivateLink (charged). Gateway Endpoints only work from within a VPC — on-premises clients accessing S3 privately over DX must use a Public VIF OR an Interface Endpoint with DNS forwarding. This is a nuanced and frequently tested distinction.
Single Direct Connect = single point of failure. Always pair with a second DX or Site-to-Site VPN backup for any HA requirement.
Direct Connect Gateway routes on-premises ↔ VPC only — it CANNOT route VPC-to-VPC traffic across regions. Use TGW inter-region peering for that.
Gateway VPC Endpoints (S3/DynamoDB) are NOT reachable from on-premises over DX or VPN. Use Interface Endpoints with DNS forwarding for private on-premises access to S3.
VPN CloudHub requires each Customer Gateway to advertise a unique BGP ASN and non-overlapping IP prefixes. If a scenario describes overlapping on-premises IP ranges needing to connect via CloudHub, this architecture will NOT work — this is a deliberate distractor in exam questions.
Accelerated Site-to-Site VPN uses AWS Global Accelerator under the hood. It is NOT the same as a standard VPN — it costs more but provides significantly better performance for geographically distant connections. Exam questions will describe 'inconsistent VPN performance from a remote office' and the correct answer is Accelerated VPN, not Direct Connect, when cost or time-to-provision is a constraint.
When BGP is used with both DX and VPN to the same VGW/TGW, Direct Connect routes are preferred over VPN routes by default due to BGP path selection (DX has a higher local preference in AWS's BGP implementation). You can influence this with AS_PATH prepending or MED attributes. Understanding this is key for failover design questions.
AWS Site-to-Site VPN connections consist of TWO tunnels for redundancy, each terminating on a different AWS endpoint. Both tunnels should be configured and monitored — if only one tunnel is active and it fails, the connection goes down. Exam scenarios about VPN redundancy within a single connection refer to these two tunnels.
Common Mistake
Direct Connect is automatically redundant and highly available once provisioned.
Correct
A single Direct Connect connection is a single point of failure. True HA requires either two DX connections (ideally from different providers/facilities) or a DX + VPN backup combination. AWS offers a Resiliency Toolkit to help design the right level of redundancy.
Exam questions routinely offer 'provision a Direct Connect connection' as an HA solution — selecting it without a redundant path is wrong. Always look for the option that includes a second path.
Common Mistake
You can use a Direct Connect Gateway to route traffic between two VPCs in different regions.
Correct
DXGW only enables on-premises ↔ VPC connectivity. It does not route VPC-to-VPC traffic. For inter-region VPC communication, you need Transit Gateway inter-region peering or VPC peering.
This misconception causes candidates to select DXGW as a solution for inter-region VPC routing problems — it cannot do that. The question stem will often describe 'multiple regions' to lure you into choosing DXGW for the wrong reason.
Common Mistake
Site-to-Site VPN is always cheaper than Direct Connect for any workload.
Correct
For high-volume data transfer workloads, Direct Connect's reduced per-GB data transfer pricing can make it cheaper than VPN (which uses standard internet data transfer rates). The break-even point depends on volume — at large scale, DX total cost of ownership is often lower.
Cost optimization questions will describe high data transfer volumes and expect you to recognize that DX can be MORE cost-effective than VPN at scale, not just a premium performance option.
Common Mistake
Gateway VPC Endpoints for S3 can be used by on-premises clients connecting over Direct Connect.
Correct
Gateway Endpoints (for S3 and DynamoDB) are only reachable from within the VPC — they are not accessible from on-premises over Direct Connect or VPN. On-premises clients must use a Public VIF to reach S3's public endpoints, or use an Interface Endpoint (PrivateLink) with proper DNS forwarding to access S3 privately.
This is one of the most tested nuances in hybrid networking. Candidates assume Gateway Endpoints extend to on-premises — they do not. Interface Endpoints do extend to on-premises when DNS is configured correctly.
Common Mistake
Transit Gateway eliminates all data transfer costs between VPCs and on-premises.
Correct
Transit Gateway introduces its own data processing charge per GB of traffic that passes through it, in addition to VPN or Direct Connect data transfer charges. It simplifies architecture but does NOT reduce data transfer costs — it can actually increase them compared to direct VGW-per-VPC approaches for high-throughput scenarios.
TGW is often presented as a cost-saving measure in exam distractors. Its value is in operational simplicity and scalability, not cost reduction for data transfer.
Common Mistake
VPN CloudHub allows branch offices with overlapping IP ranges to communicate.
Correct
VPN CloudHub requires all connected branch offices to have non-overlapping IP address ranges and unique BGP ASNs. Overlapping CIDRs make routing impossible and CloudHub will not function correctly.
Exam scenarios will describe a CloudHub setup and then mention overlapping IPs — the correct answer is that this configuration will fail, not that it will work with some workaround.
DX = Dedicated eXperience (consistent, private, premium) | VPN = Variable Path Network (cheap, flexible, internet-dependent)
VIF Types: 'PPT' — Private VIF → Private VPC, Public VIF → Public AWS services, Transit VIF → Transit Gateway
DXGW Rule: 'One Way Only' — on-premises talks to VPCs, but VPCs don't talk to each other through DXGW
Redundancy mantra: 'One DX alone will let you down — pair it with VPN or a second crown'
Gateway Endpoint = VPC-only club (on-premises not invited) | Interface Endpoint = open to on-premises with the right DNS key
Selecting a single Direct Connect connection as the answer to a 'highly available hybrid connectivity' question — a lone DX has no redundancy and will fail this requirement every time. The correct answer must include a redundant path (second DX or VPN backup).
CertAI Tutor · · 2026-02-22
Key Services
Comparisons
Guides & Patterns