Cloud Computing and Service Level Agreements (SLAs)

A service level agreement (SLA) is a technical services performance contract. SLAs can be internal between an in-house IT team and end-users, or can be external between IT and service providers such as cloud computing vendors. Formal and detailed SLAs are particularly important with cloud computing providers, since these infrastructures are large scale and can seriously impact customer businesses should something go awry. In the case of cloud computing, SLAs differ depending on a specific provider’s set of services and customer business needs. However, all SLAs should at a minimum cover cloud performance speed and responsiveness, application availability and uptime, data durability, support agreements, and exits. A carefully crafted SLA is an essential element in effective monitoring of cloud governance and compliance.

Cloud Computing SLA Basics

Customers will provide their key performance indicators (KPI), and customer and provider will negotiate related service level objectives (SLO). Automated policies enforce processes to meet the SLOs, and issues alerts and reports when an agreed-upon action fails. Cloud computing providers will usually have standard SLAs. IT should review them along with their legal counsel. If the SLAs are acceptable as is, sign it and you’re done. However, companies at any stage of cloud adoption will likely want to negotiate specific requirements into their SLAs, as the vendor SLA will be in favor of the provider. (For help choosing the cloud company that suits your business needs, read our comprehensive guide to cloud computing.) Be especially careful about general statements in the standard SLA, such as stating the cloud’s maximum amount of customer computing resources, but not mentioning how many resources are already allocated. Not every cloud computing provider will automatically agree to your requirements, but most customers can make good-faith negotiated agreements with providers. Quality of service depends on knowing what you need and how they will provide it.

This example of a cloud computing SLA details numerous technical details of the cloud agreement.

Cloud Computing SLA Specifics

A service level agreement is not the time for general statements. Assign specific and measurable metrics in each area, which allows both you and the provider to benchmark quality of service. SLAs should also include remediation for failing agreements, not only from the cloud provider but from the customers as well if they fail to keep up their end of the bargain. Cloud computing users should specifically review these items in a cloud computing SLA:

• Availability and uptime. These are not precisely the same thing. A computing service may be up, but a customer may not be able to access an application. Specify that not only must the cloud service be up a certain percentage of time (and/or or within specific time periods), but your applications and data must be available within these same percentages. Common examples include 99.99% during work days and 99.9% for nights and weekends. However, if you run an ecommerce site and/or work 24x7x365, you may have higher expectations. Disaster Recovery options are also important to uptime and availability. If you invest in the provider’s failover services, include agreements over spin-up time and speed of recovery.
• Performance. Application response time is critically important, so make agreements on metrics like services volume, different demands at different times, quality of service, average workloads, and peak times. Also remember that you have responsibilities as well. For example, if you added 500 new users to a cloud application, the service provider has the right to push back against the original performance baseline.
• Network changes. No customer wants to hear about “planned downtime,” and cloud providers dynamically scale their equipment. However, things go wrong and you can request that the provider informs you of major upgrades or changes.
• Support agreements. Cloud computing providers have 24×7 support in place but don’t make assumptions about the quality of the help center. Corporate IT calling with a problem is at an entirely different level than a new computer user who doesn’t understand how to sync their files. Must you both start with 1st level support? Or can you negotiate a dedicated team for your company?
• Measurements. Set specific performance measurements based on baselines. Don’t leave your important metrics like application response time to chance, but don’t measure essentially useless information either. Agree on the scope and frequency of performance and availability reports. Many companies will also want regular compliance and audit reports.
• Security and privacy. The data owner – your company – is ultimately responsible for data loss or theft, so know how your provider handles your data security and privacy. Strong user authentication is critical as is data encryption, anti-virus/malware, and patching. The cloud provider should also have active intrusion detection and InfoSec teams who know how to run it. Privacy is also important. If you are based in the U.S. with a remote location in France, check with your provider to see if they can geo-locate specific data sets to comply with national privacy laws. Write cloud service level agreements around those capabilities.
• Exit strategy. Include agreements on dispute mediation and escalation and maintain an exit strategy that includes a smooth transition to another cloud provider. The last thing you want is for a cloud provider to hold your data even when you’ve fulfilled your contractual obligations.

Service credits are the most common way for a cloud computing provider to reimburse a customer because the provider failed an agreement. The reason for the failure is an issue, since the provider will rarely issue credits if the failure was out of their control. Terrorist acts and natural disasters are common exclusions. Of course, the more data centers that a service provider has, and the more redundant your data is, the less likely that a tornado will affect your data.

When to Upgrade Your SLA

Your computing needs are not static, and your SLA shouldn’t be either. Your needs and the provider’s capabilities will change over time. Your provider will periodically revisit their standard and custom SLAs considering new procedures and technologies. You should do the same. Periodically review your SLAs, especially when there are changes to your business needs, technology, workloads, and measurements. Also review your SLAs when your cloud computing provider announces new services. You won’t take advantage of every offer that comes down the pike. But if a new service will improve your customer experience, then adopt it and modify the service level agreements to reflect the new product.

Benefits of the SLA

• Protects both parties. When internal IT deploys a new application, they work closely with end users to make sure everything is working. They track application success by emails and phone calls, and if there is a problem they get on the phone with the vendor to solve it. However, it doesn’t work like that with a business customer and their cloud provider. An SLA details expectations and reporting, so the customer knows exactly what to expect and what everyone’s responsibilities are.
• Guarantees service level objectives. The cloud provider agrees to the customer’s SLOs and can prove it reached them. If there is a problem, then there is a clear response and solution mechanism. This also protects the provider. If a customer saved money by agreeing to a 48-hour data recovery window for some of their applications, then the provider is entirely within its rights if it takes 47 hours.
• Quality of service. The customer does not have to guess or assume levels of service. They get frequent reports on the metrics that are meaningful to them. And if the cloud computing provider fails an agreement, then the customer has recourse via negotiated penalties. Although these penalties will not necessarily replace lost revenue, they can be excellent motivators when the cloud computing provider is paying $3,000 a day while a service is down.

SLAs are a critical part of any service offering to an internal or external client, and are particularly important between a business and its cloud computing provider. Don’t let the cloud SLA be a battleground of assumptions and mistaken expectations. Negotiate and clarify agreements with your provider. Be reasonable without being blindly trusting, and the SLA will protect both of your businesses as it is meant to do.