AWS Lambda is one of the most powerful serviceless platforms on the cloud at the moment. Its benefits range from cost efficiency to infinite horizontal scaling.
To list down, following are key benefits of using AWS Lambda
- Easy Setup
- Automatic Scaling
- Serverless
- Invoke via SDK
- Low cost
While these are crucial for many, going for lambda just for the sake of using lambda will be fitting a triangle or square in a circular box.
Here are six AWS Lambda limitations where using Lambda is either not feasible or isn’t a good choice at all.
let’s dive into the points.
Suggested read: How to setup and configure LAMP on ubuntu server? Speed up your app deployments with AWS App Runner. |
No Specialized computing hardware or GPU
Thinking of Resource-intensive workloads and AWS Lambda together? If your process requires special hardware or GPU for high processing or a machine learning accelerator.
In the recent past, Lambda allows you to use 100GB of RAM which spans across 6 vCPU but no specialized hardware option you have.
Not for latency-sensitive process
Lambda is fast but latency-critical applications should stay away from it.
Cold start problem with AWS Lambda, package size, and further dependency on other lambda processes and their cold start time can drag your latency to anywhere near seconds.
Not suited for higher processing time
Long-running tasks and AWS Lambda limitations: If your business logic takes higher than 15 minutes of processing time, avoid using lambda.
Lambda has currently a maximum running time of 15m, so anything near or more than that should stay away.
Not for large and consistent request volumes
Lambda is awesome when traffic patterns are rare and unpredictable, it outperforms everything else, stays cost-effective, and requires a minimum to maintain so. Since cost is based purely on usage, you pay nothing if no invocation is done.
Also if your request suddenly surges, lambda is quite good at scaling horizontally and handling those situations
Keeping Cost considerations for AWS Lambda, however, if your traffic has grown to a consistent volume after a certain threshold, keeping hardware availability stable will outperform lambda.
Ec2 or other computer asset gets cheaper in such cases.
No console access
Lambda provides basic monitoring via cloud watch and other logging services.
If your requirement or troubleshooting requires console access to see and debug, and audit internals. Lambda doesn’t provide you so at the moment, need to look for alternatives to AWS Lambda.
Limited memory and storage
If your process requires a large amount of memory and faster file access, lambda is not something for it. Currently, lambda provides up to 10G of RAM and 512MB of file storage during the process/runtime.
Alternatively, EC2 can provide you with much more memory and volume storage, so switching to EC2 will be something you can look for.
Final note
While we have plenty of solutions available for much more diverse use cases. We should definitely keep this in mind before making the switch, seeing our use case is recommended over the trending services.
See the latest and updated limitation of AWS Lambda
Follow @Inteligentcomp for more updates.