After having gone through the definitions and compensation in service level agreements, we now come to the final – but no less important – section in such contracts: the limitations and exceptions. The definitions sections establishes the service levels that cloud providers are willing to offer; the compensation section determines what kind of compensation they will offer when something goes wrong.

The last large section of any SLA is the limitations section, which defines what are the situations when something does go wrong, but for which the service provider can’t be blamed and, therefore, won’t offer any kind of compensation. While it may not seem as important as the others, and is usually filled with legal language, this part of the SLA needs to be looked at as carefully as any of the others.

Follow the rules, or else

One of the main things that any limitations clause will include is a “in case of misuse” item or paragraph. What this means is that if you for some reason violate their terms of service – usually done by abusing services, such as sending mass emails from cloud mail providers – they reserve the right to cancel your subscription immediately, without warning or compensation.

Another important part of the limitations, that is also associated with following rules, is that providers refrain from assuming responsibility for any unavailability or downtime that is caused directly by any action (or inaction) of the user. This is once again related to the misuse of services. If you are employing cloud servers, and, for some reason, install software that causes the servers to hang, this downtime can’t be blamed on the provider. The same goes for downtime that is caused by some inaction, such as failing to upgrade some software or configuring something on that server.

Understanding these rules is fundamental to properly operating with any provider, especially when related to the misuse or abuse of the services. A cloud server, for instance, is meant to host applications and services, so it can be very hard for a cloud provider to define what exactly constitutes a misuse of their services. This, in part, is why they leave the misuse clauses as generic as possible, and try to be as accommodating as possible to their users. On the other hand, they expect common sense from their users. If they start getting complaints about, for instance, servers you are using, they are likely to terminate your account.

Defining boundaries

The second great issue surrounding the limitations section of an SLA is the definition of the boundaries of the service you are hiring. Just as the definitions section delineates the limits of the services that will be offered, the limitations clause states that anything that happens outside of these limits will not fall under the responsibility of the provider. This makes the understanding of the boundaries fundamental.

For cloud infrastructure-as-a-service providers, the limitations are the cloud server instances themselves, as well as the internal networks of the providers themselves. They don’t take responsibility for anything outside that, either related to the external network, or to whatever software you happen to install on your server, including any operating system you choose to run on your VMs. For platform-as-a-service providers, the boundaries are related to the functionality of the platform, that is, the basic operations provided, but not to any applications you run on top of the platform. Finally, for software-as-a-service providers, the boundaries relate to the service or application being offered. As we go higher on the cloud stack, the boundaries increase: to offer guarantees on the availability of a platform, providers must ensure that the underlying infrastructure is operating fully; the same goes for software providers.

The final points of interest on limitations clauses are elements that are specific to certain providers. Amazon EC2 instances, for example, have an availability clause that doesn’t cover individual instances, but only regions as a whole. This is due to the fact that EC2 instances aren’t persistent, but rather can go offline and come back up at any moment. Looking for these specific clauses becomes even more important when working with multiple providers.

On the next post on this series, we’ll do a side by side comparison of the SLAs of some of the major providers, highlighting items of interest and points of attention on each one.