← AWS Bites
AWS Bites
144. Lambda Billing Changes, Cold Start Costs, and Log Savings: What You Need to Know
00:13:22
Loading summary
Transcript5 lines
- [00:00]
A
Cost is always the burning topic when it comes to building in the cloud. Luckily we've been treated to quite a few cost reductions from AWS over the years now and then we can get cost increases too. And today we're going to talk about some new updates from AWS and zoom in on some recent cost increases as well as decreases. I'm Owen, I'm here with Luciano and this is AWS Bytes. AWS Bytes is brought to you by four Theorem. Stay tuned to the end of the episode so we can tell you a lot more all about that. Now, whenever we talk about AWS Lambda, we discuss its cost model. With lambda, you pay for the number of requests you make, which is generally the much smaller component. But you also pay for the execution duration that's built in tiny 1 millisecond chunks, and the cost is proportional to the amount of memory you allocate for that function. Now there are a few different things that can affect this cost. Further back in 2022 year pricing was introduced and that lets you save up to 20%. If you've got high volumes of lambda usage, you've also got compute savings plans, which don't just apply to containers and EC2, but Lambda as well, and they let you commit to a certain spend and save up to 12%. And of course you've also got provisioned concurrency. Now that lets you keep functions warm, which means you're paying as long as they're provisioned and ready to process a request, but the rate you pay is less than the standard on demand rate. Now, for a long time there has been a bit of a free lunch when it comes to lambda billing. We're not just talking about the pretty nice free here, but about the cold start duration, also known as the INIT phase. The INIT duration. This is the time your function takes to load the runtime and the handler code before it actually passes the event to your function. A lot has been written about this. We'll link to a nice article by Luke van Dankershut, which I think we've mentioned before. Up until now the initialization phase was not billed for managed runtimes. Those are the official runtimes like the Python node js, Java Net Ruby runtimes. By the way, if you want to learn about how a runtime works, we have a whole episode dedicated to that topic. That's episode 104 and you'll find the link in the description. Now this free lunch free init phase thing was never something you could avail of if you had custom runtimes so if you were doing something like C Go Lang, C Rust or your very own custom runtime, that was never something you got. Similarly with Container image packaging, which we use quite a lot now, especially for large dependencies that never had this free INIT phase and provisioned concurrency never had it either. But there is a couple of benefits. So not only was it free, you, you also get two VCPUs during this init phase, regardless of the amount of memory you allocate for your function. And normally the VCU pus are tied and scaled linearly with the amount of memory you allocate. So if you wanted two VCPUs, you'd have to allocate at least 3,538 megabytes of memory to get those two cores. So you had a little bit of a performance boost in that init phase to get things up and running. The maximum execution time of that phase, by the way, is 10 second. And if your initialization exceeds this, the function times out and gets retried. But you could get a lot done potentially in those 10 seconds. So AWS has potentially spotted an issue there. Do you want to tell us more about that and what they've done about it?
- [03:15]
B
Yeah, as you can imagine, this is almost like, yeah, you mentioned it as free compute. That's, that's what it can be used for. And ideally you wouldn't really abuse it. Like the INIT phase is for, I don't know, initializing the AWS clients. Like if you want to interact with S3 or DynamoDB or maybe load Secrets or initialize other kind of clients that you might need within your lambda. So it's to kind of initialize all of these resources that ideally want to create once, and then for multiple events you will be reusing those instances. So that's the kind of usual stuff that you will do with it. But you can imagine that people could do all sorts of nasty things or maybe just use it as free compute. So like number crunching, processing, whatever they need to do, they will spin it up in a lambda, have that code in the INIT phase and then somehow make that lambda crash or maybe change an environment variable so that a new instance would be forced for the next time that lambda runs. And effectively this way you could be exploding that free compute idea. And of course this is something that AWS probably realized and they thought that the easiest solution is to reintroduce, to introduce building also for this init phase, which also makes the whole cost equation a little bit more consistent, depending on your choice of runtime or if you use something like container for image packaging or if you use provision Concurrency so the question you might have now is okay, I was not abusing, so that maybe seems a little bit unfair that now I need to pay for something that was not paying before. So yes, what kind of impact can it have in like real use cases where you're actually running a business and doing like useful stuff, you're not just trying to exploit AWS free compute? And it's not easy to answer this question. Of course your mileage might vary. I think for most people at least this is our belief, the impact is going to be very minimal. Probably you won't even notice. There might be some extreme cases where maybe you have lots and lots of cold starts, or maybe where you have lots of invocations in general, but the ratio between the initialization phase time and the execution phase is very high. In this case you might see maybe a little bit of extra cost because of course that you are doing a lot of init and now you're getting billed for that INIT time. Now another question you might have is does this make a better case for highly efficient custom runtimes like compile languages as we mentioned already, Rust C, Go, or maybe if you use other ones, maybe you can bring your own custom runtime and run code written in other compiled languages? This is also a very difficult question because I think you need to analyze exactly your use cases. So I would say it might make a difference or not. In general, I think what is worth understanding is that the init phase duration with custom runtimes when you use compile languages can be much faster. So if you're really looking for reducing that cold start, either for cost reasons or maybe because maybe you have like APIs that are running in lambda so you don't want to have occasional extra latency just because you happen to have a request that is actually creating a lambda for the first time so the user might perceive that cold start. I think using languages like Rust C or Go can make a little bit of a difference. Now difficult to give you exact numbers. There is actually a very good benchmark by Maxim David. We've mentioned it a few times. We'll leave the link in the show notes. You can open this benchmark and see a comparison between a big matrix of combinations between memory runtime, type of CPU architecture and try to figure out by yourself what is maybe a good combination for you. Of course we are not advocating for rewriting everything in Rust, although I would like that. But maybe not always the most pragmatic choice. But I will say again, if, if you really have a Lambda, that maybe you are running thousands or even millions of times per day, or maybe you are actually trying to build very efficient HTTP APIs on Lambda, you might actually justify the investment of rewriting some of that code in Rust or other compiled languages to keep it as fast as nappy as possible. And there is of course another element that we always think a little bit as a secondary element, but it's actually quite important if you care about carbon impact. Those languages generally have a much better carbon footprint. So that's another reason maybe to explore a little bit more this option. Now let's get back into logging cost reduction.
- [07:39]
A
Yeah, when we talk about Lambda costs, we're talking a lot about the execution time. But of course there's always the side effects with AWS services, since you generally need other services enabled to use things like lambda effectively. CloudWatch costs in particular logs are the primary culprit here. The situation used to be pretty much that CloudWatch Logs was the only destination for your logs and you'd pay $0.50 per gigabyte of log collection and around $0.03 per gigabyte of compressed storage thereafter. And a while back, AWS made a really nice change by adding an infrequent access tier for logs, which reduces the storage cost by 50%. So that can make a big difference. Already now, since the start of May 2025 this year, we have even more cost saving possibilities. So the main announcement was that they announced the pricing is now tiered based on usage. So what are the tiers? Well, if you have over 10 terabytes per month per account, you'll only pay 25 cents per gigabyte for standard access and 15 cents for infrequent access. That's for anything over that 10 terabyte threshold. So anything up to that initial threshold, you're still paying the old price. And there are more tiers then in steps of 20 terabytes terabytes. And then if you have a lot of logs, anything over 50 terabytes is as low as 5 cents per gigabyte, whether that's standard or infrequent access. Now these thresholds are pretty high, so it won't benefit everybody, unfortunately. But if you've got a massive CloudWatch logs bill because of your extensive use of Lambda, it can make a big difference. Eric Pullen from the Duckbill Group actually wrote a nice article all on this and even shared a calculator script that you can run against your account to estimate how much you might save. So I'd recommend checking that out and seeing if it's going to be a big lever for you.
- [09:22]
B
Yeah. Another interesting change which might help with cost reduction is that now you have new destinations for Lambda logs, as you say. It was the case that you can only send stuff to CloudWatch. Now you can actually send logs to S3 and firehose instead of just CloudWatch. And I think this will be very useful for you if you already have to process. If you already have processes that take Cloud Watch logs and send them to other destinations, you were effectively using Cloud Watch logs almost like as a transitioning storage and maybe not even ever consuming data directly from CloudWatch logs. Now you can skip all of that cost and maybe use fyros to send the data directly to whatever is your final storage to consume the logs. And this is generally something that can happen if you use, for instance, third party tools for observability. So now there might be more options to make that integration a little bit cheaper. And I think that's always nice. And also in another sense, it removes a little bit of complexity because your architecture doesn't need a component that just moves data from A to B. Of course this is not free. There is a cost to use this new S3 or firehouse destination. You still pay up to 25 cents per gigabyte for log delivery to S3 and 5 OS. And then of course you have the cost of the S3 and 5 OS services as well that you need to keep into account. Are there some recommendations that we can give to people in case they maybe want to learn a trick or two on how they can save a little bit of cost when it comes to lambda and logs in general?
- [10:52]
A
Yeah. Even if we forget about all of these changes, we've discussed today whether those cost changes impact you at all. The cost of logging is something you should keep an eye on and we can give you a few relatively quick recommendations. Of course, we'd love to hear your tips, so let us know what you think. Number one is use infrequent access wherever possible. We've adopted this since it was made available as our default almost and we rarely miss standard access mode. It has some limitations, like you can't use Live Tail embedded metrics and metric filters, but you can still use Logs Insights, which is what we primarily use for viewing and searching logs. We have a whole episode on that actually, which is episode 35. And yeah, you can check that out. I'd also say set the log retention period to a reasonable value. Often you don't need to retain Lambda logs for months, and often by default they can be retained indefinitely, which can really cause you a lot of pain. Experiment with the other new feature, which is Advanced Logging Controls. I think this was released last year. Lambda can actually filter out verbose logging like debug level for you, and you can save costs that way. And if you're using AWS power tools for Lambda, you can also do debug log sampling so that it'll only print out debug log logs for a certain threshold certain percentage of events. That can save you a lot too, and you could also customize that per environment. And again, once features have stabilized, just remove unnecessary informative logging. I've heard stories from people who were investigating cloud costs because it became critical and they discovered that they were paying thousands every month for logs that say I'm here on line 23 and that was put in for debug logging during feature development and somebody forgot to take it out and it ended up costing tens of thousands of dollars for absolutely no reason. So just to wrap up then, we just gave a quick overview of some of the nice updates that might help us save a few dollars on that AWS bill. We also said we'd mention a shout out to fourthherum for powering yet another episode of AWS bytes. And at 4th yearm, we believe that cloud should be simple, scalable and cost effective, and we help teams to do just that. Whether you're working with containers, stepping into event driven architecture, or scaling a global SaaS platform on AWS, or even just trying to keep cloud spend under control, we have your back. So visit Fourethereum.com to see how we can help you build faster, better, and with more confidence using AWS Cloud. That's all. Let us know what you think, and if you know somebody who might find this episode useful, please share it with them. Thanks again. Until next time. Goodbye.