Azure Cost Management and Service Level Agreements for AZ-900: Practical Fundamentals, Common Traps, and Real-World Thinking

Introduction: why Azure cost management and SLAs matter

For AZ-900, Azure cost management and SLAs aren’t little side quests. Honestly, this is where teams start asking the real questions: what’s this workload going to cost, how will that bill land once it’s live, and how much uptime can we actually count on if things wobble?

And no, those aren’t just finance questions. They tug at architecture, approval chains, governance rules, even the way support gets talked about in the room. It all spills over.

The simplest mental model still wins: estimate before deployment, monitor after deployment, optimize continuously, and design availability intentionally. Keep these terms apart too: pricing is the expected cost of a service, billing is what shows up on invoices and cost reports, cost optimization is how you trim waste, and SLA is Microsoft’s service-specific availability commitment under defined terms.

Azure pricing and the main cost drivers

Azure commonly uses pay-as-you-go pricing, but not every charge is purely usage-only. Azure also includes commitment-based options such as Reservations and the Azure Savings Plan for Compute, plus support plans and marketplace charges. For AZ-900, the key point is that Azure pricing can be consumption-based, commitment-based, or a mix of both.

Charges depend on service type, region, SKU, redundancy, licensing, and network usage. Billing units vary from one service to another, which is where beginners tend to get tangled, honestly. Compute may be billed by runtime, storage by GB-month, transactions by request count, and bandwidth by data transferred. Inbound data transfer is often free for many Azure services, while outbound internet egress commonly incurs charges. Some inter-region traffic can also cost money.

Not all services, SKUs, or features are available in every region, so region affects both architecture choices and estimates. Storage is a good example of a cost-versus-resilience tradeoff: LRS, ZRS, and GRS/GZRS provide different redundancy levels and different prices.

What often appears on a monthly bill: compute, managed disks, snapshots, backup, bandwidth, monitoring and log ingestion, marketplace software, and support. A VM workload rarely means “just the VM.”

Resource organization, billing scopes, and governance

Azure organization affects both governance and cost visibility. Management groups help organize subscriptions for policy and oversight. Subscriptions are important governance, quota, and billing scopes, but billing can roll up differently depending on the agreement model such as MCA, EA, or CSP. Resource groups are logical containers, not guaranteed lifecycle boundaries. Resources in one resource group can still have different owners or lifecycles.

Tags improve showback and chargeback, but they’re not some magic spell. Tags aren’t always inherited automatically in every scenario, not every resource type supports them equally, and some cost records may still appear untagged. So tagging needs standards, enforcement, and a bit of checking.

A practical tagging baseline for AZ-900-level governance is:

• Department
• Environment
• Application
• Owner

Azure Policy can help enforce required tags, restrict expensive SKUs, and limit deployments to approved regions. Typical policy effects include Deny, Audit, and Append/Modify. Example uses: require Department and Owner tags, allow only approved VM sizes, or deny deployment outside selected regions.

RBAC and billing access are related but not identical. Azure RBAC controls access at the management group, subscription, resource group, or individual resource scope level, depending on where you assign the role. So yes, scope really matters here. Cost visibility can also depend on billing roles and Cost Management permissions. In other words, being able to manage a VM does not automatically mean you can see all invoice data.

Azure tools: estimate first, then monitor actual spend

Pricing Calculator: build an estimate by selecting a service, region, SKU, runtime assumptions, storage, bandwidth, and related items such as backup. It estimates list pricing and may not reflect taxes, negotiated discounts, billing currency effects, or actual runtime behavior unless you model them.

Worked estimate example: a small VM for a dev workload may also need an OS disk, outbound bandwidth, backup, and perhaps a public IP. If you change the region or move from a Standard disk to a Premium one, the estimate changes too. That sounds obvious after the fact, but it’s really easy to miss when you’re building the estimate the first time. That’s why first estimates often come in low: people model the VM and forget the baggage around it.

TCO Calculator: use it when comparing an on-premises workload with Azure. The inputs usually include servers, storage, networking, power, facilities, and software licensing costs. It supports business-case conversations, not day-to-day cloud bill review.

Microsoft Cost Management: use it after deployment to analyze real charges. You can filter and group by subscription, resource group, service name, region, tag, and more, which is very handy when you’re chasing down spend. It also supports forecasting and exports, which is really handy when you’re trying to explain spend trends to stakeholders without hand-waving. One practical caution: cost data can have some latency, so it is not always real-time to the minute.

Budgets, alerts, and what they do not do

Budgets are useful, but AZ-900 questions love this trap: budgets do not automatically stop resources. Budgets create alerts and notifications. If you want automated action, you must connect alerts to something else such as Azure Monitor action groups, Logic Apps, Azure Automation, or Functions.

A simple workflow looks like this:

• Create a monthly budget at subscription, resource group, management group, or supported billing scope
• Set thresholds such as 80%, 90%, and 100%
• Send alerts to owners, operations, or finance
• Optionally trigger automation for nonproduction cleanup or shutdown

That last step is separate from the budget itself. The budget alerts; automation does the actual moving.

Cost optimization techniques that actually matter

Cost optimization is an ongoing cycle: baseline spend, identify top cost drivers, validate utilization, optimize, measure savings, repeat. The most useful AZ-900 techniques are right-sizing, cleanup, commitment discounts, licensing benefits, and governance.

Right-sizing: choose a VM or service tier that matches demand instead of overprovisioning for a worst case that almost never shows up.

Cleanup: remove unattached disks, old snapshots, forgotten test resources, unused public IPs, and stale backups where appropriate.

Azure Advisor: review cost recommendations, but treat them as advisory. Validate them against workload requirements before acting.

VM billing states matter:

• Running = compute billed
• Stopped (Allocated) = compute still billed
• Stopped (Deallocated) = compute charges stop
• Managed disks/storage = still billed either way

That distinction causes a lot of bill surprises. A VM shut down from inside the guest OS may remain allocated. To stop compute charges, it generally needs to be deallocated in Azure.

Reservations vs Savings Plan vs pay-as-you-go

Reservations are typically best when usage is steady and well understood. Savings Plan is useful when compute usage is predictable but might move across eligible services. They’re not the same thing, and that’s an easy exam trap. Reservations are more resource-specific; Savings Plan applies to eligible compute usage up to an hourly commitment.

Azure Hybrid Benefit is another savings lever, but only for eligible licenses and workloads, such as qualifying Windows Server or SQL Server scenarios under Microsoft licensing terms. It is powerful, but you should not assume every existing license qualifies automatically.

Support plans and other billing considerations

Basic support for subscription management and billing is available without buying a high-end technical support plan. Paid support plans mainly affect technical support response capabilities, and response times vary by severity and plan level. Offerings can change over time, so for AZ-900 focus on the concept: support level affects both operational readiness and total cost.

Also remember that free accounts and free services are not a permanent shield against charges. Exceeding free limits or retaining billable resources can still create costs.

Understanding Azure SLAs, service credits, and exclusions

An Azure SLA is a service-specific availability commitment defined in Microsoft’s official SLA documentation. For AZ-900, think of SLA primarily as an availability promise measured over a monthly period under documented conditions. It is not a guarantee of zero downtime and it is not the same as your application’s end-to-end uptime.

SLAs include conditions, exclusions, and remedies. If the service does not meet the stated commitment, the usual remedy is a service credit, not compensation for all business losses. Credits may require meeting claim conditions and following Microsoft’s claim process; they are not always automatic.

Approximate downtime in a 30-day month looks like this:

• 99.9% ≈ 43.2 minutes/month
• 99.95% ≈ 21.6 minutes/month
• 99.99% ≈ 4.32 minutes/month

One important nuance: the headline SLA often applies only if you deploy the service according to Microsoft’s documented requirements. For example, some VM availability commitments depend on architecture choices like multiple instances in an Availability Set or across Availability Zones. Do not assume every single-instance deployment gets the highest advertised SLA automatically.

Composite SLA and availability design choices

Composite SLA matters because applications depend on multiple services. If components are independent and all are required in series, you can estimate combined availability by multiplying the percentages.

Example: App Service 99.95% × SQL Database 99.99% × Storage 99.9% = 0.9995 × 0.9999 × 0.999 = 0.9984006495, or about 99.84%. That’s lower than any single component. This simple multiplication does not apply the same way to redundant parallel designs.

Availability design options increase resilience but usually add cost and complexity:

• Single instance: cheapest, but a single point of failure
• Availability Set: distributes VMs across fault domains and update domains within an Azure datacenter
• Availability Zones: uses separate physical locations in a region with independent power, cooling, and networking
• Cross-region DR: replication and failover design across regions

Not every service, SKU, or region supports zones. Some services are zonal, some are zone-redundant, and some don’t support zones at all. Region pairs help with Azure geography design and resiliency planning, but they do not automatically provide failover or disaster recovery for your application. Customers still need to configure replication, backup, and failover where required.

High availability keeps services running during common failures. Disaster recovery helps you recover from larger outages. Useful awareness terms are RTO (how quickly you need to recover) and RPO (how much data loss is acceptable).

Troubleshooting unexpected Azure charges

If a bill is higher than expected, do not guess. Use Microsoft Cost Management and work through the evidence:

1. Confirm the scope: billing account, subscription, or resource group
2. Group charges by service, resource, region, and tag
3. Check for SKU mismatch: Premium instead of Standard, larger VM size, higher redundancy
4. Verify VM state: running, stopped allocated, or deallocated
5. Inspect egress and inter-region traffic
6. Look for storage growth, snapshots, backups, unattached disks, and retained logs
7. Check Azure Monitor/Log Analytics ingestion and retention
8. Review Marketplace and support charges
9. Compare actual deployment with the original estimate assumptions

A classic case is expecting a $300 month and seeing $520 because the VM used Premium storage, the VM was stopped but not deallocated, outbound traffic grew, and log ingestion increased.

AZ-900 exam prep: traps, cues, and quick practice

Memory map: Pricing Calculator = estimate. TCO Calculator = compare on-premises cost with Azure. Cost Management = actual spend. Budget = alert, not shutdown. SLA = Microsoft service commitment. HA = architecture for uptime. DR = recovery from major outage.

Common traps:

• “Pricing Calculator shows my exact bill” → No, it is an estimate
• “Budget will stop resources automatically” → No, separate automation is required
• “Stopping a VM always stops all charges” → No, deallocation matters and storage still costs money
• “SLA means no downtime” → No, it is a defined service commitment with exclusions and credits
• “Using a region pair means I automatically have DR” → No, replication and failover must still be designed

Quick question patterns:

1. If the question asks which tool compares on-premises cost to Azure, think TCO Calculator.
2. If the question asks how to track actual monthly spend and create budgets, think Microsoft Cost Management.
3. If the question asks how to improve resilience of a single-VM design in one region, think redundancy such as Availability Set, Availability Zones, or broader DR architecture depending on the scenario.

Final review

For AZ-900, the essentials are straightforward: use the Pricing Calculator and TCO Calculator before deployment, use Microsoft Cost Management after deployment, understand that budgets alert but do not stop resources, know the difference between stopped and deallocated, and remember that an SLA is not the same as application uptime. Cost control comes from governance, monitoring, and optimization — and in real Azure environments, you really do need all three working together.

And availability? That comes from architecture, not wishful thinking.