A large discount is tempting when the hosting bill arrives every month. The useful question is how much eligible usage will remain throughout the term. A website you expect to move or shrink can leave a cheap-looking commitment partly unused.
Right-size first, then establish a stable hourly floor. Keep money for storage, delivery, recovery and other charges outside the proposed commitment. This article compares the decision, not a particular purchasable offer.
1. Name the product before comparing terms
Savings Plans exchange an hourly spending commitment for eligible discounted usage. Compute and EC2 Instance Savings Plans have different flexibility; AWS also lists Database and SageMaker AI plans. Check the current plan types and the exact eligible configuration rather than assuming one service name describes every offer.
Reserved Instances are a separate product family. The RDS Reserved Instance page currently lists no-upfront payment for a one-year term only. Do not construct a three-year no-upfront RDS comparison from a generic AWS headline. Product, region, engine, payment option and term all belong on the offer record.
2. Find the quiet-hour floor
Look at eligible hourly usage after planned changes, not the busiest hour or a monthly average. Check weekdays, weekends, seasonal demand and scheduled shutdowns. Include expected migrations and client departures in the decision.
Translate the intended workload into spend at the plan’s applicable rates. An on-demand dollar is not automatically a dollar of required commitment. Review existing commitments and sharing arrangements before adding another one. AWS explains the allocation rules in how Savings Plans apply to usage.
A simple warning sign is a quiet hour that cannot consume the proposed amount. Unused commitment in that hour does not become a balance you can spend during tomorrow’s traffic peak. Keep uncertain growth on demand until there is stronger evidence.
3. Show liability as well as savings
AWS defines Savings Plans terms as 365 days or 1,095 days, giving 8,760 or 26,280 hours. Its Savings Plans overview describes the payment options. Multiply committed hourly spend by the contractual hours, then add any upfront payment where applicable.
Fictional example. Assume one steady eligible Linux EC2 workload in Europe (London), eu-west-2, with the same capacity throughout. The following rates are invented for arithmetic, not AWS quotes: on-demand $0.10/hour, one-year no-upfront $0.07/hour and three-year no-upfront $0.06/hour. No specific instance offer has been verified. USD, tax excluded, no credits or allowances; only eligible compute is modelled. Source and calculation check: 14 October 2026.
| Choice | First 8,760 hours | Next 17,520 hours | 36-month model total |
|---|---|---|---|
| On-demand at $0.10/hour | $876.00 | $1,752.00 | $2,628.00 |
| One-year commitment at $0.07/hour; then on-demand | $613.20 | $1,752.00 | $2,365.20 |
| Three-year commitment at $0.06/hour | $525.60 | $1,051.20 | $1,576.80 |
The one-year contract creates $613.20 of liability; the three-year contract creates $1,576.80. The one-year row assumes no renewal and an unchanged hypothetical on-demand price after expiry. It is a scenario, not a forecast of future prices.
The table is the underlying calculation data. Each cell is rate × hours; storage, requests and other unchanged costs are outside this deliberately narrow comparison. Add them to a whole-application budget, and price any architecture change separately.
4. Find when unused hours erase the discount
In this fictional fixed-workload model, the one-year choice costs $613.20 whether the workload runs every hour or stops early. At the assumed $0.10 on-demand rate, equality occurs at 6,132 used hours: 70% of 8,760. The three-year equivalent is 15,768 used hours, or 60% of 26,280.
These are arithmetic break-even points, not recommended utilisation targets. They assume the full committed amount is consumed whenever this single workload runs, no other eligible usage absorbs it, and no excess usage. Real mixed workloads need hourly modelling at their applicable rates.
If the example’s one-year plan can consume only $0.04 during a quiet hour, $0.03 of its $0.07 commitment is unused. That shortfall is part of the cost already committed, not an extra fee to add a second time. This is why monthly totals can hide a poor fit.
5. Mark expiry and the exit limits
The one-year discount ends at hour 8,760 in the table. Its first-year saving is $262.80, but multiplying that by three would assume renewals at the same unknown future rate. Keep post-expiry periods separate and price renewal only as an explicitly labelled scenario.
No-upfront payment does not mean ordinary cancellation. AWS has a limited Savings Plans return process with eligibility and timing conditions. Do not treat it as an exit strategy for a later migration. RDS reservations have their own restrictions; a rule from one product does not transfer to another.
What can go wrong?
A server migration can change eligibility. A contract can outlast the customer paying for it. Two recommendations can cover the same usage. A discount can look attractive while leaving the business with less flexibility than it needs. Record these possibilities before signing, not only when utilisation drops.
Proceed, investigate or keep on demand?
- Proceed: an exact eligible offer is checked, the hourly floor is credible and the full liability is acceptable.
- Investigate: resizing, sharing or migration plans are unresolved.
- Keep on demand: flexibility is worth more than the supported saving, or the usage is too uncertain.
Before setting that floor, review EC2 capacity and storage limits. A commitment should follow the capacity decision.
Continue the AWS review
If you are reviewing your website’s hosting, tell AceMedia Host what you need.