This past Sunday was (as most of us are aware) Valentine’s Day. It’s a time many look forward to for great dinners, nights out, and quality time with our significant others.
For science fiction fans, the excitement was about something else entirely. Sunday marked the mid-season premiere of The Walking Dead. For those of you who are not aware, the show revolves around a post-apocalyptic world where zombies attacking the living is the new normal. It’s fun entertainment.
Zombies have been showing up in popular culture such as World War Z and I Am Legend, and in another more unexpected place: Amazon’s AWS Service Terms. Section 57.10 states in part: “The Lumberyard Materials are not intended for use with life-critical or safety-critical systems… However, this restriction will not apply in the event of the occurrence (certified by the United States Centers for Disease Control or successor body) of a widespread viral infection transmitted via bites or contact with bodily fluids that causes human corpses to reanimate and seek to consume living human flesh, blood, brain or nerve tissue and is likely to result in the fall of organized civilization.” No, I’m not making this up. Go ahead and check it out.
We have a mission-critical virtual private cloud, and our first thought was, “Hey! We can do that! We’re the cloud for the Zombie Apocalypse!” Sounds like a great (or not) marketing campaign – and that’s exactly what this was for Amazon. They certainly didn’t add this clause to provide a platform for the defense of a flesh-eating walking dead apocalypse. It is specific to their Lumberyard platform which is targeted towards game developers, and this was a clever way to add a contract “Easter Egg” that would appeal to that market segment. It’s a pretty brilliant marketing idea if you ask me. So, phew, no Zombie Apocalypse.
The hidden nature of the clause started making me think about cloud contracts in general. How many hidden items (I’m calling these Zombie Clauses from now on) appear in a public cloud contract that are missed because they are too long, too obscure, or skimmed over? It turns out there’s a lot of them.
If you dig into public cloud contracts, there are Zombie Clauses for everything. No liability for security issues (that’s yours to configure) and no liability for data loss (do your own backups). There are Service Level Agreements that are “per piece” – so 99.9% uptime (8 hours, 45 minutes downtime per year) is for storage. Network, Connectivity, all components are separate (to the point that you can be down for over 300 hours in a year and still be technically within the SLA. There are provisions in some contracts that the downtime meter doesn’t start running until you’ve been down for 10 minutes or more, so hiccups do not count (very frustrating when your cloud platform has a prolonged bout of the hiccups).
There are plenty of contracts that we skip through and click “I accept”. Your cloud contract should not be one of them. You should spend the time to look at what will be contractually delivered, and what you should expect. Many of these Zombie Clauses should be removed as frequently as they’ve killed off Glenn.
For more on understanding your Cloud Service Level Agreement, read our recent blog post Comparing Service Level Agreements: Stacked SLAs, Reindeer Games and Defining the Cost of an Outage