AWS Lambda Information Reviews & Insights

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

Process terabytes of data broken down into small files of 70MB each. Our Lambdas spin an instance for each file and process it within 30 seconds. This way the entire batch of 320,000 files is finished in about 2 hours.

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

At my current place of work as well as for personal projects AWS Lamba is currently used for many different projects. A few examples are "image resizers", "data processing" and invalidating cache from a 3rd party webhook. It allows for quick, easy, and inexpensive setup and maintenance especially using 3rd party libraries like "Serverless".

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 widely used in our organization by a number of development teams. It is used in both one-off tasks and coordinated workflows. My team is responsible for infrastructure management, and there are many use cases for which we have opted to use AWS Lambda. AWS Lambda is often a good choice for us when we do not need a standing compute resource.

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 currently being used to respond to events generated within our AWS infrastructure (instances terminated/created) to perform specific actions. Because AWS Lambda is not constantly running, and only in response to events, we're able to save money by only paying for the amount of CPU resources needed when functions are run.

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.

We use AWS Lambda to host our micro-services that don't need to worry about too much infrastructure. Lambdas are great at running pieces of code that don't necessarily have to belong in the main infrastructure. We have a few different lambdas that each have single responsibilities, such as creating and uploading files to S3, and running complex calculations.

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.

I used AWS Lambda to interact with the API Gateway and DynamoDB. It was used to retrieve and push data into the database. As a part of the project, it helped us a lot making the task quicker, simpler and more convenient.

Anywhere where you just pay for what you use. AWS Lambda is the best in those areas. As it is fast and scalable it can provide an excellent alternative for server backend making the whole application serverless. You just don't need the server running every time. Just run it when you need it.

We are building a system for log and data processing in AWS Lambda, S3, DynamoDB and Redshift. Data is collected and uploaded to S3 and a Lambda will be invoked to do the main processing function. It extracts and analyzes data, then puts metadata into DynamoDB and main data into Redshift. With Lambda, we are able to spin up thousands of the instances to process input S3 objects in a very short time and then remove them when finished, all with the same pattern and high performance. It saves on our development cost as implementing and deploying AWS Lambda is quite simple compared with EC2 or other services.

AWS Lambda is suitable when we need to process data on demand and require a large number of instances. AWS Lambda is not too complex, and it will fit well in case we need an authentication function to verify user login information, process input data in S3, retrieve and execute message SQS or triggered on demand by the user. AWS Lambda would not fit if we needed to constantly receive user requests, run background processes or needed to access VM underline.

We are already using other AWS services like EC2, RDS, S3, etc. and they are super reliable and easy to maintain. We use AWS Lambda to host our serverless function which is responsible for authentication. We have also started moving our microservices from EC2 to Lambda.

Product engineers can innovate rapidly as serverless architecture has alleviated the problems of system engineering. Thus, you spend less time on operational issues and it makes devops life easier.