{"id":2336,"date":"2021-04-30T21:21:46","date_gmt":"2021-04-30T21:21:46","guid":{"rendered":"https:\/\/beon.studio\/blog\/?p=2336"},"modified":"2026-05-28T14:50:43","modified_gmt":"2026-05-28T17:50:43","slug":"aws-lambda-the-good-the-bad-and-the-ugly","status":"publish","type":"post","link":"https:\/\/beon.tech\/blog\/aws-lambda-the-good-the-bad-and-the-ugly\/","title":{"rendered":"AWS Lambda: The Good, the Bad, and the Ugly"},"content":{"rendered":"\n

The World of Serverless Applications<\/strong><\/h3>\n\n\n\n

A serverless architecture allows software developers to create and launch applications without worrying about infrastructure support, fault-tolerance, scalability, and capacity provisioning. For engineering leaders, it is also part of choosing the right tech stack for long-term success<\/a>. It has been around for some years, and as people adopt the technology, several articles have been written about how good Lambda functions are, what you should be worried about, and the disadvantages of having an architecture where you don\u2019t have full control of.<\/p>\n\n\n\n

Here, we\u2019ll summarize and give in-depth technical answers to many of the questions and debating points about Lambda functions that have been around the internet since the birth of serverless applications.<\/p>\n\n\n\n

The Good<\/strong><\/p>\n\n\n\n

When you start working with AWS Lambda functions, the first thing that you notice is how easy it is to have your code ready for production<\/strong>. As you have the code fully running on the AWS infrastructure, you\u2019ll spend less time worrying about how the application will be deployed and instead focus entirely on the business logic of the solution<\/strong>. That deployment simplicity also connects with the broader challenge of building CI\/CD infrastructure for scalable remote teams<\/a>. <\/p>\n\n\n\n

Taking the burden of managing the infrastructure from the developers is much appreciated. Also, as you can access the configuration that your container will have when the Lambda function gets executed, you can quickly adjust it without doing a deployment.<\/p>\n\n\n\n

Just after the Lambda function gets executed, AWS will create a new instance of a container under the hood, which will die ten to fifteen minutes after your Lambda function finishes. In a Serverless architecture, you\u2019ll only pay for the resources you use<\/strong>, and as Lambda functions don\u2019t have any idle cost, hosting your infrastructure in the cloud will make you save up to 90% in server costs.<\/p>\n\n\n\n

Imagine that your application goes viral overnight and you go from a thousand users to fifty thousand. If you are managing your own servers, you know this is a recipe for disaster.<\/p>\n\n\n\n

During these peak times, your business needs to handle the spike of requests without any downtime or delay, and this is where AWS Lambda functions can save the day<\/strong>. The AWS Lambda service scales automatically with demand, creating multiple containers (or re-using them) to serve all requests.<\/p>\n\n\n\n

As your user base grows, you\u2019ll start to notice more Lambda invocations than before, but you won\u2019t have to make any change to the configuration<\/strong> to support a new load of users as Lambda will handle all of it.<\/p>\n\n\n\n

By using AWS Step Functions, you have the possibility to build complex asynchronous workflows to perform different tasks, a pattern that also shows up when teams evaluate a RAG, fine-tuning, and AI agents decision framework<\/a>. Step Function workflows, or just workflows<\/em>, give developers the option of chaining several AWS Lambdas where each of them performs a small task and then passes its responses to the next one. This allows the creation of small and testable Lambdas that can be reused across several workflows. We can make an entire solution using only Lambda functions, and we can also make use of it\u2019s great integration with other AWS services\u2014S3, Kinesis, DynamoDB, among many others\u2014as Lambda is an event-driven architecture.\u00a0<\/p>\n\n\n\n

The Bad<\/strong><\/p>\n\n\n\n

If I told you that using AWS Lambda functions will make you save money, prevent you from worrying about infrastructure, and give developers the possibility of focusing on what’s important, you\u2019ll probably be waiting for a cold shower of reality because everyone would be using a serverless architecture if it were all advantages. Let\u2019s discuss the most common topics of debate<\/strong> that make people reject switching to a serverless architecture.<\/p>\n\n\n\n

If you were to search over the internet \u201cissues of using AWS Lambda\u201d, the first result that will show up are cold starts. <\/strong>It isn\u2019t a strange concept, the first request that is made to a Lambda function will have a higher response time than the following one. This can add significant overhead\u2014up to 1.5s of latency! <\/p>\n\n\n\n

\"The<\/figure>\n\n\n\n

Having cold starts on the first response from your API could or could not affect your business. Most of the time, this isn\u2019t a dealbreaker for adopting a serverless approach as multiple solutions have emerged that prevent or solve this issue.<\/p>\n\n\n\n

You should be worried about cold starts on Lambdas only in these scenarios:<\/p>\n\n\n\n