Lets start with a basic scenario where there is a sudden peak in the demand for an application service as the amount of clients’ requests increase. This event leads to a direct and immediate impact on the load placed on the web servers that host the service. In the traditional world, the number of servers is fixed, therefore an overload adversely affects the application performance and the service may slow down or even be terminated. The IT team would want to restore the environment functionality and bring the service up as soon as possible. The immediate impact of such an event on the business can be devastating. Starting with this simple understanding, we can move into the world of cloud computing use including resources consumption, while relating to the key differences between the traditional data center and today’s cloud technologies.
There is a common perception that cloud storage should not really worry you because it is very cheap and available at any time. But is that really true? I often hear AWS consumers say that AWS storage means S3 (Simple Storage Service) – this is true but it is not the whole truth. There are actually 4 different AWS cloud storage models. We’ll get back to those but first let’s focus on the importance of understanding your AWS S3 footprint.
The Cloud Service Level Agreement (SLA) discussion puts penalties and compensations on the table. Can we say that the compensation method the customer expects is the same as the Software as a Service (SaaS) vendor’s SLA provides?
A while ago, I experienced issues while starting up a specific instance on Amazon AWS cloud. I’m still not sure why, but the instance entered an endless restart loop. All the application deployment work (installation and configuration of a service) we did on it for about two weeks just went down the drain. Discussion with the Amazon AWS support team ended with an escalation of the support request to their head of support.
Take a look at the following paragraphs copied from the Amazon AWS EC2 SLA –