cloud-cost-investigate

Cloud Cost Investigate

Given a cost question, run a read-only investigation in one of three modes — anomaly (why did the bill change), waste (what are we wasting), or attribution (what does X cost) — and produce a report with findings and a prioritized remediation list. Strict read-only Iron Law; per-batch operator approval for queries; cloud-native APIs only.

The Iron Law

NO MUTATIONS. EVER.
NO QUERY BATCH WITHOUT OPERATOR APPROVAL.
NO SAVINGS CLAIM WITHOUT A LABELLED SOURCE.

• Law 1: Strictly read-only. Cost APIs, resource-state APIs, metrics APIs only. No delete, terminate, update, purchase — not even "harmless" tagging fixes.
• Law 2: Every batch of cloud queries is shown to the operator and approved before execution. Per-batch (not per-query) to keep friction reasonable, but the batch is itemized with API costs and IAM permissions called out.
• Law 3: Every dollar figure in the remediation list is tagged with its source (compute-optimizer, gcp-recommender, azure-advisor, line-item-computation) and confidence (high / medium / low). No bare "save $X" claims.

Guiding principles

Four principles govern how waste evidence is read and how savings are claimed. They sit above the per-mode query plans — apply them when designing the batch, when scoring confidence, and when labelling savings.

Principle 1 — Verify activity, not attachment

Evidence of no-use measures activity, never attachment. These are different dimensions and must never be conflated:

• Activity: observed throughput — request / invocation / transaction counts, read or processing volume, access-log hits, query counts over a representative window.
• Attachment: a consumer, reference, policy, route, binding, or dependent configured against the resource. Attachment answers "what breaks if I remove this," NOT "is this being used."

Rules:

1. A dependent being enabled / connected / configured / attached is not evidence of use. Declared config ≠ runtime behavior. Confirm with an activity metric over a representative window.
2. The inverse holds: a resource being un-attached is not automatic evidence of no-use unless the resource type has no activity dimension (e.g., unattached EBS volume, unallocated Elastic IP — these cost money regardless). For anything with a usage signal (DB, queue, stream, bucket, function), require activity data.
3. Discount keep-alive noise. Heartbeats, health checks, warm-up schedules, monitoring probes, liveness pings, and automatic retries all produce activity that masks idleness. Their tell is a uniform, periodic, workload-independent cadence. Identify and subtract synthetic traffic before judging a resource idle.
4. Candidates whose only evidence is attachment state (or absence of it, for a resource type with an activity dimension) are capped at confidence: low and labelled activity-unverified in the report.
5. Two independent signals for a delete. A delete requires BOTH signals: activity = none (throughput) AND attachment understood (dependency map). Neither substitutes for the other — "nothing attached" is not enough (it may be reachable by a path not yet mapped), and "zero throughput" is not enough (removing it can still break a wired-but-idle consumer). Produce both before recommending a delete.