What is the Lambdalith approach?
The “Lambdalith” approach refers to utilizing AWS Lambda in a monolithic manner.In essence, this approach consolidates all REST API routing and processing logic into a single Lambda function. Here’s what it looks like in an AWS architecture diagram:
In the blog post Operating Lambda: Design principles in event-driven architectures – Part 2, here’s what it says about AWS Lambda design principles:
Most architectures should prefer many, shorter functions over fewer, larger ones. Making Lambda functions highly specialized for your workload means that they are concise and generally result in shorter executions. The purpose of each function should be to handle the event passed into the function, with no knowledge or expectations of the overall workflow or volume of transactions. This makes the function agnostic to the source of the event with minimal coupling to other services.
In other words, by breaking down Lambda functions into smaller units with a single purpose, you can shorten execution time. On top of that, the overall architecture becomes more loosely coupled, making it more scalable and reliable. From this perspective, using AWS Lambda in a monolithic way seems to go against the design principles that AWS itself recommends.
The Lambda monolith documentation also points out that monoliths are considered an anti-pattern, and that you should adopt a microservices approach by splitting Lambda functions per API route. However, in practice, I’ve never really felt any drawbacks from implementing Lambda functions in a monolithic way—to be honest, I’ve only experienced benefits. In this blog post, I’d like to highlight some of the advantages of taking the Lambdalith approach.
The benefits of the Lambdalith approach
Easier Lambda Runtime Updates
Probably, the most annoying thing of maintaining your Lambda functions is runtime updates. You can’t just ignore them since AWS announces them regularly—but in some projects, there may be dozens or even hundreds of Lambda functions with no test code, leaving you unsure of where to even begin to update. If each API endpoint is handled by a single Lambda function, the overall number of Lambda functions in the architecture can be significantly reduced. As a result, the effort involved in performing runtime updates is greatly minimized.
Reduced Cognitive Load
Cognitive load refers to the mental effort required to understand an entire architecture. An architecture that you can grasp at a glance—say, just by looking at an AWS diagram—can be considered one with low cognitive load. For example, an architecture using Amazon EC2 and Amazon RDS is easy to understand right away, so its cognitive load is low. On the other hand, imagine being suddenly assigned to a project with 50 Lambda functions tied together with EventBridge, SQS, SNS, and DynamoDB… It would take quite a bit of time to figure out the overall architecture and how each service is being used. That’s what we’d call a high cognitive load.
High cognitive load is one of the drawbacks of serverless architectures. And when you have a large number of Lambda functions, even monitoring logs becomes painful. Some of you might have experienced getting a log notification, trying to track down the corresponding Lambda function, and realizing you can’t remember what role it was supposed to play.
This is where a Lambdalith architecture helps. By consolidating everything, the configuration, specifications, and IAM policies become simpler, and the cognitive load is greatly reduced. moreover, having just a single Lambda function makes log monitoring and tracing much easier. In terms of operational efficiency, that’s a huge win.
Fewer Resources to Manage
A single CloudFormation stack has a resource limit of 500, but it used to be only 200. Every time you create an API route, you end up consuming three resources—Amazon API Gateway, AWS Lambda, and Amazon CloudWatch Logs. If you were creating a separate Lambda function for every API path and method, you could only fit around 60–70 paths and methods into a single stack before hitting the limit. It didn’t take long to run out of room.
With a Lambdalith architecture, you almost never have to worry about CloudFormation’s resource limits. This also ties back to the idea of cognitive load, but more importantly, it provides a clear advantage in terms of maintainability.
Use Popular Web Frameworks
When you build a web application on Amazon EC2 or Amazon ECS, you may use some kind of web framework. With a Lambdalith architecture and the aws-lambda-web-adapter—an open-source project published by AWS—you can use those same frameworks on AWS Lambda as well. For developers who aren’t familiar with Lambda, this lowers the barrier to entry and greatly expands the options available for building applications.
On top of that, applications built for Amazon EC2 or Amazon ECS can be migrated directly to AWS Lambda, which increases portability. This flexibility allows you to adjust your architecture more easily based on cost or traffic requirements.
Use AWS Lambda Function URLs
AWS Lambda Function URLs provide a simple way to add an HTTP endpoint directly to your Lambda function. While they don’t offer as many features as Amazon API Gateway, they come with the benefit of lower cost.
In a Lambdalith setup, every request is handled by a single Lambda function, and routing is managed within the function itself. That makes Lambda Function URLs a natural fit for this architecture. On top of that, they can deliver APIs with lower cost and latency compared to Amazon API Gateway.
Lower Cold Start Frequency
Since the architecture is consolidated into a single Lambda function, all incoming requests are directed to that function, which in turn reduces the frequency of cold starts.
The disadvantage of the Lambdalith
It’s true that there are some drawbacks, but in practice they rarely become major pain points in development or operations.
- IAM policies and permissions can easily become too broad
- Lambda function code can get complex , requiring careful and experienced design
- Package size can grow quickly, making it easier to hit the 250 MB limit
Conclusion
In this article, I’ve introduced the benefits of the Lambdalith approach. To be honest, I see it as an architecture with nothing but advantages. It makes both development and operations easier, and by using AWS Lambda Function URLs, it can even lower costs. So next time you need to build an API, I encourage you to give this approach a try.