AWS Service Level Agreement

What is an SLA?

The SLA, or Service Level Agreement, is the contractual quality and performance level of a service or technical infrastructure. In the case of AWS, a cloud provider, we are indeed talking about a service, since we operate in the IaaS (Infrastructure as a Service) world.

The SLA must first define what service we are talking about, and the performance criteria the provider commits to. This can include response time, guaranteed functionality, complete service availability, etc.

SLA at AWS

Below, we will review some AWS services that have an SLA at the time of writing this article. This list is of course not exhaustive.

Amazon Route 53: AWS DNS SLA

The AWS DNS service, Amazon Route 53, has a service availability SLA at the highest possible level. Indeed, there is a 100% availability commitment on the service, which is stated as "Amazon Route 53 will not fail to respond to your DNS queries during a monthly billing cycle." Why mention a month? Because AWS commits, in case of a proven failure, to reimburse you in the form of credits on that billing cycle.

Excerpt from the SLA page – Amazon Route 53 as of January 10, 2019

Amazon EC2: AWS VM SLA

AWS's flagship service, Amazon EC2 and Amazon EBS respectively provide the managed hypervisor to run your Virtual Machines (aka EC2 instances) and virtualized storage Amazon Elastic Block Store (EBS). The SLA has been extended to Amazon Elastic Container Service (ECS) and AWS Fargate (two Docker container-related services) since 2018.

The service SLA, with Amazon Web Services' commitment, is at least 99.95% monthly — less than 22 minutes of downtime.

If unavailability is proven between 99.90% and 99.99%, AWS commits to a 10% discount in AWS credits on the EC2 service, and below 99.0% availability, AWS offers a 30% credit discount.

It is important to note that the SLA is tied to the "Region Unavailable" state. If you don't already know, a region is a set of multiple (2+) Availability Zones, but within the SLA framework, AWS specifies that the "Region Unavailable" state applies if more than one Availability Zone where you run EC2 instances is unavailable — meaning instances no longer have internet access.

EBS unavailability is confirmed when storage volumes no longer generate I/O with a non-empty queue.

Amazon RDS: AWS Managed Database SLA

Amazon RDS is the AWS managed database service. It currently supports MySQL, Oracle, PostgreSQL, MariaDB, Microsoft SQL Server, and AuroraDB. However, the SLA offered by AWS only covers Multi-AZ instances (i.e., with a standby server in another Availability Zone) for SQL engines: Oracle, MariaDB, MySQL & PostgreSQL. This SLA is 99.95% service availability. Unavailability is confirmed when all connection requests fail for one minute on the Multi-AZ RDS instance.

AWS commitment for RDS and credit reimbursement as of January 10, 2019

Amazon S3: AWS Object Storage SLA

Amazon S3 is the object storage service. It is one of AWS's oldest services and has a data durability of 99.999999999% in standard storage mode. However, the SLA concerns the availability of access to stored data via the AWS API. The Amazon S3 SLA is therefore calculated based on error counting or API unavailability over 5-minute periods.

AWS's commitment is to maintain availability above 99.9% monthly, which represents less than 43 minutes and 12 seconds.

If AWS cannot ensure this availability in the region where your S3 bucket is stored, then a 10% discount on S3 storage costs will be returned as credits, and below 99.0%, the credit discount will be 25% of the Amazon S3 service cost.

Since January 2019, these rules have been extended to Amazon Elastic File System (EFS) with the same commitments as for S3. Amazon EFS is a managed simple file storage system (AWS manages the infrastructure for you).

Amazon CloudFront: AWS CDN SLA

Amazon CloudFront is the AWS CDN service. With several dozen "Edge Locations," this service caches web requests according to your chosen behaviors and URL patterns. It enables accelerated data delivery and loading on websites and mobile applications, especially when media content is being transmitted.

AWS commits to maintaining overall service availability above 99.9% monthly (identical to Amazon S3). The discounts applied to the service in case of proven failure, also based on the frequency of data access errors, are identical to those of Amazon S3.

AWS Shield: Anti-DDoS Protection Service SLA

Launched at re:Invent 2016, AWS Shield is the official AWS anti-DDoS protection. The service uses and protects other services Amazon CloudFront and Amazon Route 53, and its SLA, measured over 24-hour periods, is directly tied to the SLAs of the previously mentioned products. This SLA can be understood as a simple reminder that using AWS Shield in front of Amazon CloudFront or Amazon Route 53 does not modify their SLA.

Amazon API Gateway: API Management SLA

Since January 2019, AWS commits to ensuring 99.95% monthly availability of the Amazon API Gateway service. This fully managed service facilitates the management, monitoring, and security of APIs of any size. In case of service disruption, the allocated credit is identical to RDS: 10% discount between 99.0% and 99.95% and 25% discount for monthly availability below 99.0%.

Calculating the SLA of an AWS Infrastructure

Let's start with a fairly standard Web App infrastructure. It consists of several front-end application servers — here EC2 C4.Large instances — running the same code on each instance, with multi-Availability Zone redundancy. The database is a MySQL on RDS in Multi-AZ (Standby Instance). Static site elements are stored on S3. CloudFront is placed in front of the Load Balancer, caching static elements from S3 and rerouting other requests to the Load Balancer. Route 53 manages the site's domain name.

Web Infrastructure: Amazon Route 53, CloudFront, S3, EC2 and RDS

Here is how we can calculate the SLA of this infrastructure. Of course, this applies in the case of a failure of all AWS services used in a region, and within the SLA framework of each service. In this case, the infrastructure cannot claim a higher SLA without additional redundancy.

RDS Multi-AZ MySQL: SLA of 99.95%
EC2: SLA of 99.95%
CloudFront: SLA of 99.9%
S3: SLA of 99.9%
Route 53: 100.0%

The raw infrastructure SLA will be:

99.95% x 99.95% x 99.9% x 99.9% x 100% = 99.70%

If we consider that S3 unavailability is not critical for maintaining web infrastructure availability (for example, an API) and that we handle potential CloudFront downtime via Route 53 by pointing to the Load Balancer as a backup, we gain 0.2% SLA simply by modifying and optimizing the infrastructure design:

99.95% x 99.95% x 100% = 99.90%