Ep#146 Unlocking Accurate Cloud Cost Estimates using FinOps with Jeff Blume

Host: Jon

Hi everybody and welcome to the Jon Myer podcast. Today's topic is estimating cloud cost, and is that possible? We're talking with Jeff b Bloom, who's a senior optimization solutions architect at AWS on the optics team. Please join me in welcoming Jeff to the show. Jeff.

Guest: Jeff

Jon, thank you for having me, and thank you for accepting my random LinkedIn message to join. So

Host: Jon

Don't tell everybody that I accept it, man. Just

Guest: Jeff

Kidding. I used prior connections then to get on the show. Ignore my previous.

Host: Jon

Yeah, he had some influence based on the optics teams. Jeff, we're talking about estimating those cloud causes. How about you walk us through the process of actually estimating and what your thoughts are about it?

Guest: Jeff

Yeah, to me, I think that estimating cloud costs is a really important piece of any #FinOps journey, any cloud financial management journey. And the planning piece in that plan run for CFM is one that I've been experienced with in my history, both at AWS and prior. It's sort of how I got involved and got ingrained into #FinOps as a whole before #FinOps was a term. So to me, the cost estimation process is one that kind of breaks down into four steps regardless of cloud providers of one, describe that technical solution. Two, map two and identify in this case the AWS service that you'd want to use. Three, select those resources and then four, build out that high-level cost estimate. So there are some similarities and differences between how you would go about this. Depending on if your starting point is a net new workload or if the starting point is an on-prem workload, the existing data from an on-prem workload can help map those resources and services.

Guest: Jeff

But if it's not new, that's what folks like myself are here to do to help architect and design that workload to be cost-effective from the get-go. So to begin with that technical solution, think about what you need. I need to compute attached storage, I'm going to need X amount of servers, and I need X amount of object storage. And then you start to map those to those AWS services. So obviously if you need servers, it's going to be e C two. If you need to compute attached storage, it's going to be e B s volumes, object storage, I need s3. So then once you get that in place, you can dive a little bit deeper and start hatching out some of the specifics. So if you're going to use web S, what do I need? Do I need a general-purpose solid state? I'm going to go to GP three and the same for s3.

Guest: Jeff

I need object storage. What storage class makes sense? How often am I going to retrieve those objects? Do I need access immediately? Can I archive it? And then for e c two, similar things, right? What instance size, what instance type what operating system? And then you can dive even deeper and you can talk about whether will these be on all the time. Should I buy a savings plan? Should I leave them on demand? Can I use spot instances? So those are the types of conversations that we have all the time, and those are the things that when it comes to building a cost estimate, you can go through and do that at a high level and you can go through and do this in a rather quick manner or you can go through and you can do it in a rather detailed manner. To me, building out some of these cost estimates is one of the most complicated and complex things that you can do when it comes to the cloud.

Guest: Jeff

And you can go through and you can spend as much or as little time as you want. And to me, I think that if you don't let perfect be the enemy of good and you do the just good enough and I think you go ahead and move it and you can get a little bit more insights into how it's running once it's running on the cloud, using some of those reporting and monitoring tools and getting a handle on what that data looks like and what your application looks like once it's running, it's much easier that way.

Host: Jon

Jeff, we're going to dive into some of the tools in helping you estimate your cost for aws, but architecting the end product, that's really what you're talking about is working through from the start of it to the finish, but how it's going to look in the long term, three to six months down the road, optimizing your S3 archiving certain things always on going into RI savings plans, you're looking at the business-driven factors of your application, how long it needs to be up, what do you need to utilize? That sounds like a lot of time to implement. Is that going to be one of the cost benefactors of like, I'm going to architect it, this is going to take me months to architect it, but I need to get to the cloud right away. How do you balance those?

Guest: Jeff

It's tough, right? I mean it depends on what you want to do as a customer and how long you want to take. I mean, if it was me, what I think is a best practice, I mean, to take your best shot, take your best guess, and try to architect it as you can. But some of the things that you're taking, I'll say a guess like an air quote. You're guessing at what this is going to look like based on either an estimate you're creating for net new or what it looks like and it's very likely to be different. So once you build out the cost estimate, go ahead and run and test it out maybe in some sort of proof of concept on a smaller scale and see what it looks like. See some of those technical metrics, see what your CPU utilization looks like, disc utilization, and memory utilization.

Guest: Jeff

See how often you need to retrieve those things from S3 and then go from there. So in trying to balance how fast you move versus how well it needs to be from the get-go, there are things that you're going to do. You'll go through this estimation process and you'll say, Hey, I think we're in a good place here. This is as optimized as it's going to get. And then in two or three days you say, oh, actually something changed. Now we can take advantage of something else. So and optimization are a very long-term thing, and I would say that you don't need to do it perfectly right off the bat because as you go through and as you go through that journey, other opportunities to optimize are going to come up as things as you grow. And we'll talk a little bit later on maybe in this session, in a different session about forecasting and what pieces go into that and those are key pieces to try and figure out what is this going to cost in the long term.

Guest: Jeff

I think that as you look to optimize, it's going to be twofold, right? What can I optimize or what can I think about from optimizing right off the bat to number two, which is what can I look for once I've moved to the cloud? What things can I now view with the metrics and the data that I have to optimize again? And then kind of continuously do that. It's not just one and done either way, whether a week goes by, whether a month, that's part of the entire premise and part of the entire value proposition of synopsis. Somebody needs to be looking at this all the time. And in doing that, you're going to ensure that it's optimized over the long term and you're running as efficiently as you can in the cloud.

Host: Jon

Well, Jeff, I've got my architecture, but what tools are available to help me estimate my costs going to the cloud?

Guest: Jeff

There are some and some are better than others. So just at the very beginning level, there's a service page for every single W S service on the website that shows the public pricing great information for a single service, maybe not so great to try and price out an application that uses 20 or 30 services. So then you kind of go a level deeper. You have the w s pricing calculator, which can provide multiple estimates and multiple services at the same time, and you can use it to model some of those solutions before building them. And you can explore some of those AWS service price points and review the calculations behind those estimates. Probably still not a best practice in my mind. And as you go, like one layer deeper, you have the price list APIs, you have two. One is the bulk API, which allows you to query the prices of all AWS services in bulk, just like the name.

Guest: Jeff

And that API either returns a JSON file or a CSV file, and it retains all of the historical versions of the price list. And then the second one is the query API or the price list query API, where you can query specific information about certain AWS services products and pricing using either an AWS SDK or the AWS CLI. And that API can retrieve information about certain products or prices rather than just retrieving every single thing in bulk. So you can take out the information that you need. And then one more layer deeper would be if you want to just get notifications when the prices change on AWS, they change prices a lot. So whenever you go through and if AWS cuts a price of an instance or cuts a price of a service, those will be notified or you will get notifications whenever those happen.

Guest: Jeff

So you can sign up to be notified every time a price changes, whether that's, I think it sends out once a day and if you sign up to be notified once a day, the notification includes all the price changes that were applied during that day. You can also use Excel, right? Excel is something you could pull in the APIs. And I don't necessarily use, I don't like necessarily saying Excel is the way to go because it seems like well, Excel is an Excel kind of basic. Well, in some ways it is. But one of the mottoes that I've tried to go through, whether it be my #FinOps journey or my career is a manager of mine had said, keep it simple. And I think the exact acronym was kept it simple, comma stupid, but I leave that part off. I don't think that's necessarily a good thing, but it keeps, the simpler it is, the easier it is to kind of digest and to work with using the APIs or using Excel to try and model that out is something that I've had a lot of success with customers and trying to give more custom building and more custom control over some of those estimation drivers.

Guest: Jeff

Those are some of the different tools, some of the different options.

Host: Jon

Jeff, the pricing calculator that you're talking about is the newer version, not the older version that everybody's kind of familiar with, or the older AWS people who have utilized it, the version of the AWS S3 Simple monthly calculator that has since been retired, correct?

Guest: Jeff

Yes, there is a new version of the web-based tool. It's not the same s I think it was S three Simple Monthly calculator. It is different now. It looks different.

Host: Jon

All right. Now Jeff, how does Cloud #FinOps play a role in the estimation of your cloud cost?

Guest: Jeff

Well, I think setting up some of that #FinOps framework is an important piece of going through the estimation process. #FinOps as a whole, the entire framework is set on helping balance some of that agility and control of the cloud. And so when you think about a good #FinOps journey and setting up some of those foundational best practices, and whether it's cloud financial management or #FinOps, whatever term that you want to use, some of those core functions and core features are important and they all sort of tie together. So I'm talking about estimating cloud costs. I'm talking about the plan pillar of cfm. But it's also important to know that once you go through and once you plan something out, then you need to be able to see it. You can't action anything unless you can go and see some of those costs in real-time.

Guest: Jeff

So then you go and you take the next step and you can see your cloud costs, and then you have save, which allows you to go through some of the best practices and optimizing and run, which is setting up those guardrails and some of those cost controls. So I think having that framework and having that understanding is key in the planning. And one of the key features or one of the key principles of #FinOps is establishing some of that communication for the team, whether it's tech, whether it's finance, whether it's a product, or whether it's somebody from the business. Getting some of that executive sponsorship and going through and having those conversations, whether you're setting up a cloud center of excellence, a cloud adoption office, cloud business office, whatever term that you want to use, getting everybody on the same page and going through is going to yield better results.

Guest: Jeff

It's not something that one single #FinOps analyst on a team is going to be able to do by themselves with much success. If I'm estimating or if I'm helping estimate an app application for my cloud platform team, who better to know how it's going to run than the cloud platform team? I'm not going to go do that by myself. So I think understanding and establishing some of those #FinOps foundational pieces are key to try and understand one, how do you estimate this correctly? But two, start talking to some of those more technical folks who are going to be the ones deploying the application. They know better than that, or at least when I was in the role, they knew better than me about how it was going to run and what everything was and all those components were going to look like. So I think establishing that culture and opening the lines of communication early is one of the most important things that you can do as a whole.

Host: Jon

Jeff, one of the things that you mentioned about the notification on price changes for AWS through the API and that it came out monthly is daily. And one of the things that I've always noticed is that AWS has, I don't think I've ever seen AWS increase prices. It's always a decrease in prices. As new services come out, new features evolve. They want you to either utilize the new or the older ones, or they keep the prices the same. So that's one of the things that I like about AWS is they're always trying to reduce the cost. Here's a challenging question for you, right? Estimation is very tough to do, and some of the things in my experience when we used to do this, we would always add 20% overhead. The reason that is, is because I have never seen an estimation come close to the actual usage. How do you suggest we get a little bit better at that rather than say just add 20%, you'll be close enough.

Guest: Jeff

What was that? I'm sorry, Jon. I think you cut out on No, I'm just kidding. I think, and as I said earlier, I do the best I can. It's tough. That's why I said if you sit there and if you nitpick and if you go through it, I mean, I've had some customers we've talked to for months about changing variables and going through the different components, and you're right, sometimes it's wildly different from just actually running on AWS. So I think just take your best shot, use the available tools, talk to those different teams, and try and get a good understanding. Maybe you got something else you can model off of. Maybe there's another application that you're already running in the cloud that behaves similarly, and you can go through and say, okay, well what does this look like? What does the utilization, and what do the metrics look like?

Guest: Jeff

What KPIs matter on these pieces? And then maybe I can use that to help model the other. Now, if that's not the case, then you're just going to have to do the best you can with the different components and the different pricing and how your team validates that. But if you do can, maybe there's something else, there's somewhere else that you can look to help model an application or a workload that already exists, and you can go through those steps and kind of apply that extra layer of logic too to say, Hey, we know what this costs. We know what that costs. Let's kind of tie those together. Let's see what it looks like.

Host: Jon

Jeff, it feels like I need a degree in estimation. That's all. I mean, I don't think I'm going to ever be able to accurately estimate every single component because what about the hitting costs that are not thought of when creating it? Like the VPC DA data transfer, I don't know how much data transfer's going in and out. I want to keep it internal. That's all part of the architecting. But how do you account for all the hidden costs within, I don't want to say they're hidden, they're not like a surprise to anybody, but some things are not thought of throughout the process of adding those or how many times am I going to use SQL? How many messages are going to be sent? All the things that you can't account for.

Guest: Jeff

What's the old saying practice makes perfect. Is that how it goes? I think that some of that just happens. It happens over time. You're going to make some mistakes. Nothing's going to be perfect right off the bat. You're going to have to go through you're, you're probably going to make some mistakes. You're probably going to say, oh, I missed that. Right? There's a lot of documentation. There are a lot of articles. There are a lot of things you can read about how to do this. There are certain #FinOps books, there is the #FinOps Foundation. We have tons of messaging about how you do this. But the fact is that you're still going to miss things. You can do the best you can. And I would say go and read. Be as knowledgeable as you can be. And that's kind of why I said go look and see if you can see some of the other things around how your other applications are behaving if you are right if that's applicable.

Guest: Jeff

I would say most people watching this podcast are probably users of AWS in some capacity already. Whether it's a little bit or a lot. If you can go through and see some of the other costs of what an application does, maybe you can get some insights into that and say, oh, data transfer is this. I did not think about that. Doesn't have to be a workload that's the same or VPCs or anything of that nature. Those hidden costs that usually aren't considered whenever you're thinking, how much is it going to cost? Well, how much is the server? That's very, very top-level. But when you continue to go through and iterate, if you have some of that data at your disposal, I would say go through that and try to figure out what some of that is, whether it's support costs or whether it's those data transfer costs or whether it's a hidden storage cost that you didn't think about.

Guest: Jeff

I would say go through that and see if something already exists that you can leverage to take advantage of. And if not, then maybe start taking some of the peer connections into account. Listen to podcasts like this one, and listen to other people whenever they talk about their estimations and what they're doing and some of the things that are some of the gotchas, there are a lot of potential gotchas and people are pretty good about surfacing those. And I think we are in the middle of building a really good #FinOps community to share some of those best practices. AWS yourself, we're all on the same team I want, and we want customers to run efficiently and run as efficiently as possible and have as good of an estimation as you can get. So let's all share that knowledge, share those best practices, and try to remove those hidden costs and get those up to the forefront.

Host: Jon

Jeff, I think the community is key, and we're talking about #FinOps and estimation for your cloud costs, and it's possible. The other thing to note is that part of the cloud #FinOps methodology is accurate reporting and reporting. Often in the beginning processes, you might be reporting, I want to say daily or weekly, and checking and validating your cost. Jeff, you mentioned that practice makes perfect. We're not saying make thousands of dollars or a million-dollar mistake and your AWS bill, and that's where the reporting comes in to help you understand where your cloud costs are going. Jeff, you kind of said to keep it simple and you added another part, but really, what is that all about?

Guest: Jeff

The reporting?

Host: Jon

No, they keeping it simple methodology.

Guest: Jeff

Wow, I got you. Right. So I think that it can be pretty overwhelming especially in this space when you think about all the different things and best practices. So when I say keep it simple and think about some of the reporting aspects and some of the KPIs, start small. Don't try to boil the ocean. Think about some of the unit metrics and some of the KPIs that you can use and you can track that maybe don't take a lot of time or a lot of effort. You can kind of snowball that goes into the crawl, walk, and run. Don't try and just break out a dead sprint down the #FinOps journey. You're going to have to learn. You're going to have to keep it simple, especially early on. Maybe it's just total AWS spend as a metric. Maybe it's something as simple as AWS spending per instance hour.

Guest: Jeff

There are some advanced techniques that you can do, but I would say just try and keep it simple. And when you keep it simple, you're more likely to get some of that buy-in from folks who may not have as deep of an understanding as you. And if you can break that down into some of those fundamental building blocks, then I think you'll have more success than throwing up a bunch of fancy dashboards right off the bat. Some of them are good and they're detailed, but it can be overwhelming for people especially getting started. So that was kind of my thinking anyway.

Host: Jon

All right, everybody, it's time to wrap up our topic today of estimating cloud costs is that possible? Jeff, thank you so much for joining me.

Guest: Jeff

Thank you, Jon. It was great being on and had a lot of fun. Hopefully, we can do it again soon.

Host: Jon

Yeah, and in fact, we have an upcoming podcast to talk about budgeting and forecasting. Stay tuned for that release, everybody. My name's Jon Myer. You've been watching the Jon Myer podcast. Don't forget to hit that, like subscribe and notify because guess what, we're out of here.