Understanding AWS Service Level Agreements (SLAs): A Practical Guide for Builders
A practical breakdown of how AWS Service Level Agreements work, including uptime commitments, service credit tiers, and how to design reliable systems using SLAs for EC2, S3, Lambda, and RDS.
What Is an AWS Service Level Agreement?
An AWS Service Level Agreement (SLA) is a contractual commitment about the availability of a given service over a monthly billing cycle, backed by service credits if AWS misses it. It is separate from a service's documentation: the SLA is a legal document, published independently for most AWS services, that defines a target Monthly Uptime Percentage, how that percentage is measured, and what AWS owes the customer when it falls short.
SLAs matter for two reasons. First, they describe the floor AWS itself is willing to commit to in writing, which is a useful signal when comparing services or deployment patterns. Second, SLA credits are not a substitute for your own reliability engineering: they compensate you financially after an outage, they do not prevent one. Treating "AWS commits to 99.99% uptime" as equivalent to "my application will experience 99.99% uptime" confuses a vendor commitment with an architecture decision.
How AWS SLA Credits Actually Work
Nearly every AWS SLA follows the same structure, whether it covers compute, storage, databases, or a managed service.
Monthly Uptime Percentage
Each SLA defines "Unavailable" for that specific service (no external connectivity for EC2, failed connection attempts for RDS, a threshold error rate for S3) and then calculates Monthly Uptime Percentage as 100% minus the share of the billing cycle the service was Unavailable. AWS commits to keep that percentage above a stated threshold using "commercially reasonable efforts," not an absolute guarantee.
Service Credits, Not Refunds
If AWS misses the threshold, you receive a service credit: a percentage discount applied to a future bill, not a cash refund. Credit tiers step up as the shortfall gets worse, typically something like 10% back for a modest miss, 25 to 30% for a larger one, and 100% if uptime drops below 95%. Credits are calculated against the charges for the affected service and region, not your entire AWS bill, and most SLAs only pay out if the credit would exceed $1.
Filing a Claim
Critically, AWS does not apply these credits automatically in most cases. You have to notice the outage, document it, and file a claim:
- Open a case in the AWS Support Center within the window the SLA specifies (usually by the end of the second billing cycle after the incident)
- Include the affected region, the service, start and end timestamps, and supporting evidence such as logs
- State which SLA you are claiming under, since some services have separate tiers (for example EC2's region-level vs. instance-level SLA) that cannot be combined
SLA Commitments Across Core AWS Services
The specifics vary a lot by service. Here is what the published SLAs actually commit to, as of this writing, for four services most builders touch daily.
Amazon EC2
EC2 has two separate SLAs. The region-level SLA commits to 99.99% Monthly Uptime Percentage, but only applies if your instances are spread across two or more Availability Zones in the same region (or two regions). The instance-level SLA commits to 99.5% for a single instance with no redundancy. Credits run 10% for falling below the threshold but staying at or above 99.0%, 30% for dropping into the 95.0% to 99.0% band, and 100% below 95.0%. Separately, and automatically, AWS does not charge for any instance that is unavailable for more than six minutes in a clock hour.
Amazon S3
S3's SLA works differently: instead of one headline uptime number, it defines an Error Rate (the share of requests per type, per 5-minute interval, that return InternalError or ServiceUnavailable) and derives Monthly Uptime Percentage from that. Credit tiers differ by storage class: S3 Standard and similar classes get 10% back below 99.9% uptime, 25% below 99.0%, and 100% below 95.0%; the Infrequent Access and Intelligent-Tiering classes use a lower starting threshold. Either way, the mechanism is the same: AWS is measuring error rates against your actual request pattern, not a single global switch.
AWS Lambda
Lambda commits to 99.95% Monthly Uptime Percentage per AWS Region. Credits are 10% for dropping below that but staying at or above 99.0%, 25% for the 95.0% to 99.0% band, and 100% below 95.0%. Because Lambda is regional and serverless, there is no instance-level carve-out the way there is for EC2.
Amazon RDS
RDS mirrors EC2's two-tier structure. A Multi-AZ DB instance or cluster is covered by a 99.95% Monthly Uptime Percentage commitment; a single-AZ instance with no standby is covered by a separate 99.5% instance-level commitment. Both use 10% / 25% / 100% credit tiers depending on how far uptime falls. The gap between the two targets is the SLA's way of pricing in the reliability benefit of Multi-AZ: AWS will not credit a single-AZ instance as if it had failover it does not have.
SLA vs. SLO vs. SLI
It is worth keeping three related terms straight. An SLI (Service Level Indicator) is a measurement, like the actual error rate your service returned last hour. An SLO (Service Level Objective) is an internal target you set for that measurement, like "99.9% of requests succeed." An SLA is what you turn an SLO into once it is written into a contract with consequences attached, typically for a paying customer. AWS's SLAs are its own SLOs made contractual toward you; your application's SLA, if you offer one, should be built on top of AWS's numbers plus your own architecture, not copied from them directly.
Designing Your Own SLA on Top of AWS's
A common mistake is assuming a managed service's SLA becomes your application's SLA for free. It does not, for a few reasons:
- Your application is a composition of multiple AWS services, each with its own SLA; the combined availability of a chain of dependent services is the product of their individual availabilities, which is always lower than any single one
- Single-AZ or single-instance deployments fall under the weaker, instance-level SLA tier for EC2 and RDS, not the headline 99.99%/99.95% figures, unless you explicitly architect for Multi-AZ or multi-region redundancy
- SLA credits are backward-looking compensation, not an uptime guarantee for any specific hour, so they do nothing for a customer who needed your service during the exact window it was down
- Code, configuration, and operational mistakes on your side are not covered by any AWS SLA, and in practice cause more downtime for most applications than AWS regional incidents do
In practice this means budgeting your own error budget from the ground up: multiply the uptime commitments of every service in your critical path, subtract margin for your own deployment and operational risk, and only then decide what you are comfortable promising a customer.
Key Takeaways
- An SLA is a financial commitment with credits attached, not an uptime guarantee; it compensates you after the fact, it does not prevent outages
- Read the specific SLA for each service you depend on; thresholds, credit tiers, and what counts as "Unavailable" differ by service and are not interchangeable
- Single-instance and single-AZ deployments fall under weaker SLA tiers than the headline numbers most people quote
- Claiming a credit is a manual process with a filing deadline, not an automatic refund
- Your application's real-world reliability depends on the composition of every service in its critical path plus your own operational practices, not on any one SLA in isolation
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article