Managing AWS discounts like a ninja!
Last week I talked about how to build a commitment portfolio that helps you achieve big savings while maintaining the flexibility to optimize your workloads. We also talked about the tradeoffs you must make when building out your portfolio. Well, today I want to introduce you to a better portfolio and an accelerator to get top-tier savings right now, not in 3 years.
The (new) Ideal Commitment Portfolio
Let’s start with the familiar graph from last week showing how our ideal portfolio’s commitment reduces over time.
We like this profile because it gives us the flexibility to reduce our total utilization by 1/36th or about 3% each month. Still, it leaves us with a 3-year total commitment of 1.5X our current annual run rate (even higher for Windows workloads).
What if we could make our graph look like this?
Yes, you are reading that correctly. For month 2 we are committed to only 1.3% of our $1M spend. If we only have a $100k/year ARR, our month 2 commit is only 13.2%.
The Magic
For years I totally missed a gem of the commitment world – the convertible reserved instance (CRI). I figured convertible reserved instances were for organizations who were willing to take lower savings in exchange for more flexibility, and once savings plans came along, it made even less sense to get a CRI. However, recently I had a partner that pointed out some unique intricacies of CRIs. Three key statements from the documentation on exchanging CRIs transform them from a tradeoff to the only logical choice:
- You can exchange one or more Convertible Reserved Instances at a time for one Convertible Reserved Instance only.
- If you merge multiple Convertible Reserved Instances with different term lengths, the new Convertible Reserved Instance has a 3-year term.
- If you exchange multiple Convertible Reserved Instances that have different expiration dates, the expiration date for the new Convertible Reserved Instance is the date that’s furthest in the future.
When we put these three concepts together, we get an engine that can effectively extend a 3-yr RI discount perpetually.
Picture this. You have a 3-yr all-upfront CRI that expires at the end of the month. Because you have the new ideal portfolio, you also have a 1-year no-upfront t4g.nano that expires at the end of next month. If you exchange both of these Ris for a new RI (principal 1), the new RI will have the term and discount of your 3-yr all-upfront RI (principal 2) and an expiration date of next month (principal 3). I can pick any instance family or size I want, so long as the total hourly commitment remains the same, or higher. Shazam! You just extended your 3-yr discount one more month!
Now if you had the ideal portfolio, you would also have a new t4g.nano 1yr CRI expiring every month for the next 12 months. And each month you would buy a new one to prepare for next year. Now, every month, you can rebalance your RI commitment to match your anticipated run-rate!
By now you’re asking yourself, “What if I am doing a major optimization and need to decrease my commitment next month by 20%? If I exchange my current RI plus my monthly RI, won’t I need to keep the same commitment level?”
Well, I’m glad you asked. Enter principal 4. You can also SPLIT you RIs into multiple smaller Ris in the same family. And since each of those can expire or be exchanged, you have massive flexibility.
So, let’s say you have a 3yr all-upfront m7i.32xlarge instance that’s covering your workload at 95%. Now you want to drop your total commitment by 20%. First, you’ll need to split your m7i.32xlarge into 64 m7i.large instances. You’re going to let 15 of those expire. You’ll take the last one and merge it with your 1yr no-upfront reservation that expires next month and make a series of exchanges and splits to ultimately get 1 m7i.24xlarge, 1 m7i.xlarge and 1 m7i.large, effectively reducing your commitment by ~20% while keeping the 3yr all-upfront rate on all of these.
So, there you have it. Your ideal portfolio has a 3-yr all-upfront reservation for this month’s usage and 11 1-yr no-upfront t4g.nano reservations. Of course, it’s not quite that simple as you need to convert reservations into the various instance families you are already using and duplicate this strategy in each region, but the concept remains the same. Everything can be converted down to the smallest increments and then exchanged for appropriately sized instances of each family.