Cloud computing terms of service

Overview

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.

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

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.

• Data Preservation. If a subscriber’s access to cloud services is terminated “for cause,” i.e., because the subscriber has violated the clouds' acceptable use policy or for nonpayment, most providers state that they have no obligation to preserve any subscriber data remaining in cloud storage. Further, after a subscriber voluntarily stops using a cloud, providers generally state that they will not intentionally erase the subscriber’s data for a period of 30 days. Some providers preserve only a snapshot of subscriber data, or recommend that subscribers: (1) backup their data outside that provider’s cloud inside another provider’s cloud, or (2) back it up locally.

• Legal Care of Subscriber Information. Generally, providers promise not to sell, license, or disclose subscriber data except in response to legal requests. Providers, however, usually reserve the right to monitor subscriber actions in a cloud, and they may even demand a copy of subscriber software to assist in that monitoring.

Limitations

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.

• Force majeure events. Providers generally disclaim all responsibility for events outside their realistic control. Examples include power failures, natural disasters, and failures in network connectivity between subscribers and providers.

• 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.

• Security. Providers generally assert that they are not responsible for security, i.e., unauthorized modification or disclosure of subscriber data, or for service interruptions caused by malicious activity. Generally, SLAs are explicit about placing security risks on subscribers. In some cases, providers promise to use best efforts to protect subscriber data, but disclaim security responsibility for data breach, data loss, or service interruptions by limiting remedies to service credits for failure to meet availability promises. Further, it is unclear how easy it would be for a subscriber to determine that a service disruption was maliciously induced versus induction from another source.

• Service API Changes. Providers generally reserve the right to change or delete service APIs at any time.

Obligations

Generally, subscribers must agree to three key obligations:

• Acceptable Use Polices. Subscribers generally must agree to refrain from storing illegal content, such as child pornography, and from conducting illegal activities such as: (1) gambling, (2) sending spam, (3) conducting security attacks (e.g., denial of service or hacking), (4) distributing spyware, (5) intrusive monitoring, and (6) attempting to subvert cloud system infrastructures. Acceptable use policies vary among providers.

• Licensed Software. All providers state that third-party software running in their clouds must conform to the software’s license terms. In some cases, providers bundle such software and include monitoring to ensure that license restrictions are enforced.

• Timely Payments. Cloud service costs are generally incurred gradually over a billing period, with the fee due to the provider at the period’s end. Failure to pay, after a grace period, usually subjects a subscriber to suspension or termination “for cause” which can result in loss of subscriber data.

Source

• NIST Special Publication 800-145, at 3-1 to 3-3.

Recommendations

• 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.