AWS Savings Plans for FinOps: Compute vs EC2 comparison

For a UK FinOps team, the Compute-versus-EC2 decision starts with workload mobility: Compute Savings Plans cover eligible EC2, Fargate and Lambda usage, while EC2 Instance Savings Plans bind the discount to one EC2 instance family in one Region.[1] Commit only after testing a realistic hourly baseline, migration plans and the cost of quiet periods.

Compare the scope before the discount

Database Savings Plans are an officially documented AWS product, not an unconfirmed third-party offering.[1] A service name alone does not mean every charge on that service is covered. Keep storage, requests, software charges and other line items outside the model unless the relevant eligibility documentation includes them.

For Compute and EC2 Instance plans, AWS describes one- or three-year commitments and All Upfront, Partial Upfront or No Upfront payment choices.[4] Compare actual account rates for the same workload and term. Headline maximum discounts are not a forecast of the percentage by which your total bill will fall.

Keep commitment consumption and On-Demand charges separate

A commitment is money per hour, not a count of instances or an On-Demand-equivalent bill. Covered usage consumes that commitment at the applicable Savings Plans rates. Uncovered usage is charged at its On-Demand rates; unused hourly commitment does not carry forward.[2] Do not subtract a dollar commitment from a usage quantity or assume the remaining discounted-rate value is the On-Demand charge.

For a single-rate illustration, let C be the hourly commitment, q the usage units in the hour, s the Savings Plans price per unit and o the On-Demand price per unit. Covered units are the lesser of q and C/s. The simplified hourly cost is C plus uncovered units multiplied by o. Unused commitment is C minus covered units multiplied by s. These equations are an explanatory model for one rate, not an AWS invoice reconstruction.

All figures are invented for arithmetic, in US dollars, with no tax, currency conversion or unrelated charges. For example, an hour with only two units still costs the $6 commitment in this model, versus $2 On-Demand. A plan can therefore lose money during underuse even when its per-unit discount looks attractive. With upfront payment, distinguish amortised hourly economics from the timing of cash payment.

Real estates contain multiple rates. AWS documents application priorities, including EC2 Reserved Instances before Savings Plans, EC2 Instance plans before Compute plans, and eligible usage with higher discount percentages first.[2] Use billing tools and actual line items for the final model.

Use recommendations as historical evidence

AWS recommendations simulate additional commitment against the selected historical period; they do not forecast future usage. Queued or scheduled purchases are not included. Compute and EC2 recommendations use the same usage base, so buying both recommendations in full can duplicate the intended coverage.[5]

1. Choose the relevant estate: record accounts, sharing settings, Regions, services and existing commitments.
2. Explain changes: mark planned rightsizing, shutdowns, migrations and business seasonality rather than treating last month as a forecast.
3. Model quiet hours: examine the recurring floor and weekends as well as high-demand periods. Test several smaller candidate commitments.
4. Reconcile pending purchases: check scheduled orders before approving more commitment.
5. Record the decision: retain the inputs, assumed rates, sensitivity cases, approver and workload owner.

AWS distinguishes management-account recommendations, which consider relevant shared usage across the organisation, from member-account recommendations for an isolated account.[5] Confirm that the analysis boundary matches the intended purchasing and sharing arrangement.

Monitor utilisation and coverage together

Utilisation asks how much of the purchased commitment was consumed. Coverage asks how much eligible usage received Savings Plans benefits; AWS expresses coverage using the On-Demand-equivalent spend basis.[6] A fully used commitment can still leave substantial eligible demand uncovered. Conversely, pursuing a high coverage target can leave commitment unused during quieter hours.

Assign a monthly review owner and an earlier review after major workload changes. Investigate whether uncovered usage is durable before adding commitment, and whether unused commitment reflects a temporary dip or a permanent change. AWS Cost Explorer provides reporting and budget alerts to support this work.[4]

Understand the limited return mechanism

AWS permits returns for eligible active plans with commitments of $100 per hour or less, purchased within the last seven days and the same calendar month in UTC, subject to the return quota and other restrictions. Returns also require appropriate permissions; seller-of-record and management-account conditions can matter.[3]

Returning a plan refunds upfront charges, while previously covered usage is repriced On-Demand or covered by another applicable plan. AWS states that a return cannot be reversed.[3] This is a limited correction mechanism, not a general cancellation right or a reason to skip purchase approval. Confirm eligibility in the current documentation and console before relying on it.

UK approval checklist

Use the account’s actual purchase screen and agreement to record the billing currency, conversion assumptions, VAT treatment, contracting entity, cash payment schedule and total commitment. The US-dollar example above is not a GBP quote. Ask the relevant internal finance owner to resolve those account-specific fields.

Approve only when a named workload owner supports the expected usage, the commitment remains acceptable in downside cases, and the team accepts the fixed term. If the baseline or migration destination remains uncertain, leave that portion uncommitted and revisit it with better data. A conservative purchase decision is an operating judgement, not a universal utilisation threshold.

References

1. AWS — Savings Plans types (amazon.com)
2. AWS — How Savings Plans apply to usage (amazon.com)
3. AWS — Returning a purchased Savings Plan (amazon.com)
4. AWS — What are Savings Plans? (amazon.com)
5. AWS — Recommendation calculations (amazon.com)
6. AWS — Coverage metrics and calculations (amazon.com)