 |
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 Service Level Agreement, including:
- What is the guaranteed uptime of the 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 for from the service for my applications?
- What will be the impact to my business of any service outages?
- What are the penalties on the cloud provider for failing to meet the guarantees?
Amazon Web Services have 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, so 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 SLAs for some of the most commonly used AWS services, including EC2, RDS, EBS, ECS, Fargate and S3 to to give you a flavour of what’s on offer, but this is just a guide and should not be considered as a substitute for reading the actual SLAs for the services that you plan to consume.
Amazon EC2 SLA
The Service Level Agreement for Amazon EC2 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 guarantees that any services included in the SLA will be available for 99.99% in any given region in any monthly billing cycle. 99.99% uptime 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 really the application should be hosted across multiple regions.
It should be noted that the 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, and providing 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 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
The Amazon RDS Service Level Agreement covers multi Availability Zone deployments of Relational Database Service instances for the following database engines hosted on RDS:
- 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 data base 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 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’ which you can read more about in my S3 Guide post.
AWS Support Response Times
AWS Support Response times are separate to the individual service uptime SLAs. Response times vary between the 3 available AWS support plans – Developer, Business and Enterprise. For ease of comparison I’ve listed out 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! Although 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 like all things with AWS they make it very easy to do so, with a full set of FAQs published here.
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 have 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 – be sure to check the terms and conditions for any such services you are using).
As a customer, you are fully responsible for:
- Access to AWS services and resources through users, groups permissions and credentials that you control.
- Storage – you choose where your content is stored – in which region and on what type of type of storage.
- Security – AWS offer 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
So there you have some key things to look for and consider when trying to understand the Amazon Web Services Service Level Agreements. The key piece of advice I would offer is not to be relying 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 go little way 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 practise is being followed, 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 are here to help and advise. Why not book a call with one of our AWS experts to discuss your specific circumstances?
