No-Code Serverless: Simplifying AWS Architectures
How removing unnecessary Lambda functions from AWS architectures can boost performance, reduce cold starts, and simplify your infrastructure.
During my several years of working with AWS cloud-based systems for various clients, whether in long-term engagements or specific projects, I have repeatedly encountered situations where Lambda functions were used as intermediaries between services, without implementing any real business logic. Over time, I began to analyze whether, in such cases, it would be better to eliminate the code entirely and allow AWS services to communicate directly.
A common pattern I observe when reviewing clients’ architectures is the use of Lambda functions as middleware between AWS services that do not perform any business logic. The most frequent example of this pattern is API Gateway -> Lambda -> SQS/SNS.
The code for such an intermediary typically looks like this (example generated for demonstration purposes):
A one-time solution like this does not seem to cause problems at first glance, but when an application has >20 microservices built in this way that communicate with each other and run asynchronously, there is a significant drop in performance and an increase in AWS resource usage (in this case, Lambdas) that are not necessary.
By eliminating unnecessary Lambdas in a large system and moving the entire integration to the infrastructure level (for example, CDK), we can clearly observe the following effects:
- Reduction of latency caused by Lambda cold starts
- Decreased resource consumption and related maintenance costs
- Fewer components requiring testing and deployment
- Improved architecture clarity and simplified change lifecycle
- Reduced failure points: one less service means one less potential source of errors
This kind of change is also important for project management. Less code means fewer tests, less CI/CD, fewer dependencies. The architecture becomes more deterministic, and its configuration can be described solely in the infrastructure as code layer.
From real life...
Below are a few examples of architecture transformations I have recently done, which had a significant impact on resources from the perspective of the whole system.
Use case 1: Sending emails based on users different actions in the system
Before refactoring:
In this approach, the first Lambda function was middleware only and it received the request from API Gateway and simply forwarded it to the SQS queue, without any processing logic. Then, the second Lambda picked up messages from the queue and conditionally routed them to more services such as Amazon SES, S3 (for data archiving) and CloudWatch (for logging events). This solution worked correctly, but it introduced unnecessary complexity, increased response times (for example, due to cold starts), and added extra points of failure. It also led to higher resource usage, which affected maintenance costs.
After refactoring:
The refactoring involved removing the Lambda functions and replacing the message distribution logic to SES, S3, and CloudWatch with EventBridge Pipes. As a result, the entire data flow now happens directly between AWS services, without the need to maintain or run application code. The flow became more transparent and declarative, configured as infrastructure without writing code. EventBridge Pipes provided reliable and scalable event distribution to multiple target services, with easy filtering and data transformation capabilities.
Benefits:
- Zero code needed to put messages on the queue
- No cold starts
- All JSON mapping is done in integration.request.body on API Gateway side
- Ability to validate JSON schema by API Gateway (JSON Schema model)
- Asynchronous work split on EB pipes, which provides a clean and reactive architecture
- SQS combined with EventBridge Pipes is a great fit for fan-out - multiple pipes can independently process a single message and send it to different services.
- Easy to extend - if new logic is needed, new pipe would do it without changing the currently working solution
Use case 2: CSV file verification
Before refactoring:
After uploading a CSV file to a specific folder in S3, an analysis is automatically triggered to detect whether the file contains data matching patterns defined in code. Depending on the result, the file can either be automatically moved to a secure area or marked for manual review.
After refactoring:
The refactoring involved removing all custom Lambda code and using AWS Macie, where custom patterns can be defined for data detection. Macie emits the found data to the appropriate EventBridge rules, which then execute the required logic accordingly.
Benefits:
- No code - lower costs, zero cold starts, less maintenance
- Observability and auditability - each "finding" is a separate event that you can log and analyse
- Flexible routing through EventBridge - easy to add more consumers and extend decision-making by adding appropriate EventBridge rules
Each of these approaches above allows building a reactive architecture that does not require maintaining intermediate application code. This means higher efficiency, lower cost, and simpler maintenance.
Limitations of a no-code approach
Although an architecture based solely on service integration sounds appealing, it also comes with challenges. The biggest one is the lack of real code that can be tested or run locally. All logic, including data validation, event filtering, or request routing, is moved to the service configuration layer. No tool allows full testing of such an architecture without running it in a cloud environment. Debugging is limited to analysing logs in CloudWatch, using X-Ray, or inspecting metrics. For developers who expect to write unit or integration tests, this is a significant limitation.
From my perspective
From a design perspective, this approach offers significant visual and conceptual benefits. If microservices and processes are well documented using data schemas, flow diagrams, and state diagrams, a code-free architecture can be exceptionally clear. You don't need to look over the implementation. Everything is defined as data flow and service configuration.
This approach requires a mature team, experience with cloud technologies, and a clear understanding of the tool's limitations. A no-code architecture is not a universal solution. I do not recommend implementing direct AWS service integrations everywhere just because it’s technically possible. I believe the choice of services and tools should be tailored to the specific problem, solving it in the simplest, fastest, and most efficient way, considering cost, performance, security, and complexity. Sometimes that means avoiding code. Other times, writing code is necessary.
Direct integration of AWS services is a powerful tool. It allows you to reduce code, simplify architecture, lower costs, and increase reliability. However, it’s not an approach that can be applied thoughtlessly. It requires a shift in how we think about applications, a different approach to testing and configuration management, and a high level of design discipline. When well thought out, it delivers excellent results. When applied automatically, it can hinder development, increase vendor lock-in, and limit the team. It’s not a shortcut, it’s an alternative path that, under the right conditions, leads to significantly better outcomes.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article