Do Reserved Instances and Savings Plans Shrink Your Cloud SLA Credit?
August 18, 2026
Every cloud SLA credit is a percentage multiplied by a base. Teams watch the percentage, the 10% or 30% tier in the credit table. The base gets less attention, and that is where the money quietly disappears, because every provider defines it as what you actually paid after discounts, not list price. AWS goes further and excludes one-time Reserved Instance payments from the base entirely. Pay three years of compute upfront and you can shrink the number your credit is calculated on by two thirds before the outage even happens.
What the credit is actually calculated on
Each provider phrases it differently, and the differences change your claim size. Here is the language from the current SLA pages: Amazon Compute (May 2022), Microsoft Online Services (August 2026), Google Cloud Compute Engine (March 2025), DigitalOcean CPU Droplets (June 2025).
| Provider | What the credit is calculated on | Floor or cap |
|---|---|---|
| AWS (EC2) | Monthly bill for EC2 in the affected region, excluding one-time payments such as upfront payments made for Reserved Instances | No credit under $1 |
| Azure | Applicable Service Fees: the total fees actually paid for the service in the Applicable Period | Never more than that month's fees for the service |
| Google Cloud | Percentage of the monthly bill for the covered service in the region that missed the SLO | Never more than the amount due for that service that month |
| DigitalOcean | Charges for the specific Droplet that missed the target | Any breach of 99.99% pays 100% of that Droplet's charges |
Two patterns jump out. The base is net of discounts everywhere, so committed-use deals and reserved capacity quietly lower what a breach pays you. And the payout is always a credit against future spend, never a refund; AWS may at its discretion refund the card you paid with, but do not plan around that. The credits are not cash post covers the difference.
AWS: one-time payments do not count
The EC2 SLA is the clearest of the four. Service credits are a percentage of the monthly bill for EC2 in the affected region, with one explicit carve-out: one-time payments such as Reserved Instance upfronts are excluded. What remains is everything recurring: on-demand usage, monthly RI installments, and savings-plan charges, since those appear on the monthly bill. The exclusion is written as a category, one-time payments, with RI upfronts named as an example, so a savings plan paid as a lump sum sits in the same category.
AWS also gives you two SLA levels to claim under, and you cannot stack them. The Region-Level SLA promises 99.99% for instances running across two or more AZs, with credits of 10% below 99.99%, 30% below 99.0%, and 100% below 95.0%. The Instance-Level SLA promises 99.5% per individual instance with the same three tiers, plus a perk nobody remembers: an instance unavailable more than six minutes of a clock hour is not billed for that hour, automatically, no claim needed.
Claims go through AWS Support with Amazon Compute SLA Credit Request in the subject, plus the region, dates, times, resource IDs, and request logs, and must arrive by the end of the second billing cycle after the incident month. Approved credits land within one billing cycle of confirmation. See the AWS credits walkthrough for the full filing path.
The base is what you actually paid, not list price. AWS excludes one-time Reserved Instance payments from it, Azure credits fees actually paid, Google Cloud uses the monthly bill for the affected service in the affected region, and DigitalOcean credits only the affected Droplet's charges. Discounts shrink the base, and the payout is always a credit, never cash.
Azure: fees actually paid, with a 30 day lookback
Azure's general terms define the credit as a percentage of Applicable Service Fees: the total fees actually paid by you for the service in the Applicable Period. No carve-outs for reserved capacity or Azure Hybrid Benefit appear in the text. None are needed: the base is simply whatever you paid after discounts.
The Applicable Period holds a surprise. For metered pay-as-you-go services such as Virtual Machines, it is the 30 days prior to and including the first day of the incident, not the outage month's bill. A breach on the 25th is calculated against what you paid in the roughly four weeks before it. For flat-fee services it is the calendar month of the incident.
Microsoft processes claims in about 45 days, applies the credit to your fees, and caps any payout at the monthly fees you paid for that service. Claims need a description of the incident, the time and duration, affected resource names, and the number and location of affected users. The SLA requires Azure claims within 60 days of the incident; Microsoft's partner documentation phrases it as two months from the end of the billing month. Either reading kills a claim filed a quarter later. The portal path is in our Azure refund walkthrough.
One more Azure detail: Scheduled Downtime with at least five days notice is excluded from downtime entirely, and so is the monthly maintenance window. Read the exclusion list before you count the minutes; the SLA only measures what Microsoft decides to measure.
Google Cloud and DigitalOcean: the affected service's bill
Google Cloud's Compute Engine SLA credits a percentage of the monthly bill for the covered service in the region that missed the SLO. Committed use discounts are not carved out, which means the base is the discounted bill. Credits run 10% below the SLO, 25% below 99.0%, and 100% below 95.0% for multi-zone setups, capped at what you owed for that service that month. The credit lands on future bills within 60 days of the request, which must cite log files showing each downtime period.
DigitalOcean takes the simplest route. The CPU Droplet SLA commits to 99.99% per individual Droplet, and any month below that pays 100% of that Droplet's charges. Not a percentage tier: the whole month's fee. Requests go to success@digitalocean.com within two billing cycles of the outage month with your account email, Droplet details, and outage times; scheduled maintenance and customer-initiated downtime are excluded.
The money math
Here is what the base rules do to a $10,000 monthly EC2 bill when EC2 misses the 99.99% Region-Level SLA and the 10% tier applies.
| How you pay for EC2 | Monthly bill | One-time upfront | Credit base | 10% credit |
|---|---|---|---|---|
| All on demand | $10,000 | $0 | $10,000 | $1,000 |
| 70% on 3-year all-upfront RIs | $3,000 | $7,000 | $3,000 | $300 |
| 70% on a savings plan, no upfront | $10,000 | $0 | $10,000 | $1,000 |
| 50% all-upfront RIs, rest on demand | $5,000 | $5,000 | $5,000 | $500 |
Same outage, same tier, and the payout swings from $1,000 to $300 depending on how you prepaid. None of this means reserved capacity is a bad deal: the discounts are worth far more than the credits you give up. It means your recovery ceiling is set by your payment structure, and you should know the number before you file, not after.
What this changes about your claim
Before you open a support case, pull the affected service's charges off your last invoice and compute the base yourself. If the math sits close to a tier boundary, your own monitoring matters: one minute of observed downtime can separate the 10% from the 30% tier, and provider status pages are not always honest about recovery (see what status pages hide). We built UptimeAudit to track this: when observed downtime crosses a threshold we draft the claim pre-filled with the incident window and evidence, so the base math is done before you file.
That is the one concrete step for this month: find the service that went down, note what you actually paid for it after discounts, multiply by the credit tier, and file inside the deadline. The percentage gets all the attention. The base decides what the credit is worth.