AWS Lambda Reviews

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.

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.

Public Cloud

Amazon Web Services (AWS)

AWS Lambda is primarily used for serverless architecture. I have used it for web applications, particularly during my time at a company where we developed an image processing tool. It helps to trigger events on a runtime basis. AWS Lambda also has various other use cases such as machine learning processes and handling big data tasks.

AWS Lambda's serverless architecture and event-driven programming are highly valuable. You pay only for the events triggered, optimizing costs. It is beneficial for deployment CI/CD tooling and for triggering pipelines for data processing. The cost model is pay-as-you-go, with a tier for free requests and computational time. Scalability and stability are also very efficient.

AWS Lambda could offer support for more programming languages beyond Python and Node.js. The process for creating Lambdas could be simplified for beginners with less expertise in AWS.

I have been working with AWS Lambda for almost eight years.

Deploying AWS Lambda is pretty quick if the process is known. It takes between 30 minutes to one hour to deploy once the code is ready.

AWS Lambda is very stable. Issues are typically related to the user’s code and can be debugged through logs such as CloudWatch.

AWS Lambda's auto-scaling features are crucial for operations and provide great scalability. I rate the scalability of AWS Lambda at eight out of ten.

The documentation for AWS Lambda is comprehensive and thorough, eliminating the need for frequent technical support. A 2000-page guide covers all aspects, from setup to advanced use.

Positive

The initial setup of AWS Lambda can be somewhat challenging for first-time users, primarily due to the learning curve involved. I would rate it a six on the ease scale.

AWS Lambda has a cost model that aligns with usage. There is an initial free tier, after which charges apply based on requests and compute time. Different architectures have distinct pricing models. Despite being a bit expensive initially, the overall cost effectiveness is notable.

AWS Lambda should be used when there is a need for event-driven programming on an as-needed basis. It might become expensive if used for continuous processes. In terms of the overall solution, I rate AWS Lambda at nine out of ten.

Public Cloud

Amazon Web Services (AWS)

I primarily use AWS Lambda for building serverless applications. I integrate it with services such as S3 and DynamoDB.

The capability of AWS Lambda to automatically scale thousands of requests simultaneously without requiring manual intervention is invaluable. 

Additionally, its integration with other AWS services such as Amazon S3 and DynamoDB has been very beneficial. The pay-as-you-go pricing model ensures that I only pay for the resources used, providing cost-effectiveness. 

The serverless computing feature eliminates the need to manage servers, provision, or scale.

AWS Lambda has a limitation where the execution time is capped at 15 minutes per task. Increasing this time would allow for handling heavier tasks more efficiently. 

While the documentation is satisfactory, beginners might encounter some challenges, so any improvements could be helpful.

I have been working with AWS Lambda for about six months.

AWS Lambda is quite stable, with a high level of availability and the ability to distribute functions across multiple availability zones. I'd rate it at nine out of ten in terms of stability.

AWS Lambda can automatically scale to handle increasing requests. For example, I used it in a personal project to integrate with a Simple Notification Service, which ensured I received real-time notifications during peak times without manual scaling.

I did not use a different solution before AWS Lambda.

The initial setup was moderately challenging, especially for beginners. Although the documentation is adequate, new users might find it not entirely straightforward and may face some challenges. It took me around five to ten minutes to deploy Lambda for the first time.

I deployed AWS Lambda by myself while learning about it and sought help from friends when necessary.

Lambda provides a cost-saving advantage because of its serverless design and automatic scaling without manual infrastructure needs. Its pay-as-you-go model means I only pay for what I use, which is financially beneficial for handling applications with fluctuating traffic levels.

AWS Lambda is cost-effective and flexible, particularly suitable for small applications. I am using the service within a free tier account, which influences the pricing experience.

I rate AWS Lambda overall at ten out of ten. New users should thoroughly read the documentation and start with small projects to understand the platform. It's important to be aware of AWS Lambda's limitations, take advantage of monitoring and debugging tools, and stay updated with new releases. Joining a community for learning and sharing is also recommended.

Public Cloud

We primarily use AWS Lambda for our APIs. Most of our transactions flow through the API, which is managed using API Gateway and AWS Lambda. Our development team works on the API.

We use AWS Lambda because it provides a solution for our needs without requiring us to manage our infrastructure. With the tool, we only pay for the resources we use. Additionally, it is straightforward to implement and integrates with other services like API Gateway.

The tool's serverless nature has had the most significant impact on our workflow. I find it particularly attractive because it eliminates the need for managing servers. In my previous experience, managing upgrades and updates was quite challenging. 

The solution's integration process with other AWS services was relatively easy. We primarily use AWS services such as EventBridge for scheduling processes and log management. 

We need to invest time in learning the tool's language variant. We have encountered instances of downtime as well. 

I have been using the product for a year. 

I rate the tool's stability an eight out of ten. 

The tool is scalable. 

The solution's technical support is good. 

Positive

AWS Lambda's deployment is very easy. 

The solution follows a pay-as-you-go licensing model, which results in cost savings. 

I rate the overall solution a nine out of ten. 

I have used AWS Lambda for deploying our mobile application to integrate it with services like S3 bucket, Bedrock, or SageMaker. It serves to connect our local systems to call servers for mobile application integration.

AWS Lambda operates as a serverless architecture, providing quick responses to events without requiring server management. It supports multiple runtimes like Python, Java, .NET, and Node.js. Additionally, the Lambda timeout service allows processes to run for up to fifteen minutes, enhancing time efficiency. AWS Lambda is useful for integrating with CI/CD pipelines and real-time scenarios.

AWS should provide more trial support for new users and customers. AWS should also provide basic access to perform some actions using different tools on the AWS platform. This would help customers understand the types of integration possible and the various tasks they can perform using AWS services.

I have used AWS Lambda for around one year.

AWS Lambda is very stable, providing good response times compared to other cloud services and requiring a stable network connection.

AWS Lambda is highly scalable. I rate its scalability ten out of ten. It can handle large datasets, and its integration with other AWS services enhances its scalability.

I was previously manually creating models and deploying them to AWS S3 cloud buckets. This process was more time-consuming and took two to four days for large datasets.

The initial setup of AWS Lambda is easy. I would rate the initial setup process ten out of ten. It takes around one to two hours to learn and understand the use cases.

Only one or two people are necessary for the deployment and maintenance of AWS Lambda, as it involves data engineering and deployment only.

AWS Lambda pricing is moderate. You only pay for the services when they are used, unlike EC2 services. Sometimes AWS Lambda seems expensive, rating around five out of ten for pricing.

I have worked with Azure AI Studio and found Azure to have better performance for generative tasks compared to AWS.

AWS Lambda rates ten out of ten. For new users, gaining trial support and understanding the capabilities of AWS's integration are advised. I would give the overall solution a rating of 10 out of 10.

Public Cloud

Amazon Web Services (AWS)

I have used AWS Lambda for simple messaging for SQS, creating a cron job, and delay messaging. Creating a cron job ensures emails are automatically sent to users at a specific time we set. For example, a mail would be sent automatically instead of manually to a user whose subscription is about to expire.

AWS Lambda functions have many versions. Sometimes, it takes a little time to load and run the commands in AWS Lambda. We can write anything as code, but the solution will not give proper error information. It is a little time-consuming to understand where the error came from.

I have been using AWS Lambda for one and a half years.

The solution's initial setup is easy. You can easily code in AWS Lambda if you have good coding experience in any coding language.

The solution is free of cost for the first year, and after that, it becomes expensive.

If you are using AWS Lambda for the first time, you need to know about AWS. You need good coding knowledge to work with AWS Lambda. If you want to code a node, you must know about node and node syntax. If we are using AWS Lambda with Python, you have to know about Python. It is easy to learn AWS Lambda if you have good coding knowledge.

Overall, I rate the solution a seven out of ten.

Public Cloud

Amazon Web Services (AWS)

We have one or two use cases for real-time file processing. We use the event triggers to detect file arrival.

AWS Lambda is serverless. It is quick to deploy. The event-driven execution model has improved the project efficiency because it is quick and easy to deploy. However, it also introduced a set of new problems. It is the industry traction ever since the network went fully API.

Since the tool is serverless and it is hosted in the cloud, we do not need an initial capital investment on servers. We can pay as we use. We have integrated the product with other AWS services. We use SNS and SQL. There is an offering from AWS for integrated solutions.

We face some problems with the event-driven execution model.

The tool is very stable. There are certain things that we have to do to support it, but once we cross the t's and dot the i’s, it works.

The initial setup seems to be very straightforward.

I will recommend the solution to others for serverless computing needs. It’s a quick delivery. We do not have to set up servers before we start deploying. Overall, I rate the product a nine out of ten.