AWS Service Level Agreement – What you need to know

When looking to host your IT infrastructure and applications in the AWS cloud, service level agreements are an important consideration—you need to ask yourself a number of questions before evaluating the AWS SLA, including:

• What is the uptime guarantee of the AWS service or services that you wish to consume?
• What response time can I expect from the provider in the event of a problem with the service?
• How much downtime can I tolerate from the service for my applications?
• How would my business be affected by any service outages?
• What penalties does the cloud provider face for failing to meet the guarantees?

Amazon Web Services has separate service level agreements for each of the many services that they offer—at the time of writing, there were 121 separate SLAs published on the AWS website (which has risen to 173, as of April 2023). 

This means it’s important to understand the differing SLAs for each service you are consuming, how these fit with the service level objectives you have defined for your application, and how these will impact the overall SLA that you are able to offer to your customers or users for your applications running in AWS.

In this article, we explore the AWS SLAs for some of the most commonly used services, including EC2, RDS, EBS, ECS, Fargate and S3 to give you an idea of what’s on offer. However, this is just a guide and should not be considered a substitute for reading the actual SLAs for the services you plan to consume.

Amazon EC2 SLA

The service level agreement for Amazon EC2 (available here) covers several compute services, including:

• EC2 (Elastic Compute Cloud)
• EBS (Elastic Block Store)
• ECS (Elastic Container Service)
• AWS Fargate for ECS and EKS

Amazon EC2 Uptime SLA

Amazon’s availability SLA guarantees that services included in the agreement will be available for 99.99% in any given region in any monthly billing cycle. This equates to 4.38 minutes of permitted downtime per month. 

This is a strong SLA—if you have an application that needs to run on EC2 and it requires 100% uptime, then the application should ideally be hosted across multiple regions. 

It should be noted that the AWS uptime SLA for single EC2 instances is only 90%, allowing for up to 73.05 hours of downtime per month. So, at the very least, an application should be hosted on multiple EC2 instances in at least two availability zones in order to be covered by the 99.99% uptime SLA. (Instances deployed in a single availability zone are not covered by the SLA.)

AWS EC2 Service Credits

AWS does offer service credits for failure to meet the uptime SLA, but it is important to note that these are not automatically applied. In order to receive service credits for downtime, AWS customers must raise a claim for credit by opening a case in the AWS support centre (with the words ‘SLA Credit Request’ in the subject line).

You’ll need to provide details of the dates and times of the outage or outages that you are claiming credit for, backed up with logs and resource IDs for the affected services. If service credits are available for the outage, they are normally applied as a credit against any future invoices for the same service.

For EC2 (and associated services) the available credits are as follows:

Monthly Uptime Percentage	Service Credit Percentage	Downtime Per Month
Less than 99.99% but equal to or greater than 99.0%	10%	4.38 minutes to 7.31 hours
Less than 99.0% but equal to or greater than 95.0%	30%	7.31 hours to 36.53 hours
Less than 95.0%	100%	More than 36.53 hours

Amazon RDS Service Level Agreement

• MySQL
• MariaDB
• Oracle
• PostgreSQL
• SQL Server

Amazon RDS Uptime SLA

For all RDS instances hosted in multiple availability zones (with the ‘Multi AZ’ parameter set to ‘True’), Amazon guarantees 99.5% uptime in any monthly billing cycle.

This allows for up to 3.65 hours of downtime per month. For applications that cannot tolerate this level of downtime, customers should consider hosting their databases across multiple regions, or using a different database service such as Amazon Aurora, which has a 99.99% uptime SLA.

Amazon RDS Service Credits

As with EC2 and all AWS services, service credits must be applied for using the procedure described above. The service credits for RDS are as follows:

Monthly Uptime Percentage	Service Credit Percentage	Downtime Per Month
Less than 99.95% but equal to or greater than 99.0%	10%	3.65 hours to 7.31 hours
Less than 99.0% but equal to or greater than 95.0%	25%	7.31 hours to 36.53 hours
Less than 95.0%	100%	More than 36.53 hours

Amazon S3 Service Level Agreement

The Amazon S3 Service Level Agreement (available here) covers:

• S3 (Simple Storage Service) 
• S3 Glacier

Amazon S3 Uptime SLA

The uptime SLA differs by S3 service types, and guaranteed uptime ranges from 99.9% to 99%.

All S3 services have 99.9% guaranteed uptime with the exception of the following services, which are guaranteed for 99% uptime:

• S3 Intelligent-Tiering
• S3 Standard-Infrequent Access
• S3 One Zone-Infrequent Access

AWS S3 Service Credits

The service credits available for S3 services (excluding those listed above) are as follows:

Monthly Uptime Percentage	Service Credit Percentage	Downtime Per Month
Less than 99.9% but greater than or equal to 99.0%	10%	43.83 minutes to 7.31 hours
Less than 99.0% but greater than or equal to 95.0%	25%	7.31 hours to 36.53 hours
Less than 95.0%	100%	More than 36.53 hours

The service credits available for S3 Intelligent-Tiering, S3 Standard-Infrequent Access and S3 One Zone-Infrequent Access are as follows:

Monthly Uptime Percentage	Service Credit Percentage	Downtime Per Month
Less than 99.0% but greater than or equal to 98.0%	10%	7.31 hours to 14.61 hours
Less than 98.0% but greater than or equal to 95.0%	25%	14.61 hours to 36.53 hours
Less than 95.0%	100%	More than 36.53 hours

Amazon S3 also offers a guarantee for ‘durability’. You can read more about it in my S3 Guide post.

AWS Support Response Times

AWS support response times are separate from the individual service uptime SLAs. Response times vary between the three available AWS support plans:

• Developer


• Business


• Enterprise

For easy comparison, I’ve listed the available response times and associated support fees in the table below. Don’t expect a 15-minute support response if you are only paying for a business support plan! That said, in my experience, AWS support is both rapid and effective.

Case Severity	Developer	Business	Enterprise
General Guidance	<24 business hours	<24 hours	<24 hours
System Impaired	<12 business hours	<12 hours	<12 hours
Production System Impaired	—	<4 hours	<4 hours
Production System Down	—	<1 hour	<1 hour
Business Critical System Down	—	—	<15 minutes
Pricing	Greater of $29 / month*** – or – 3% of monthly AWS usage	Greater of $100 / month*** – or – 10% of monthly AWS usage for the first $0–$10K 7% of monthly AWS usage from $10K–$80K 5% of monthly AWS usage from $80K–$250K 3% of monthly AWS usage over $250K	Greater of $15,000 – or – 10% of monthly AWS usage for the first $0–$150K 7% of monthly AWS usage from $150K–$500K 5% of monthly AWS usage from $500K–$1M 3% of monthly AWS usage over $1M

AWS Customer Data Privacy

Another often overlooked aspect of service level agreements is data ownership and data privacy.  Entrusting all of your data to a third party is a big deal and something that should be thoroughly researched. Fortunately, AWS makes it incredibly easy to accomplish this by providing a comprehensive set of FAQs. 

In summary, your data remains your property at all times. AWS will never:

• Access your data or content
• Use your data or content for marketing or advertising purposes
• Move or replicate your content outside of the region you’ve elected to store it in*

*With the exception of some services that process data outside of the region you have selected. This applies to some machine learning services, for example, which process data elsewhere, so be sure to check the AWS service terms and conditions for any such services you are using.

As a customer, you are fully responsible for:

• Access: you control your AWS services and resources through users, groups permissions and credentials.
• Storage: you choose where your content is stored—in which region and on what type of type of storage.
• Security: AWS offers all the necessary tools to encrypt data in transit and at rest—it is the customer’s responsibility to select the appropriate tools for the type of content being stored.

AWS SLA Summary

There you have it. Some key things to look for and consider when trying to understand Amazon Web Services’ service level agreements. The key piece of advice I would offer is to not rely on service level agreements to guarantee the uptime of your applications.

The SLA offers some guidance on the levels of uptime that you can expect, but the service credits offered (assuming you remember to claim them) are likely to be insufficient towards compensating for any downtime experienced by your application, and the likely business consequences in terms of loss of productivity or potentially even loss of revenue.

AWS offers all of the tools and services you need to build a resilient, highly available and highly secure cloud-based infrastructure, but it is up to you as the customer to ensure that best practice is being followed, and that you are adhering to AWS Well-Architected principles and that you are fulfilling your responsibility under the AWS Shared Responsibility model:

It’s also important to ensure that you have good observability of your application infrastructure—if you don’t spot the service outages, you won’t be able to claim against the SLA so you could be missing out on credits. You need to be able to back up your claim with log files—so be sure that you know where to get these!

If this all seems a little daunting, Logicata is here to help and advise. Why not book a call with one of our AWS experts to discuss your specific circumstances?