AWS DynamoDB SLA Credits & Refunds

When DynamoDB 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 DynamoDB SLA tiers, what AWS considers a qualifying event for a database service, and the evidence you need to assemble before you open a case.

What this guide covers

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

Frequently asked questions about AWS DynamoDB SLAs

What is the typical SLA uptime guarantee for AWS DynamoDB?

AWS commits to a 99.99% Monthly Uptime Percentage for standard DynamoDB tables, and a higher 99.999% target for Global Tables that span multiple regions (provided you have at least three replicas and attempt regional failover during an incident). Performance below those thresholds triggers tiered credits of 10%, 25%, or 100% of the in-region DynamoDB charges.

How do I claim AWS DynamoDB 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 DynamoDB 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 DynamoDB SLA?

DynamoDB specifically excludes ProvisionedThroughputExceeded errors and throttling caused by hot partitions or undersized capacity — those are customer capacity-planning issues, not service unavailability.

Why is it difficult to get refunds for DynamoDB outages manually?

Database SLAs get complicated because read availability, write availability, and replication health are often measured separately. A DynamoDB outage that prevents writes but allows reads may qualify for a partial credit, or none at all, depending on the precise wording. The evidence required (query error rates, connection failures, replication lag from your monitoring) has to match the SLA's definition of unavailability exactly.

Related AWS SLA guides

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

• AWS RDS SLA credits — Database
• AWS Aurora SLA credits — Database
• AWS Redshift SLA credits — Database
• AWS EC2 SLA credits — Compute

Stop leaving AWS credits unclaimed

The hardest part of recovering DynamoDB 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 DynamoDB 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.