Decoding AWS Reserved Instances

You will always get an instance when you need it, and never get an error about not having enough instances of a certain type.

This is critical if you are using autoscaling, especially during an outage. If you are shifting your workload from one region to another at the same time as everyone else, if you have reservations and they don't, you'll get the instances before anyone else.

It breaks the whole "pay as you go" cloud model, but as long as you can find batch jobs to fill those reserved instances 1/3 of the time, you'll still come out ahead.

We had to buy the new reservations first and would then could cancel the old ones

I work for a company [0] that specialises in Cloud FinOps, and I helped write our in-house billing system, which has to deal with _all_ of the intricacies of Reserved Instances, so I know very well how deep this rabbit hole goes.

This article opens by categorising RIs as "one of the most complex but crucial AWS offerings", but I think it perhaps glosses over some of that complexity, which might cause people to get burnt. For example, it suggests that you can safely sell your way out of trouble on the RI Marketplace, but in many cases you can't: there are 5 products you can buy RIs for (EC2, RDS, ElastiCache, OpenSearch, and Redshift), but the RI Marketplace only lets you sell EC2 RIs, and only Standard EC2 RIs at that, not Convertible.

I don't want to take anything away from this article, nor do I want to frighten people away from buying RIs, but please take care. If you aren't sure, I encourage you to use one of the many companies operating in this space to help you out (and you certainly don't have to give away 20% of your savings to do that).

0: https://strategic-blue.com

I think it is going too far to say that RIs are a trap: the rules are pretty transparent. I agree with you that if your infra is elastic or evolving then you need to be very cautious about making large or long-term commitments.