Microsoft Azure Fundamentals AZ-900: Azure Cost Management and Service Level Agreements

1. Introduction: Why Azure Cost and Availability Matter

Azure Fundamentals expects you to understand two ideas that are tightly connected: what a solution costs and how available it is expected to be. In practice, cloud design is never just “deploy the resource.” Every time you deploy something in Azure, you’re not just spinning up a resource — you’re also creating a cost pattern, an operating pattern, and an expectation around uptime.

For AZ-900, that means getting comfortable with the basics of Azure pricing, cost governance, billing tools, support plans, Service Level Agreements (SLAs), and the different availability options Azure gives you. Honestly, the cheapest design isn’t always the right one, and the most resilient design isn’t always the one your budget can comfortably live with. In my experience, good Azure decisions usually come down to balancing three things: what the business actually needs, what the budget can realistically support, and how much resilience the workload really needs.

2. How Azure Pricing Works: Core Cost Drivers

Azure uses a mix of consumption-based and fixed or commitment-based pricing. A lot of Azure services are billed based on usage, but some costs show up as recurring charges, license-based charges, reservation commitments, or even support-plan costs. Pricing can move around over time because of region, currency, agreement type, and service changes, so anything you see in a calculator is really just an estimate, not a hard promise.

For AZ-900, the big cost drivers you’ll want to remember are:

• Resource type: A VM, storage account, database, firewall, and AI service are billed differently.
• Usage: Compute runtime, storage capacity, transactions, requests, throughput, or data processed.
• Region: The same service can cost different amounts in different Azure regions.
• SKU or tier: Basic, Standard, Premium, and service-specific tiers affect both performance and price.
• Networking: Data ingress to Azure is typically free, while outbound internet egress is commonly charged. Inter-region traffic and some network services can also add cost.
• Licensing: Windows Server, SQL Server, and marketplace software may have separate licensing implications. If you’ve got eligible licenses, Azure Hybrid Benefit can help lower the cost.
• Subscription and billing agreement: Billing structure depends on the account and agreement model.
• Marketplace charges: Third-party products can add separate line items.

Service billing also varies by design. A VM may be billed for compute while running, managed disks for provisioned capacity, storage accounts for capacity plus transactions, and databases for provisioned performance or serverless consumption. Autoscaling can improve performance and availability, but it can also increase spend during busy periods.

Important cost gotcha: “Stopped” does not always mean “not billing.” If you shut down a VM from inside the guest operating system, you can still get billed for compute because the VM may still be allocated in the background. A VM in Stopped (deallocated) state generally stops compute charges, but attached managed disks, snapshots, backups, and some networking resources such as reserved public IPs may still incur charges.

3. Azure Pricing Calculator, Azure TCO Calculator, and Azure Cost Management + Billing all sound similar, but they’re used for very different jobs.

At first glance, these tools can feel confusingly similar, but each one has its own purpose.

• Azure Pricing Calculator: Estimates future Azure cost before deployment.
• Azure TCO Calculator: Compares on-premises cost with Azure for migration and business-case planning.
• Azure Cost Management + Billing: Reviews actual spend, trends, budgets, invoices, and forecasts after deployment. In day-to-day conversations, most people just shorten that to Azure Cost Management.

Exam shortcut: Estimate, Compare, Manage = Pricing Calculator, TCO Calculator, Cost Management.

A simple Pricing Calculator workflow is: choose a region, add a VM, add storage, add estimated outbound bandwidth, select licensing assumptions, and review the monthly estimate. A TCO workflow starts with current on-premises server, storage, power, support, and licensing assumptions, then compares those with Azure. Cost Management uses real billing data, so it is the tool for actual spending analysis.

4. How to Control and Track Azure Spend

Estimating cost is only the start. Azure gives you governance tools to monitor and control spend over time.

Budgets let you define a spending threshold at a management group, subscription, or resource group scope. Budgets can track both actual spending and forecasted spending, and they can trigger alerts when you hit thresholds like 80%, 90%, or 100%.

Important: budgets do not automatically stop spending. They generate alerts. To automate action, organizations commonly connect alerts to action groups, email notifications, automation workflows, serverless functions, runbooks, or internal approval processes.

Tags help organize and allocate cost, for example:

• Environment=Prod
• CostCenter=Finance
• Application=CRM
• Owner=AppTeamA

Tags are powerful, but they have limits. They are not automatically present everywhere unless enforced, and adding tags later does not automatically make all historical cost data perfectly categorized. In real environments, tag consistency matters as much as tag design.

Azure hierarchy for management is:

Management Groups → Subscriptions → Resource Groups → Resources

This hierarchy supports governance and policy inheritance. Billing, however, may also be organized above the subscription level depending on agreement type, such as billing account, billing profile, or invoice section.

Azure Policy and Azure RBAC solve different problems:

• Azure Policy controls what is allowed or required, such as approved regions, required tags, or allowed VM SKUs.
• Azure RBAC controls who can create, modify, or view resources and cost data.

Azure Advisor provides recommendations in categories such as cost, reliability, performance, security, and operational excellence. Its cost recommendations might point out rightsizing opportunities or idle resources, but they’re just recommendations — you should always validate them before touching production.

Practical budget workflow: open Cost Management + Billing, choose the scope, create a budget, set the amount and reset period, add alert thresholds, and assign notification recipients or action groups. Then you can use Cost Analysis to filter by subscription, resource group, service name, or tags so you can see exactly where the money’s going.

5. Common Azure Billing Gotchas

Unexpected Azure bills usually come from a few repeated patterns:

• A VM was shut down in the operating system but not deallocated, so compute charges continued.
• Managed disks, snapshots, backups, or reserved public IPs remained after compute was removed.
• Autoscaling increased instance count during high demand.
• Outbound data transfer or inter-region traffic was higher than expected.
• A Premium SKU or higher redundancy option was selected.
• Marketplace products or support-plan charges were added.

Troubleshooting a cost spike: check Cost Analysis by service and resource, review recent deployments, look for autoscale activity, confirm network egress, inspect unattached disks and snapshots, and verify whether a third-party marketplace item or support cost appeared.

6. Pay-as-you-go, Reservations, Savings Plans, and Azure Spot VMs are the main purchasing models you’ll run into.

Azure gives you a few different purchasing options, and the right one depends a lot on how predictable the workload is.

Reservations apply to specific eligible resource families or services, not to everything in Azure. Savings Plan for Compute is often more flexible for changing compute patterns. Azure Spot Virtual Machines are useful only when interruption is acceptable.

Rule of thumb: unpredictable = pay-as-you-go, predictable = reservation or savings plan, interruptible = Spot.

7. Support Plans, Billing Scope, and Licensing Basics

Support plans are separate from Azure resource consumption charges. They affect total cost, but they are not the same as VM, storage, or database usage charges. Plan names and response details can change over time, so for production decisions you should verify the current official service details.

For billing structure, a subscription is always a management boundary. Billing, however, can roll up at broader scopes depending on the agreement model, such as billing account, billing profile, and invoice section. That is why one organization may have multiple subscriptions but a consolidated invoice view.

Licensing can affect cost too. If you’ve got qualifying licenses, Azure Hybrid Benefit can lower the cost of eligible Windows Server and SQL Server workloads. That’s a fundamentals-level point, but it’s absolutely worth remembering: licensing decisions can make a real difference to Azure pricing.

8. What Is an SLA in Azure?

An SLA, or Service Level Agreement, is Microsoft’s contractual commitment for a service over a monthly service period under defined conditions. Depending on the service, the SLA may be expressed in terms of uptime, connectivity, successful transactions, or another service-specific measure.

An SLA does not mean zero downtime. If the documented SLA conditions are not met, the remedy is typically service credits, subject to exclusions, claim requirements, and the service’s SLA terms. Service credits are not the same thing as automatic reimbursement for all business loss.

Exam takeaway: SLA is the contract, high availability is the design, disaster recovery is the restore and failover plan.

9. Reading SLA Percentages and Composite SLA

Higher SLA percentages mean less allowable downtime in the monthly service period, not perfect uptime.

Composite SLA matters when multiple dependent services must all be available for the solution to work. In a simple serial dependency model, multiply the decimal availability values:

99.999.999.9% × 99.9% = 99.8001%

Put simply, two dependent services can pull the overall availability down below either service’s individual SLA. This multiplication shortcut applies to serial dependencies, not to every architecture.

Redundancy changes the picture. If a workload has parallel redundant instances and either one can serve traffic, effective availability can improve compared with a single-instance design. AZ-900 usually focuses on the serial-dependency concept, but it is important to know that redundant architectures are not calculated with the same simple multiplication rule.

10. How Azure Improves Availability

Azure has several availability options, and they’re definitely not all the same thing.

• Availability Sets: VM-focused feature that distributes VMs across fault domains and update domains within a datacenter to reduce the impact of hardware failure or planned maintenance.
• Availability Zones: Physically separate locations within a region with independent power, cooling, and networking. Zone support can vary by region and by service, so just because a region exists doesn’t automatically mean every service in that region supports zones.
• Regions: Geographic areas containing one or more datacenters.
• Region pairs: Azure-defined regional relationships used for certain platform recovery prioritization and update sequencing scenarios. They do not automatically provide disaster recovery for your application unless you architect replication and failover.

For modern VM design, zone-aware or zone-redundant deployment patterns are often preferred where supported. Availability Sets are still important to understand, especially for VM-focused exam questions. Many platform services use built-in redundancy models instead of Availability Sets.

Also remember that not all Azure services have the same SLA conditions. Some services require multiple instances or specific deployment patterns to qualify for higher SLA levels.

11. Cost vs Availability Tradeoffs

Availability improvements usually cost money. More instances, zone redundancy, cross-region replication, premium storage, and load balancing all improve resilience — but, naturally, they also add more cost and complexity too.

A simple way I like to think about it is this:

• Low-criticality dev/test: single VM, pay-as-you-go, lower cost, lower resilience.
• Production internal app: multiple instances or zone-aware design, budgets and monitoring, moderate cost.
• Business-critical customer-facing app: multi-instance, load balancing, zone redundancy, possibly cross-region disaster recovery, highest cost and strongest resilience posture.

Region and zone choices can also affect networking cost. A more resilient design can also bring in inter-zone or inter-region data transfer charges, so your architecture choices affect both uptime and the budget.

12. AZ-900 Exam Quick Review

• Pricing Calculator = estimate future Azure cost.
• TCO Calculator = compare on-premises vs Azure cost.
• Cost Management + Billing = analyze actual spend, budgets, forecasts, invoices.
• Budget = alerting threshold, not an automatic spending cap.
• Tags = organize and report cost; they do not replace RBAC or Policy.
• Azure Policy = rules and compliance.
• Azure RBAC = access permissions.
• SLA = contractual commitment, not zero downtime.
• Composite SLA = lower for serial dependencies.
• Availability Set = fault domains and update domains for VMs.
• Availability Zone = separate physical location within a region.
• Stopped VM in the operating system may still bill; Stopped (deallocated) generally stops compute charges.

13. Practice Scenarios and Final Takeaway

Scenario 1: You need to estimate a new web app before deployment. Use the Pricing Calculator.

Scenario 2: Leadership wants to compare current datacenter cost with Azure. Use the TCO Calculator.

Scenario 3: A subscription is exceeding its monthly target. Use Cost Management + Billing to review actual spend, create a budget, and filter by tags or resource groups.

Scenario 4: A batch rendering job can tolerate interruption. Consider Azure Spot Virtual Machines.

Scenario 5: A production VM runs continuously all year. Consider Reservations or a Savings Plan for Compute if the usage pattern is predictable.

The big takeaway is simple: Azure cost management and SLAs are connected. You need to understand what drives spend, what tools estimate versus measure cost, how governance controls waste, what an SLA really means, and how architecture choices such as Availability Sets, Availability Zones, and regional design affect both resilience and price. For the exam and for real-world Azure work, the goal is not maximum cost savings or maximum availability in isolation. The goal is the right balance for the workload.