Reserved & Savings Plans #

In cloud computing, full flexibility is a premium feature that’s very expensive. When using the standard On-Demand pricing model, we pay full hourly or per-second rates with the benefit of freely shutting down or changing machine types anytime. However, for application workloads that have stabilized and are predictable long-term, this On-Demand model becomes highly uneconomical. Cloud service providers offer massive price discounts (reaching over 70%) through long-term commitment schemes known as Reserved Instances (RI) and Savings Plans. By committing to use a minimum amount of compute capacity over 1 or 3 years, we can drastically cut infrastructure spending. The key to this strategy’s success is balancing financial savings levels with architectural flexibility loss risks (over-commitment).

Concept: Trading Flexibility for Discounts #

Cloud commitment pricing models are based on a simple economic exchange principle: cloud providers gain long-term revenue certainty to plan their physical hardware purchases, and in return, we get significant price cuts.

flowchart TD
    subgraph SkenarioBeban ["Compute Usage Patterns & Cost Allocation"]
        direction TB
        BebanPuncak["Peak Load (Burst Traffic)\n- Unpredictable / fluctuating"]
        BebanDasar["Baseline Workload\n- Stable running 24/7"]
        BebanBatch["Batch Load / Background Jobs\n- Flexible start times"]
    end

    subgraph StrategiHarga ["Optimal Purchase Models"]
        direction TB
        OnDemand["1. On-Demand Pricing\n- High flexibility\n- Regular rates"]
        Committed["2. Reserved / Savings Plans\n- Discount (30-72%)\n- Tied to commitments (1-3 years)"]
        Spot["3. Spot / Preemptible Instances\n- Discount (60-90%)\n- Can be unilaterally terminated"]
    end

    BebanPuncak -. "Allocated to" .-> OnDemand
    BebanDasar -. "Allocated to" .-> Committed
    BebanBatch -. "Allocated to" .-> Spot

1. Property Rental Analogy #

To make understanding easier for teams, we can equate the three cloud compute purchase models with physical accommodation options:

• On-Demand (Daily Hotel Rental): We can check in today and check out tomorrow morning without penalties. The nightly rate is very high because we’re buying absolute freedom.
• Reserved / Savings Plans (Annual Apartment Contract): We sign a 12-month lease contract. Monthly rates are far cheaper than daily hotel rates. However, if we decide to move cities in month three, we’re still obligated to pay the apartment’s remaining rent until the contract ends.
• Spot / Preemptible (Standby Room Rental): We rent leftover empty rooms at 85% discounts, but with the condition that if main guests arrive paying full price, we must vacate the room within a short time.

2. When Should We Use Commitments? #

We should only buy commitments when:

• Infrastructure workloads have run stably for at least 3 consecutive months.
• No major technology migration plans (like moving from VMs to Serverless) exist in the near future.
• Core system architectures (like primary database clusters) have been agreed upon and won’t change specifications.

Reserved Instances (RI) in Depth #

Reserved Instances are the first-generation commitment mechanism offered by cloud providers like AWS. It’s important to note that buying RIs doesn’t mean we rent new physical servers; RIs are accounting discount instruments automatically applied by billing systems to active instances matching our commitment criteria.

1. Main RI Purchase Parameters #

When buying Reserved Instances, we must lock in the following parameters:

• Term: 1-year or 3-year options. 3-year commitments offer far larger discounts, but carry high technology change risks.
• Instance Family: Locks the machine CPU/RAM type (e.g., the m5, c6g, or t3 families).
• Region: Physical datacenter location (e.g., ap-southeast-1).
• Payment Option:
  • All Upfront: Pay the entire 1- or 3-year commitment cost upfront. Offers the largest discount.
  • Partial Upfront: Pay part of the cost upfront, with the rest billed in monthly installments.
  • No Upfront: Pay nothing upfront; we just pay discounted commitment installments every month.

2. Standard RI vs. Convertible RI Comparison #

To give consumers some leeway, cloud providers divide RI instruments into two types:

Savings Plans (Modern Commitment Mechanism) #

To address the administrative complexity and rigidity of Reserved Instances, cloud providers launched Savings Plans. The main difference: instead of committing to specific instance types (e.g., 5 units of m5.large servers), we commit to a minimum hourly spend value (e.g., committing to spend $10.00 per hour).

1. Main Savings Plans Categories #

There are two main Savings Plans types we can choose:

• Compute Savings Plans (Very Flexible):
  • Automatically applies to all VM types (EC2), serverless container services (AWS Fargate), and serverless functions (AWS Lambda).
  • Discounts apply across regions, OSes, and instance families instantly.
  • Provides peace of mind for development teams frequently modifying their technology stacks.
• EC2 Instance Savings Plans (Higher Discounts):
  • Locks our commitment to a specific instance family in a specific region (e.g., the c6g family in the Singapore region).
  • Offers larger discounts than Compute Savings Plans, but we lose flexibility if we want to move workloads to other regions or serverless containers in the future.

2. Hourly Billing Consumption Mechanism #

Let’s study a simulation example of how billing systems apply Savings Plans hourly:

Suppose we buy Compute Savings Plans of $5.00/hour for a 1-year term.

• First Hour Case (Normal Usage): Our application runs with a total on-demand cost of $8.00 that hour. The billing system applies Savings Plans discount rates until our $5.00 commitment limit is exhausted. Remaining usage ($3.00) is billed at regular On-Demand rates.
• Second Hour Case (Reduced Usage / Under-utilization): Our application is quiet and many instances are shut down by autoscaling, so actual usage costs only $3.00. The billing system deducts our full $5.00 commitment. We experience a $2.00 inefficiency loss because we must pay the minimum agreed commitment value.

{
  "SavingsPlansRecommendations": [
    {
      "RecommendationDetail": {
        "SavingsPlansType": "COMPUTE_SP",
        "TermInYears": 1,
        "PaymentOption": "NO_UPFRONT",
        "HourlyCommitmentToPurchase": "3.45",
        "EstimatedAverageHourlySavings": "1.25",
        "EstimatedMonthlySavings": "900.00",
        "EstimatedROI": "36.2"
      }
    }
  ]
}

The JSON response format above is an example recommendation report from the AWS Cost Explorer API helping us calculate optimal commitments based on the last 30 days of usage history.

Commitment Needs Calculation Methods #

Buying commitments without careful calculations is dangerous financial speculation. We must apply systematic calculation formulas before approving contracts:

1. Determine Baseline Workload Values #

Collect our compute usage historical data from the last 3 to 6 months. Find the minimum usage value (floor value) always active 24 hours a day, 7 days a week.

$$\text{Baseline Workload} = \min(\text{Usage Hour}_1, \text{Usage Hour}_2, \dots, \text{Usage Hour}_n)$$

Use this baseline value as the maximum commitment limit we’ll purchase. Never buy commitments approaching peak traffic load values.

2. Calculate Financial Savings (ROI) #

Let’s simulate an ROI calculation for 10 c5.2xlarge instances in the AWS Singapore region running continuously for 1 year:

• Cost Without Commitments (On-Demand): On-Demand rate = $0.34 per hour per instance.

  $$C_{\text{on-demand}} = 10 \text{ instances} \times $0.34 \times 24 \text{ hours} \times 365 \text{ days} = $29,784\text{/year}$$

• Cost With Commitments (1-Year No Upfront RI): Reserved rate (No Upfront) = $0.22 per hour per instance (~35% discount).

  $$C_{\text{reserved}} = 10 \text{ instances} \times $0.22 \times 24 \text{ hours} \times 365 \text{ days} = $19,272\text{/year}$$

• Net ROI Calculation:

  $$\text{Annual Savings} = $29,784 - $19,272 = $10,512$$

  $$\text{ROI (Percentage)} = \frac{$10,512}{$19,272} \times 100% \approx 54.5%$$

By buying No Upfront commitments, we save $10,512 per year in operational costs without needing to spend upfront cash capital at contract start.

Over-Commitment Risk Mitigation Strategies #

The biggest risk of long-term commitment purchases is unexpected technology obsolescence. For example, we buy a 3-year commitment for Intel c5 instances. However, in year two, the cloud provider launches ARM c6g instances based on Graviton chips offering 40% better performance at 20% lower prices. We get trapped in a financial dilemma: keep using the expensive old Intel servers to burn through the commitment contract, or move to ARM but still pay penalties for unused Intel commitment remainder.

1. Use the 70% Rule #

To minimize risks, never buy commitments for 100% of baseline capacity at once. Start by buying commitments of 70% of the baseline value. Let the remaining 30% run on On-Demand or Spot schemes. Over time, if historical data proves our baseline keeps rising stably, we can buy additional commitments gradually (staggered commitments).

2. Monitor Two Key Metrics #

We must monitor two main metrics in cloud billing dashboards:

• Commitment Coverage Rate: The percentage of our total compute costs covered by commitment discounts. Optimal targets range between 70% to 80%.
• Commitment Utilization Rate: The percentage of purchased commitments actually consumed by active applications. Optimal target is above 95%. If utilization rates fall below 80%, that’s a strong indicator we’re wasting money on empty commitments.

Commitments for Database and Non-Compute Services #

Long-term discount commitment programs aren’t limited to compute virtual machines (EC2/VMs). We must also apply commitment strategies to other supporting infrastructure components:

1. Managed Databases #

Managed database services (like AWS RDS, Amazon Aurora, or Google Cloud SQL) run continuously 24 hours a day and rarely experience sudden instance type changes. Therefore, databases are the best and safest candidates for Reserved DB Instance purchases.

2. Cache & Search Clusters #

Memory cache clusters (like ElastiCache Redis) and search engines (like OpenSearch/Elasticsearch) generally have very regular baseline workload patterns. Applying Reserved Node commitments to these clusters can cut supporting database bills by up to 45%.

Summary #

• Reserved Instances and Savings Plans trade flexibility for discounts — Offering 30% to 72% price cuts with 1- or 3-year contract commitment requirements.
• Convertible RIs allow parameter change leeway — Compared to rigid Standard RIs, Convertible RIs allow changing instance families if architecture needs evolve.
• Compute Savings Plans are the most flexible option — Automatically applying across regions, instance types, operating systems, as well as Fargate container and Lambda serverless services.
• Apply commitments only to baseline capacity — Calculate historical minimum compute usage values, and limit initial purchases to a maximum of 70% of that baseline.
• Use ROI formulas to measure break-even points — Transparently evaluate annual savings comparisons between commitment models and On-Demand schemes.
• Production databases are the primary commitment targets — Because databases run stably 24/7 and rarely change instance types, over-commitment risks become very low.

← Previous: Cost Allocation & Tagging   Next: FinOps →