SLAs in the Cloud

What are SLAs and why are they used?

A key principle of any contract is to establish clear responsibilities in relation to each party within a liability framework, providing legal certainty of recourse in the event of a breach of contract. This is simple to achieve, monitor and enforce where a contract can deal with absolute requirements, such as of confidentiality – it is easy for both parties to know when the contractual requirement has been achieved or failed. The situation is more complex where an absolute requirement is not realistic and a certain amount of failure is expected. This is particularly the case with IT and IT related services where there is an expectation and/or understanding that it will not always “work” flawlessly. This can create a problem with traditional contractual provisions, for example with a requirement for a supplier to provide services to the standard of “reasonable skill and care”. How much “failure” would therefore be permitted in a scenario where a flawless service is not expected before a Supplier has failed to achieve this contractual standard of reasonable skill and care? To avoid this uncertainty and to minimise the requirement of lawyers and courtrooms to come to conclusions on such questions, SLAs are therefore used as an objective contractual measurement mechanism for a particular aspect of a service which allows a clearly defined amount of failure before a breach of contract occurs.

SLAs work by defining a particular service, setting a clear standard by which it will be measured and offering customers a particular remedy in the event of a failure to meet the required standard. SLAs are usually measured over regular and relatively short periods such as a month or quarter. Where an SLA has been failed in a measurement period, the customer will be entitled to a remedy under the contract. The remedy available will vary between SLAs and it often depends on the severity of the SLA failure and will be typically set out within the SLA description. Common remedies include a small price adjustment against future service charges (called a service credit) but can include other remedies such as a termination right to end the contract and (less commonly) the right to sue the supplier for damages to recover losses suffered as a result of the SLA failure.

SLAs within the Cloud
As highlighted above, a certain amount of “failure” may be expected when using cloud services unless a customer is prepared to pay a significant premium for a flawless service with numerous levels of redundancy and contingency. As the vast majority of cloud users do not require this type of service (and the majority of suppliers do not provide this type of service), the key question arises as to how much “failure” is acceptable before the supplier is in breach of its contract? It is therefore vital from the perspective of the customer to ensure that minimum standards and levels for the provision of the services are established and clearly documented through SLAs within the applicable contract. Whilst suppliers of cloud solutions will not always offer SLAs to customers as standard, and only a minority of customers typically request such, the inclusion of SLAs within a cloud contract is likely to also benefit the supplier as the customer’s expectations can be appropriately managed, whilst the effect of a failure in the provision of the services can also be mitigated through the insertion of a service credit regime.

Where suppliers do offer SLAs, these are often set out so as to exclude most causes of a service outage, either expressly within the contract or by qualifying service levels through the use of one or more of the following:
Reasonable endeavours – the effect of setting out that the supplier will use “reasonable endeavours” to achieve certain service levels is that it will be significantly more challenging for the customer to determine, or otherwise prove, when the supplier has failed to achieve such levels. The inclusion of this further qualification means the supplier need only make reasonable efforts to achieve the service level. It follows therefore that if the supplier can demonstrate that it used reasonable efforts to achieve the service level, but did not actually achieve it, this may still be regarded as a successful achievement of the SLA. Customers who are used to the negotiation of IT SLAs will often insist that this qualification be removed. If however the supplier insists on qualifying any service levels with an “endeavours” type commitment, customers will often seek a higher level of commitment being an “all reasonable endeavours” or, if possible, “best endeavours” commitment, each of which constitute higher thresholds of effort for the supplier to have to achieve;
Multiple failures – as service credits are often linked to the occurrence of a service level failure by the supplier, it is important for the customer to understand precisely what constitutes a failure.
The most beneficial definition for the customer is for a single service level failure to entitle such customer to service credits. However, cloud suppliers often attempt to reduce the availability of service credits to the customer by defining a failure for the purpose of providing such service credits as the occurrence of multiple service level failures and/or by setting out minimum duration thresholds which must be surpassed in order to qualify as a failure;
Third parties – cloud services from different providers are increasingly being packaged together to offer innovative cloud solutions. For example, a number of software-as-a-service (SaaS) providers are providing their cloud services running on another cloud provider’s infrastructure-as-a-service offering (e.g. Amazon’s EC2 solution). Cloud suppliers will often seek to exclude service problems caused by other suppliers from the scope of the SLA. The scope of the SLA therefore needs to be checked carefully by the customer to determine whether the SLA covers the aspects of the cloud service as is intended – often cloud SLAs will be narrower in coverage and exclude aspects of the cloud service that may not be immediately apparent; and
Force majeure – commonly in cloud contracts internet service provider (ISP) failures and/or delays are considered to be events of force majeure due to the cloud supplier not having control over the internet infrastructure and communication links over which the cloud services are being provided. Accordingly, as such failure or delay is argued to be outside of the cloud supplier’s reasonable control, cloud SLAs will often exclude the application of SLAs to failures caused by these factors. It is important, however for a Customer to ensure that a distinction is drawn between:
the supplier’s own internet connection, which is under the supplier’s control and therefore should not be a permitted reason for a failure of any service level;
the customer’s internet connection, which is not under the supplier’s control and therefore should be a permitted reason for a failure of any service level; and
the internet infrastructure between both parties’ respective connection, which is under neither party’s control. In this instance, some cloud suppliers are beginning to take responsibility for internet non-availability as part of the provision to customers of end-to-end SLAs (for example, certain Google products), although a majority of suppliers are still reluctant to do so.
Types of cloud SLAs
Within cloud computing, many areas of service have well understood industry-standard service levels. Most commonly, these consist of:
Availability SLAs - availability of a cloud service (ie whether the cloud service is working and is available for use by the customer) is likely to be vital to a customer of cloud services. The “off/on” nature of cloud services means availability SLAs will usually be the most important SLA for a customer. The level of commitment which a supplier will provid often varies between cloud contracts. Cloud services which are provided for free or low cost will not usually provide high availability commitments (or may not offer any at all), however where cloud services are being provided on a larger scale/value, availability commitments are commonly high and usually capable of negotiation. Availability SLAs are usually measured based on a percentage of time during a month that the service is available for use by the customer, and may be broken down into isolated service elements;
Performance SLAs – poor performance of the cloud service may be equally as problematic to a customer as complete non-availability. The level of responsiveness of the cloud service needs to be agreed between the customer and supplier and must be capable of being measured from an objective perspective. Commonly performance is measured by reference to latency (in milliseconds) based on a percentage of time during a month that the service performs to the appropriate level. The location from where performance measurements are taken is also central to ensuring that the service level provided is of any benefit to the customer, as measuring from a location near to service output, such as the data centre from which it is hosted, will not provide a true evaluation of whether the service has breached the applicable levels when it is received by the customer. As with availability SLAs however, cloud services which are provided for free or low cost will not usually provide any performance commitments, however where cloud services are being provided on a larger scale for a higher value, performance SLAs are usually capable of negotiation; and
Support SLAs – Support SLAs are typically offered by suppliers where a customer is purchasing some form of premium or enhanced support service. Support SLAs are used to measure the performance of these premium/enhanced support services and are usually split into two key areas:
Response SLAs – response SLAs measure how rapidly the supplier responds to notifications of faults and errors with cloud services and are often measured in relation to a series of separate events which are completed on time during a performance period, such as the number of calls responded to by the supplier within a certain number of hours over a monthly period; and
Resolution SLAs – resolution SLAs measure how rapidly the supplier resolves a fault with the cloud services following notification of such by the customer, and is also often measured over a monthly period by reference to the number of faults fixed within a certain time period of being notified of such by the customer.
Where premium/enhanced support is not being purchased by a customer, or where support is being provided without extra cost, suppliers will not usually offer Support SLAs.

Service credits for cloud SLAs
As described above, where an SLA has been failed in an SLA measurement period (e.g. over the course of a month), the customer will be entitled to a remedy under the cloud contract. The remedy available will vary between SLAs and it often depends on the severity of the SLA failure and will be typically set out within the SLA description. If an SLA does not mention the remedy, the common law contractual right of damages will apply which may allow the customer to sue the supplier for its damages suffered in connection with the breach of contract (ie the failed SLA). However, the initiation of court action in response to an SLA failure to sue a supplier for damages will likely be entirely disproportional and impractical in comparison to the losses suffered by a customer in response to an SLA failure (if any loss has been suffered at all). In light of this, a pre-agreed remedy for SLA failure in the form of a small price adjustment against future service charges (called a service credit) is often included within cloud contracts as a more practical and realistic remedy to an SLA failure.

Customers should check cloud contracts to determine whether service credits are being provided as a “sole and exclusive” remedy for SLA failure. This means that the provision of a service credit in a response to an SLA failure is to the exclusion of all other rights and remedies including the right to terminate for breach of contract and the right to sue for damages in relation to such failure. The importance of this will vary depending on the nature of the cloud services, and the amount of fees the customer is paying for the cloud services, however this may not be an appropriate position in higher value business critical type deals where a customer may need the right to terminate (and potentially sue for damages) and source an alternative supplier if service is extremely poor. In recognition of this, some cloud service suppliers may accept termination for severe or persistent service level failures, such as where a service outage is significant and prolonged and adapt standard SLAs to accommodate this. The most often discussed area between customers and suppliers in respect of service credits is the financial value of service credits and how these are to be calculated. As with SLAs themselves, the value of service credits are usually linked to the value of monthly or quarterly charges being paid to supplier, typically by way of a percentage of such charges. Service credits are usually subject to an overall maximum limit for a given period which, depending on the value of the cloud services, will typically vary between 5-20% of charges payable in the measurement period.

Conclusion
While the transition to cloud computing may provide a host of benefits to businesses, such as a reduction in overall IT spend and increased flexibility and scalability of IT solutions, the complexities of cloud computing architecture and the interdependence of the multiple parties involved in providing the end-service to the customer increases the risk of a supplier-side failure in the service output. This is a particular concern where IT solutions which are being transferred to the cloud supplier are mission-critical. Customers seeking to mitigate the risk of cloud reliance are either seeking to negotiate SLAs which necessitate bespoke cloud solutions (e.g. private clouds) or alternatively, are only selecting suppliers which offer well-defined SLAs that:
clearly identify the areas of supplier responsibility;
define the levels of acceptable and unacceptable performance; and
create a mechanism for service credit compensation in the event of unacceptable performance.

As the trend of increasing value and complexity of cloud continues, these SLA requirements are becoming ever more important in the cloud contracting landscape.