Cloud SLA Renewal Checklist: Review the Version You Are Actually Under Before You Re-Sign
August 26, 2026
The SLA that decides your next credit claim is not the document you signed at the last renewal. AWS keeps its older Compute SLA under a page titled "Prior Version(s) Not Currently In Effect". Google publishes ten previous versions of its Compute Engine SLA, the oldest dated October 2015. Microsoft reissues the consolidated Azure SLA about monthly; the edition in force now is dated August 10, 2026. DigitalOcean replaced its single SLA page with per-product pages, each stamped with a last-updated date.
If you are on auto-renew, you are claiming under rules you never read.
Where the four SLAs actually live
All four treat the SLA as a living page, not a frozen contract, differing only in how they version it.
| Provider | Current document | Version history | The change that matters |
|---|---|---|---|
| AWS | Per-service SLA pages; compute terms sit in the Amazon Compute SLA | Current page says "Last Updated: May 25, 2022"; a separate "Prior Version(s)" page logs older editions | The May 2022 rewrite raised the multi-AZ EC2 commitment from 99.95% to 99.99%, added an Instance Level SLA at 99.5%, and split EBS, ECS and Fargate into their own SLAs |
| Microsoft Azure | One consolidated SLA for Microsoft Online Services, downloadable as a docx | Reissued roughly monthly; the licensing site holds an archive back to 2011 | The edition dated August 10, 2026 is in force now, and the terms can shift from month to month |
| Google Cloud | Per-service pages such as the Compute Engine SLA | Each page links a "Previous versions" section with dated archives | Compute Engine was last modified March 4, 2025; single instances now have SLOs, and Mexico and Stockholm carry lower multi-zone commitments than other regions |
| DigitalOcean | Per-product pages under digitalocean.com/sla | The old single SLA URL now returns 404; each product page shows a "Last Updated" date | The Regional Load Balancer SLA, updated December 3, 2025, depends on a 24 hour notice window and a 10/25/100% credit schedule |
No provider emails you when a version changes.
The renewal trap, in dollars
Claiming against the wrong version costs real money. Take a $50,000 compute bill in a breached month on the standard multi-zone schedule:
| Breach tier | AWS EC2 multi-AZ | Azure VM with Availability Zones | GCP Compute Engine multi-zone Premium | DigitalOcean Regional Load Balancer |
|---|---|---|---|---|
| Below commitment, above 99.0% | 10% = $5,000 | 10% = $5,000 | 10% = $5,000 | 10% = $5,000 |
| Below 99.0% | 30% = $15,000 | 25% = $12,500 | 25% = $12,500 | 25% = $12,500 |
| Below 95.0% | 100% = $50,000 | 100% = $50,000 | 100% = $50,000 | 100% = $50,000 |
| Commitment being tested | 99.99% | 99.99% | 99.99% | 99.9% |
Now the trap in the top row. At 99.99%, 4.3 minutes of downtime in a 30 day month is already a breach; at the 99.95% the old AWS EC2 SLA carried, you had 21.6 minutes. Runbooks written against the old number have been calling a claimable outage not claimable.
The version pinned to the provider's SLA page during the month of the outage is the one that decides your credit, not the copy in your contract folder. AWS labels older editions "not currently in effect". Google archives them. Microsoft issues new Azure editions monthly. Save a dated copy of what you rely on, because the page is the only version you can prove you were reading.
What the version trails show
The AWS archive tells the clearest story. An older standalone SLA for EC2 and EBS promised 99.95% region-level uptime and asked for the words "SLA Credit Request" in the subject line. The current Compute SLA promises 99.99% for multi-AZ deployments, adds an Instance Level SLA at 99.5%, and requires "Amazon Compute SLA Credit Request - Region-Level Claim" (or the Instance Level variant) in the subject. The rewrite also folded Elastic IP addresses, Elastic Inference and Elastic Graphics into the coverage. One detail needs no claim: AWS does not charge for a single EC2 instance unavailable more than six minutes of a clock hour.
Google's archive is the most candid: ten dated versions from October 2015 through November 2024. The current edition, last modified March 4, 2025, added a Single Instance SLO at 99.9% for most families and 99.95% for memory-optimized machines, coverage that used to require multiple zones. It also cut the commitment for Mexico and Stockholm, where multi-zone Premium instances sit at 99.95% instead of 99.99%, so the lower bar applies to workloads there.
Microsoft is a different beast. The Azure SLA is one docx, reissued almost monthly, so the edition your procurement team saved a year ago is long dead. Azure billing adds its own traps: a lapsed Enterprise Agreement falls into Indefinite Extended Term, pricing returns to retail, and the EA credit expires when the enrollment ends, with the EU program the only exception. Since August 2019 there is no opt-out, so expired enrollments drift to retail on their own.
DigitalOcean went structural too: the old umbrella SLA URL returns 404, replaced by per-product pages. The Regional Load Balancer SLA, updated December 3, 2025, shows why you re-read them: it carries a 24 hour written notice requirement, fail it and you forfeit the credit no matter how soon you file. It also sets a $1 minimum, credits only apply to future invoices, and size-1 load balancers have no SLA at all.
| Provider | The claim detail worth re-reading at renewal |
|---|---|
| AWS | Subject line "Amazon Compute SLA Credit Request - Region-Level (or Instance-Level) Claim"; file by the end of the second billing cycle |
| GCP Compute Engine | Notify support within 60 days of eligibility, with logs; credits are the sole remedy |
| Microsoft Azure | Reissued monthly; check the edition date before you file |
| DigitalOcean | Written notice within 24 hours of downtime, then a claim by the end of the second billing cycle; $1 minimum |
The traps hiding outside the SLA pages
Commitment contracts move on their own clock, and the SLA is never part of that decision. AWS Reserved Instances do not renew automatically; at expiry you keep running but pay On-Demand rates until you buy again. Google resource-based CUDs do the opposite: enable auto-renewal and the commitment renews until you disable it. Nobody re-checks the SLA at term roll.
The Microsoft enrollment handoff is the quietest trap. A new enrollment number generated at renewal does not carry your subscriptions over automatically; the prior enrollment number must sit in the renewal request. Put that item in the letter yourself, because it is too late to fix after the effective date.
What to ask for when you have negotiating room
If your bill is big enough for a named account team, negotiate the version, not the numbers. Ask that the agreement name the exact SLA edition it sits under, so a rewrite applies from the next term instead of mid-term. Ask what the renewal letter says about service credits, because the standard schedules above are published and the negotiated ones are not. Confirm in writing how credits are applied, to a future invoice or your prepayment balance.
Do this the quarter you renew
Open the SLA page for every critical service and save a dated copy in the contracts folder and the Wayback Machine. Diff it against the version you signed and write down three things that changed. Set two reminders: a quarterly check that the saved copies still match the live pages, and a calendar entry for the claim window after your annual peak. Clip this checklist to the renewal letter.
The version live when the outage happened is the version you claim under. Ten minutes of archiving turns the next status incident from a shrug into a filed claim. If tracking a dozen moving SLA pages is not your core job, that is the gap an uptime monitor fills; the one we built is UptimeAudit. Do the review anyway, before the page changes.