What is a serverless SLA worth?

The pitch says the platform handles availability. The SLA, read closely, says something narrower, and the gap between the two sentences is where production estimates go wrong. We have asked how many nines you need; this briefing is the other half of that arithmetic, reading what the platform's documents actually supply.

Start with what an SLA is: a refund schedule, not a reliability promise. AWS's compute commitments, like every provider's, define a monthly uptime percentage below which you receive service credits. Three properties follow that change the engineering math. The remedy is capped at what you paid the provider, while your outage costs are priced in your revenue, so the SLA transfers almost none of your actual risk. The measurement is monthly and per-service, so a brutal forty-minute regional event can leave every SLA intact. And the definition of "unavailable" is the provider's, written carefully, which is why incidents that felt like outages to your customers often do not qualify as one to the meter.

So the title's question decomposes, as our questions usually do. What would have to be true for your workload to see the composite availability you told the business?

First, multiply the chain. A request through a gateway, a function, a queue and a database traverses four commitments, and availability composes by multiplication: four services at 99.95 are not 99.95 together; the arithmetic lands near 99.8, which is a different number of annual hours than anyone promised upstairs. The published figures are per-service. Your users experience the product of them.

Second, separate the control plane from the data plane. Serverless platforms are strongest exactly where the marketing says: running what is already deployed. Their historical soft spot is control-plane operations, deploys, scaling decisions, configuration reads, and incidents in that layer produce a system that is "up" by the SLA's lights and unable to scale into a traffic spike by yours. A review asks which of your steady-state paths secretly touch the control plane; the common surprise is cold starts reading configuration at invocation time.

Third, price the tail you cannot engineer around. What the platform genuinely removes is a class of failure you used to own (hosts, patching, capacity); what it adds is a smaller class you cannot touch: when the platform's shared layer has a bad day, your architecture has no vote, as June 2025 demonstrated at industry scale. The honest accounting sets the removed class against the added one; for most workloads the trade is favorable, and the review's job is naming the workloads where it is not, usually the ones whose outage minutes are priced in four figures each.

The recommendation, sized to a page: compute the multiplied SLA for your top three request paths and file it next to the number the business believes. Where the gap embarrasses, either add the engineering (multi-region for the one path that earns it, degraded modes for the rest) or correct the belief, which is cheaper and more often right. Nines are bought, path by path, or they are assumed. The SLA page was never selling them. It was selling credits, and it says so, in the only paragraph nobody quotes.