What to Watch For in Your Cloud SLAsBy John Pavolotsky
Cloud SLAs: Does Your Deal Leave You Exposed?
The potential for cloud service outages raises a basic, but important, question: Would a more stringent SLA have helped your organization avoid problems?
Of course, an SLA can do nothing to prevent an outage caused by a force majeure event, such as Hurricane Isaac. Rather, an SLA is a promise. If a cloud vendor fails to live up to that promise, there are certain, often exclusive, remedies available to the customer, usually in the form of service credits. Sometimes, if negotiated into the SLA, you'll even have right to terminate the cloud services agreements. For example, this right of termination might be applicable if your vendor fails to provide services consistent with those promises over a certain agreed-upon period of time, such as three consecutive months, or four (non-consecutive) months in any six-month period, or six months in any 12-month period.
Many cloud vendors will not offer an SLA. Most will provide one if asked. Some will agree to negotiate the SLA, if only along the edges. No reputable vendor will agree to rip up its SLA and accept one proposed by any one customer. If there will be any changes, they will be financial (e.g., a bigger service credit) and not operational. The vendor will cite administrative reasons why proposed variations will not be accommodated. It will also point to the prospect of reputational damage as a further motivator to provide good service.
Cloud SLAs: Beware The Litany of Exceptions
SLAs are subject to a litany of exceptions, including force majeure. Force majeure events excuse performance failures. As a customer, you'd be able to ask for some modification of the force majeure exception. For example, your SLA can state that force majeure can only be used as an excuse for service failure if the outage could not have been prevented by the vendor taking precautionary measures. These precautionary measures could include having in place a backup generator, or perhaps even a backup to the backup, accompanied by periodic testing of one or both generators. In practice, few vendors would agree to anything so intrusive. If they did, as a customer you would probably wonder about their ability to deliver. Further, SLAs are not really intended to address force majeure, but rather outages due to poor management or technical failures.
Some observers posit that a cloud vendor that offers redundant data centers - in locations not affected by a particular force majeure event -- may alleviate, if not preclude, an outage of cloud services. Perhaps. But keep in mind that cloud providers often make such backup options available only for an additional cost. Redundant data centers mean redundant costs for you.
For some cloud services, especially Infrastructure-as-a-Service (IaaS), such redundancies are particularly attractive to customers because your costs can be tied to actual usage. But even if there is another data center in a different region, there is still the question of whether your cloud service provider can assure seamless failover in the event of an outage.
For other cloud services - especially Software-as-a-Service (SaaS) -- true redundancy becomes significantly more complicated. The application (including any customizations to it), and underlying infrastructure would need to be fully replicated.
In either case, however, the location of the redundant data center can be a major sticking point. There are a variety of reasons - including export controls, intellectual property protection and regulatory compliance - why you might not want your data transferred outside the United States. If your cloud provider can't assure you that the redundant data center is U.S.-based, then be prepared to use another vendor. Otherwise, you'll be running the risk of degraded availability due to a lack of data center redundancy where you need it.
In fairness to cloud vendors, your risks of outages do not magically disappear if you decide to keep running your enterprise software on-premise or in your own data centers. In fact, in many cases, it's questionable whether an organization's internal team can address such risks better than experienced cloud vendors.
Certainly, the use-case matters. For example, if internal email is down for a period of time, It's inconvenient but unlikely to have significant impact on your revenues.. On the other hand, if the e-commerce Website that accounts for the vast majority of your company's sales goes down, revenue and brand impact will be immediate and damaging. In the latter case, you'll want to carefully consider whether to host that Website yourself, especially if you have a proven disaster recovery plan and considerable resources.
If you do opt for cloud vendors for some or all of your needs, there are clear benefits to having a strong SLA for your cloud services. For starters, an SLA may simply incentivize the vendor to perform to the agreement.
What to Watch For in Your Cloud SLAs
Most SLAs allow your cloud vendor to have some permitted downtime, including scheduled maintenance. This may represent fairly significant period of time, but it is rarely quantified. In general, cloud vendors compensate customers for SLA breaches by providing service credits. To receive service credits, the customer must notify the vendor -- usually within five business days to 30 calendar days, depending on the SLA. Some SLAs give customers audit rights to confirm the SLA determinations.
Typically, service credits in cloud SLAs are limited to 25% of recurring charges, at most. Some SLAs assign a flat percentage to a failure to meet a particular service level, such as service availability (uptime). Others give the customer one service credit (equal to, e.g., 1/30 of the month during which the applicable service level was not met) plus additional credits for each increment (measured in minutes) beyond the permitted downtime. Service credits have value in that they can be obtained without your company having to prove actual damages as a result of the SLA breach.
In addition to addressing uptime/downtime, SLAs may exist for restore time, response time, specific transactions, and resolution of critical defects. Some enterprises even look to cloud vendors to provide a service level for user satisfaction.
Other key SLA concepts include measurement periods for unavailability (usually monthly or quarterly). This is typically defined as total hours during a measurement period minus permitted downtime in that period. Annual measurement periods are almost useless, especially if there have been persistent outages and the sole remedy is a credit (for a service that the customer no longer wants). Quarterly measurements are a better option than annual measurements. But they bring their own dangers: For example, if there have been outages in the first and second months of the quarter, it's possible that the vendor will still be able to provide the required availability for the total quarter, and thus not violate the SLA.
You should be aware of the limits of the SLA with your cloud vendors. An SLA is not a substitute for backing up your data or otherwise creating and executing a disaster recovery plan. In fact, some cloud services agreements contractually require the your enterprise to back up its own data, in addition to making it absolutely clear that the vendor is not responsible for such services.
About the Author
John Pavolotsky's legal practice focuses on technology transactions and other intellectual property matters at Greenberg Traurig, where he is Of Counsel. He works primarily with clients in the software, hardware, Internet, mobile, wireless and life sciences industries. All views expressed herein are solely those of the author and should not be attributed to Greenberg Traurig.