FinOps — AWS Reserved instances vs Savings Plans

Claranet
7 min readJul 6, 2021

--

This article will help you to understand the difference between Reserved Instances (RI) and Savings Plans (SP) on Amazon Web Services (AWS). It will also help you to choose the right decision for your reservations.

Matrix RIs/Savings Plans

This board is a quick view sumup of the difference between the different possibilities offered by AWS.

Claranet decision tree and Recommendation

Some elements to take into account

  • Rightsizing is very important and does not prevent making reservations (small instances)

Definition :

Rightsizing is a form of optimization where measurements are taken over time to assess the periodic requirements of a workload running in the cloud, and to match it to a virtual resource which is sized to run it efficiently with a minimum of waste. It is important to measure actual workload demand in small increments rather than using average load figures to be sure that workloads requiring larger instances for peak demand are accommodated. Rightsizing can be used as a technique to save cost but must always involve technology oversight as well.

  • The term of the commitment : reservations are made over 1 or 3 years. If they can be made, reservations over 3 years offers reductions often greater than 50%. This means that after 18 months, the cost becomes as free for the next 18 months compared to on-demand.
  • Payment for the commitment
  • All-Upfront
  • Partial-upfront
  • No-Upfront

When you buy Reserved Instances, the larger the upfront payment, the greater the discount. To maximize your savings, you can pay all up-front and receive the largest discount. Partial up-front RI’s offer lower discounts but give you the option to spend less up front. Lastly, you can choose to spend nothing up front and receive a smaller discount, but allowing you to free up capital to spend in other projects.

AWS wants to sell an All-Upfront Savings Plan (or RI), to get cash. But if you offer no cash upfront, they’re essentially lending you the money to buy that Savings Plan. The difference in the total savings between a Partial upfront and an all-upfront is the interest on that loan over 1 or 3 years that AWS is charging to get the discount.

  • technical team must be aware of the decisions

Saving Plans

In an AWS organization (consolidated billing), Savings Plans SHOULD BE bought in an empty AWS Account (except if you don’t want to share SP with other AWS accounts). Usually, it’s the Root/Master account but, if there are running resources which can match the Savings Plans, use another account.
“The problem comes into play when there are multiple accounts in an AWS organization. While Savings Plans have wide applicability, they apply first to ALL matching resources in the account where they reside, then float to the highest discounted resources elsewhere in the AWS organization. This means if there are lower discounted resources in the account where a Savings Plan is purchased, those resources will be covered first before other higher discount resources, leading to a suboptimal savings outcome.” source

To go deeper

Savings Plans(Financial Commitment)

AWS Savings Plans have between three and five components that determine the price:

  • The type of plan — EC2 Instance Savings Plan or Compute Savings Plan
  • The term of the commitment — one year or three years
  • Payment for the commitment — all upfront, partial upfront, or no upfront
  • The Region (EC2 Instance Savings Plans only)
  • The instance family (EC2 Instance Saving Plans only)

Savings Plans are purchased as a committed hourly spend. It means that you’re engaged to spend at least XX$/hours of computing and if you spend more than this price you pay the difference at the On-Demand rates.
“To reward” this commitment, AWS applied a discount on the On-Demand price(ex: m5.large On-Demand rate $0.107Saving Plan Rate $0.067)

Simple Examples:
You want to buy a saving plan for 3 running instances m5.large(reminder: m5.large On-Demand rate $0.107Saving Plan Rate $0.067)
Without savings plans 0.107 * 3 = 0.321 $/hour = 231.12 $/month

With a full saving plan commitment coverage of 0.3 $/hour:

0.067 * 3 = 0.201 $/hour = 144.72 $/month # and 0.099$/hour(70.56$/month) remains available for other running instances.

With a partial saving plan coverage commitment of 0.134 $/hour:

(0.067 * 2) + 0.107 = 0.241 $/hour = 173.52 $/month # Only 2 instances are covered by the saving plan. The last one will be charge at the On-Demand price.

With a (smaller) partial saving plan commitment of 0.10 $/hour:

0.10/0.067 = 1.49 #As 0.10 doesn’t cover 2 instances we applied a rate
(1.49 * 0.067) + (0.51 * 0.107) + 0.107 = 0.2614 $/hour = 188.208 $/month

The discount applied is variable regarding the instance parameters(OS/Tenancy/Family/Size/Region).
Example: in eu-west-1 for a Linux instance, shared tenancy, no upfront, 1-year term:

As you can see, the discount is 5% more important for m5 instances compared to m4. So you can optimize, a little bit more, your savings plans discount by selecting the best-discounted instances.

As a side note, by default, when AWS applied savings plans it takes first, the resources with the highest discount percentage(if equal it takes the one with the lower saving plan rate). Let’s say you have 5 m5.large and 5 m4.large but regarding your hourly commitment(XX $/hour) it can cover only 6 instances. AWS will discount the 5 m5.large and 1 m4.large and the remaining ones will be charged at the On-Demand rate.

There are two types of Savings Plans, “Compute Savings Plans” and “EC2 Instance Savings Plans”.

Good to Know : calculated bills with Saving Plans

Savings Plans apply to your usage after the Amazon EC2 Reserved Instances (RI) are applied.
Your current Savings Plans are grouped together and applied to the eligible usage. EC2 Instance Savings Plans are applied before Compute Savings Plans because Compute Savings Plans have broader applicability.

In a Consolidated Billing Family, Savings Plans are applied first to the owner account’s usage, and then to other accounts’ usage. This occurs only if you have sharing enabled.
We calculate your potential savings percentages of each combination of eligible usage. This percentage compares the Savings Plans rates with your current On-Demand rates. Your Savings Plans are applied to your highest savings percentage first. If there are multiple usages with equal savings percentages, Savings Plans are applied to the first usage with the lowest Savings Plans rate. Savings Plans continue to apply until there are no more remaining usages, or your commitment is exhausted. Any remaining usage is charged at the On-Demand rates.

Compute Savings Plan

Compute Savings Plans offer more flexibility, but a smaller discount — up to 66 percent compared against On Demand rates. The plans can be applied to EC2 instances, AWS Fargate services, and AWS Lambda services in any region, across any instance family, and between services (if, for example, container workloads running on Amazon ECS are moved to the Fargate service).

EC2 Instance Savings Plan

EC2 Instance Savings Plans offer savings of up to 72 percent compared against On Demand rates depending on the term of the commitment, payment option used, and instance family. This plan can only be applied to EC2 instances in a specific instance family in a specific region (i.e. M5 EC2 instances in N. Virginia), but will continue to apply if instance sizes, operating systems, or tenancies are changed.

Reserved Instances(Utilization Commitment)

When you purchase a Reserved Instance, you can choose between a Standard or Convertible offering class. The Reserved Instance applies to a single instance type, platform, scope, and tenancy over a term.

There are eight components that determine the price of an Reserved Instance:

  • Platform (e.g. Linux)
  • Instance type (e.g. m4.large)
  • Scope (e.g. Regional or Availability Zone)
  • Network (e.g. virtual private cloud or classic)
  • Tenancy (e.g. dedicated)
  • Term (typically 1 or 3 years, although variable terms can be found on the Amazon Reserved Instance Marketplace)
  • Type of reservation offering (e.g. No Upfront)
  • Class of reservation (e.g. Convertible or Standard)

Standard RI

Standard RIs can be modified in the following ways:

  • Switching between Regional and an Availability Zone scope
  • Switch between Availability Zones for reservations scoped to a specific zone within the same region
  • Switching between Classic EC2 and Virtual Private Cloud
  • Altering the instance size within the same family

Convertible RI

Convertible RIs are much more flexible than Standard RIs. You can exchange them in all the ways you can for a Standard RI, but in addition you may:

  • Exchange for a new instance type
  • Exchange for a new operating system
  • Exchange for a different tenancy
  • Exchange for a different instance sizes

--

--

Claranet
Claranet

Written by Claranet

Combining pioneering technologies, practices, and expertise to propel your business ambitions