This chapter covers Azure Service Level Agreements (SLAs)—the contractual uptime guarantees Microsoft makes for its cloud services. Understanding SLAs is critical for the AZ-900 exam because questions on SLA components, composite SLAs, and credit calculations appear regularly in the 'Cloud Concepts' domain, which carries roughly 25-30% of the exam weight. You will learn what an SLA guarantees, what it excludes, how to calculate composite availability, and how to interpret SLA credits. By the end, you'll be able to answer any AZ-900 question about SLAs with confidence.
Jump to a section
Imagine you run a factory that needs electricity 24/7. You sign a contract with a power company that promises electricity 99.99% of the time. This means they guarantee your factory will have power for all but about 52 minutes a year. If the power goes out more than that, the company gives you a credit on your next bill—not cash, just a discount. However, the fine print says they don't cover outages caused by storms, grid failures beyond their control, or scheduled maintenance (they'll tell you in advance). Also, if your factory has old wiring that causes a short, that's your problem. The guarantee only applies if you have a backup generator? No, but if you want the highest guarantee (like 99.999%), you must install dual power feeds and a backup generator at your own cost. And the credit you get is small—maybe 10% of your bill for a day of outage—because the guarantee isn't insurance; it's a service commitment. This is exactly how Azure SLAs work: Microsoft promises a certain uptime percentage for each service, offers credits if they fail, excludes certain events (force majeure, planned maintenance, customer misconfiguration), and requires you to meet specific architecture requirements (like deploying across availability zones) to qualify for the highest tiers. You don't get money back—you get service credits toward future bills. And the credit percentage increases with the severity of the outage, but never covers 100% of your costs.
What is an SLA and Why Does Azure Have Them?
A Service Level Agreement (SLA) is a formal contract between Microsoft (the service provider) and you (the customer) that defines the level of service you can expect. For Azure, the SLA specifies the guaranteed uptime percentage for each service, the conditions under which that guarantee applies, and the compensation (service credits) you receive if Microsoft fails to meet the guarantee. SLAs exist because cloud computing involves shared responsibility: Microsoft manages the infrastructure, but you must configure and deploy services correctly to achieve the promised availability. Without SLAs, you would have no recourse if a service goes down. On-premises, you own the entire stack, so there is no external SLA—you define your own availability targets. In the cloud, SLAs give you a measurable, contractual baseline that you can rely on for your own service commitments to your customers.
How SLAs Work – The Mechanism
Every Azure service has a published SLA page on the Azure website (e.g., https://azure.microsoft.com/en-us/support/legal/sla/). The SLA document lists the monthly uptime percentage for each service tier. For example, a single Virtual Machine (VM) using premium SSD managed disks has a 99.9% SLA. This means Microsoft guarantees that the VM will be available at least 99.9% of the time in a given month. 'Available' means the VM is running and accessible over the network. If the VM goes down, Microsoft starts measuring downtime. At the end of the month, they calculate the total downtime minutes. If the actual uptime falls below 99.9%, you are eligible for a service credit. The credit is a percentage of your monthly bill for that service, applied as a discount on a future invoice. For example, if uptime is between 99% and 99.9%, you get a 10% credit. If it's below 95%, you get a 25% credit. You never get cash—only credits. To claim a credit, you must submit a support request within a specified time (usually 60-90 days) with evidence of downtime.
Key Components of an SLA
Uptime Percentage: The guaranteed availability, typically expressed as 99.9%, 99.95%, 99.99%, or 99.999%. The more nines, the higher the guarantee and the more stringent the architecture requirements.
Downtime: Periods when the service is not available. The SLA defines what counts as downtime—usually unplanned outages, but excludes scheduled maintenance, customer actions, and force majeure events.
Service Credits: The compensation you receive if the SLA is not met. Credits are a percentage of your monthly fee, ranging from 10% to 100% depending on the severity of the outage.
Exclusions: Events that are not covered, such as:
- Planned maintenance (Microsoft gives advance notice) - Force majeure (natural disasters, war, etc.) - Customer misconfiguration (e.g., deleting a VM, changing network settings incorrectly) - Actions by third parties (e.g., ISP issues) - Services that are not covered by an SLA (some preview or free services) - Architecture Requirements: To qualify for a given SLA, you must deploy the service in a specific way. For example, to get a 99.95% SLA for VMs, you must deploy at least two VMs in an availability set. For 99.99%, you need VMs across availability zones.
Tiers and Pricing Models
Azure services offer multiple tiers with different SLA percentages. For instance, Azure SQL Database has:
Basic tier: 99.99% (but with limited features)
Standard tier: 99.99%
Premium tier: 99.99% (with faster performance)
Business Critical tier: 99.995%
Higher SLA percentages often require you to use more expensive tiers or deploy additional resources (like multiple replicas). The SLA is tied to the service tier you choose, not the price you pay. However, the cost of achieving a higher SLA is higher because you need redundant components.
Composite SLAs
When you combine multiple services in an application, the overall availability is the product of their individual SLAs. For example, if your app uses a web app (99.95% SLA) and a database (99.99% SLA), the composite SLA is 99.95% × 99.99% = 99.94%. This is lower than either individual SLA. To improve composite availability, you must add redundancy within each tier (e.g., multiple web apps behind a load balancer) or choose services with higher SLAs. The exam often asks you to calculate composite SLAs for simple two-service scenarios.
Comparing to On-Premises
On-premises, you have no SLA from a vendor—you are responsible for everything: hardware, power, cooling, network, and software. You set your own availability targets and must invest in redundant hardware, backup generators, and disaster recovery to meet them. The cost is high and upfront. Azure SLAs give you a contractual guarantee, but you still must architect your solution correctly to achieve high availability. The SLA is not a guarantee of performance—only availability. For example, a VM might be 'available' but running slowly due to resource contention. That is not an SLA violation.
Azure Portal and CLI Touchpoints
You can view SLA information for a service in the Azure portal by navigating to the service's overview page and looking for the 'SLA' link, or by visiting the official SLA page. There is no CLI command to retrieve SLA data directly, but you can use Azure Monitor to track uptime and set alerts for downtime. For example, you can create a metric alert that fires when a VM is unavailable for more than 5 minutes. The CLI command to create such an alert might look like:
az monitor metrics alert create --name "VM Down Alert" --resource-group myRG --scopes /subscriptions/.../virtualMachines/myVM --condition "Percentage CPU > 90" --description "Alert when VM is unresponsive"This is not directly about SLAs, but it helps you monitor availability. For SLA credit claims, you must use the Azure portal to submit a support request.
Concrete Business Scenario
Consider a retail company running an e-commerce website on Azure. They use a single VM to host the web server and a single Azure SQL Database for inventory. The VM has a 99.9% SLA, and the database has a 99.99% SLA. The composite SLA is 99.9% × 99.99% = 99.89%. This means the application could be down for about 0.11% of a month, or roughly 48 minutes. The company decides this is acceptable for their business. However, during a peak sale, an Azure region outage takes the VM down for 2 hours. At the end of the month, they calculate the VM uptime was 99.5%, which is below 99.9%. They submit a support request and receive a 10% credit on their VM bill. The database remained available, so no credit for that. The company learns that to improve availability, they should deploy two VMs in an availability set and use a load balancer, which would increase the VM SLA to 99.95%.
Identify Service SLA
First, determine the SLA for each Azure service you plan to use. Visit the official Azure SLA page (https://azure.microsoft.com/en-us/support/legal/sla/) and find the service you are using, such as Virtual Machines or Azure SQL Database. Note the uptime percentage for the specific tier you intend to deploy. For example, a single VM with premium managed disks has a 99.9% SLA. This step is crucial because the SLA varies by service and tier. You must also check the footnotes for architecture requirements—e.g., to get 99.95% for VMs, you need at least two VMs in an availability set. Ignoring these requirements means you won't qualify for the higher SLA even if you pay for the tier.
Architect for Required SLA
Based on the SLA you need, design your deployment to meet the architecture requirements. For example, if your application requires 99.99% uptime for VMs, you must deploy at least two VMs across availability zones (not just an availability set). This step involves configuring redundancy: adding multiple instances, load balancers, and possibly geo-redundancy. Azure provides best practice documentation for each service. You must also consider the composite SLA of all components. For instance, if you have a web app and a database, the overall availability is the product of their individual SLAs. To achieve a target composite SLA, you may need to add redundancy within each tier, such as multiple web app instances behind a load balancer.
Monitor Availability
After deployment, continuously monitor the availability of your services using Azure Monitor. Set up availability tests (e.g., URL ping tests) and metric alerts to detect downtime. For example, create an alert that fires when a VM is unavailable for more than 5 consecutive minutes. This helps you track actual uptime and compare it to the SLA. You should also enable diagnostic logs and store them for at least 90 days, because SLA credit claims require evidence of downtime. Azure Monitor can export logs to Log Analytics or Azure Storage. Without monitoring, you may not realize an outage occurred until it's too late to file a claim.
Calculate Actual Uptime
At the end of each month, calculate the actual uptime percentage for each service. Use the formula: (Total minutes in month - Downtime minutes) / Total minutes in month × 100. Downtime includes any period when the service was unavailable as defined by the SLA (excluding exclusions like planned maintenance). For example, if a month has 43,200 minutes and the service was down for 100 minutes, uptime = (43200-100)/43200 × 100 = 99.77%. Compare this to the SLA guarantee. If the actual uptime is below the guarantee, you are eligible for a service credit. The credit percentage depends on how far below the guarantee the uptime fell.
Claim Service Credit
If the SLA was not met, submit a support request in the Azure portal to claim a service credit. You must provide evidence of the downtime, such as Azure Monitor logs or screenshots. The request must be submitted within the time frame specified in the SLA (usually 60-90 days after the end of the month). Microsoft will review the claim and, if approved, apply the credit to your next invoice. Note that credits are not cash refunds—they are discounts on future bills. Also, the credit is only for the service that failed, not for the entire bill. For example, if only the VM SLA was breached, you get a credit on the VM charges, not on the database charges.
Scenario 1: E-Commerce Platform with High Availability Requirements
A national retailer launches an e-commerce platform on Azure. They need 99.99% uptime to avoid revenue loss during peak shopping seasons. They deploy multiple VMs in an availability set behind a load balancer for the web tier (achieving 99.95% SLA per VM pair) and use Azure SQL Database Business Critical tier with zone-redundant deployment (99.995% SLA). The composite SLA is 99.95% × 99.995% = 99.945%. They also add Azure Front Door for global load balancing and a secondary region in active-passive mode to handle regional outages. The team configures Azure Monitor alerts for any VM or database downtime. During a regional outage, the secondary region takes over within minutes, and the composite uptime remains above 99.99%. However, due to a misconfiguration in the load balancer health probe, one VM is marked unhealthy but still serving traffic—this causes intermittent failures that are not counted as downtime by Azure because the VM is technically running. The retailer loses some sales but cannot claim an SLA credit because the VM was 'available' per Azure's definition. This highlights that SLAs do not guarantee performance or correct configuration.
Scenario 2: Small Business Using Single VM for ERP
A small business runs its ERP system on a single Azure VM with a 99.9% SLA. They have no redundancy. One month, the VM experiences 8 hours of downtime due to a host hardware failure. The month has 43,200 minutes, so uptime is (43200-480)/43200 = 99.89%, which is below 99.9%. They submit a claim and receive a 10% credit on the VM cost. However, the business lost 8 hours of productivity, which far exceeds the credit value. They learn that for critical workloads, a single VM is risky, and they should consider an availability set or VMSS with at least two instances. The low cost of the credit (10% of maybe $100) does not compensate for the business impact. This scenario illustrates that SLAs are not insurance—they are a partial compensation mechanism.
Scenario 3: Media Streaming Service Using Azure CDN
A media company uses Azure CDN to stream video content globally. The CDN SLA is 99.99% for standard tier. During a major event, a DNS misconfiguration by the company causes traffic to be routed incorrectly, resulting in buffering for users. The CDN itself was available, so the SLA is not breached. The company cannot claim a credit. They also learn that the CDN SLA only covers the CDN service—it does not cover the origin server or network issues. To improve user experience, they add a second CDN provider and implement health checks. This example shows that SLA exclusions (customer actions) are common and that you must understand what is and isn't covered.
AZ-900 Objective 1.5: Describe Service Level Agreements (SLAs)
The exam tests your understanding of what an SLA is, what it guarantees, how composite SLAs work, and the concept of service credits. You will NOT be asked to calculate complex SLAs, but you may see simple multiplication for two services (e.g., 99.9% × 99.99%). There are typically 2-3 questions on SLAs in the exam.
Common Wrong Answers and Why Candidates Choose Them: 1. 'SLAs guarantee performance (e.g., response time).' — Candidates confuse availability with performance. The SLA only guarantees uptime, not speed. Performance is not covered. 2. 'You get a refund if the SLA is not met.' — Candidates think they get cash back. In reality, you get service credits (discounts on future bills), not refunds. 3. 'All Azure services have the same SLA.' — Different services have different SLAs, and even the same service can have different SLAs depending on the tier and deployment configuration. 4. 'A single VM has a 99.95% SLA.' — A single VM with premium disks has 99.9% SLA. To get 99.95%, you need at least two VMs in an availability set. Candidates often misremember the numbers.
Specific Terms and Values That Appear on the Exam: - 'Monthly uptime percentage' — the SLA is measured monthly. - 'Service credit' — the compensation, not a refund. - 'Composite SLA' — the product of individual SLAs. - 'Availability set' — required for 99.95% VM SLA. - 'Availability zones' — required for 99.99% VM SLA. - 'Planned maintenance' and 'force majeure' are common exclusions. - Credit percentages: 10% for uptime between 99% and 99.9%, 25% for below 95% (varies by service, but these are typical).
Edge Cases and Tricky Distinctions: - The SLA applies only to the service itself, not to your application. If your app crashes due to a bug, that's not an SLA breach. - Free services (e.g., Azure Free Account) do not have SLAs. - Preview services (with 'Preview' label) typically do not have SLAs. - If you deploy a VM without premium disks, the SLA may be lower (e.g., 99.5% for standard HDD). - The composite SLA calculation assumes independent failures. In reality, failures may be correlated, but the exam uses the product formula.
Memory Trick: 'SLAs are about uptime only, not speed. Credits are discounts, not refunds. More nines require more redundancy.' Use the acronym 'SUCC' (SLA = Uptime, Credit = Discount, Composite = Multiply).
An SLA is a contractual uptime guarantee from Microsoft, measured monthly as a percentage (e.g., 99.9%).
Service credits are discounts on future bills, not cash refunds, and require a support request within 60-90 days.
Composite SLA is the product of individual SLAs (e.g., 99.9% × 99.99% = 99.89%).
A single VM with premium disks has a 99.9% SLA; two VMs in an availability set achieve 99.95%; availability zones achieve 99.99%.
Exclusions: planned maintenance, force majeure, customer misconfiguration, and third-party actions are not covered.
Free and preview services typically have no SLA.
The SLA does not guarantee performance, only availability (uptime).
To claim a credit, you must provide evidence of downtime (e.g., Azure Monitor logs).
These come up on the exam all the time. Here's how to tell them apart.
Single VM SLA
99.9% uptime guarantee
No redundancy required
Lower cost
Higher risk of downtime
Eligible for 10-25% credit if breached
Two VMs in Availability Set SLA
99.95% uptime guarantee
Requires at least two VMs in same set
Higher cost (two VMs + load balancer)
Protects against rack-level failures
Eligible for higher credit tiers
Mistake
SLAs guarantee that my application will be available to users.
Correct
SLAs guarantee the Azure service itself is available, not your application. If your app has a bug or misconfiguration, it may be unavailable even if Azure is fine. The SLA does not cover application-level availability.
Mistake
If Azure fails to meet the SLA, I get a cash refund.
Correct
You receive a service credit (discount on future bills), not cash. Credits are typically 10-25% of the monthly fee for the affected service, not the entire bill.
Mistake
All Azure services have a 99.99% SLA.
Correct
SLA percentages vary by service and tier. For example, a single VM has 99.9%, Azure SQL Database has 99.99%, and some services like Azure DNS have 100% (no SLA). Always check the specific SLA page.
Mistake
Deploying two VMs in the same availability set gives me a 99.99% SLA.
Correct
Two VMs in an availability set give a 99.95% SLA. To get 99.99%, you need VMs across availability zones. The exam tests this distinction.
Mistake
The SLA covers all downtime, including planned maintenance.
Correct
Planned maintenance is excluded from the SLA. Microsoft provides advance notice of planned maintenance. Only unplanned outages count toward the uptime calculation.
An Azure SLA (Service Level Agreement) is a formal commitment from Microsoft regarding the uptime percentage of a cloud service. It specifies the guaranteed availability, the conditions under which the guarantee applies, and the compensation (service credits) if the guarantee is not met. For example, a single Azure VM with premium managed disks has a 99.9% SLA, meaning it will be available at least 99.9% of the time in a month. If Microsoft fails to meet this, you can claim a credit. The SLA does not cover performance or application-level issues.
Composite SLA is calculated by multiplying the individual SLAs of each component in your application. For example, if you have a web app with a 99.95% SLA and a database with a 99.99% SLA, the composite SLA is 99.95% × 99.99% = 99.94%. This assumes independent failures. The result is always lower than the lowest individual SLA. To improve composite availability, you need to add redundancy within each tier (e.g., multiple instances behind a load balancer) or choose services with higher SLAs.
A single Azure VM with premium SSD managed disks has a 99.9% SLA. If you use standard HDD disks, the SLA is 99.5%. To achieve a higher SLA (99.95%), you must deploy at least two VMs in an availability set. For 99.99%, you need VMs across availability zones. These requirements are documented in the official Azure SLA page. The exam often tests these specific values and conditions.
No, not all Azure services have an SLA. Free services (e.g., Azure Free Account) and preview services (labeled 'Preview') typically do not have an SLA. Also, some services like Azure DNS have a 100% SLA (meaning no financial commitment). Always check the official SLA page for the specific service you are using. If a service has no SLA, you cannot claim credits for downtime.
Common exclusions include: planned maintenance (with advance notice), force majeure events (natural disasters, war, etc.), customer actions (misconfiguration, deleting resources), third-party actions (ISP outages), and services not covered by an SLA. Also, downtime due to your failure to meet architecture requirements (e.g., deploying a single VM when the SLA requires two) is not covered. The SLA document lists all exclusions.
To claim a service credit, you must submit a support request in the Azure portal within the time frame specified in the SLA (usually 60-90 days after the end of the month). You need to provide evidence of the downtime, such as Azure Monitor logs, screenshots, or third-party monitoring data. Microsoft will review the claim and, if approved, apply the credit to your next invoice. The credit is a percentage of the monthly fee for the affected service, not the entire bill.
An SLA is a service commitment that offers compensation (credits) if the service fails to meet a defined uptime percentage. It is not a warranty that the service will be perfect. A warranty typically covers defects in materials or workmanship. In Azure, the SLA covers availability only, not performance, security, or functionality. You cannot get a refund or replacement for a 'defective' service—only credits for downtime.
You've just covered Service Level Agreements (SLAs) in Azure — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?