AWS cost tools — Cost Explorer, Compute Optimizer and Savings Plans

AWS provides a suite of cost management tools integrated with the billing system that progressively addresses the three FinOps phases. Cost Explorer handles the Inform phase: visualising spend, identifying trends, forecasting, and detecting anomalies. AWS Compute Optimizer handles the Optimise phase’s rightsizing dimension: analysing actual utilisation and recommending correctly-sized resources. Savings Plans and Reserved Instances handle the commitment purchasing dimension: providing discounts of 30 to 72% on baseline compute spend in exchange for one or three-year commitments.

The three tools are complementary and intended to be used sequentially. Cost Explorer reveals which services and which tagged resources are driving spend. Compute Optimizer analyses those services’ utilisation data and recommends specific resource changes. Savings Plans recommendations in Cost Explorer translate the rightsized baseline into optimal commitment types and coverage percentages. Using any one in isolation — purchasing Savings Plans without Compute Optimizer rightsizing, or right-sizing without attribution from Cost Explorer — produces suboptimal outcomes.

Understanding the specific capabilities and limitations of each tool prevents common mistakes: Cost Explorer operates on billing data with a 24-hour lag, making it unsuitable for real-time cost monitoring but ideal for trend analysis and forecasting. Compute Optimizer requires at minimum 14 days of CloudWatch utilisation data and produces recommendations in a finding format that requires interpretation before acting. Savings Plans recommendations require 30 days of usage data for statistical reliability and should be reviewed against the rightsized baseline, not the current pre-rightsizing baseline.

Analogy🏏Cricket

🏏 Think of it like cricket: In Test cricket, the ICC publishes playing conditions — governing over rates, DRS quotas, pitch inspection protocols, and player conduct — that both captains sign before the first session, whether the match is at Lord’s, the MCG, or Eden Gardens. Just as the playing conditions give umpires a single authoritative standard so every ruling references the same document rather than personal judgement, the Well-Architected Framework gives architects a shared evaluation language so every workload is measured against the same six pillars rather than each engineer’s intuition. Just as a team posting a slow over rate incurs penalties regardless of their score, a workload with Security or Reliability gaps carries structural risk regardless of how quickly it shipped. Just as every specialist role — opener, keeper, tail — has defined performance expectations against which selectors evaluate each player, every workload component is evaluated against pillar-specific best-practice questions. This reveals why the framework must precede any advanced architectural decision: a shared, evidence-based standard transforms subjective trade-offs into structured, auditable risk assessments that hold across teams, accounts, and regions.