AWS Lambda Reviews

We are using most of AWS services, including EC2, ECS, S3, Lambda, and Rock. We have been using AWS Lambda for close to five years now.

We are implementing a serverless architecture using AWS Lambda. For our typical client-server applications, we are using EC2s and ECS.

We are able to use both Python and JavaScript. We are using load testing and sending number of requests in parallel to test our applications.

AWS Lambda is effective for scenarios requiring quick response times and minimal logic. When we need to handle huge logic, we move that to AWS ECS.

Automatic scaling is a valuable feature. When the number of requests increases, the system automatically scales up to the target we have set and scales down once the requests are resolved.

We can choose which resources to pay for and we are able to use their free resources mostly. I have been using AWS for almost close to twelve years now, and I find it easy to use.

AWS Lambda needs to improve cold start time. Some AWS Lambda functions require a cold start, and if you need AWS Lambda to provide quick responses, you need some of the AWS Lambdas to be always on, which is risky. We need AWS Lambda's cold start time to be reduced so that we can use it much faster than now.

We need a better way to handle the cold start. We should be able to start AWS Lambda much before in a predictable way instead of just calling and then having it start.

Whenever the number of requests increases, the system automatically scales up to the target we have set and scales down once the requests are resolved. This is effective.

When we raise a ticket or have an issue, the support team is responsive.

Neutral

I have utilized AWS Lambda's event-driven architecture.

As it is serverless, AWS Lambda has more scope for building scalable architectures.

AWS Lambda's integrations with other AWS services have helped my development process. We can integrate with S3, API Gateway, Step Functions, and EventBridge schedulers.

I would assess AWS Lambda's flexibility in supporting multiple programming languages for my projects as good. We mostly developed in Python and .NET.

Based on the requirement, AWS Lambda's ability to manage compute resources will be configured because there are many projects, so each team has a different configuration.

I haven't used AWS Lambda's auto-scaling feature yet, so I cannot provide a rating or evaluation.

In my opinion, AWS Lambda can be improved. As it is serverless, from our end, we don't need to manage it. All of it will be maintained by AWS itself. We don't need to put more effort on it. Regarding scaling, we can add up to 1,000 execution environments for every 10 seconds per function, per region.

I would like to see additional features in the future in the monitoring and logging part to make it closer to ten. The graph representation should be more accurate compared to now, and also API response and container image support would be beneficial.

Event source mapping improvements, particularly with SQS, can help when we provision them for faster scaling.

I have been using AWS Lambda for about two years.

My experience has been positive overall.

I would rate their technical support as a seven out of ten.

Overall, it is good, but there is some room for improvement when it comes to response time and overall competence. The response from them is not faster. If it is a priority issue, they will give the response quicker, but if it is moderate, they take some time.

Before AWS Lambda, I worked in GCP, where it was Cloud Function. AWS Lambda is also similar to AWS Lambda function.

AWS Lambda's ability to manage compute resources will be configured because there are many projects, so each team has a different configuration. I have assigned an overall review rating of eight to AWS Lambda.

My customers' usual use cases for AWS Lambda are to create serverless engines so they don't want to have a dependent engine. For a few services, they don't want a dependency, so we create a serverless engine for them through AWS Lambda.

AWS Lambda is supporting my customers' AI-driven projects.

My customers do not integrate any specific AI tools or frameworks with AWS Lambda; we generally use authentications or small services. We have not integrated any AI-related functionality until now, but we create microservice-based applications. In that, we integrate those serverless engines so that dependencies can be removed at a place of a complete system or complete port. We just have a single service that is going to do each and every work for that particular purpose. The dependencies it is removing is a good thing.

The features or capabilities of AWS Lambda that I have found most valuable are how easily usable and integratable it is with normal functions or SQS, SNS, or event-related things. If I want to hit any event-related tasks, it can easily provide me all those configurations in the AWS part. It is very easy to use and the way we can use it with multiple languages is also good.

The features of AWS Lambda that have most significantly improved the workflow efficiency for my customers are the limits they have; they can increase those limits so that it is better for all the clients. There is a limit of a particular amount of RAM or memory that can be allocated. This limitation should be increased to double at least so that it is better for bigger serverless engines to work properly.

Other than memory limitations, the areas I would to see improved or enhanced in AWS Lambda are mainly concerning monitoring, as everything else is pretty good and fast.

My concerns about monitoring in AWS Lambda are that the logs they provide are not easily understandable, and how they provide it makes it take time to find specific logs and that particular number itself.

I have been working with these tools within the last 12 months, as I have been working with this tool for the last 8, 9 to 10 years.

When it comes to how stable and reliable AWS Lambda is, I can rate this aspect a nine from 1 to 10, where 1 would be the lowest and 10 would be the highest stability level.

My customers have not had any issues with the reliability of AWS Lambda. I don't know about others, but for me there have been no issues.

My impression of AWS Lambda's automatic scaling capabilities is that it is pretty good; auto scaling works well for multiple hits and multiple things. For a small application or small serverless application, it is very good.

I would rate how scalable AWS Lambda is a nine on a scale from 1 to 10, where 1 would be the lowest and 10 would be the highest level of scalability.

I can rate scalability a nine because the functionality, the scalability, and the easily integratable services are very good.

When it comes to the increased needs of my customers trying to grow, AWS Lambda is not an issue to grow with them, but another concern I have is that it is a bit expensive in comparison with Google Functions.

I never interacted with the technical support and customer service of AWS Lambda because I never needed it.

Negative

My experience with the initial setup and deployment of AWS Lambda is that it is very simple.

This is a very simple process. I just add my components and it works. They also give a visual editor where I can easily add my required components, for example, any event I want to add. It is very easy.

It usually takes me one minute to deploy a Lambda.

My customers have not shared with me any information about the return on investment from working with AWS Lambda. I never talk to clients directly. Whatever information I get is from my upper higher leads.

I have not used any documentation, guides or manuals for AWS Lambda specifically; maybe I did it around three, four years ago, but not nowadays. I don't need any guide.

Back when I was using documentation, my impression was that it could be improved. They are using complex terms at multiple places, so those things should be improved. When I read at that particular time, I noticed these issues. Nowadays, I don't read documentation as I know how to implement multiple things.

I figured everything out myself; sometimes documentation helped, but it didn't help completely. Some things I needed to figure out myself.

I rate AWS Lambda 8 out of 10.

What I appreciate most about AWS Lambda is that you do not need to purchase the entire service; it only charges you whenever you call that API, which is excellent.

Another feature I value most is that if anything changes, you need to call the function through the AWS Lambda event, and it will update your data wizard.

The initial setup of AWS Lambda is straightforward and not overly difficult. If you understand what the number is and how to use it, then it will be easy for you, but if you do not know what it is, then it can be somewhat challenging.

From my perspective, I believe there is nothing to improve in AWS Lambda.

I have been using AWS Lambda for around two years to trigger events happening in my day with my database.

I would rate the stability of AWS Lambda as stable; there is no issue, but there is only the time issue that I believe is an AWS issue.

On a scale from one to ten, I would rate the scalability of AWS Lambda as eight because you can write as many limiters as you want, and they can trigger whenever that particular time zone event happens.

The reason for the eight rating is that sometimes when I want an event to occur, I want AWS Lambda to be called, but it is not calling at that particular time; it is calling after some time, which might be a latency issue that I am uncertain about, but in one project, I have seen this scenario.

I evaluate the technical support team as good; if we send an email, we can get a response within twenty-four hours.

Before using AWS Lambda, I was directly using Postgres, and when something happened in storage for that particular Postgres, I had to trigger an event by writing general code in Python.

The initial setup of AWS Lambda is straightforward and not overly difficult. If you understand what the number is and how to use it, then it will be easy for you, but if you do not know what it is, then it can be somewhat challenging.

Regarding licensing or pricing, AWS Lambda pricing is high, similar to the servers for S3 buckets, and if we purchase them for two years or three years, there will be some kind of discount, but it is not a very large discount that we can afford.

I would recommend AWS Lambda to others, especially if the latency issue is fixed, then it is totally good.

I would tell others looking into using AWS Lambda to understand what the purpose of AWS Lambda is; according to their requirements, they can use it for scenarios that occur in the database or CPU when events happen, which can be handled directly. I give this product an overall rating of eight.

I am currently using it mostly for our APIs. We don't really use any instance or any soft host for it. We just use purely serverless for our API operations. 

Before that, my previous company used it mainly for step functions. Some of our processes would trigger step functions, which in turn would trigger a series of Lambda functions to process the data.

The convenience is a valuable feature. If you start the traditional way, you need to spin up an instance or host a container, which can be a lot of effort. Lambda allows you to focus on the code itself. You can easily integrate it into API gateway, making the convenience probably the best part.

Having a better preview would be helpful. Sometimes, if my Lambda code is too big, it can be inconvenient as I'm unable to see my code when it exceeds a certain size. AWS has a limit, like a three-megabyte limit, beyond which I cannot view or edit the code easily.

I have been using it for probably about three years now, I would say. It could be three and a half years.

All of this is usually automated. We typically have a DevOps team to manage these automation processes. Developing the desktop infrastructure generally requires two or three developers, provided they know what they're doing. Once it's set up, the entire process should be automated, eliminating the need for further human input.

Personally, I haven't encountered scalability issues, but AWS themselves have mentioned Lambda scaling issues. For example, Amazon Prime noted that while Lambdas can scale, it becomes really expensive with a lot of traffic. So, Lambda might not be the best solution right now for high-traffic applications.

Most of the support they provide is just documentation. I don't think there's anyone I can call or ask for help unless I pay extra. For AWS, the company needs to pay extra for technical support. Companies like Stripe have call services for developers, but I'm not aware of AWS having anything like that. Having something like a Discord server for support would be beneficial.

Negative

At my last company, I know they used to use containers instead. They actually moved to Lambda after some time.

I would say it's quite easy to set up. I would give it a ten compared to Google Cloud, as it is easier to set up. The first time I deployed, I used the template, so it took a few seconds. However, the template Lambda did nothing significant. For work, we use CloudFormation, and it usually takes a minute or a minute and a half.

Usually, all of this will be automated. We typically have a DevOps team to manage these automation processes. Developing the desktop infrastructure generally requires two or three developers. Once it's set up, the entire process should be automated, eliminating the need for further human input.

This is not really my area since I handle the coding part. I know that if there are a lot of Lambda requests, it might turn out to be quite expensive compared to hosting the API traditionally. 

However, I don't have access to the traffic data for the company, so it's not something I'm aware of or concerned about.

Before that, they switched to Lambda, jumping onto the microservices hype some years ago. I think it might not have been the best decision in hindsight, however, it is done, and we cannot go back now.

Overall, I would rate it an eight out of ten. 

It is a good starting point, yet be aware of how your project scales. If you start encountering high traffic with your backend, Lambda might not be the best option. However, it's definitely a good and easy way to start.

I use it for event-based retrieval. This is just to process for trigger purposes.

It has access to various other AWS resources like S3. You can use it to configure event-based triggers or conditions. You don't need to configure the servers; it will automatically execute the job and go idle. In that regard, Lambda is good and serves the purpose.

Integration capabilities:

They have the built-in IDE, so everything happens without integration issues. 

AI-features:

Just the Amazon Q [Amazon Simple Queue Service (SQS)] will also be there, like a pop-up in the AWS console. We can use that for Lambda as well, but no other integration. I wish there were AI integration for the code, like CodeWhisperer. That would be a good add-on.

They could add Copilot or their own suggestion tool, like CodeWhisperer, to the AWS IDE. The current IDE seems outdated and could be improved. 

Also, Lambda is restricted in terms of Internet access. 

You can't get public connectivity directly. You need to download packages manually elsewhere, zip the files, and add the layer manually. You can't install packages directly from the Internet, like PIP install Pandas.

I have been using it for two to three months. 

It is a stable product. 

On a scale of zero to ten, maybe seven out of ten, with ten being best.

I have faced a few challenges while implementing Lambda. There are possible limitations, like the timeout error. Initially, you'll have that timeout issue. Based on the scenario and load, you need to adjust the timeout manually. Otherwise, the job will fail, timeout, and go idle again. 

You need to manually verify the process, check the logs, and adjust the required time. 

Tip: Regarding layers, you need to manually zip and install them. This step needs practice, and you might need to do it several times. Be aware of that.

Deployment time:

For deployment, simple use cases need some apps to deploy. For new issues without proper documentation, you may need two or three days.

Maintenance and Costs

No maintenance is needed if it is deployed correctly. If it passes your tests, the function will work properly in the background. It's not expensive. It costs maybe less than ten dollars per month in my use case. If deployed on a manual server, you need to run it for the whole month. Lambda does the job and goes idle, providing good value for money.

It's not expensive, it is okay when it comes to licensing. It costs maybe less than $10 per month in my use case.

Overall, I would rate it a seven out of ten. 

My recommendation:

Regarding layers, you need to manually zip and install them. This step needs practice, and you might need to do it three to four times to get a hang of it. Be aware of that.

Positive

My primary use case for AWS Lambda involves real-time data and media processing. Specifically, I use it to process user-uploaded content, including filtering, resizing, and applying effects to media files like images and videos. Lambda triggers these operations immediately upon file upload, ensuring minimal latency. One of the key advantages of using Lambda is its automatic scaling, which adjusts based on the volume of uploads. This means it can handle spikes in traffic without the need for provisioning and managing dedicated infrastructure, allowing for cost-effective operations during periods of high demand. Additionally, by leveraging Lambda, we can quickly deploy new processing workflows without affecting the existing infrastructure.

AWS Lambda has greatly improved our organization by driving significant cost savings and enabling more efficient resource utilization. Its pay-per-use pricing model ensures that we only pay for the compute power we actually use, which helps optimize our budget. The generous free tier is particularly beneficial for smaller applications or low-traffic periods, allowing us to reduce costs even further. Moreover, Lambda eliminates the need for provisioning, maintaining, or scaling servers, which not only reduces operational overhead but also frees up our team to focus on more strategic tasks. This serverless architecture has enhanced our agility and scalability, as we can now quickly adjust to changing workloads without worrying about infrastructure management.

The most valuable feature of AWS Lambda is its event-driven architecture. This allows us to trigger code in response to events such as data changes, HTTP requests, or database updates, without worrying about provisioning or managing servers. The automatic scaling feature is also incredibly valuable, as it adjusts seamlessly to traffic spikes, ensuring optimal performance without manual intervention. Additionally, Lambda’s serverless management and resource efficiency significantly reduce overhead by automatically handling infrastructure. This enables our team to focus on application development rather than server management, all while benefiting from cost-effective pay-per-use pricing, which has been a key advantage for us.

One area where AWS Lambda could be improved is the execution timeout limit, which is currently capped at 15 minutes. This is restrictive for tasks that require longer processing times, such as complex data analysis or large-scale batch processing. Additionally, the environment customization is limited, particularly with regard to file system access, persistent storage, and certain execution capabilities, which can be restrictive for more advanced use cases. Another area for improvement is the cold start latency, which can add significant overhead to the execution time, especially for applications with infrequent or unpredictable invocations.

For future releases, it would be helpful if AWS Lambda allowed for longer execution times or offered an option for more flexible execution environments. Reducing cold start latency or offering features like provisioned concurrency with more granular control could also help improve the overall performance and responsiveness of Lambda functions.

I have been using AWS Lambda for a total of three years, although my experience has been spread out over time, rather than continuous usage.

AWS Lambda is highly stable and reliable. It automatically manages scaling, fault tolerance, and availability across multiple availability zones, ensuring that functions remain resilient and available even in the event of infrastructure failures. This distributed architecture reduces the risk of downtime, as Lambda can quickly shift workloads to healthy zones. Additionally, its integration with other AWS services like CloudWatch provides robust monitoring and alerting, helping to quickly identify and address issues before they impact performance. This stability makes Lambda an excellent choice for mission-critical applications that require high uptime and reliability.

AWS Lambda is highly scalable and excels in handling varying levels of traffic due to its auto-scaling capabilities. It automatically adjusts the number of instances based on the volume of incoming requests, ensuring that the application can handle spikes in demand without manual intervention. This scalability is particularly beneficial in environments with fluctuating workloads, such as user uploads, real-time data processing, or event-driven architectures. Lambda’s ability to scale up and down efficiently ensures optimal performance while minimizing costs by only utilizing resources when necessary. This makes it a great choice for applications that need to quickly adapt to changing traffic patterns without the complexity of managing infrastructure.

I have not had to contact AWS technical support for Lambda, as we have not encountered any critical issues that required intervention. This reflects the stability and reliability of the service, as it has been relatively straightforward to implement and maintain. However, I do appreciate the comprehensive documentation and the support resources available, such as the AWS forums and CloudWatch logs, which have helped us troubleshoot any minor issues independently. In the rare cases where we might face challenges, the AWS support team is known for being responsive and helpful, though we haven't needed to reach out yet.

Positive

Before using AWS Lambda, I utilized IBM Cloud Functions for event-driven architecture, particularly for supporting a microservices-based approach. While IBM Cloud Functions offered similar capabilities, I switched to AWS Lambda due to its more extensive ecosystem, better integration with other AWS services, and scalability. AWS Lambda’s seamless integration with tools like API Gateway, DynamoDB, and S3, along with its robust community support and more flexible pricing model, made it a more suitable choice for our evolving needs. Additionally, Lambda's ease of use and automatic scaling significantly improved our operational efficiency.

The initial setup of AWS Lambda is generally straightforward, especially with the self-managed AWS infrastructure, which eliminates the need for provisioning and maintaining servers. The process of creating functions, setting triggers, and integrating with other AWS services (like S3 or DynamoDB) is intuitive, thanks to the comprehensive documentation and AWS console. However, debugging distributed resources in serverless applications can be challenging, as the lack of direct access to the underlying infrastructure can make it harder to troubleshoot complex issues. While tools like AWS CloudWatch and X-Ray provide visibility, the distributed nature of serverless architectures sometimes requires a more nuanced approach to pinpoint and resolve issues effectively.

The deployment of AWS Lambda typically requires just one person for the configuration and setup, as the service itself is self-managed. However, writing the code and integrating Lambda with other services usually involves a team of three to five people, including software engineers, QA testers, and sometimes DevOps engineers, depending on the complexity of the use case. In our case, the implementation was handled by an in-house team with expertise in cloud technologies and serverless architectures. The process was collaborative, with engineers focusing on code development and automation, while QA testers ensured the functions were thoroughly tested for performance and reliability. Overall, the expertise of our in-house team allowed us to deploy AWS Lambda efficiently and effectively.

AWS Lambda offers a strong return on investment (ROI) primarily through its cost efficiency and pay-per-use pricing model. By eliminating the need for provisioning and maintaining infrastructure, Lambda reduces upfront capital expenditures and ongoing operational costs. Its auto-scaling feature ensures that we only pay for the compute resources we actually use, which translates into better cost management during high-demand periods without the need for heavy infrastructure investments. Additionally, the time saved on managing infrastructure allows the team to focus on development and innovation, further increasing overall productivity and reducing operational overhead. These factors combined lead to significant cost savings and higher operational efficiency, making AWS Lambda an excellent choice for optimizing ROI.

AWS Lambda offers a highly favorable pricing model, especially for smaller applications or low-traffic workloads. The first one million requests per month are free, which provides significant cost savings for startups or testing phases. After that, the pricing is based on the number of requests and the duration of function execution, which is quite cost-effective compared to traditional server-based solutions. The pay-per-use model means you only pay for what you use, eliminating the need for upfront costs or long-term commitments. However, it’s important to consider that while the costs are low, high-frequency invocations or long-running processes can add up, so it's essential to monitor usage to optimize spending.

Yes, before choosing AWS Lambda, I also evaluated Azure Functions, which is another popular solution for event-driven architecture. Azure Functions offers similar features, such as automatic scaling and integration with other Azure services. However, I found AWS Lambda to be a better fit due to its deeper integration with the broader AWS ecosystem, including services like API Gateway, DynamoDB, and S3, which are critical to our infrastructure. Additionally, Lambda’s pricing model and scalability options aligned more closely with our needs, especially for handling varying workloads and minimizing operational overhead.

I would rate AWS Lambda a nine out of ten. It stands out as one of the most important AWS services due to its high return on investment (ROI), cost-effectiveness, and ease of use. Lambda's serverless architecture significantly reduces the complexity of managing infrastructure, allowing teams to focus on building applications. Its seamless integration with other AWS services, including CloudWatch for monitoring and logging, enhances its value by providing robust observability and troubleshooting capabilities. While Lambda excels in scalability and performance, I would suggest that improvements in execution time limits and cold start latency could make it even more powerful. Overall, Lambda has been a game-changer for my organization, offering both operational efficiency and significant cost savings.

I use AWS to host our app space within my university, APU. My infrastructure is based on the AWS cloud, and most of my compute workloads are primarily based on Lambda. This setup facilitates all transactions that require engagement from multiple stakeholders, including staff, faculty, students, and administrative staff. I have in-house applications, both mobile and web-based, that engage with Lambda to provide the required scalability, especially during peak hours of university timings. Lambda is a highly utilized service for me.

The most important feature of Lambda for me is that I don't need to manage any resources. I don't have to set up an AWS stack or developer tools, as they are provided by AWS by default. This means that if I need to set up Lambda, it's a matter of minutes to deploy my code, which facilitates my CI/CD pipelines. Time is an important optimization for me, and Lambda is economical. Additionally, it is highly available and sustainable, unlike EC2, which is a single point of failure. Lambda saves me time in configuration and deployment and gives me confidence in its high availability and scalability. I have done my workload migration from an on-premises environment to the cloud, significantly reducing my capital expenditure. The automation improves my planning for product releases and hybrid connectivity. Also, content delivery has improved, and application latency has decreased.

I would say an increase in the current limits would be quite beneficial. Right now, the threshold is fifteen minutes. AWS has increased the limits from three to ten gigabytes, enhancing the productivity of different workloads. If this threshold is extended further, more workloads currently utilizing EC2 could potentially be executed using Lambda.

I have been working with Lambda since 2018.

Speaking of scalability, I would rate this aspect as close to nine out of ten. So far, I haven't had any issues with the usage of Lambda. Since AWS launched its region in Malaysia, the compute is happening right next to my location.

Support is of the highest quality, so I would give it a five out of five.

Positive

Before Lambda, I mainly used my on-premises environment.

The entire Lambda project took less than three months. I'm not the team lead for that setup, so the exact timeline isn't possible for me to provide. Currently, I'm mainly in the training division.

Maintenance of the overall cloud setup involved less than fifty people. They are not only for maintenance, as they are also involved with enhancing other solutions. I would include developers who are creating new products and releasing them. So overall, the staff is around fifty, but specifically for maintenance, there are fewer people.

Azure was one of the options during my evaluation, but I decided to go with AWS.

I would suggest newcomers go through the AWS Well-Architected Framework, especially the serverless application stack offered by AWS, such as Lambda. The cloud adoption framework by AWS is quite in-depth, providing many integration points for reskilling and handling workloads. It’s crucial to explore these frameworks before migrating workloads to the cloud. Additionally, looking into AWS CloudFormation for automating infrastructure provisioning is beneficial. I would rate AWS Lambda as nine out of ten.

I use AWS Lambda for serverless services to avoid running applications on an instance. I use it for my personal website. When people want to view my website, the service is trigger-based, so it only operates when accessed, allowing for cost efficiency.

I like AWS Lambda as it is cheaper compared to other AWS services that require applications to be running continuously. Lambda is trigger-based, which means it only activates when accessed, ensuring cost savings. 

It's also serverless and makes processes easier despite the initial difficulty in setting it up. Being able to configure Lambda to work in a trigger-based manner is highly beneficial for my needs.

AWS Lambda is a bit difficult to set up if someone doesn't know how to code. It would be helpful to have a chatbot or resource that can guide users through the process, especially for those not proficient in coding. Setting up workflows that connect multiple AWS services can be challenging without guided support.

I've been using AWS Lambda for some months now.

There are no stability issues. AWS Lambda is very fast and secure, and I've not encountered any problems with it.

AWS Lambda's scalability depends on the number of users. It might not handle a high volume of requests efficiently, so it's better suited for small-scale operations where the number of users is limited.

The initial setup of AWS Lambda can be difficult, especially for those who do not know how to code. It took me about a week to set it up properly.

I am the only person maintaining the AWS Lambda setup.

I can't provide specific cost savings numbers, yet, due to the fact that AWS Lambda is trigger-based, it offers cost savings compared to instances that are always running.

AWS Lambda is cheaper compared to running an instance continuously. You only pay for what you use, making it cost-effective.

I would recommend AWS Lambda based on the use case. It's suitable for small applications where user access is limited. However, it's not ideal for large-scale platforms due to limitations in managing high traffic. 

I rate AWS Lambda a seven out of ten.