Reserved vs. On-Demand Pricing
18 min
Cloud providers typically offer a steep discount for reserved (or "committed use") capacity — pay some amount upfront (or commit to a term) in exchange for a lower per-hour rate versus on-demand pricing. Whether that's a good deal depends entirely on how long you'll actually run the resource: the upfront cost needs enough months of savings to pay itself off before it's worth it.
def break_even_months(on_demand_rate_per_hour, reserved_upfront_cost, reserved_rate_per_hour, hours_per_month=720):
monthly_on_demand = on_demand_rate_per_hour * hours_per_month
monthly_reserved = reserved_rate_per_hour * hours_per_month
monthly_savings = monthly_on_demand - monthly_reserved
if monthly_savings <= 0:
return None
return round(reserved_upfront_cost / monthly_savings, 2)
A workload you'll run for 6 months should almost never buy a reservation with an 18-month break-even point -- this exact calculation is the deciding factor real infrastructure teams run before committing budget to reserved capacity, not a guess based on the sticker discount percentage alone.
Write `break_even_months(on_demand_rate_per_hour, reserved_upfront_cost, reserved_rate_per_hour, hours_per_month=720)`: compute the monthly cost under each pricing model, then return how many months of savings it takes for the reserved option's upfront cost to pay for itself (`upfront_cost / monthly_savings`, rounded to 2 decimal places). Return `None` if the reserved rate isn't actually cheaper per month.
Why would a cloud provider offer a CHEAPER hourly rate in exchange for an upfront payment (reserved/committed pricing) instead of just charging everyone the same on-demand rate?
You can compute a reserved-vs-on-demand break-even point, and understand why providers exchange a lower rate for the reduced business risk of an upfront commitment.