An AWS SLA (service level agreement) is the uptime commitment Amazon Web Services publishes for each service, with service credits if it is missed. Amazon EC2, for example, commits to 99.99% monthly uptime per region for instances spread across two or more Availability Zones. Miss it, and AWS credits a future bill; it does not pay for lost business.
Key takeaways
- AWS says it offers SLAs for all paid, generally available services. Each service has its own SLA page with its own uptime percentage and credit tiers.
- Typical commitments: EC2 99.99% per region (multi-AZ) and 99.5% per instance, RDS Multi-AZ 99.95%, Lambda 99.95%, and an S3 Standard credit threshold of 99.9%.
- Remedies are service credits of 10%, 25% or 30%, and 100% of the affected service's monthly charges, depending on how far uptime fell. The SLA is your sole and exclusive remedy.
- Credits are not automatic. You open a case in the AWS Support Center, and it must arrive by the end of the second billing cycle after the incident.
- The SLA covers AWS's infrastructure, not your application. Your own uptime depends on how you design across Availability Zones and regions.
What is an AWS service level agreement?
It is a short legal document that sets a measurable availability target for one AWS service and the credit AWS gives you if it falls short. AWS lists them all on its Service Level Agreements page, grouped by category from analytics to storage, and states that it commits to offering SLAs "for all paid, generally available services". Preview and free features are therefore not covered.
Every service SLA follows the same pattern:
- A service commitment: a monthly uptime percentage, measured in a way defined for that service (for example, external connectivity for EC2, or the error rate of requests for S3).
- A credit schedule: the percentage of that month's charges you get back as credit for each band of missed uptime.
- A claim process: how and by when to ask for the credit.
- Exclusions: causes of downtime that do not count, such as your own configuration or events outside AWS's reasonable control.
Uptime percentages and credit tiers for core AWS services
The table below uses the figures on each service's SLA page as of October 2026. AWS updates these pages from time to time, so check the "last updated" date on the page before you rely on a number in a contract.
| Service and scope | Monthly uptime commitment | Service credit if missed | SLA page last updated |
|---|---|---|---|
| Amazon EC2, region level (instances in 2+ AZs in one region) | 99.99% | 10% below 99.99%; 30% below 99.0%; 100% below 95.0% | 25 May 2022 |
| Amazon EC2, instance level (each single instance) | 99.5% | 10% below 99.5%; 30% below 99.0%; 100% below 95.0% | 25 May 2022 |
| Amazon S3 Standard, Express One Zone, Glacier Flexible Retrieval, Glacier Deep Archive | Credits start below 99.9% | 10% below 99.9%; 25% below 99.0%; 100% below 95.0% | 28 Nov 2023 |
| Amazon S3 Intelligent-Tiering, Standard-IA, One Zone-IA, Glacier Instant Retrieval | Credits start below 99.0% | 10% below 99.0%; 25% below 98.0%; 100% below 95.0% | 28 Nov 2023 |
| Amazon RDS Multi-AZ instance or cluster | 99.95% | 10% below 99.95%; 25% below 99.0%; 100% below 95.0% | 22 Jan 2024 |
| Amazon RDS Single-AZ instance | 99.5% | 10% below 99.5%; 25% below 99.0%; 100% below 95.0% | 22 Jan 2024 |
| AWS Lambda, per region | 99.95% | 10% below 99.95%; 25% below 99.0%; 100% below 95.0% | 5 May 2022 |
Sources: the Amazon Compute SLA, the Amazon S3 SLA, the Amazon RDS SLA and the AWS Lambda SLA. Note that EC2's middle credit band is 30%, while S3, RDS and Lambda use 25%. Older summaries that quote one schedule for every service are wrong.
What the percentages mean in minutes
In a 30-day month (43,200 minutes), the commitments allow roughly this much downtime before credits apply:
- 99.99%: about 4.3 minutes
- 99.95%: about 21.6 minutes
- 99.9%: about 43.2 minutes
- 99.5%: about 3.6 hours
This is why the EC2 region-level figure only applies when you run instances in at least two Availability Zones. A single instance carries the 99.5% instance-level commitment, which allows hours, not minutes, of downtime per month.
How do AWS service credits work?
A service credit is a percentage of what you paid for the affected service in the affected scope that month. For EC2 at region level, it is a percentage of your monthly EC2 bill in that region, excluding one-time payments such as upfront Reserved Instance fees. For an instance-level claim, it is a percentage of that one instance's bill.
A worked example: you spend USD 8,000 on EC2 in eu-north-1 (Stockholm) in a month, and region-level uptime for your multi-AZ instances comes in at 99.95%. That is below 99.99% but above 99.0%, so the credit is 10%, or USD 800, applied against future EC2 payments.
Other rules from the EC2 SLA that catch people out:
- Credits go against future payments for the same service. They do not entitle you to a refund or cash payment.
- AWS issues a credit only if it is worth more than USD 1 for the billing cycle.
- You can claim under the region-level or the instance-level SLA for an instance, not both.
- The SLA is your "sole and exclusive" remedy for unavailability, unless your agreement with AWS says otherwise.
How to claim a service credit from AWS
- Collect evidence. Record the dates and times of the incident, the affected region (and Availability Zone for instance-level claims), the resource IDs, and logs that show the outage. Redact sensitive data.
- Open a case in the AWS Support Center. Use the subject line the SLA asks for. For EC2 it is "Amazon Compute SLA Credit Request – Region-Level Claim" or "– Instance-Level Claim"; for S3 the subject must include "SLA Credit Request".
- Submit in time. For EC2 and S3, AWS must receive the request by the end of the second billing cycle after the incident.
- Track the outcome. AWS confirms whether the downtime qualifies and applies the credit to a later invoice.
Teams that run many accounts often miss credits because nobody owns this process. If you work with a managed service provider, make claim handling part of the contract.
What do AWS SLAs not cover?
The exclusions are similar across services. Downtime does not count towards the SLA if it is caused by:
- factors outside AWS's reasonable control, including internet problems beyond AWS's network edge;
- your own actions or inaction, such as ignoring health notices or misconfiguring resources;
- your own equipment, software or other technology;
- AWS suspending or ending your use of the service under the agreement.
Two other things often get mixed up with the SLA:
- Performance. The core SLAs measure availability (connectivity or error rates), not latency or throughput. A slow but reachable service is generally not "unavailable".
- Support response times. These sit in your AWS Support plan, not in a service SLA, and AWS describes them as targets it will make "every reasonable effort" to meet. Current plans list, for example, under one hour for a production system down case on Business Support+ and under 15 minutes for a business-critical system down case on Enterprise Support. Missing them does not trigger service credits.
Why your application uptime is your responsibility
The SLA tells you what AWS promises for one service. Your users experience the whole chain: load balancer, compute, database, storage, DNS and your own code. If each part fails independently, the availability of the chain is roughly the product of the parts. An application that needs EC2 at 99.99% and an RDS Multi-AZ database at 99.95% has an expected ceiling of about 99.94% before you count your own code and deployments.
To get beyond what a single service offers, design for failure:
- run compute in at least two Availability Zones behind a load balancer;
- use Multi-AZ deployments for databases;
- automate recovery and test it, including backup restores;
- for the most critical systems, consider a second region with a tested failover plan.
The Reliability pillar of the AWS Well-Architected Framework covers these patterns in detail. Our guide to cloud SLAs in general explains how to compare commitments across providers, and the Azure SLA article covers Microsoft's equivalent.
Example: multi-AZ design in practice
When Opsio moved Swedish ski resort group Branäsgruppen from VMware to AWS, critical applications were placed in multiple Availability Zones with auto-scaling and managed databases to handle peak-season traffic. The case reports 99.9%+ application uptime and a 40% reduction in total cost of ownership after the migration.
AWS SLAs vs a managed service provider SLA
An AWS SLA covers the platform. A managed service provider's SLA covers the work done on top of it: how fast someone responds to an alert, how quickly they start fixing it, and what availability they commit to for the environment they run. The two complement each other. For example, Opsio's standard cloud managed services SLA includes 15-minute triage for critical alerts and 1-hour active remediation, with service credits if response times are missed. Read the detail of any provider's SLA, including ours on the Opsio cloud SLA page, the same way you read AWS's: what is measured, how, and what you get when it is missed.
Frequently asked questions
What is the AWS SLA uptime?
It depends on the service. EC2 commits to 99.99% per region for instances in two or more Availability Zones and 99.5% per single instance. RDS Multi-AZ and Lambda commit to 99.95%. S3 Standard credits start when uptime falls below 99.9%.
Does AWS guarantee 100% uptime?
No. No AWS service SLA promises 100%. The highest common commitment is 99.99%, which still allows about four minutes of downtime in a 30-day month. Higher availability has to come from your own architecture.
What happens if AWS does not meet its SLA?
You can claim a service credit of 10% to 100% of the affected service's monthly charges, depending on how low uptime fell. Credits apply to future bills, are not paid in cash, and are your sole remedy unless your agreement says otherwise.
How long do I have to claim an SLA credit from AWS?
For EC2 and S3, AWS must receive your request by the end of the second billing cycle after the incident. You submit it as a case in the AWS Support Center with the subject line the SLA specifies.
Is AWS Support response time part of the SLA?
No. Response times belong to your AWS Support plan and are described as targets. Service SLAs cover availability only, and only service SLAs give credits.
Are all AWS services covered by an SLA?
AWS says it offers SLAs for all paid, generally available services. Services in preview are not covered, and each service has its own terms, so check the specific SLA page for every service your application depends on.
Related reading: aws sla.
Related reading: What Happens If Azure Does Not Meet Its Own Service Level Agreement Guarantee (Sla).
Related reading
Written By
Country Manager, India
Praveena leads Opsio's India operations, bringing 17+ years of cross-industry experience spanning AI, manufacturing, DevOps, and managed services.
Editorial standards: This article was written by the cloud practitioner named in the byline above. We revise it when the technology or regulation it covers changes; the dates on this page show the latest update. Opsio maintains editorial independence.