Scaling up AWS Reserved Instances (EC2, Elasticache, Aurora)

608 Views Asked by At

REQUIREMENTS: I have 1 m5.xlarge EC2 instance. Time to time I scale up to m5.2xlarge over a short period of time, then I scale down to m5.xlarge. I do not scale horizontally so cannot go with more than 1 instance.
Within 6 months I might increase a lot my traffic so I might have to move to m5.2xlarge as a basis, and probably scale up time to time to m5.4xlarge.
I also have 1 cache.r5.large (Redis Elasticache) and 1 db.r5.large (aurora), with the same constraints as above.

QUESTIONS: Let's start with EC2 instances.
I want to save cost, and evaluating Standard RI, including the possibility to:

  1. scale up/down time to time m5.xlarge/m5.2xlarge and
  2. potentially move to m5.2xlarge as a basis

Let's say I reserve 1 m5.xlarge. Regarding

  1. I can scale up temporarily to m5.2xlarge. I will have the saving applied to 50%. the other 50% I will pay on-demand cost. makes sense. Regarding
  2. I would need to modify my RI reservation to m5.2xlarge but I guess I can't because I read: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-modifying.html#ri-modification-instancemove

The original and new Reserved Instance must have the same instance size footprint.

m5.2xlarge and m5.xlarge have a different footprint, so I can't do that.
There is an alternative?
e.g. I might understand I need to buy another m5.xlarge, so I have 2 m5.xlarge, which will apply 100% for my m5.2xlarge?
The only potential issue is the expiration date, the 2 RIs will have 2 different expiration dates.
To solve this, I have the option to merge the 2 RIs right? so I will merge my 2 m5.xlarge RI to 1 m5.2xlarge (and the expiration date will be the longest one of course)?

Hopefully I did understand correctly. I want to double check with you before proceeding.

now regarding RDS: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithReservedDBInstances.html It seems the same for 1) and 2)

and regarding Elasticache, the doc is light: https://aws.amazon.com/elasticache/reserved-cache-nodes/ I understand 1) is the same, but no idea about 2) as they do not mention scaling up a RI

1

There are 1 best solutions below

0
On

RI's add up a lot more planning and monitoring than we would have originally anticipated.

When planning for saving costs on EC2 I would recommend opting for "Savings Plan" rather than RI's. Savings plans are much more flexible than the RIs.

In the events where we have to buy the RIs always buy multiple smallest footprints of the family, we wish for. So when you are planning to scale always try and purchase the smallest unit (m5.large).

Now coming to the question of merging. If the modification request goes through then a longer time is considered. Following is a snippet from the AWS blog:

The original reservation is retired. Its end date is the start date of the new reservation, and the end date of the new reservation is the same as the end date of the original Reserved Instance. If you modify a three-year reservation that had 16 months left in its term, the resulting modified reservation is a 16-month reservation with the same end date as the original one.

Link here

And all your other understandings and assumptions are correct.