Reserved instances save real money, but only if you’re confident about your baseline load for the length of the commitment. For a small team, that confidence is the whole question — not the discount percentage.

The discount is real but not the point

1-year and 3-year commitments typically knock 30-50% off on-demand pricing depending on the provider and payment option. That’s a genuine saving. The risk isn’t the math, it’s the commitment: you’re betting that your infrastructure shape today is roughly what it’ll look like in 12-36 months.

When it pays off

• You have a stable baseline — a database, a couple of always-on API servers, anything that’s been running at roughly the same size for 3+ months with no planned rearchitecture.
• You’re not mid-migration. If you’re planning to move off a managed instance to something serverless, or switch cloud providers, or refactor a monolith into services, don’t lock in reserved pricing for the shape you’re about to abandon.
• You can commit without stressing cash flow. Upfront payment gets the best discount, but a small team paying upfront for a 3-year term is tying up capital that might be worth more elsewhere.

When it doesn’t

• Early-stage products where instance sizes and counts are still changing month to month. You’ll either overcommit and pay for capacity you shrink out of, or undercommit and barely save anything.
• Workloads you’re actively trying to move to spot instances or serverless. Reserved pricing is a bet on staying put; those approaches are a bet on flexibility. Don’t hedge both at once on the same resource.
• Anything where you’re not sure if the product itself survives the commitment window. A 3-year reservation on a side project you might sunset next year is a bad trade regardless of the discount.

Putting the three sections above together, here’s the actual decision:

flowchart TD
    A[Considering a commitment] --> B{Stable baseline for 3+ months?}
    B -- No --> C[Stay on-demand]
    B -- Yes --> D{Mid-migration or changing approach?}
    D -- Yes --> C
    D -- No --> E{Confident the product survives the term?}
    E -- No --> C
    E -- Yes --> F{Sure of exact instance shape?}
    F -- No --> G[Compute savings plan]
    F -- Yes --> H[Reserved instance]
  

The middle ground: savings plans

Most providers now offer a compute savings plan instead of an instance-specific reservation — you commit to a dollar-per-hour spend, not a specific instance family, and it applies automatically across instance types and even across regions in some cases. This gets you most of the discount with much less lock-in risk, since you can change instance sizes without losing the discount. For a small team unsure about exact future shape but confident about rough spend level, this is usually the better trade than a classic RI.

Compute Savings Plan: commit to $0.50/hr compute spend, 1-year term
→ ~28% discount, applies across instance family/size/OS automatically

Do the math before committing

Pull your last 3 months of on-demand spend on the resource you’re considering. If it’s been flat or growing, reserved pricing wins. If it’s been shrinking or volatile, wait.

aws ce get-cost-and-usage \
  --time-period Start=2026-06-16,End=2026-09-16 \
  --granularity MONTHLY --metrics "UnblendedCost" \
  --filter '{"Dimensions":{"Key":"INSTANCE_TYPE","Values":["m5.large"]}}'

If the number’s been stable for a quarter, a 1-year term is low-risk. Save the 3-year term for infrastructure you’re certain is foundational — the database, not the app server you rewrite every year.

The gotcha

The break-even point on most reserved terms is 6-8 months of continuous use. If there’s a real chance you shut down or resize before then, on-demand costs you less even at the “worse” hourly rate. Run the break-even math against your actual survival odds for that resource, not just the sticker discount.