AZ-900 Azure Cost Management and Service Level Agreements: Pricing, Optimization, and Availability Explained

1. Introduction

For AZ-900, Azure cost management and service level agreements sit right at the center of practical cloud decision-making. Honestly, most real-world Azure conversations boil down to two questions pretty quickly: what’s this going to cost, and how available does it actually need to be? In Azure, those questions are connected. Higher resilience usually means more redundancy, more services, and more spend. Usually, when you push cost down, you end up with a simpler design and a little less fault tolerance. That’s just the tradeoff.

This article sticks to the fundamentals Microsoft expects you to know: how Azure pricing works, which tools help you estimate and track cost, how governance keeps spending in check, which optimization options fit different workloads, and how SLAs and availability design shape uptime. So anyway, it’s still exam-focused, but it’s also grounded in how this stuff actually works day to day.

2. How Azure Pricing Works

Azure pricing is not just one model. Many services use consumption-based billing, where you pay for measured usage, but some services use provisioned capacity pricing, and some discounts depend on commitments such as Reservations or Azure Savings Plan for Compute. The exam version is simple: Azure charges are based on meters, and different services use different meters.

Common billing factors include compute runtime, storage capacity, transactions or operations, database performance tier, backup retention, and network transfer. Take a virtual machine, for example. While it’s running, you’re paying for the compute, and then the managed disk usually gets billed separately. On top of that, outbound network traffic can quietly tack on more cost than people expect. A storage account can cost you in a few different ways too: the amount of data stored, the redundancy level you pick, and even the number of transactions it processes. And some services go by usage in a different way altogether, like execution count, API calls, or how much log data you send in.

Network pricing deserves special attention. Inbound data transfer to Azure is generally free, while outbound internet egress is typically charged. Cross-region transfer and some architecture-specific traffic, including certain inter-zone or service-to-service patterns, can also add cost depending on the service and design. That is why a workload can look inexpensive in compute terms but still produce a surprisingly high bill.

Azure also offers free services, limited free tiers, and in some cases trial credits or free account benefits. For AZ-900, one thing I always remind people is to account for both paid consumption and any free usage limits. Free tiers are actually really useful for labs, testing, and small proof-of-concept workloads.

3. Common Azure Billing Components You Might Forget

A classic Azure mistake is pricing only the main service and forgetting the supporting services around it. A VM estimate that ignores disks, backups, monitoring, and network egress is incomplete. The same is true for platform service designs that ignore storage transactions or log retention.

A lot of people forget about charges like managed disks, snapshots, backup vault usage, load balancers, public IP addresses, NAT Gateway, outbound bandwidth, monitoring and log analytics ingestion, and premium performance tiers. With VMs, there’s another really important exam nuance: stopping the machine from inside the guest operating system is not the same thing as stopping and deallocating it in Azure. Compute charges generally stop only when the VM is deallocated, while attached disks and some associated resources can still continue billing.

That is the bigger lesson: Azure cost is usually the total of the solution, not just the headline resource.

4. Azure Tools for Estimating and Managing Cost

AZ-900 expects you to distinguish clearly between three core tools, and it often tests them by timing:

• Azure Pricing Calculator: estimate a planned Azure deployment before you build it.
• Azure TCO Calculator: compare current on-premises costs with Azure during migration planning.
• Microsoft Cost Management and Billing: analyze actual Azure spend after deployment.

A practical Pricing Calculator workflow is pretty straightforward: pick the region, add services like App Service, Azure SQL Database, Storage, and outbound data transfer, choose the performance tiers, and then review the monthly estimate. And honestly, good estimates should also include dependent resources like backups, monitoring, and public IPs. The tool is excellent for what-if planning, but it is still an estimate, not a bill.

The TCO Calculator is different. It asks about your current environment, including things like server count, storage, networking, facilities, power, and labor assumptions. It’s great for building a migration business case, but the output is only as good as the inputs you feed it. If the on-premises numbers are off, the comparison’s going to be misleading. Simple as that.

Microsoft Cost Management and Billing is the tool you lean on once the environment is live and you need to see what’s really happening with spend. Teams use it to break down cost by subscription, resource group, service, region, and tag, plus set budgets, forecast spending, and export data for reporting. Azure Advisor is a nice companion to that because it points out things like oversized resources or idle stuff that’s just sitting there burning money. Cost Management shows where the money went. Advisor helps suggest what to improve.

5. Governance: Budgets, Policy, and Access Control Work Together

Governance is how organizations keep Azure spend understandable and controlled. Subscriptions are a primary billing, governance, and access boundary in Azure, but management groups, resource groups, Azure RBAC, and Azure Policy also shape control and visibility.

Tags are one of the simplest tools for cost accountability. A small standard such as Environment, Owner, Application, and CostCenter is often enough to support showback or chargeback reporting. Without tags, cost analysis becomes much harder.

Budgets give you visibility, not enforcement. Budgets can absolutely trigger alerts when actual or forecasted spend crosses a threshold, but they won’t, by themselves, stop deployments or power things off. If you need real enforcement, you usually end up combining Azure Policy, RBAC, automation, and sometimes scheduled operational controls.

Azure Policy helps keep costs under control indirectly by enforcing standards like required tags, allowed regions, approved SKUs, and even blocking certain resource types. RBAC helps by limiting who can deploy expensive services or change production resources. A common governance pattern is simple: budgets for visibility, Policy for guardrails, RBAC for permission control, and automation for response.

6. Cost Optimization in Azure

Cost optimization is really about lining up spend with what the workload actually needs, not just cutting resources because it sounds good on a slide. For AZ-900, the big ones to know are right-sizing, auto-scaling, deallocating unused resources, Reservations, Azure Savings Plan for Compute, Spot VMs, and Azure Hybrid Benefit.

Right-sizing means reducing oversized resources after reviewing utilization. In practice, teams usually check CPU, memory, disk, and traffic trends before they decide to resize anything. Auto-scaling fits variable workloads, but poorly tuned rules can raise cost instead of lowering it. Deallocation is useful for dev/test systems, but remember that disks, backups, and some other dependencies can still incur charges.

Reservations and Azure Savings Plan for Compute are both commitment-based, but they are not the same. Reservations are more resource-specific and work well for stable, predictable usage. Savings Plan is a spend-based commitment across eligible compute services and offers more flexibility. Spot VMs are for interruptible workloads and can be evicted when Azure needs capacity. Azure Hybrid Benefit reduces licensing cost for eligible Windows Server and SQL Server workloads, subject to product terms and license eligibility.

Azure Advisor is especially useful here because it helps call out idle or underused resources that you might’ve missed. In real operations, I usually think of it like this: check actual spend in Cost Management, review the recommendations in Advisor, make sure the performance impact makes sense, and then roll the changes out carefully.

7. Understanding Azure SLAs

An SLA is Microsoft’s formal commitment for a specific Azure service, usually expressed as an uptime percentage over a defined period. The important exam point is that SLAs are service-specific and architecture-specific. Current SLA values should always be verified against Microsoft's official service agreement details because they can change by service, region, and deployment pattern.

An SLA does not guarantee that your entire application will always be available. It applies to the service under the documented conditions. Some services have different SLA levels depending on architecture, such as single-instance versus multi-instance deployment, and some preview features may have limited or no SLA at all. Preview services are generally not the default production choice unless explicitly stated otherwise.

Service credits are also commonly misunderstood. They are typically billing credits under the SLA terms, not cash reimbursement and not compensation for business loss. An SLA matters, definitely, but architecture, redundancy, monitoring, and recovery design are what really shape the user experience.

One more distinction helps a lot: availability is about service uptime, durability is about the likelihood that data remains intact, and disaster recovery is about restoring service after a major failure. People mix these up all the time, especially when storage services are involved.

8. Worked Composite SLA Examples

Composite SLA applies when your application has serial dependencies, meaning all required components must be available for the solution to work. In that case, you multiply the SLA values together, and the result is lower than the individual service SLAs.

Two-service example:
0.999 × 0.9995 = 0.9985005 = 99.85005% — that’s the math in plain sight.
Rounded, that is about 99.85%.

Three-service example:
If you’ve got a web tier at 99.95%, a database at 99.99%, and storage at 99.9%, here’s how the composite SLA works out:
0.9995 × 0.9999 × 0.999 = 0.99840064995 — that’s the result when you stack all those dependencies on top of each other.
That is about 99.84%.

The memory aid is simple: more required parts usually means lower composite SLA. That does not mean complex solutions are bad. It means you must design redundancy intelligently. If redundancy removes a single point of failure, effective solution availability can improve even when the architecture becomes more complex.

9. How SLA Changes with Architecture

Architecture affects availability as much as the service SLA itself. A single VM is easy to understand, but it also creates a single point of failure. Two VMs behind a load balancer can definitely improve resilience. Availability Sets spread VMs across fault domains and update domains within an Azure datacenter deployment. Availability Zones place resources across physically separate locations within a region, although zone support still depends on the service and the region.

Region pairs matter too, but people definitely misunderstand them a lot. They support Microsoft platform recovery priorities and some service replication patterns, yet they do not automatically fail over your workload. Actual customer failover has to be designed with services and architectures that support replication and recovery.

For disaster recovery, high-level business concepts matter: RPO is how much data loss you can tolerate, and RTO is how quickly service must be restored. Those targets help you decide whether a single-region design, a zonal design, or a cross-region DR approach actually makes sense for the workload.

10. Monitoring, Service Health, and Troubleshooting — here’s the practical version

Monitoring doesn’t replace an SLA, but it’s how you actually detect and respond to real issues. Azure Monitor is used for metrics, logs, dashboards, and alerts in your environment. Azure Service Health shows Azure platform incidents, planned maintenance, and advisories that may affect your resources. Resource Health helps you understand the health state of a specific resource.

A simple operational example works well for AZ-900. If users start reporting slow response times, Azure Monitor is usually the first place I’d check for metrics and logs. If multiple resources in a region are affected and it seems like a platform-side issue, check Service Health. If one VM or App Service seems unhealthy, Resource Health can help you figure out whether the problem is platform-related.

For unexpected spend, I’d use a short checklist: review cost by subscription and resource group, look for new deployments, check autoscale activity, inspect outbound and cross-region traffic, review premium SKU changes, and look for orphaned dis...ks, IPs, snapshots, or log ingestion spikes. For availability incidents, check Service Health, Resource Health, single points of failure, backend dependencies, scaling rules, and expired certificates or secrets.

11. AZ-900 Exam Trap Patterns and Memory Aids

AZ-900 usually tests distinctions more than deep configuration. These are the patterns worth memorizing:

• Before deployment = Pricing Calculator
• Compare on-premises to Azure = TCO Calculator
• Actual spend, budget, forecast = Cost Management and Billing
• Optimization recommendation = Azure Advisor
• Stable predictable usage = Reservation
• Flexible predictable compute spend = Savings Plan for Compute
• Interruptible workload = Spot VM
• Existing Windows or SQL licenses = Azure Hybrid Benefit
• Budgets = alerts, not automatic shutdown
• Stopping a VM is not the same as deallocating it
• Multiple dependent services = composite SLA
• Preview often means limited or no SLA; GA means generally production-ready, but still service-specific
• Availability Set = fault/update domains for VMs
• Availability Zone = separate physical locations within a region

If you want one compact summary, use this: estimate, compare, manage, optimize. Estimate with Pricing Calculator, compare with TCO Calculator, manage with Cost Management, optimize with Advisor and the right commitment or scaling choice.

12. Conclusion

For AZ-900, the big ideas are straightforward. Azure pricing is meter-based and depends on service type, usage, region, networking, and licensing. Cost control relies on the right tools, clear governance, and good optimization choices. SLAs are service-specific commitments, not guarantees for an entire application, and composite SLA usually drops as more required dependencies are added. Higher availability usually costs more because resilience requires redundancy and planning.

If you can clearly explain the difference between Pricing Calculator, TCO Calculator, Cost Management, and Advisor; distinguish budgets from enforcement; and connect architecture choices to SLA and cost, you are in strong shape for both the exam and real-world cloud discussions.