What is Azure Service Level Agreement (SLA)?
The SLA ensures that, when you send two or more role instances for each role, access to your cloud service will be maintained not less than 99.95 percent of the time. Additionally, identification and recorrection activity will be started 99.9 percent of the time when a role instance’s procedure isn’t running.
A service-level agreement (SLA) is a commitment between a service provider and a client. … As an example, Internet service providers and telcos will commonly include service level agreements within the terms of their contracts with customers to define the level(s) of service being sold in plain language terms.
Service level agreement (SLA) and its purpose. A service level agreement or SLA is a formal document that defines a working relationship between parties for aservice contract. It is generally more applicable to businesses than to consumers and involves one or more end user parties and a service provider.
10 tips for mastering Microsoft cloud SLAs
- Read the contract and all the supporting documentation
This may seem obvious, but many people don’t actually read the contract, just like they skim over End User License Agreements. “I run into an amazing number of people who zip through a PowerPoint and then sign the contract,” says Paul DeGroot, who works as a consultant at Pica Communications advising clients on Microsoft licensing. If you don’t understand something in the contract after analyzing it, ask for help. The key to understanding your SLA is reading it.
Paul DeGroot, consultant at Pica Communications
Contracts can be confusing though. DeGroot says sometimes relevant information is in a supporting document. SLA parameters can be outlined in one section of a document but the contract can be subject to terms that are defined in other literature. Make sure to read the entire contract, including any supporting documents.
- SLA breaches must be reported
Some providers will automatically credit customers when there is an outage, others will not. It is imperative that customers report any outages they believe breach the SLA. DeGroot has run into instances where customers experienced a multi-day outage and were sure their bill would simply reflect the event with a credit. But if you don’t document and report it, you don’t have any way to prove you experienced downtime. If you have a problem, record it, inform your provider immediately and file a claim for the breach of an SLA.
Microsoft requires that customers submit an SLA breach claim to customer support by the end of the calendar month after the event has happened. (So for example if an incident happens in mid February, the customer has until the end of March to report it.) The claim must include: a detailed description of the incident; duration of incident; number of users or sites impacted; description of your attempts to remedy the situation.
- An SLA with 99.9% uptime still allows for 8 hours of downtime per year
Many of Microsoft’s services come with a 99.9% uptime guarantee (three-nines). That sounds good. But being up for 99.9% of the year still allows for 8 hours and 45 minutes of downtime each year with no breach of the SLA. How would you feel if your workload is unavailable for 8 hours one day? This uptime calculator can help users predict how much downtime they should expect from their provider based on their SLA uptime guarantee.
- Each service can have its own SLA
Each individual service can have its own SLA uptime guarantee. For example, Microsoft Azure VMs have a 99.95% uptime guarantee (if deployed across two Availability Sets; more on that later) and the SQL database has a 99.9% uptime guarantee. Most Microsoft Online SaaS products come with a 99.9% uptime guarantee too. But 99.9% uptime allows for up to 43 minutes of downtime to occur in a month without breaching the SLA.
As Troy Hunt, a Microsoft expert blogger points out in this piece, those downtime events do not have to occur at the same time for the provider’s SLA to be intact. So, for example, if you have a system that relies on Azure VMs, a SQL database and Azure storage, then on the first day of a month an Azure VM could go down for 21 minutes and bring your workload down. The next day Azure SQL could go down for another 42 minutes and bring the application down. Both of those would still be within the terms of the SLA. For more on this, blogger Brent Stineman explores how to calculate aggregate SLAs across multiple services here.
- VMs may need to be deployed across multiple instances for the SLA to kick in
One of the mantras of cloud computing is prepare for failure. And in fact some cloud services, including Microsoft and AWS, mandate that customers architect their systems to be prepared for failure to meet the terms of the SLA. AWS, for example requires that virtual machines be deployed across multiple Availability Zones (which are different data centers in AWS’s cloud) and both copies of the VM must be unavailable for the SLA to be breached. Microsoft uses the term Availability Sets instead of Availability Zones, but it’s the same idea. Customers must heed the best-practice architectures to ensure their systems comply with the terms of the SLA.