Alright, let’s talk about Savings Plans. This is where AWS billing goes from “mildly terrifying” to “actually manageable,” provided you know what you’re doing. Think of it as the corporate discount card for the cloud. You’re committing to spend a certain amount of money per hour ($10/hour, for example) on compute services for a 1 or 3-year term. In return, AWS gives you a significantly lower hourly rate. It’s a win-win: you save money, and AWS gets a predictable revenue stream. They love that.

The genius (and, initially, the confusion) of Savings Plans is that they decouple the discount from a specific instance. With old-school Reserved Instances, you were committing to a specific instance type in a specific region. If that instance got deprecated or your needs changed, you were stuck. Savings Plans are more flexible. You commit to a dollar amount, and that commitment is applied to whatever eligible compute usage you have, up to that hourly rate.

There are two main flavors you need to know about, and the difference is crucial.

Compute Savings Plan: The Flexible Powerhouse

This is the one you probably want. It’s the most flexible option. Your hourly commitment applies to any EC2 instance usage—regardless of family, size, region, OS, or tenancy. It even applies to Fargate and Lambda (if you’ve committed to EC2, it applies to Fargate; if you’ve committed to Fargate, it applies to Lambda). This is the “set it and forget it” of AWS discounts.

Why is this so powerful? Because your applications change. You might move from a c5.large to a m6i.xlarge, or even from EC2 to Fargate. With a Compute Savings Plan, your discount follows you. You’re not betting on your infrastructure staying static for three years, which is a fool’s bet.

The discount is typically the best you can get—up to 66% compared to On-Demand. You’re paying for flexibility, and it’s worth every penny.

EC2 Instance Savings Plan: The Specific (and Cheaper) Bet

This one is more like the Reserved Instances of yore, but slightly smarter. It’s cheaper than a Compute Savings Plan (up to 72% discount), but it’s also more rigid. You commit to a specific instance family within a specific region. For example, you commit to $5/hour of m5 usage in us-east-1.

This is a fantastic deal if you are absolutely, positively sure that your m5 workload in North Virginia isn’t going anywhere for the next one to three years. The moment you shift that workload to a c6g instance or to eu-west-1, the discount doesn’t apply. You’re back to paying On-Demand rates for that new usage.

Use this only for your stable, predictable, foundational workloads. Your core production database? Maybe a candidate. Your ever-evolving analytics cluster? Probably not.

How It Actually Applies: The Magic of the Benefit Hierarchy

This is the part that makes people’s heads spin, but it’s simple once you get it. AWS applies your discounts in a specific order to maximize your savings. They use your most flexible commitments first, then your more specific ones.

  1. First, they apply any Reserved Instance discounts. These are the most specific, so they get used first.
  2. Second, they apply your Compute Savings Plan commitment. This covers whatever is left, across any instance family or region.
  3. Third, they apply your EC2 Instance Savings Plan commitment. This covers anything leftover that matches its specific criteria (family, region).
  4. Whatever is left gets billed at the full On-Demand rate.

This hierarchy is why it’s generally safe to buy both types. The flexible Compute Plan will cover a broad swath of your usage, and the cheaper, specific Instance Plan will act as a targeted discount on top of that for your rock-solid workloads.

The Gotchas: Read This So I Don’t Get an Angry Email

  • It’s a Financial Commitment, Not a Capacity Reservation: This is the biggest mental shift from RIs. Savings Plans do not guarantee capacity. You still need to worry about availability zones and capacity. If you need guaranteed capacity, you must purchase Reserved Instances or use On-Demand capacity reservations alongside your Savings Plan. Yes, it’s annoying. No, AWS doesn’t seem inclined to fix this dichotomy.
  • You Can Get Stuck: While you can exchange or sell Standard RIs, you can’t sell a Savings Plan. You can exchange them for new ones, but the new commitment must have a longer term than the remaining term on the old one and a higher hourly commitment. So, if your needs drop, you might be stuck paying for something you don’t use. You can only reduce your commitment by letting it expire.
  • The “Usage” Rate is the Key: When you’re in the AWS console, it will show you your potential savings. Pay very close attention to the “recommended” amount. It’s based on your last 30 days of usage. If you had a one-off project last month that spiked your usage, and you buy a Savings Plan to cover it, you’ll be grossly over-committed when that project ends. Always analyze your usage in Cost Explorer over a longer, more representative period.

How to Buy: Using the AWS CLI

You don’t have to click through the console. You can describe your commitment programmatically. Here’s how you’d get the offerings for a 3-year term paid all upfront (the cheapest option).

# Describe the Savings Plans offerings for EC2
aws savingsplans describe-savings-plans-offerings \
  --product-type EC2 \
  --plan-type COMPUTE \ # Or EC2_INSTANCE for the other type
  --durations 31536000 \ # 3-year term in seconds (1-year is 31536000? Wait, no...)
  --payment-options AllUpfront \
  --region us-east-1

Whoops. Let’s get that right. The duration for a 3-year term is actually 94608000 seconds. A 1-year term is 31536000. My bad. This is exactly the kind of annoying conversion that makes the CLI a pain for this. This command will return a JSON blob with an offeringId and rates.

A more practical approach is to use the recommendation API to see what AWS suggests based on your usage.

# Get Savings Plans purchase recommendations
aws cost-explorer get-savings-plans-purchase-recommendation \
    --savings-plans-type COMPUTE \
    --term-in-years 3 \
    --payment-option AllUpfront \
    --lookback-period-in-days 30

This will give you a data-driven suggestion on how much to commit to. It’s the best place to start.

The bottom line? Start with a Compute Savings Plan for your base load. It’s the closest thing to a no-brainer in the AWS pricing universe. Use EC2 Instance Savings Plans for the extra savings on your truly static workloads. And for the love of all that is holy, use Cost Explorer to model it first. Your CFO will thank you.