Why Is My Azure Bill So High? Hidden Costs Explained
Azure bills have a way of being higher than expected without any obvious explanation. You look at your VMs, your databases, your storage buckets, and the numbers seem roughly consistent with what you're running. But the total is still wrong. The gap tends to live in a handful of predictable places that aren't prominently labeled on the invoice.
This post covers the categories that show up most consistently as unexplained spend, based on patterns we see repeatedly when reviewing Azure environments at Absolute Ops. Most of these are confirmed by multiple independent sources, which is a reasonable signal that they affect a wide range of organizations rather than edge cases.
VMs that aren't actually off
This one catches a lot of teams off guard, and it's Azure-specific behavior worth understanding clearly.
When you shut down a VM from within the operating system (issuing a shutdown command in Windows or Linux), the machine powers off but Azure does not release the underlying compute resources. The VM enters a "Stopped" state, not a "Stopped (Deallocated)" state. Azure is still reserving CPU and memory for it. You're still being billed for compute at the full hourly rate, even though the machine isn't doing anything.
To actually stop the billing, you need to deallocate the VM through the Azure Portal, CLI, or PowerShell. The az vm deallocate command explicitly does this. When a VM shows "Stopped (Deallocated)" in the portal, compute charges stop. When it just shows "Stopped," they don't.
This distinction catches engineers who assume a shutdown command is equivalent to stopping the resource in Azure. It also affects Azure ML compute instances, which have their own quirk: the standard stop option doesn't fully deallocate the underlying VM, and the only guaranteed way to stop compute billing on an ML instance is to delete it and recreate it when needed.
Even in the fully deallocated state, charges continue for attached managed disks, public IP addresses, and any backups associated with the VM. Deallocating stops the compute charge, not everything.
Orphaned resources accumulating quietly
Azure doesn't clean up after you. When a VM gets deleted, the managed disks attached to it stay behind unless you explicitly delete them too. The same applies to snapshots, network interfaces, load balancers provisioned for projects that ended, static public IP addresses, and Azure Container Registry images from old deployments.
None of these generate alerts. They appear on the bill month after month. In environments that have been running for several years across multiple teams, the accumulation can be substantial. One pattern cited across multiple reviews is that roughly a third of a typical Azure bill can come from resources that are no longer serving any purpose.
The specific resource types worth auditing: managed disks (charged at $0.075/GB/month for Premium SSD, regardless of whether they're attached to anything), static public IPs (charged whether in use or not), unattached network interfaces, and load balancers that have no backend pools.
Azure Monitor and Log Analytics ingestion
This is one of the most consistently reported sources of unexpected Azure spend, and it's gotten more prominent as organizations deploy more services and enable more diagnostic settings.
Azure Monitor charges for log ingestion by volume: $2.30/GB for Analytics Logs (after a 5 GB free monthly allowance) and $0.50/GB for Basic Logs. The pay-as-you-go rate applies unless you've set up a commitment tier. At $2.30/GB, a busy application environment or a Kubernetes cluster sending detailed container logs can generate significant charges without anyone explicitly deciding to spend that money.
Several specific patterns produce unexpected spikes. Enabling Microsoft Sentinel Content Hub solutions automatically turns on new data connectors, which start sending additional log tables to your workspace. Each connector added is volume added to your ingestion bill. Deploying Application Insights with default sampling settings on a high-traffic application sends far more telemetry than most teams realize or need. Container Insights enabled on an AKS cluster collects container logs, performance data, and metric tables that are all billable.
The fix involves auditing which tables in your Log Analytics workspace are actually being used for alerting, dashboards, or investigation, and reclassifying infrequently queried ones as Basic Logs or configuring data collection rules to reduce what's sent. Commitment tiers offer up to 30% savings compared to pay-as-you-go for workspaces ingesting consistently high volumes.
Data egress and inter-region transfer
Outbound data transfer from Azure to the public internet is charged at $0.087/GB for the first 10 TB per month in most regions. For applications serving significant traffic directly from Azure, or for architectures that replicate data across regions for disaster recovery, this becomes material quickly.
Inter-region transfers are also charged, and this surprises teams who assume data movement within Azure is free. It isn't. Data transferred between Azure regions is billed as outbound data transfer at standard rates. Teams running multi-region architectures, syncing databases across regions, or replicating blob storage should model this cost explicitly.
Keeping interconnected resources in the same region where possible, using Azure CDN to cache content closer to users, and reviewing whether all cross-region replication is actually necessary are the primary mitigations. Azure Front Door, which routes global traffic, can introduce data transfer costs that aren't obvious from the service description alone.
Auto-scaling misconfigurations
Azure's auto-scaling capabilities are useful, but misconfigured scaling rules can multiply costs faster than most other issues. A VM Scale Set configured to scale out aggressively on CPU load that then doesn't scale back in quickly (or at all) will accumulate instances until someone notices. There are documented cases of auto-scaling misconfigurations producing unexpected charges in the thousands of dollars within days.
Azure does not have a hard spending cap that stops services when a budget is exceeded. Azure Cost Management provides alerts when thresholds are crossed, but services continue running regardless. This means a misconfigured scaling rule, a retry loop that generates runaway API calls, or a development environment accidentally configured with production-tier scaling can run up a significant bill before the alert is seen and acted on.
Setting scale-in cooldown periods carefully, testing scaling behavior before deploying to production, and configuring budget alerts with action groups that can actually trigger remediation (not just email notifications) can help prevent these costs from getting out of control.
Storage tier mismatches and retrieval costs
Azure Blob Storage has four access tiers: Hot, Cool, Cold, and Archive. The storage cost per GB decreases significantly as you move to cooler tiers, but retrieval costs increase, and in the case of Archive, the retrieval times are measured in hours.
The trap is that teams configure lifecycle policies to move data to Archive (at $0.002/GB/month) to reduce storage costs, then later need to retrieve large datasets for analysis or compliance purposes without accounting for the retrieval charges. Archive retrieval is priced per GB read and can take up to 15 hours for standard rehydration. There's also an early deletion penalty if objects are moved to Archive and then retrieved or deleted before a minimum retention period.
Storage transactions are another line item that accumulates unexpectedly. Applications that frequently read, write, list, or query small amounts of data generate transaction charges that can exceed the storage charges themselves, particularly with Premium storage tiers.
Load balancer charges beyond the hourly rate
Azure Load Balancer and Application Gateway are both charged on a model that includes a data processing component beyond the hourly rate, and the data processing charge is where the unexpected costs appear.
Standard Load Balancer charges both a fixed hourly rate and a per-GB rate for data processed. Application Gateway charges by capacity units, which measure connection count, throughput, and compute usage simultaneously. In high-traffic applications, the capacity unit charges on Application Gateway can significantly exceed what the hourly rate alone would suggest.
Unused load balancers from decommissioned services continue to incur hourly charges indefinitely. In environments with many microservices, the count of load balancers can grow quietly through normal development activity and never gets reviewed.
The Hybrid Benefit and licensing you might not be using
If your organization has existing Windows Server or SQL Server licenses with Software Assurance, Azure Hybrid Benefit entitles you to use those licenses on Azure VMs at a reduced rate, saving up to 40% on Windows VMs and significantly more for SQL Server. Many Azure deployments, particularly those that were set up quickly or by teams without deep Azure billing knowledge, don't have Hybrid Benefit enabled despite being eligible.
This isn't a hidden cost per se, but it's a consistent source of overspend that shows up in billing reviews. Checking which VMs are running Windows or SQL Server and confirming Hybrid Benefit is applied where eligible is a straightforward audit step that sometimes produces immediate savings.
Getting a clear picture
The categories above appear consistently across multiple independent analyses of Azure overspend. Not all of them will apply to every environment, but in most Azure accounts that haven't been systematically reviewed, several will.
If you want a structured assessment of where your Azure (or AWS) spend is concentrated and what the highest-impact reductions would be, a free cloud audit is a practical starting point. We review cost patterns, resource configuration, and architecture and come back with a prioritized list of what to address. Get in touch to get started.
