Reserved instances on Outscale: the math nobody does

An Outscale account manager will, at some point, suggest you reserve instances. The pitch sounds good: 30-60% off the on-demand rate, 1-3 year term, predictable spend. Sign here.

Reserved instances aren't a scam. But the math is more nuanced than "30% off, what's not to love." Here's when they actually win, when they don't, and how to think about the choice.

The headline numbers

Outscale's current reserved-instance discounts depend on term length and payment structure:

• 1-month commitment, full upfront — about 30% off on-demand
• 1-year commitment — 40-50% off depending on payment terms
• 2-year commitment — 45-55%
• 3-year commitment — 50-60%

These look strong. They are. But they assume something that's not always true: the instance will run 24/7 for the full term.

The fine print

A reservation is a financial commitment for a specific instance type, in a specific region, for a specific term. You pay the discounted rate whether the instance runs or not. Three things to internalize:

You pay 730 hours/month, every month. Even if the actual VM only runs 200 hours. The discount is on the hourly rate, not the monthly bill.

The reservation doesn't move. Bound to instance type and region. Right-size the workload to a smaller VM type — the reservation still belongs to the old one. Migrate to a different region — same problem.

Outscale's reservation policy has been shrinking. 3-year reservations were once standard; many account types now max at 1 or 2 years. Each cut narrows the term over which the discount compounds.

Where reserved actually wins

Three workload shapes make reserved instances genuinely correct:

1. Always-on production with stable demand. A database that runs 24/7 for the next two years. The reservation discount stacks across the term. Scheduling can't help (you can't shut it down). Right-sizing might, but if you've already done that, reserved is the next lever.

2. Workloads that can't be scheduled. Some things are 24/7 by nature: the API gateway, the auth server, the web tier behind a load balancer. They run all 730 hours by design. Reserved is the right tool.

3. Predictable baseline + variable peak. Reserve the baseline, leave the peak on-demand. Most production workloads have a "minimum instance count" that's stable for years — that's the reservable portion. The autoscaling delta stays on-demand and shrinks naturally during off-hours.

Where scheduling beats reserved

Three workload shapes where scheduling wins, sometimes by a wide margin:

1. Dev / staging / QA. Used 8 hours a day, 5 days a week. That's 50/168 of total hours = 70% reduction in compute via scheduling. Reserved gives you 50% off, applied to 730 hours. Scheduled gives you 100% off the unused hours, applied to the same. Scheduling wins by a factor of two on this workload, every time.

2. Batch and ETL. Run for 4 hours a night, sit idle 20. Reserved pays for the idle 20. Scheduling shuts them off entirely.

3. Anything you might right-size, refactor, or kill within the term. The reservation doesn't follow the change. If you're 9 months into a 3-year reservation when someone refactors the service onto a smaller instance type, the original reservation becomes a sunk cost.

The hybrid approach

The right answer for most teams isn't "reserved or scheduling." It's both, on different parts of the fleet.

1. Schedule everything that can be scheduled. Dev, staging, batch, anything human-driven. This shrinks the on-demand bill 30-70% on those resources.
2. For what's left (the always-on baseline), reserve it. Stable production, databases, the things that genuinely run 730 hours/month. Apply the reservation discount.
3. Re-evaluate quarterly. Workload shapes change. The thing that was always-on six months ago might now have a clear off-hours dip. The thing you reserved might be on its way out.

The decision rule

Here's a simple check. For any candidate workload, ask:

Does this run more than 730 × discount-percentage hours per month?

For a 50% reservation, that's 365 hours. If the workload actually consumes more than 365 hours/month — reserve it (or right-size first, then reserve). If it consumes less, schedule it.

For a 30% reservation, the breakeven is 511 hours. For 60%, it's 292.

This isn't a perfect rule (it ignores right-sizing benefits, term risk, and migration risk), but it's a sound first cut. Anything that runs less than the breakeven is a scheduling candidate. Anything more is a reservation candidate.

Most workloads are not at the breakeven. They're either clearly always-on (production databases) or clearly periodic (dev, batch, QA). The hard cases are rare. Don't agonize over them — pick a default, run for a quarter, and re-evaluate.