Connect a Cloud Account, See Dollar Findings in Five Minutes

This is part two of our Connection Value series. Part one laid out the ladder: what a connection should return in the first five minutes, the first week, and every month after. This article walks that ladder for the connection most teams make first — a cloud account, whether that's AWS, Azure, or GCP.

The claim in the title is specific on purpose. Not "insights." Not "visibility." Findings with dollar estimates attached, before you type a single prompt. If a tool asks you to grant access to your cloud account, the least it owes you is proof — fast — that the access was worth granting. Here's what that looks like in practice, and just as important, what a read-only connection can and cannot do.

Minute zero to five: read-only role, first findings

You don't hand over credentials. You create a read-only identity in your own cloud from a provided template:

• AWS — a cross-account IAM role with a read-only policy. Paste the role ARN.
• Azure — an app registration with Reader on the subscription(s) you choose.
• GCP — a service account with viewer-level roles on the project(s) you choose.

In each case the template shows the exact permissions, so your security review can see precisely what is — and isn't — granted before anything connects. No agents installed on instances, no write access at connection time. The connection guide has the full walkthrough for all three clouds; the setup itself is a few minutes of copy-paste.

The moment the connection validates, the first scan starts. It goes after the cheap-to-find, expensive-to-ignore waste first: unattached volumes and disks, idle instances, unused elastic IPs and public IPs, and the most obvious rightsizing candidates. Within about five minutes you have your first three to five findings, each with a monthly estimate.

Numbers below are illustrative — a composite first scan on a mid-market account around $45K/month. Your account will differ.

That's roughly $5,500/month surfaced in the first five minutes — not the deep architectural work, just the waste that's sitting in plain sight once something actually looks. Each finding carries its evidence: the metrics window, the current cost, the projected saving as a range, not a single suspiciously confident number.

If you're on AWS and want the full seven-category treatment — snapshots, Savings Plans coverage, NAT gateway traffic, and the rest — we've written a dedicated AWS deep-dive. This article stays at the level that applies equally to all three clouds.

Minute ten: a map of what you actually run

While the cost scan runs, the same read access builds an inventory: compute, storage, network, and databases, laid out as a topology map rather than a flat list. Each node carries a cost annotation, so "what's in this VPC?" and "what does this VPC cost?" become the same glance.

This sounds like a nicety until the first time you use it. Most teams discover at least one thing on the map they didn't know was running — a load balancer from a decommissioned service, a database replica in a region nobody remembers choosing. The map is also what later findings hang off: when an anomaly fires in week two, it points at a node you've already seen, not an opaque resource ID.

Alongside cost, the same read-only access gives Olivier — CloudThinker's security agent — enough to render a posture preview: publicly readable storage buckets, security groups open to 0.0.0.0/0, IAM access keys past 90 days without rotation. It's a preview, not an audit — but it's the kind of list that tends to get forwarded to the security channel within the hour.

Day seven: the first weekly report

A week in, the first scheduled cost report lands in Slack or email. It's built to be read in ninety seconds:

• Deltas — what spend did week-over-week, by service, with the movers called out.
• New findings — waste that appeared since last week (every deploy can orphan a volume; a weekly cadence catches it while the responsible engineer still remembers the deploy).
• Savings realized — not projected: what was actually saved by findings you acted on, so the report earns its place in the channel.
• One "act on this" deep link — the single highest-value open finding, one click from the report to the approval screen.

The realized-savings line matters more than it looks. Plenty of tools can generate a big projected number on day one. The number that keeps a report from being muted is the one that goes up because of things your team actually did.

Week two onward: baselines and anomalies with a probable cause

After a week of data, the agent has baselines on spend and utilization — per service, per environment, adjusted for your weekly rhythm so a normal Monday ramp doesn't page anyone. From then on, anomalies come with a probable-cause line, not just a red number: "Compute spend in us-east-1 up 34% since Tuesday 14:00 — coincides with the autoscaling group's new minimum of 6."

If you've also connected a repository, anomalies get correlated with deploy markers, which is often the whole diagnosis: the spend jump started eleven minutes after a specific merge. That's part three of this series — and a first taste of why connections compound rather than just accumulate.

Monthly: commitment coverage, gated by your autonomy level

The biggest line items on most cloud bills aren't waste — they're full-price payments for stable workloads that should be covered by reserved instances, savings plans, or committed-use discounts. Monthly, the agent analyzes your coverage: what your stable baseline supports, where you're over- or under-committed, and what a specific purchase would save, with break-even math shown.

These arrive as recommendations you approve, not actions that happen. Commitment purchases are multi-thousand-dollar, multi-year decisions; they run at whatever autonomy level you've set — which for commitments, for nearly every team, means a named human clicks approve after reading the analysis. Alex, the cost agent, prepares the case; the decision stays yours.

What read-only access will not do

Worth stating plainly, because "connect your cloud account" should make you ask exactly this.

Everything described above — the findings table, the topology map, the security preview, the weekly report, the anomaly baselines, the coverage analysis — runs on read-only access. During all of it:

• No resource is modified. Not resized, not stopped, not rescheduled.
• Nothing is deleted. Not even a 14-month-old unattached volume the evidence says is safe.
• No commitment is purchased. Coverage analysis produces a recommendation and a break-even case, never a transaction.

Acting on findings requires two separate, deliberate steps: granting scoped write permissions (a second template, as reviewable as the first), and setting an autonomy level above Notify for that action type in that environment. Every automated action in CloudThinker runs at one of four levels — Notify, Suggest, Approve, Autonomous — with role-based access control on who can change the levels and a full audit trail of what was found, what was proposed, who approved, and what changed. Most teams run everything at Notify or Suggest for weeks, watch the agent be right, and only then promote narrow, reversible action types — deleting a snapshotted volume in staging, say — toward Approve.

The honest framing: read-only access buys you a continuously refreshed audit with dollar figures attached. It does not buy the agent the keys to anything. Those are granted separately, narrowly, and on your schedule — or never, if a findings feed is all you want.

Five minutes is the test

If you take one thing from this article: don't evaluate a cloud connection on its feature list. Evaluate it on what it hands you in the first five minutes with nothing but a read-only role. A findings table with real dollar estimates is a fair opening bid; everything after — the map, the weekly report, the baselines, the coverage analysis — is the same access paying rent every week.

Try CloudThinker free — 100 premium credits, no card required — and follow the connection guide for AWS, Azure, or GCP. Your own first findings table should exist before your coffee gets cold.