IPsec Site-to-Site VPN<\/a> article provides the VPN fundamentals.<\/p>\nThe backup path should be sized and tested for the traffic it is expected to carry. A VPN that has never handled production volume is only a theoretical fallback.<\/p>\n
Resiliency should be expressed as a failure matrix<\/h3>\n Teams should document the failures they expect the design to survive: one BGP session, one customer router, one Direct Connect device, one circuit, one provider path, one location, or the entire hybrid connection.<\/p>\n
Each row in that matrix should map to the path that remains, the expected traffic shift, the monitoring signal, and the operator action.<\/p>\n
Direct Connect resiliency becomes trustworthy when the routing and physical design have been exercised under those failures, not merely when the connection count matches a diagram template.<\/p>\n
Provider diversity should be verified rather than assumed. Two connections ordered from different carriers can still share conduit, meet-me room, or upstream infrastructure. The business should decide which physical failures matter and ask providers how independently the paths are engineered where that information is available.<\/p>\n
Customer-edge devices also need redundancy. Two AWS-side connections can terminate on one on-premises router, firewall, or power circuit and still share a single local failure domain. Maximum-resiliency design should be mirrored through the customer side until traffic reaches an infrastructure layer that is intentionally shared.<\/p>\n
BFD can reduce failure-detection time in some routing designs, but faster detection should be tested with device and provider behavior. Aggressive timers that are unstable under normal packet loss can create route flaps worse than the failure they are meant to detect. Routing convergence should be measured end to end rather than inferred from one protocol timer.<\/p>\n
Bandwidth asymmetry can create a hidden failover problem. The primary path may carry several gigabits while the surviving path has less capacity. During a test, basic connectivity remains healthy but queues and application latency rise sharply. Resiliency planning should size the secondary path for the traffic the business expects to preserve during failure.<\/p>\n
Route advertisement policy should be documented before the test. If both links advertise the same prefixes, local preference and AS-path behavior determine which path carries traffic normally and which becomes backup. For transit virtual interfaces, Transit Gateway route propagation and segmentation add another layer that can alter the expected path.<\/p>\n
Regular tests should vary which peering is brought down. Testing only one link proves only one direction of failover. A complete exercise rotates through the connections and validates that each surviving topology meets the requirement, including return traffic and stateful firewall behavior.<\/p>\n
Direct Connect Gateway and Transit Gateway designs should be included in failover tests. A circuit can recover at BGP while route propagation, association, or segmentation prevents a destination VPC from receiving the expected path. Hybrid tests should therefore include representative VPC routes, not only one reachability target.<\/p>\n
Monitoring should track BGP session state, connection state, bandwidth utilization, packet loss where observable, and application latency. A link can remain \u201cup\u201d while becoming too degraded to meet the workload SLO. Operational policy should define when to prefer the alternate connection before complete failure.<\/p>\n
Maintenance events are another reason to rehearse. AWS or a provider can schedule work that affects one connection or device. If the redundant path has been tested recently, maintenance becomes a controlled capacity event rather than an unplanned experiment with production traffic.<\/p>\n
The connection inventory should also record LOA\/CFA information, provider, location, device, VLAN, virtual-interface ownership, and the business services that depend on each path. Hybrid connectivity is difficult to restore quickly when technical and contractual details live only in one engineer\u2019s notes.<\/p>\n
Route convergence time should be measured during every failover exercise. The business cares about the period during which application traffic is interrupted or degraded, not merely the moment the BGP session changes state. Timers, provider behavior, firewall session handling, DNS dependencies, and application retry logic all influence the observed recovery time.<\/p>\n
Asymmetric routing should be checked explicitly, especially when multiple connections, firewalls, and Transit Gateway paths are involved. One direction can move to the backup circuit while return traffic still prefers the primary path, creating stateful-firewall or troubleshooting problems even though both routes look individually valid.<\/p>\n
Direct Connect encryption requirements should also be addressed where relevant. MACsec is available on supported dedicated connections and can protect traffic over the physical Direct Connect link, while application- or VPN-layer encryption may still be used depending on the security model. Resilience and confidentiality should be designed together rather than assuming a private circuit automatically satisfies every data-protection requirement.<\/p>\n
Finally, ownership should span both AWS and the carrier side. Incident runbooks should include provider escalation contacts, circuit IDs, demarcation details, and the AWS resources associated with each connection. A technically redundant design can still have a long outage if nobody can identify or escalate the failed circuit quickly.<\/p>\n","protected":false},"excerpt":{"rendered":"
AWS Direct Connect resiliency depends on more than having two circuits. The location, device, provider path, BGP design, virtual-interface configuration, and failover testing all determine whether a second connection is actually independent enough to carry traffic when the first path fails. Inside AWS Architecture and Operations, Direct Connect is the hybrid-network path that connects on-premises […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19779","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t