Issue 32

Deep dive in clouds providers SLAs

Radu Vunvulea
Solution Architect


In the era of cloud we are bombarded with different cloud services. New features of cloud providers are lunched every day and prices are dropping every month. In this moment the most known cloud providers are Amazon, Google and Microsoft.

Looking over their services we will see SLAs (Service Level Agreement) that reach 99.9% availability, 99.95% availability or even 99.99% availability. This article will jump into cloud providers SLAs, trying to explain why the SLAs are so important, what are the benefits of them and last but not least how much money we could get back if a service goes down.

What does a SLA mean?

"A service level agreement (SLA) is a contract between a service provider (either internal or external) and the end user that defines the level of service expected from the service provider. SLAs are output-based in that their purpose is specifically to define what the customer will receive. SLAs do not define how the service itself is provided or delivered."1

A SLA is a contract between a service provider and the consumer that specify the 'quality' of a service that will be provided to the consumer. For example if we think about a service that gives you the exact time, the SLA will define how much time the service will be up and running in a year (99.99%).

Beside that, the SLA defines the warranties that are provided if the SLA is not reached. For example if the exact time service is down more than 0.01% per month, the service provider will reduce the total cost the bill with 50%.

What areas are covered?

Based on what type of service or business we are talking about, the things that can be covered are different. It is very common for a SLA to cover the following attributes of a service:

Looking again over our example with the exact time service, we could have an SLA that says: "The exact time service is up 99.99% per year, the response time from the moment when a request hit the service is 0.0001 seconds and the time precision is 0.00000001 second."

Cloud SLAs

In general if we are talking about cloud providers and services that are offered by them, the areas that are covered by all of them is the uptime. Beside uptime, there are other areas that are covered, but they vary based on service type.

Microsoft, Google and Amazon have a clear SLA that specify the uptime for each service that is provided by them. Even if they are different companies, the SLAs are very similar to each other.

For example if we are looking at cloud storage service that is not replicated to different datacenters or nodes we will discover that Google is offering a 99.9% uptime SLA, Microsoft is offering a 99.9% uptime SLA, Amazon is offering a 99.95% uptime SLA (with the remark that if we have for use Read Access-Geo Redundant Storage from Microsoft we can reach even 99.99%).

As we could see in the above example, the SLAs are very similar +/-0.05%.

How is the service measured?

This question is very important, because each cloud provider SLA specifies very clearly how, who, when, based on what SLA service is measured.

In all the cases the service uptime is measured internally, by their own system. This doesn't mean that the measure is not real. No, it is very real, but if the cause of the downtime is an external factor like network issues on client side, than it is not their problem - and it is normal.

The SLA is not applicable for cases when the service is used outside specific boundaries. For example the SLA is applicable only when the number of requests per second is under 10 million requests or when there are at least two instances of that deployment.


Very often people assume that if they have a service in cloud that generate 1000\$ per hour, in a case of a downtime, the provider will give them the amount of money that service would generate. Another wrong assumption is that a cloud provider will cover all the lost that are generated by a downtime.

Both assumptions are wrong. In this moment I don't know a cloud provider or a service provider that would cover the loss of a downtime.

It might sound strange, but it is normal. First of all, it is hard to measure and calculate the loss and secondly the SLA is referring to the service that you are using, not the system and services that you are providing over it.

Google, Microsoft and Amazon are offering very similar warranties. Based on the downtime period at the end of the month, a specific amount of service credit is offered to the customer. For example if the uptime of a service was under 99.9%, the customer will receive 25% of that service cost of that specific month as credit. This credit will be used to reduce the bill cost in the next month.

Also the SLAs specify that if a specific incident or event causes a downtime to more than one cloud service, then the client can submit a claim only for one service that was affected by this event.

For example if a datacenter goes down because of the same software update, where storage, computation and messaging systems are affected, than the customer can claim the credit for only one of the services.

Amazon, Google and Microsoft Warranty

Let's take a look at the warranties that are offered by these cloud providers in a case of a downtime of their storage service.




The offer is not 100% the same, but it is pretty similar. Even if Google offers 50% storage credit in the case of a downtime, I don't want to be in the case when the uptime is only 90% for example. The credit that is offered when the uptime is between 99.xx% and 99% is the same. Every '9' that is offered on top of 99% is very expensive and hard to obtain. Those nines are representing the real battle and can make a difference between a service and a great service.

When and how do I receive the credit?

All cloud providers have different mechanisms to notify customers when a service is not working as expected (over a web site, using an API or via email). In all these cases, even if a service is down more than it is specified in SLA, the customer will not receive the credit that we talked about above (by default).

The moment when customers are affected by an incident, they need to notify the cloud provider and open a ticket at customer support level. They need to specify what service was affected and when. Based on this information, the cloud provider will check the internal audit system and the level of error rate at that specific time interval.


This is the key word around cloud providers and their customers. The most important thing is the trust that exists between them. We, the customers, trust our cloud providers that will respect their SLAs. The same thing is happening with any external provider.

In general all the SLAs that are offered by cloud providers are respected. The cases when incidents exist are very rare and isolated.

Cloud service uptime is not our product uptime

An important thing that we need to take into consideration is that when we are constructing a product over cloud the uptime of our system is not the same with the uptime of the cloud services.

For example, if we have a product that is constructed using 20 services from cloud, than the uptime of our system will need to be calculated taking in consideration the uptime of all cloud services. If each of the cloud services has an uptime of 99.9% than the uptime of our system could reach around 98% uptime.


As we have seen above, the SLAs that are offered by different cloud providers are pretty similar. The most important thing is to know exactly what does the SLA cover and how to handle downtime periods.


  1. Amazon EC2 SLA
  2. Google SLA
  3. Microsoft SLA




  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • P3 group
  • Ing Hubs
  • Colors in projects