High vs Maximum Resilience on Direct Connect: picking the right SLA

A bank I worked with had spent close to a year building what its architects proudly called "redundant Direct Connect." Two AWS Direct Connect (DX) dedicated connections, both terminated in the same colocation campus, both in the same metro, both running through the same building riser to the same partner cage. The diagrams were tidy. The Border Gateway Protocol (BGP) sessions were stable. The peering with AWS was active-active and the team had documented failover playbooks. Then a contractor working on the building's electrical risers cut a fiber bundle that, against everyone's mental model, both DX paths shared. Within seconds the bank lost every private virtual interface it had into AWS, and the only thing that saved a regulated batch window was a Site-to-Site VPN tunnel that nobody had treated as anything more than an afterthought.

That afternoon is the kind of incident that makes the difference between High Resilience and Maximum Resilience on DX feel less like a marketing label and more like a real engineering decision. Both postures sit inside the AWS Direct Connect Resiliency Toolkit. Both connect on-premises infrastructure to AWS over private fiber. They differ in the fault domains they cover, the resilience outcomes they commit to, and the blast radius of an event that crosses the line each one happens to draw. Picking between them is rarely as simple as choosing the bigger number on a slide.

The Resiliency Toolkit exposes three models. Maximum Resilience is the only posture associated with a 99.99% SLA target. High Resilience is associated with a 99.9% target. The third option, called Development and Test, terminates separate connections on separate AWS devices in a single DX location and is explicitly not intended for production workloads — it covers device failure but not site failure, and it carries no Multi-Site SLA. Underneath those three labels sit very specific configuration requirements published in the AWS Direct Connect Service Level Agreement, and that document is where the resilience outcome is actually defined.

The vocabulary matters. The Toolkit talks about "Maximum Resilience" and "High Resilience"; the SLA talks about "Multi-Site Redundant Deployment" and "Multi-Site Non-Redundant Deployment." They map to each other, but the SLA is the contract. Anything you build that does not meet the SLA's minimum configuration is, in the eyes of AWS commitments, a single-connection deployment with a 95% target — which in practice is not a target at all. A team can run two beautiful DX connections that fail to qualify for either Multi-Site SLA, and never realize it until the credit request comes back denied.

The 99.99% commitment under the Multi-Site Redundant SLA requires at least four DX connections deployed across at least two DX locations, with no fewer than two connections in each location and each connection terminating on a unique AWS device. At least one of those DX locations has to be associated with the AWS Region the workload reaches. The AWS-side endpoint, when private, has to live in two or more Availability Zones (AZs). Operationally, you also need an Enterprise Support plan and a completed Well-Architected Review with an AWS Solutions Architect. None of these are formalities. The Well-Architected Review is the moment the architecture is interrogated against the Reliability Pillar, REL02-BP02 in particular, which prescribes redundant connectivity across separately deployed private networks and explicit BGP-driven failover.

The Multi-Site Redundant pattern is the only one that meaningfully covers a complete location failure. The four-connection requirement is not arbitrary: with two connections per metro, a device or fiber failure at one DX location can reduce capacity by half but the Deployment as a whole stays inside the SLA window because the surviving location still has redundant paths. Pull a metro entirely — the kind of event the bank in the opening anecdote discovered — and the second metro keeps the service online. The blast radius of a single fault domain is contained to the loss of throughput, not the loss of reachability.

The 99.9% commitment is associated with the Multi-Site Non-Redundant SLA, which the Toolkit surfaces as High Resilience. The minimum configuration is at least two connections deployed across at least two DX locations, an Enterprise Support plan, and, for private endpoints, deployment across two or more AZs. The "non-redundant" wording trips people up. The Deployment itself is redundant in the sense that two separate connections from two separate metros can keep traffic flowing. What is non-redundant is each individual path: lose one and you have no second connection in the same metro to absorb the failure. Capacity halves, the surviving path is on its own, and any second concurrent fault at the surviving site takes the Deployment down.

That trade-off is what you are buying when you choose High Resilience over Maximum Resilience. You spend less — two connections rather than four, and proportionally less in port-hour charges and partner cross-connects — and you accept a tighter coupling between any single in-metro failure and the resilience outcome of the Deployment. For many workloads that is exactly the right answer. The 99.9% target translates to roughly 43 minutes of permitted unavailability per month before service credits begin to apply, and the SLA defines unavailability as the complete inability to send or receive data through all connections in the Deployment for at least 120 consecutive seconds. For workloads whose recovery time objective (RTO) is measured in minutes rather than seconds, that arithmetic is honest.

The temptation, especially in regulated industries, is to default to Maximum Resilience because it is the highest number on the page. That instinct is not always wrong, but it is often unexamined. The right way to choose is to be specific about what each posture protects against and what it does not. Maximum Resilience covers device failure, single-link failure, and complete location failure across two metros. High Resilience covers device failure and single-link failure, with a metro outage handled by the surviving metro at half capacity. Neither posture protects against a misconfiguration that simultaneously affects both metros — for instance, a BGP policy change pushed across all on-premises edge routers that breaks every session at once. That class of failure is a control-plane risk that the data-plane diversity of DX cannot solve, and it is one of the reasons the Reliability Pillar pushes teams toward Site-to-Site VPN as a parallel path that does not share the same control-plane fate.

The other piece of the decision is what happens at the BGP layer when something does break. DX private virtual interfaces speak BGP with AWS using an AWS-side autonomous system number that defaults to 64512 on a virtual private gateway, or a custom ASN you assign to a Direct Connect gateway. AWS publishes well-defined local preference community tags — 7224:7100 for low, 7224:7200 for medium, and 7224:7300 for high — that let you steer return traffic across multiple DX paths. Active-active across two paths uses a single community across both prefixes, which lets equal-cost multi-path (ECMP) take over. Active-passive uses a higher preference on the primary and a lower one on the standby. Either way, the BGP session is the trigger that makes the resilience outcome real, which is why bidirectional forwarding detection (BFD) is asynchronously enabled on every virtual interface and waiting for the on-premises router to negotiate it. Without BFD, BGP keepalive timers do the detection, and the difference between sub-second and tens-of-seconds detection shows up directly in the impact you absorb.

There is no universal answer between High Resilience and Maximum Resilience. There is the resilience outcome the workload actually requires, the cost of the connections that achieve it, and the discipline to meet the SLA's minimum configuration in full rather than in spirit. Multi-Site Redundant earns its keep when a single-metro incident is unacceptable, when the regulator is going to ask for evidence of two-metro independence, and when the cost of four ports is small relative to the cost of an outage. Multi-Site Non-Redundant earns its keep when one in-metro incident is recoverable inside the workload's RTO, when a Site-to-Site VPN over a Transit Gateway is genuinely treated as a third leg rather than a slide, and when the team is honest about what the surviving path can carry under load.

DX gives you the physical paths. The next article is about what those paths actually do under control of BGP — AS-path, communities, multi-exit discriminator, and the edge cases that bite when Multi-Site postures are pushed into asymmetric routing or unintended ECMP. We will walk through the AWS-specific BGP behaviors that turn a redundant deployment from a diagram into something that survives the day.