A lower bill is not enough to prove an optimization worked. Compare the same workload and cost basis, account for demand and rate changes, and preserve the evidence behind each accepted saving. The numbers here are synthetic teaching inputs, not a customer result.
Practical artifact
Cloud savings assessment registerRead the HTML instructions and download the blank CSV without registration.
Choose the population before calculating a percentage
Name the workload, linked accounts, services, regions, billing currency and comparison windows. Confirm that both windows contain the same resource population. Record business demand, deployment changes and incidents that could explain a change independently of optimization.
Use the billing data that is available for the agreed assessment. Reconcile the selected cost measure to finance totals before drawing conclusions. Do not mix an unblended baseline with an amortized comparison, or include credits on only one side. Preserve the export definition and query revision so another reviewer can reproduce the result.
AWS Cost and Usage Reports.Worked example: distinguish demand from efficiency
Assume a fictional API handled 1,000,000 comparable requests at a baseline cost of USD 10,000. The comparison window handled 800,000 requests and cost USD 7,200, with no credit or rate change in this deliberately simplified example. The invoice difference is USD 2,800. At the baseline unit cost, the lower-demand workload would have cost USD 8,000. The normalized efficiency benefit is therefore USD 800, or 10% of that normalized baseline.
This proportional adjustment is suitable only when the selected cost changes approximately with the measured demand. A fixed database, minimum cluster capacity or tiered price can invalidate the assumption. In those cases, model fixed and variable components separately and document uncertainty instead of forcing the same percentage.
baseline_unit_cost = 10000 / 1000000
normalized_baseline = baseline_unit_cost * 800000 # 8000
normalized_benefit = normalized_baseline - 7200 # 800
benefit_percent = 800 / 8000 * 100 # 10Do not count the same opportunity twice
A rightsizing recommendation and a commitment recommendation may cover the same compute hours. Apply the intended implementation sequence to the reduced usage baseline, rather than adding both standalone estimates. Mark dependencies and overlap groups in the findings register.
Separate potential monthly run-rate benefit from realized cost reduction over a measured window. If the engineering work costs USD 1,600 and a stable normalized benefit is USD 800 per month, a simple payback illustration is two months. That arithmetic excludes future demand changes, ongoing fees, tax, currency effects and the time value of money; it is not a commercial forecast.
Acceptance is a joint engineering and finance decision
Before the change, agree availability, latency, error and rollback thresholds with the application owner. Record the approved change and validation window. Afterward, confirm service health, then validate the economics with the finance owner. A lower cost during an outage is not a successful saving.
Keep the baseline and comparison exports in restricted storage. The public template needs evidence references, not raw account IDs, credentials or customer data. Keep unrealized findings as estimates and mark insufficient data explicitly. Review the measurement and acceptance record with the assigned technical and finance owners before applying it to a production decision.
Before acting, confirm the owner, evidence, production risk, expected outcome, and validation method for each recommendation.