AWS writes one of the more generous credit schedules in the industry, and it collects on almost none of it. The reason is structural: there is no single "AWS SLA." Each service (EC2, S3, RDS, Lambda) carries its own document, its own uptime target, and its own credit tiers, and the burden of proving a breach sits entirely with you. This guide walks the AWS-specific process end to end, so a bad month turns into a filed claim instead of a forgotten one. For the cross-provider version, see the complete claim guide; to see the dollar figure before you start, run the numbers in the SLA calculator.
Find the right AWS SLA first
Because AWS splits its commitments by service, the first job is matching your outage to the correct document. A regional EC2 event is governed by the Amazon Compute Service Level Agreement. An S3 availability drop falls under the Amazon S3 SLA. RDS has its own. Claiming the wrong document, or worse, claiming against your whole AWS bill, is the fastest route to a slow, skeptical review.
Here are the targets that matter most:
| Service | Target (Monthly Uptime %) | Notes |
|---|---|---|
| EC2 / EBS | 99.99% | Requires instances running across two or more Availability Zones in a region |
| S3 Standard | 99.9% | Measured per region as error rate over 5-minute intervals |
| RDS (Multi-AZ) | 99.95% | Single-AZ deployments carry a lower commitment |
The EC2 two-AZ prerequisite trips up a lot of teams. A single-AZ event may hurt you badly and still not breach the regional Compute SLA, because AWS measures availability at the region level across zones. Know which target you are claiming against before you write a word.
Convert your downtime to a percentage
AWS grades every claim on Monthly Uptime Percentage, so translate raw minutes:
uptime % = (43,200 - downtime minutes) / 43,200 * 100
A 90-minute EC2 disruption in a 30-day month is 99.79% uptime. That sits below the 99.99% target and inside the "less than 99.99% but at least 99.0%" band, which pays a 10% credit on your EC2 charges for that region and month. If you need the tier boundaries worked out for you, our downtime and uptime guide shows the full conversion table with examples.
Gather AWS-grade evidence, fast
AWS reviewers want corroboration, and the artifacts weaken every day after the incident. Capture:
- The AWS Health Dashboard event. This is your least disputable evidence: AWS's own record that something failed. Export or screenshot the event ID and window.
- CloudWatch and monitoring graphs. Availability, error-rate, and latency panels covering the incident window, with the region and time zone visible.
- Affected resource identifiers. Instance IDs, EBS volume IDs, bucket names, DB instance identifiers, and their regions. AWS evaluates claims per resource, per region.
- A sample of failed requests. A handful of 5xx responses or failed request IDs. AWS explicitly asks for logs that corroborate the outage window.
Open the claim folder the day the incident resolves. Waiting a sprint is how evidence, and credits, evaporate.
File the case within the window
AWS accepts SLA claims through the end of the second billing cycle after the incident, roughly 60 days. File through the AWS Support Center, using a clear subject such as "SLA Credit Request - Amazon EC2 - us-east-1." Structure the body like an invoice, not a complaint:
- The SLA by name: "Amazon Compute Service Level Agreement."
- The month, account, and resources: billing month, account ID, affected instance IDs and region.
- The measured uptime and tier: "Measured Monthly Uptime Percentage of 99.79% falls below the 99.99% commitment, in the 10% credit tier."
- The requested credit: "10% of July EC2 charges in us-east-1: $1,240."
Attach the evidence. Keep the tone factual: the SLA makes this a contractual entitlement, not a favor.
Track the credit onto the invoice
Approved AWS credits land as a line item on a subsequent invoice, usually one to two billing cycles later, applied against the affected service. Verify it actually posts; approved claims sometimes stall between approval and invoicing. If AWS rejects on an exclusion (scheduled maintenance, customer-caused downtime), ask for the exact clause and re-check it against your Health Dashboard export. Exclusion calls are frequently reversible with better data.
Where AWS fits in the wider picture
AWS is only one provider you may be owed by. The sibling Azure and Google Cloud guides cover their very different windows and targets. For the credit-recovery playbooks and negotiation angles, see cloud-credits.com. To confirm an incident even happened at the times you think, cross-reference the historical outage records at clouddowntime.com/data and set up breach alerts at awsdown.com/alerts. When you are ready, walk the general how it works flow, then file.
The math is not subtle. On a $60,000/month EC2 footprint, a single 10% tier is $6,000 for the time it takes to write one support case. AWS is betting you will not send it. Send it.