This content is part of the Essential Guide: Breaking down what's in your cloud SLA
Problem solve Get help with specific problems with your technologies, process and projects.

Defining the right cloud SLA requirements up front

Before signing on the dotted line for cloud services, scrutinize your SLA for unsavory terms. Be wary of these SLA gotchas.

Cloud services are moving into the mainstream. They offer elastic IT infrastructure that can respond quickly to new demands, such as business growth or new projects. Cloud models also offer possible cost savings through pay-per-use approaches and economies of scale. But to save money with a cloud model, IT pros have to construct SLAs carefully.

Businesses rely on service-level agreements (SLAs) to hold cloud providers accountable for services and to establish a set recourse if a service fails. SLAs specify, for example, the responsibilities of providers, such as the time frame in which a vendor should be able to address a problem and the reparations it should make if downtime occurs and a customer loses business.

When it comes to cloud SLAs, the devil is in the details.

But, when it comes to cloud SLAs, the devil is in the details. Outlining the terms of customer reimbursement can be problematic, for example. Should customers be reimbursed for lost services, or is it sufficient for an SLA to stipulate a future credit? Not surprisingly, creating solid, realistic SLAs on which both parties can agree can be complex. As a result, companies are understandably gun-shy about the fine print of these agreements.

For companies eager to try cloud services, it’s prudent to consider potential gotchas, including pricing, provider responsibility, availability, data security, customer rights, risks and penalties in choosing a cloud service provider.

Prepare for a cloud SLA
Before you can sign on the dotted line, you have to identify certain business requirements. You can’t specify the time it should take a cloud provider to get back up and running following a disaster until you determine your maximum downtime tolerance and the potential business loss for your company. That means running the scenarios and the numbers.

First, identify business-critical needs for data and applications in a cloud environment. This requires establishing key performance indicators -- or KPIs -- that are unique to your company’s business requirements, such as:

  • acceptable latency levels,
  • the measured impact of downtime or lost data,
  • the need for constant access to business data (current or archived), and
  • a cloud service usage pattern.

If a business needs a cloud service to have peak transaction load at certain times of the month, quarter or year, reviewing a provider’s SLA for monthly average latency figures is not a good enough indicator of how your business latency needs will be met. It’s also important to understand business requirements -- the legal, compliance, regulatory or other business-critical obligations -- to which a company must adhere. These factors can involve data locality, data set size, access speed or time taken to access archived/backed-up data.

While you might expect otherwise, in the event of failure, the onus is often not on the provider. It can be up to the customer to identify a service failure and its impact.

Considerations may also include disaster recovery, availability guarantees, privacy, hard deletion and encryption, and capabilities for monitoring, managing and auditing cloud SLAs. As an example, your business may require data to be physically stored within the geographical limits of your country for legal or compliance reasons, but your service provider is a global entity with data centers spread among different countries for economic advantage. In this case, you need to ensure that the provider SLA addresses your data locality needs but also provides requisite data-access audits.

Provider practices are another consideration. A prospective cloud provider should be able to demonstrate certain best practices to ensure compliance. As a neutral third party, it should be able to provide evidence of separation of duties and a chain of custody for critical business information to support consistency for compliance.

In outsourced or co-sourced cloud environments, evaluating service-level agreements involves a clear understanding of the implications of an SLA conflict or breach as well as the resolution process. Typical off-the-shelf cloud SLAs may not be sufficient for enterprise customers with business-critical data requirements.

Set cloud provider and consumer responsibilities
After you evaluate your business requirements, consider those needs in light of cloud services provider responsibilities. In the event of an outage or problem, how are responsibilities shared between your company and a provider? What is the provider’s level of transparency, and does it proactively inform consumers of SLA noncompliance and breaches? In the event of a disaster, does the language limit the provider’s liability at the expense of your company’s data? What types of restitution does the provider offer in the face of disaster?

The answer to these questions may be surprising. While you might expect otherwise, in the event of failure, the onus is often not on the provider. It can be up to the customer to identify a service failure and its impact.

Cloud service monitoring and management could result in additional tasks and costs for a company, unless it already has SLA noncompliance identification automation in its on-premises or private cloud setup that can be easily extended for a hybrid cloud. Companies also need to assess noncompliance penalties and determine whether those reasonably cover lost business opportunities.

About the author:
Larry Carvalho runs Robust Cloud LLC, an advisory services company that helps organizations develop strategies to take advantage of cloud computing.

Dig Deeper on Cloud computing SLAs