How CloudIQ works
Four steps from a read-only connection to a saving you can prove: find the biggest opportunities, price each one, ship the change through engineering, and prove the result.
A recommendation does not reduce a cloud bill. Someone has to find the right opportunity, decide it is worth doing, make the change, and check that it worked. CloudIQ runs that loop, with your engineers approving every change.
The timeline#
| Step | When |
|---|---|
| Read-only setup, guided by us | About 2 hours |
| First priced findings | About 1 hour later |
| Changes prepared for review | Same day |
| First savings reach the verified stage | Days |
The first three happen on day one. The fourth depends on how quickly your team ships.
1. Find the biggest opportunities first#
CloudIQ runs more than 400 automated checks across AWS, Google Cloud and BigQuery, every day. It combines the results into one list, ranked by estimated saving. The first item is your largest opportunity, such as an oversized BigQuery reservation or idle GPUs.
It looks for two kinds of cost:
- Waste: resources that are idle, orphaned, oversized or forgotten. Cleanup is the obvious first move and, in most estates, the smaller half of the opportunity.
- Design debt: pricing models, storage classes, network paths and services that no longer fit the workload. These do not show up as idle resources, so cleanup tools miss them.
Each check is narrow by design. It looks for one named condition in one service and knows what evidence proves it. See What a finding looks like.
2. Know the value before you act#
Every finding shows:
- its current cost
- the estimated monthly saving, and how it was calculated
- a risk level and a confidence rating
- the usage data that supports it
Your team sees the value and the risk before deciding to approve, defer or reject the change.
Estimates are never reported as results. They stay estimates until the change ships and a later audit confirms it.
3. Deliver the change through engineering#
An approved finding becomes work in the systems your team already uses:
- a Terraform pull request, generated from one of about 40 templates and aligned with the resources you already manage in Terraform
- a runbook with rollback steps, from 28 AWS runbook catalogs, for changes that are not expressed in code
- a BigQuery SQL rewrite for an engineer to review
- a Jira ticket assigned to the right owner, with the evidence in the body
Nothing changes in your environment until your engineers review and apply it. See From finding to fix.
4. Prove the result#
A savings ledger tracks each opportunity through five stages.
| Stage | Meaning |
|---|---|
| Identified | A check found it and priced it |
| Assigned | It has an owner |
| In progress | The change is being made |
| Completed | The owner marked the work done |
| Verified | A later audit no longer finds the condition, and later billing data confirms the expected effect where available |
Estimated and verified amounts are kept apart, and a potential saving is never reported as verified. Finance-ready exports report the ledger by stage.
What runs where#
Nothing runs in your accounts. CloudIQ reads resource configuration, utilization metrics, pricing and billing data through the cloud provider APIs, under a read-only role you create. Every call appears in your CloudTrail or Cloud Audit Logs. The security and access model lists what it can and cannot access.
Next#
Try this against your own spend
A free savings analysis runs the checks described in these docs against your AWS or Google Cloud account and returns a ranked list of priced findings.