An AWS uptime miss buys a bill credit, not a refund

The workload

Nothing in the EC2 Service Level Agreement or the S3 Service Level Agreement triggers a credit on its own. A founder has to notice degraded availability, then keep the records the documents ask for: incident dates and times, affected resource identifiers, and a request filed through the AWS Support Center. Both documents state, verified, that a credit request must arrive 'by the end of the second billing cycle after which the incident occurred,' and the S3 version further requires the words 'SLA Credit Request' in the subject line. AWS does not calculate or apply credits automatically; the workload is watching, logging and filing, and it falls entirely on the customer.

What the documents show

Verified, as the EC2 SLA states it: AWS commits to 99.99% monthly uptime across multiple Availability Zones (a region-level commitment) and 99.5% for a single running instance. Verified, as the S3 SLA states it: standard storage classes carry a 99.9% commitment, while Intelligent-Tiering and the infrequent-access classes use a lower 99.0% threshold, calculated over 5-minute error-rate intervals across the monthly cycle rather than a single outage clock. Both documents name the same exclusions, verified: force majeure, factors outside AWS's 'reasonable control,' the customer's own equipment or software, and any period after suspension or termination. Read together, AWS does not offer one uptime number for its infrastructure; it offers a different one for every product and, within S3, every storage class.

The operating cost

The remedy is a service credit against a future bill, not cash and not compensation for lost business; neither document uses the word refund. Verified tiers: for EC2, 10% credit at 99.0%–99.99% actual uptime, 30% at 95.0%–99.0%, and 100% below 95.0%, applied only to that cycle's charges for the affected service. S3's Standard-class tiers are 10% (99.0%–99.9%), 25% (95.0%–99.0%) and 100% (below 95.0%). A credit is bounded by what the customer actually spent on that resource that cycle, so a single small instance produces a correspondingly small credit even at the 100% tier — an estimate this entry draws from the tiers, not a figure either SLA states directly.

The stop condition

The claim right expires on a fixed clock, verified: miss the end of the second billing cycle after the incident and the SLA text gives no path to recover it. Editorially, the workload of monitoring and filing only pays off once the credit's value exceeds the time spent assembling the claim; for a handful of small instances, that point may never arrive, a plausible reason some accounts never file even after a qualifying outage.

• Does the workload on this instance or bucket matter enough that a percentage-of-bill credit would meaningfully offset the outage?
• Does the region-level EC2 commitment apply, or does the deployment depend on a single instance governed by the lower 99.5% figure?
• Who on a one-person team is responsible for filing within the two-billing-cycle window?

Both documents commit AWS to a number and a remedy narrower than the general reliability reputation the platform carries. This entry describes only that promise, as retrieved on 16 September 2026, not any specific dated outage.