Yes: establish workload ownership, remove idle resources, right-size the remaining environment, and understand planned architecture changes before committing to long-term cloud pricing. The objective is to commit against a validated baseline—not today's avoidable waste.
A discount applied to an oversized or unnecessary workload can lock in avoidable spend.
Cloud cost reduction should begin with visibility and ownership, then move through idle-resource removal, rightsizing, architecture review, and baseline validation before the company evaluates commitment-based pricing.
That sequence does not mean commitments are bad. It means the organization should know what workload it actually expects to run before committing to pay for it.
The finance question is not "How large is the discount?" It is "What stable amount of required usage are we comfortable committing to after waste and near-term changes are accounted for?"
| Stage | Evidence to review | Decision |
|---|---|---|
| Allocate ownership | Account, subscription, project, workload, environment, tags, business owner | Can the spend be assigned to a real workload and accountable owner? |
| Remove idle resources | Idle compute, unattached storage, stale snapshots, abandoned environments, orphaned services | Can the resource be stopped or deleted safely? |
| Right-size | CPU, memory, storage, network, utilization history, performance requirement | Is the workload materially over- or under-provisioned? |
| Examine architecture | Storage tier, data transfer, database design, replication, logging, scaling, recovery design | Is the architecture creating unnecessary consumption? |
| Establish the baseline | Required run rate, seasonality, planned migrations, retirements, growth, existing commitments | Which usage is sufficiently stable to evaluate for commitment? |
| Optimize rates | Provider commitment options, term, flexibility, coverage, existing commitments | What pricing mechanism fits the validated baseline? |
| Govern | Ownership, budgets, anomaly detection, recurring review, change plans | How will unnecessary spend be prevented from returning? |
Finance should bring:
Engineering should bring:
Cost decisions based on the invoice alone can remove resources that appear unnecessary but support security, testing, backup, disaster recovery, periodic workloads, or customer performance.
For every material workload, establish an accountable owner, environment, monthly cost, utilization pattern, reliability requirement, and known upcoming change.
Before buying a new commitment, put each material workload through this decision file:
| Field | Question |
|---|---|
| Workload owner | Who is accountable for this workload? |
| Environment | Production, development, test, DR, shared platform, or other? |
| Current run rate | What is the recent cost and usage baseline? |
| Utilization | Is compute, memory, storage, or another resource materially oversized? |
| Reliability requirement | What capacity is required for performance, resilience, or recovery? |
| Idle resource check | Has genuinely unused capacity been removed? |
| Planned change | Is a migration, retirement, architecture change, or growth event expected? |
| Seasonality | Does demand materially change by month, quarter, event, or business cycle? |
| Existing commitments | What coverage or obligation already exists? |
| Stable baseline | What portion of usage is expected to remain? |
| Commitment decision | Commit, defer, reduce scope, or investigate further |
A commitment should be a rate decision applied to a validated operating baseline.
The company commits to capacity it later removes
Rightsizing after the commitment can reduce the workload while the financial obligation remains.
An architecture change invalidates the baseline
A database migration, containerization effort, application retirement, or modernization project can materially change required consumption.
Seasonality gets mistaken for a stable run rate
A short observation period can capture a peak, launch, migration, or unusual demand pattern.
Existing commitments are ignored
New purchases can overlap with coverage the organization already has.
Engineering loses flexibility
The commercial commitment can become a constraint on a technology decision that was not considered during procurement.
No.
Rightsizing means matching resources to the workload's documented operating requirements. Those requirements can include performance, security, resilience, backup, recovery, burst capacity, and expected growth.
A resource with low average utilization is not automatically unnecessary. The review should determine whether the capacity is required for a legitimate operating condition.
Cloud optimization should not stop with virtual machines.
Review:
The objective is to understand the complete workload economics before optimizing the rate.
Use enough history to understand the workload's actual pattern and known business cycle rather than applying an arbitrary universal window.
AWS current prescriptive guidance explicitly places rightsizing ahead of Savings Plans and recommends establishing consistent usage before making a commitment. Microsoft's current Azure guidance likewise sequences rightsizing and shutdown recommendations ahead of reservation and savings-plan recommendations.
The appropriate history depends on the workload, seasonality, growth, migrations, and available performance data.
These questions connect the procurement decision to the operating evidence rather than the other way around.
Blackspire's technology spend review can help leadership evaluate recurring technology spend alongside contract, utilization, and operating evidence.
Published: July 22, 2026 · Last Modified: August 28, 2026 · Publisher: Blackspire Advisors · Category: Technology Spend