Back to Blog
FinOps
8 min read

Azure Storage Costs: Why It's Probably Your Biggest Bill

AzureStorageCost OptimisationFinOps

Ask any Azure customer what they think costs them the most and they'll say virtual machines. It's a reasonable guess. VMs are the expensive, visible resources everyone monitors.

But when we actually break down Azure bills, storage is often the single biggest cost category. Not by a small margin either. In many estates we assess, storage accounts for over a fifth of total spend, and sometimes significantly more than that.

Nobody expects it. And that's exactly why it gets so out of control.

Storage Is Everywhere

The reason storage dominates isn't that individual storage accounts are expensive. It's that everything in Azure generates storage, and it all adds up.

Think about what's sitting in your Azure estate right now:

  • Blob storage - Files, images, application data, exports
  • Azure File Shares - Mapped drives, FSLogix profile containers
  • Managed disks - OS disks, data disks, temporary disks
  • Disk snapshots - Taken for backup or migration and never cleaned up
  • Boot diagnostics - Enabled on every VM, writing to a storage account
  • Diagnostic logs - Every resource pumping logs into storage
  • Backup vaults - VM backups, SQL backups, file share backups
  • SQL database backups - Automated backups with default retention
  • Log Analytics workspaces - Ingesting gigabytes of telemetry daily
  • Recovery Services vaults - ASR replication data for disaster recovery

Every single one of those is a storage cost. And most of them were set up once and never reviewed again.

The "Set and Forget" Problem

Here's what typically happens. Someone provisions a storage account during a project. They choose the defaults because the project has a deadline and storage configuration isn't the priority. The project ships. Everyone moves on.

Six months later, that storage account is still there, still on the default settings, still growing. Nobody owns it. Nobody reviews it. The monthly cost creeps up so gradually that it never triggers an alert.

Now multiply that by every project, every team, every subscription in your organisation. You end up with dozens or hundreds of storage accounts, all quietly accumulating data and cost.

This is fundamentally different from VMs. When a VM is too expensive, someone notices because it shows up as a single line item. Storage costs are distributed across so many small charges that no individual one looks concerning. It's death by a thousand cuts.

The Services That Generate the Most Storage

Not all storage is created equal. Some Azure services are particularly aggressive at generating storage costs.

Backup Vaults

Azure Backup is brilliant at protecting your data. It's also brilliant at running up your storage bill. Every VM backup creates a recovery point. Every recovery point is stored data. Default retention policies keep far more recovery points than most organisations actually need.

We regularly see backup storage that costs more than the VMs being backed up. That's not an exaggeration.

Diagnostic Logging

When you enable diagnostic settings on Azure resources (and you should, for operational reasons), all that telemetry has to go somewhere. Storage accounts, Log Analytics workspaces, Event Hubs - they all cost money.

The issue isn't enabling diagnostics. The issue is never setting retention policies. Logs from three years ago that nobody will ever look at are still sitting there, billing you monthly.

Disaster Recovery Replication

Azure Site Recovery replicates your VMs to a secondary region. That replication data is stored as managed disks and cache storage accounts in the target region. If you're replicating a large estate, the DR storage costs alone can be substantial.

Snapshots

Disk snapshots are cheap per-GB, but they accumulate fast. Teams take snapshots before changes, intending to delete them afterwards. They don't. Months later, you've got snapshots of disks that no longer exist, still costing money.

The Redundancy Multiplier

This is the one that catches people out the most.

When you create a storage account, you choose a redundancy option. The default for most account types is LRS (Locally Redundant Storage) - three copies within a single data centre. That's the baseline cost.

But many organisations choose GRS (Geo-Redundant Storage) for important data. GRS replicates your data to a paired region, effectively doubling your storage footprint. The cost reflects that.

RedundancyCopiesApproximate Cost Multiplier
LRS3 (single DC)1x (baseline)
ZRS3 (across zones)~1.2x
GRS6 (two regions)~2x
RA-GRS6 + read access~2.5x
GZRS6 (zone + geo)~2.4x
RA-GZRS6 + read access~3x

The question is: does all your data actually need geo-redundancy?

Backup data that's already a copy of production data probably doesn't. Diagnostic logs almost certainly don't. Temporary processing data definitely doesn't. But if the storage account was created with GRS and nobody changed it, you're paying double for data that could be on LRS.

We've seen organisations cut their storage bill by a third just by reviewing redundancy settings and downgrading non-critical data to LRS or ZRS.

Hot Tier by Default

Most Azure Blob Storage defaults to the Hot access tier. Hot is designed for frequently accessed data and has the highest per-GB storage cost.

The reality? Most data in most storage accounts is rarely accessed. Backups, logs, archives, old exports - they're sitting in Hot tier pricing because that's what was configured when the account was created.

We've written a detailed guide to storage tiers and lifecycle policies that covers how to move data to Cool, Cold, or Archive tiers. The short version is that moving infrequently accessed data to the right tier can save anywhere from half to over ninety percent on storage costs for that data.

Why This Matters for Your FinOps Practice

Storage costs behave differently from compute costs, and your FinOps approach needs to account for that.

Compute costs are spiky and visible. Someone spins up a large VM, the bill jumps, you notice.

Storage costs are slow and cumulative. They grow a few percent each month. By the time anyone flags it, years of accumulated data are sitting there.

This means the standard FinOps approach of watching for cost anomalies doesn't catch storage waste. You need to proactively audit storage on a regular schedule.

Here's what that audit should cover:

CheckWhat to Look For
Redundancy reviewGRS/RA-GRS on non-critical data
Access tier reviewHot tier data that's rarely accessed
Retention policiesBackups and logs with no expiry
Orphaned snapshotsSnapshots of deleted or changed disks
Unattached disksManaged disks not connected to any VM
Backup vault sizingRetention periods longer than required
Log Analytics retentionDefault 30-day vs actual need
Boot diagnosticsEnabled on VMs that don't need it

Most organisations have never done a comprehensive storage audit. When we run one, the findings are almost always surprising.

The Compounding Effect

Storage has a property that compute doesn't: it compounds. Data accumulates over time. Backups stack up. Logs pile on. Snapshots multiply.

A VM costs the same this month as it did last month (assuming no changes). But your storage bill this month is almost certainly higher than last month, because more data has been written than deleted. Without active management, storage costs only ever go in one direction.

This is why storage creeps to the top of the bill. It's not that any single storage decision was wrong. It's that hundreds of small, reasonable decisions compound over months and years into something that dominates your spend.

What to Do About It

The first step is knowing where you stand. Most organisations are genuinely surprised when they see storage broken out as a percentage of their total Azure spend.

The second step is understanding which storage is necessary and which is waste. Not all storage is bad - you need backups, you need logs, you need redundancy for critical data. The waste is in the defaults that were never reviewed, the retention policies that were never set, and the redundancy levels that don't match the data's importance.

The third step is making it someone's job. Storage costs need an owner who reviews them regularly, not just someone who sets up the account and walks away.


Not sure how much of your Azure bill is storage? Our free savings snapshot breaks down your spend by category and identifies the biggest storage savings opportunities.

How mature is your cloud cost management?

Take our free 2-minute FinOps maturity test and get a personalised improvement roadmap.