DynamoDB SLA: Uptime Commitments, Service Credits and Claims

The Amazon DynamoDB SLA commits to a Monthly Uptime Percentage of at least 99.99% in each AWS Region. It rises to 99.999% when every DynamoDB table you have in that Region is part of a global table for the whole month and you make reasonable attempts to fail over during a regional problem. If AWS misses the commitment, you can claim a service credit of 10%, 25% or 100% of that Region's DynamoDB charges for the month. Credits are not applied automatically: you request them through AWS Support by the end of the second billing cycle after the incident.

The current version of the DynamoDB SLA was last updated on May 14, 2025, and applies separately to each AWS account.

DynamoDB SLA at a glance

The outage figures are equivalents, not allowances. DynamoDB measures availability as the share of requests that fail in each 5-minute interval, so a partial error rate spread over a longer period uses up the same budget.

Service credits

Credits are a percentage of the month's credit base (above) for the Region that missed its commitment.

The conditions that come with them:

• Credits apply only against future DynamoDB payments. AWS may instead credit the card that paid for the affected billing cycle, but a credit is never a refund.
• A credit is issued only if it is worth more than $1 for the month.
• Credits can't be transferred or applied to another account.
• Unless your agreement with AWS says otherwise, service credits are your only remedy for DynamoDB being unavailable.

How DynamoDB measures availability

• Per 5-minute interval. Availability is the percentage of your requests in each 5-minute interval that don't fail with an Error. An interval in which you made no requests counts as 100% available.
• Errors are HTTP 500 and 503 only. Throttling (ProvisionedThroughputExceededException, ThrottlingException, RequestLimitExceeded), validation errors and missing tables return HTTP 400, so they don't count against the SLA.
• Averaged over the month. The Monthly Uptime Percentage is the average availability of all 5-minute intervals in the billing cycle.
• Every table in the Region. The Standard SLA counts requests to all of your tables in the Region. The Global Tables SLA also counts the corresponding replica tables in other Regions.
• DynamoDB API requests only. DynamoDB Accelerator (DAX) requests are excluded. DAX has its own DAX SLA: 99.99% for Multi-AZ clusters and 99.5% for Single-AZ clusters.

When the 99.999% Global Tables SLA applies

Both conditions have to hold for the whole billing cycle:

1. Every DynamoDB table you have in that Region is part of a global table. One single-Region table in the same account and Region, such as a scratch or test table, puts the whole Region on the 99.99% Standard SLA for that month. Keeping single-Region tables in a separate account avoids this, because the SLA is evaluated per account.
2. You make reasonable attempts to fail over when a single Region has an availability problem. If you don't, the Standard SLA applies.

Failing over means your application can send its traffic to a replica in another Region. With the default multi-Region eventual consistency (MREC) mode, writes that had not replicated when the Region failed may be missing from the other replicas: the recovery point equals the replication delay, which AWS says is usually a few seconds. Multi-Region strong consistency (MRSC), generally available since June 30, 2025, replicates each write to at least one other Region before acknowledging it, so the recovery point is zero, at the cost of higher latency for writes and strongly consistent reads. The global tables guide covers both modes.

What the SLA does not cover

The service commitment does not apply to unavailability or performance problems that:

1. are caused by factors outside AWS's reasonable control, including force majeure events and Internet problems beyond DynamoDB's demarcation point;
2. result from your voluntary actions or inactions;
3. result from not following the best practices in the DynamoDB Developer Guide;
4. add recovery time because your table didn't have enough read or write throughput for the workload;
5. are caused by your own equipment, software or other technology;
6. arise from AWS suspending or terminating your right to use DynamoDB under your agreement.

The SLA also makes no promise about several things people assume it covers:

• Latency. There is no latency commitment. What to expect and how to measure it is in DynamoDB performance and latency.
• Global table replication lag. AWS says MREC changes typically replicate "within a second or less" and states that "there is no SLA on this latency."
• Throttling. Throttled requests are HTTP 400 responses and not SLA errors. Avoiding them is a capacity question, covered in DynamoDB throttling.
• Your own mistakes. DynamoDB automatically replicates every table across three Availability Zones in its Region, but nothing in the SLA protects you from an accidental delete or a bad deploy. Point-in-time recovery restores a table to any second in the last 1 to 35 days, and deletion protection blocks DeleteTable. See DynamoDB backup and restore.

How to claim a DynamoDB SLA credit

1. Collect the evidence. AWS asks for the billing cycle, the Region, your Monthly Uptime Percentage for that Region, and the dates, times and availability of every 5-minute interval below 100%. Your request logs are the proof. The CloudWatch metric SystemErrors (published per table and operation) counts HTTP 500 responses and helps you find the affected intervals. AWS SDKs retry 500 errors automatically, so log at the SDK level, with request IDs, to capture failures your application code never saw. The DynamoDB error 500 page explains what those responses look like.
2. Open a case in the AWS Support Center with the words "SLA Credit Request" in the subject line.
3. Include the billing cycle and Regions, the Monthly Uptime Percentage, the details of each affected 5-minute interval, and the request logs that document the errors. Remove or mask confidential data in the logs.
4. Submit it in time. The request must reach AWS by the end of the second billing cycle after the incident. A request without the required information is disqualified.
5. Wait for the credit. If AWS confirms that your Monthly Uptime Percentage was below the commitment, it issues the credit within one billing cycle following the month in which you made the request.