Looking at the EC2 SLA in Depth


Course Introduction
Amazon CloudWatch
AWS Config
What is AWS Config?
AWS Control Tower
AWS Control Tower
PREVIEW19m 56s
AWS Resource Access Manager
AWS Management
AWS Service Catalog
PREVIEW10m 34s
AWS Trusted Advisor Best Practices
AWS Health Dashboard
AWS Data Visualization
Finding Compliance Data with AWS Artifact
Observability in AWS
Start course
6h 2m

This section of the AWS Certified Solutions Architect - Professional learning path introduces the AWS management and governance services relevant to the AWS Certified Solutions Architect - Professional exam. These services are used to help you audit, monitor, and evaluate your AWS infrastructure and resources and form a core component of resilient and performant architectures. 

Want more? Try a Lab Playground or do a Lab Challenge!

Learning Objectives

  • Understand the benefits of using AWS CloudWatch and audit logs to manage your infrastructure
  • Learn how to record and track API requests using AWS CloudTrail
  • Learn what AWS Config is and its components
  • Manage multi-account environments with AWS Organizations and Control Tower
  • Learn how to carry out logging with CloudWatch, CloudTrail, CloudFront, and VPC Flow Logs
  • Learn about AWS data transformation tools such as AWS Glue and data visualization services like Amazon Athena and QuickSight
  • Learn how AWS CloudFormation can be used to represent your infrastructure as code (IaC)
  • Understand SLAs in AWS

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, 

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
Learning Paths

Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.