AWS re:Invent 2025 - The bill shock that taught me cost optimization (DEV208)

🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.

Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!

Overview

📖 AWS re:Invent 2025 - The bill shock that taught me cost optimization (DEV208)

In this video, Rejoice, a technical lead at Intelligi, shares how a $86 daily Lambda function cost taught her FinOps optimization. She explains that this single function accumulated over $31,000 annually due to idle wait time while calling Transcribe and Comprehend. Through Lambda Power Tuning, right-sizing memory allocation, breaking monolithic functions into smaller handlers, and optimizing log retention strategies, her team achieved a 97.7% cost reduction to under $730 per year. She provides actionable advice: audit Lambda functions in Cost Explorer, use AWS Lambda Power Tuning tool, set up cost alerts in AWS Budgets, and log only essential identifiers rather than full payloads.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

The $86 Bill Shock: How One Lambda Function Cost Over $31,000 a Year

Alright, hello everybody. It's good to see you all. Thank you so much for coming. You guys look tired. Are you tired? Wow, alright, cool. Let's get to it. I know there's a party next door, so let's just try to stay here. Okay, cool.

As I was introduced, my name is Rejoice. I'm a technical lead at Intelligi, which is a fintech startup in South Africa. All the way from South Africa, we're saying hello, Las Vegas. Right now I want to take you through some very interesting things. I think the title of my talk is "The Bill Shock that Taught Me Cost Optimization." This is something more around learning experiences and what we did with what we learned to sort of get into the space of FinOps.

When we think about the bill shock, I know you're probably thinking, how much did she have? Not a big number, right? Yeah, I know you're thinking, come on, Rejoice, $86? Really? Are we sitting here for $86? You're under $100. What? Is this a bill shock? Alright, I'm going to tell you why it is a bill shock. Firstly, this was a cost for just one Lambda function per day. Is it starting to, are you seeing it? So what this means is this number got burned in my head because the more I had to work around it, the more I learned how to optimize costs.

For today, on our agenda, this is what we're going to do. I'm going to take you through and basically help you understand things like the startup culture. I work in a startup space, right, so I'll take you through the startup culture. I will help you understand Lambda pricing in a way that actually makes sense. And then I'm going to show you how to right-size your functions and eliminate what we call idle wait time. As we move more into the talk, I'll show you how to optimize your Lambda logging to save cost. And most importantly, I'm going to give you practical actions that you can start working on now, as soon as you leave here, to help you optimize your cost if you work in a serverless environment. So, are you ready? Alright, cool, let's get into it.

So let's talk about the startup culture. Let me set the scene for you. I don't know how startups are in where you come from in the US, Latin regions and all that, but in Africa, if it works, don't touch it. We all know that if it works, do not touch it. So what this means is velocity. You need to be able to ship faster and make more revenue. It means lean teams, very small teams. It means small teams, big ambitions. That's startup. We are going to do as much as possible with as little as possible, and then it means just ship it. So it's MVP1, get it out there. We'll do this feature in MVP2. Does that sound familiar? I'm sure nobody in this room has worked at a company like that. You guys all have structure.

So I'm going to set a scene for you of what happened. At the company I was working for, we had this application that basically was doing a lot of sentiment analysis. At that time I just joined the company and I was trying to figure out what's going on. I was there building things so fast, but there were these things that were working that don't touch it, it's working. So I took a step back and then I was OK, let me find out about what's currently working. So I requested the architectural diagram.

Looking at the architectural diagram, as you know, we build the ship as we fly it. It didn't exist. The second thing, let's get into some code review, right? I had to go to the ground and create an architectural diagram. I'm trying to figure out what does this application do. After that, I now had to understand the costs, and that's when I saw it right there in Cost Explorer. $86.67 per day for one function. Now, this is what I came up with from my review. It was an Amazon Connect call center running sentiment analysis, and that was what it was. One function doing all of that.

So the problem was basically this. Does anybody know what could be the problem with this? This Lambda was waiting for all these other things to happen while it was running. Right, so let's talk about that bill shock moment. The $86 per day actually translated to five days, $433. In a month, $2,600, and in a year, over $31,000. In a year for one function, and don't forget there are other costs there. This is just one function costing over $31,000 a year.

Understanding Lambda Pricing and Eliminating Idle Wait Time

So what now we needed to do as a team was we needed to understand Lambda pricing, and this is where my cost optimization journey began, which is what I'm going to share with you. So the first thing was, when it comes to Lambda pricing, there are three key drivers for Lambda function cost. Number one is memory configuration. That is basically how much memory do you allocate to your Lambda function. Our Lambda function had over five gigabytes allocated to it because it was calling Comprehend, it was calling Transcribe, it was doing so much. So we thought, let's increase the memory, maybe it kept timing out.

The second thing that drives costs for Lambda is the function size, right? Memory configuration, function size, basically how big is your function. And the last thing is the number of invocations. Remember, Lambda bills per millisecond billing. So every time you invoke it, it's billing. Every time you invoke it, it's billing. So those are the three, they are not the only drivers, but they are the three main ones. These are the ones that normally you have to look out for.

Now, the critical thing here that people miss is that Lambda has this millisecond billing, right? And it charges the entire time that your function is running. So we know that it's serverless, right? You only pay for what you use, but the fact that it's idle doesn't mean it's not getting charged, and that's where most people miss it with Lambda. So now that was our problem. If I take you back, we now had to go and do a little bit of right sizing, right?

First up, the first thing that I'm going to do is I'm going to ask you a little quiz. Let's assume you have, I want you to tell me which Lambda function you think would cost more. You have a Lambda function with 128 megabytes and it's running for 10 seconds. You have another one that's one gigabyte and runs for one second. Which one do you think costs more? 128 or one gig? This one. Correct. Do you see that? It's weird, right? Because you'd think that's one gig, more compute, more power, more expense, but it's only going to execute something in one second, millisecond billing, and it's done. This is going to run for 10 seconds. You see that?

Let's get another scenario, right? How, then the question now becomes, how do you now know when to use what? How do you know this right sizing, how do you know? AWS Open Source Group, the community, has put together an amazing tool called Lambda Power Tuning. How many of you have heard of Lambda Power Tuning? So what Lambda Power Tuning does is it's basically a Step Functions state machine that uses real data. You give it different sizes of the Lambda, you want 128, and then it calculates for you.

So what you see here right now, at 128 megabytes, for those who have used Lambda, can you tell me what you can tell me about this graph? You can see here that right now the pink line is showing that at 128 megabytes, it takes about 3.5 seconds to execute. But then the sweet spot is there where it's circled. That's where there's the right sizing. So basically what this is saying is when you increase your memory to about 1.5 gigabytes, execution time actually dropped to 3 seconds. You see that?

I'm going to give you another example. Here's another one. At 128 megabytes of execution, it takes about 2.4 seconds, right? And when you bring it down, it's almost the same time, it's almost the same cost. So basically, bigger doesn't always mean more expensive. You see that? So if you want to know more, these examples came at the bottom of the screen. There is the GitHub repo for Lambda Power Tools. If you want to explore more about Lambda Power Tools, there are a lot of examples there that you can use. You can basically just run it and start using it.

So this is quite a great tool, and this is what we use to optimize our Lambda functions. This Lambda Power Tools sort of takes out the guesswork out of everything. You are able to use actual data to optimize your Lambda functions for your applications and actually find that sweet spot where performance and cost sort of meet. All right, so now let's take it a little bit further. Now that we have seen that bigger doesn't always mean more expensive, let's do another quick quiz. Which function here now do you think would cost more? The 128 one, yeah, because it's the same size, but this is running longer. So the per millisecond billing means this is going to run longer, meaning this is going to cost more.

Right, so I'm going to run through some key things. We said our biggest problem was that we had idle time, and when we look at our architecture the way it was, it basically meant that our Lambda function was doing the following. It will send audio to Transcribe and wait. It will get the transcription back and wait. It will send the transcript to Comprehend and wait. It will get the sentiment analysis and wait, and then it will send the results to S3. All of this waiting is what was costing us almost $86.67 per function.

So what we now had to do is we understood that having one function is not exactly saving money. We had to optimize things because idleness costs more, it doesn't cost less. So when it comes to Lambda, you need to avoid having your Lambda function working as an orchestrator. If your Lambda function is sitting idle, it is going to cost you money because Lambda is charged for running. Whether it's doing something or not, it is going to charge you.

Optimizing Lambda Logging and Achieving 97% Cost Reduction

All right, so when it comes to another key tip, it's Lambda logging, right? Lambda has different kinds of loggings that they actually released lately. You'll see at the bottom of the screen there's a recent blog that has introduced what is called tiered pricing. And this is basically the more you log, the cheaper it is. And this new functionality is automatic. What you see here is a screenshot of what tiered pricing will look like in the North Virginia region. All right, so you'll see that the more you log, the cheaper it gets. So this is a new feature. You should check it out. The blog is at the bottom. AWS wrote a very nice blog about this.

The next thing that you'll see is log retention. What do we need? Be realistic about your logs. Why are you keeping dev environment logs for a year? Be realistic. Do you need them for a year? You can say development environment is like 7 days to 2 weeks, staging environment is 30 days, production environment maybe because of compliance 3 months to a year or whatever. But be realistic. You can't log everything because logs cost money.

The second tip I'll give you is log archiving.

AWS also introduced a new cool feature recently that allows you to send your logs directly to Amazon S3 or Amazon Data Firehose. This is a new feature that you can do directly from Lambda for your logging. If you have a need for Lambda logs to stay for more than a year, why not just send them to S3? It will save you a lot of money. These are little things that we miss that actually end up spiking the Lambda cost.

The next thing that I will say is log smarter. What do I mean by that? You don't always have to log every payload. Log key identifiers that you need for your application. You don't have to log every single piece of information that's coming from your API. Logging everything costs money. The bigger your log payload, the more size that it is, the more money it's going to cost to store it. These are simple things that we don't think about when we are building, but they contribute to the Lambda pricing. So log key identifiers instead.

Now, the results. After doing all of this, we have since improved this. It's now running more on a Step Functions state machine. But at this point, the team wasn't very familiar with Step Functions, so we had to quickly do something with Lambda. We optimized our code and broke the Lambda into different chunks. You have just a transcriber handler, a sentiment handler, and a storage handler, which means it invokes for like three milliseconds, then it stops. It comes back with an S3 event trigger, it triggers another 13 milliseconds, then it stops.

The results were phenomenal. Our costs dropped to less than $2 per day. Think about it, from almost $86.67 for one function to having three functions like you saw here that now were costing us less than $2. What did this mean? That is over 97.7% drop in one function alone by doing these things that I just told you. Now think about what that meant for the company, because we still had Amazon Transcribe running. We had Amazon Comprehend, we had S3 logs, we had all of those other costs.

If one function alone was costing us roughly over $31,000 a year and it has now dropped to less than $2, what did this look like? The savings meant before we were over $31,600 a year, and after we are sitting with $730 a year. Think about it. Just by going back, optimizing our Lambda function, fixing up our logs, removing what we don't need, keeping only the logs that we need, we met this drastic 97% decrease in our bill. That is huge. I don't know what you think, but this is huge because all of a sudden, we moved from over $31,000 for one function. Remember, it's not one service, one function, and we had other things running also to that price a year without doing much.

So what exactly does this mean? At the end of the day, it basically means there are things that you can do now. Number one, go and audit your Lambda functions right now. Audit your Lambda functions, go into AWS Cost Explorer, sort these things by service, look for Lambda, and understand how much you are logging and what it is costing. The second thing is run the AWS Lambda Power Tuning tool. Go and find better ways to optimize your Lambda functions because there just could be something different you can do.

The third thing I would say is set up cost alerts. They seem like they are nothing, but they will save you a lot of money. Your wallet will thank you. Don't just wait for something to happen. Go and set up a budget in your AWS Budgets. Get notified before you are like us, stuck with over a $31,000 bill. The last thing I'll say is optimize your Lambda logs. Don't log everything. Log what you need.

You don't have to take every payload and log it. I know that you probably were expecting me to tell you about millions, but when you work in a startup, these are the little wins that in the end have great impact. Being able to move your bill from over $31,600 for one Lambda function to less than $730 for that same one function helps you optimize. I'd like to say thank you everybody for attending this talk. If you have any questions, you can meet me at the back, and I can answer any questions you have. Thank you very much, everyone.

---

; This article is entirely auto-generated using Amazon Bedrock.