Learn how to save the most from AWS Reserved Instances and Savings Plans with Yotascale experts.
In this webinar, we cover:
Length: 58 minutes
Learn how to save the most from AWS Reserved Instances and Savings Plans with Yotascale experts.
In this webinar, we cover:
Length: 58 minutes
Susan Brandes
OK, great. All right. Hi, everybody. Welcome. Thank you for joining us today. We’re going to talk about reserved instances and savings plans. Very exciting, exciting stuff. Our main speaker today is Jeff Harris. He’s our head of customer success at Yotascale. I also have a Anu Gardiner. She’s our head of sales. I have Pedro, Leonardo. He is our director of product management. We’re all here to help answer any questions that you have as Jeff goes through his presentation. As I said, there’s a lot to cover. So feel free to chime in or use the chat to ask questions. And with that, I will let Jeff take it away.
Jeff Harris
Awesome. Thank you, Susan. As Susan mentioned, my name is Jeff Harris, I’m director of customer success here at Yotascale. I’ve been with Yotascale for now in my 6th year. So prior to Yotascale and helping with the cost management problem in cloud, I was working at Google as part of the Google Cloud team helping to bring customers on digital cloud. A lot of times we were working with AWS customers. This was again six years ago and trying to understand sort of what challenges they were having, and often we were told that we don’t understand our billing. So when Asim our CEO approached me and asked if I wanted to join the company, I had a good understanding of the problem and saw that there was an opportunity here. Since then, I’ve been here at Yotascale, working with the team to try to help build a product that can help solve some of the cost management challenges.
Jeff Harris
Reserved instances and savings plans being one of them, and as we try to understand what we are going to talk about today, we will discuss how to save money on your AWS costs. This particular discussion is going to focus on reservations and savings plans. We will go through an introduction to those, try to understand the differences, and where they should be used. Then we’ll get into how to get started and how to start using reserved instances and savings plans in your infrastructure today. How to manage that commitment life cycle. Time permitting, we’ll also have a quick case study on one of our customers who went through a purchasing planning decision-making process, what they implemented, and what benefits they saw from the choices they made. We’ll save some time for Q&A at the end and go from there.
Jeff Harris
So starting from this, what are the options that I have? What are the levers that I have to be able to save money on AWS, assuming that you are going to run the infrastructure, you have a product that you’ve built, you’ve got some sort of services you’ve built. How can you save money on AWS? What we’re going to be talking about today is commitment: how do you make commitments to cloud providers, specifically AWS, to be able to get a discount on the same workloads that you’d be running if you didn’t make a commitment? Today, we’re not going to get into too much optimization. We’ll mention it and sort of how it fits in with the commitment side of things. There’s also a third way here too that we’re not going to get into today, but negotiation. This is coming from purchasing power and being a large customer, being able to get enterprise discounts. These are very much custom. So we’re going to stay away from those two mostly today and focus here just on commitments on AWS.
Jeff Harris
The key thing is that if you don’t take anything else away from this today, it’s that you’re trading off between flexibility and cost. If you run everything on demand, we can see here on our sort of a fun chart. I wouldn’t take this to be exactly correct, but I think this can help you understand the differences between these things and what you get for making these commitments. When we’re talking about flexibility, it’s really flexibility for you and your engineers to choose what resources they use and when. On-demand being the ultimate level of flexibility: you put it out there whenever you want, whatever you want, you pay the on-demand price for it. The next step down being, how do I get some savings? If you just commit to the compute savings plans that are out there today, we’ll talk more about what these are. This is going to get you some really good savings and still have a lot of flexibility. In this chart here, we’re really focusing on EC2 and compute. We’ll get into some of the other services as well when we talk about reserved instances, but trying to compare these right on a single service so that we can understand how Amazon views these and what they use them for. We’ll get into sort of the convertible reserved instances, but just understand that savings plans are going to help you get an immediate discount and still have some flexibility with compute.
As we get more specific about what resources we want to use, we’ll get into how we do that and what options there are. Then we end up losing flexibility, committing to a specific instance type and getting bigger discounts because of that. So I give up my flexibility, I get better pricing, but to give up that flexibility, I have to have confidence that those resources will be used for some time. The other one I’ll mention quickly is spot instances. These relate similarly in that there’s a different pricing mechanism for it. The spot market fluctuates and changes, and what you’re really doing with spot is purchasing unused capacity within Amazon’s data centers. They sell it at a huge discount to try to get people to fill that in so they can recoup some of the money from running that infrastructure anyway. The challenge with spot and the reason why I’m saying it’s less flexible is because you don’t have a choice of what’s available on the spot market. That’s really dependent on what people are using from an on-demand perspective, what reservations other companies have made because those get priority over any spot instances. Spot is also ephemeral, so you have to design your workload to work with spot where EC2 reserved instances and savings plans allow you to continue to use EC2 and compute in the way you are.
High-level recommendation for spot: look at development workloads to see if you can run them there. Things that aren’t production and that’s generally a good place to start. Companies do run production workloads on spot as well. The key takeaway here is flexibility is not free and that’s really what you’re trading off: flexibility for better cost savings.
Jeff Harris
Now let’s get into more of the details around these things. What are reserved instances? Reserved instances have been around for quite a while, probably a decade if not more. They were introduced as a way to discount pricing when customers of AWS commit to specific instance types and families. Your options for these commitments are from one year or three years. There are multiple purchasing and payment options, so you can choose to do a capital investment and pay for the three-year commitment upfront to get a bigger discount, or you can do it on-demand and reduce your capital investment, keeping it as an OpEx and paying monthly over the period of time that you’ve committed. You can also sell reservations in a marketplace, which is a key difference between reservations and savings plans. Note that AWS takes a cut of this, it’s not a very liquid market, but it is an option. Reserved instances are available for multiple services, so when we talk about savings plans, they are really focused on compute, but with reserved instances, there is EC2, RDS, Redshift, Elastic Cache, and multiple services that AWS offers that are resource-based, allowing you to commit to those services and get discounts.
When we look at EC2, Amazon recommends moving away from reserved instances and moving to savings plans. We believe the general trend is that at some point in the future, they’ll deprecate reserved instances and savings plans will take their place. They haven’t set a date yet, but their recommendation today is to look at savings plans first. Discounts are very similar and focus on using savings plans because they offer more flexibility.
Jeff Harris
So we get into this: how do we purchase reservations as we start to plan? What are the options we have when I look at the recommendations in AWS or in a product like Yotascale? What are we actually recommending you to purchase these for? There are a set of attributes that AWS looks for that you need to commit to, and some of those are going to be your instance type. The instance types are not going to get into too much detail about this today. If you’re not familiar with the different instance types, one example would be like an M4.2Xlarge or C5.8Xlarge. There are a couple of different pieces here. The first part of this being the family. That M4 portion is the family and the generation, so M is the family, and 4 is the generation. Then there’s a size within the family that scales linearly, and we’ll see what that looks like, but that’s where this concept of instance size flexibility comes in.
The other options that you have available are what platform are you using with EC2 instances specifically? You’re looking at Linux and Windows as the different operating systems that you can have. With Linux, you get some additional benefits if you’re going with Linux reserved instances versus Windows reserved instances; there’s more flexibility on the Linux side. There’s also an option for tenancy. Most people aren’t selecting dedicated. Most people are doing the default tenancy. Dedicated is a very specific use case. If you think you need a dedicated server at all times, then you can select dedicated, and that will ensure that if inventory ran out, you have a reservation still; you still have an instance that’s being held for you that you’re paying for. There’s a cost to that as well, but in disaster recovery situations, this can be a good option to look at dedicated.
AZ and regional: these are also optional settings within these attributes. When you purchase this, you’re basically saying I’m going to buy an M4.2Xlarge, Linux, default tenancy, in a specific availability zone or region. Again, there’s a cost to the flexibility. If you select a region, there’s a higher cost to that. With availability zone selection, you get a bigger discount because, again, you’re committing and giving AWS more information about how much capacity they need to plan for and in which regions, availability zones, and operating systems. AWS will give you a discount for that information and for that commitment.
Jeff Harris
When we talk about instance size flexibility, I’m just going to touch on this briefly because there is some additional flexibility offered if you are selecting region-scoped reserved instances. That’s looking at this option here: default tenancy and using Linux OS, any instance type that you select, any instance family, actually, that you select will then have that reservation applied in a linear scale. So what does that mean exactly? If I buy an 8X large instance or reservation, AWS can actually split that up and apply half of it to a 4X large, a quarter of it to a 2X large, etc. So whatever size you end up using, this will still apply within the family that you select.
If I buy M5 reservations, I would be able to take whatever size I bought them in, have it split up, or I can buy multiple extra-larges, and those can be used together on an 8X large to pay for it proportionally. Why does this matter? Well, from a mathematical standpoint, it matters because typically, you want to buy the smallest units available to fit the problem that you have. This is going to squeeze out just a little bit of extra savings. In a product like Yotascale, we will recommend if you’re purchasing for the M5 family to purchase them all in the large size, and that allows you to fit the number of reservations you need more specifically to your actual usage. Just something to keep in mind. This doesn’t matter with savings plans; we’ll talk about why that is in a minute.
But this instance size flexibility applies to reservations because of the way that they’re purchased, and reservations are purchased at a resource level. Savings plans, which we’ll get into in a minute, are based on a dollar commitment instead.
Jeff Harris
So we’ve determined what the attributes are that we would look at to make a purchase. Those are those four attributes we just went over.
The next set of options for you to decide on is how do we want to pay for this? The payment options being, I can pay for a one-year or three-year commitment. You’re going to get a bigger discount with the three-year commitment than you do with the one-year commitment. There’s also when do you pay? Do I pay now or do I pay later? Or do I want to do a hybrid? That’s where we get no upfront, being all OpEx, no CapEx here, right? So I will pay the amount that I’m committing monthly going forward. Partial upfront is about a 50% commitment, and then you do 50% of the OpEx, so it’s sort of a split between CapEx and OpEx. With all upfront, you’re paying for the entire commitment, the one-year or three-year commitment, upfront. Again, you get a bigger discount when you do this; however, it does require a capital investment.
So those are a few of the different options you have there. Then we can also look at the concept within reserved instances of standard versus convertible. If we recall that flexibility chart we looked at earlier, with convertible reserved instances, you are getting some flexibility, but it puts the work on you. You have to monitor and manage your convertible reserved instance fleet manually. There are some products out there that can help with that, and there are also APIs available for you to write your own scripts to manage this. One of the challenges with this is you still have to make those commitments upfront, and then you have to have that monitoring process in place. Otherwise, you can end up in a situation where you are wasting. So one, you’re already purchasing convertible reserved instances, which get you less of a discount than standard reserved instances, and then two, you have to monitor and manage those so that you don’t end up with wastage as well. Again, standard reserved instances get you a bigger discount than the convertible ones. Also very important to keep in mind.
Other options that exist out there for reserved instances include a capacity reservation option. Again, that’s to say I want to hold that spot no matter what, and you’re going to pay extra for that capacity reservation. Volume discounts are available as well, so if you’re making a very large purchase, go through your AWS rep; they’ll help you navigate this. There are certain dollar values that offer a volume discount, and if you get into the millions of dollars of spend. There is one other niche use case. I actually have not seen this used across any of our customers, but it does exist: scheduled reserved instances. Scheduled reserved instances allow you to purchase reservations for a 12-hour period, and I believe the way they do it is either morning or evening. So that could be another option out there for some scheduled workloads.
I do see some things in the chat. Do we have any questions come in Susan?
Susan Brandes
Yeah, we have a couple.
Jeff Harris
OK, I can take a pause here if we want to talk about this in the reserved instances section.
Susan Brandes
Yeah, you might be addressing this later, but one question came in on how negotiation works. Is it based on overall billing?
Jeff Harris
Yeah, yeah. So I can touch on it very quickly. It’s really going to be working with your AWS rep, and it is based on overall billing. Generally, what we see is each customer has specific needs in specific areas. So if you’re running a storage-heavy operation and you’re frustrated with how expensive S3 is or how much it’s costing you to transfer data, those are conversations you need to have with your AWS rep to see if there’s any flexibility AWS can provide because you’re using AWS in a very specific way. Those are agreements that you’ll enter into with AWS, and they’re all custom. Generally, we see that happening when you’re spending millions of dollars a year on AWS. Otherwise, AWS isn’t really incentivized to have those types of conversations, and that’s why reservations and savings plans exist to offer some sort of discount vehicle for companies that don’t have the negotiating power to have those types of conversations. You can get some discount by making some commitment to AWS.
Any other questions here today, Susan?
Susan Brandes
I knew you had a question. Is there a separate section in billing that reports on RI commitments?
Jeff Harris
Yeah. So there’s both within the AWS console. There’s some utilization information, both wastage and coverage, that you can find. And then also in products like Yotascale, we monitor your usage and identify where waste is and help you identify also where the opportunity to invest in reserved instances could be as well.
Susan Brandes
Yeah.
Jeff Harris
OK, great. This is the brief section here on reservations. Let’s jump over to…
Anu Gardiner
Jeff, just to interrupt, I think there’s a comment from Ray saying he believes that scheduled reserved instances are retired.
Jeff Harris
That may be true. Yeah. That… yeah, I didn’t check that before I did the presentation today, so they may have retired. That’s probably true…
Anu Gardiner
Yeah. Thank you, Ray.
Jeff Harris
Thanks Ray.
Jeff Harris
With savings plans, these are going to be discounted pricing similar to reservations. You still have to make a commitment, and you’re still looking at that one or three-year option for that commitment. The difference here is that you’re offering a dollars-per-hour commitment as opposed to a resources-per-hour commitment. Reservations were done at a resource per hour, and savings plans are done at dollars per hour. Now, this is interesting because it opens up a couple of different options that we’ll see are also different about savings plans.
Now, you can apply some of this to serverless workloads, where with reservations you couldn’t do that because it was tied to a specific resource for a specific period of time or to a resource type for a specific period of time. With savings plans, you’re just choosing a dollar commitment, so this allows you to make a commitment for compute workloads like Lambda. Fargate. Savings plans are also available for SageMaker. So we don’t know what AWS is going to do, but it does look like this method going forward will be dollar-per-hour commitments, which will allow some of these discounts to be applied to some of AWS’s managed services. For now, it’s really focused on compute workloads. And same as reserved instances, when these expire, you’re running on-demand. Anything that’s not covered by these runs on-demand or not covered by these or reserved instances will be running on-demand.
Susan Brandes
Hey Jeff, I had a question. Do they notify you when things expire, or are you just supposed to stay on top of these things?
Jeff Harris
You know, I’m not sure that AWS does at this point. That’s where something like Yotascale could come in use, right? We can alert you when your costs are going to change and when your costs do change. We can also identify once they’ve expired, what should you purchase to replace them.
Susan Brandes
Okay.
Jeff Harris
Yeah. So, great question. Yeah. And we’ll get into that actually very shortly in terms of how do we combine savings plans and reserved instances. So I’ll answer that in just a moment.
Jeff Harris
But, savings plan purchasing options, this is going to be very similar. So one-year, three-year commitments, no upfront, partial upfront, all upfront—same things. AWS says that savings plans, if you look at them, there’s two different types of savings plans when we’re talking about compute. We’ve got the compute savings plans, which is a very generic option. This is the one that gives you the most flexibility, almost as much flexibility as on-demand. You’re still committed, so not quite as flexible. You can’t turn it off if you decide you’re not going to use it. But in these cases, you can use any EC2 instance type, any region, any family, any OS. All of that is—you just choose, and whatever dollar amount that you’ve committed, they will apply it to those resources that you’re using. You don’t have to manage it anymore, and that’s one of the big benefits of savings plans. That’s why AWS is also encouraging people to move from reserved instances to savings plans.
The EC2 instance savings plans are going to be more similar to reservations. However, they will apply across regions, which is different than what we had with EC2 instance savings plans. We had to select a region as an attribute when purchasing instant savings plans. At minimum. You could also go more specific and choose an availability zone. But with EC2 instance savings plans, you don’t get locked into a specific region, so it applies across your workloads, again providing more flexibility if you need to move regions or you start spinning up workloads in a different region. Those will be covered already if you have the savings plans available.
Other options: there are SageMaker savings plans as well. If you’re using SageMaker, obviously, this would be a great option if you have a consistent amount of cost on it. There are capacity reservations on reserved instances—that’s something to be aware of. There are no capacity reservations with savings plans, so you can purchase reserved instances to cover anything that you need capacity reserved for. Let’s say an availability zone drops out in a region that you’re operating in, and all of a sudden, all the other regions are now—or the other availability zones are now flooded with a capacity reservation. You can hold space. So for very, very important workloads, there could be a case made to say, “Hey, we’re going to purchase reserved instances in this specific region so that we make sure that we have capacity there in a disaster-type event.”
So, just a quick summary on some of the differences here. Reserved instances are a resource usage commitment, so you’re going to say how many specific instances you’re going to be using. If we’re talking about M54X larges, I might buy 10 reserved instances, and I’m going to have those 10 resources running 24/7 or pay for them to be running 24/7 for one year or a three-year period. You have less flexibility to change reserved instances. Caveat that with: you can exchange convertible reserved instances. It is a manual effort, and you have to monitor it and make those changes yourself. You can also sell reserved instances in the marketplace. This marketplace again is not very liquid, so it’s really hit or miss if you’re going to find somebody who’s looking in the marketplace to purchase the exact amount that you’re offering, and then AWS will also take a 12% cut on anything that you sell there. So you’re probably selling it at a discounted amount, and AWS is going to take a percentage. So it’s not a strategy that I recommend using unless you know you just end up in a situation where you have extra reserved instances and you never anticipated getting there. I wouldn’t overbuy and then plan to recoup that loss in the marketplace.
Reserved instances are also available for multiple services, so RDS, Redshift, EC2, and others, and that’s again a good reason to combine reserved instances and savings plans. You want to cover the use of the other services that you’re using, but savings plans won’t do that today. So in those cases especially, you definitely want to go with the reserved instances and get that discount.
With savings plans, you’re doing a dollar-per-hour commitment, so not a resource-per-hour, but a dollar-per-hour commitment. With savings plans, you have more flexibility to change things, and you don’t have to manage it. So as things change in your environment, you don’t have to be monitoring it to say, “Oh, we changed this instance type,” or “We’re now putting resources in another region, so we need to buy savings plans for that region.” So the management overhead is much lower. These are also only available for compute. Those specific services that are covered for savings plans are EC2, Fargate, and Lambda. SageMaker has its own set of savings plans, so you have to make a commitment specific to SageMaker. Fargate and Lambda are only covered by the compute savings plan options. Instance savings plans are really just for EC2 instances, and again, there you’re making those commitments to specific instance types similar to reservations. The difference with savings plans again being that I don’t have to specify what region I want to put them in.
All right, so when to use each, right? One of the questions we had was how do I combine them, or can I combine them? The answer is yes. AWS doesn’t mind. They automatically apply them. When we look at something like Yotascale, we make recommendations based on only your on-demand usage. So anything running on-demand, we’ll look at and then recommend what options are out there for covering that usage. On-demand being that whatever you want to run whenever you want to run it, you can turn it off, and you don’t have to pay for it later. So for spiky workloads, for dev workloads, on-demand can work well.
Reservations, reserved instances, this is sort of the legacy vehicle that Amazon has had out there, works great still today for other services. Amazon themselves recommend using savings plans over reservations. They state that savings plans and reservations will have similar discounts when you’re comparing the compute to convertible compute savings plan to convertible reserved instances and the instance savings plan to EC2 reserved instances. The pricing model should be similar in those areas, but you get greater flexibility with savings plans.
And then spot again, we’ll just touch on this one more time. This still works great for dev workloads. In fact, it works great for some production workloads, but you really have to engineer your infrastructure to work that way—to work in a way that allows for ephemeral instances, for resources to be pulled out from under you when there’s a spike in use in a particular region or availability zone. Spot can be really great for data processing that isn’t time-bound, that you don’t need done very quickly. Offload and batch workloads as the spot market becomes cheaper, but this does require a lot of management and investment into designing your system to work with spot.
The hybrid approach is definitely the best way to go, though. If you are able to actively manage it, you should be able to find a really good combination of these that will work for you, right? If you need to do some capacity reservation, reserved instances are still there. You can use those for that. Other services, reserved instances for sure. You should expect, unless you’re running just a very static set of workloads, you should expect to have some on-demand cost still. You don’t want to have 100% coverage if you have weekly spikes in your workload because you’ll be paying for those resources 24/7 for the period of time that you’re committing to them for.
So yeah, I highly recommend the hybrid approach. It can be complicated to get to a really good state, and so if you are just getting started, savings plans is a great place to start because you can cover some of that base compute cost that you have, get a 30-60% discount pretty quickly, and then you’re able to look at the rest of your costs and continue to manage that going forward.
Jeff Harris
Just a question here, does it depend on the volume of spikes? Absolutely.
So one other interesting thing to note that I’m not sure if this is well-known or not is how does AWS apply discounts? This is another piece of information that I think can be frustrating to people who purchase these discounts. AWS doesn’t care what you think you bought the reservation for. So what does that mean? If you have a team that knows they’re going to be using M54X larges for the next three years, they just know it. It’s the same instance type. There’s no reason it’s going to change. They’ve done the work to tell you and to do the capacity planning to say this is what we need for the next three years. If you buy the reservations or you buy the discount savings plans for that team, AWS has no way for you to tell them what you bought them for. So AWS will apply those discounts randomly. When you look at your bill, you may have 20% of that workload that you bought them for covered by savings plans, and then the rest was distributed to other resource types or resources and teams and applications. It is not an easy task to tease out that discount and reapply it to the other team. So just keep that in mind as you’re thinking about how do I show this back to the teams. It is a challenge.
The commitments are applied based on the class that you purchase. If you’re looking at reservations, they will only apply to M4X larges, but if you’re looking at compute savings plans, they’ll apply to any sort of instance type or any compute workload that’s out there. We talked about that instance size flexibility. So if you have an 8X large reservation and you’re only running larges, that 8X large can be broken up and then be applied to the larges as well. You can also only use part of it. So if you bought an 8X large and you were only running a 4X large in your environment, you have 50% of your savings plan or, sorry, your instance reserved instance wasted. So that’s something to note as well.
Yeah, it is definitely a problem that it’s not necessarily not knowing. And Anu asked, “Is this a problem people encounter not knowing where the discounts are applied?” It’s absolutely a problem. I mean, you see your total discount, so when you look at the organization level, you see the right amount that you got billed. The challenge is more in how do I distribute that discount to the team who told me that they were going to make the investment.
Anu Gardiner
Yeah. Thank you, Jeff. And I was wondering from our audience if this is a problem that people see, you know, with your clients or with your employer, is this an issue that you see?
Jeff Harris
Yeah. We’ll see if we get some answers there in the chat.
Anu Gardiner
I think everyone’s on mute. But yeah, go ahead and put it in. But we can continue, Jeff. Thank you.
Jeff Harris
Yeah. All right, so getting into some of the best practices and really what you’re trying, the goal of this, if you look at it as an optimization problem, is to minimize your on-demand and at the same time you’re maximizing the utilization of the discounts that you purchased.
So at a high level, what’s that sort of cycle look like? You can really start at any point in this circle. Well, you can’t really start manage if you don’t have them yet, but you can start at investing or you can start at right-sizing.
My recommendation is to kind of come into this from making an investment. That means that look at your total workload today, your on-demand, how much you’re spending on demand today. Find a way to commit, cover 20% of the base, 30% of the base, something, whatever your financial team is comfortable with to start getting a discount on that base workload immediately.
Once you’ve done that, you can start to continue through the cycle, managing what you’ve purchased, making sure that you’re getting the utilization out of it that you expected to, and right-sizing the instances as well. So there can be, for companies that are just coming into this, maybe you did a lift and shift into AWS.
A challenge is always, did we get the right instance size? We see consistently teams are oversizing the instances, and they’re doing that for a good purpose. They don’t want the workload to go down. So we’re going to buy something large that’s going to make sure we have the availability that we need, and we’re going to be able to process the data that we need to. But often people don’t come back to it to say, did we get the right instance size? Can we scale down that instance size, save some money if we’re only using 10% on average? We see about 10 to 20% utilization as a high mark for most workloads that our customers have. So there’s a huge amount of capacity that’s going unused.
Right-sizing before you invest in the reservations is also important, and that’s why I’m saying when you do that initial investment, start at 20-30% because you may find that you need to right-size and drop down. Let’s just say you drop it down 50%. You don’t want to now have to be holding a bag for three years of resources that you ended up not needing because you hadn’t right-sized, because you’re using instances that were too big. So right-sizing is a big part of this that falls into the optimization color from that first slide that we were looking at, right.
So we had discount commitments, we’ve got right-sizing or optimization, it’s part of right-sizing, and then there’s the negotiation. So those three.
After you’ve right-sized, you can invest. Now the cloud is dynamic, so you’re going to have new resources, new projects, new applications being spun up throughout the year. You need to keep an eye on how things are changing and fluctuating. Teams may be right-sizing without you knowing; they may be changing instance types without you knowing.
That, as the central team, right, so we want the teams to have that flexibility, and then on that central financial team, you’re the one who’s responsible for monitoring, helping lead some of that capacity planning effort to make sure that you’ve got a good understanding of the forecast and how costs are going to change over time. And then just make sure you’re rebalancing frequently if you’re using reserved instances, especially you want to rebalance frequently.
Savings plans help reduce some of that. Compute savings plans, especially. You don’t have to rebalance really at all, but with instance savings plans, you may still have to rebalance there and check and see. Are we using everything that we had or not?
This cycle also allows you to implement a more frequent purchasing methodology, and we’ll see why that’s also helpful. Checking in, especially for companies that are growing, it’s really important too. If you’re sort of at a plateau, when you’re flat for a little while, you know the rebalancing frequently is less important. But we see very often customers are in a dynamic situation. Often costs are increasing, and not just because it’s getting more expensive, but because you’re putting more workloads into the cloud. You’re bringing in more users, you’re driving more traffic and customers.
So this cycle is important, and having some sort of regular cadence, whether it’s monthly or quarterly, is really helpful to keeping this optimal.
We talked about right-sizing just real quick, so this is before you make a significant commitment. You want to make sure that you’re using the right instance types. Now the problem with right-sizing is it’s time-intensive and it’s resource-intensive from your engineers as well. They have to check and see. Can we run our, even though we say oh, you’re only using 20%, let’s move it to a smaller instance size. Can you actually run your workloads, your applications on that smaller instance size? So that is an engineering effort, and that takes the ability for you to make a quick discount. It takes it away from you, so that’s where making commitments at some level, some small level even before you right-size can be helpful.
Just have to have a good idea of how much opportunity to right-size is available, and that’s where a product like Yotascale can also help is identifying where those right-sizing opportunities that you may want to take before you go make a big investment in your savings plans, discount commitments. Yeah. So, I mean, just kind of going through your baseline, the utilization, what you’re using, identify those opportunities, so you can do that manually. You can use a product like Yotascale and then go through the actual process of implementing the changes that are approved.
Once you’ve right-sized, then you can start planning for your purchase, right? You now have more confidence in the workloads that you got out there. If you’re looking at EC2-specific and EC2 instance commitments where you get the bigger discount, you want to look at how many resources or how many dollars am I spending each hour in total of hours or dollars. And if you’re looking at reserved instances, savings plans, and start to understand for each instance class.
So the point here, I’m not gonna go through every single one of these and bore you to death. But the point is this gets complicated, and there’s a lot of variables to think about, and that’s where looking at a product like Yotascale can help you evaluate the options that you have without having to go do all of this in a spreadsheet.
Other recommendations that I would call out is to make the purchase at the payer account. That allows you more flexibility in where it’s applied. You can purchase reservations and savings plans at a linked account, and then those reservations and savings plans will be used at that account first before they’re spread to other accounts. But the recommendation really is to purchase it at the payer account so they’re used across the board. And if you have a budget, that’s another thing to consider as well, right?
If sometimes you can’t just purchase all of the reservations or savings plans that it’s recommended for you, there may be a budget that you have, either a monthly amount that you need to spend or an annual amount that you need to spend. Maybe you don’t have the money for CapEx and you have to just do the recurring payment with OpEx.
So we’ve done our right-sizing, we’ve made a purchase, we’ve invested, and now how do we manage these going forward? Two key metrics that I recommend tracking are utilization and coverage. Utilization—generally, you’re not going to have 100% utilization. If you do, that means that there’s more opportunity, likely more opportunity out there for you to increase the commitment that you’re making.
Wastage is the—so utilization is, I’ve purchased 10 reserved instances. How utilized are those reserved instances? Because what those are are blocks of each hour you’re expecting to have 10 instances running. When you talk about reservation, if I do it in a $10 per hour commitment, each hour I’m committing, I’m going to spend $10 with AWS. So understanding how well utilized is that is important, but again, it doesn’t need to be 100%.
In a perfectly optimal world where there’s variance like we see here with the workloads, you’re not going to have 100% utilization. If it’s flat and you’ve got 10 resources out there, you know exactly what it is. You’ll get 100% utilization, but generally, we’re looking at trying to minimize the wastage, maximize the utilization, and also minimize the on-demand spend that we have.
Those coverage targets can rely on your CapEx, OpEx comfort levels. So it really depends on how much you want to invest and how much on-demand you want to leave out there in case there’s a risk of that on-demand going away or that variable workload going away.
Anu did you have a question?
Anu Gardiner
I do, Jeff. At what frequency, In your experience, do customers do this? Is this a daily exercise? Is this something that’s done monthly or quarterly? Could you give us a sense of how, on top of this, people need to be?
Jeff Harris
Yeah, yeah. It depends on the organization. I think generally quarterly is a good place to start if you’re not already doing quarterly. If you’re doing quarterly, I mean monthly can be an interesting option as well. I think it also depends on what state you’re in. Are you in a lift and shift? Are you growing significantly? Because in those cases, you want to watch it more closely. You get to a fairly steady state, and you’re not expecting a lot of change. You don’t need to monitor it as closely, but those initial stages of moving into AWS or in a high growth environment, then you want to watch more frequently because there’s going to be more opportunity.
We’ll actually get into a case study here in a minute that kind of explains the math behind that.
Jeff Harris
Some of the flexibility there, specifically around reserved instances. There is a cost of conversion, so you have to manage and maintain it yourself. There’s also a 12% fee if you’re selling reserved instances in the marketplace. So those are just things to keep in mind as you’re considering whether or not to convert or to sell or to buy convertible. Any of these options, there is a cost to that flexibility.
All right, so getting into what is the optimal scenario for… There’s a question here from Roman. What is the optimal scenario for a company that has seasonality, 50% of the year low workload, 50% high workload?
Yeah. So let’s say summers are spending more money on cloud in the summer or in the winter, for whatever reason. Because you’re only, let’s say that workload pops up to that and is 50% higher during these high growth periods or high use periods. I would say don’t buy reservations for the spiky part of the workload there because you’re making a commitment for a full year, so it is a commitment to 24/7 use of that resource. In that case, I would say if you know it’s going to be like that, start to look at can we design our application to use spot? If you want to get some discounts, how could we potentially leverage spot or spot instances to be able to save money?
I would say whatever that low workload baseline is, is where you want to focus your discount commitment because that’s going to be there throughout the year. Commit to that level. Whatever you’re comfortable with within that level and leave that seasonality where it grows for whatever period of time different on demand or look to spot to see if you can cover it.
Yeah, there may be some… If you want to get really fancy with it, there may be some opportunity to go purchase some reservations on the marketplace, but you’re kind of limited to what’s available in the marketplace, and you can find some deals out there, but it is hit or miss. So that’s somewhere to look as well.
Can you time when you buy savings plans? Anu can you help me understand that question?
Anu Gardiner
I was thinking exactly to Romano’s question about, let’s say you’re dealing with an e-commerce company and they know that, starting after October, it’s going to be the big load. Could you then say we’re gonna buy all our SP’s in the month of September?
Jeff Harris
You could, but if that workload dropped, right? Let’s just use a Black Friday scenario, right? So I bought savings plans, anticipating our huge spike in October. Well, you’re going to feel really bad when October is over and your workload drops down, but your price is the same. You’ve lost the elasticity capability, the value and the elasticity because now I’m paying for that. I paid less for that spike, but now I’m paying for it for a year. So in that moment in time, it was great, but now I’m committed to operating at that spike level for a year. So no, yes, you can time it, but no, I wouldn’t recommend doing that for seasonal workloads.
Anu Gardiner
Hence your recommendation to tie it to the lowest level, if you will, of the workload.
Jeff Harris
Yeah, exactly. Exactly.
Jeff Harris
So quick case study. This was a case study from a customer of ours. Really, we’re going to start with the theory here. So the theory is if my EC2 costs are increasing over time. So again, we’re talking about a very specific use case, although I think there’s a lot of people in this scenario or in this situation today and historically of increasing my spend on AWS compute. If you’re continuing to add workloads to AWS, let’s say you started at zero and each day I’m spending more and more money on AWS. This is really the on-demand cost that you have here, right?
So just quick math: four units in there, right? If we make a purchase, then our on-demand cost drops to zero and then our linear growth continues. So that’s sort of what’s happening in this chart. If I, instead of purchasing way out here, I make two purchases during this time period, I’ve now reduced the amount of on-demand spend that I have. So this is a case for purchasing more frequently. If I make this purchase here, I now have on-demand cost through this growth period and then it continues to grow at that same linear rate. Make another purchase a month later and now over that two-month period, I’ve reduced my on-demand cost by 50%.
Feel free to jump in if we have questions here. It gets a little bit more complicated as we look at this one. So what if I did four purchases during that same time period, same concept. I now have 75% savings because I’ve reduced the amount of time that I have on-demand costs.
So when we look at an actual use case, this is the data for some on-demand costs for a customer of ours. And they were purchasing at about a monthly frequency. We see we have all this on-demand spend. It drops down when they buy their reserved instances or savings plans, grows over time, purchase drops down. So this is an actual use case where we saw a customer purchasing on a monthly basis and saw the impact on their on-demand cost. Now they’re still spending money on the reserve cost, right? But that’s workload that they were going to be paying for either way. As they had this growth that was happening pretty rapidly throughout the year, they decided they wanted to make these purchases more frequently, and they got a benefit from that.
Yeah. So in this example, there were four purchases in this period. They saved about 75% of on-demand costs, which comes out to almost, you know, $220K per year for this particular use case, spending about, you know, anywhere from around $2K per day on on-demand EC2 costs here.
Jeff Harris
Any questions about anything that we talked about today? Happy to go through any of this in more detail. And if not, I can spend a quick 5 minutes just kind of showing what we’ve got in Yotascale.
Susan Brandes
Hey Jeff, I did get a question from email, any tips for engineering and finance have to work together to make all this happen. It’s a huge job. Any advice you can offer?
Jeff Harris
Yeah, it’s a good question. Yeah, it tends to be finance that has to pull the trigger on this, right, because you are making a big purchase and it is a multi-year commitment in either case or a year or more commitment in either case. So usually the finance team is the one who approves that, and there’s a challenge because engineering is trying to say, “Hey, we want to prepay for our compute use or we want to make a commitment that we’re going to be paying for this millions of dollars for the next year.”
In an ideal world, you’re able to do a capacity planning exercise. You’re able, every engineer is able to tell you exactly what they’re going to be using, how that’s going to grow over time. Where we do see capacity planning, this doesn’t happen at every company, but where we do see it happening, it tends to happen in a spreadsheet. Somebody is kind of collecting information and trying to put it all together. And then you have to do this exercise almost every time, right? So it can get very difficult and challenging.
In a lot of organizations that are doing this successfully, there is a central sort of like a hybrid team may have heard of FinOps. Some people call it financial ops. Some people call it cloud operations, cloud success. The idea being you need both finance and they need a counterpart in engineering so that they can have the literacy across both disciplines. Right, engineering doesn’t quite understand the constraints that finance has. Finance has no idea what an M54X large is, or why it matters. So you have to have that sort of hybrid team to really do this well.
That’s a good question.
Jeff Harris
All right, very quickly, I do have some…
Anu Gardiner
I just wanted to add a funny bit there, Jeff, to your point about finance and engineering having to work together, I still remember I was at the AWS event in San Francisco in April. I was talking to an engineer about, you know, how they tackle this, and the answer was, “I don’t know. Finance pays the bills.” So you just brought us down to reality, which is, you know, engineering and finance have to come together, and do come together, to solve this problem.
Jeff Harris
Yeah. And you know, honestly, it tends to be something that people avoid because there’s this big financial commitment, finance doesn’t understand the sort of the attributes that are being combined that I’m purchasing for. Will it be around for the next year or three? So often there’s a hesitancy to make a commitment at all, and then you end up paying on demand instead. So it’s costing you money to not make this commitment.
If you think you’re going to be using the resources for the next eight months, make a one-year savings plan, compute savings plan purchase, and just at a 30% level of what your on-demand cost is, it’s fairly safe. And don’t come back to me; I’m not going to pay for the bill if it turns out not to work out for you. But the idea is to find a way to step into it, make a small purchase, get comfortable with it, start going through this process, and as you build the expertise in-house, it just becomes second nature.
Anu Gardiner
Yeah, especially, I mean, just the macroeconomic environment, you know what’s happening today. Every CFO is under a lot of pressure given what’s coming in the next year. And so to your point, if you don’t already have this muscle going, it becomes very difficult because you need talent. You need people working together, and you have financial pressure. So really, really relevant and timely comments from you, Jeff.
Jeff Harris
Yeah, thank you. So quickly, I’m going to jump through just a couple of screens here in Yotascale to show how we fit into that whole life cycle of managing, both identifying what’s needed and helping make recommendations.
First step here, just looking at some of our EC2 costs for our example company, Acme Tech. One of the ways that we break this down is not only can you see how much you’re spending on each instance type, but I can see how much I am spending on demand, on spot, on reserved resources, right? So all of my EC2 costs can be broken down into these categories as well.
We can see here at Acme Tech we have a pretty good base. There’s probably some opportunity to make some purchases because I do see a consistent level of on-demand each day over the past 30 days, but we are covering up our base with reservations. And this is what we want to do. We want to cover the base with reservations or discount commitments because we’re confident in this amount of cost and this amount of workload sticking around in the cloud. But we’re not so sure about this on-demand fluctuation, this variability that we see in the on-demand cost. We’re just going to expect to have some, but we want to try to reduce this, and there’s still some opportunity here because we see at least about $30K per day being spent on demand for EC2.
So the first step is just to identify kind of how things are going out there. Let’s take a look at where we’re at now. Yotascale can also provide specific recommendations and help you evaluate the differences between them.
When we look at compute savings plans recommendations as an example here, I’m able to see what is that default recommendation from AWS. So AWS tells me three-year, all upfront is going to be the best savings I can get. That’s great. I want to know about it. This is based on some time period in the past, and we can see what our savings rate is going to be over that on-demand cost that we may incur.
With Yotascale, we see a couple of different options down here as well though, right? So maybe a three-year is not really what we can do, but we want to understand… (Oh, I clicked on the wrong button there. Excuse me.) Back over here, add options with Yotascale.
What I can actually do is come in and say let’s look back at the last 30 days. Let’s use that to base our decision on. We see a lot of this variability here. We can look at maybe a one-year, and let’s do no upfront and our hourly commitment 7 day. My data is not going to be friendly to me here today, but the idea is I can come in and enter a budget in terms of how much I want to commit, and then we can see how that budget compares to the other options that we’ve added here.
This is really useful when talking to finance and trying to speak more of their language. We can say if we make a one-year commitment, this is how much it’s going to cost us per month, per year, compared to what we’re currently paying per month, per year. What’s the savings on that? How much upfront cost will I have for this option?
So the intent here is to help you evaluate the different options that are out there, including allowing you to set your own budget. This is a big difference from what you see in just the AWS console. So keep that in mind.
And then after you’ve made those purchases, the next step is the monitoring. We also have some capabilities here in our analytics side that allow us to see where the wastage is coming from, how much we have used, both looking at utilization as well as wastage. So when we look at wastage, I can identify what region, what instance type. We can see the RDS wastage, Redshift wastage, etc. So I can see all of that here in Yotascale and monitor where it is coming from, what instance types, what regions, etc. That allows you to determine if you need to make any changes, and then you can use the recommendations module to evaluate where you can redeploy that capital.
Susan Brandes
Jeff, did you cover this? Ray wants to know, could we see the qualified service type breakdown in charts for compute SP?
Jeff Harris
That’s a good question. In the console here, within this recommendation, you can find that in cost analytics. The other piece here within recommendations that I would point out…
Susan Brandes
We’re almost out of time here, Jeff.
Jeff Harris
Yeah, yeah. This is the last thing I wanted to share. That EC2 filter on here, we can also see things like RDS reservations. With RDS reservations, different from our compute savings plan recommendations, we get specific. So with reservations, you have to define what instance type, region, operating system. Then we can go in and look at the details of each of these recommendations.
Here, we can see a breakdown of the different sizes and how those are contributing to the recommendation that we’re making here for this smaller size. This goes back to that size flexibility concept we were talking about earlier. We can see what our usage was over time. You can even purchase reservations from Yotascale for RDS and EC2 as well.
OK, I’ll stop here. If there are any other questions, I’m happy to answer them and appreciate everybody’s time today. Feel free to reach out via email to us as well.
Susan Brandes
Yeah, that was a lot of stuff to cover. Thanks so much, Jeff, for doing that. Everybody, we did record this, so we’ll send you a link to the recording within the next day or two. Please reach out to me. You all have my email if you have any questions or if you want to, you know, talk further with Yotascale. Thanks, everyone.
Jeff Harris
Thank you. Have a good day. Thanks.
