AWS Lambda

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 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.

I would recommend using AWS Lambda when you have one-off tasks that can be accomplished with a single function and do not require a persistent, constantly running compute resource. Some example use cases include file or image processing, data analytics (you might have DynamoDB stream updates to AWS Lambda for processing), in conjunction with API Gateway as a backend.
I would not recommend using AWS Lambda when your Lambda function has potentially long-running, asynchronous calls involved (e.g., calling out to a service hosted in another cloud platform). This can drive up execution time and, in turn, cost. While Lambda layers allow you to share code between Lambda functions, I would not recommend AWS Lambda for cases where there are high degrees of interdependence between the Lambdas. I think that Lambdas work better when considered isolated.

[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.

Process large datasets where bigger files are broken into smaller ones. Executing step functions. Submitting requests for Sagemaker pipeline. Submitting queries to Redshift data API. Managing dynamodb records (read-write).

I believe the main concern is about costs. If your function calls generates profit, no problem with the amount, as more [is] better. But if this is not the case and your user case trends to grow without associate profit, maybe by provisioning dedicated resources (EC2 instances for example) to run your functions will hurt less in your wallet.

Well suited:
1. when we need to worry about time to market and we don’t have infra defined.

Not suited:
1. Not suited for Business Client transactions as its server are located out of Switzerland and hence country laws are different

Working with Web and mobile apps well suited for Lambda. It provides a clear support path and improvement. Also it helps to reduce cost and accelerate speed of reaction on changes.

A sess appropriate scenario would be when CIO push to implement new technology and services without clear understanding of the results and project needs.

A great example of using AWS Lambda is when your application needs to be able to render images for the user and have those images be resized and optimized on load. Using AWS Lambda you can create endpoints with a minimal amount of code that allows your applications to request the images and use query parameters to declare the height and width etc.

AWS Lambda is most suited as a Serverless methodology. When you do not want to handle the software and only want to work on logic and code development, AWS Lambda is the best option. You can also trigger AWS Lambda from many AWS services like when a new row is added into DynamoDB or when a new file is uploaded to S3 or also when you want to execute Lambda once a day or at a specific intervals(cron jobs).

I would definitely recommend using Lambda for short-running, event-triggered processes that are dedicated to a single function. This could be for one-off processing or intermediate tasks between other resources like objects stored in buckets and queues for processing those objects. Also, since Lambda executions can be scheduled, processes that need to happen on regular intervals can be implemented with Lambda as well.
I would not recommend using Lambda for anything that needs to run longer than a few seconds. Long running processes like ETL jobs or intensive computations may be better suited for step functions, batch jobs, or even a server based approach.

The main area in my point of view is the automation reduction of costs. You can program and use Lambda to execute several tasks based in several types of events like logs, schedules, and output from other AWS tools. With the AWS API, you can do almost anything you want and your function will use only the needed resource (memory, cpu) so it is optimized.

I think it works really well for managing workloads without the need to manage the underneath infrastructure.

AWS Lambda is a great way to deploy smaller-scale data synchronization jobs and other "housekeeping" routines that don't require preservation of state. We use it to build API gateway tools used by our larger applications (many of which are hosted on AWS EC2 instances) and it's a perfect fit.

If you have complicated workflows that run a long time, or require state to be saved between function calls, AWS Lambda is probably not the right choice for a serverless solution.

AWS Lambda is very well suited to the scenario in which I use it; namely, Alexa skills. To respond to an Alexa skill request, it would be inefficient to spin up a server. For applications that run continuously and are not event-driven, AWS Lambda is not well-suited.

AWS Lambda is well suited for batch scripts, and API development.

AWS Lambda is well suited in cases where the entire stack is on AWS. It doesn't make sense to use lambda when you have services with other cloud providers.

I know a lot of our developers use this personally to develop Alexa skills. The best use case for us is building simple rest API's with minimal effort and overhead. It is easy to use and scalable. You can also through a lot of load against it very quickly with little to no performance issues that I have seen. Also, it is very well suited in environments where developers have language freedoms.

AWS Lambda is best for short-lived applications/codes. Configure AWS Lambda to act based on the events that are produced on certain services. It works. We used it to move the RDS snapshot from WEST to EAST and EAST to WEST whenever the RDS automatic backups are done. It helps in other scenarios, like when application teams don't have a server or don't have a place to run a job on a regular basis. Then we can leverage this AWS Lambda to run the code against the database. As I mentioned, this is not suited for long-lived applications.

AWS Lambda is great for atomic micro services and being leveraged as a conduit for other Amazon services. It's great for a quick way to innovate other resources that you already have on the platform. It marries well with the ecosystem and allows for easy deployments and updates to the program based on the tools.

For its price, flexibility, and integration with other tools, AWS Lambda is the most popular serverless functions platform for a reason. In my opinion, it's best used as the backing behind some higher abstraction like Serverless or even Netlify Functions, but from what I've seen, it would be a great option even if used directly. In generall, serverless architecture works well for stateless applications, API aggregation, event-driven processes, and where the scale/demand is unpredictable.

If you're not afraid to get your hands dirty in wiring things up yourselves or you can use AWS' own abstractions like Amplify or SAM, then Lambdas and their surrounding platform pairings (Like SQS, API gateway) are great tools that can help you create a backend or infrastructure for a relatively low cost. If you don't find yourself in that camp, but you know your way around full-stack JavaScript frameworks and tooling, you may be better served with a higher level abstraction like what Zeit Now or Netlify offers.

AWS Lambda is great for distributed systems in which scaling of independent components is critical and you don’t want to manage the overhead of needing to maintain a fleet of virtual machines.

AWS Lambda is best used in environments where you need to perform specific actions in response to an event happening. This reduces cost and will only be billed for the CPU time it takes to run the function. For long-running tasks, AWS Lambda is not good because of the timeouts set by the function.

Anywhere you have an isolated responsibility of your code, AWS Lambdas are well suited for. If you have something that has to perform an intensive calculation - it makes sense to offload that to something like an AWS Lambda. Or something that needs to send data and integrate with another service, it can be a good place for that interface/job to live.

It can be possible to build a larger architecture using a series of AWS Lambdas, but it could become hard to maintain and be hard to understand very quickly.