Cloud vendor SLAs are one of the most cited and least read documents in enterprise IT. AWS, Azure, and GCP all publish service level agreements that promise uptime figures like 99.9% or 99.99%, and procurement teams routinely treat those numbers as settled fact. The reality is more complicated. What counts as "downtime," how credits are calculated, and which failure scenarios are excluded can vary dramatically between providers and between individual services within the same provider.
What "availability" actually means in a cloud SLA
The first thing to understand is that cloud SLAs do not guarantee your workload stays up. They guarantee that the service endpoint remains reachable from outside the provider's network, according to the provider's own monitoring. Those two things are not the same.
Take AWS EC2 as an example. The AWS Compute SLA defines availability as the percentage of minutes in a monthly billing cycle when a region is accessible. But it applies per region. If your application runs in a single Availability Zone and that zone has a partial outage, you may experience degraded performance or failed requests without the provider technically breaching the SLA at all. The SLA covers the region. Your architecture is your problem.
Azure and GCP take similar approaches. Azure's compute SLA measures connectivity to virtual machines, not application-level correctness. GCP's SLAs are service-specific and calculated monthly. In all three cases, the provider is measuring something narrower than what most engineering teams assume when they quote the number to a stakeholder.
The exclusions that swallow the guarantee
Every cloud SLA contains an exclusions section. This is where the document does most of its real work, and where Australian IT teams are most likely to be caught off-guard.
Common exclusions across AWS, Azure, and GCP include:
- Outages caused by customer configuration errors, including security group rules, IAM policies, and misconfigured load balancers.
- Force majeure events, which providers define broadly enough to cover most large-scale infrastructure incidents.
- Scheduled maintenance windows, even when those windows are announced with short notice.
- Failures caused by third-party services, including external DNS providers or CDN vendors not owned by the cloud provider.
- Issues resulting from exceeding published service quotas.
The configuration error exclusion deserves attention. Cloud IAM misconfigurations are among the most common causes of access failures across Australian deployments, and most of those failures fall squarely within the exclusions clause. The outage is real, the business impact is real, and the SLA credit is zero.
How SLA credits work and why they're rarely worth much
When a provider does breach an SLA, the remedy is a service credit, not a refund of consequential losses. This is a critical distinction for any organisation that relies on a cloud workload for revenue-generating services.
Credits are typically calculated as a percentage of the monthly bill for the affected service. AWS and Azure both apply a tiered structure: a minor breach might trigger a 10% credit, while severe breaches can reach 100% of that month's spend on the specific service. GCP follows a similar model. The catch is that "100% credit" on a $500-per-month compute bill is $500. If an outage cost your business $50,000 in lost transactions, the credit is cosmetic.
Australian businesses dealing with this gap sometimes assume their standard commercial contracts with providers offer additional remedies. Most hyperscaler agreements explicitly cap liability at the credit value and exclude consequential loss entirely. Cloud providers negotiate from a position of significant power, and the standard terms reflect that. Negotiated enterprise agreements sometimes contain better terms, but only if the procurement team explicitly pushed for them.
What Australian IT teams should do differently
Reading the SLA is the starting point, not the endpoint. The more important question is whether your architecture actually achieves the availability your business requires, independent of what the SLA says.
A 99.9% uptime SLA permits roughly 8.7 hours of downtime per year. A 99.99% SLA permits about 52 minutes. Whether those figures are acceptable depends entirely on the workload. For some internal tools, 8.7 hours per year is fine. For a payment processing service or a patient-facing health application, even 52 minutes carries serious consequences. The SLA number does not tell you whether your architecture is adequate. It tells you the minimum standard the provider has committed to for its own infrastructure layer.
Multi-region deployments are the most reliable way to build above the SLA floor. If your workload runs across two regions with proper failover, the effective availability target is determined by your architecture, not the provider's per-region guarantee. The complexity and cost of that approach is real. So is the alternative when a single region has a bad day. Australian teams building a multi-region cloud strategy should treat SLA targets as a floor for each individual service, not a ceiling for what their architecture needs to achieve.
For critical workloads, it's also worth mapping SLA terms to actual incident history. AWS, Azure, and GCP all publish incident post-mortems. Reviewing those for your region and service type gives a more honest picture of failure frequency and duration than the SLA percentage alone.
The Australian regulatory dimension
Australian organisations subject to the Privacy Act, APRA's CPG 234, or sector-specific frameworks face an additional layer of complexity. A provider breach of SLA is one thing. A provider outage that causes a notifiable data breach or a regulatory reporting failure is another. Service credits do not satisfy regulatory obligations, and regulators do not accept "our cloud vendor had an outage" as a complete defence.
APRA-regulated entities in particular are expected to conduct due diligence on cloud providers and maintain documented contingency plans that function independently of the provider's SLA commitments. That means testing failover procedures, maintaining runbooks, and ensuring that critical data can be accessed and processed even when a primary cloud region is unavailable. The APRA CPG 234 guidance on information security is explicit that regulated entities retain full accountability for outcomes, regardless of where the service is hosted.
State and federal government agencies face similar obligations under Australian Government cloud policy, which requires documented risk assessments and continuity plans rather than reliance on provider SLA terms as the primary risk control.
Questions worth asking before you sign
Before locking in a cloud service agreement, Australian IT teams should clarify a few things that standard SLA documents rarely address clearly. Does the SLA cover all service tiers you use, or just specific instance or storage types? How does the provider measure and report availability incidents, and can you access that data independently? What is the process for claiming credits, and are there deadlines for submitting a claim? Is the liability cap negotiable for your contract tier?
Providers rarely volunteer answers to these questions. The standard SLA document is designed to minimise provider liability, not to help customers understand their real exposure. Treating it as a starting point for negotiation rather than a finished agreement produces meaningfully better outcomes for teams that do the work.