Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Eoin: 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 Eoin. I'm here with Luciano. And this is AWS Bites. AWS Bites is brought to you by fourTheorem.
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. And that's billed in tiny one millisecond chunks. And the cost is proportional to the amount of memory you allocate for that function.
And there are a few different things that can affect this cost further. Back in 2022, tiered 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 tier, 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 of 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 Luc van Donkersgoed. 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 unit phase thing was never something you could avail of if you had custom runtimes. So if you were doing something like C++, Golang, 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 also get two vCPUs during this init phase, regardless of the amount of memory you allocate for your function. And normally the vCPUs 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 3538 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 seconds. 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 this and what they've done about it?
Luciano: Yeah, as you can imagine, this is almost like, yeah, you mentioned it as free compute. 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 you 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 exploiting 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 billing 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 I was not paying before. So yes, what kind of impact can it have in real use cases where you're actually running a business and doing 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 initial injection 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, 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 compile 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 compiled 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 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 Maxime 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 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 combined languages to keep it as fast and snappy 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 get 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.
Eoin: 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 50 cents per gigabyte of log collection and around three cents 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. And then if you have a lot of logs, anything over 50 terabytes is as low as five 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 share the 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.
Luciano: Yeah, another interesting change which might help with cost reduction is that now you have new destinations for Lambda logs. As you said, 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 processes that take CloudWatch logs and send them to other destinations.
You were effectively using CloudWatch 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 Firehose 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 Firehose destination. You still pay up to $0.25 per gigabyte for log delivery to S3 and Firehose. And then, of course, you have the cost of the S3 and Firehose 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?
Eoin: 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 using frequent 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 LiveTail 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 logs for a certain threshold, certain percentage of events. That can save you a lot, too.
And you can 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. 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 ForTheorem for powering yet another episode of AWS Bites. And at ForTheorem, 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 fourtheorem.com to see how we can help you build faster, better, and with more confidence using AWS Cloud. And 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.