This week brought news that pharmaceutical giant Eli Lilly has ended its use of Amazon EC2 because of an inability to negotiate contractual terms with Amazon Web Services. Though subsequently retracted, the beef, as originally reported, was that Eli Lilly wanted AWS to assume more (read “some”) liability for network outages, data breaches and other issues that might affect Eli Lilly’s business.
Whether true or not, the issues the report raises will become more common as large enterprises consider moving more workloads to the cloud. They add prestige to customer lists, but large companies also stand to lose a lot of money if something goes wrong. And they want to know they’re covered if that happens. What’s not so certain is whether cloud computing providers will, should or have to budge.
Cloud computing terms of service — from every self-service provider — uniformly deny all liability for outages or data losses, disclaim all warranties of any type and limit damages to those outlined in the SLA. In some cases, they might allow recovery up to the actual amount of costs paid to the provider, or for additional damages based on (extremely rare cases of) gross negligence, willful misconduct or fraudulent misrepresentation. Businesses that use cloud resources to host customer-facing services must indemnify the cloud provider should any of these third-party (and, thus, not contractually bound) customers sue the provider for any reason.
The Legality of it All
If these terms sound unfair, too bad: In similar circumstances (Google AdWords and clickwrap contracts), courts have proven quite willing to uphold them. When challenged on the grounds that form agreements constitute contracts of adhesion, courts have been loath to find them either procedurally or substantively unconscionable, both of which are necessary to render the terms unenforceable. This is especially true in cases like that of AWS and Eli Lilly, where both parties are commercial entities perfectly capable of understanding contractual terms and obligating themselves however they please.
When viewed in light of the cloud computing model, there’s even better reason to see why such terms are allowed to persist. Multitenant infrastructures mean a single failure could affect an untold number of users, which could leave providers defending just as many lawsuits. Additionally, cloud computing (IaaS, particularly) can be a low-margin business for providers, while offering customers the chance to do a lot for only a little money. Assuming liability, even for negligence, would be a high-risk, low-reward proposition for providers. Finally, the anonymity of self-service cloud computing means that cloud providers don’t necessarily even know who’s running what on their platforms, and thus can’t act accordingly. This argument gains support from contract law, specifically Restatement (Second) of Contracts § 351, which protects against damages “that the party in breach did not have reason to foresee as a probable result of the breach when the contract was made.”
Should Cloud Providers Care?
Although cloud providers should be able to sleep easy knowing their customer agreements are valid and enforceable, they’re always free to negotiate terms with individual customers if they want to. This might not be a bad idea for some customers (Eli Lilly, perhaps), but where do providers draw the line? Who is important enough to negotiate with, and how much risk are they willing to assume if they don’t have to?
For true self-service, pay-per-use offerings like AWS, both the delivery model and the provider-customer relationship represent a change (arguably for the better) from the longstanding vendor-customer relationship and resource procurement model. If cloud providers really want enterprise customers, they must consider how far they’re willing to bend to earn that business. Enterprises need to figure out what they actually want from the cloud, because with most cloud providers, they can’t have their cake and eat it too. There are plenty of cloud options offering negotiable contracts, meaningful SLAs and even dedicated resources, but they don’t accept American Express.