Cloud Contracts: 8 Questions To Ask
What should you look for in a cloud contract? What's hiding in cloud providers' service-level agreements and terms? Read our expert guide.
What's a cloud service-level agreement (SLA) worth? Sometimes, not much.
SLA language is often vague, reflecting a young industry where no one is certain just how porous provider guarantees may be. There are loopholes, like if you're notified of pending downtime due to regular maintenance that makes your service unavailable, that won't count toward the guaranteed amount of uptime promised each year.
Google Compute Engine, Amazon Web Services, Microsoft Azure, and the HP Cloud cluster around a stated guarantee of 99.95% uptime, with penalties to follow if they fall under that mark in any given month or quarter and cause their customers a loss of service.
That would seem to be a high standard. After all, it only allows four hours and 38 minutes of downtime for a given year. But that's not the highest standard active among service providers. Dimension Data guarantees 99.99% uptime, and if they can do it, why not the bigger-name providers? That standard allows only 53 minutes of downtime a year.
Or possibly your contract goes in the opposite direction. NetSuite's most recent SLA document, from May 2013, guarantees 99.5% uptime, which could allow over 43 hours of downtime a year.
Salesforce.com's contract states that Salesforce will "use commercially reasonable efforts to make the online Purchased Services available 24 hours a day, 7 days a week," whatever "commercially reasonable" means. The exceptions are planned downtime such as maintenance intervals and "events beyond our control" such as earthquakes, civil unrest, acts of terrorism, or war.
Salesforce's exceptions to its pledge of constant availability include "denial of service attack." Most service providers on the Web have built in protections against denial of service attacks and don't consider them an event that justifies a service outage.
Amazon Web Services was once termed by Gartner cloud analyst Lydia Leong as "the poster child for cloud IaaS, but the AWS SLA also has the dubious status of 'worst SLA of any major cloud IaaS provider.'''
AWS's current SLA (dated June 1, 2013), also uses "commercially reasonable efforts" as the standard by which it will achieve 99.95% uptime. Its definition of when it's down, or "unavailable," leans in favor of the provider. For example, a customer using only one availability zone within an Amazon regional data center isn't acting on Amazon's recommended best practice of having backup in a second availability zone. Each region has multiple availability zones that function autonomously from each other. To violate Amazon's SLA, more than one availability zone must be unavailable to the customer. So if a whole availability zone goes down and you're in it, you collect nothing in the way of Amazon SLA credits unless your workloads also occupied another zone, and it was also unavailable.
In addition, all workloads need to be down, not just some of them, for the SLA's credit repayment to kick in. And Amazon has all year to achieve that 99.95% uptime, even if it's down for four-and-a-half hours in a given month.
Even the definition of "available" leans in favor of AWS. For EC2 to be considered "unavailable," all of a customer's instances must be unavailable in EC2 in a given region, such as the US East data center complex in Ashburn, Va. In addition, for the storage attached to running instances to be unavailable, they must be performing "zero read/write I/O, with pending I/O in the queue." In other words, if Elastic Block Store has slowed to a snail's pace, and your business is clearing three or four transactions an hour, that doesn't necessarily qualify as an outage meriting a service credit.
While HP's SLA for its public cloud is also set at 99.95% availability, that's for each month, not across a whole year. And its terms consider the loss of availability of one instance, not all instances in a given region, to be an outage. In the cloud, each service has its own SLA definitions, complicating the picture and giving providers more than one exception on an outage claim.
Amazon, to its credit, has chosen to interpret its terms liberally, offering credits to customers for its April 2011 Easter outage even though servers were up and running during it. Customers, in some cases, had no way of accessing them or making use of the Elastic Block Store storage service, as a disconnected network set off a "remirroring storm" inside its US East facilities.
What's your cloud's uptime? What's in your SLA? Can your service provider do better? Read on to learn more about what to look for in your cloud contracts. Share additional advice with your peers using the comments section.
(Source: Kara Harms on Flickr)
What's the consequence for downtime that exceeds the contractual limit? This is one of the biggest gotchas in cloud contracts. Amazon Web Services pays for downtime by granting customers a repayment credit for the time lost. But what if your website is down for four hours and 39 minutes during the holiday buying season? What's the lost business worth? An Amazon credit won't begin to cover the real cost of the downtime. NetSuite has a higher standard if it crosses the outage limit. It grants a month's free service to compensate. There's still no compensation for the loss of reputation and business, but better a 30-day repayment versus a simple swap of replacement credit for the downtime.
(Source: Public Domain Pictures on Pixabay.)
Data security is paramount in the cloud, and the cloud vendors say a lot of nice things about providing it. But how do they provide it?
Salesforce.com's contract says, "We will maintain administrative, physical, and technical safeguards for protection of the security, confidentiality, and integrity of Your Data, as described in the Documentation." What exactly are those safeguards? Encryption of data in motion? Do they meet HIPAA or PCI DSS standards? The contract says the safeguards are described in the documentation, and its definition of what constitutes the documentation is: "Our online user guides, documentation, and help and training materials, as updated from time to time, accessible via help.salesforce.com." You may ask, "which version of all these materials?" since they are going to be changed and redrafted periodically.
The nature of data security as covered by the contract looks like a moving target. When it comes to keeping information confidential, the contract says Salesforce.com "will use the same degree of care that it uses to protect the confidentiality of its own confidential information," which may be reassuring. But it's still hard to know exactly what you're getting. The Amazon Customer Agreement guarantee sounds like this: "We will implement reasonable and appropriate measures designed to help you secure Your Content against accidental or unlawful loss, access, or disclosure."
(Source: nevillekingston on Pixabay.)
One un-cloudlike characteristic of some contracts is that they don't charge you for what you use, the way the cloud is supposed to. They charge you for each month that you've signed up for the service at the level of use stated in the contract -- not what you actually use. That means of course, if you don't use the service at the stated level, you will still be charged. Salesforce.com's contract wording is perfectly clear under Section 6, Fees and Payments: "6.1. Fees are based on Services and Content purchased and not actual usage."
(Source: timlewisnm on Flickr.)
Newcomer CloudHealth points out that customers may seek the savings promised by Amazon's Reserved Instance agreement, but something may be going awry behind the scenes as they think they're converting on-demand instances to lower cost RIs.
For the conversion to be successful, the on-demand instance being converted has to be located in the physical facility where the Reserved Instance was created. An Amazon instance's availability zone is a logical map to a number of physical facilities. It's hard for a customer to know which one its on-demand instances may actually reside in, since Amazon provides a logical location assignment, not a physical one. The RIs, on the other hand, must operate in the physical facility where they were created. One customer looking for 40% savings by converting 150 on-demand instances to RIs actually achieved 5% savings because so few of its on-demand virtual machines could be mapped to the available RIs, says Joe Kinsella, CEO of CloudHealth.
So if you're trying to achieve the advertised savings, ask Amazon where your on-demand instances are and where are the RIs will be that you wish to launch in their place. It's not easy for customers to figure that out on their own.
(Source: Pascal on Flickr.)
Watch the small print in the on-demand service terms for extra fees and hidden charges. Don't assume just because it's easy to get into the cloud that it's also easy to get out. There's no charge for loading your data into Amazon, Microsoft Azure, or Google Compute Engine. Each provider considers the prospect of charging you to upload your data a friction that may impede capturing new business. But when it comes to getting your data out, that's a different story, and a little friction may help you decide not to leave. To export data to the Internet, you'll pay 12 cents per GB after the first free GB, which adds up quickly if you've accumulated terabytes of big data. That would be $120 per TB.
If you're using Amazon's Elastic Block Store, you can expect 4,000 I/O per second in 16K increments per provisioned volume. If that's not fast enough, you can pay for more. And if you're moving data around, say from Relational Database Service to S3 or Glacier storage, that's 1 cent per GB within the same availability zone. If you like to spread copies across various zones, as frequently recommended by Amazon as a reliability factor, that's 2 cents per GB.
(Source: Wikipedia.)
Guaranteed performance in a cloud contract is about as easy to find as newly minted $50 gold pieces in the Sierra Nevada foothills. It's on the subject of performance that some of the cloud's most artful language shows its stuff. Salesforce.com refers obliquely to performance when it says: "Purchased Services will perform materially in accordance with the applicable Documentation, (d) subject to Section 5.3 (Integration with Non-Salesforce.com Applications)," and, "We will not materially decrease the functionality of the Purchased Services during a subscription term." There is no guarantee it will maintain existing response times or other performance benchmarks.
Amazon's SLA refers to services maintained by "commercially reasonable efforts," as do the contracts of other cloud providers. Purchased services "will perform materially in accordance with the applicable Documentation" -- no metrics mentioned. You do get this promise: "We will not materially decrease the functionality of the Purchased Services during a subscription term," but a service whose performance has slowed can still display the same functionality.
(Source: Philipp Lucke on Flickr.)
Cloud services are so new and changing so rapidly that no one considers it strange that the service provider reserves the right to change the service it provides to you. The wording is usually generous enough that the service could change substantially after you've contracted for it, and the provider, if it were in its business interests to do so, could amend it significantly. It may be a good idea to leave that right in the provider's hands, but the Common Law Group, in its Common Legal Issues In Cloud Contracts, recommends limiting the wording in a way that suggests changes have to be beneficial to customers as well as suppliers. Customers could try to limit changes to "commercially reasonable modifications," it suggests. "Even better would be to add to that a qualification prohibiting 'materially detrimental' modifications -- perhaps something to the effect of, 'Service Provider may make commercially reasonable modifications to the Service, provided that they do not materially diminish the nature, scope, or quality of the Service.'"
(Source: UCAR on Flickr.)
The Cloud Security Alliance recommends that every cloud contract include provisions allowing a third-party auditor to audit the service provider annually to ensure that the security measures named in the contract are actually being provided. Most cloud contracts have no such authorization.
"Ideally, the contract should also provide for regular SAS 70, Type II audits, with customer access to the results," says the Common Law Group, citing the CSA's recommendation.
The CSA has also prepared a useful guide to security issues in cloud contracts: "CSA Security Guidance Domain 3: Legal Issues -- Contracts and Electronic Discovery," available for free download from the CSA's Resource Library.
(Source: Crazy Label on Flickr.)
The Cloud Security Alliance recommends that every cloud contract include provisions allowing a third-party auditor to audit the service provider annually to ensure that the security measures named in the contract are actually being provided. Most cloud contracts have no such authorization.
"Ideally, the contract should also provide for regular SAS 70, Type II audits, with customer access to the results," says the Common Law Group, citing the CSA's recommendation.
The CSA has also prepared a useful guide to security issues in cloud contracts: "CSA Security Guidance Domain 3: Legal Issues -- Contracts and Electronic Discovery," available for free download from the CSA's Resource Library.
(Source: Crazy Label on Flickr.)
-
About the Author(s)
You May Also Like