Amazon S3 At Your Service

Virtually everyone on the Amazon Web Services team has occasion to interact with our developer customers from time to time. This rich source of product feedback gives us a lot of insight into ways that we can do an even better job of meeting their needs as we grow and enhance each of our web services.

Some of the developers building applications with Amazon S3 have been asking us about an SLA, or Service Level Agreement. An SLA defines the minimum acceptable level of performance from a service along with some sort of penalty for not meeting expectations. A typical SLA actually defines a performance or reliability boundary which is somewhat lower than what the system is actually designed, built, and expected to deliver.

We know that many of our customers, including a multitude of teams within Amazon, are using S3 in mission-critical ways and need a formal commitment from us in order to make commitments to their own users and customers.

After talking to many developers to make sure that we fully and precisely understood what the term "SLA" meant to them, we were able to start defining one that was appropriate for S3.

I am very happy to announce that, effective October 1, 2007, The Amazon S3 Service Level Agreement is in effect.

This SLA has been in the works for a while and we take the commitments made in this document quite seriously. We knew that S3 had to meet the very high performance and reliability goals set by our internal clients. We strongly believed that meeting this level of operational excellence would be good enough for our external users as well. Before we published our SLA, we wanted to get a better sense of how our external developers were making use of S3. With well over 5 billion objects under management, we now understand the usage patterns and properties needed to make an informed commitment.

You can read the entire document to see how this will work. Basically, we commit to 99.9% uptime, measured on a monthly basis. If an S3 call fails (by returning a ServiceUnavailable or InternalError result) this counts against the uptime. If the resulting uptime is less than 99%, you can apply for a service credit of 25% of your total S3 charges for the month. If the uptime is 99% but less than 99.9%, you can apply for a service credit of 10% of your S3 charges.

We're committed to providing a highly available service which meets the needs of current and future customers. This new SLA is our way of formalizing that commitment, letting you know what the minimum expected level of performance will be.

As is the norm with agreements like this, there's some fine print and you should definitely read it yourself to learn more.

--Jeff;

Comments

[Fred Oliveira]

These are pretty exciting news, Jeff. I've heard it from several people that they could not risk a move to S3 because of the lack of a Service Level Agreement. No excuse now - this is a great move.

Wrote about it here, too:
http://blog.webreakstuff.com/2007/10/amazon-s3-gets-a-sla-exhale/

[Felipe Albertao]

This is a great start! When are you guys going to provide some kind of guarantee on EC2 as well? Also, it would be great if you make EC2 instances persistent. You do not need to provide a SLA for data stored on EC2, but at least some assurance that the data will not be lost due to shutdown or hardware failures.

[Paul Stamatiou]

"you can apply for a service credit" - How does one go about this process? Hopefully it is not on some page hidden 10 links deep.

[Oliver Thylmann]

great news, thanks. Another thing that recently came to me was that it would be very nice if there was an option to quasi acquire a permanent IP as an entry point into S3, meaning that I can have a load balancer on there and if it fails give the ip to another one, which is probably a faster solution than some faulty dyndns or low TTLs in your dns server.

Or is there another suggestion?

[Oliver Thylmann]

never mind me ;) http://www.eweek.com/article2/0,1759,2190210,00.asp

[Domain Url]

I've heard it from several people that they could not risk a move to S3 because of the lack of a Service Level Agreement.

[Darryl Collins]

Great move. But is it really the case that customers who have experienced outages are responsible for initiating the service credit claim? Within 10 days? With all the pertinent details? Surely you already have all the relevant information and can spot and process the credit automatically without customer input? Seems like off-loading responsibility to customers to me, but maybe I am too cynical! :-)

[Mica Cooper]

Great,

You have an SLA. Now for the next step!

AWS needs to have a Security document in place describing the physical and logical security procedures for AWS. How are old hard drives cycled? Are they destroyed? Are they sold without being securely wiped? Who has access to the hardware? Is it possible for customers to get access to other customers data? Has it ever happened? Is AWS Hippa compliant?

PLEASE do this. I had a Fortune 50 client ready to use AWS but could not because there was no security document.

[Reuven Cohen, CEO, Enomaly Inc]

This is awesome, we've been getting a lot of request for an SLA in context to our S3 backed Disaster Recovery solution ElasticDrive. We're one step closer to ditching the idea of traditional storage in favor of a complete cloud based solutions.

Nice work!