How to Recover Credits from AWS: The Complete Playbook

AWS gives money back through three separate doors. Most companies knock on none of them. This playbook walks each one - what it pays, who qualifies, and the exact claim mechanics.

Credit types

SLA service credits. Every major AWS service publishes an SLA with tiered credits. When measured monthly uptime falls below the commitment, you are contractually owed a percentage of that service's monthly charges - from 10% for a mild breach to 100% for a severe one. The catch: credits are claim-only. AWS never applies them automatically - and independent CloudDowntime research finds 68% of major cloud incidents breach an SLA while most of those credits go unclaimed.

Promotional and startup credits. AWS Activate funds early-stage companies with usage credits: the self-serve Founders tier (up to $1,000) and the Portfolio tier for startups affiliated with an Activate Provider - accelerators, incubators, and VC funds - worth up to $100,000. Separate programs exist for specific workloads (AWS promotional credits for research, proof-of-concepts negotiated with your account team).

Billing-error recovery. Not a program - a practice. Invoice audits routinely surface 1–3% of annual spend in recoverable or stoppable charges: idle resources, duplicate subscriptions, misapplied Savings Plans, and outright metering disputes (which AWS support will investigate and credit when documented).

Eligibility

• SLA credits: any account whose measured uptime for a covered service fell below the target, with evidence. Configuration matters - the EC2 99.99% commitment is region-level; a single-AZ event that only hurt one AZ may not breach it.
• Activate Founders: new-ish AWS accounts, no prior Activate award, self-funded.
• Activate Portfolio: startups in a Provider's portfolio, typically under 10 years old and under ~$100M raised; the award scales with the Provider relationship.
• Billing disputes: any account; AWS support reviews metering disputes case by case.

The claim process, step by step

1. Confirm the breach. Convert downtime to monthly uptime: (43,200 − minutes down) ÷ 43,200 × 100 for a 30-day month. Compare against the service's target. Borderline? Run it through the SLA credit calculator with your spend.
2. Collect evidence immediately. AWS Health Dashboard event IDs, your own availability graphs with timestamps, affected instance/bucket/function IDs per region, and a handful of failed request IDs. Evidence decays - dashboards age out.
3. Open the case in time. AWS Support Center → new case, subject containing "SLA Credit Request," submitted before the end of the second billing cycle after the incident.
4. State the figures like an invoice. The SLA by name, the billing month, measured uptime, the tier it lands in, and the dollar amount requested. Factual tone; it's a contractual entitlement, not a favor.
5. Reconcile. Approved credits appear as a line item on a subsequent invoice, usually within one to two cycles. Verify it, or the approval is worth nothing.

For Activate: apply through the Activate console (Founders) or through your accelerator/VC's Provider link (Portfolio) before the big migration or launch - credits don't apply retroactively to past bills.

Common mistakes

• Claiming the whole bill. Credits apply to the affected service's charges, not the account total. Overclaiming slows everything down.
• Missing the window. The number-one killer. Calendar the claim deadline the day the incident resolves - outage tracking with alerts makes the trigger automatic.
• No resource-level evidence. "us-east-1 was down" isn't proof your workloads were.
• Burning Activate credits on unoptimized architecture. Credits expire; rightsizing first effectively doubles them.
• Treating billing recovery as one-time. The leaks recur. Schedule the audit quarterly or automate the watching.