Amazon EC2 Pricing Model: Part 3

Amazon EC2 Pricing Model: Part 3

While working with EC2 instances, we would want the amount paid toward the EC2 instances must be as low as possible and to achieve this we must know the different EC2 pricing models. We will look at the different available pricing models below.

On-Demand Instances:

In the case of on-demand instances, we will ask AWS to provide an EC2 instance then will use that instance and once done will terminate that instance. this instance has the highest cost and highest flexibility.

The On-demand instances are ideal for a web application with spiky traffic i.e we don't know how much traffic we would receive. Also, we can use this instance in case of a batch program that has unpredictable runtime and can't be terminated.

Spot Instances:

Every spot instance has some price which will vary across regions, In the old model, we needed to bid a price and the highest bidder will be getting the spot instance.

In the new model, we need to quote the max price and if the spot instance price is less than the one we quoted then the spot instance will be allocated to us. We can get the spot instances almost 90% off as compared to the on-demand instances.

Aws will give a 2-minute notice before terminating the spot instances, now why AWS will take back the spot instances? So as we quoted a max price for the spot instance the current spot instance price might cross the max price limit set by us so in this case AWS can take back the spot instances.

So the spot instances are ideal for workloads that can tolerate interruptions and do not have strict deadlines, an example would be a batch program that has no strict deadline and can be stopped at short notice and then restarted.

The best practice while working with spot instances is that, we should always either "Stop" or "Hibernate" the spot instances when we receive an instance termination notice by AWS, doing this will allow us to restart from where we left off, there are some variations for spot instances which are mentioned below.

Spot Block:

  • Request a spot instance for a specific duration (1 or 2 or ... 6 hrs)

  • ideal for jobs that take a finite time to execute.

Spot Fleet:

  • Request spot instances across a range of instance types.

  • the more instance types we specified, the better our chances to get a spot instance.

Note: We can request a spot instance while creating an EC2 instance or we can create a spot request separately in the "Spot Request" section.

1)

2)

Reserved Instances:

The reserved instances allow us to reserve EC2 instances ahead of time, below are the different types of reserved instances.

Types:

  • Standard (General)

  • Convertible (Can change instance family, type, tenancy model)

  • Scheduled (Scheduled for a specific block of time)

For the above-mentioned types, there are three different payment models:

  • No Upfront: $0 upfront, Pay monthly installments.

  • Partial Upfront: $X upfront, Rest can be paid in monthly installments.

  • All Upfront: Full amount upfront, no monthly installments.

1) Standard Reserved Instance:

In this type, we commit "In a region, I want to reserve EC2 instance with the specific platform (ex- Linux), a specific instance type (t2 micro) for a term of 1 year or 3 years".

In the standard reserved instance type, we can switch between instance sizes of the same type which we committed earlier i.e from t2 micro we can switch to t2 small. we can also switch to another AZ.

Note: In the case of standard reserved instance type, we can not change the instance families, operating system and tenancies.

2) Convertible Reserved Instance:

In this type, we solve the above issue that is we can switch between different instance families, types, operating systems, AZ and tenancies.

Here we just commit that "In a region, I want to reserve an EC2 instance for a term of 1 year or 3 years".

3) Scheduled Reserved Instance:

In this type, we commit "In a region, I want to reserve an EC2 instance part-time for a year - X hours every month/week/day at a specific time ZZ: ZZ"

There are few restrictions working with scheduled reserved instances, that is they are available for very few instance types (ex- c3, c4, m4, r3) in a few regions (ex-US East, US West, Europe)

One of the use cases can be, we have a batch program to generate bills on the very first day of every month, then a batch program runs for a few hours every day.

Note: We can sell the reserved instances on the AWS reserved instance marketplace if we don't want to use our reservations.

Savings Plan Instance:

1) Compute saving plan:

Here we commit "I would spend $X per hour on AWS compute resources (AWS EC2, AWS Fargate, AWS Lambdas for a 1 or 3-year period)".

It provides complete flexibility i.e we can change instance families, size, OS, tenancies and AWS region, then we can switch between Amazon resources i.e EC2,

2) Instance saving plan:

Here we commit "I would spend $X per hour on AWS EC2 instances of specific instance family within a specific region".

EC2 Pricing Model's Summary:

1) On-Demand Instance:

  • Request when we want it.

  • flexible & most expensive.

2) Spot Instance:

  • Will quote a max price.

  • Cheapest (upto 90% off), but no guarantee that an instance will be provisioned.

3) Reserved Instance:

  • Reserved ahead of time

  • Upto 75% off, 1 or 3 years reservation.

4) Saving Plans Instance:

  • New version of reserved instances

  • Commit spending $X per hour on (EC2, AWS Fargate, AWS Lambda)

  • Upto 66% off, 1 or 3 years reservation.