DEV Community

Muskan _zop
Muskan _zop

Posted on

From Read-Only Connect to Your First Cloud Waste Report in Five Minutes

Cost tool evaluations die of two opposite diseases. The first is the security stall: three weeks of review before anyone grants a single permission, value never demonstrated, eval expires. The second is quieter and worse: the tool connects in minutes, renders a beautiful first report, and half the numbers are silently wrong because half the permissions were missing and nothing said so.

This post is about doing the first five minutes right: what a read-only connection can honestly tell you immediately, what it structurally cannot tell you yet, and the one thing to demand from any tool so the first report can be trusted at all.

What "read-only connect" should mean

No agents, no access keys. A cross-account IAM role on AWS (assumed with short-lived sessions and an ExternalId), a service principal or workload identity on Azure, workload identity federation or a service account on GCP. Metadata and meters only: the tool learns that an instance exists, its size, and its CPU curve, never what's inside it. Revocation is one deletion.

If a vendor's connect flow wants long-lived keys or anything writable on day one, stop the eval there. That's not a threshold judgment; it's a category error.

The five-minute truth: what's knowable immediately

The instant billing access works, one class of answers is available because the cloud provider already computed them: spend by service, by account, by region, trend against last month, and the shape of the daily burn. From that alone, a competent first pass can flag:

  • The concentration picture. Which three services carry 70% of the bill. This takes one GROUP BY, and it reframes every later conversation.
  • Account-level anomalies. A sandbox account spending like production is visible in the first chart.
  • The unattributed number. What percentage of spend has no team, no tag, no owner. It's usually 10-30%, and it's the single most predictive number for how much waste the deeper scan will find.
  • Weekend shape. If the daily spend curve is flat across Saturday and Sunday, non-production is running around the clock. A flat weekend on a business-hours company is the cheapest waste signal that exists.

You can do this five-minute version yourself with no tool at all: Cost Explorer, last 30 days, group by service (then by linked account), plus two terminal one-liners for the classic zombies:

aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeType,Size]' --output text |
awk '{s+=$2} END {printf "Unattached storage: %d GB = $%.0f-%.0f/month\n", s, s*0.08, s*0.10}'
Enter fullscreen mode Exit fullscreen mode
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==`null`].AllocationId' --output text |
wc -w | awk '{printf "Idle public IPs: %d = $%.2f/month\n", $1, $1*3.65}'
Enter fullscreen mode Exit fullscreen mode

Five minutes, a real dollar figure, zero risk. That's the floor any paid tool has to clear, and clear visibly.

What five minutes cannot tell you (and any honest report says so)

  • Idle verdicts. "This database has had zero connections" is a claim about history. A trustworthy idle call needs 14-30 days of metrics; a tool that declares idleness on day one is reading a single frame of a film.
  • Rightsizing. Same reason: percentile CPU and memory over weeks, not the last hour.
  • Savings-plan and reservation math. Coverage and utilization need a full billing cycle to mean anything.
  • Trend anomalies. Baselines have to be learned before deviations from them exist.

So a genuine first waste report has two sections: "found now" (billing-shape findings, zombies, unattributed spend, weekend flatness) and "maturing" (idle, rightsizing, commitment coverage, each with the date it becomes trustworthy). If a first report has no "maturing" section, it's either omniscient or lying, and one of those is more likely.

The silent permission trap

Here's the failure that actually ruins first reports. Read-only is not one permission; it's dozens across billing, inventory, and metrics, granted per account and sometimes per region. Partial grants don't fail loudly. They produce a report where the cost chart is perfect, the idle section is empty, and nobody can tell whether "no idle databases" means healthy infrastructure or a missing Monitoring Reader assignment in one subscription.

An empty section and a blocked section look identical unless the tool distinguishes them. So the one thing to demand in the first five minutes: per-feature, per-account permission state, visible in the product. Which accounts granted what, which findings are gated on what's missing, and what specifically to grant to unlock them. If the tool can't say "this section is empty because we can't see X in account Y", you can't trust any section that happens to be empty.

This is where ZopNight is a working example of the standard: it runs read-only by default (connect via IAM role, service principal, or workload identity, no agents), and its View Permissions screen tracks every permission it checks per account and per region, showing Granted, Denied, or Unknown per feature, with each page bannering exactly which missing access is gating which findings, down to named states like "Probe-blocked" when it can't even read which permissions exist. Whatever tool you evaluate, hold it to that bar: a first report that states what it could not see is worth ten that don't.

A checklist for minute five

Before the eval call ends, the first report should contain:

  1. Spend by service and by account, reconciled to the bill's shape, with the top-3 concentration named.
  2. The unattributed percentage, stated as a number, not hidden in an "other" slice.
  3. A zombie list with a monthly dollar per item (unattached storage, idle IPs, dead load balancers).
  4. The weekend-flatness verdict on non-production accounts.
  5. A "what we cannot see yet" section: missing permissions by account, and which findings they gate.
  6. Dates on the maturing findings: when idle and rightsizing verdicts become defensible.

Items 1-4 prove the tool works. Items 5-6 prove you can believe it.

FAQ

How fast can a cloud cost tool actually show value?

Billing-shape findings (spend concentration, account anomalies, unattributed percentage, weekend flatness) are available within minutes of billing access, because the provider already computed the data. Structural zombie findings follow as soon as inventory access is granted. Metric-based verdicts (idle, rightsizing) genuinely need two to four weeks of history, whatever any vendor says.

What can a cost tool see with read-only access?

Metadata and meters: that resources exist, their configuration and size, their utilization metrics, and your billing data. Not file contents, not database rows, not secrets, provided the role is scoped to the control plane. The distinction and the exact policy statements are their own topic; the short version is metadata yes, contents never.

Why does my cost tool's report look empty or wrong?

The most common cause is partial permissions: billing granted but metrics missing, or one account granted and five not. Sections then render empty rather than erroring. Check whether the tool exposes per-account permission state; if it can't tell you what it couldn't see, treat empty sections as unknown, not as good news.

Is "five minutes to value" realistic or marketing?

Both, depending on the claim. Five minutes to a real, dollar-quantified readout of billing shape and zombies: realistic. Five minutes to idle and rightsizing verdicts: not possible from a cold start, because those are claims about weeks of history. The honest version of the pitch names both halves.

What should I grant first if I'm rolling permissions out gradually?

Billing read first (it unlocks the most insight per permission), then inventory metadata, then metrics. Write or action permissions never belong in an evaluation; a tool that needs them to demonstrate value is demonstrating something else.

Top comments (0)