AWS ECS SLA Credits & Refunds

When ECS misses its uptime target, your team rarely gets a credit automatically — AWS waits for a billing case before issuing anything. This guide walks through the specific ECS SLA tiers, what AWS considers a qualifying event for a compute service, and the evidence you need to assemble before you open a case.

What this guide covers

• The official AWS ECS uptime commitment and credit tiers
• Which incidents qualify (and which exclusions silently disqualify claims)
• How to file an ECS credit request inside the AWS claim window
• Why manual claim recovery typically leaves money on the table

Frequently asked questions about AWS ECS SLAs

What is the typical SLA uptime guarantee for AWS ECS?

AWS commits to a 99.99% Monthly Uptime Percentage for Multi-AZ ECS deployments and a separate 99.5% Task-Level commitment for individual tasks (including Fargate tasks). Service credits range from 10% (between 99.0% and the applicable threshold) to 100% (below 95.0%) of the affected ECS or Fargate charges.

How do I claim AWS ECS SLA credits after an outage?

Open a billing case in the AWS Support Center within 60 days of the affected billing period (the exact window is in the ECS SLA itself). The case needs: the affected resource IDs, timestamps of the disruption in UTC, your monitoring evidence (CloudWatch metrics, error logs, or third-party uptime monitoring) cross-referenced against the AWS Health Dashboard, and your calculation of the Monthly Uptime Percentage. AWS reviews the case manually and applies any granted credit to your next invoice rather than refunding cash. Teams that file these regularly automate the evidence-gathering step because it's the most error-prone — a claim missing the wrong field gets denied and has to be refiled.

What exclusions apply to the AWS ECS SLA?

The 99.99% Multi-AZ commitment specifically requires that you run tasks across at least two Availability Zones — single-AZ services that fail when an AZ degrades only qualify under the lower 99.5% Task-Level tier.

Why is it difficult to get refunds for ECS outages manually?

Compute outages rarely show up cleanly. An ECS workload might be partially degraded — some instances fail, others stay healthy — and the SLA only counts the portion of capacity that was actually unavailable. To prove a claim you need per-instance (or per-task) error-rate data, not just an aggregate dashboard. Most teams discover this only when their first credit request comes back denied for "insufficient evidence."

Related AWS SLA guides

Other AWS services that share the same claim window and Support Center workflow:

• AWS EC2 SLA credits — Compute
• AWS Lambda SLA credits — Compute
• AWS EKS SLA credits — Compute
• AWS S3 SLA credits — Storage

Stop leaving AWS credits unclaimed

The hardest part of recovering ECS credits isn't the SLA — it's the lag between an outage and the moment somebody on your team has the bandwidth to file the case. By the time the FinOps team gets around to it, the evidence has rolled out of CloudWatch and the billing window is closing.

Next Signal watches AWS Health and your own observability data, detects ECS SLA breaches in real time, assembles the evidence package the way AWS expects it, and files the billing case for you. See how it works or start a free trial.