Azure Cost Management and Service Level Agreements for AZ-900

Quick Take

• Azure pricing is mostly consumption-based, but each service can be billed a little differently.
• What you end up paying really depends on the service you’re using, how much of it you consume, where it’s running, the licensing, the level of redundancy you pick, the network traffic involved, and the purchase option you choose.
• Use the Azure Pricing Calculator to estimate future cost.
• Use the Azure TCO Calculator to compare on-premises cost with Azure.
• Use Azure Cost Management + Billing to analyze actual spend, budgets, forecasts, and exports.
• An SLA is an uptime commitment, not a zero-downtime promise.
• Composite SLA for dependent components is calculated by multiplying availabilities.
• Higher availability usually increases cost.

1. Why Cost Management and SLAs Matter in Azure

For AZ-900, cost and availability belong together. In Azure, you’re not just picking a piece of technology. You’re also choosing how you’ll spend, how much uptime you need, and how you plan to run things day to day. A design that looks cheap on paper can get expensive fast if it leads to outages, slow performance, or a lot of rework. And honestly, a highly resilient design can be tough to defend too if nobody thought through the cost.

That is why Azure cost tools and Service Level Agreements matter. Cost tools help you estimate, compare, monitor, and optimize spend. SLAs help you understand the availability commitment Microsoft publishes for a service when it is deployed in a qualifying way. The exam usually tests whether you know which tool or concept fits which situation, not whether you can memorize every current price.

A simple memory aid is this: Estimate, Compare, Monitor. Estimate with the Pricing Calculator, compare with the TCO Calculator, and monitor with Cost Management. Then pair that with SLA thinking: understand what uptime commitment your architecture is actually buying.

2. How Azure Pricing Works

Azure uses service-specific meters. That means billing units and granularity vary by service. Many compute services are metered based on runtime and size, storage is commonly metered by capacity and transactions, databases by performance tier or allocated compute, and networking by data transfer or connectivity choices.

Honestly, this is one of the biggest differences between cloud and traditional on-premises IT. With on-premises, you usually start with capital expense: buy the hardware, install it, and then depreciate it over time. Azure tends to shift more of that into operational expense, so you’re paying for what you consume while the services are running. That flexibility is great, but it also means your monthly bill can move around instead of staying fixed.

At a basic level, it helps to think about Azure costs in a few service categories:

• Compute: VM size, operating system, runtime, region, and purchase option affect cost.
• Storage: capacity used, redundancy option, access tier, and transactions affect cost.
• Databases and managed platforms: service tier, performance level, storage, backup retention, and high availability options affect cost.
• Networking: outbound data transfer, load balancing, VPN Gateway, ExpressRoute, and inter-region traffic can affect cost.
• Monitoring and security: log ingestion, retention, analytics, and some security features can add meaningful cost.

Prices do change over time, and they can vary by region, service, and offer. For AZ-900, it’s more important to understand the pricing model and how you’d make the decision than to memorize exact numbers. In real projects, always verify current official pricing and service guidance before making budget or architecture commitments.

3. What Affects Azure Costs?

Azure cost is influenced by more than just VM size. The main drivers are service type, consumption volume, deployment region, network traffic pattern, service tier, redundancy choice, licensing, and discount model.

Service type and usage are the most obvious factors. A VM, an Azure SQL Database, a Blob Storage account, and an Azure Functions app can all be billed in different ways, which is where people sometimes get tripped up. In general, the more runtime, requests, transactions, storage, or throughput you use, the more cost you’ll usually see.

Region matters. Pricing can vary by region, and network or data transfer pricing can vary by source, destination, and pricing geography. That is more precise than saying “billing zones,” which can be confused with Availability Zones. Availability Zones are resiliency constructs inside supported regions; they are not the same thing as pricing geography.

Bandwidth is a classic surprise. Outbound data leaving Azure is commonly charged, while a lot of inbound traffic is often free, though there are exceptions depending on the service and scenario. If you’ve got a public app pushing downloads, video, backups, or large reports, egress can become a surprisingly big part of the bill.

Licensing also matters. Windows-based compute often has different pricing considerations than Linux-based compute, and Azure Hybrid Benefit can reduce cost in some eligible licensing scenarios. For AZ-900, you do not need licensing detail, but you should know that software licensing can change the final bill.

Redundancy and performance choices affect cost too. Storage choices like LRS, ZRS, GRS, and GZRS usually give you better resiliency, but they also tend to cost more. Premium storage, higher database tiers, zone redundancy, and multi-region designs usually push the cost up too.

Hidden or missed items are where underestimation usually happens: backups, snapshots, reserved public IPs, load balancers, monitoring and log analytics, storage transactions, and old disks left behind after a VM was deleted.

4. Pricing Calculator, TCO Calculator, and Cost Management

This distinction shows up constantly in AZ-900 questions:

• Azure Pricing Calculator: estimate the cost of a planned Azure deployment.
• Azure TCO Calculator: compare on-premises total cost of ownership with Azure.
• Azure Cost Management + Billing: analyze actual Azure spend and usage after deployment.

The Pricing Calculator is for design-time estimation. You choose services, sizes, regions, and assumptions. The output is an estimate, not a bill. The TCO Calculator is for migration business cases. You plug in assumptions about your current setup — things like server count, storage, networking, power, cooling, and support — and then compare that against Azure. Cost Management is the tool you use once things are running for real, for things like cost analysis, budgets, alerts, forecasting, exports, and trend review.

One more distinction helps in practice: invoices and billing statements show what was billed, but Cost Management is the analysis layer that helps you spot patterns and optimize them.

5. Using the Azure Pricing Calculator in Practice

A good estimate starts with a realistic workload definition. Suppose you want to estimate a small production web app with two virtual machines, managed disks, a storage account, and outbound traffic.

A practical workflow usually looks something like this:

• Choose the target region.
• Add the VM service and select family, size, operating system, and expected runtime.
• Add managed disks and choose disk type and quantity.
• Add storage and choose capacity and redundancy.
• Add estimated outbound bandwidth.
• Don’t forget to include supporting services like public IP, load balancer, backup, or monitoring if they apply.
• It’s also worth comparing assumptions across regions or pricing models.

For example, if you estimate two always-on VMs but forget backup, log ingestion, storage transactions, and egress, your estimate may look artificially low. That is one of the most common reasons estimated cost and actual billed cost differ.

The Pricing Calculator is especially useful for side-by-side comparisons:

• Region A versus Region B
• Pay-as-you-go versus reservation assumptions
• Standard storage versus premium storage
• Single instance versus multi-instance design

Its limitation is simple: it is only as good as the assumptions you enter.

6. Azure Purchase and Discount Options

Azure does not have only one purchasing model. Understanding the major options helps with both exam questions and real budgeting.

Reservations are not just for VMs; Azure offers reservation-style discounts for some other eligible services as well. Savings Plan for Compute is more flexible across some compute usage patterns than a specific reservation. Spot VMs are excellent for batch jobs, large-scale testing, rendering, or analytics workloads that can restart. They are a poor fit for critical systems that must remain continuously available.

For AZ-900, the safe exam idea is this: predictable usage favors commitment-based discounts, interruptible usage may fit Spot, and uncertain usage fits pay-as-you-go. Eligibility, scope, and discount details vary, so always confirm current official service guidance.

7. Hidden and Commonly Missed Azure Cost Components

Many Azure bills grow because teams estimated only the obvious resources. A more complete pre-deployment checklist should include:

• Outbound data transfer
• Backup vault usage and retention
• Snapshots and recovery points
• Monitoring and Log Analytics ingestion and retention
• Public IP addresses and load balancers
• Storage transactions and replication choice
• OS or software licensing where applicable
• Idle or orphaned resources such as unattached disks

Here is a simple real-world pattern: VM count stayed the same, but the bill increased. Why? Maybe backups kept more data than expected, logs grew because verbose diagnostics were turned on, outbound traffic spiked after a marketing campaign, or a standard disk got replaced with premium storage. Those are exactly the kinds of changes teams miss if they watch only compute.

8. Using Azure Cost Management + Billing

Azure Cost Management + Billing is the operational tool for understanding actual spend. It supports cost analysis, budgets, alerts, forecasting, exports, and trend review across scopes like management groups, subscriptions, and resource groups, depending on permissions and billing setup.

Useful capabilities include:

• Cost analysis: break down spend by service, resource, location, or tag.
• Budgets: set thresholds and notify stakeholders.
• Forecasting: estimate whether current trends will exceed budget.
• Exports: send cost data for recurring reporting or deeper analysis.
• Optimization review: identify unusual growth patterns and investigate them.

A practical way to handle budgets is pretty straightforward: pick a scope, set a monthly amount, define thresholds like 80% and 100%, and send alerts to the resource owner or finance contact. Then check forecast alerts before the month ends, not after the invoice shows up.

When investigating a spend increase, I’d start with this sequence:

1. First, identify the affected scope: management group, subscription, or resource group.
2. Review cost by service to find the largest change.
3. Drill down by resource and by tag.
4. Check recent deployments, scaling events, or configuration changes.
5. Review networking, log ingestion, backup growth, and storage expansion.
6. Look for idle or orphaned resources.

This diagnostic pattern is more valuable than memorizing screens. That’s what teaches you how to explain a bill instead of just reading one.

9. How to Optimize Azure Costs

Cost optimization means cutting waste without breaking the workload. The highest-value actions are usually governance, visibility, and rightsizing.

Tags improve accountability. Common tags include Environment, Owner, Application, and CostCenter. Tags are especially useful for showback and chargeback reporting.

Rightsizing means validating utilization before resizing a service. If a VM or database consistently uses far less than its allocated capacity, a smaller SKU may be sufficient. Always confirm performance impact before changing production resources.

Stop or deallocate idle resources. This matters a lot for Azure VMs. Shutting down a VM from inside the guest operating system may not stop compute charges. To stop Azure VM compute billing, the VM must be deallocated. Even then, disks, backups, snapshots, and some networking components may still incur charges, so deleting unused resources may be necessary.

Use lifecycle and scheduling. Dev and test VMs do not always need to run 24/7. Scheduled shutdowns are a simple way to cut waste. Storage lifecycle rules can move older data into cooler, cheaper tiers when the access pattern makes that a good idea.

Review discount options regularly. Stable workloads may justify reservations. Variable but ongoing compute may fit an Azure Savings Plan for Compute. Batch or fault-tolerant processing may fit Spot VMs.

10. Cost Governance Basics in Azure

Governance is what turns cost control from a one-time cleanup into something you can repeat and actually manage. In Azure, the main building blocks are management groups, subscriptions, resource groups, and tags.s, Azure Policy, and RBAC.

A common hierarchy looks like this:

• Management Group: Corporate
• Subscriptions: Production, Dev/Test, Sandbox
• Resource Groups: App-specific or team-specific groupings
• Tags: Owner, CostCenter, Environment, Criticality

This structure helps separate billing, access, and policy enforcement. For example, a sandbox subscription may allow experimentation, while production subscriptions may have tighter controls.

Azure Policy can directly support cost control. You can require tags, restrict allowed regions, or limit expensive SKUs. That is useful because cost problems are easier to prevent than to explain later.

RBAC also matters, but with a nuance: infrastructure permissions and cost visibility are not always identical. Access to billing data can depend on billing scope permissions and Cost Management access configuration in addition to standard resource access. At a fundamentals level, the key idea is least privilege: only the right people should be able to deploy costly resources or view sensitive billing data.

11. What Is an SLA in Azure?

An SLA, or Service Level Agreement, is Microsoft’s published commitment to a certain level of availability for a service under documented conditions. It is not a guarantee of zero downtime, and it is not the same as overall business continuity.

This distinction matters. A service can have a strong SLA, but your application can still be unavailable if you deploy it in a single-instance design, misconfigure it, or depend on other components that fail. Published SLA values are service-specific and may depend on deployment topology, tier, or instance count. In other words, the documented SLA often applies only when the architecture meets the service’s stated conditions.

SLAs may include service credits if Microsoft does not meet the documented availability target. Those credits are typically the contractual remedy, but they do not automatically cover business losses, and they usually require a claim process subject to terms.

Free tiers, trial offerings, and preview features may not include the same SLA commitments as generally available paid services. Preview services typically do not carry the same production commitments, support guarantees, or SLA coverage as generally available services unless explicitly stated.

One more exam trap: support plans affect support response and advisory options, not the availability percentage defined in the SLA.

12. Interpreting SLA Percentages as Downtime

Availability percentages sound abstract until you translate them into downtime. The exact interpretation depends on the service terms and measurement period, but the following approximations are useful for intuition:

This is why “99.9%” is not the same as “basically always available.” Small changes in percentage can represent a meaningful difference in downtime. It is also why higher availability designs usually cost more.

13. Composite SLA and Availability Design

Composite SLA describes the availability of a solution made up of multiple dependent components. For serial dependencies, where every component must work for the solution to work, you multiply the availability values.

Example with two dependent services:

99.95% × 99.99% = 0.9995 × 0.9999 = 0.99940005 ≈ 99.94%

Example with three dependent services:

99.95% × 99.99% × 99.9% = 0.9995 × 0.9999 × 0.999 = 0.9984006495 ≈ 99.84%

That drop is normal. More dependencies usually reduce composite availability when they are all required for end-to-end success.

But there is an important nuance: redundant or parallel components are modeled differently. If you place two instances behind a load balancer and the service can continue when one instance fails, effective availability can improve rather than decline. So the multiplication rule is most useful for dependent serial components, not for every architecture pattern.

For AZ-900, the exam-safe takeaway is:

• Dependent components usually reduce composite SLA.
• Redundancy can improve effective availability.
• Architecture matters more than looking at one SLA number in isolation.

14. Architecture Patterns That Change Cost and Availability

Availability is not just a service property; it is a design decision. Azure offers several resilience patterns, each with cost implications.

Availability Sets apply to Azure VMs and distribute them across fault and update domains. Availability Zones are physically separate locations within supported regions, but not every service or region supports them the same way. Region pairs are a Microsoft resiliency concept that can support disaster recovery planning, but they do not by themselves create application failover. Disaster recovery still depends on the service capabilities and your replication and failover design.

High availability focuses on minimizing interruption during localized failures. Disaster recovery focuses on restoring service after major outages. Those are related, but not identical.

15. Troubleshooting Unexpected Azure Spend

If your Azure bill is higher than expected, do not start by guessing. Use a structured troubleshooting process.

1. Check scope: Which management group, subscription, or resource group changed?
2. Check service breakdown: Did compute, storage, networking, or monitoring increase?
3. Check resource breakdown: Which exact resources drove the increase?
4. Check tags: Which team, app, or environment owns the spend?
5. Check recent changes: New deployment, autoscale setting, backup policy, or retention change?
6. Check hidden items: Egress, snapshots, unattached disks, public IPs, log ingestion, stale backups.

Common root causes include:

• Autoscaling added more instances than expected
• VMs were shut down in the OS but not deallocated
• Outbound traffic increased
• Monitoring or diagnostic logs expanded sharply
• Premium tiers or stronger redundancy were selected
• Old snapshots, disks, or backups were never cleaned up

This is also where good governance pays off. Strong tags, budget alerts, and policy controls make cost investigations much faster.

16. Support Plans, Preview Services, and AZ-900 Exam Traps

These are the mistakes commonly tested:

• Support plan ≠ SLA. Support plans affect support response and case handling, not uptime percentage.
• Pricing Calculator ≠ actual bill analysis. It estimates future cost.
• TCO Calculator ≠ Azure usage monitoring. It compares on-premises and Azure cost assumptions.
• Cost Management ≠ predeployment estimate. It analyzes actual spend.
• Higher availability usually increases cost.
• Composite SLA decreases for dependent components.
• Preview services typically do not have standard production SLA commitments.

A quick memory aid works well here: Support helps people; SLA covers service availability.

17. AZ-900 Rapid Review and Practice

Memorization grid:

• Pricing Calculator = estimate future Azure cost
• TCO Calculator = compare on-premises with Azure
• Cost Management + Billing = monitor and analyze actual spend
• SLA = uptime commitment
• Support plan = support experience
• Composite SLA = multiplied dependent availability

Tool selection practice:

• You need to price a new app before deployment → Pricing Calculator
• You need to justify moving servers from a datacenter to Azure → TCO Calculator
• You need to find why storage cost rose 25% last month → Cost Management + Billing
• You need to understand uptime commitment for Azure SQL Database → the published SLA details for that service

Purchase option practice:

• Steady 24/7 workload → consider Reservations
• Variable but ongoing compute → consider Azure Savings Plan for Compute
• Interruptible batch processing → consider Spot VMs
• Eligible existing Microsoft licenses → consider Azure Hybrid Benefit

Final exam-safe reminders:

• Azure pricing is consumption-based, but meters differ by service.
• Outbound data transfer is a common hidden cost.
• Deallocate, not just shut down, to stop Azure VM compute charges.
• SLA percentages, conditions, and service credits are service-specific.
• Always verify current pricing and SLA details in official Microsoft service guidance.

If you remember the core idea, you will be in good shape for AZ-900: cost management helps you control what you spend, and SLAs help you understand the availability commitment your design is likely to deliver.