You can more - Fotolia


AWS SLAs guarantee uptime, but users aren't off the hook

Despite the availability guarantees in AWS' service-level agreements, enterprises need to read the fine print and put in some work themselves to protect against losses.

As many companies increase their investments in AWS, it's important to ask which services are covered by a service-level...

agreement, but the answer isn't necessarily satisfying.

AWS SLAs are similar across most of its services, and those agreements include availability guarantees.

"I was just at re:Invent, and AWS was talking about how they have raised their general availability for AWS services to 99.99%," said Bill Martorelli, principal analyst at Forrester. AWS bakes that claim into its SLA language. For example, the Elastic Compute Cloud SLA states: "AWS will use commercially reasonable efforts to make Amazon EC2 and Amazon EBS [Elastic Block Store] each available with a Monthly Uptime Percentage … of at least 99.99%, in each case during any monthly billing cycle."

But keep an eye on the fine print that follows that reassuring language. "In the event Amazon EC2 or Amazon EBS does not meet the Service Commitment, you will be eligible to receive a Service Credit as described below." The "below" makes it clear that you'll get something, but it might not be nearly as valuable as what you lose if you suffer downtime.

"The important thing to remember is that, should the SLA be breached, there is no way that the payout is going to cover your losses," said Owen Rogers, research director of digital economics at 451 Research. For example, he said, if your e-commerce site goes down on Black Friday, "then a few dollars [for a] refund of a virtual machine isn't going to repair the damage in lost opportunity."

AWS' SLAs won't really cover losses, but caveat emptor could also be in play. "We think all services should be adequately covered by SLAs without exception, but customers vote with their feet and, so far, don't seem to have cared enough," said Lydia Leong, analyst at Gartner.

Don't treat AWS' SLAs like an insurance policy, she said. Instead, evaluate the specifics of SLAs to understand the likely availability of services so you can plan your architecture accordingly. "It is really up to you to decide whether you want to put something in a different region, and it is up to you to determine your plan," Leong said.

Factor disaster recovery into your assessment

That means an AWS customer should think through the economic implications. As with traditional business continuity and disaster recovery (BCDR), you have to determine how much you want to spend to meet your goals. But it can be difficult to translate SLA verbiage and BCDR priorities into the right array of cloud services.

Paying for two [VMs] in two availability zones might be twice the cost of just one, but it is a premium worth paying to protect revenue.
Owen RogersResearch Director, Digital Economics, 451 Research

AWS' zone architecture often includes multiple data centers within each zone. This potentially delivers more redundancy and reliability than some competitors. Azure doesn't have that level of redundancy yet, though plans to in the future, Leong said. Even as cloud competitors seek to add more redundancy, they'll need to catch up to AWS in other ways.

The key to cloud success is to build resiliency into every aspect of a cloud, regardless of what an SLA says. "Paying for two virtual machines in two availability zones might be twice the cost of just one, but it is a premium worth paying to protect revenue," Rogers said.

Framing the concept a little differently, Martorelli said that clouds SLAs are different than SLAs with other managed services. Traditional SLAs slowly evolved to meet the specific needs of customers and providers, and they often reflected special levels of care or reliability. In the cloud, it is more of a one-size-fits-all approach. "The customer needs to have more awareness and must be watchful rather than complacent," he said. "We have made the argument over the years that you don't look at cloud SLAs as an instrument of financial redress for services interruption."

Instead, try to architect reliability yourself, independent of AWS' SLAs. For example, run applications across two or more availability zones to ensure the highest reliability. That will make SLAs the icing on the cake if a reliability issue develops.

Dig Deeper on AWS support, licensing and SLAs