AWS Direct Connect Outage in us-east-1: What Actually Broke and Why RDS Felt It

Date: February 21, 2026 | Duration: ~95 minutes | Region: us-east-1 (N. Virginia)

Photo by Kevin Ku on Unsplash

01 — The Short Version

On February 21, 2026, AWS Direct Connect experienced a connectivity loss in the N. Virginia region. The incident started at 00:38 UTC and was resolved roughly 95 minutes later.

For teams running database workloads entirely inside AWS, nothing was noticeably wrong. For teams with on-premises application servers connecting to Amazon RDS over a Direct Connect private virtual interface, it was a different story, their path to the database went dark even though RDS itself never had a problem.

That distinction between a transport failure and a database failure is the most important thing to understand about this incident. RDS was not degraded. Direct Connect was. But for architectures where on-prem traffic flows through DX to reach VPC-hosted databases, the practical effect was the same: the app couldn’t reach the DB.

Note: As of February 22, 2026, AWS has not published a post-incident review. The root cause of the Direct Connect failure is still officially unconfirmed. This analysis is built on publicly observable incident data and known DX architecture behavior; not on internal AWS diagnostics.

02 — Incident Timeline

Here’s what the incident looked like from the outside, pieced together from the AWS Health Dashboard, StatusGator, and IsDown tracking data.

03 — The Architecture: How DX Connects to RDS

To understand why a Direct Connect failure affects RDS, it helps to be clear about where each piece sits. Direct Connect is not a service that lives inside a VPC ; it’s the physical and logical path between the outside world and a VPC. RDS lives inside the VPC.

A private virtual interface (private VIF) is the logical construct that terminates the DX connection at the AWS side and routes traffic into a specific VPC via a Virtual Private Gateway or Direct Connect Gateway. When that BGP session drops for any reason, the route advertisements are withdrawn and the path between on-prem and the VPC is severed.

Inside the VPC, everything keeps running. RDS processes no errors. CloudWatch metrics show nothing unusual. The database is healthy. But from the on-premises side, every connection attempt to that RDS endpoint times out or hangs.

If the application was already inside AWS — EC2, ECS, Lambda in the same VPC; it never touched Direct Connect at all and would have seen zero impact during this incident. This is not a subtle distinction; it’s the entire reason this incident was selectively damaging rather than universal.

04 — What Happens to In-Flight Connections

This is where the incident gets technically interesting. When a DX circuit loses BGP connectivity, existing TCP connections between on-prem application servers and RDS do not receive an immediate RST packet. They just stop receiving acknowledgements. The application has no way to know the connection is broken until a socket timeout fires, or a keepalive probe goes unanswered enough times to declare the connection dead.

The four phases above illustrate what the connection pool looks like across the lifecycle of the failure:

• Phase 1 — Normal Operation: All connections are healthy and responsive through the DX path.
• Phase 2 — DX Circuit Drops: BGP fails. Some connections start hanging open at the TCP level but pointed at a path that no longer responds. No RST is received, so the pool doesn’t know yet.
• Phase 3 — Pool Exhausted: As more connections hang and new requests come in, the pool fills entirely with zombie connections. New requests either queue waiting for a slot to free up, or fail immediately if the pool is at capacity. Application error rates spike hard here.
• Phase 4 — Recovery: Once DX restores, dead connections are gradually cycled out and replaced with fresh ones. Recovery is not instantaneous; the pool needs time to flush and replenish, which means effective downtime can extend a few minutes beyond when AWS marks the incident resolved.

DB connections can drop when they reach the client or server-side timeout. How quickly the pool flushes dead connections depends entirely on how connectTimeout, socketTimeout, and TCP keepalive settings are configured at the driver level. Without explicit configuration, the OS-level TCP defaults can leave connections hanging for several minutes.

05 — February 2026 in us-east-1: A Pattern Worth Noting

This incident didn’t happen in isolation. Looking at AWS status data across late January and February 2026, there’s been a noticeable cluster of network-layer events in us-east-1.

It’s genuinely unclear what’s driving this pattern. It could reflect infrastructure remediation work that’s temporarily introducing instability as a side effect. It could be coincidental. Without an official explanation from AWS, drawing a firm conclusion isn’t warranted. But four distinct network-layer events in us-east-1 within three and a half weeks is a pattern worth acknowledging especially for teams with availability-critical workloads in that region.

Source: StatusGator, IsDown, AWS Health Dashboard. Duration values are approximate based on status page data.

06 — Why Diagnosing This Was Hard

Incidents like this tend to generate a frustrating early investigation loop. The symptoms database errors, timeouts, connection failures point straight at the database. The natural first steps are checking the RDS console, looking at CloudWatch metrics, scanning RDS error logs. All of those show green. Nothing looks wrong at the database layer because nothing is wrong at the database layer.

The failure lives in a part of the stack that most database-focused runbooks don’t cover: the network path from on-premises into the VPC. The fastest way to isolate it is a connectivity check from inside the VPC something as simple as nc -zv [rds-endpoint] 5432 from an EC2 instance in the same VPC. If that works while the on-prem application is failing, the database is fine and the investigation shifts to the network path. This two-sided check is a small addition to any RDS incident runbook that pays off disproportionately in cases like this one.

07 — What the Incident Surfaces

A few architectural realities become more visible after an incident like this; not as criticisms of any specific setup, but as things worth examining.

The backup network path. The standard resilience model for Direct Connect is a primary DX connection with an IPSec VPN over the public internet as a fallback, both running BGP with route preferences favoring DX. When the DX circuit fails, traffic reroutes over VPN automatically. Many customers deploy two or more DX connections to achieve redundancy and higher capacity, using combinations of private VIFs, transit VIFs, and Direct Connect Gateways across multiple DX locations. Teams without any fallback path experienced a full connectivity loss during this event rather than a degraded path.

BFD and BGP failover timing. BFD (Bidirectional Forwarding Detection) is automatically enabled for each Direct Connect virtual interface on the AWS side, but does not take effect until it’s configured on the customer’s router. With default BGP hold timers (~90 seconds), there’s a meaningful gap between when a circuit fails and when routes are withdrawn and traffic knows to reroute. BFD can compress that detection window to sub-second but only when configured end-to-end on both sides.

Multi-AZ scope. Multi-AZ for RDS handles instance-level failures and AZ-level failures. It doesn’t factor into a transport failure upstream of the VPC. The two mitigations address completely different failure domains, and it’s easy to assume Multi-AZ provides broader coverage than it actually does. No Multi-AZ failover was triggered during this incident because, from RDS’s perspective, nothing failed.

RDS Proxy and this failure mode. RDS Proxy helps with connection management and failover at the RDS layer, and it maintains idle client connections during failover events. But the Proxy endpoint lives inside the VPC. If the on-prem path to the VPC is severed, the Proxy is equally unreachable. RDS Proxy does not help with transport-layer failures outside the VPC boundary; it only helps once traffic can actually reach the VPC.

08 — Waiting on the PIR

A proper post-mortem isn’t possible without the AWS post-incident review. The root cause of the Direct Connect failure whether it was a physical layer issue, a routing problem, a software rollout, or something else in the DX infrastructure at the Ashburn colocation facilities isn’t publicly confirmed. AWS will presumably publish something in the coming weeks.

What this incident does make concrete, regardless of root cause, is that the network path between on-premises infrastructure and VPC-hosted databases is its own failure domain. It fails independently of the database, it fails in a way that looks like a database failure from the application layer, and the mitigations for it are different from the mitigations for database-layer failures.

TL;DR — AWS Direct Connect Outage (Feb 21, 2026, us-east-1)

• A ~95-minute Direct Connect network failure broke connectivity between on-prem systems and AWS VPCs.
• RDS itself never failed; databases were healthy inside AWS.
• Apps running inside AWS saw no impact.
• Apps running on-prem over DX couldn’t reach their databases → timeouts, hanging connections, pool exhaustion.
• The real failure domain was the network path, not compute or database infrastructure.
• Teams without DX failover (VPN backup + BGP/BFD tuning) experienced full outages.
• Diagnosis was tricky because DB metrics looked normal: the issue was outside the VPC.

Core lesson:

Multi-AZ protects against infrastructure failure. It does not protect against network path failure.

Sources: AWS Health Dashboard, IsDown, StatusGator, AWS Direct Connect documentation, AWS RDS Proxy documentation. AWS PIR not yet published as of February 22, 2026. This post will be updated when official root cause details are available.