Most storage cost problems come from the same root cause: nobody knows what is in there. Blobs accumulate over years, teams change, workloads come and go, and the data stays. You end up paying for gigabytes — or terabytes — of objects that nobody can confidently say are still needed.
Azure Blob Inventory is the starting point for fixing that. It generates a regular export of every blob in a storage account, with enough metadata to answer the questions that actually matter for cost management: how much is there, how old is it, when was it last accessed, and is it using the right storage tier?
This article looks at what Blob Inventory actually gives you, how to use it for cost work, and what to watch out for when you set it up.
What It Does
Blob Inventory runs on a schedule you define — daily or weekly — and produces a CSV or Parquet file listing every blob (and optionally every container) in a storage account. You choose a destination container where the output files are written, and you configure which fields to include in the report.
The key thing to understand is that Blob Inventory is a per storage account feature. If you have 50 storage accounts, you need to enable it on each one individually. It does not give you a cross-account view — that is what Azure Storage Discovery is for. Blob Inventory is for drilling into the detail of a specific account once you have identified it as a problem or a candidate for optimisation.
Why This Is More Useful Than It Looks
At first glance, a CSV of blob names and sizes sounds underwhelming. The value comes from what you can do with the data once you have it.
Finding blobs in the wrong tier
Storage tiers exist precisely because not all data is accessed equally. A blob sitting in Hot tier that was last accessed two years ago is costing several times more than it would in Cool or Archive. Without inventory data you have no systematic way to find these blobs. With an inventory file you can filter to blobs where LastAccessTime is older than 90 days and AccessTier is Hot — and immediately have a list of candidates for tier changes.
Understanding the true size of soft-deleted data
One of the most common storage cost surprises is soft-deleted blobs. When soft delete is enabled on a storage account, deleted blobs are retained for a configured period before permanent deletion. They are not free — you pay for their storage throughout the retention period. The inventory report includes the Deleted field and RemainingRetentionDays, which lets you calculate how much you are paying for data that has already been deleted but is still being retained. If soft delete retention is set to 30 days but blobs are typically large, this can be a meaningful cost.
Identifying old and forgotten data
Filtering the inventory by Last-Modified date is a quick way to surface blobs that have not been touched in a long time. Blobs that have not been modified in over a year and have a LastAccessTime showing similar inactivity are strong candidates for archiving or deletion. This is the kind of analysis that is nearly impossible to do manually in the portal but straightforward once you have an inventory file.
Practical Questions You Can Answer With Blob Inventory
How much data in this storage account is actually being accessed?
Enable LastAccessTime tracking on the account (it needs to be turned on explicitly before it starts populating), then once you have an inventory file, filter to blobs where LastAccessTime is within the last 30 or 90 days. The remaining blobs — those with no recent access — represent storage you are paying for with no apparent active workload consuming it.
How much are we spending on data that is already deleted?
Filter the inventory for rows where Deleted is true and sum Content-Length. Multiply by the storage cost per GB for the relevant tier. This gives you the cost of soft-deleted data in your retention window. If the number is significant, consider whether the soft delete retention period is longer than it needs to be.
Which blobs should be moved to a cooler tier?
Filter for AccessTier = Hot and LastAccessTime older than your threshold (typically 30–90 days depending on your workload). Sort by Content-Length descending to prioritise the largest blobs first. The biggest wins will be large blobs that have not been accessed in months but are still in Hot tier.
How much of our storage is snapshots and versions?
If you include snapshot and version fields in the inventory rule, you can filter to rows where Snapshot is populated or IsCurrentVersion is false. In accounts where versioning has been enabled for a long time without a lifecycle policy to clean up old versions, this can represent a significant and entirely invisible cost.
Which containers are growing fastest?
Compare inventory files from different dates. Group by container (extract the container name from the blob path), sum Content-Length per container for each date, and calculate the delta. Containers with accelerating growth are the ones to discuss with the owning team before the cost gets out of hand.
What to Watch Out For
The output folder will grow quickly
Every inventory run writes a new file to the destination container. With a daily schedule on a large account, you will accumulate 365 files in a year, and each file could be hundreds of megabytes for a large account. If you forget about this, the destination container itself becomes a cost. Set up a lifecycle policy on the destination container to automatically delete inventory files older than a certain number of days — keep the last few runs and clean up the rest.
LastAccessTime requires explicit opt-in and has a delay
Access time tracking is not enabled by default. You have to turn it on in the Blob Inventory settings, and once enabled, it only records the first read within each 24-hour window (to avoid performance impact on read-heavy accounts). This means you need to wait for access tracking to accumulate meaningful data before using LastAccessTime for tier decisions. Enable it as soon as you start using inventory, even if you are not using the data yet.
Container inventory is of limited value for cost work
Blob Inventory can run in either blob or container mode. Container mode gives you per-container metadata but not the individual blob details. For cost optimisation purposes the blob report is almost always what you want — the container report alone does not tell you enough about what is inside the containers to drive any action.
Including versions and snapshots adds significant output volume
If your account has versioning enabled and blobs have accumulated many versions over time, including VersionId and IsCurrentVersion in your inventory rule can multiply the output size dramatically. For a first run, it is often worth starting without versions and snapshots to get a baseline, then adding them once you understand the account structure.
It is per account — scale requires automation
If you have 30 storage accounts and want inventory running on all of them, you will need to either configure each one manually or use Azure Policy or scripting (PowerShell or CLI) to deploy inventory rules at scale. There is no tenant-level or subscription-level toggle. If you are managing a large estate, plan for this before you start.
Is It Worth Enabling?
Yes, but the value is proportional to what you do with the data. Simply enabling inventory and letting the files accumulate in a container gives you nothing. The value comes from actually querying the output.
For a FinOps practitioner or engineer doing a cost review, a one-off inventory run followed by analysis in Excel, Azure Synapse, or even a simple script can surface actionable findings in an hour. For ongoing management, setting up a recurring run and connecting it to a data analysis source will help.
The tooling overhead is low — enabling it takes a few minutes and costs nothing directly. The cost is the storage consumed by the output files, which is manageable if you clean them up regularly.
Key Takeaways
- Blob Inventory gives you a per-blob export with size, age, tier, access time, and deletion status — the raw material for almost every storage cost optimisation conversation
- The most valuable fields for cost work are Content-Length, LastAccessTime, AccessTier, and Deleted
- Enable LastAccessTime tracking as soon as possible — it cannot backfill historical access data
- Set up a lifecycle policy to clean the destination container, or the inventory files themselves become a cost
- Start without versions and snapshots to keep the output manageable; add them once you understand the account
- It is per storage account — if you have many accounts, plan for automation to deploy rules at scale