Right, let’s talk about giving AWS a pile of money upfront so they stop taking so much of your money every month. It’s a weird financial ritual, but it works. We’re diving into Reserved Instances (RIs) and Savings Plans (SPs), the two primary ways you commit to AWS to get massive discounts. Think of it like buying a coffee subscription instead of paying for each overpriced latte individually. The goal isn’t to just buy these things; it’s to buy the right ones. Screwing this up is expensive, and I’ve seen it happen more times than I care to admit.

The Core Idea: Trading Flexibility for Cash

At its heart, an RI or SP is a billing discount applied to resource usage in exchange for a commitment. You’re saying, “Hey AWS, I promise to run an m5.large in us-east-1 for the next year. Please stop charging me an arm and a leg for it.” AWS loves this. It gives them predictable revenue. You love it because you get a discount of up to 72% compared to On-Demand. The catch? You’re on the hook for that commitment. If you stop using that m5.large, you’re still paying for it. It’s the gym membership of the cloud world.

Reserved Instances: The Old Guard

RIs are the legacy way to do this. They’re a bit fussy and require you to think about specific attributes. When you buy an RI, you’re reserving capacity for a specific:

  • Instance Type (e.g., m5.large)
  • Region (e.g., us-east-1)
  • Tenancy (default or dedicated)
  • Platform (Linux/Windows, SUSE, etc.)

The discount only applies to an instance that matches all of those attributes exactly. It’s like having a coupon that’s only valid for a grande, oat milk, double-shot, 145-degree latte. If you change your order, the coupon is useless.

The biggest “gotcha” here is that RIs are billing constructs, not capacity reservations. Buying an RI in us-east-1 does not guarantee AWS will have capacity for you when you launch an instance. It only guarantees you’ll get the discount if you do. This trips up everyone at least once.

Savings Plans: The Flexible Upgrade

Savings Plans are AWS’s admission that RIs are too rigid. Instead of committing to a specific instance type, you commit to a certain amount of compute usage (measured in $/hour) for a term (1 or 3 years).

There are two main types:

  1. Compute Savings Plans: The king. This is the one you probably want. It applies to any EC2 instance usage, regardless of family, size, region, OS, or tenancy. It even applies to Fargate and Lambda. You change from an m5.large to a c6i.xlarge? The discount still applies. You move your workload from Ohio to Tokyo? Discount still applies. It’s glorious flexibility.
  2. EC2 Instance Savings Plans: A bit more specific. The discount applies to a specific instance family in a specific region (e.g., all M5 types in us-east-1). It’s cheaper than a Compute SP but not as flexible.

The AWS billing system automatically applies your SP commitment to your most expensive On-Demand usage first. You don’t have to micromanage it.

How to Actually See Your Recommendations

You don’t have to guess. AWS Cost Explorer has a dedicated section for this, and it’s surprisingly good. It analyzes your last 7-30 days of usage and tells you exactly what to buy. The key is to look at the “recommended” amount, not just the “potential savings.”

Let’s pull this data ourselves with the AWS CLI because I don’t trust a pretty UI for serious decisions. We’ll use the Cost Explorer API.

# Get RI recommendations for EC2
aws ce get-reservation-purchase-recommendation \
    --service AmazonEC2 \
    --lookback-period-in-days THIRTY_DAYS \
    --term-in-years ONE_YEAR \
    --payment-option NO_UPFRONT \
    --service-specification '{
        "EC2Specification": {
            "OfferingClass": "STANDARD"
        }
    }'

This command spits out a JSON blob that tells you what instances you’re using, how much you could save, and what your recommended upfront commitment should be. The --payment-option is crucial: NO_UPFRONT (all paid monthly), PARTIAL_UPFRONT, or ALL_UPFRONT. More upfront cash means a bigger discount.

Now, let’s do the same for Savings Plans.

# Get Savings Plans recommendations
aws ce get-savings-plans-purchase-recommendation \
    --lookback-period-in-days THIRTY_DAYS \
    --term-in-years ONE_YEAR \
    --payment-option NO_UPFRONT \
    --sp-type COMPUTE_SP

The output here will show you a recommended hourly commitment amount. Multiply that by 24 * 365 to understand your annual spend.

The Art of the Commitment: What to Actually Buy

Here’s the tactical advice you’re here for:

  1. Start with Compute Savings Plans. Unless you’re running a hyper-static environment where nothing ever changes (you’re not), the flexibility is worth the slightly lower discount. It future-proofs you against instance type upgrades and regional shifts.
  2. Buy in increments. Don’t just blindly buy the full recommended amount. Your usage fluctuates. Buy 50-70% of the recommendation, see how it covers your bill for a month, then buy more. You can have multiple SPs or RIs.
  3. Prioritize Stable Workloads. Use SPs for your baseline, always-on infrastructure: your databases, your application servers, your Kubernetes nodes. Do not use them for dev/test environments that you tear down every night or auto-scaling groups that scale to zero. That’s a recipe for wasted commitment.
  4. The 3-Year vs. 1-Year Dilemma. A 3-year term gets you a bigger discount. It also locks you in for three years. In the fast-moving world of cloud tech, that’s an eternity. I almost always recommend 1-year terms. The extra discount from 3 years rarely outweighs the risk of your architecture changing fundamentally. Calculate the break-even point; sometimes it’s not worth it.
  5. Check Your Scope. When you buy, you can set the scope to “Region” or “Entire account.” For SPs, “Entire account” is usually the way to go unless you have a very good reason to isolate spend to a single region.

Common Pitfalls (Where People Get Burned)

  • Ignoring Utilization: This is the big one. If you buy an RI for an instance you use 50% of the time, you’re wasting the other 50% of the commitment. The discount only applies when the instance is running. Always check your utilization in Cost Explorer before buying.
  • Forgetting About Convertible RIs: There’s a second class of RI called a “Convertible” RI. It has a smaller discount but allows you to change almost any attribute (instance type, family, OS, tenancy) during the term. It can be a good middle ground if you absolutely need the capacity reservation but want some flexibility.
  • The Region Lock: A us-west-2 RI does nothing for your us-east-1 instances. This seems obvious until you’re a month into a new project and realize your discount isn’t applying because someone launched everything in a different region.
  • Platform Mismatch: Your RI is for Linux. Your developer accidentally provisions a Windows instance. Congrats, you’re paying full price. Savings Plans elegantly solve this specific nightmare.

The golden rule: never commit to something you aren’t absolutely certain will be running for the entire term. It’s better to leave some savings on the table than to be locked into paying for something you don’t use. Now go forth and optimize. Just do it thoughtfully.