AWS CloudFront SLA Credits & Refunds Guide
How the AWS CloudFront SLA works: uptime tiers, exclusions, claim windows, and how to recover the credits you're owed when CloudFront goes down.
AWS CloudFront SLA Credits & Refunds
The CloudFront SLA is one of the more nuanced commitments AWS publishes, partly because networking services have multiple availability tiers depending on how you deploy them. This guide breaks down which CloudFront configurations qualify for credits, the calculation method AWS uses, and the operational data you'll need to win a claim.
What this guide covers
- The official AWS CloudFront uptime commitment and credit tiers
- Which incidents qualify (and which exclusions silently disqualify claims)
- How to file a CloudFront credit request inside the AWS claim window
- Why manual claim recovery typically leaves money on the table
Frequently asked questions about AWS CloudFront SLAs
What is the typical SLA uptime guarantee for AWS CloudFront?
AWS commits to a 99.9% Monthly Uptime Percentage for CloudFront. Service credits kick in below that threshold at 10% (99.0-99.9%), 25% (95.0-99.0%), and 100% (below 95.0%), measured against your CloudFront charges for the affected billing cycle.
How do I claim AWS CloudFront 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 CloudFront 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 CloudFront SLA?
CloudFront specifically excludes errors caused by your origin being unreachable — a 5xx response triggered by an unhealthy origin server you operate counts as your downtime, not CloudFront's.
Why is it difficult to get refunds for CloudFront outages manually?
Networking incidents are the easiest to misclassify. A CloudFront disruption might really be a DNS resolution issue, an upstream peering problem, or a TLS certificate failure — and the SLA only covers what the provider's own infrastructure caused. Distinguishing a true CloudFront outage from a downstream symptom requires correlated telemetry across multiple layers, which is exactly the data manual claim filers tend to miss.
Related AWS SLA guides
Other AWS services that share the same claim window and Support Center workflow:
- AWS VPC SLA credits — Networking
- AWS Route 53 SLA credits — Networking
- AWS EC2 SLA credits — Compute
- AWS S3 SLA credits — Storage
Stop leaving AWS credits unclaimed
The hardest part of recovering CloudFront 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 CloudFront 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.
Related SLA guides
Other AWS services with their own SLA credit recovery process.