Direct Connect, VPN, and Hybrid Redundancy
Key Takeaways
- Dedicated Direct Connect connections land at a Direct Connect location you control; hosted connections are delivered by an AWS Direct Connect Partner at partner port speeds
- Private virtual interfaces reach VPCs through a virtual private gateway or Direct Connect gateway; transit virtual interfaces reach Transit Gateways through a Direct Connect gateway; public virtual interfaces reach AWS public endpoints
- A Direct Connect gateway lets one hybrid path serve virtual private gateways or Transit Gateways across accounts and Regions (except AWS China Regions)
- The Direct Connect Resiliency Toolkit maximum model uses diverse locations and devices for a 99.99 percent SLA objective; high resiliency targets 99.9 percent; Site-to-Site VPN is the usual backup overlay
- Transit Gateway prefers Direct Connect gateway-propagated prefixes over Site-to-Site VPN for the same CIDR, so identical advertisements yield active Direct Connect and standby VPN
Hybrid paths are SLA and prefix-policy problems
On SAP-C02, hybrid connectivity is rarely “order a circuit.” You are scored on failure domains, which virtual interface type actually reaches the construct in the stem (VPC, Transit Gateway, or public AWS API), and how BGP chooses Direct Connect versus VPN when both advertise the same on-premises prefixes. AWS Direct Connect places a private Ethernet path from your router to an AWS router at a Direct Connect location, bypassing the public internet for that path. A location is associated with a Region, but a Direct Connect gateway extends private and transit virtual interfaces to other public Regions. Confirm current location-to-Region mapping in AWS documentation when a scenario names a metro; do not invent a location list from memory.
Dedicated connections, hosted connections, and LAG
A dedicated connection is a physical port you (or your colo provider) cross-connect to AWS at a Direct Connect location. Current AWS documentation describes dedicated Ethernet using single-mode fiber at 1 Gbps, 10 Gbps, 100 Gbps, and 400 Gbps with the corresponding LR optics, 802.1Q VLAN tagging, and BGP with MD5. Bidirectional Forwarding Detection (BFD) is available on virtual interfaces; AWS enables asynchronous BFD on the Direct Connect side, and it becomes effective when you configure it on your router.
A hosted connection is provisioned by an AWS Direct Connect Partner. You work with the partner for both the AWS port and the access circuit back to your data center. Hosted speeds include sub-1 Gbps options that dedicated ports do not sell as native port speeds. Hosted is often faster to consume when you do not already sit in a Direct Connect-enabled colo; it is not automatically “less resilient.” Resiliency still comes from two locations, two devices, two last miles—whether each port is dedicated or hosted.
A link aggregation group (LAG) bundles multiple dedicated connections of the same speed that terminate on the same AWS Direct Connect endpoint so you manage them as one connection. AWS connectivity guidance describes aggregating up to four 1 Gbps or 10 Gbps connections, and up to two 100 Gbps connections, at one endpoint. LAG increases capacity and provides link-level redundancy inside one AWS endpoint. It does not replace a second Direct Connect location. A one-location LAG still fails together in a building or metro event. Exam stems that want maximum resiliency are asking for location diversity, not a wider LAG.
Virtual interface types
You do not “attach Direct Connect to a VPC” as a single object. You create a virtual interface (VIF) on the connection:
| VIF type | What it reaches | Typical professional pairing |
|---|---|---|
| Private | VPC resources on private IPs | Virtual private gateway on one VPC, or Direct Connect gateway to many virtual private gateways |
| Public | AWS public IP space (for example Amazon S3 public endpoints, public API endpoints) | Global public services; also the underlay for IPsec to AWS-managed VPN endpoints |
| Transit | Transit Gateways | Direct Connect gateway associated with one or more Transit Gateways |
A private VIF does not attach to a Transit Gateway. If the hub is a Transit Gateway, the exam answer is a transit VIF into a Direct Connect gateway, then an association from that gateway to the Transit Gateway. A private VIF to a virtual private gateway is the older per-VPC model; it still appears when a single VPC has not moved to a hub. You generally do not run both a virtual private gateway hybrid path and a Transit Gateway attachment as two competing defaults in the same VPC without a deliberate migration design.
A public VIF is how you reach AWS public services without traversing the internet from your campus, and how you build Direct Connect plus VPN: the public VIF provides a predictable path to the AWS Site-to-Site VPN public endpoints, then IPsec provides encryption. That pattern is about confidentiality on a private circuit, not about failover. Failover is a second path with its own prefixes.
AWS publishes association limits between Direct Connect gateways, virtual interfaces, and gateways. Use the current Direct Connect quotas page rather than memorizing a number that may have changed; the exam cares that you know limits exist and that you pick the VIF type that matches the attachment type.
Direct Connect gateway
A Direct Connect gateway is a globally available resource (outside AWS China Regions) that decouples the circuit from a single VPC in a single Region. Associate it with virtual private gateways (private VIF model) or with Transit Gateways (transit VIF model). That is how one New York circuit serves us-east-1 and eu-west-1 Transit Gateways, and how several member-account gateways share one hybrid path. There is no extra Direct Connect gateway surcharge in AWS pricing descriptions for multi-account use; you still pay port hours and data transfer as documented. Allowed prefixes on the Direct Connect gateway control which AWS-side CIDRs are advertised to on-premises. If a spoke VPC never appears on-premises, check allowed prefixes and transit gateway route-table propagation before you blame BGP on the customer gateway.
Direct Connect gateway attachments on a Transit Gateway support ECMP across multiple transit virtual interfaces when prefix, prefix length, and AS_PATH match. AWS recommends a single Direct Connect gateway when you want that ECMP behavior rather than inventing multiple gateways that split the path.
Site-to-Site VPN as overlay and as backup
AWS Site-to-Site VPN builds two IPsec tunnels per VPN connection toward a virtual private gateway or a Transit Gateway. AWS Well-Architected networking guidance treats each tunnel as capped at 1.25 Gbps and notes that Transit Gateway VPN with ECMP across multiple tunnels can aggregate throughput (AWS describes designs approaching much higher aggregate throughput when you add tunnels). VPN remains sensitive to internet jitter; Direct Connect remains the stable primary for latency-critical east-west and replication traffic.
Two professional compositions appear constantly:
- VPN as backup to Direct Connect. Advertise the same on-premises prefixes over the Direct Connect (transit or private) path and over a Transit Gateway VPN. Transit Gateway route evaluation prefers Direct Connect gateway-propagated routes over VPN-propagated routes for the same CIDR. The VPN prefix is hidden until Direct Connect stops advertising. Do not install a more-specific static VPN route unless you want VPN to win.
- VPN over Direct Connect (public VIF). IPsec rides the public VIF to AWS VPN endpoints so traffic is encrypted on the circuit. This does not by itself survive a location failure.
Enable BGP on the VPN if the customer gateway supports it, and enable ECMP on the Transit Gateway VPN when you need aggregate bandwidth. Static VPNs without BGP make failover slower and harder to reason about.
Resiliency models and SLA language
The AWS Direct Connect Resiliency Toolkit walks you through ordering dedicated connections for a stated objective:
- Maximum resiliency: separate connections that terminate on separate devices in more than one location, with matching diversity on-premises. AWS documents this model as the way to pursue a 99.99 percent SLA, subject to the Direct Connect Service Level Agreement’s actual requirements.
- High resiliency: two connections to multiple locations (commonly described as each on-premises site connecting to a Direct Connect location). AWS documents a 99.9 percent SLA objective for this class of design.
- Development and test: separate devices in one location. Survives a device failure, not a location failure.
SLA percentages are contractual and require you to meet the documented topology—not merely to tick a console wizard. A single 100 Gbps port in one building can be “fast” and still be a non-resilient design. For critical market-data or payments paths, maximum resiliency plus a VPN backup for control-plane and reduced-capacity failover is the conservative professional story.
Region and Availability Zone selection for latency
Pick the AWS Region closest to the users, systems of record, and Direct Connect metro that you can actually fiber to. A Direct Connect location associated with us-east-1 plus a Direct Connect gateway can reach us-west-2, but you still pay the wide-area latency of that hairpin. If the application is active in two Regions, place Regional Transit Gateways (or Cloud WAN edges) in both and extend the Direct Connect gateway to both, rather than forcing all packets through one Region’s hub.
Inside a Region, enable Transit Gateway attachments in every AZ that hosts workloads. Missing an AZ forces internal shift of traffic and adds jitter. Place customer gateways and Direct Connect routers so that failure of one AZ, one AWS Direct Connect device, or one on-premises edge does not blackhole the only BGP speaker. For latency-sensitive hybrid databases, measure the metro fiber, not only the Region name: a “closer” Region with a long last-mile to the Direct Connect location can lose to a slightly farther Region with a short cross-connect.
Scenario: global bank with DX plus VPN backup
A bank runs latency-sensitive trading in us-east-1 and a regulatory copy in eu-west-1. Order diverse dedicated connections in two U.S. Direct Connect locations and two European locations (maximum resiliency per geography). Create transit VIFs to one Direct Connect gateway per geography or a carefully controlled global gateway, associate each Regional Transit Gateway, and advertise on-premises prefixes with BGP. Add Transit Gateway VPNs in each Region advertising the same prefixes so failover is automatic when a metro fails. Do not use a single LAG in New Jersey as the only U.S. path. Encrypt replication that must not traverse the circuit in cleartext by running IPsec over a public VIF or by encrypting at the application or storage layer—Direct Connect is private from the internet, not a substitute for encryption policy.
A market-data platform must keep hybrid connectivity up through the failure of an entire Direct Connect location and through the failure of a single AWS Direct Connect device. Which topology matches the Direct Connect Resiliency Toolkit maximum-resiliency model?
An organization has Transit Gateways in us-east-1 and eu-west-1. It wants one Direct Connect presence in New York to reach VPCs attached to both Regional hubs using private IP routing. Which virtual interface and gateway combination is correct?
You must keep a lower-bandwidth hybrid path alive if Direct Connect BGP sessions go down. On-premises prefixes are the same on both paths. How should you attach AWS Site-to-Site VPN so it remains standby until Direct Connect fails?