Cloud SLAs Explained: What 99.99% Uptime Really Means and How to Claim Credits

A cloud provider's uptime promise is easy to read and easy to misread. "99.99%" sounds close to perfect, yet it still allows about four minutes of downtime in a 30-day month, and the money you get back when that promise is broken is usually a small credit against future bills, not a refund. For teams running AI features on Amazon EC2, Google Compute Engine or Amazon Bedrock, knowing exactly what the service level agreement (SLA) covers is the difference between planning for real resilience and assuming the contract will protect you.

This guide explains how to turn uptime percentages into minutes, what "unavailable" actually means in the main compute and AI SLAs, how credits are calculated, and the paperwork you need to claim them.

Key facts at a glance

Who this is for

This is for engineering leads, platform teams and small companies that run production workloads, including AI inference, on a public cloud and need to set realistic uptime targets, answer a customer's "what is your SLA?" question, or decide whether an outage is worth filing a claim for. It is not legal advice. Your own contract can override the public terms, so check what you actually signed.

Step 1: Convert the percentage into minutes

Uptime percentages hide how much downtime they allow. A 30-day month has 43,200 minutes, so the math is simple:

Two points follow from this table. First, a single virtual machine is promised far less than a multi-zone deployment. On EC2, one instance carries a 99.5% commitment, which allows several hours of downtime a month before any credit is due. Second, the higher tiers only apply if you architect for them. AWS's 99.99% region-level promise applies only when all your running instances are deployed across two or more Availability Zones in the same region. Google's 99.99% figure applies to "Instances in Multiple Zones," meaning instances placed across two or more zones in a region.

Step 2: Read the definition of "unavailable"

The headline number matters less than the definition behind it, because that definition decides whether your outage counts.

Amazon EC2. For a single instance, "unavailable" means the instance has no external connectivity. For the region-level commitment, it means all of your running instances across two or more zones have no external connectivity at the same time. If one zone fails and your instances in another zone stay reachable, the region-level SLA has not been breached, even if your application had problems.

Google Compute Engine. Downtime means loss of external connectivity or persistent disk access for a single instance or, for multi-zone deployments, for all applicable running instances. A "Downtime Period" has to last at least one full consecutive minute. Partial minutes and intermittent drops of less than a minute do not count.

Amazon Bedrock. The AI service is measured differently. Availability is calculated for each 5-minute interval as the percentage of your requests that do not fail with an error, and an "Error" is defined as a request that returns a 500 error code. If you made no requests in an interval, that interval counts as 100% available. The monthly figure is the average of all those intervals. Because the definition is tied to 500 errors, responses such as slowdowns or other error types do not appear to fall under it.

That distinction matters for AI workloads. A model endpoint that is slow, or that rejects traffic for reasons other than a 500 error, may feel down to your users while staying inside the SLA.

Step 3: Understand what a credit is worth

Credits are a percentage of what you paid for the affected service in the affected region for that month, not a percentage of your total cloud bill and not compensation for lost revenue.

For EC2's region-level commitment, uptime below 99.99% but at least 99.0% earns 10%. Below 99.0% but at least 95.0% earns 30%. Below 95.0% earns 100%. The instance-level tiers use the same 10%, 30% and 100% steps, starting below 99.5%. AWS also states that it will not charge for any single EC2 instance that is unavailable for more than six minutes of a clock hour, and that this applies automatically without a request.

For Bedrock, uptime below 99.9% but at least 99.0% earns 10%. Below 99.0% but at least 95.0% earns 25%. Below 95.0% earns 100%.

Some limits apply across these agreements:

• Credits apply to future bills. AWS applies credits only against future payments for the same service and says they do not entitle you to a refund. Google applies its financial credits to future use of the covered service.
• Small credits disappear. AWS issues a credit only if it is greater than one US dollar for the billing cycle.
• Credits are capped. Google's maximum credit in a month will not exceed what you owed for the affected services in the affected regions.
• No stacking. On EC2 you can claim under the region-level or the instance-level SLA for a given instance, not both. Google likewise allows a credit for an instance as either a single instance or part of a multi-zone group, but not both.
• It is the only remedy. Each agreement describes the credit as your sole and exclusive remedy for unavailability, unless your contract says otherwise.

Step 4: Check the exclusions before you file

Every SLA lists situations where downtime does not count. The common ones are factors outside the provider's reasonable control, problems caused by your own software, equipment or configuration, and suspension of your account under the terms.

Bedrock's list is worth reading closely if you run AI features. It excludes problems that result from your own actions, with examples including scaling of provisioned throughput, VPC configurations or credential settings, and disabling or making encryption keys inaccessible. It also excludes problems from not following the documented guidelines and best practices, and issues caused by underlying software that leads to repeated model crashes or an inoperable model.

Google excludes features that are pre-general availability unless the documentation says otherwise, and errors that resulted from quotas applied by the system. If your outage was really a quota limit, it is unlikely to qualify.

Step 5: File the claim correctly

Providers do not pay these credits automatically, apart from the EC2 per-hour billing rule above. You have to ask, on time, with evidence.

For EC2, open a case in the AWS Support Center by the end of the second billing cycle after the incident. A region-level claim needs the subject line "Amazon Compute SLA Credit Request – Region-Level Claim," the dates, times and affected region of each incident, the EC2 resource IDs, and request logs that document the errors. An instance-level claim uses "Amazon Compute SLA Credit Request – Instance-Level Claim" and also needs the affected Availability Zone. AWS asks you to replace confidential information in logs with asterisks.

For Bedrock, the subject line is "SLA Credit Request," and the claim must include the billing cycle, the regions, the monthly uptime percentage, and the dates, times and availability for each 5-minute interval that was below 100%, plus request logs.

For Compute Engine, notify Google technical support within 60 days of becoming eligible and provide log files showing the downtime periods with their dates and times. Google says that if you do not meet these requirements, you forfeit the credit.

The practical lesson is to log request outcomes yourself. If you do not record timestamps and error codes at the client side, you will struggle to prove an outage, especially for Bedrock, where the claim is built from 5-minute intervals.

How to apply this to your own uptime target

A provider SLA is a floor for one component, not a promise about your product. If your application depends on several services in a chain, their availabilities multiply. Two dependencies that each deliver 99.9% give you roughly 99.8% combined if a failure in either one takes you down, which is closer to 90 minutes of possible downtime a month than 43.

A few habits help:

1. List every dependency in the request path, including the model API, the database and the load balancer, and write down each one's published commitment.
2. Match architecture to the tier you rely on. If you quote 99.99%, make sure you actually run across multiple zones, because single-instance terms are much weaker.
3. Track your own availability with client-side logs of status codes and latency, so you see degradation that the provider's definition does not count.
4. Keep a fallback for AI calls, such as a second region or a second model provider, if an outage of a few hours would seriously hurt users.
5. Promise customers less than your providers promise you, leaving room for your own bugs and deploys.

Takeaways

• Convert percentages into minutes before you rely on them: 99.9% still allows about 43 minutes of downtime in a 30-day month.
• The strongest commitments require multi-zone deployments. Single machines get noticeably weaker terms.
• Read the definition of "unavailable." Bedrock counts failed requests that return 500 errors in 5-minute intervals, and Compute Engine ignores drops shorter than a minute.
• Credits are a share of the affected service's bill, apply to future usage, and are the only remedy unless your contract says otherwise.
• Claims need logs and have deadlines, from 60 days on Google to the end of the second billing cycle on AWS, so record the evidence as the outage happens.