1. Home
  2. Training Library
  3. Designing for Disaster Recovery & High availability in AWS - Level 2

Looking at the EC2 SLA in Depth

Start course
Difficulty
Intermediate
Duration
1h
Students
5
Description

This course covers the core learning objective to meet the requirements of the 'Designing for disaster recovery & high availability in AWS - Level 2' skill

Learning Objectives:

  • Analyze the amount of resources required to implement a fault-tolerant architecture across multiple AWS availability Zones
  • Evaluate an effective AWS disaster recovery strategy to meet specific business requirements
  • Understand SLA for AWS services to ensure the high availability of a given AWS solution
  • Analyze which AWS services can be leveraged to implement a decoupled solution
Transcript

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!

About the Author
Students
225572
Labs
1
Courses
215
Learning Paths
175

Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.

To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.

Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.

He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.

In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.

Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.