In this lecture, I’d like to take a look at the SLA for one of the most fundamental services in AWS, which is Amazon EC2. To do this, I’ll go to the website, aws.amazon.com/legal/service-level-agreements. 

On this site, you can find any AWS service SLA.  You can either look through the list of services, or you can use the search bar to find the service SLA you’re looking for. In this case, I’m looking for the EC2 SLA, so I’ll type in EC2 and press enter. 

Here, I can see two results in the list, one for EC2 and one for instance-level EC2. If we click into either of these results, we’ll see the same information - so I’ll just choose the first option on the list. 

Each SLA page has the following information:

1. It details the availability commitment or what percentage of uptime that AWS will guarantee. 

2. When AWS misses that percentage of uptime, the SLA also tells you the amount of service credits you can get, depending on how much they missed their guarantee 

3. If you’re entitled to service credits, it tells you how and what you need to submit a claim 

4. It tells you what’s excluded, 

5. And it also provides definitions. This is important, as every SLA will define what availability means for that service, and it can be different depending on the service. For example, some SLAs define availability based on the period it is available, while some define it based on failed requests to the service. 

For EC2, we can see that availability or monthly uptime percentage for EC2 is defined based on the period of time the service is unavailable. You can get this number by taking 100% and then subtracting the percentage of minutes that EC2 was in the state of unavailability. And we also get the definition for unavailability, which means that all your instances, whether you only have one or more, have no external connectivity.

Now that we understand how availability is defined, let’s talk about the commitment. For EC2 and most instance-based services, there are two levels of commitment depending on how you architect your application. The first is a region-level commitment for apps that have instances across multiple AZs and the second is an individual instance-level commitment for apps that use a single instance in a single AZ. 

For the region-level SLA, AWS commits to availability of at least 99.99%. That means, if you experience downtime for more than 4 minutes and 22 seconds in a month, then you are entitled to some level of service credit. 

For example, if your downtime is more than 4 minutes and 22 seconds (which is 99.99% availability), but less than 7 hours and 30 minutes (which is 99.0% availability), then you are entitled to 10% of your total spend in service credits. The longer the service is down, the more service credits you get. 

Let’s compare these availability times to the instance-level SLAs. Obviously, one instance will have lower availability than multiple instances, especially if they are positioned across multiple AZs. So, in this case, AWS commits to availability of at least 99.5%, which is about 3.6 hours a month of downtime. In addition to this, AWS also says that if an instance is down for more than 6 minutes in an hour, you will not be charged for that hour. The nice thing about this 6-minute rule is that it applies automatically, you don’t have to send in a credit request to support in order to not be charged. 

However, to take advantage of service credits for all other SLAs, you do need to submit a request and back up that request with proof. For EC2, the proof you’ll need is listed, and it says you need: 

1. the dates, times, and affected AWS region (for region-level SLAs) or AZ (for instance-level SLAs) of each Unavailability incident that you are claiming

2. the resource IDs for Amazon EC2; and

3. your request logs that document the errors and back up your claimed outage.

Last, each SLA details what it excludes as well. This basically says that if EC2 is stopped, terminated or fails outside of AWS’ control via an internet outage, or the failure of your software, equipment or technology, then they are not responsible for compensating you. Additionally, if you are suspended, you will not receive service credits either. 

In summary, this is what an SLA looks like in context with one of the most commonly used services. You can expect to see the same categories of information for every SLA that AWS offers. The important thing is that you read the definitions for each service and understand how they’re defining availability for that service. That’s it for this one - see you next time!