Every Cloud VM Has Two SLAs: Region-Level vs Instance-Level Claims

September 19, 2026

A single cloud VM carries two different uptime promises, and the deployment shape, not the outage, decides which one you claim under. AWS publishes a Region-Level SLA at 99.99% next to an Instance-Level SLA at 99.5%. Microsoft pays on a range that starts at 99.99% for two or more VMs across availability zones and slides to 99.5% or 95% for a lone instance, depending on its disks. Google commits to 99.99% only for instances spread across zones. DigitalOcean went the other way: one 99.99% promise per Droplet and a flat 100% credit the moment it slips. The same 45-minute failure on the same $2,000 monthly bill can pay $0, $20 or $200 depending on which cell of the table your workload sits in.

The commitments, by provider and deployment shape

Every VM in the big four sits in one of these buckets, and the bucket is the promise a claims reviewer will measure against:

Some of these rows surprise people. On Azure, a single VM's promise is set by disk type: move the OS disk from premium SSD to standard HDD and the commitment falls from 99.9% to 95%, and a VM with mixed disk types takes the lowest of the set. On AWS, the single-instance promise stays 99.5% whatever the instance costs per hour, which allows more than three and a half hours of lost connectivity in a 30-day month before the first dollar is owed. Google starts single instances at 99.9%, and runs its Mexico and Stockholm regions one notch lower across the board.

What counts as unavailable

None of the four count your application's downtime. They count minutes of lost connectivity, and the definitions decide more claims than the headline numbers.

• AWS measures external connectivity. The Region-Level clock only runs when every running instance across your two or more AZs has no connectivity at the same time. One dead instance in an otherwise healthy region earns nothing at that level.
• Microsoft measures Virtual Machine Connectivity: bi-directional TCP or UDP traffic the VM is configured to allow, whether over the virtual network or a public IP.
• Google counts loss of external connectivity or loss of persistent disk access. Intermittent downtime under a minute never counts, and repeated identical failing requests without backoff can void the error record the claim depends on.
• DigitalOcean counts loss of connectivity over the Droplet's public, reserved or private IP, or loss of read and write access to its root disk.

Read together, these definitions explain why two teams can live through the same incident and only one of them holds a valid claim.

A VM carries both promises, but you file under exactly one of them for a given instance and incident. AWS forbids stacking Region-Level and Instance-Level claims. Google's Compute SLA puts it plainly: a VM is claimed either as a single instance or as instances in multiple zones, never both. Azure requires choosing one service level per incident. The architecture chosen at provisioning time is the promise you claim under, whether or not anyone remembers choosing it.

What a breach pays

The credit schedules track each commitment, and the first tier of each is where most of the real money sits.

The 100% tier on the big three demands a catastrophe: below 95% means more than 36 hours of downtime in a 30-day month. Two schedules bend lower still. Google's single instances pay their 10% from below 99.9% (99.95% for memory optimized), 25% below 95%, and their top tier below 90%. Azure's standard-disk singles stretch the ladder the furthest: the 95% HDD promise pays 10% below 95%, 25% below 92% and 100% below 90%. DigitalOcean skips the ladder entirely, and as of its June 2025 SLA, any miss below 99.99% pays 100% of the affected Droplet's charges for the cycle.

Money math: one outage, four answers

Take $2,000 a month of compute in the affected region, a 30-day month of 43,200 minutes, and a 45-minute incident. The month lands at 99.896%.

The AWS zero in the middle row is the shape of the whole post. A single instance on AWS carries a 99.5% promise, and 45 minutes down is 99.896% of the month, well above it. The same 45 minutes lands below Azure's 99.9% single-VM promise and Google's 99.9% single-instance promise, so both pay. If that lone Azure VM sits on standard SSD, its promise drops to 99.5% and Azure joins AWS at zero. One small consolation on the AWS side: the Compute SLA refuses to charge any clock hour in which a single instance was unavailable for more than six minutes. The credit arrives automatically, no claim needed, and on a $200 a month instance it is worth pennies, but it does arrive.

Filing the claim

Each provider routes compute claims through its standard support channel with its own deadline:

All four evidence packs share a spine: timestamps in a stated timezone, the provider's own incident record, your resource identifiers, and logs proving the loss of connectivity. The claim evidence guide covers what each reviewer actually accepts.

Here is the audit worth running before the next outage. List every VM in the estate and write next to it which promise covers it today: spread across zones or standing alone, in an availability set or not, and on Azure, what its disks earn it. That single column is the difference between $0, $20 and $200 for the same 45 minutes, and no provider will fill it in for you. It is also the mapping UptimeAudit automates when it drafts claims against the big four's health feeds, for teams who would rather not re-derive the table mid-incident.