What happened
On October 20, 2025, the single most concentrated region in cloud computing, AWS us-east-1 in Northern Virginia, had a bad morning that the rest of the internet felt for most of the day. The root cause was not a hardware fire or a fiber cut. It was DNS. An automated system that manages the DNS records for the regional DynamoDB API endpoint produced a bad record, and clients could no longer resolve where to send their DynamoDB requests.
That would have been serious on its own, because DynamoDB is a workhorse database for a huge number of applications. What made it a headline event is that AWS itself runs on DynamoDB. Internal control planes that launch EC2 instances, update IAM permissions, and route Lambda invocations keep state in DynamoDB. When DynamoDB became unreachable, those control planes stalled, and the failure fanned out across dozens of AWS services and the thousands of companies that depend on them. Sites that had no idea they were tied to us-east-1 discovered it the hard way.
Recovery was slow and deliberate. AWS restored the correct DNS record within a few hours, but bringing dependent services back without a retry storm took the rest of the day. By late evening UTC, roughly 15 hours after it began, the event was resolved.
SLA credit analysis (the tier and dollar logic)
DynamoDB has one of the strongest SLAs in the AWS catalog, which works in your favor here. Amazon commits to 99.999% monthly uptime for multi-Region global tables and 99.99% for single-Region tables, measured per Region as the share of five-minute intervals whose error rate stays under the SLA threshold.
Do the arithmetic on a 30-day month. A 99.99% target allows only about 4.3 minutes of downtime for the whole month. The October event delivered hours of elevated errors in us-east-1. Even one fully failed hour is twelve consecutive bad five-minute intervals, which by itself pushes a single-Region table below 99.99%. That clears the first credit tier immediately.
The DynamoDB credit schedule is tiered against your monthly DynamoDB charges in the affected Region:
- Below 99.99% but at or above 99.0%: a 10% service credit.
- Below 99.0% but at or above 95.0%: a 25% service credit.
- Below 95.0%: a 100% service credit.
So a team spending 20,000 dollars a month on DynamoDB in us-east-1 that landed in the 10% band is owed 2,000 dollars, and one that dipped under 99.0% is owed 5,000 dollars. The credit is scoped to DynamoDB, not your entire AWS bill, and critically, it is not paid automatically. AWS does not scan your account and mail you a check. You have to notice, measure, and ask.
How to claim
- Pin the window. The impact ran the morning of October 20, 2025, in us-east-1. Pull your own DynamoDB CloudWatch metrics (SystemErrors, ThrottledRequests, and successful-request counts) for that day to document your real error rate, not just AWS's regional summary.
- Compute your monthly uptime for the Region and identify your tier (10%, 25%, or 100%).
- Price it. Run your monthly DynamoDB spend and downtime through the free SLA credit calculator so you open the case with a number, not a guess.
- File a case in the AWS Support Center within the SLA claim window (AWS requires the request before the end of the second billing cycle after the incident), attach your metrics, and cite the DynamoDB SLA tier.
If you want the mechanics step by step, the SLA claim filing guide walks through the exact case fields, and how it works shows where this fits in the broader recovery process.
Lessons
- Single-Region on us-east-1 is a concentration risk, and the strong DynamoDB SLA is small comfort when the credit is a fraction of a DynamoDB bill that is itself a fraction of your outage cost.
- Multi-Region only protects you if the whole dependency graph is regionally independent. Several teams that had multi-Region data still stalled on shared control planes.
- Credits expire. The single most common reason SLA money goes unclaimed is that nobody measured the breach before the claim window closed. Build the habit now.
- This was not an isolated AWS event; compare the pattern to the November 2020 Kinesis outage, which also started in us-east-1 and cascaded through dependent services.
For the wider blast radius across other providers, see awsdown.com, azuredown.com, and gcpdown.com. To recover both SLA credits and silent billing overcharges automatically, our sponsor Next Signal watches your cloud accounts and drafts the claim for you, and cloud-credits.com covers the credit-recovery side in depth.