AWS Lambda -Swiss knife of AWS Platform

AWS Lambda can be used in a number of different scenarios, it is easy to get started with, and can run with minimal operating costs. One of the reasons behind its popularity is the flexibility it comes for developers and cloud architects.

The service performs all the operational and administrative activities on your behalf, including capacity provisioning, monitoring fleet health, applying security patches to the underlying compute resources, deploying your code, running a web service front end, and monitoring and logging your code.

Lambda has “pay as you go (PAYG)” pricing model with a generous free tier, and it is one of the most appealing for cost savings. Lambda billing is based on used memory, number of requests and execution duration rounded up to the nearest 100 milliseconds. This is a huge leap comparing to the hourly based billing of EC2.

Lambda can instantly scale up to a large number of parallel executions, for which the limit is controlled by the Number of concurrent requests. Downscaling is handled simply by automatically terminating the Lambda function execution when do code finishes running.

Lambda comes with native support for a number of programming languages: Java, NodeJS and Python. There are additional open source frameworks for more supported languages, rapid development and deployments, like Serverless (formerly knows as JAWS).

Use of Lambda:

Operating serverless websites

This is one of the killer use cases to take advantage of the pricing model of Lambda, and S3 hosted static websites. Consider hosting the web frontend on S3, and accelerating content delivery with Cloudfrontcaching. The web frontend can send requests to Lambda functions via API Gateway HTTPS endpoints. Lambda can handle the application logic, and persist data to a fully managed database service (RDS for relational, or DynamoDB for non relational database).

You can easily build a Lambda function to check log files from Cloudtrail or Cloudwatch. Lambda can search in the logs looking for specific events or log entries as they occur and send out notifications viaSNS. You can also easily implement custom notification hooks to Slack, Zendesk, or other systems by calling their API endpoint within Lambda.
Automated backups and everyday tasks

Scheduled Lambda events are great for housekeeping within the AWS accounts. Creating backups, checking for idle resources, generating reports and other tasks which frequently occur can be implemented in no time using the boto3 Python libraries.

Processing uploaded S3 objects

By using S3 object event notifications, you can immediately start processing your files by Lambda, once they land in S3 buckets. Image thumbnail generation by Lambda is a great example for this use case, so the solution will be cost effective and you don’t need to worry about scaling up – Lambda will handle any load!

Filtering and transforming data on the fly

Because Lambda is highly scalable, it is great for transitioning data between S3, Redshift, Kinesis and database services, and filtering on the fly. You can easily place Lambda in between services to transform and load data as required.


Lambda comes with a number of “limitations”, which is good to keep in mind when architecting a solution.

There are some “hard limitations” for the runtime environment: the disk space is limited to 512 MB, memory can vary from 128 to 1536 MB and the execution timeout for a function is maximised in 5 minutes. Package constraints like size of deployment package and number of file descriptors are also defined as hard limits.

Similarly, there are “limitations” for the requests served by Lambda: request and response body payload size is maximised in 6 MB while event request body can be 128 KB.


If your Lambda function would be running for hours, it should rather go to Beanstalk or EC2 than Lambda.


Lambda is one of the versatile tools in the AWS ecosystem and can be used for many use cases. However, as controlling a powerful highly scalable service, things can go horribly wrong if functions not implemented well, so always make sure you have architected and tested thoroughly before publishing your functions live.