AWS SLA credits, explained
When Amazon Web Services misses its 99.99% uptime commitment, you’re owed service credits. Here’s exactly how the Amazon EC2 / EBS (Region-level) schedule works — and how to claim what you’re due.
- Uptime SLA
- 99.99%
- Downtime budget
- 4 min/mo
- Claim window
- 60 days
- Max credit
- 100%
AWS credit schedule
Service credits are calculated against your monthly bill for the affected service, based on its Monthly Uptime Percentage.
| Monthly uptime | Equivalent downtime | Service credit |
|---|---|---|
| 99.0% – < 99.99% | 4 min/mo – 7.2 hrs/mo | 10% credit |
| 95.0% – < 99.0% | 7.2 hrs/mo – 36 hrs/mo | 30% credit |
| Below 95.0% | 36 hrs/mo – 720 hrs/mo | 100% credit |
Do you qualify for a AWS credit?
AWS credits aren’t automatic, and not every outage counts. Check each condition below before you spend time building a claim.
You ran the service across multiple Availability Zones
The EC2 Region-Level SLA (99.99%) only applies when your instances run in two or more AZs in the same Region. Single-AZ deployments fall under the lower Instance-Level SLA — confirm which one your architecture qualifies for before you calculate.
Monthly Uptime Percentage fell below 99.99%
Eligibility is measured per Region, per service, across the full billing month. A two-hour outage on one day is averaged across all 43,200 minutes of the month — small blips rarely cross the threshold on their own.
The unavailability was AWS’s fault
Downtime caused by your own code, security groups, instance limits, or anything AWS classes as outside its reasonable control does not count toward the Monthly Uptime Percentage.
Your account is in good standing
Accounts with overdue invoices or in breach of the Customer Agreement are ineligible until the balance is cleared.
How to claim your AWS credit
Credits aren’t automatic — you have 60 days to file. Follow these steps.
Confirm the affected region & service
Identify which AWS Region and service (EC2, RDS, S3, etc.) breached its Monthly Uptime Percentage. Each service has its own SLA schedule.
Gather your evidence
Collect CloudWatch metrics, request logs, error rates, and timestamps showing unavailability. AWS requires the dates, times, and request IDs of failed requests.
Open an AWS Support case
File a case in the Support Center under "Account and billing" → "Service Limit / SLA credit" within 60 days of the incident, attaching your evidence.
Receive credit on a future bill
Approved Service Credits are applied to a future monthly bill — not refunded as cash — and only against the affected service.
Eligibility fine print
- Service Credits are capped at the monthly charges for the affected service in the affected region.
- You must have no overdue balance and an account in good standing.
- Scheduled maintenance and issues outside AWS’s control are excluded.
Estimate your AWS credit
Enter your spend and downtime to see what AWS owes you.
A 10% credit on your $8,000 monthly AWS bill, based on 99.40% uptime.
Estimate only, based on AWS’s flagship compute SLA. Credits are capped at the affected service’s monthly charge. The smallest billable credit here is $800.00. Verify against your provider’s current agreement.
Gather your AWS claim evidence
A complete evidence pack is the single biggest factor in getting a credit approved on the first pass. Tick each item off as you collect it, then export the list for your ticket.
Gather every item below before you file. Complete evidence is the single biggest factor in getting a credit approved on the first pass.
Draft your AWS claim email
Fill in your incident details and we’ll write a claim email in AWS’s own terms, with the credit math already worked out. Copy it, attach your evidence, and send.
Fill in your incident details and we’ll draft a claim email in AWS’s own terms — ready to paste into a AWS Support case (Account and billing → SLA credit).
Subject: SLA Service Credit request — Amazon EC2 / EBS (Region-level) downtime on [incident date] Hello AWS Support, I am writing on behalf of [Your company] to request an SLA Service Credit for downtime that affected Amazon EC2 / EBS (Region-level) on our account ([account / subscription ID]). Incident summary - Affected service: Amazon EC2 / EBS (Region-level) - Date of incident: [incident date] - Total downtime: 4 hours 20 minutes - Resulting Monthly Uptime Percentage: 99.398% Amazon Web Services commits to a 99.99% Monthly Uptime Percentage SLA for this service. Our measured uptime of 99.398% falls below that commitment, which under your published SLA entitles us to a 10% Service Credit against the monthly charges for the affected service. Based on our monthly spend of $8,000 on this service, the 10% Service Credit amounts to approximately $800. Supporting documentation (attached) - Timestamped downtime windows (UTC) - Monitoring metrics / uptime checks for the incident period - The relevant invoice line item for the affected service This claim is submitted within your 60-day claim window. Please confirm receipt and let me know if you require any additional evidence to process the Service Credit. Thank you, [Your name] [Your company]
Review before sending — figures are estimates based on AWS’s flagship compute SLA. Attach your evidence and verify against your current agreement.
AWS SLA credit FAQ
- What is AWS's uptime SLA?
- Amazon Web Services commits to 99.99% Monthly Uptime Percentage for Amazon EC2 / EBS (Region-level). Falling below that threshold makes you eligible for service credits on a sliding scale, up to 100% of your monthly bill for the affected service.
- How long do I have to claim a AWS SLA credit?
- You must file your claim within 60 days of the incident (or of becoming eligible). Miss the window and the credit is forfeited — AWS does not issue credits automatically.
- Are AWS SLA credits paid as cash?
- No. Credits are applied against a future monthly invoice for the affected service, not refunded as cash, and they are capped at that service's monthly charge.
- What evidence do I need to claim a credit?
- Provide the dates and times of each downtime window plus supporting monitoring data (error rates, failed requests, uptime checks). Detailed logs make approval far more likely.