- About This Book
- Trying to Define the Cloud
- Moving to AWS
- Essential Characteristics of AWS Cloud Computing
- Operational Benefits of AWS
- Cloud Provider Limitations
- Data Security at AWS
- Network Security at AWS
- Application Security at AWS
- Compliance in the AWS Cloud
- Migrating Applications
- The Well-Architected Framework
- The Well-Architected Tool
- In Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Cloud Provider Limitations
Each cloud provider has a published SLA that specifies what services are provided and at what specific operational level. All public cloud providers make promises about how they will handle security, compliance, and overall operations and how their methodology will be contained in the cloud provider’s SLA. The challenge is to live up to that agreement. In the SLA, there will be details about acceptable outage time and the responsibility of the cloud provider when outages occur. There also will be statements about not being responsible for events outside the cloud provider’s control. Another common term typically used in the SLA is “best effort” or “commercially reasonable effort.”
Regardless of the cloud model, the cloud provider is responsible for overall service operation and deployment, service orchestration, the overall management of the cloud, the security of the cloud components, and maintenance of customer privacy. The responsibility of how each customer, the cloud consumer, is to carry out business with the cloud provider will also be described in some detail in the SLA. Each cloud consumer must fully understand what each cloud service offered provides; this is exactly what the cloud service will and will not do.
The reality is that every public cloud provider will not have an SLA that you will like, and the stark reality is that their best effort is the best they can do. This might seem a little harsh, but it’s reality; according to AWS, “everything fails all the time.” What happens when a key component of your application hosted in the AWS cloud fails? Is it a disaster, or is it manageable? Is it acceptable to expect AWS failures from time to time? It’s a reality; AWS is 100% right; everything fails.
Operating in the public cloud means that you must design your hosted application to be able to continue operating even if compute and storage failures occur. That’s our responsibility.
All public cloud providers really have the same SLA; here it is, summarized in nine short words: “we are sorry; we will give you a credit.” This SLA summary applies to every public cloud provider. Here’s another reality check; if you’re down, you will have to prove that you were actually down by providing network traces and appropriate documentation that leaves no doubt that you were down because of an AWS cloud issue.
Oh, and here’s another small detail to be aware of: if you didn’t build redundancy into your application design, don’t bother calling for a credit. Application designs that have a single instance hosting the application with no failover or high-availability design parameters have no SLA. AWS expects you to be serious about your application design; we need to understand and use the tools in the AWS toolbox to ensure that your SLA for availability and performance is achieved.
Not every service at AWS even has a defined SLA; there are more than 100 services and only 8 defined SLAs. Remember: all managed services—in fact, all services—are built from the resources found in Table 1-2.
Table 1-2 SLAs at AWS
AWS Service |
SLA Summary |
|---|---|
CloudFront |
99.9% during any monthly billing cycle |
DynamoDB |
Monthly uptime percentage of 99.999% for global tables, or 99.99% for regular tables |
EC2 instances (includes elastic container service [ECS] and EBS volumes) |
Monthly uptime percentage of at least 99.99% |
RDS databases |
Monthly uptime percentage of at least 99.95% for multi-AZ instances |
Route 53 DNS service |
Commercially reasonable efforts to make Route 53 100% available during a monthly billing cycle |
S3; S3 Glacier object storage |
The number of errors calculated during each 5-minute period subtracted from 100% |
Lambda functions |
Monthly uptime percentage of 99.95% during any monthly billing cycle |
AWS Shield (Advanced) |
Any failure of service commitments provided by CloudFront or Route 53 when being protected by AWS Shield Advanced distributed denial of service (DDoS) protection |