12

We have deployed a web application on an m5.xlarge EC2 instance and when we try to buy an annual or 3 years reserved license, AWS recommends based on our current usage it is recommended to purchase 54 t2.nano instances instead of the m5.xlarge we have now. It calculates and shows a difference in the overall cost and shows that going with that option is more profitable to us.

The thing I can't understand is what does it mean to buy 54 t2.nano instead of one m5.xlarge? Does it mean we need to host the application in all 54 nano EC2 servers and then put it through an ELB? I am a bit confused here about what to do

  • 1
    Can you share a screenshot of the recommendation? Normally it will recommend enough of the smallest size in an instance family to cover being amalgamated into whatever you are running. So 54 t2.nanos may be to cover a t2.xlarge (32 nanos), a t2.large (16 nanos) and 3 t2.micros (2 nanos each so 6 nanos) or some other combination. It shouldn't be recommending t2.nano reserved instances for m5 instance types because they can't be used that way. – ydaetskcoR Nov 16 '20 at 09:35
  • 1
    Recommendations don't mean you *need* anything. Remember that automatic recommendations aren't always accurate... – user253751 Nov 16 '20 at 19:23

2 Answers2

21

There's a couple of things to understand:

  1. Reserved Instances are just a billing construct. AWS will try to match the purchased reserved instances against your running instances at the billing time. I.e. you don’t assign RIs to your actual EC2 instances, you get the discount automatically.

  2. Reserved Instances capacity doesn’t have to match the running instances. The price for t2.medium is the same as for 2x t2.small or 8x t2.nano. So if you purchase 32x t2.nano it would fully cover the price of 1x t2.xlarge. From the billing perspective it’s the same.

    On the other hand t2.anything won't be applied against m5.anything - they are a different instance class. You can buy 2x m5.large instead of 1x m5.xlarge reserved instance - same thing from a billing perspective.

  3. Now why does it recommend 54x t2.nano? Probably it found out that your actual needs are somewhere between t2.xlarge and t2.2xlarge - and it's best expressed as 54x t2.nano.

    Depending on your application you may or may not be able to spread the load over a number of smaller instances. I wouldn't go to 54x t2.nano but perhaps 3x t2.large could be a good option? You can then set up auto-scaling to remove some of the nodes during quiet times and save. And even use Spot Instances and save even more. However for both ASG and Spot you'll need some automation in place.

  4. For a much greater flexibility look at AWS Saving Plans - with that you'll be able to migrate your application to newer instance types, mix and match instance types, etc. With Reserved Instances you're locked to a particular instance class in a particular region. With Saving Plans you only commit to a certain spend per month and it's up to you how you use it.

Hope that helps :)

MLu
  • 23,798
  • 5
  • 54
  • 81
  • 1
    I think this is much closer to being the correct answer than the above one (that currently has more votes) but I've never seen it recommend buying reserved instances in another family type, particularly not a previous generation. It suggests to me that the OP is receiving a recommendation to buy reserved instances for other t2 instances that sum to 54 nanos and this is unrelated to the m5 instance. I've asked the OP to share a screenshot of the recommendation to check this. – ydaetskcoR Nov 16 '20 at 09:37
  • The other comment to make is that there is no reason to buy t2 nowadays other than free tier, as t3, t3a are all cheaper and faster and same generation as m5. Other than that, Savings Plans are probably a much better way to go. – jdog Nov 17 '20 at 03:18
7

The general idea behind this is instead of provisioning one large server for peak load, you have a larger number of smaller servers that scale up and down automatically to meet load. You put your servers behind an application load balancer. This also gives you redundancy, in case something goes wrong with one server.

54 t2.nano is an odd recommendation. Maybe it's optimal but it's not intuitive. It also means each server has very little RAM, which might not work for the application. t instances can also run out of CPU credits, so I wouldn't use them behind a load balancer. If you turn on the option on T instance to buy extra credits it costs more than using a non-T instance.

The m5.xlarge isn't a particularly large server, so it's more difficult to split it up. I would stay with m series, the smaller is m5.large so you would probably scale between 1 and 3 of them.

If it's a fairly steady state application and the cost isn't a problem the easiest option is to stay with your m5.xlarge.

Tim
  • 30,383
  • 6
  • 47
  • 77
  • 1
    Good point - the sum of a lot of little instances isn't the same as a single larger instance. OP needs to figure out their application's memory/cpu minimums, which will indicate a minimum instance size. – Criggie Nov 16 '20 at 06:23