Cloud IaaS SLAs can be meaningless
In infrastructure services, the purpose of an SLA (or, for that matter, the liability clause in the contract) is not “give the customer back money to compensate for the customer’s losses that resulted from this downtime”. Rather, the monetary guarantees involved are an expression of shared risk. They represent a vote of confidence — how sure is the provider of its ability to deliver to the SLA, and how much money is the provider willing to bet on that? At scale, there are plenty of good, logical reasons to fear the financial impact of mass outages — the nature of many cloud IaaS architectures create a possibility of mass failure that only rarely occurs in other services like managed hosting or data center outsourcing. IaaS, like traditional infrastructure services, is vulnerable to catastrophes in a data center, but it is additionally vulnerable to logical and control-plane errors.
Unfortunately, cloud IaaS SLAs can readily be structured to make it unlikely that you’ll ever see a penny of money back — greatly reducing the provider’s financial risks in the event of an outage.
Amazon Web Services (AWS) is the poster-child for cloud IaaS, but the AWS SLA also has the dubious status of “worst SLA of any major cloud IaaS provider”. (It’s notable that, in several major outages, AWS did voluntary givebacks — for some outages, there were no applicable SLAs.)
HP has just launched its OpenStack-based Public Cloud Compute into general availability. HP’s SLA is unfortunately arguably even worse.
Both companies have chosen to express their SLAs in particularly complex terms. For the purposes of this post, I am simplifying all the nuances; I’ve linked to the actual SLA text above for the people who want to go through the actual word salad.
To understand why these SLAs are practically useless, you need to understand a couple of terms. Both providers divide their infrastructure into “regions”, a grouping of data centers that are geographically relatively close to one another. Within each region are multiple “availability zones” (AZs); each AZ is a physically distinct data center (although a “data center” may be comprised of multiple physical buildings). Customers obtain compute in the form of virtual machines known as “instances”. Each instance has ephemeral local storage; there is also a block storage service that provides persistent storage (typically used for databases and anything else you want to keep). A block storage volume resides within a specific AZ, and can only be attached to a compute instance in that same AZ.
AWS measures availability over the course of a year, rather than monthly, like other providers (including HP) do. This is AWS’s hedge against a single short outage in a month, especially since even a short availability-impacting event takes time to recover from. 99.95% monthly availability only permits about 21 minutes of downtime; 99.95% yearly availability permits nearly four and a half hours of downtime, cumulative over the course of the year.
However, AWS and HP both define their SLA not in terms of instance availability, or even AZ availability, but in terms of region availability. In the AWS case, a region is considered unavailable if you’re running instances in at least two AZs within that region, and in both of those AZs, your instances have no external network connectivity and you can’t launch instances in that AZ that do; this is metered in five-minute intervals. In the HP case, a region is considered unavailable if an instance within that region can’t respond to API or network requests, you are currently running in at least two AZs, and you cannot launch a replacement instance in any AZ within that region; the downtime clock doesn’t start ticking until there’s more than 6 minutes of unavailability.
(Update: HP provided some clarifications.)
Every AZ that a customer chooses to run in effectively imposes a cost. An AZ, from an application architecture point of view, is basically a data center, so running in multiple AZs within a region is basically like running in multiple data centers in the same metropolitan region. That’s close enough to do synchronous replication. But it’s still a pain to have to do this, and many apps don’t lend themselves well to a multi-data-center distributed architecture. Also, that means paying to store your data in every AZ that you need to run in. Being able to launch an instance doesn’t do you very much good if it doesn’t have the data it needs, after all. The AWS SLA essentially forces you to replicate your data in two AZs; the HP one makes you do this for all the AZs within a region. Most people are reasonably familiar with the architectural patterns for two data centers; once you add a third and more, you’re further departing from people’s comfort zones, and all HP has to do is to decide they want to add another AZ in order to essentially force you to do another bit of storage replication if you want to have an SLA.
(I should caveat the former by saying that this applies if you want to be able to usefully run workloads within the context of the SLA. Obviously you could just choose to put different workloads in different AZs, for instance, and not bother trying to replicate into other AZs at all. But HP’s “all AZs not available” is certainly worse than AWS’s “two AZs not available”.)
Amazon has a flat giveback of 10% of the customer’s monthly bill in the month in which the most recent outage occurred. HP starts its giveback at 5% and caps it at 30% (for less than 99% availability), but it covers strictly the compute portion of the month’s bill.
HP has a fairly nonspecific claim process; Amazon requires that you provide the instance IDs and logs proving the outage. (In practice, Amazon does not seem to have actually required detailed documentation of outages.)
Neither HP nor Amazon SLA their management consoles; the create-and-launch instance APIs are implicitly part of their compute SLAs. More importantly, though, neither HP nor Amazon SLA their block storage services. Many workloads are dependent upon block storage. If the storage isn’t available, it doesn’t matter if the virtual machine is happily up and running — it can’t do anything useful. For example of why this matters, you need look no further than the previous Amazon EBS outages, where the compute instances were running happily, but tons of sites were down because they were dependent on data stores on EBS (and used EBS-backed volumes to launch instances, etc.).
Contrast these messes to, say, the simplicity of the Dimension Data (OpSource) SLA. The compute SLA is calculated per-VM (i.e., per-instance). The availability SLA is 100%; credits start at 5% of monthly bill for the region, and go up to 100%, based on cumulative downtime over the course of the month (5% for every hour of downtime). One caveat: Maintenance windows are excluded (although in practice, maintenance windows seem to affect the management console, not impacting uptime for VMs). The norm in the IaaS competition is actually strong SLAs with decent givebacks, that don’t require you to run in multiple data centers.
Amazon’s SLA gives enterprises heartburn. HP had the opportunity to do significantly better here, and hasn’t. To me, it’s a toss-up which SLA is worse. HP has a monthly credit period and an easier claim process, but I think that’s totally offset by HP essentially defining an outage as something impacting every AZ in a region — something which can happen if there’s an AZ failure coupled with a massive control-plane failure in a region, but not otherwise likely.
Customers should expect that the likelihood of a meaningful giveback is basically nil. If a customer needs to, say, mitigate the fact he’s losing a million dollars an hour when his e-commerce site is down, he should be buying cyber-risk insurance. The provider absorbs a certain amount of contractual liability, as well as the compensation given by the SLA, but this is pretty trivial — everything else is really the domain of the insurance companies. (Probably little-known fact: Amazon has started letting cyber-risk insurers inspect the AWS operations so that they can estimate risk and write policies for AWS customers.)
Posted on December 5, 2012, in Infrastructure and tagged cloud, IaaS. Bookmark the permalink. 18 Comments.
I wouldn’t call the Amazon SLA “meaningless” just because it doesn’t cover what people expect it to cover. The SLA is useful if you build your cloud app with the “Rambo Architecture”. Instances and AZs can die, but the SLA says “you should be able to launch replacements”, which means a well-written app can make forward progress.
I also don’t see the a problem with “you must use multiple AZs”. If you want High Availability, you can’t use a single data center. The SLA may as well state “we only care about people willing to re-architect their applications for the cloud”.
Other companies may have ‘better’ SLAs, but that doesn’t make them more reliable. (Witness the many reputable datacenters in New York that went entirely offline because they were not prepared to self-power more than a day or two.)
Hi there every one, here every one is sharing these kinds of know-how, thus it’s fastidious to read this blog, and I used to pay a quick visit this webpage every day.
I have read so many articles or reviews about the blogger lovers however this piece of writing
is genuinely a good post, keep it up.
My brother suggested I would possibly like this blog.
He used to be entirely right. This put up truly made my day.
You cann’t consider simply how much time I had spent for this info! Thanks!
Wow, this article is fastidious, my sister is analyzing these things, so I
am going to tell her.
After checking out a handful of the blog articles on
your site, I really appreciate your technique of
blogging. I book-marked it to my bookmark website
list and will be checking back soon. Please check out my web site too and let me know your opinion.
Definitely believe that which you stated. Your favourite justification
seemed to be at the internet the simplest factor to keep in mind of.
I say to you, I definitely get annoyed even as folks think about concerns that they just don’t realize
about. You managed to hit the nail upon the highest and also defined out
the whole thing without having side-effects , folks
could take a signal. Will probably be again to get more.
Hey, just became aware of your blog through Google, and found that it is really informative. I’m gonna watch out for brussels. I’ll be grateful if you continue this in future. Many people will be benefited from your writing. Cheers!
Pingback: HP undercuts Rackspace on OpenStack IaaS price | CodeBlue Technology
Pingback: Who's Who in Cloud December 7, 2012 « Gathering Clouds Gathering Clouds
Pingback: Some clarifications on HP’s SLA « CloudPundit: Massive-Scale Computing
Pingback: HP undercuts Rackspace on OpenStack IaaS price | My Blog
Pingback: Cloud IaaS SLAs Can Be Meaningless: Kown What You're Paying For
Pingback: Amid criticism, HP pledges to refine SLAs for IaaS | My Blog
Pingback: Amid criticism, HP pledges to refine SLAs for IaaS | CodeBlue Technology
Pingback: The Enterprise Cloud Site - Michael Steinhart - Controversy & Dissent Plague Cloud SLAs
Pingback: A tale of a 7 year journey in developing software for the enterprise | The Enterprise Architect
Pingback: A tale of a 7 year journey in developing software for the enterprise | by Johan Den Haan