Fandom

The IT Law Wiki

Cloud computing terms of service

32,181pages on
this wiki
Add New Page
Talk0 Share

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.

Overview Edit

Cloud computing terms of service are determined by a legally binding agreement between the subscriber and the cloud provider often contained in two parts: (1) a service agreement, and (2) a Service Level Agreement (SLA). Generally, the service agreement is a legal document specifying the rules of the legal contract between a subscriber and provider, and the SLA is a shorter document stating the technical performance promises made by a provider including remedies for performance failures. For simplicity, the following discussion refers to the combination of these two documents as an SLA.[1]

Although the self-service aspect of a cloud implies that a subscriber either (1) accepts a provider’s pricing and SLA, or (2) finds a provider with more acceptable terms, potential subscribers anticipating heavy use of cloud resources may be able to negotiate more favorable terms. For the typical subscriber, however, a cloud’s pricing policy and SLA are nonnegotiable.

Published SLAs between subscribers and providers can typically be terminated at any time by either party, either “for cause” such as a subscriber’s violation of a cloud’s acceptable use policies, or for failure of a subscriber to pay in a timely manner. Further, an agreement can be terminated for no reason at all. Subscribers should analyze provider termination and data retention policies.

Provider promises, including explicit statements regarding limitations, are codified in their SLAs. A provider’s SLA has three basic parts: (1) a collection of promises made to subscribers, (2) a collection of promises explicitly not made to subscribers, i.e., limitations, and (3) a set of obligations that subscribers must accept.

Promises Edit

Generally, cloud providers make four key promises to subscribers:

  • Availability. Providers typically advertise availability promises as uptime percentages ranging from 99.5%-100%. These are strong claims, and care is needed to understand how these percentages are calculated. Often, the percentage applies to the number of time intervals within a billing cycle (or longer periods such as a year) in which services are not “up” for the entire interval. Examples of time intervals used by prominent providers are 5 minutes, 15 minutes, and 1 hour. For example, if a provider specifies an availability interval of 15 minutes, and the service is not functional for 14 minutes, 100% availability is preserved using this metric. Generally, the definition of “up” is intuitively defined as service responsiveness, but in some cases, multiple cloud subsystems must fail before the service is judged as unavailable. Providers may also limit availability promises if failures are specific to particular functions or Virtual Machines (VMs).
  • Remedies for Failure to Perform. If a provider fails to give the promised availability, a provider should compensate subscribers in good faith with a service credit for future use of cloud services. Service credits can be computed in different ways, but are usually determined by how long the service was unavailable within a specific billing period. Service credits are generally capped not to exceed a percentage of a subscriber’s costs in the billing period in which downtime occurred. Typical caps range from 10% to 100% of a subscriber’s current costs, depending on the provider. Responsibility for obtaining a service credit is generally placed on the subscriber, who must provide timely information about the nature of the outage and the time length of the outage. It is unclear whether a provider will voluntarily inform a subscriber of a service disruption.

Limitations Edit

Generally, provider policies include five key limitations:

  • Scheduled Outages. If a provider announces a scheduled service outage, the outage does not count as failure to perform. For some providers, outages must be announced in advance, or must be bounded in duration.
  • SLA Changes. Providers generally reserve the right to change the terms of the SLA at any time, and to change pricing with limited advanced notice. For standard SLA changes, notice is generally given by a provider by posting the change to a Web site. It is then the subscriber’s responsibility to periodically check the Web site for changes. Changes may take effect immediately or after a delay of several weeks. For changes that affect an individual subscriber’s account, notice may be delivered via email or a delivery service.
  • Service API Changes. Providers generally reserve the right to change or delete service APIs at any time.

Obligations Edit

Generally, subscribers must agree to three key obligations:

References Edit

  1. Some cloud providers historically have not provided SLAs, or have provided them only to large or persistent users. An SLA is extremely important to understand a cloud provider’s promises.

Source Edit

Recommendations Edit

  • Terminology. Subscribers should pay close attention to the terms that are used in SLAs. Common terms may be redefined by a cloud provider in ways that are specific to that provider's offerings.
  • Remedies. Unless a specific SLA has been negotiated with a provider, remedies for any failures are likely to be extremely limited; subscribers may wish to formulate remedies that are commensurate with damage that might be sustained.
  • Compliance. Subscribers should carefully assess whether the SLA specifies compliance with appropriate laws and regulations governing subscriber data.
  • Security, Criticality, and Backup. Subscribers should carefully examine the SLA for any disclaimers relating to security or critical processing, and should also search for any comment on whether the provider recommends independent backup of data stored in their cloud.
  • Negotiated SLA. If the terms of the default SLA do not address all subscriber needs, the subscriber should discuss modifications of the SLA with the provider prior to use.

References Edit

Also on Fandom

Random Wiki