AWS SLA Credits: Exact Thresholds, Deadlines, and a Copy-Paste Claim Template
July 20, 2026
AWS will happily credit your account when it breaches a service-level agreement, provided you open a support case, cite the right SLA, attach the right evidence, and do it all before the deadline. This post is the reference sheet: exact thresholds, the deadline math, and a template you can paste into a support case today.
The thresholds that trigger a credit
AWS SLAs are per-service. "Monthly Uptime Percentage" is measured per region, per billing month. If a service drops below its committed percentage, you earn a credit equal to a percentage of what you paid for that service in that region that month.
| Service | Commitment | 10% credit | 30% credit | 100% credit |
|---|---|---|---|---|
| EC2 (multi-AZ) | 99.99% | below 99.99% | below 99.0% | below 95.0% |
| ECS / EKS (multi-AZ) | 99.99% | below 99.99% | below 99.0% | below 95.0% |
| RDS (multi-AZ) | 99.95% | below 99.95% | below 99.0% (25%) | below 95.0% |
| Lambda | 99.95% | below 99.95% | below 99.0% (25%) | below 95.0% |
| S3 | 99.9% | below 99.9% | below 99.0% (25%) | below 95.0% |
| DynamoDB | 99.99% | below 99.99% | below 99.0% (25%) | below 95.0% |
| CloudFront | 99.9% | below 99.9% | below 99.0% (25%) | below 95.0% |
Two details worth internalizing:
- The top tier triggers on any miss at all. At a 99.99% commitment, roughly 4 minutes and 23 seconds of downtime in a month is already a breach. You don't need a day-long outage to be owed money: the famous us-east-1-style incidents put nearly every customer in credit territory.
- The credit applies to the affected service in the affected region. A 30% EC2 credit covers your EC2 usage in the impacted region, not your whole AWS bill.
The deadline: 60 days, and it bites
AWS requires credit requests to arrive within 60 days of the end of the billing cycle in which the incident occurred. An outage on March 3 means the billing cycle ends March 31, and your claim must be in by the end of May.
Miss it and there is no appeal channel: the SLA stops applying to that incident. This is where most recoverable money dies: not in rejected claims, but in unfiled ones.
The deadline is 60 days from the end of the billing cycle in which the incident occurred. An outage on March 3 means the cycle ends March 31, and your claim must be filed by the end of May. Miss that window and the SLA stops applying to the incident, with no appeal.
What AWS Support asks for
The SLA terms spell out the required contents of a credit request:
- "SLA Credit Request" in the subject line. Those exact words route the case correctly.
- Your 12-digit AWS account ID.
- The billing cycle (month and year) you're claiming against.
- The region and the affected service.
- The dates and times of each impacted period, with time zone.
- Request logs that document the errors for the claimed period: AWS wants evidence the failures happened to your resources, not just a status-page screenshot. Redact anything sensitive; the logs exist to prove error rates, not to expose your data.
Small print worth knowing: individual credits under $1 aren't paid, and AWS may aggregate multiple incidents in the same service into one credit calculation for the month.
Copy-paste claim template
Fill in the bracketed fields and paste this into an AWS Support case (Account and Billing → Service Credits, or a technical support case on a paid support plan):
Subject: SLA Credit Request - Amazon EC2 - us-east-1
I am writing to request a service credit under the Amazon EC2 Service
Level Agreement.
AWS Account ID: [1234-5678-9012]
Billing Cycle: [Month YYYY]
Service: Amazon EC2
Region: [us-east-1]
Incident Details:
- Start: [YYYY-MM-DD HH:MM UTC]
- End: [YYYY-MM-DD HH:MM UTC]
- Observed downtime: [NN] minutes
During the period above, Amazon EC2 in [region] experienced a service
disruption that reduced the Monthly Uptime Percentage below the 99.99%
commitment in the EC2 SLA. The AWS Health Dashboard recorded the event
here: [link to AWS status / Personal Health Dashboard entry]
Request logs documenting the elevated error rates for our instances
during this window are attached (sensitive data redacted).
Per the EC2 SLA credit schedule, our account is eligible for a service
credit. Please review and apply the appropriate credit to our account.
Thank you,
[Name]
[Organization]
Swap the service name, SLA percentage, and region for S3, RDS, Lambda, or any other covered service; the structure stays identical.
A worked example
Say you spend $5,000/month on EC2 in us-east-1, and an incident leaves EC2 impaired in that region for 47 minutes. Monthly Uptime Percentage: roughly 99.89%, below 99.99% but above 99.0%, so the 10% tier applies.
Credit: $500 against a future bill, for about ten minutes of paperwork, if you noticed the incident, matched it to your footprint, and filed inside 60 days.
The part nobody has time for
Everything above is mechanical once you know an incident happened, that it hit your services and regions, and that the monthly math crossed a tier. The hard part in practice is surveillance: AWS runs dozens of services across 30+ regions, and its status page is not going to email you a reminder that money is owed.
That's what we built UptimeAudit for. We monitor AWS (plus Azure, Google Cloud, and DigitalOcean) down to the service and region level; you can watch it live on the AWS status page. When observed downtime crosses the SLA threshold for a service you use, we draft this exact claim pre-filled with your account details and the incident evidence, with the deadline tracked. You review it and submit it yourself; AWS still makes the final call on every claim.
The SLA is already paid for. The credit is already owed. The only variable is whether someone files.