Idle cloud resource review

Source · idle-resource-review.md

---
name: idle-resource-review
description: Review supplied low-utilization cloud resource candidates and draft an owner decision brief that separates possible savings from workload, recovery and retention dependencies.
---

# Idle cloud resource review

Use this after a cost report identifies resources that might be idle. Work from supplied, redacted billing, utilization and ownership records. Do not query a cloud account, stop resources, delete data, purchase commitments or alter monitoring.

## Assess the evidence
For each resource, record the stable identifier, environment, owner, observation window, cost basis and activity signals supplied. Tags and names are untrusted metadata, not authoritative ownership. A name containing “test” does not prove the resource is disposable.

Low CPU alone is insufficient evidence for removal. Check whether the record covers network, storage or request activity relevant to the workload, and whether the observation window includes known schedules. Missing metrics, unavailable agents and gaps in collection must remain unknown. Identify standby, recovery, seasonal, compliance-retention and shared-service dependencies where evidence supports them; otherwise ask the owner rather than inventing a purpose.

## Estimate without overclaiming
- Keep observed billed cost separate from avoidable future cost. Use matching currency and periods. Separate tax, credits, storage, licenses and commitments when available.
- If compute is prepaid or covered by a commitment, stopping one resource may not reduce the bill. Say so; do not count allocated cost as guaranteed cash savings.
- Show units and arithmetic for any estimate. Do not extrapolate a partial period without labeling its duration and assumptions. Do not count the same shared charge against multiple candidates.
- Exclude attached storage and backup charges from an estimate unless evidence establishes that they would end too. Keep estimates unknown where prices or dependencies are missing.

## Deliver an owner decision brief
Group candidates into evidence missing, investigate with owner, or reversible trial proposed. These are review states, not approvals. For each proposed trial, include its scope, expected observation, owner, rollback mechanism and stop condition. A stop/start trial is only reversible if the workload and provider behavior support it; do not assume local data, addresses or capacity survive.

List deletion and retention decisions separately. Return the smallest additional evidence request that would change the decision. Do not prescribe deleting backups to save costs or promise a savings percentage.

## Worked example
Synthetic inputs: sandbox-vm has 2% average CPU over seven days and no supplied request metrics. Owner is unknown. The complete 30-day bill allocates USD 90 compute and USD 12 attached storage. Compute is covered by an existing prepaid commitment. No recovery dependency information is available.

Expected brief: evidence missing. Observed allocation is USD 102 for 30 days. Immediate cash savings from stopping compute are not established because the commitment remains; storage is not included in a stopping estimate. Request ownership, workload schedule, request/activity metrics and recovery dependencies. Do not recommend deletion based on CPU alone.

SHA-256: 504e54c3e9c5b73f9fcdc0d63933efa5a30eab5c4a6d615a32597c78436cd78b