AWS publishes SLAs for all paid, generally available services, but each service defines its own availability commitments and remedies. For Amazon EC2, that means separate Region-Level and Instance-Level guarantees, with compensation typically provided as service credits rather than cash refunds.
What it is and who it’s for
An AWS SLA is Amazon Web Services’ contractual availability commitment for a service. AWS says it offers SLAs for all paid, generally available services, and its central SLA page lists service families that include Amazon WorkSpaces, Amazon WorkSpaces Applications, Amazon WorkSpaces Thin Client, Amazon Braket, and AWS Ground Station.
This matters most for engineering managers, cloud architects, procurement teams, and FinOps leaders who need to know what contractual protection remains after an AWS outage. In the Amazon EC2 terms, the SLA applies separately to each account using Amazon EC2.
How it works
For Amazon EC2, AWS defines two different commitments.
The first is a Region-Level SLA. Under this commitment, AWS targets a 99.99% Monthly Uptime Percentage for EC2 across two or more Availability Zones in a region, where Monthly Uptime Percentage is defined as 100% minus the percentage of minutes in Unavailability. In practice, this stricter target is only available to workloads architected to run across multiple Availability Zones — a standalone instance does not qualify for the Region-Level SLA.
The second is an Instance-Level SLA, which sets a 99.5% Instance-Level Uptime Percentage for each Single EC2 Instance, calculated the same way. In practice, this less stringent availability target covers a single instance regardless of its deployment architecture, but it also takes more downtime before a credit is triggered.
The credit schedules differ by commitment type. Under the Region-Level SLA, service credits are 10% when uptime is below 99.99% but at least 99.0%, 30% when uptime is below 99.0% but at least 95.0%, and 100% when uptime is below 95.0%.
The Instance-Level SLA uses the same tiered structure against a 99.5% baseline: 10% when uptime is below 99.5% but at least 99.0%, 30% when uptime is below 99.0% but at least 95.0%, and 100% when uptime is below 95.0%.
There’s also an hourly rule that’s easy to miss in a quick read: AWS does not charge for any Single EC2 Instance that is unavailable for more than six minutes of a clockhour, and that no-charge treatment applies automatically — no credit request needed.
To receive a service credit under the EC2 SLA, a valid claim through AWS Support Center is required. AWS says claims must be submitted by the end of the second billing cycle after the incident, and any missing required information disqualifies the claim.
There’s also an anti-stacking rule: Region-Level and Instance-Level claims cannot be combined for a Single EC2 Instance.
Pricing and cost considerations
In the EC2 terms, AWS defines a Service Credit as a dollar credit that may be credited back to an eligible account, calculated from the monthly bill and excluding one-time upfront Reserved Instance payments. AWS applies that credit only against future EC2 payments, though it may at its discretion issue the credit to the payment card used for the billing cycle.
Two mechanics matter for budgeting around this. First, AWS says a Service Credit is only issued if the amount for the billing cycle is greater than one dollar — smaller credits are not paid out. Second, Service Credits cannot be transferred or applied to any other account, so organizations running EC2 across multiple AWS accounts cannot pool credits from one account to offset spend in another. AWS says it issues the Service Credit within one billing cycle after the month the request is confirmed.
How to choose
Which SLA applies is decided by architecture, not by choice: multi-AZ deployments fall under the stricter Region-Level SLA, while single-instance deployments fall under the looser Instance-Level SLA. What teams do control is whether they capture the credit they are owed. Since AWS requires a valid claim through AWS Support Center rather than applying credits automatically, incident-response runbooks should include an explicit SLA-claim step, and finance teams should plan for a billing reduction rather than a cash payment when budgeting around an outage.
Limitations and gotchas
The biggest gotcha is that not every outage becomes a payable SLA event. AWS excludes outages caused by force majeure, Internet access issues beyond EC2’s demarcation point, customer actions, customer equipment, and AWS suspension or termination under the Agreement.
Another important limitation is scope. The EC2 SLA applies separately to each account, which means eligibility is framed at the account level rather than as one pooled enterprise-wide measurement across all EC2 usage.
There is also a difference between automatic relief and requested relief. AWS says the six-minute clockhour no-charge rule for an unavailable Single EC2 Instance applies automatically, but the monthly service-credit process still requires a claim.
What this means in practice: even when an outage clears the SLA bar, the remedy is a billing credit against future EC2 spend, not a payment. Organizations should treat the AWS SLA as a contractual uptime commitment to plan around, not as business-interruption insurance.
FAQ
Is there a minimum credit amount AWS will actually pay out?
Yes, there’s a floor. AWS says a Service Credit is applicable and issued only if the credit amount for the billing cycle is greater than one dollar; smaller amounts are not credited.
Can a Service Credit earned on one AWS account be applied to a different account?
No. AWS says Service Credits may not be transferred or applied to any other account, which matters for organizations that split EC2 usage across multiple accounts.
What information does AWS require in an SLA credit request?
A case opened in AWS Support Center with:
- the correct claim type in the subject line (Region-Level or Instance-Level);
- the incident’s dates and times;
- the affected resources (region, plus AZ for instance-level claims);
- supporting request logs corroborating the outage.
Missing information disqualifies the claim.
Does the EC2 SLA also cover Elastic IP addresses or Elastic Inference attached to an instance?
Yes. AWS defines Amazon EC2 for purposes of this SLA to include Amazon Elastic Graphics, Elastic Inference, and Elastic IP Address resources purchased with the relevant EC2 instance, so those resources fall under the same Region-Level and Instance-Level commitments rather than having a separate SLA.
