Managed Database SLAs: What RDS, Aurora, Azure SQL and Cloud SQL Promise at Each Tier
September 11, 2026
Two teams run the same managed PostgreSQL in the same region on nearly identical bills. One carries a 99.99% commitment with credits reaching 100% of the monthly fee in a bad month; the other has no commitment at all. The difference is not the provider or the engine: it is the deployment option chosen at provisioning time.
All four big providers split their database SLA by deployment configuration: Multi-AZ versus single, zone redundant versus not, HA versus zonal, standby versus no standby. Buyers compare vCPU and storage prices, skip past this line item, and meet it the month an outage lands. What follows: the commitments per tier, the math they tolerate, and where the claim goes.
The commitment depends on the deployment, not the product
Read the current SLA documents back to back and one pattern stands out. The number people quote from memory ("RDS is 99.95%") is one row of a table that runs higher or lower depending on the deployment.
| Product and deployment | Monthly uptime commitment | Credit schedule |
|---|---|---|
| RDS, Multi-AZ instance or Multi-AZ cluster | 99.95% | 10% below 99.95%, 25% below 99.0%, 100% below 95.0% |
| RDS, Single-DB instance | 99.5% | 10% below 99.5%, 25% below 99.0%, 100% below 95.0% |
| Aurora, cluster across two or more AZs | 99.99% | 10% below 99.99%, 25% below 99.0%, 100% below 95.0% |
| Aurora, single-AZ cluster | 99.9% | 10% below 99.9%, 25% below 99.0%, 100% below 95.0% |
| Azure SQL Database, zone redundant (General Purpose, Business Critical, Premium, Hyperscale) | 99.995% | 10% below 99.995%, 25% below 99.0%, 100% below 95.0% |
| Azure SQL Database, not zone redundant | 99.99% | 10% below 99.99%, 25% below 99.0%, 100% below 95.0% |
| Cloud SQL Enterprise Plus with HA, or a read pool with 2+ nodes | 99.99% | 10% below 99.99%, 25% below 99.0%, 100% below 95.0% |
| Cloud SQL Enterprise with HA | 99.95% | 10% below 99.95%, 25% below 99.0%, 50% below 95.0% |
| Cloud SQL single-zone, shared-core, and single-node read pools | no commitment | none |
| DigitalOcean Managed Databases with standby nodes | 99.95% | 10% below 99.95%, 25% below 99.0%, 100% below 95.0% |
| DigitalOcean Managed Databases without standby nodes | 99.5% | 10% below 99.5%, 25% below 99.0%, 100% below 95.0% |
Azure SQL Managed Instance repeats the split: zone redundant instances carry 99.995%, non-zone-redundant instances 99.99%. Microsoft also credits recovery metrics, which no other database SLA here does: geo-replication on Business Critical promises a 5-second recovery point objective and a 30-second recovery time objective.
Every schedule applies to the affected resource's charges for the month, not your total invoice, and every provider measures per instance or per cluster, so one bad database does not erase a clean month for the rest. Sources: the RDS SLA (January 2024), the Aurora SLA (March 2025), Microsoft's September 2026 consolidated SLA, Google's Cloud SQL SLA, and DigitalOcean's Managed Databases SLA (June 2025).
The deployment option is the SLA. Cloud SQL single-zone instances are excluded from Google's covered service entirely, and single-AZ RDS and standby-less DigitalOcean clusters sit at a 99.5% bar. That gap decides whether a bad night produces a claim or a shrug.
What each commitment tolerates
Percentages hide the stakes. In a 30-day month (43,200 minutes), here is the failure each promise allows before a breach:
| Commitment | Downtime allowed in a 30-day month |
|---|---|
| 99.995% | 2 minutes 10 seconds |
| 99.99% | 4 minutes 19 seconds |
| 99.95% | 21 minutes 36 seconds |
| 99.9% | 43 minutes 12 seconds |
| 99.5% | 3 hours 36 minutes |
A 90-minute incident is the most instructive test case here: it pierces every commitment from 99.9% up, and stays comfortably inside the 99.5% allowance. Run it against a fleet where every database bills $6,000 a month:
| Deployment, all on a $6,000 monthly bill | Result of a 90-minute outage |
|---|---|
| RDS Multi-AZ instance or cluster | 10% credit, $600 |
| RDS Single-DB instance | no breach (allowance is 3 h 36 min), $0 |
| Aurora, multi-AZ or single-AZ cluster | 10% credit, $600 |
| Azure SQL Database, zone redundant or not | 10% credit, $600 |
| Cloud SQL Enterprise or Enterprise Plus with HA | 10% credit, $600 |
| Cloud SQL single-zone | not covered, $0 |
| DigitalOcean with standby nodes | 10% credit, $600 |
| DigitalOcean without standby nodes | no breach (allowance is 3 h 36 min), $0 |
Same outage, same bill, and the spread between the rows is the full $600. The zero rows are the cheapest configurations in the fleet. RDS Single-DB and standby-less DigitalOcean do pay once downtime passes 3 hours 36 minutes, but Cloud SQL single-zone never pays, because it is not in the contract. Reaching the 25% tier takes a month below 99.0%; the 100% tiers need a month below 95%.
The definitions decide which minutes count
Every schedule above only matters after the definitions are applied, and all four providers define unavailability the same strict way: a minute counts only when all connection attempts to the resource fail for the entire minute. DigitalOcean adds a floor on top: connectivity must be gone for more than five minutes.
The consequence: a database returning errors to half its queries, doubling latency, or dropping connections under load is not "down" in SLA terms. Slow is not down. Only total, sustained connection failure moves the number, which is why incidents that ruin a week settle at zero credit.
The exclusions trim further: AWS excludes the Micro instance class, Google keeps scheduled maintenance out of Enterprise edition downtime math, and Microsoft bars previews and free tiers outright. Sort borderline incidents against the exclusions before counting them.
Where the claim goes
All four providers put the filing on you, and the clocks differ: every window below starts at the incident, not at your next finance review.
| Provider | Route | Window |
|---|---|---|
| AWS, RDS and Aurora | Support case in the AWS Support Center | By the end of the second billing cycle after the incident |
| Azure SQL | Portal support request, Billing then Refund Request | Within 60 days of the incident |
| Google Cloud SQL | Notify Google technical support through the SLA contact form | Within 30 days of becoming eligible |
| DigitalOcean | Support contact from the account | By the end of the second billing cycle |
AWS wants "Amazon RDS SLA Credit Request" plus the claim type ("Multi-AZ Claim" or "Single-DB Claim") in the subject line, with instance or cluster IDs, regions, dates and times, and request logs. Claims do not stack, so one database gets one claim type, for RDS and Aurora alike. Credits under $1 are not paid.
Azure requires a description of the incident, its time and duration, affected resource names, user counts and locations, and the errors observed, and typically processes claims within 45 days of receipt. File it as a portal support request; our Azure refund guide walks through the steps.
Google runs the shortest fuse: 30 days from the moment you become eligible, after which the right is forfeited. Credits land within 60 days of the request, capped per billing month at 50% for Enterprise edition and 100% for Enterprise Plus.
Keep the incident window's request logs somewhere retrievable: every provider demands them, and memory will not survive three weeks. Our evidence checklist covers what each provider accepts.
Spend an hour on the database inventory this week. Record each production instance's deployment option next to the commitment from the first table, then flag anything in a no-commitment or 99.5% row. Each flag is one decision: pay for HA, or accept the exposure with open eyes. Discovering the gap mid-incident is not an option.