Chapter 5
Pricing, SLAs, and Azure Support
One of the biggest promises of cloud computing is that you stop guessing about capacity and stop paying for servers that sit idle. But that promise comes with a catch: in Azure, the meter is always running. Every virtual machine, every gigabyte of storage, every gigabyte of data that leaves a datacenter — all of it is measured and billed. This chapter is about understanding that meter so it never surprises you. You will learn what drives Azure costs, how to estimate them before you spend a dollar, how to keep them under control once workloads are running, what Microsoft guarantees about uptime (and what happens when it falls short), and what kind of help you can get when things go wrong. The AZ-900 exam treats this as practical knowledge: it wants you to think like someone responsible for a real budget, not someone memorizing definitions.
5.1 Why Pricing Deserves Its Own Chapter
In the on-premises world, costs are lumpy and predictable. You buy a server, and whether it runs at 5 percent utilization or 95 percent, the money is already spent. Cloud flips this completely: you pay for what you use, by the second or minute, and you can scale up and down at will. That flexibility is powerful — but it means costs follow behavior. Leave a large virtual machine running over a weekend nobody uses, and you pay for every hour. Deploy resources in the most expensive region when a cheaper one would do, and nobody stops you. Move terabytes of data out of Azure without thinking about it, and the bandwidth bill can dwarf the compute bill.
Microsoft gives you tools for all of this — calculators, budgets, alerts, cost analysis dashboards, tagging, reservations, and discounts. The exam expects you to know which tool solves which problem. It also expects you to understand the two big formal agreements in the relationship between you and Microsoft: the Service Level Agreement, which states what uptime Microsoft promises, and the support plan, which states what help you get when you need it.
5.2 Factors That Affect Azure Costs
Before you can estimate or control costs, you need to know what the meter actually measures. Four factors drive nearly every Azure bill: the type and size of the resource, the region it lives in, the bandwidth it consumes, and how you choose to pay for it.
Resource Type and Size
Every Azure service has its own pricing model, and within a service, bigger costs more. A virtual machine with 64 virtual CPUs and 256 GB of RAM costs dramatically more per hour than a small two-core machine. A premium SSD disk costs more per gigabyte than standard HDD storage. A high-throughput database tier costs more than the basic tier. This sounds obvious, but it has a practical consequence the exam cares about: choosing the right size and tier for the workload is the single most basic cost decision in Azure. Over-provisioning — renting a far bigger machine than you need "just in case" — is the most common way beginners waste money, because in the cloud you can always scale up later.
Storage adds its own dimensions: you pay for the amount stored, the type of storage (hot, cool, or archive tiers get progressively cheaper but slower to access), and the number of read/write operations. Networking charges for things like VPN gateways, load balancers, and public IP addresses. The lesson is the same everywhere: in Azure, you are renting finely sliced capacity, and the slice you pick determines the price.
The exam loves scenario questions like: "A company wants to reduce costs. Which change would help?" The right answer is almost always something like choosing a smaller VM size, deleting unused resources, or using a cheaper storage tier — not something exotic.
Location (Region)
The same virtual machine does not cost the same everywhere. Azure regions are priced differently based on local realities: the cost of electricity, real estate, taxes, and the expense of building and staffing datacenters in that part of the world. A VM in US East may cost less per hour than the identical VM in a region with expensive power or a newly built datacenter.
Region choice matters for two more reasons. First, not every service is available in every region, and brand-new services often launch in a handful of regions first. Second, data transfer between regions is billed, while transfer within a region is generally free. So if your application servers sit in West Europe but your database sits in North Europe, you pay for every gigabyte that crosses between them — plus you add latency. The best practice is to keep tightly connected resources in the same region, and to pick the cheapest region that meets your latency and compliance needs.
Common exam trap: "Deploying resources in a different region is free." It is not — inter-region bandwidth is charged, and regional prices differ. Also watch for the reverse trap: moving data into Azure is free (see below), so a question might try to make you think all transfers cost money.
Bandwidth: Ingress Is Free, Egress Is Not
Bandwidth — data moving in and out of Azure datacenters — follows one simple rule that the exam tests constantly: inbound data transfer (ingress) is free, outbound data transfer (egress) is charged. You can upload a terabyte into Azure storage and pay nothing for the transfer itself (you still pay for the storage). But downloading that terabyte back out to the internet incurs egress charges, billed per gigabyte, with the rate typically decreasing as volume grows.
There are nuances worth knowing. Data transfer between Azure services within the same region is generally free. Transfer between regions is charged. Transfer from one availability zone to another within a region has its own pricing. Content delivery through the Azure CDN has separate pricing. For AZ-900 purposes, though, the core rule is enough: in is free, out costs money. This is why architects think carefully about where data leaves the cloud — streaming video to millions of users, for example, means serious egress planning.
How You Pay: Pay-As-You-Go vs. Reserved Capacity
The last cost factor is your purchasing model. The default is pay-as-you-go: no upfront commitment, billed per second (for most compute) or per minute, and you can stop anytime. It is the most flexible and the most expensive per unit — perfect for unpredictable workloads, experiments, and anything short-lived.
The alternative is committing to capacity in advance through reservations (often still called reserved instances). You commit to one or three years of a particular VM family in a region, and in exchange you pay significantly less — savings of up to around 72 percent compared to pay-as-you-go for a three-year commitment. Reservations suit steady, predictable workloads: the domain controller that runs 24/7, the production database that never sleeps. The exam wants you to connect the model to the workload: predictable and long-running means reserve; spiky or experimental means pay-as-you-go.
The exam frequently asks which purchasing option fits a scenario. "A company runs the same VMs continuously for the next two years and wants the lowest cost" — that is reserved capacity, not pay-as-you-go, and not spot (spot is for interruptible work, covered later). "A startup is testing an idea for three weeks" — pay-as-you-go.
5.3 Estimating Costs Before You Spend: The Pricing Calculator and the TCO Calculator
Nobody should deploy into Azure blind. Microsoft provides two free web-based tools for cost estimation, and the exam expects you to know exactly which one answers which question.
The Pricing Calculator
The Pricing Calculator (formerly the Azure Pricing Calculator) answers: "What will this Azure architecture cost me per month?" You pick the services you plan to use — virtual machines of a certain size, a SQL database tier, a certain amount of storage, estimated bandwidth — choose the region, and the calculator produces a monthly estimate. You can compare the same workload across regions, try different VM sizes to see the price difference, and export or share the estimate.
Two important caveats. First, the calculator works from published retail rates — your actual bill can differ because of enterprise agreements, reservations, hybrid benefits, or spot pricing, none of which the basic estimate includes. Second, it is an estimate, not a bill. Still, it is the right tool for the planning phase, and it is the answer whenever an exam question asks how to estimate costs before deploying resources.
The Total Cost of Ownership (TCO) Calculator
The TCO Calculator answers a different question: "Is moving to Azure cheaper than staying on-premises?" It is a business-case tool. You feed it details about your current on-premises environment — number of servers, virtual machines, storage capacity, networking gear, software licenses, electricity, and even IT labor costs — and it projects what the equivalent Azure deployment would cost over time, showing the expected savings.
This matters because cloud migrations are sold to executives, and executives ask for numbers. The TCO report gives you a defensible comparison: here is what we spend today running our own datacenter, here is what Azure would cost, here is the difference over three years. It accounts for things people forget, like the cost of powering and cooling on-premises hardware and the salaries of the staff maintaining it — costs that simply vanish (or transform) in the cloud.
The exam tests the distinction between these two tools relentlessly. Pricing Calculator = estimate the cost of an Azure solution before you build it. TCO Calculator = compare on-premises costs against Azure to build a migration business case. If a question mentions "compare our datacenter costs with Azure," that is TCO, every time.
5.4 Managing and Tracking Costs: Cost Management + Billing
Estimating is only half the battle. Once resources are running, you need visibility and guardrails. That is the job of Cost Management + Billing, a free set of tools built into the Azure portal.
Cost Analysis
Cost analysis is the dashboard view: where is money going, broken down by subscription, resource group, service, location, or time period. You can spot the expensive VM someone left running, see which project is burning through budget, and track trends month over month. It is the first place you look when the bill surprises you.
Budgets and Alerts
A budget sets a spending threshold on a subscription or resource group — say, $5,000 per month for the development environment. The powerful part is what happens when spending approaches or exceeds it: alerts. You configure alert rules at percentages of the budget (50 percent, 80 percent, 100 percent — and even forecasted overspend, so you get warned before the money is gone). Alerts can send emails to the team, and through action groups they can trigger automated responses: a webhook, a Logic App, or an Automation runbook that shuts down non-critical VMs.
Watch for the subtle point that budgets do not stop spending by themselves — they alert. If a question asks how to automatically shut down VMs when a budget is exceeded, the answer involves action groups and automation, not the budget alone. The exam likes testing whether you understand that a budget is a tripwire, not a wall.
Tagging for Cost Tracking
As environments grow, you need to answer: which department, project, or cost center does each resource belong to? Tags solve this. A tag is a name-value pair — Department: Marketing, Project: Phoenix, Environment: Production — that you attach to resources, resource groups, or subscriptions. Cost Management can then group and filter spending by tag, so each team sees its own bill.
Three tagging facts the exam cares about. First, tags are also used for automation and organization, not just billing — but cost tracking is the exam's favorite angle. Second, tags applied at the resource group level are not automatically inherited by the resources inside it — a classic trap. Third, because people forget or mistype tags, you use Azure Policy to require tags or automatically apply them, keeping the system honest.
5.5 Ways to Reduce Costs
Knowing the meter is one thing; shrinking the bill is another. The exam groups cost-saving techniques into a short list you should know cold.
Reservations: Commit and Save
As covered in 5.2, Azure Reservations let you commit to one or three years of capacity — VMs, SQL databases, storage, and other services — for a steep discount versus pay-as-you-go, up to roughly 72 percent on a three-year term. The key judgment call: only reserve what you are confident you will use continuously. An unused reservation still costs you.
Azure Hybrid Benefit
Many companies already own Windows Server or SQL Server licenses with Software Assurance. The Azure Hybrid Benefit lets them apply those existing licenses to Azure VMs instead of paying for the license portion of the VM's hourly rate again — you pay only for the base compute. It is essentially "bring your own license to the cloud," and for Microsoft-heavy shops the savings are substantial. The exam's angle is simple: Hybrid Benefit = use existing on-prem licenses in Azure to save money, and it requires Software Assurance.
Spot Virtual Machines
Azure datacenters always have unused capacity. Spot VMs let you bid for it at discounts of up to around 90 percent off pay-as-you-go — with one big condition: Azure can take the capacity back at any time. When Azure needs those resources, your spot VM is evicted, with only about 30 seconds of notice. That makes spot perfect for fault-tolerant, interruptible work — batch processing, rendering, dev/test, large-scale simulations that checkpoint their progress — and completely wrong for anything that must stay up, like a production database or a customer-facing web server.
Spot VM questions are almost always scenario-based: "Which workload is suitable for spot VMs?" Look for batch jobs, rendering, or anything described as interruptible or fault-tolerant. If the scenario says "must run continuously" or "cannot tolerate interruption," spot is the wrong answer — the exam is testing whether you know about eviction.
Autoscaling, Right-Sizing, and Good Hygiene
The remaining techniques are about discipline. Autoscaling adjusts the number of VM instances based on real demand — scale out during the morning rush, scale in at night — so you never pay for idle capacity. Right-sizing means matching VM sizes to actual utilization (Azure Advisor flags oversized VMs for you). Auto-shutdown powers off dev and test VMs on a schedule. And plain hygiene — deleting unattached disks, unused public IPs, and forgotten resource groups — saves real money. Finally, remember region choice from 5.2: deploying in a lower-cost region is itself a cost-reduction strategy.
Azure Advisor deserves a mention here: it is the free built-in consultant that reviews your environment and recommends cost savings (along with security, reliability, and performance improvements). If a question asks which tool recommends ways to reduce spending on running resources, that is Cost Management/Advisor territory — not the Pricing Calculator, which is for pre-deployment estimates.
5.6 Service Level Agreements (SLAs)
A Service Level Agreement (SLA) is Microsoft's formal promise about a service's availability — typically expressed as an uptime percentage over a month or year. It is the contractual answer to "how reliable is this?" Free services and services in preview generally carry no SLA; paid, generally available services do, and the percentage varies by service and configuration.
Reading Uptime Percentages
The percentages look similar but mean very different things in practice:
- 99.9% ("three nines") allows about 43.8 minutes of downtime per month — roughly 8.76 hours per year.
- 99.95% allows about 21.9 minutes per month.
- 99.99% ("four nines") allows about 4.38 minutes per month — under an hour per year.
Each additional nine roughly cuts allowed downtime by a factor of ten — and typically costs more, because higher availability requires redundancy: availability zones, paired regions, replicated data. The exam does not usually make you compute these from scratch, but it does expect you to recognize that a higher percentage means less permitted downtime and that achieving it requires architectural choices (like deploying across zones), not just wishing.
Composite SLAs: The Math the Exam Loves
Here is where it gets interesting — and where the exam sets its favorite trap. When your application depends on multiple services, the overall SLA is the product of the individual SLAs. This is called a composite SLA, and it is always lower than any single component.
Example: your web app runs on Azure App Service (99.95% SLA) and stores data in Azure SQL Database (99.99% SLA). The composite SLA is:
0.9995 × 0.9999 = 0.9994, or 99.94%
Notice what happened: even though both services promise excellent uptime individually, the combination promises slightly less, because either service going down takes your app down. Every dependency you add multiplies the risk. This is why architects minimize critical dependencies and design for failure — and why the exam loves asking you to compute or reason about composite SLAs.
Expect a question like: "An application uses two services with 99.9% SLAs each. What is the composite SLA?" Multiply: 0.999 × 0.999 = 0.998001, roughly 99.8%. The trap answers are 99.9% (forgetting to multiply) and 199.8% (adding). Remember: composite is always lower than the weakest link's SLA — more dependencies means a lower combined guarantee.
Service Credits
What happens if Microsoft misses the SLA? You may be eligible for service credits — a percentage of your service fees credited back to your account, on a sliding scale based on how far below the SLA the actual uptime fell. Two things to know: credits are not automatic in the sense of appearing unprompted — you typically need to submit a claim — and they compensate with credit, not cash. The SLA is ultimately a financial accountability mechanism, not a guarantee that downtime will never happen.
5.7 The Azure Service Lifecycle: Preview vs. General Availability
Azure services move through a lifecycle, and the exam cares about exactly two stages.
Public preview means a service is available for customers to try and give feedback on, but it is not finished. Preview services are not recommended for production workloads, they carry no SLA, pricing may be reduced or the service may be free during preview, and support is limited. Breaking changes can still happen. Think of it as a public beta.
General availability (GA) means the service is finished, production-ready, backed by an SLA, billed at standard rates, and fully supported. This is the stage enterprises wait for before betting critical workloads on a service.
The exam tests this as a set of paired facts: preview = no SLA, not for production, possibly discounted; GA = SLA-backed, production-ready, standard pricing. A question might describe a company wanting to run a critical workload on a preview service to save money — the correct response is that preview has no SLA and is not recommended for production.
5.8 Azure Support Plans
When something breaks or you need guidance, what help you get depends on your support plan. Every Azure subscription includes the Basic plan for free; the paid tiers add progressively faster, deeper technical support.
Basic (Free)
Included with every subscription at no cost. You get 24/7 access to documentation, whitepapers, and community support, plus help with billing and subscription management — but no technical support. If your VM will not boot, Basic will not get an engineer on the case. It is enough for learning and for sorting out invoice questions.
Developer (~$29/month)
Aimed at non-production, trial, and evaluation environments. You get business-hours access to support engineers by email, with initial response targets under 8 business hours for minimal-impact issues. No 24/7 phone line, no help with production outages. It is the right plan for a developer experimenting or a team running proofs of concept.
Standard (~$100/month)
The plan for production workloads. This is where real technical support begins: 24/7 access by phone and email, an initial response target of under one hour for critical (Sev A) issues, and architecture guidance. If your production system is down at 3 AM, Standard gets you an engineer fast. For any business running customer-facing systems on Azure, this is the baseline sensible choice.
Professional Direct — ProDirect (~$1,000/month)
The top tier for organizations with business-critical dependencies on Azure. Everything in Standard, plus ProDirect delivery managers — named technical account managers who know your environment — the fastest response times (under one hour for critical), prioritized handling, and support APIs for integrating with your own ticketing systems. Large enterprises with significant Azure spend live here.
Support plan questions are usually "which plan fits this need" scenarios. Memorize the ladder: Basic = free, billing help only, no tech support. Developer = cheap, email, business hours, non-production. Standard = 24/7, under-1-hour critical response, production workloads. ProDirect = most expensive, delivery managers, business-critical. The exam also likes the trap that Basic includes no technical support — do not pick it for any scenario involving broken production systems.
5.9 Chapter Summary
Pricing in Azure is driven by what you use, where you use it, how much data leaves, and how you pay — with pay-as-you-go for flexibility and reservations for predictable workloads at up to ~72% off. Estimate before deploying with the Pricing Calculator; build your migration business case with the TCO Calculator. Track spending with Cost Management + Billing: cost analysis for visibility, budgets and alerts (tripwires, not walls) for guardrails, and tags — enforced by policy — for organizing costs by team or project. Cut the bill with reservations, Hybrid Benefit, spot VMs for interruptible work, autoscaling, right-sizing, and good hygiene. SLAs state Microsoft's uptime promise; composite SLAs multiply (and shrink) with each dependency; missed SLAs mean service credits. Preview services carry no SLA and are not for production; GA services are production-ready and SLA-backed. And support plans run from free Basic (billing help only) through Developer, Standard (24/7, <1 hr critical), to ProDirect with dedicated delivery managers. If you can explain why each of these exists — not just what it is — you are ready for this portion of the exam.
End-of-Chapter Test
1. A company wants to estimate the monthly cost of a planned Azure deployment before creating any resources. Which tool should they use? A. Azure TCO Calculator B. Azure Pricing Calculator C. Azure Cost Management D. Azure Advisor
2. Which of the following does NOT affect the cost of an Azure deployment? A. The Azure region resources are deployed in B. The size of the virtual machines selected C. The number of users who sign in to the Azure portal D. The amount of outbound data transfer
3. A company runs the same virtual machines 24/7 and expects to keep them for the next three years. Which purchasing option gives the lowest cost? A. Pay-as-you-go B. Spot virtual machines C. Azure reservations (reserved capacity) D. The free tier
4. A company needs to track Azure spending separately for its Marketing and Engineering departments. What is the best way to organize costs? A. Create a separate Azure subscription for each employee B. Apply resource tags such as Department: Marketing to resources C. Use the Pricing Calculator for each department D. Enable Azure Policy to delete untagged resources immediately
5. Which workload is most suitable for Azure Spot VMs? A. A production SQL database that must run continuously B. A customer-facing web application with strict uptime requirements C. A nightly batch job that renders video files and can be restarted if interrupted D. A domain controller providing authentication for the office
6. An application depends on two Azure services. Service A has a 99.9% SLA and Service B has a 99.9% SLA. What is the composite SLA for the application? A. 99.9% B. 99.8% C. 199.8% D. 99.99%
7. A company wants to run a business-critical workload on an Azure service that is currently in public preview because preview pricing is lower. What should they be told? A. This is a good idea because preview services include an SLA B. Preview services are not recommended for production and carry no SLA C. Preview services are free forever D. Public preview is the same as general availability
8. A company's production web application goes down at 2 AM and they need an Azure engineer on the phone within the hour. Which is the minimum support plan they need? A. Basic B. Developer C. Standard D. They cannot get phone support at any plan level
9. A company owns Windows Server licenses with Software Assurance and wants to use them for Azure virtual machines to reduce costs. Which option should they use? A. Azure Spot VMs B. Azure Hybrid Benefit C. Pay-as-you-go pricing D. Azure reservations
10. A department sets a monthly Azure budget of $10,000 and wants to be notified by email when spending reaches 80% of the budget. Which feature should they configure? A. A resource lock on the subscription B. A budget alert in Cost Management + Billing C. An Azure Policy that denies deployments over $8,000 D. The TCO Calculator
---
Answer Key
1. B — The Pricing Calculator estimates costs before deployment. The TCO Calculator (A) compares on-premises costs to Azure for migration business cases. Cost Management (C) tracks spending on resources that already exist. Azure Advisor (D) recommends improvements for running resources.
2. C — Region, VM size, and outbound bandwidth all affect cost. The number of users signing in to the portal has no effect on the bill — Azure does not charge per portal user.
3. C — Steady, long-running workloads should use reservations (1- or 3-year commitments) for the deepest discounts (up to ~72%). Pay-as-you-go (A) is for flexible/short-term use. Spot VMs (B) can be evicted and are unsuitable for continuous production. The free tier (D) does not cover production VMs.
4. B — Resource tags (name-value pairs like Department: Marketing) let Cost Management group and report spending by department. Separate subscriptions per employee (A) is unmanageable. The Pricing Calculator (C) is for pre-deployment estimates. Policy (D) can enforce tagging but does not itself organize cost reporting.
5. C — Spot VMs offer huge discounts but can be evicted with ~30 seconds notice, so they suit interruptible, fault-tolerant batch work. Production databases (A), customer-facing apps (B), and domain controllers (D) cannot tolerate eviction.
6. B — Composite SLA = 0.999 × 0.999 = 0.998001, approximately 99.8%. It is always lower than the individual SLAs — never the same (A), never added (C), and never higher (D).
7. B — Public preview services carry no SLA and are not recommended for production workloads. Pricing may be reduced during preview, but that does not make them suitable for business-critical systems.
8. C — Standard is the first plan with 24/7 phone and email support and under-1-hour response for critical issues. Basic (A) has no technical support; Developer (B) is email-only during business hours for non-production.
9. B — Azure Hybrid Benefit lets customers apply existing Windows Server/SQL Server licenses with Software Assurance to Azure VMs, paying only for base compute. Spot (A) is discounted interruptible capacity; pay-as-you-go (C) is full price; reservations (D) are time commitments, not license reuse.
10. B — Budget alerts in Cost Management + Billing notify (via email or action groups) when actual or forecasted spending crosses thresholds like 80%. Resource locks (A) prevent changes, not spending alerts. Policy (C) controls deployments, not budget notifications. The TCO Calculator (D) is for migration comparisons.
Answer key
Want the full Microsoft Azure Fundamentals (AZ-900) package?
This guide is free to read. Get the downloadable PDF guidebook plus the full 700-question AZ-900 practice exam with 3 months of online access.
Get Microsoft AZ-900 Full Access — $10