AWS Lambda Reviews

We're using AWS Lambda to trigger jobs and receive SQS messages. We're also using the tool as a single unit where you have computing, storage, and network.

AWS Lambda has improved my company through its usage in a distributed system, particularly event-driven architecture. When an event is passed to AWS Lambda from Amazon SQS asynchronously, the tool can call an ETL job, and it can trigger that job, and that job can trigger an AWS Lambda function, which can then send a message to the queue to complete the entire use case.

The most valuable feature of AWS Lambda is that you can trigger and run jobs instantly, and after you complete the job, that function is either destroyed or stopped.

The feature to attach external storage, such as an S3 or elastic storage, must be added to AWS Lambda. This is its area for improvement.

I've been using AWS Lambda for two years.

Stability-wise, AWS Lambda is an eight out of ten.

Scalability-wise, AWS Lambda is an eight out of ten.

I have not encountered any problems with AWS Lambda, so I didn't need to contact its technical support team.

We didn't use a different solution apart from AWS Lambda.

The initial setup for AWS Lambda was straightforward.

I saw ROI from AWS Lambda.

Price-wise, AWS Lambda is a five out of ten.

One person is enough for maintenance for a cloud-based tool, such as AWS Lambda.

I cannot share the number of AWS Lambda direct users in my company, as that figure is confidential.

My advice to others looking into implementing the tool is that it's easy to use as long as you know the basics.

AWS Lambda has good features, so I'm giving it an eight out of ten.

Our primary use case for the solution is automation. There was a scenario where we tried to reduce cost in our environment using Instance Scheduler, where the AWS Lambda function was also used during that process. So we use it for automation and tagging.

The solution has helped our organization with cost optimization. So we have used AWS Lambda for consolidated billing.

The automation feature is valuable.

The runtime for the solution can be improved.

We have been using the solution for approximately two years.

The solution is stable. I rate it a nine out of ten.

The solution is scalable, and I rate it a ten out of ten.

The initial setup was straightforward.

The solution is very expensive.

I rate the solution a nine out of ten.

Our company uses the solution as a function engine to deploy triggered events for customers. We have a team of twelve developers and our deployments have 1,000 to 2,000 customers during peak times. 

The solution runs on the latest cloud technology so it is easy to deploy cloud-native projects. 

The solution is very useful for managing triggered events. 

It can be a bit difficult to switch between accounts when creating services for customers. 

I have been using the solution for one year. 

The solution is cloud-based so of course it is stable as long as the cloud is available. 

The solution is scalable. 

We have not needed technical support. We utilize available documents that contain content for solving any issues. 

The solution is serverless computing so there is no setup. You just launch the service, write your code, and run it. 

The solution is part of the AWS subscription model that is paid annually. There is no charge for monthly usage. 

There are many calculation criteria for AWS services or licenses. It is difficult to say whether the solution reasonably priced or expensive. Each company weighs price against the benefits and efficiencies provided by the solution. 

AWS is the pioneer of cloud computing and they lead the industry in innovations. Other providers follow in AWS' footsteps to implement similar features and service levels. 

AWS has differentiated the use cases for serverless computing. Lambda is used for basic capabilities like triggered events and Fargate is used for extended capabilities. 

I started using Lambda for a specific use case and I continue to use Lambda and Fargate for use cases as recommended by AWS. 

I definitely recommend the solution and rate it a ten out of ten. 

AWS Lambda's most valuable feature is serverless architecture.

There are sometimes issues following an update.

I've been using AWS Lambda for about five years. 

AWS Lambda is stable.

AWS Lambda is scalable.

The initial setup was straightforward and took only a few minutes.

AWS Lambda's cloud version isn't expensive, and I'd rate its pricing as five out of five.

I would rate AWS Lambda ten out of ten.

We use AWS Lambda for jobs that we just want to offload to a cloud function. We are an educational institution, and if I want to upload an exam I generated for all my students, then I just write the script on AWS Lambda. That is, we use it for independent jobs that we can offload on their own.

I like the pay-for-what-you-use feature. This is the main reason why we use AWS Lambda. I don't have to manage servers; I just have to configure Lambda and expose it to an API gateway.

AWS Lambda's cold start needs to be improved. It has to warm up first, and so, the response time is slower.

Another challenge I've noticed is that there is a limit to the environment variables such as the 4 KB limit. Although, the advice is to use parameters or other things to store the details when the limit has exceeded the data, this adds additional intensity to the application. If the size limits for environment variables can be revealed, it would be helpful. Even if we have to pay for it, at least we would know that we are not dealing with latency. So, I would like to see the size of the environment variables increased.

I've been using AWS Lambda for one year.

It's very stable.

AWS Lambda is scalable; I don't need to worry about it. At present, we have less than 10 people using this solution.

The initial setup is straightforward. It can be done on the console, and you can use the infrastructure as the code.

The deployment time can vary from 10 minutes to an hour depending on your needs and how comfortable you are with AWS Lambda.

AWS Lambda now supports multiple languages, but find out if the language you want to use to write your jobs is supported by it. If it is supported, then you are good to go.

Because AWS Lambda is scalable and does what it's meant to do, I would rate it at nine on a scale from one to ten.

Usually, it is for small transactions. They're very atomic transactions. For example, we built a solution for an ad platform where an electronic ad runs for about 15 seconds a piece. Every time one of the ads runs, we have to record where did it run, how long did it run for, who was in the room, and how many people. There is a bunch of data around that. We typically send that transaction through an Amazon Kinesis pipe into a Lambda function, and then Lambda will take it and store it in S3 or target it to Redshift or put it in some kind of data store. That's one example of what we would use it for. That's a typical model for Lambda. 

It is serverless and scalable. It can scale infinitely. You don't have to worry about the size of the servers that you're pre-allocating. You don't have to build server scale-out models. Auto scale and other similar features are just inherent in Lambda. So, for atomic and fairly non-persistent transactional units of work, Lambda works very well.

My engineers work with it on a daily basis. I just don't have enough depth of knowledge about what kinds of edge cases they may have tried and found lacking. There may be some issues with some language support at one point or another because we couldn't get the underlying libraries in there. A lot of what we do is either in JavaScript, Python, or some of the non-compiled languages. I'm not sure if we've ever tried building a C# solution, for instance, in Lambda or a Java solution in Lambda. It doesn't mean those aren't its capabilities. I would rather refer to my engineers for where the boundaries are.

It has probably been five or six years since we've been migrating functionality from EC2 instances to Lambda.

Its stability is really good, and it is also highly available. The stability is inherent, but it also naturally gives you a high availability model because you don't have to have multiple EC2 instances running in, for instance, different regions. It is baked into the model. So, you can allow for inter-region Lambda functionality. It all becomes very highly available across Amazon's footprint.

It is endlessly scalable. In terms of its users, Lambda is typically baked into the middle of an application somewhere. Our ad platform solution is a fully-automated IoT solution. So, there are no people involved. The whole thing is automated from end to end. So, sometimes people don't even come into the equation.

We probably do or have dealt with their support, but that would be at the end engineer level. It is not something to which I would have much visibility. 

It is straightforward in my understanding. From the engineering perspective, I haven't gotten feedback that it is at all burdensome.

You're not paying for a server if you're not using it, which is another reason I like it. So, you're not paying if you're not using it. It scales, and you're charged based on usage. It all depends on the use case. Some can be extremely inexpensive if you have very low volume transaction rates. That way, you don't have to fire up and absorb the cost of the servers just sitting there waiting for a transaction to come through. You're only paying when you use it. So, depending upon the use model, Lambda could be highly efficient relative to an EC2 solution. You don't have to have things reallocated.

Understanding what your use model looks like is the key. All these cloud providers have so many different ways of implementing a solution that you really have to understand the near-term and long-term picture for that solution. What does it look like? When you're first building it, there might be a more expedited way to get it off the ground, but that may not scale properly, or your cost can get out of control. So, it is very important to align the right set of features within an AWS or Azure environment for not just getting the initial MVP built but also making sure that you're building it in a way that allows scaling and optimization of the cost model over time as the application scales. There's no one answer. The way you build the solution in the cloud is very dependent upon what the use case is.

From my perspective, not being at the engineering level, I would give it a nine out of ten. There is always room for improvement, but it has been a terrific advance over what was previously available just having to build everything in EC2.

I have found this solution very useful. By using Lambda, we can use Python code and the Boto3 solution. 

The triggering feature is also valuable. For example, if we are using Kafka, we need to be aware that the language comes in Kafka when we write in Python, and that we are transforming our data into the meaningful server and dumping that into the S3 bucket.

I would like to see a find and replace function as part of Lambda's future releases. Currently, if we want to replace a code, we copy the code into Notepad, then find and replace it, and then copy that to Lambda. This would improve the editing function of the product.

Lambda would benefit from a debugging feature as well. For example, if you want to debug code running in Python and deployed in Lambda, it would be beneficial to have a debugging feature.

I have been working with AWS Lambda for one year.

The solution is stable. There are times when we do need to refresh when we make changes and deploy them. This seldom occurs.

We have five developers using Lambda. 

Technical support can take a long time to respond. I would rate their service a seven out of 10.

Neutral

The initial setup of AWS Lambda is simple.

I would rate this solution a seven out of ten overall. 

We have a DNS as a service and NAS as a service, which integrates, and we use Lambda functions there. We have a lot of applications that we use Lambda for. 

This solution is cloud-based. 

Some of the most valuable features are that it's easy to install and use. The performance is also good. 

Lambda could be improved in the sense that some of the things done with Lambda function take some time. So the performance could be better and faster. 

I have been using Lambda for many years. 

This solution is stable. 

This solution is scalable. 

I think, eventually, we will increase our usage. We need to move some of our services to Lambda. 

Amazon's technical support is good. 

Before implementing Lambda, we had legacy types of solutions. 

The installation could be faster, but I believe it's a straightforward process. I manage a team that handles the installation, so I can't comment on the specifics of the installation process. Within the team that handles maintenance and deployment, we have two engineers. 

We implemented this solution through an in-house team. 

We don't need to pay for licensing to use Lambda. 

I rate AWS Lambda an eight out of ten. I would recommend AWS Lambda to others. We provide a lot of services, part of which is that we write Lambda functions.