AWS Route 53 SLA Credits & Refunds

When Route 53 misses its uptime target, your team rarely gets a credit automatically — AWS waits for a billing case before issuing anything. This guide walks through the specific Route 53 SLA tiers, what AWS considers a qualifying event for a networking service, and the evidence you need to assemble before you open a case.

What this guide covers

• The official AWS Route 53 uptime commitment and credit tiers
• Which incidents qualify (and which exclusions silently disqualify claims)
• How to file a Route 53 credit request inside the AWS claim window
• Why manual claim recovery typically leaves money on the table

Frequently asked questions about AWS Route 53 SLAs

What is the typical SLA uptime guarantee for AWS Route 53?

Route 53's authoritative DNS service is one of the most aggressive SLAs on AWS: the no-credit threshold is 99.99% Monthly Uptime Percentage for each Hosted Zone in standard regions, with a 25% service credit triggered between 99.95% and 99.99% and a 100% credit below 99.95%. Route 53 was historically marketed as a "100% uptime" service, but the published SLA defines credit tiers below 99.99%.

How do I claim AWS Route 53 SLA credits after an outage?

Open a billing case in the AWS Support Center within 60 days of the affected billing period (the exact window is in the Route 53 SLA itself). The case needs: the affected resource IDs, timestamps of the disruption in UTC, your monitoring evidence (CloudWatch metrics, error logs, or third-party uptime monitoring) cross-referenced against the AWS Health Dashboard, and your calculation of the Monthly Uptime Percentage. AWS reviews the case manually and applies any granted credit to your next invoice rather than refunding cash. Teams that file these regularly automate the evidence-gathering step because it's the most error-prone — a claim missing the wrong field gets denied and has to be refiled.

What exclusions apply to the AWS Route 53 SLA?

Route 53 specifically excludes any unavailability where your domain is not configured to use all four virtual name servers AWS assigned to your Hosted Zone — if you delegated only a subset and one of those name servers had an issue, AWS will reject the claim.

Why is it difficult to get refunds for Route 53 outages manually?

Networking incidents are the easiest to misclassify. A Route 53 disruption might really be a DNS resolution issue, an upstream peering problem, or a TLS certificate failure — and the SLA only covers what the provider's own infrastructure caused. Distinguishing a true Route 53 outage from a downstream symptom requires correlated telemetry across multiple layers, which is exactly the data manual claim filers tend to miss.

Related AWS SLA guides

Other AWS services that share the same claim window and Support Center workflow:

• AWS VPC SLA credits — Networking
• AWS CloudFront SLA credits — Networking
• AWS EC2 SLA credits — Compute
• AWS S3 SLA credits — Storage

Stop leaving AWS credits unclaimed

The hardest part of recovering Route 53 credits isn't the SLA — it's the lag between an outage and the moment somebody on your team has the bandwidth to file the case. By the time the FinOps team gets around to it, the evidence has rolled out of CloudWatch and the billing window is closing.

Next Signal watches AWS Health and your own observability data, detects Route 53 SLA breaches in real time, assembles the evidence package the way AWS expects it, and files the billing case for you. See how it works or start a free trial.