One of the best general definitions of SLA comes from Marilly, Martinot and Betgé-Brezetz (2002, p.57-62), “A Service Level Agreement (SLA) is a contract between Service Providers or between Service Providers and Customers that specifies, usually in measurable terms, what services the Service Provider will furnish and what penalties the Service pay if he cannot meet the committed goals.”. The similar definition applies to cloud providers. In essence, the SLA describes a contract between the vendor that delivers a cloud service and the company which is receiving it. That said, I see some differences between the traditional IT level SLA and those created by cloud providers. While in the depth of the covered obligations, the cloud service level agreements appear to be similar to typical IT SLA, the cloud landscape is certainly more complex, which also alters the nature of cloud SLAs and their presentation to end client. Let me explain.
The IT enterprise in contract with an external provider is traditionally accustomed to coping with a single overarching SLA. However, this practice is somewhat hard to accomplish in the cloud. To illustrate, according to Amazon Web Services (2017), the AWS service offers well over 90 different cloud services. The sheer diversity/complexity of cloud services provided by a single provider pushed many providers away from the standard practice of providing a single SLA document. As a matter of fact, most cloud providers moved to a convoluted practice of defining an explicit SLA for each of the cloud services, with each offering often quite dissimilar definitions of availability, performance, and security. Sometimes, such as in the case of Microsoft Azure or Amazon AWS, there are multiple SLAs for what is essentially the same service. As an example, Amazon cloud storage comes in four SLA flavors: “Standard, Infrequent Standard, Reduced Redundancy and Glacier.” (Cloudyn.com, 2017).
The bottom line being, that the end client must often consider more than a single service level agreement, even though all required cloud services may pertain to a sole cloud provider.
Importance of Cloud SLA Analysis
In my view, even though the actual service availability, security and performance and various levels of refunds, are all undeniably playing a significant role in the cloud provider’s SLA, I think they actually seldom matter. As a decade-long user of various cloud services, I realized that the refunds provided for hours of downtime (in any of the measured areas) rarely cover the loss of business.
In my opinion, a single primary point of any SLA should be a precise definition of circumstances under which the level of service promised does (service commitment) and does not (exclusions) apply. It is primarily because for the end user SLA provides the only legal way out of a long-term contract obligation. Alternatively, in other words, the SLA should guarantee to meet the outlined expectation of the cloud service, so the customer does not get trapped in a long-term contract in a situation when the service does not meet business needs and SLA guarantees.
For example, according to Uptime.is (2017), the SLA level of 97.999 % uptime/availability can be calculated as 7 days, 7 hours and 24 minutes of a potential downtime/unavailability. The above calculation truly points to an importance of SLA analysis, because building a product, or an entire business on a possibility of over 7 days of complete downtime could be a disaster in waiting, especially if SLA does not offer a way out of the long-term contract.
Cloud Provider SLA Evaluation (Compute Service)
As I hinted earlier, due to many different SLAs (storage, compute, etc.), it is not a simple task to compare service level agreements of various cloud providers. Thus, in the following evaluation, I concentrate on a single compute service, in which I compare Amazon EC2 and Microsoft Azure Compute service SLA side by side (Figure 1).
Figure 1 – © Jozef Jarosciak
Marilly, E., Martinot, O., Betgé-Brezetz, S. (2002). Requirements for service level agreement management. In IP Operations and Management, 2002 IEEE Workshop on (pp. 57-62). IEEE.
Techdonut.co.uk. (2017). Sample service level agreement. [online] Available at: http://www.techdonut.co.uk/it-support/it-support-contracts/sample-service-level-agreement [Accessed 18 Jun. 2017].
Amazon Web Services, Inc. (2017). Cloud Products & Services – Amazon Web Services (AWS). [online] Available at: https://aws.amazon.com/products/?hp=tile&so-exp=below [Accessed 18 Jun. 2017].
Uptime.is. (2017). SLA & Uptime calculator: How much downtime corresponds to 99.9 % uptime. [online] Available at: https://uptime.is/ [Accessed 18 Jun. 2017].
Cloudyn.com. (2017). [online] Available at: https://www.cloudyn.com/wp-content/uploads/2016/05/AWS-GCP-Azure-May-2016-final.pdf [Accessed 18 Jun. 2017].
Amazon Web Services, Inc. (2017). Amazon EC2 SLA. [online] Available at: https://aws.amazon.com/ec2/sla/ [Accessed 18 Jun. 2017].
Azure.microsoft.com. (2017). SLA for Virtual Machines. [online] Available at: https://azure.microsoft.com/en-us/support/legal/sla/virtual-machines/v1_0/ [Accessed 18 Jun. 2017].
Paloaltonetworks.com. (2017). What is a Service Level Agreement? | Palo Alto Networks – Palo Alto Networks. [online] Available at: https://www.paloaltonetworks.com/cyberpedia/what-is-a-service-level-agreement-sla [Accessed 18 Jun. 2017].