Savings Report
The Savings Report answers one question: what could we stop paying for. It quantifies reclaimable spend across storage, compute, and cloud, and it names the specific arrays, vCenters, and subscriptions the money is sitting in.
What this screen shows
Four context tabs run across the top: Total, Storage, Compute, and Cloud. Total gives one bar per context so you can see which layer holds the largest opportunity, backed by a three-row grid. The other three tabs swap in a chart and grid shaped to that context’s savings types. In the Storage context an extra $ / GiB toggle switches the chart and grid between dollar savings and raw capacity, which matters when the conversation is about deferring an array purchase rather than cutting a bill.
What each context surfaces
| Context | Savings types | Grid granularity |
|---|---|---|
| Total | Roll-up of the three below | One row per context |
| Storage | Orphaned LUNs, volume locked free space | One row per array |
| Compute | CPU savings, memory savings, orphaned VMDK cost | One row per vCenter, stacked bar by type |
| Cloud | Estimated savings per subscription | One row per subscription |
What the savings types mean
- Orphaned LUNs. Storage allocated to a host that no longer attaches to it. Decommissioned applications and forgotten migrations are the usual causes.
- Volume locked free space. Free capacity trapped inside allocated volumes. The array counts it as used, the host is not using it, and nobody can allocate it elsewhere until it is reclaimed.
- CPU and memory savings. Over-provisioned vCPU and RAM on virtual machines, valued at what that allocation costs.
- Orphaned VMDK cost. Virtual disk files left behind by deleted VMs and abandoned snapshots. Frequently the largest single line in the compute context.
- Cloud savings. The aggregated opportunity per subscription. The specific actions behind that number live on Optimization Recommendations.
Reading the numbers honestly
The Storage and Compute contexts report estimated lifetime savings. The Cloud context reports estimated annual savings. Those are different horizons, so treat the Total roll-up as a ranking of where to look first rather than a single figure to drop into a budget. Validate individual lines against the detail grid before committing to a number.
Tip: Before acting on an orphaned-storage figure, check whether the capacity belongs to a DR site. Replication targets can look orphaned and still be doing exactly their job.
Dollars or capacity, depending on who is asking
The same finding has two currencies. Finance wants the dollar figure. Engineering wants the capacity or the cores back. The Storage context toggle between dollars and GiB exists for exactly that reason, and it changes which conversation the report supports: cutting a bill, or deferring an array purchase.
One workflow across on-premise and cloud
Right-sizing covers on-premise virtual machines and all three major hyperscalers in a single workflow against one cost model. A reclaimed on-premise vCPU and a downsized cloud instance land in the same report on the same basis, so the practitioner reports one savings number instead of reconciling several tools.
In the Storage context, the specific volumes behind a reclaimable figure are named, which is what turns an estate-wide number into work an engineer can actually pick up. No team finds orphaned volumes by hand across an estate of any size.
Related screens
Optimization Recommendations turns the cloud figure into specific recommended actions with adoption status. Cost Efficiency Dashboard ranks assets by how well their cost is earned, which is a different question from how much is reclaimable. Financial Administration shows the cost build behind each asset.