Microsoft announced advanced capacity insights in Azure Storage Discovery in preview on October 22, 2026. The Capacity details experience adds analysis of access recency, data age, tiers, storage composition, object sizes, and retention, with drill-down to the resources behind a trend. Microsoft's announcement.
For a storage review, the useful output is a list of resources to investigate with their owners. An inactive-looking dataset is not automatically a deletion candidate, and a capacity chart is not an approved lifecycle policy.
What the New Views Help Explain
Microsoft describes charts for tier and recency, live data versus versions, snapshots and soft-deleted objects, size-bucket distribution, and retention considerations. The minimum-retention analysis highlights data that may incur early deletion charges if changed today. Microsoft says advanced insights are included in the Standard plan and can be enabled through Capacity details. Announced capabilities.
I would begin with one business-owned data area and a question the team can answer. For example: what explains its recent growth, and which part of that growth has a documented purpose?
Keep the first review read-only. Establish the evidence and ownership before changing tiering or retention behavior.
Make the Comparison Scope Explicit
The report documentation notes that capacity size and count include soft-deleted blobs, versions, and snapshots by default. Blob Inventory rules do not include those categories unless explicitly configured.
That difference matters when two reports appear to disagree. Before treating one as wrong, compare their scope, included object categories, and observation dates.
My review record would preserve the selected subscriptions, accounts, regions, tags, and filters. Another engineer should be able to reproduce the investigation without guessing which screenshot settings were used.
Also distinguish the overview from a historical trend. Microsoft documents that overview tiles use the latest available data and do not change when the selected time range changes. Report interpretation.
Separate Age from Business Value
For each candidate area, I would ask the owner to explain the expected access pattern and why the data is retained. Include infrequent operational, recovery, and business uses that may not appear in everyday application traffic.
Record which signal led to the investigation: creation age, last modification, or observed access recency. Avoid treating these as interchangeable explanations of usefulness.
If the owner cannot yet explain the dataset, assign discovery work. Lack of an immediate answer should not become authorization to delete or re-tier it.
Keep retention requirements with the responsible business or governance team. The storage administrator should not have to infer them from a chart label.
Inspect Composition Before Proposing Savings
My next step would distinguish live application data from recoverable or historical copies. Ask which protection or versioning behavior created the capacity and which recovery outcome it supports.
If a proposal changes that behavior, state the lost capability as clearly as the expected capacity reduction. Review the proposal with the workload owner and the team responsible for recovery.
For an object-size pattern, investigate the application's read and write behavior before suggesting compaction. A smaller object count alone does not establish that a changed layout will improve the workload.
Use observed costs and the applicable service terms when estimating an intervention. Do not turn a percentage of apparently inactive capacity directly into a promised percentage saving.
Run a Bounded, Approved Experiment
Once the owner approves a specific candidate, I would test the proposed change in an appropriate non-production area or an explicitly approved subset. Capture the starting state and the behavior that must remain intact.
Include access, recovery, and application checks, not just a follow-up capacity reading. Document how the team would respond if expected data becomes unavailable or the cost effect differs from the estimate.
Keep the outcome linked to the original question. A useful optimization record explains what changed, who approved it, what was measured, and which remaining assumptions still need review.
Practical Cloud Engineer Takeaway
Treat the preview as investigation support, not cleanup authorization.
Align report scope and object categories before comparing totals.
Separate age, access signals, and business retention needs.
Review the recovery value of versions and soft-deleted data.
Validate an approved change against workload outcomes and actual costs.
Who Should Care?
Azure Blob Storage administrators, data-platform owners, and FinOps teams investigating capacity growth without weakening application access or recovery requirements.
Bottom Line
Advanced capacity insights add useful detail behind estate-wide storage totals. The responsible next step is a scoped, owned decision with evidence—not an automatic rule that old or quiet data should disappear.
No data, lifecycle rule, storage tier, retention setting, or Discovery workspace was changed for this article.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments