AWS Lambda Reviews & Insights

We use Lambdas as the primary deployment mechanism for our APIs. It provides flexible ways to deploy without worrying too much about infrastructure, server resilience, or load.

Lambda excels at event-driven, short-lived tasks, such as processing files or building simple APIs. However, it's less ideal for long-running, computationally intensive, or applications that rely on carrying the state between jobs. Cold starts and constant load can easily balloon the costs.

We utiliza AWS Lambda to execute jobs and connects async executions to the rest of AWS services. AWS Lambda is also used based on events triggered by other AWS services or our application. In a particular case example you can use Lambda to send a email to a customer after some event happens and your application call the Lambda run.

Well suited for asynchronous specific job execution, such as a follow up process after some event
Not suites for long running multi purpose job such as running a whole application or jobs that requires storing and passing info in memory

We use a lot of Lambda for all of our customized logic needs, we no longer deploy anything on EC2. It scales and costs beautifully, but it does require a different way of not only deploying, but also thinking about your software. It's limitations are its strengths if used a appropriately.

We use a lot of Lambda for all of our customized logic needs, we no longer deploy anything on EC2. It scales and costs beautifully, but it does require a different way of not only deploying, but also thinking about your software. It's limitations are its strengths if used a appropriately.

So, in a recent task, we developed an application where user-uploaded images were getting stored in S3, triggering AWS Lambda function to resize them for uniform display. AWS Lambda also handled CRUD operations, which allows us to focus solely on business logic without managing servers. This serverless approach has streamlined development and we continue to use it for various tasks.

AWS Lambda is well suited for event driven tasks that require automatic scaling and minimal infrastructure management such as Image processing (as in our case) and Backend API's. However, AWS Lambda is less appropriate for long running processes and tasks that require consistently low latency as cold starts can introduce latency.

We use AWS Lambda for a number of use-cases, such as an API endpoint behind AWS Cloudfront and also for data collection and evaluation before sending statistics on to our other internal systems. We have also used AWS Lambda to process messages on an SQS queue to allow a full serverless implementation of our microservices.

AWS Lambda is well suited for serverless microservices and can run independently of other services. AWS Lambda functions can be triggered by a number of external services, such as API calls, cron schedules, Cloudwatch event rules or via AWS Simple Notification Service (SNS) triggers. The service works well for API services however might be less suited to website hosting of systems like Wordpress.

AWS Lambda is perfect for small serverless workloads that enable cheap integrations with native AWS services. It is primarily used as a trigger from things like DynamoDB or SNS, which allows for very lightweight automations to occur. Not having to allocate or pay for a dedicated server to handle these micro workloads is ideal. The integration with many services gives AWS Lambda a lot of potential.

AWS Lambda is well suited for small/micro workloads that do not need to be running 24/7. It is a very cost efficient way to handle quick triggers or automations that integrate with AWS services. Things like triggering an email from a DynamoDB change or processing an incoming file into S3.
It is not suited for very complex and/or very long running jobs that need to be ready and active at all times.

We use AWS Lambda for running some periodic tasks. We've configured some triggers using AWS CloudWatch Alarms which trigger these Lambdas at certain intervals. This solves our business problem as we don't need to run a separate server for this neither it adds a load on any of the existing servers which are there to serve the requests. It only runs when there is a trigger and we only have to pay for the compute capacity we use.

Scenarios where AWS Lambda is well suited: 1. When we need to run a periodic task few times in a day or every hour, we may deploy it on AWS Lambda so it would not increase load on our server which is handling client requests and at the same time we don't have to pay for AWS Lambda when it is not running. So, overall we only pay for few function invocations. 2. When some compute intensive processing is to be done but the number of requests per unit of time fluctuates. For example, we had deployed an AWS Lambda for processing images into different sizes and storing them on AWS S3 once user uploads them. Now, this is something that may happen few times every hour on a particular day or may not happen even once on other days. To handle this kind of tasks AWS Lambda is a better choice as we don't have to pay for the idle time of the server and also we don't have to worry about scaling when the load is high. Scenarios where AWS Lambda is not appropriate to use: 1. When we expect a large request volume continuously on the server. 2. When we don't want latency even in case of concurrent requests.

I used AWS lambda in one of project which was developed by company I am currently in. My current company is AWS partner network accredited. While developing project, our company tries to make offer for AWS lambda as it is cost efficient compared to EC2 instance or any other compute service. Business problems are related to what clients want in a smaller budget. AWS lambda is considered as server-less compute service and helps to deliver solution much faster than any other computer service.

Compressing image while uploading it to S3 bucket can be easily done using lambda. While if your workload require lot of execution time or there is large amount of data to be processed, also workload where tweaking environment to suit workload, lambda can be less appropriate. Instead other computer service like EC2 and elastic beanstalk can be well suited for such task.

-AWS Lambda is being used for cron job with AWS Event bridge.
-AWS Lambda can be also be used as a serverless function with api gateway.

-AWS Lambda can be used for cron job with AWS EventBridge.
-When we use AWS Lambda use with API Gateway to only transport data to another service without any business logic.

[AWS Lambda] is being used in specific departments of the company as and when we require it because cost is involved depending upon usage. This can be integrated with multiple AWS tools like redshift, S3 and many other services that helps in easy processing of data. This has positively impacted our maintenance cost.

[AWS Lambda] is very well suited for the projects that doesn't have any infra but needs it where short running processes are required. But if your application need to run continuously than this might not be the very apt tool for you.