E09: Finding Cost-Efficiency in Instance Size Flexibility

What's up everybody? This is Nick from tenacity.ai with my cohost Jason, and you're listening to the Cloud Cost optimization podcast. Today we're gonna talk about reserved instances, standard reserved instances in aws, and some of the nuances in making decisions there. Some of the things I think can kind of be intimidating.

So, let's start the topic with, I guess first, Jason. Why don't we could you define kind of the, the discount programs that are available through aws, Sort of the four options that, that are there and sort of, frame them in for the audience? Yeah, so we have, you know, standard reserved instances.

Reserved instances in general have two different types, standard and convertible. Convertible reserved instances essentially just allow you to, you know, change different. Ability to exchange those particular reserved instances for other types of reserved instances, whereas standard reserved instances, you ba you, you can only either sell them or keep them throughout the period of the term.

And then you have savings plans. Savings plans, either, either compute based savings plans or e c two based savings plans only. The only difference really at a high level being that compute savings plans includes compute used by Lambda and some containerized based solutions, and then that, that makes up a majority of, of where you can save, save money.

There are also some ancillary services within AWS that offer. Reserved instances as well as maybe savings plans. I think there's a SageMaker savings plan, and then there's a handful of services like Open Search, rds. Alaska Cash and a couple others that offer reserved based instances, but those are all kind of separate one to one sort of things.

They're very, they're much easier to, to understand than the E two or compute based in general plans. Yeah. And, and so I, I think that was, I think that's kind of frames in the world. There's of course, other discount programs that AWS offers or other credit based programs that AWS offers. But when you think about committed commitment based discounts, which is really where we're focused on, and that's a place where you can really do a lot of opt optimization.

You, you, I, I think. It's a little bit confusing, at least when, when we've been out in the world, both ourselves from kind of, acquisition and learning, learning about it, but also when we're, you know, into environments where you know, we, we've, we've gotten to do it. You know, we've, we've gotten to understand this hundreds of times over and over and over, but folks who are in their own enterprise, you know, managing their AWS environ, Haven't had the number of repetitions to sort of uncover some of the gotchas and to get over some of the sort of, you know, decisions that you end up having to make that you're kind of blind to some of the impacts.

And so I think that creates some confusion and creates a phenomenon that we, that, that we see where a lot of times folks select a really easy, kinda low risk plan, implement it and just. You know, year after year, not really getting the benefit of, of the deepest discounts they could or, or taking advantage of, of how some of these plans work.

And specifically what I'm talking about is, is where we've run into issues in standard reserved instances where there's some confusion around instance size flexibility. Some people know that it exists, other. Don't know that it exists. And that I think, you know, that I think is a source of almost, I don't know what you would call it, maybe indecision or uncertainty that, that causes people to move towards savings plans, which isn't necessarily a bad thing.

I mean, at the at, at the end of the day, saving money is, is always good. But if you're. If you go by the suggestions being made by the providers, you're most likely saving the amount of money that they want you to save and not the amount that you can actually save. And that's because one, it's, it's really confusing.

the whole, all of, you know, all of them in general, Why should I have this one versus this one? Which workload should I have? This one, when you start to look at the decision tree for just whether you should use. Reserved instances versus savings plans. I mean, there's a handful of decisions that make it really easy.

Like if you're only using Lambda and Fargate, right, then I should be on a compute savings plan. Very easy. But 65 or 70% of AWS's revenue comes from EC two, so that's where you can save a majority of your money. And you know, once you get into trying to figure out. What's best for these types of workloads and ones that work on these days.

Just a litany of different decisions that you have to make. And so savings plans, when they came in, they were pretty successful because it made it, you, you commit based on spend. You don't have to worry about usage. There. There's, there's just less decisions that you need to make, but you're gonna, you're, you're.

Bang for your buck is to one, have a strategy for both, right? Depending on the workloads that you have commit and usage based spend. And there's so much context that's missing from the recommendations that the providers give you, right? I mean, they don't, they, they only give you simple calculations and look back periods to say, Okay, you know, and, and things.

If I had , you know, like if I do the look back period at 60 days versus seven days, and let's say I shut down half of my EC two instances 30 days ago, it's still gonna recommend a bunch of compute from 60 days ago that I no longer have. It just, it, it, but, but again, that's not the tool. It's, it's, it's meant to give you an estimation and it's meant to give you basically the, the lowest risk recommendations.

That AWS will give you and you can just achieve far greater savings by one, adding context to an algorithm. But two, just you know, using, recognizing that it takes far, much, too much time to gain this expertise when you, when your time at your organization is far better spent servicing your customer, getting a company to help you with it.

Yeah, I think you hit on a good point there. The recommendation is that the. The providers make, or specifically the AWS makes? We had, we had a recent in a recent issue with this where AWS was making a recommendation on the 60 day look back period that would have caused someone who followed that recommendation to have bought or to have acquired a bunch of standard reserved instances.

For which they would have no use whatsoever, and it would've ended up costing them more. Yeah, it would've ended up costing them more at a run rate level than what they were currently spending on their on-demand charges. And so you have to be careful in looking at AWS's recommendations over a longer look back period because the algorithm there, that's, that's helping make those recommendations does not wait.

What you're currently using at a much higher weight or, you know, at a much higher relevance than what was happening 60 days ago. And that's really how, that's really how a recommendation algorithm needs to work. That's, in fact, how the tenacity algorithm works is it's, it looks contextually at what you're doing right now versus a look back to try and understand variance and.

Inform you about potential risk so that if you're most recently using a bunch of stuff that you weren't using 60 days ago, it's, it's gonna, it's gonna tell you about that. So, that, that's one, that's one of the issues there. I think the other issue that gets people is this instant size flexibility. You know, you, you can buy standard reserved instances and, and plans and use them within the same family for different sizes.

So, for instance, I could go buy t2 medium. A reserved distance plan and I could actually stop running my T2 medium. E C two instance and start running two e c two T2 Smalls, and that plan would cover them. And there, you know, the, the, the, this is, I think, confusing to folks that there is this normalization factor that's hidden.

You, you can go find it in the. AWS knowledge base, but, but it's not evident inside of buying a plan or really understanding a plan, but there is this normalization that allows you to be flexible in using standard reserved instances. However, there's a catch. It only works for you know, Linux, Unix based.

EC two instances and there's even some exclusions there. Doesn't work for Windows, doesn't work for Red Hat Enterprise doesn't work for Susi Enterprise. And so, and, and, and there's a number of other exclusions. I haven't given the whole list of exclusions, but broadly or generally people get hung up here where they may be running workloads.

That don't meet the conditions for instant size flexibility and then mess up and, and, you know, purchase the wrong reserve things. Committed, committed to the wrong thing. I mean, if you wanna maximize savings this, it's almost impossible with just the recommendations that they give you. And the other thing I, and I say this a lot to, you know, different people, is that why, why would you wanna trust the entity charging.

To tell you how much you can save on how much revenue they're generating from you. Just to me it doesn't make much sense. I mean, I, it's great that they do it and they do allow you to save a little bit of money. That's great. They've got no problems with the plans themselves, but you know, they're gonna make the recommendations that are win, that are, you know, more favored in their side of the win, right?

Because it's, they have stock shareholders, they have demands to meet, right? And so, they need to give you enough to keep you. But you can say far. By doing some of the things we just said. Yeah, definitely. Agreed. You know, I, I, I think that probably covers off on the topic we wanna touch on here, which is really, you know, I'm trying to understand the recommendations around aws.

We'll, we'll talk more on this topic and how you actually get to a recommendation, how you can get to a human contextual rep recommendation. And, and you know, there are a lot of tools out there that help you make decisions automatically allow you to put it on autopilot. And, and those can get you some really good benefits in that they can, you know, buy and sell and convert these plans very quickly.

But there's also, it misses a human contextual element that You know, you, you can make some risk based decisions that allow you to get some of the deepest discounts available on, you know, areas in your environment you feel are actually pretty safe to go make those, make those purchases. And, and what plays into that is this instant size flexibility.

Because if you know you're gonna be in the T two family or the T three A family, M five family for a long period of time due to the workloads you're running. You can actually optimize and maximize some savings, even though you know that, that that family may change over time. It's probably not gonna change in the time span, or at least the changes won't be relevant from a cost perspective in the timeframe in which you can gain that advantage.

So, you know, it's, it is worth, it's worth actually thinking about and understanding that instant size flexibility and the impact on those recommendations. Any parting foster, Jason? All right. Well, that's it for today, folks. Thanks for tuning in. See you next time.