Every major cloud ships tooling that does the first pass of cost analysis for you. It is consistently underused — partly because it needs enabling before it collects anything, and partly because engineers assume tools this easy cannot be saying anything they do not already know.
Topic 1: The Four Tools
Enable all four before optimization work begins. Several need a day or more of data collection before they show anything useful.
| Tool category | What it does | Priority |
|---|---|---|
| Cost explorer | Visualises spend by service, resource, tag and time range | First |
| Right-sizing recommender | Recommends instance sizes from observed utilisation | Second |
| Best-practice advisor | Idle resources, security gaps, quota warnings, reliability findings | Third |
| Anomaly detection | Alerts on unexpected spend spikes per service or account | Fourth |
The ordering reflects dependency, not importance. The explorer tells you where to look; the recommender tells you what to change; the advisor catches what you did not think to check; anomaly detection stops the next surprise.
Topic 2: Cost Explorer
The workhorse. Its most valuable use is not exploration but proof.
After any change, the verification loop:
- Filter to the resource type, then to the specific resource ID.
- Filter by the new instance type or configuration.
- Group by day — this is the step people miss, and without it the change is invisible inside a monthly total.
- Compare the day before the change against the day after.
- Export or screenshot for the change record.
A concrete result from that loop: an instance migrating between CPU vendors moved from roughly $20/day to $16–17/day — about $100–130 per month, for one instance, from a change with a two-minute maintenance window.
Costs typically settle within 24 hours of a change. Verify then, not at month end when the signal is buried.
Topic 3: The Right-Sizing Recommender
Analyses collected utilisation and recommends a size, with a projected saving attached.
- Must be enabled, and typically needs up to 24 hours before showing data.
- Recommendations improve as history accumulates — treat week-one output as provisional.
- The equivalent tool exists on every major cloud under a different name; the concept is identical.
Its real value is removing guesswork and, more importantly, removing argument. “This instance should be smaller” is an opinion. “The provider’s own recommender projects a 60% saving from this change based on 90 days of utilisation” is a proposal.
Do not implement recommendations mechanically. The recommender sees utilisation, not context — it does not know about the quarterly batch job, the failover capacity you deliberately hold, or next month’s launch.
Topic 4: The Best-Practice Advisor
Broader than cost, which is what makes it useful. Typical findings across categories:
| Category | Example findings |
|---|---|
| Cost | Idle instances, unattached volumes, underutilised databases |
| Security | Accounts without MFA, security groups open to the world on admin ports |
| Performance | Missing autoscaling, misconfigured health checks |
| Limits | Resources approaching a service quota |
| Reliability | Missing disruption budgets, short backup retention, absent maintenance windows |
The cost findings here are the fastest money in the whole discipline — unattached volumes and idle public IPs are pure waste with no performance consideration and no business conversation required. One estate cleared roughly $232/month from unattached block volumes alone.
A cross-cloud difference worth knowing: one major provider’s equivalent tool is entirely free, while another gates the full recommendation set behind a paid support tier. If you work across clouds, do not assume parity.
Topic 5: Anomaly Detection
The only tool here that is forward-looking. Everything else describes what already happened; anomaly detection tells you about the spend spike while it is still happening.
- Configure per service and per account, with a threshold that reflects normal variance.
- Route alerts somewhere a human reads — a cost alert in an unmonitored inbox is not a control.
- Tune the threshold. A detector that fires on every deployment gets muted, and then it is worse than nothing.
This is what catches the misconfigured job that spins up instances in a loop, or the log level someone set to debug in production on a Friday.
Topic 6: Where Native Tools Stop
Being clear about the ceiling saves you from expecting too much:
- They see resources, not architecture. No tool will tell you the workload should not run in that region, or that two services could share a cluster.
- They cannot see business context. Deliberately-held failover capacity looks identical to waste.
- They rarely reach inside Kubernetes. A cluster appears as nodes; the recommender cannot see that a pod requests six times the memory it uses. That gap is exactly what the Kubernetes-specific tooling in stage 3 exists to close.
- Recommendations are per-resource. They do not compose. Twenty recommendations, each individually sound, can add up to an architecture nobody designed.
Try it yourself: Export every recommendation with its projected saving, then rank the list twice — once by saving, once by implementation risk. The disagreement between those two orderings is your actual implementation plan.
Common mistake: Enabling the tools on the day you need their output. They are historical analysers — a recommender enabled this morning has nothing useful to say this afternoon. Enable them on day one of any engagement, before you have decided what to do.