Savings Plans: a complete AWS guide for production teams

Savings Plans: Commit to spend, save on compute

If you've been running production workloads on AWS for any length of time, you've probably noticed that your bill keeps climbing. The pay-as-you-go model is flexible, but it's also expensive when you have a predictable baseline. Savings Plans let you commit to a certain amount of compute spending over one or three years and receive a significant discount in return. Think of it like signing a phone contract—you lock in a rate and pay less per unit, but you have to follow through on the commitment.

I've found that Savings Plans work best when you have a clear picture of your compute needs. Over the past five years building platforms on AWS, I've seen teams waste money by ignoring commitment discounts, and I've also seen others lock in commitments they couldn't use. The middle ground—a thoughtful, monitored approach—is where you win.

Compute Savings Plans cover EC2, Fargate, and Lambda

AWS offers several types of Savings Plans, but Compute Savings Plans are the most versatile for typical application workloads. They apply across three major compute services: EC2, Fargate (container compute on ECS/EKS), and Lambda (serverless functions). This flexibility is powerful because you're not locked into a single service or instance type.

In a recent project running a ride-hailing platform, we had traffic that split across EC2 auto-scaling groups, Fargate tasks for the matching engine, and Lambda functions for event processing. With separate Reserved Instances or on-demand pricing, we'd be paying full rates across the board. Instead, a single Compute Savings Plan commitment covered all three, and AWS applied the discount dynamically as our workload shifted between services.

Here's what that looked like in practice:

• EC2: All instance families and sizes, across all regions (if you choose regional commitment) or on-demand anywhere (if you choose all-region commitment).
• Fargate: ECS and EKS tasks running on Fargate, measured in vCPU-hours and memory-hours.
• Lambda: Function execution, measured in GB-seconds of compute.

The key insight is that you don't have to decide upfront which service gets how much of your commitment. AWS tracks your hourly spend across all three and applies the Savings Plan discount wherever you use it. This is fundamentally different from Reserved Instances, which lock you into a specific instance type.

Commit for one or three years

Savings Plans require a commitment period: either one year or three years. The longer the commitment, the deeper the discount. Typically, one-year plans offer 15–25% off on-demand pricing, while three-year plans offer 30–45% off, depending on the service and compute type.

The decision between one and three years depends on your risk tolerance and growth trajectory. If you're running a stable, mature SaaS platform with predictable customer counts, a three-year commitment might make sense. If you're in a scaling phase or exploring new markets, a one-year plan gives you more flexibility to adjust.

I tend to start with one-year commitments. You lock in a discount without betting too heavily on your infrastructure needs three years out, and the discount is still substantial. As your platform matures and you have two or three years of historical data, moving to three-year plans on your core services becomes a safer bet.

Payment options also matter. You can pay upfront, partially upfront, or all on-demand (no upfront payment). Paying upfront gives the best discount, but it ties up capital. For a bootstrapped or early-stage team, an all-upfront three-year plan might be impractical even if the discount is higher. A partial upfront one-year plan strikes a better balance for cash flow.

Start with a portion of your baseline

Here's the mistake I see most often: teams commit to 100% of their peak compute spend. Then their workload shifts, they optimize infrastructure, or they enter a slower season, and suddenly they're paying for a commitment they barely use.

Instead, commit to a portion of your baseline—the minimum compute you know you'll need. If your average daily spend is $1,000 and your peak is $1,500, commit to maybe $700–$800 worth of compute. The remaining headroom stays on-demand pricing, which is higher but gives you flexibility.

Let's walk through a concrete scenario. I worked on an e-commerce platform that handled seasonal spikes (holiday sales, flash deals) but had a stable baseline. We analyzed 12 months of billing and found:

• Minimum daily EC2 + Fargate spend: $500
• Average daily spend: $800
• Peak daily spend (Black Friday): $2,200

We committed to a $500/day Compute Savings Plan (one year, no upfront). This covered 100% of our baseline at a ~20% discount. On peak days, the extra $1,700 was on-demand, which is painful but expected and budgeted. On average days, we had $300 of on-demand overage. The math worked out to roughly 25% savings across the year.

If we'd committed to $1,500/day, we'd save more per unit hour, but we'd be paying for compute we don't use most of the time. If we'd committed to $200/day, we'd leave money on the table because our average exceeds it.

To calculate your baseline, pull your last 12 months of billing data and identify the minimum compute hours you've consistently used. Account for growth: if you've grown 10% month-over-month, project forward. Then set your commitment at 70–85% of that projected baseline.

Review coverage monthly

Savings Plans aren't set-and-forget. Every month, I review how much of the plan is being used. AWS provides detailed reports in the Cost Explorer and Billing pages showing your Savings Plan utilization rate.

A healthy utilization rate is 80–100%. Below 80%, you're likely overcommitted, and you should let that plan expire and size down next time. Above 100% would be ideal (you'd buy more), but it means you're paying on-demand for the overage, which is expensive.

Here's a practical review checklist I use monthly:

1. Pull the Savings Plan utilization report. In the AWS Billing Console, go to Cost Explorer → Savings Plans Utilization. Note the percentage.
2. Check for infrastructure changes. Did you optimize away some EC2 instances? Did you migrate a Lambda workload to Fargate? These shift your compute profile and may affect coverage.
3. Forecast forward. If you're at 70% utilization and trending downward, you know you're overcommitted. If you're at 95% and growing, consider an additional commitment.
4. Plan the next renewal. Savings Plans expire at the end of their term. AWS will start billing you on-demand if you don't buy a new plan. Decide 1–2 months before expiration what your next commitment should be.

In the ride-hailing platform I mentioned earlier, we tracked utilization weekly during our first three months, then monthly after that. We found that our matching engine (Fargate) was heavier than expected, so we'd underestimated that portion of the baseline. In month four, we bought a second, smaller Savings Plan to cover the gap. That extra $200/day commitment saved another $4,000 over the year.

Reviewing monthly also surfaces opportunities to optimize. If you see your Fargate utilization is low, maybe you can consolidate tasks or switch to EC2. If Lambda is climbing, maybe you should increase that portion of your commitment. The data drives the decision.

Common mistakes

• Committing to 100% of peak spend. You'll end up with unused commitment and waste the discount on compute you don't need. Stick to your baseline.
• Ignoring all-region commitments. If you run in multiple regions, a single all-region commitment is simpler than managing region-specific ones. You pay a small discount penalty, but operational simplicity is worth it for most teams.
• Forgetting renewal dates. If your plan expires and you don't buy a new one, your workload flips to on-demand pricing overnight. It's expensive. Use a calendar reminder for 60 days before expiration.
• Not accounting for growth. If you're in a scaling phase, don't commit based on today's spend. Project forward at least 6 months and buy accordingly, or commit to a shorter one-year term.
• Mixing Reserved Instances and Savings Plans poorly. If you have old Reserved Instances (which are now less flexible), they can create gaps in your Savings Plan coverage. Audit your existing RIs before buying a Savings Plan.

Key takeaways

• Compute Savings Plans cover EC2, Fargate, and Lambda, giving you flexibility to shift workloads between services while keeping the discount.
• One-year commitments offer ~20% savings; three-year commitments offer ~35–40% savings. Start with one year if you're still optimizing.
• Commit to 70–85% of your projected baseline compute spend, not your peak. Leave 15–30% for on-demand overages and flexibility.
• Review utilization monthly. Aim for 80–100% utilization to ensure you're not overcommitted and not wasting the discount.
• Set calendar reminders for plan expiration 60 days in advance. Missing the renewal window is expensive.