Cloud Infrastructure
Amazon Web Services SLA credit guide
What Amazon Web Services owes you when it misses its uptime commitment — the credit tiers, the filing deadline, how to file, and a calculator to estimate your credit.
What SLA credit are you owed when Amazon Web Services is down?
When AWS (generic service) falls below its 99.9% monthly uptime commitment, you're owed an SLA service credit worth 10%–100% of the affected service's monthly spend — larger the further uptime fell — claimable within 60 days of the end of the affected billing month. It's a credit toward a future invoice, not a cash refund.
Full Amazon Web Services claim guide · What is an SLA credit? · SLA glossary
Uptime commitment
99.9%
Filing window
60 days
counted from the end of the affected billing month
Services with SLA data
7
Credit calculator
SLA target is 99.9% — enter what you actually observed.
Enter your monthly spend above to see the dollar credit for a 10% tier.
Estimate only, from the vendor’s published tiers — the final credit is set by the vendor against your actual invoice and their SLA definitions.
Credit tiers by service
| Measured uptime | Credit |
|---|---|
| 99% – under 99.9% | 10% of spend |
| 95% – under 99% | 25% of spend |
| below 95% | 100% of spend |
Health API + Support API require Business/Enterprise Support (Basic/Developer get neither). Credit only if > $1. THE WINDOW IS COUNTED IN BILLING CYCLES, NOT DAYS: every AWS service SLA says "the credit request must be received by us by the end of the second billing cycle after which the incident occurred", so an incident early in a month has roughly 90 days and one at month-end roughly 60 — Ontracko computes the conservative earlier date. ⚠️ THE REQUIRED CASE SUBJECT IS PER-SERVICE — read it off the service note below, never off a sibling service. GENERIC AWS PROFILE — the commitment, the credit table and the required case subject above are the AWS family's common shape, not the specific service's terms; read them off that service's own SLA page before filing. ⚠️ THE REQUIRED CASE SUBJECT IS PER-SERVICE, NOT VENDOR-WIDE: the Compute SLA demands exactly "Amazon Compute SLA Credit Request – Region-Level Claim" (or "…Instance-Level Claim"), the RDS SLA demands exactly "Amazon RDS SLA Credit Request – Multi-AZ Claim" (or "…Single-DB Claim"), while the S3, CloudFront, DynamoDB and Lambda SLAs only require the subject to CONTAIN the words "SLA Credit Request". Never carry one service's subject across to another. Index of all AWS service SLAs: https://aws.amazon.com/legal/service-level-agreements/.
| Measured uptime | Credit |
|---|---|
| 99% – under 99.9% | 10% of spend |
| 95% – under 99% | 25% of spend |
| below 95% | 100% of spend |
Measured how? Amazon CloudFront is measured as a request success rate — errors as a share of total requests, averaged over short intervals — not as wall-clock uptime. Availability for this service is the vendor’s Monthly Uptime Percentage under that definition, which only Amazon Web Services can compute from its request logs. A status-page outage is evidence that a qualifying event happened; it is not the contractual figure.
Health API + Support API require Business/Enterprise Support (Basic/Developer get neither). Credit only if > $1. THE WINDOW IS COUNTED IN BILLING CYCLES, NOT DAYS: every AWS service SLA says "the credit request must be received by us by the end of the second billing cycle after which the incident occurred", so an incident early in a month has roughly 90 days and one at month-end roughly 60 — Ontracko computes the conservative earlier date. ⚠️ THE REQUIRED CASE SUBJECT IS PER-SERVICE — read it off the service note below, never off a sibling service. SUBJECT LINE: the case subject must CONTAIN the exact words "SLA Credit Request" — CloudFront prescribes no fixed full subject, so the Compute string would satisfy the letter of the requirement while naming the wrong SLA; write a CloudFront subject. CREDIT BASE: "a percentage of the total charges paid by you for Amazon CloudFront for the billing cycle in which the error occurred" — the whole CloudFront bill for that cycle, not a per-distribution or per-region slice, which is the opposite of how S3's base works. Source: https://aws.amazon.com/cloudfront/sla/.
| Measured uptime | Credit |
|---|---|
| 99% – under 99.99% | 10% of spend |
| 95% – under 99% | 25% of spend |
| below 95% | 100% of spend |
Measured how? Amazon DynamoDB is measured as a request success rate — errors as a share of total requests, averaged over short intervals — not as wall-clock uptime. Availability for this service is the vendor’s Monthly Uptime Percentage under that definition, which only Amazon Web Services can compute from its request logs. A status-page outage is evidence that a qualifying event happened; it is not the contractual figure.
Health API + Support API require Business/Enterprise Support (Basic/Developer get neither). Credit only if > $1. THE WINDOW IS COUNTED IN BILLING CYCLES, NOT DAYS: every AWS service SLA says "the credit request must be received by us by the end of the second billing cycle after which the incident occurred", so an incident early in a month has roughly 90 days and one at month-end roughly 60 — Ontracko computes the conservative earlier date. ⚠️ THE REQUIRED CASE SUBJECT IS PER-SERVICE — read it off the service note below, never off a sibling service. SUBJECT LINE: the case subject must CONTAIN the exact words "SLA Credit Request" — DynamoDB prescribes no fixed full subject, so the Compute string would satisfy the letter of the requirement while naming the wrong SLA; write a DynamoDB subject. ⚠️ TWO COMMITMENTS: this profile carries the STANDARD 99.99% one. DynamoDB publishes a separate GLOBAL TABLES SLA at 99.999% with the same 10%/25%/100% bands, so a global-table workload breaches at a level this row does not detect — check which SLA your tables sit under before quoting the commitment. AWS's own measure is a REQUEST SUCCESS RATE (the share of Requests not returning 500/503, averaged over 5-minute intervals), not wall-clock uptime, so cite the request-level errors you observed alongside the incident timeline. Credits are applied against future DynamoDB payments. Source: https://aws.amazon.com/dynamodb/sla/.
| Measured uptime | Credit |
|---|---|
| 99% – under 99.99% | 10% of spend |
| 95% – under 99% | 30% of spend |
| below 95% | 100% of spend |
Health API + Support API require Business/Enterprise Support (Basic/Developer get neither). Credit only if > $1. THE WINDOW IS COUNTED IN BILLING CYCLES, NOT DAYS: every AWS service SLA says "the credit request must be received by us by the end of the second billing cycle after which the incident occurred", so an incident early in a month has roughly 90 days and one at month-end roughly 60 — Ontracko computes the conservative earlier date. ⚠️ THE REQUIRED CASE SUBJECT IS PER-SERVICE — read it off the service note below, never off a sibling service. SUBJECT LINE IS EXACT FOR COMPUTE: the case subject must be "Amazon Compute SLA Credit Request – Region-Level Claim", or "Amazon Compute SLA Credit Request – Instance-Level Claim" where the claim is against a single instance rather than a whole region. This is the Compute/EC2 string ONLY — every other AWS service in this catalog has its own subject requirement, so never carry it across. Region-level claims need evidence of unavailability in 2+ Availability Zones in the region; instance-level claims name the affected AZ. Source: https://aws.amazon.com/compute/sla/.
| Measured uptime | Credit |
|---|---|
| 99% – under 99.95% | 10% of spend |
| 95% – under 99% | 25% of spend |
| below 95% | 100% of spend |
Measured how? AWS Lambda is measured as a request success rate — errors as a share of total requests, averaged over short intervals — not as wall-clock uptime. Availability for this service is the vendor’s Monthly Uptime Percentage under that definition, which only Amazon Web Services can compute from its request logs. A status-page outage is evidence that a qualifying event happened; it is not the contractual figure.
Health API + Support API require Business/Enterprise Support (Basic/Developer get neither). Credit only if > $1. THE WINDOW IS COUNTED IN BILLING CYCLES, NOT DAYS: every AWS service SLA says "the credit request must be received by us by the end of the second billing cycle after which the incident occurred", so an incident early in a month has roughly 90 days and one at month-end roughly 60 — Ontracko computes the conservative earlier date. ⚠️ THE REQUIRED CASE SUBJECT IS PER-SERVICE — read it off the service note below, never off a sibling service. SUBJECT LINE: the case subject must CONTAIN the exact words "SLA Credit Request" — Lambda prescribes no fixed full subject, so the Compute string would satisfy the letter of the requirement while naming the wrong SLA; write a Lambda subject. Source: https://aws.amazon.com/lambda/sla/.
| Measured uptime | Credit |
|---|---|
| 99% – under 99.95% | 10% of spend |
| 95% – under 99% | 25% of spend |
| below 95% | 100% of spend |
Health API + Support API require Business/Enterprise Support (Basic/Developer get neither). Credit only if > $1. THE WINDOW IS COUNTED IN BILLING CYCLES, NOT DAYS: every AWS service SLA says "the credit request must be received by us by the end of the second billing cycle after which the incident occurred", so an incident early in a month has roughly 90 days and one at month-end roughly 60 — Ontracko computes the conservative earlier date. ⚠️ THE REQUIRED CASE SUBJECT IS PER-SERVICE — read it off the service note below, never off a sibling service. SUBJECT LINE IS EXACT FOR RDS, AND IT IS NOT THE COMPUTE ONE: the case subject must be "Amazon RDS SLA Credit Request – Multi-AZ Claim", or "Amazon RDS SLA Credit Request – Single-DB Claim" for a Single-AZ DB Instance claim. Filing an RDS claim under the Compute subject states the wrong SLA on the face of the case. ⚠️ TWO TABLES: this profile carries the MULTI-AZ one (99.95%, 10%/25%/100%). The Single-DB Instance SLA commits to a different level and its 10% band starts below 99.5% — claim against the table that matches the instance you ran. Source: https://aws.amazon.com/rds/sla/.
| Measured uptime | Credit |
|---|---|
| 99% – under 99.9% | 10% |
| 95% – under 99% | 25% |
| below 95% | 100% |
Measured how? Amazon S3 is measured as a request success rate — errors as a share of total requests, averaged over short intervals — not as wall-clock uptime. Availability for this service is the vendor’s Monthly Uptime Percentage under that definition, which only Amazon Web Services can compute from its request logs. A status-page outage is evidence that a qualifying event happened; it is not the contractual figure.
A percentage of what? Amazon S3’s credit is a percentage of the total charges paid for the applicable Amazon S3 storage class in the AWS Region (or, for S3 Express One Zone, the AWS Availability Zone) affected for the billing cycle — per storage class per Region, not your whole S3 bill — not of your invoice. The Credit column above is that percentage, and it converts to no dollar figure we can compute for you, because that base is not a figure Ontracko holds — quote the tier and ask Amazon Web Services to apply it to the base its own SLA sets.
Health API + Support API require Business/Enterprise Support (Basic/Developer get neither). Credit only if > $1. THE WINDOW IS COUNTED IN BILLING CYCLES, NOT DAYS: every AWS service SLA says "the credit request must be received by us by the end of the second billing cycle after which the incident occurred", so an incident early in a month has roughly 90 days and one at month-end roughly 60 — Ontracko computes the conservative earlier date. ⚠️ THE REQUIRED CASE SUBJECT IS PER-SERVICE — read it off the service note below, never off a sibling service. SUBJECT LINE: the case subject must CONTAIN the exact words "SLA Credit Request" — S3 does not prescribe a fixed full subject the way the Compute and RDS SLAs do, so the Compute string satisfies the letter of this requirement while misdescribing which SLA you are claiming under; write an S3 subject. ⚠️ TWO TABLES, AND THIS PROFILE CARRIES THE STANDARD-CLASS ONE: the 99.9% commitment and the 10%/25%/100% bands above apply to S3 STANDARD (with S3 Express One Zone, S3 Glacier Flexible Retrieval and S3 Glacier Deep Archive). S3 Intelligent-Tiering, S3 Standard-Infrequent Access, S3 One Zone-Infrequent Access and S3 Glacier Instant Retrieval sit on a SEPARATE table whose 10% band starts below 99.0% (not 99.9%) and whose 25% band starts below 98.0% — check which storage class the affected charges belong to before quoting a percentage. CREDIT BASE: "a percentage of the total charges paid by you for the applicable Amazon S3 storage class in the AWS Region (or, for S3 Express One Zone, the AWS Availability Zone) affected for the billing cycle" — per storage class per Region, not your whole S3 bill. Source: https://aws.amazon.com/s3/sla/.
How to file a Amazon Web Services SLA credit claim
Portal: AWS Support Center ↗
- ⚠️ THE REQUIRED CASE SUBJECT IS PER-SERVICE, NOT PER-VENDOR — this is the step that gets read wrong, because AWS's service SLAs prescribe it three different ways. EC2 / Compute: the subject must be exactly "Amazon Compute SLA Credit Request – Region-Level Claim", or "…– Instance-Level Claim" for a single instance. RDS: exactly "Amazon RDS SLA Credit Request – Multi-AZ Claim", or "…– Single-DB Claim" — a genuinely different string, and filing an RDS claim under the Compute subject names an SLA you are not claiming under. S3, CloudFront, DynamoDB, Lambda: no fixed subject, but it must CONTAIN the words "SLA Credit Request". Take the subject off the SLA of the service you are claiming on, never off a sibling.
- ⏰ THE WINDOW IS COUNTED IN BILLING CYCLES, NOT IN DAYS. All six AWS SLAs say it identically: "the credit request must be received by us by the end of the second billing cycle after which the incident occurred." So the real deadline depends on WHERE IN THE MONTH the incident fell — an incident on the 1st has roughly 90 days, one on the 31st roughly 60. Ontracko computes the conservative earlier date (month-end + 60 days), which is at most a day or two before AWS's own; file by that date and you are safely inside AWS's window, never outside it.
- Sign in to the AWS account that incurred the affected usage.
- Open Support Center → "Create case" → choose Account and billing → Service: Billing, Category: SLA Credit Request. Then set the case SUBJECT to the exact string your service requires (step 1) — the category is AWS's console taxonomy, the subject line is the SLA's stated condition, and they are not the same field.
- Paste the claim text from section 8 below into the case description.
- Attach your own confirmation from the AWS Health Dashboard (account-specific events strengthen the claim). For the request-rate services — S3, CloudFront, DynamoDB, Lambda — AWS's contractual measure is the share of requests returning 500/503 errors averaged over 5-minute intervals, not wall-clock downtime, so include your own request/error logs for the window alongside the timeline.
- CHECK WHICH TABLE YOU ARE CLAIMING UNDER before quoting a percentage — several AWS services publish more than one. S3 has a second table for Intelligent-Tiering, Standard-IA, One Zone-IA and Glacier Instant Retrieval whose bands start lower than the Standard-class table's; RDS has a separate Single-DB table alongside Multi-AZ; DynamoDB has a Global Tables SLA at 99.999% alongside the standard 99.99%. The credit base differs too: S3 pays on the charges for the affected storage class in the affected Region, while CloudFront pays on the total CloudFront charges for the billing cycle.
- AWS credits are applied to a future invoice after approval, and only where the credit for the billing cycle exceeds one dollar — watch the case for their response.
Evidence you’ll need
- •Account ID
- •Affected region
- •Incident timestamps
- •Request logs documenting the errors
- •Affected AZ (instance-level) or 2+ AZs (region-level)
Common exclusions
- •Scheduled maintenance
- •Customer-caused issues
Frequently asked
What is Amazon Web Services's SLA uptime commitment?
AWS (generic service) carries a 99.9% monthly uptime commitment.
How much credit can I claim if Amazon Web Services misses its SLA?
Credits are tiered by measured uptime, from 10% up to 100% of the monthly service spend for the affected service, depending on how far below 99.9% availability fell.
What is the deadline to file a Amazon Web Services SLA credit claim?
Claims are generally due within 60 days of the end of the affected billing month (verify the exact clause in Amazon Web Services's SLA before filing).
Does Ontracko file Amazon Web Services SLA credit claims for me?
Ontracko monitors Amazon Web Services for free, detects SLA breaches automatically, and assembles the complete claim package (evidence + credit math + claim text). You file it; Ontracko charges 8% only on credits that are actually recovered.
Let Ontracko file it for you
Connect Amazon Web Services and Ontracko monitors the SLA, catches every breach, and drafts the claim with the evidence attached. Free — 8% only on recovered credits.