What is your primary use case for AWS Lambda?

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.

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

Essentially, I use AWS Lambda to run Python code. Usually, I set up triggers for other parts of AWS. It's really basic programming tasks.

We use AWS Lambda for various tasks, such as triggering reports, queueing calls for displays on our dashboard, and integrating with environmental variables for different outputs.

I use it for event-based retrieval. This is just to process for trigger purposes.

I have to send daily reports. We have many child accounts in AWS Organizations. We need reports on the cost of the accounts. I use AWS Lambda because we have to run the code without provisioning the servers. AWS Lambda is a serverless computing service.

AWS Lambda is a serverless computing service provided by AWS. It is allowed to run the course without the provisioning or managing server and paying only for the compute time consumed during execution.

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

We use it primarily for image resizing in batch and scheduled jobs. Additionally, one of our clients relies on Lambda for running a continuously active custom API, handling their ongoing API requests.

In our organization, we have a huge number of users using Lambda, approximately around 100. We are using Lambda based on several considerations like costs, and scalability and it provides us with high availability and scalability in our processes.

We had to deploy some serverless Node.js applications.

We are building a Twitter-like application in the boot camp. I have used Lamda for the integration of the post-confirmation page in the application. This will help you get your one-time password via mail. You can log in with the help of a post-confirmation page. We didn’t want to set up an instance specifically for confirmation. We used the Lambda function so that it goes back to sleep after pushing up.

As a platform team, we had to enable a light-weight ingestion platform ensuring the aspects of governance were baked into the platform and the business teams could accelerate their cloud adoption and only develop the business logic.

Our primary use case for AWS Lambda is a backend service module. Thanks to this solution, we do not need to worry about hardware or resource utilization. It saves us time. It saves us a lot of setup time. And, because it's our code, we will use Lambda. Lambda is the best AWS product we can use for running our code and it is very quick for the developers. All they have to do is commit their codes and, once we set up our code pipeline once after committing the code and building and deploying to our Lambda, the project will be up and running in the market. This setup is better than managing on EC2. We don't need to use EC2 in this case.

My primary use cases for AWS Lambda is collecting data from other systems through API, pre-calculations, and ETL.

AWS Lambda is good because if you chop up your application into small pieces and that is something that can be accomplished as a Lambda-based solution on the cloud, you will save on the cost of your applications. The reason Amazon AWS has provided AWS Lambda is to allow people to write small pieces of application tasks that will run on Amazon's own internal servers.

We have some services deployed that we need to consume in Lambda because it's a faster and better implementation. We have a model that microservice in the product, which we implement in AWS. For that reason, we use Lambda.

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.

AWS Lambda is mainly used for automation. To simplify, in AWS Lambda, I define a function, and I can invoke that function or feature whenever I want and on schedule. For example, if I have data to collect daily from different services, I schedule the AWS Lambda function to do that, and it does the job. That's one of the use cases of the tool. Another use case for AWS Lambda is when you have multiple servers running and need to shut down the servers at night. You can configure an AWS Lambda function that would shut down the servers every night on schedule. You can also use it as a backend and invoke it through API, so you deploy your backend from an AWS Lambda function, then link it with the API gateway, then you can invoke your function through the API.

There's a lot of use cases. The solution is used for immediate processing, so it's used everywhere. When data comes in, you process a Lambda function to tag it and categorize it. I've used Lambda functions to process inbound videos to make them smaller. I've used a Lambda function as a serverless backend for a customer-facing app, so I didn't have servers running.

It is used for capturing data through an API.

I am using AWS Lambda for building web and mobile applications.

We use AWS Lambda extensively for our maintenance work, for our products, and in our daily actions. We try to move some data based on alerts in certain situations and events. For example, if we are using queues based on the queue methods, we prefer to trigger different Lambdas for different functions (to enable some functionality across products). There are also a few Lambdas for audits. There are a few Lambdas for backups and many other use cases.

AWS Lambda is used for the whole surface, it does the backups, and schedules, and learns some of the core functionalities but it can depend on the topic or application. The solution is used to build APIs and many other functions

We have used Lambda for batch processing for specific schedules. We have used Lambda for different bot functions that run regularly, check certain things, and handle completes. In one of the implementations, we created Lambda using for the backend process. A majority of Lambda functions are used for backend processing, that is, for batch processes.

AWS Lambda is used to write developer codes in Python. It is a place we can run where we can run our codes.

I am using AWS Lambda to set up real-time notifications and backup transfers.

We are primarily using AWS Lambda for real-time API services. We use AWS Redshift to support our Lambda code functions. This solution is cloud-based.

We are using the latest version. We use the solution for the building of small applications.

My primary use case for this solution is usually for event-driven architecture. Since it's AWS, it's cloud-based.

Lambda can be used for automating AWS resources. It can also be used for automation outside of the cloud and for serverless applications. With Lambda, you can apply the code directly.

We use AWS Lambda for several things. We are using it, for instance, to do authentication of information from HTTP sites. We use it for alerting when monitoring the direct database infrastructure, and we use it for API transformation.

The product is primarily used to deploy code and provision a software solution to your clients when they don't have the time. You don't have to pay for the servers and the uptime.

AWS Lambda enables server-less architecture for seamless orchestration. We use the solution for various orchestrations. This is very useful when you would need to perform orchestrations of the different applications together. Many organisations are using this solution for web and mobile applications at scale.

The product serves as a function as a service, a serverless environment, you can say. It's a serverless environment, or, as some people call it, function as a service, FaaS. We have been using it as a mobile backend. We have a mobile frontend, a mobile application, which uses the AWS Lambda functions running in the cloud. It serves as an API backend for a mobile application that is running in the frontend.

It is useful in many scenarios. For example, in a microservices architecture where serverless functionality is required, one can use Lambda.

AWS Lambda has serverless programming, like Logic Apps from Azure. You just configure the run-time and then they start coding. It is event-driven. It started with my obtaining Salesforce. Salesforce is a low-code and non-code program and totally SAS. Everything starts from the event, from the trigger. You get the trigger and you work at the program. You have some other models, maybe faster or fancier models. But in my opinion, this kind of program is started by locating the system and identifying where the trigger and entry point of the program are. Then you get the full advantage of the program. You don't need to worry about any infrastructure. I think this is the future. Compared with the EC2, you don't have to pay anything if you don't run it. Otherwise, with EC2 when our client provisions the system and the instances, you always have to pay. There are other tremendous advantages, like flexibility. After you provision EC2 you can write something that does not totally follow the cloud convention. You use it to provision the container. With the program you need to have those 10 principles of cloud computing. Especially recently, within the past four or five years, I have gotten away from DevOps, or the software development life cycle. Even though I researched the product portfolio from DevOps and then the life cycle for DevOps, I try to position myself as an architect with hands-on experience. In my opinion, Lambda is very similar to Salesforce, which is the original for the SaaS platform and is an extremely low-code environment. With Microsoft and AWS you can say, "Okay. You can choose whatever language you need to make it even more flexible." Everything is the cloud. Lambda is a fully managed service. If you want to do it either as a private cloud or on-premise, I'm sure you can do that, too. But I don't know how to manage the pricing structure. But then you've lost the point of Lambda because if you do not use it, you do not pay. Again, I just want to emphasize, I'm not a Lambda expert. But, logically thinking, the big advantage of serverless programming for the customer is that you just use it and pay. Pay and go. You don't need to provision anything. All my experience with AWS Azure is on the public cloud. We do not get too deep. In IBM we do. When we do sales training we always get the private cloud on-premise. There are many reasons for this. One reason is that IBM lost the battle for the public cloud so we get into it much deeper. We go to the enterprise and we can deploy programs to your data center and offices. But for the tech data for AWS and Azure, we are all using the public cloud as a showcase when we talk to the customer and to the retailer.

We have some APIs and we use some mechanisms to process these APIs. Normally, some APIs need to be hosted by some servers. However, with this product, we can compute everything serverless.

We are a startup, and we are doing faster and cheaper storage for IT. We are going to offer our storage services in about two months, and we are starting with AWS. We do lossless compression using microservices. We do the compute in a lossless compression way similar to gzip, WinZip, or PKZIP, except that we are giving a discount to customers. The product that we are developing is not yet in the market. We are doing alpha testing for select customers who are using AWS. The biggest advantage is that you get faster storage without doing a forklift upgrade, and you get 35% cheaper storage. So, you get 2X faster storage with a 35% to 50% lower monthly bill. We use AWS Lambda to encode and decode data. I work on the encode and decode software. I am working with a cloud developer. He works on the Lambda deliverable and wraps my C code with his C++ wrappers. They get bundled together with no JS stuff.

Our primary use case is for our financial institutions. We use it for many customers that we work with. We develop solutions for our customers and run them on AWS. We wanted to build the solution on the public cloud and out of all the public cloud providers, AWS is the best. It has a rich set of services.

Primarily, I work with all my clients to provide them with solutions. We are a service company, so we work with clients to define and build applications that resolve their need for automation issues. I create the solutions, and then there is a delivery team of mine which works to deliver that solution to the client.

We have only used it for a few services. It's still in POC mode. We haven't done any production on it currently.

We use this solution for a mobile banking application with the ability to scale as per demand and to focus on core business functions rather than the platform.

Our primary use case for Lambda is for serverless computing in our project. We have an environment in AWS with Lambda, EC2, S3, SQS, RDS, and Redshift. Our Lambda function is triggered whenever a new object is put into S3. It will validate, extract data from S3 then input metadata into MySQL and put the main data into Redshift as the data warehouse. An SQS message will be created so our Application in EC2 is alerted that there is new data to have processed.

I back up my MongoDB, that database has user data. The performance of AWS Lambda has been fine.