Turning Cloud SLA Credits into a Service for Your Managed Clients
August 9, 2026
Every cloud account you manage has money sitting in it that nobody claimed. When AWS, Azure, Google Cloud, or DigitalOcean misses its uptime commitment, the account is owed a service credit worth up to 100% of that month's bill for the affected service. Credits are claim-only: they land only if someone files within 30 to 60 days of the billing month's end. Your clients are not filing, because almost nobody files. That is the entire service in one sentence. An MSP that watches for breaches, files the claims, and lands the credit on the client's next invoice has delivered something the client can see on a bill, which is rarer in this business than it should be.
Below: who is allowed to file, the real deadlines, where the money lands, and how to price the work. Every number comes from the providers' own SLA documents.
Why clients never file
Two reasons, and neither is laziness. Providers do not tell you a credit is owed. The status page records the incident, the invoice never mentions it, and nobody at the provider sends a note that says "you are owed 10% of last month." Second, the process is built for people who already know the rules: evidence formats, subject lines, windows measured in weeks. A client running one account and a business will never learn those rules.
This is where an MSP earns the fee: you are the party that watches, matches incidents to the client's footprint, and files on time. The windows are short enough that a monthly billing review will miss them. Google Cloud gives you 30 days from the day you become eligible. A breach on the first of the month can be dead before the invoice arrives.
Who files, where, and by when
The reference sheet below. "You" means the account holder or the MSP acting with delegated access, depending on the provider.
| Provider | Who files | Channel | Deadline |
|---|---|---|---|
| AWS | Account holder | AWS Support Center case; subject line must include "SLA Credit Request" (the EC2 SLA spells it out as "Amazon Compute SLA Credit Request - Region-Level Claim") | End of the second billing cycle after the incident, about 60 days after month end |
| Azure (direct) | You | Azure portal: Help + support, issue type Billing, problem type Refund Request | 2 months from the end of the billing month |
| Azure (via CSP) | Your CSP provider | Partner Center support ticket | 2 months from the end of the billing month |
| Google Cloud | Account holder | Cloud Platform SLA contact form | 30 days from the day you become eligible |
| DigitalOcean | Account holder | Support ticket | 30 days from the end of the billing cycle; the Spaces SLA also requires written notice within 24 hours of downtime starting |
Details that usually surprise people. Azure credits apply only to the affected service and billing month, and cannot exceed that service's monthly fee. AWS and DigitalOcean do not pay credits under $1. Google expects one request per product per month, so batch incidents into a single claim.
The credit lands in the account that paid for the service. On AWS, Google Cloud, and DigitalOcean that is almost always the client's account, so the value you sell is diligence and deadline discipline, not a cut of the refund. The one exception is Azure CSP, where the credit arrives on the provider's invoice and has to be passed through to the customer.
Where the money actually lands
Get this right before you sell anything. AWS service credits are applied against future charges of the same service, and the EC2 SLA is explicit that credits "may not be transferred or applied to any other account." If you manage a client's own AWS account, the credit stays theirs. If the client runs inside your account, the credit is yours, and your managed services contract decides what happens next. Either way, plan the contract around that flow before you promise anyone a share.
Azure through CSP is the one model where the credit physically reaches you. Microsoft accepts credit requests only from CSP direct and indirect providers, and not from indirect resellers, and the approved credit appears on the provider's next invoice and reconciliation file for that customer. If you are an indirect reseller, your indirect provider files for you, and that handoff eats time out of a 60-day clock. The evidence list: the customer tenant GUID, the outage incident ID from the Service Health Dashboard, confirmation the subscriptions came through CSP, and proof the customer asked for the credit. The customer's email must come from the affected tenant's domain; a personal address is rejected.
The money math
A realistic worked example. A client runs $4,000 a month of EC2 across two availability zones in us-east-1. A 45-minute regional incident puts that month at roughly 99.9% uptime: below the 99.99% commitment, above 99.0%, so the 10% tier applies. That is $400 in credit for a support case that takes half an hour. To reach the 30% tier the same account needs more than seven hours of downtime in one month, which is why the big regional outages are the events that pay.
The honest part: many months have no breach at all. This is a subscription to diligence with occasional payouts, so price it like insurance, not like a commission.
| Pricing model | How it works | Where it fits |
|---|---|---|
| Flat monthly fee per client | You charge a fixed amount whether or not a breach happens | Predictable MRR; suits clients whose accounts you manage anyway |
| Percentage of recovered credits | You take a cut of each credit that lands | Works on Azure CSP, where the credit passes through your books; awkward on AWS, where the client never sees the money in hand |
| Bundled into the managed services contract | No separate line item; recovery is a feature | Easiest to sell, easiest to underdeliver, so it needs a visible report |
| Fee per claim filed | You charge for each claim you file | Simple, but it rewards filing marginal claims, which burns goodwill with provider support |
I would not sell a percentage on AWS work. The credit never touches your bank account, and clients resent handing over a cut of money they never saw arrive. Flat monthly or bundled keeps the relationship clean, and the provider invoice is the proof of work.
Where this breaks
Be honest about the failure modes before you build the service. Google's 30-day window means a monthly review is too slow; you need monitoring that pages you while the outage is live. AWS requires request logs from the client's own resources, so you need log access, not just a status page screenshot. Azure CSP claims need a client who replies with a tenant-domain email inside the window, and a client who ghosts you for a week can kill the claim. DigitalOcean Spaces credits expire 90 days after they are issued if the account does not use them. And every SLA has an exclusions list: maintenance, client-side faults, and force majeure are common carve-outs. Filing claims for excluded incidents teaches provider support to slow-walk the next one.
Start with one claim
Do not launch the product. Run the pilot. Take your five largest clients, pull six months of Service Health history and status archives, and find every incident that crossed a threshold for a service they actually run. Pick the strongest candidate and file it end to end: evidence, subject line, deadline. When the credit lands, bring the invoice to the client's next quarterly review and let the number make the pitch. Tools like UptimeAudit watch all four providers down to service and region and draft the claim with the deadline attached; you still press submit. One recovered claim is the entire sales deck for this service, because the client can see it on a bill.