The Savings That Are Waiting
Enterprise technology finance conversations consistently reveal a gap between what organisations spend on cloud and what they need to spend. The gap is not a management failure. It is the predictable result of cloud spend growing faster than the processes to manage it, in a multi-cloud environment where spend visibility is fragmented across providers, accounts, and business units.
The 30-day multi-cloud cost audit is not a FinOps programme. It does not require organisational change, cultural transformation, or a new governance model. It is a structured analysis of the current cloud spend that surfaces the savings opportunities that already exist in the environment — without requiring any of the longer-term investments that sustained FinOps maturity eventually requires. The value of the audit is immediate: a ranked list of savings opportunities with implementation effort and financial impact quantified, executable within the organisation’s current capacity.
Most enterprises that conduct a structured audit of their multi-cloud spend find recoverable savings between eight and fifteen percent of total spend within the first month. At enterprise cloud spend levels, this is a significant return on a month of structured analysis.
The 30-Day Framework
The framework has four sequential phases of roughly one week each, with each phase building on the outputs of the previous.
Days 1–7: Spend Inventory and Attribution
The starting point is a complete spend inventory across all cloud providers, all accounts, all subscriptions, and all cost centres. For most multi-cloud organisations, this inventory does not exist in a single view. The first week is the integration work: pulling cost data from each cloud provider’s cost management tool, normalising it to a common taxonomy, and attributing it to the teams, products, or business units that generate it.
The spend inventory will surface the first category of savings opportunity: shadow spend. Cloud accounts and subscriptions that are not in the official inventory, services that are running without a clear owner, and cost that has been allocated to a default cost centre because tagging was not implemented at provisioning time. The shadow spend that the inventory discovers is typically five to ten percent of total spend and is immediately eligible for review: either it is owned by a team that did not know it was being charged for it, or it is genuinely orphaned and can be decommissioned.
Days 8–14: Waste and Idle Resource Identification
The second week focuses on the resources that are running but not delivering value: idle compute instances, unattached storage volumes, unused reserved instances, and services provisioned for workloads that have since been decommissioned.
Cloud provider cost management tools and third-party FinOps tools both surface idle resource recommendations. The audit discipline at this stage is validation rather than blind acceptance of tool recommendations: each recommendation should be confirmed with the owning team before action, because the tool’s utilisation data may not capture all legitimate uses of a resource. The combination of tool output and team validation typically produces a confirmed idle resource list representing three to seven percent of spend.
Reserved instance and savings plan coverage analysis identifies the gap between current committed spend and the committed spend that would be optimal for the workload profile. Undercommitment is the most common gap: organisations that have not made reservations for stable workloads are paying on-demand prices for workloads that have been running continuously for months. The savings from right-sizing the reservation portfolio to match the actual workload profile are immediate once the reservations are purchased.
Days 15–21: Right-Sizing and Architecture Opportunities
The third week addresses the resources that are running and being used, but provisioned at a size or specification that exceeds what the workload requires. Right-sizing analysis compares actual resource utilisation — CPU, memory, storage throughput — against the provisioned resource size, and identifies workloads where the provisioned size significantly exceeds average utilisation.
The right-sizing opportunity requires more validation discipline than the idle resource analysis, because utilisation patterns vary: a resource that averages twenty percent CPU utilisation may spike to eighty percent under peak load, and reducing its size based on average utilisation would create a performance problem. The right-sizing recommendation should account for peak utilisation, not average utilisation.
Architecture opportunities in this phase address the patterns that generate cost above what the same outcome could be achieved for with different architectural choices. Data transfer costs from moving data between cloud regions or between cloud providers. Storage tier mismatches where data that has not been accessed for months is in hot storage rather than cold storage. Compute choices where serverless or managed services would be significantly cheaper than the provisioned compute the workload is running on.
Days 22–30: Prioritisation, Financial Quantification, and Action Plan
The fourth week converts the findings from the first three into a ranked action plan with financial impact and implementation effort for each opportunity.
The ranking criteria are financial impact (annual savings) and implementation effort (the engineering time and operational risk required to capture the saving). The highest-priority opportunities are those with the highest financial impact and the lowest implementation effort: the idle resources that can be decommissioned with a one-line email confirmation from the owner, the reservations that can be purchased through the cost management console in an afternoon.
The prioritisation output is the deliverable: a ranked list of savings opportunities, with the top ten to twenty representing the highest-ROI actions within the organisation’s current capacity to implement. The audit report presents this list with the assumptions behind each estimate and the implementation steps required.
What the Audit Does Not Do
The 30-day audit surfaces the savings that exist in the current environment. It does not address the structural conditions that produced the waste: the provisioning processes that do not require cost justification, the tagging policies that are inconsistently applied, the FinOps governance that does not create engineering accountability for cloud spend.
The audit findings are a starting point, not a conclusion. The organisation that conducts the audit, captures the immediate savings, and does nothing else will return to the same level of waste within twelve to eighteen months as the environment continues to grow without the governance that prevents waste accumulation.
The audit is most valuable as the first step of a FinOps programme rather than as a substitute for one. The findings provide the evidence base for the FinOps governance investment: this is what unmanaged cloud spend costs us, this is what structured management could save us, and this is what the governance investment required to sustain those savings would cost. That is the investment case that the audit enables.
The 30 days are worth spending. The conversation they enable is worth having.