Everything you need to know to use AWS Lambda
for real-world applications
AWS Lambda is a serverless computing service provided by Amazon Web Services (AWS). Users of AWS Lambda create functions, self-contained applications written in one of the supported languages and runtimes, and upload them to AWS Lambda, which executes those functions in an efficient and flexible manner.
The Lambda functions can perform any kind of computing task, from serving web pages and processing streams of data to calling APIs and integrating with other AWS services.
The concept of “serverless” computing refers to not needing to maintain your own servers to run these functions. AWS Lambda is a fully managed service that takes care of all the infrastructure for you. And so “serverless” doesn’t mean that there are no servers involved: it just means that the servers, the operating systems, the network layer and the rest of the infrastructure have already been taken care of, so that you can focus on writing application code.
Each Lambda function runs in its own container. When a function is created, Lambda packages it into a new container and then executes that container on a multi-tenant cluster of machines managed by AWS. Before the functions start running, each function’s container is allocated its necessary RAM and CPU capacity. Once the functions finish running, the RAM allocated at the beginning is multiplied by the amount of time the function spent running. The customers then get charged based on the allocated memory and the amount of run time the function took to complete.
The entire infrastructure layer of AWS Lambda is managed by AWS. Customers don’t get much visibility into how the system operates, but they also don’t need to worry about updating the underlying machines, avoiding network contention, and so on—AWS takes care of this itself.
And since the service is fully managed, using AWS Lambda can save you time on operational tasks. When there is no infrastructure to maintain, you can spend more time working on the application code—even though this also means you give up the flexibility of operating your own infrastructure.
One of the distinctive architectural properties of AWS Lambda is that many instances of the same function, or of different functions from the same AWS account, can be executed concurrently. Moreover, the concurrency can vary according to the time of day or the day of the week, and such variation makes no difference to Lambda—you only get charged for the compute your functions use. This makes AWS Lambda a good fit for deploying highly scalable cloud computing solutions.
When building Serverless applications, AWS Lambda is one of the main candidates for running the application code. Typically, to complete a Serverless stack you’ll need:
Lambda fills the primary role of the compute service on AWS. It also integrates with many other AWS services and, together with API Gateway, DynamoDB and RDS, forms the basis for Serverless solutions for those using AWS. Lambda supports many of the most popular languages and runtimes, so it’s a good fit for a wide range of Serverless developers.
Due to Lambda’s architecture, it can deliver great benefits over traditional cloud computing setups for applications where:
Some of the most common use cases for AWS Lambda that fit these criteria are:
Scalable APIs. When building APIs using AWS Lambda, one execution of a Lambda function can serve a single HTTP request. Different parts of the API can be routed to different Lambda functions via Amazon API Gateway. AWS Lambda automatically scales individual functions according to the demand for them, so different parts of your API can scale differently according to current usage levels. This allows for cost-effective and flexible API setups.
Data processing. Lambda functions are optimized for event-based data processing. It is easy to integrate AWS Lambda with datasources like Amazon DynamoDB and trigger a Lambda function for specific kinds of data events. For example, you could employ Lambda to do some work every time an item in DynamoDB is created or updated, thus making it a good fit for things like notifications, counters and analytics.
With its event-driven model and flexibility, AWS Lambda is a great fit for automating various business tasks that don’t require an entire server at all times. This might include running scheduled jobs that perform cleanup in your infrastructure, processing data from forms submitted on your website, or moving data around between different datastores on demand.
As of now, AWS Lambda doesn’t support all programming languages, but it does support a number of the most popular languages and runtimes. This is the full list of what’s supported:
All these runtimes are maintained by AWS and are provided in an Amazon Linux or Amazon Linux 2 environment. For each of the supported languages, AWS provides an SDK that makes it easier for you to write your Lambda functions and integrate them with other AWS services.
A few additional runtimes are still in the pre-release stage. These runtimes are being developed as a part of AWS Labs and are not mentioned in the official documentation:
The C++ runtime also serves as an example for creating custom runtimes for AWS Lambda. See the AWS docs for the details of how to create a custom runtime if your language isn’t supported by default.
AWS Lambda has a few unique advantages over maintaining your own servers in the cloud. The main ones are:
Pay per use. In AWS Lambda, you pay only for the compute your functions use, plus any network traffic generated. For workloads that scale significantly according to time of day, this type of billing is generally more cost-effective.
Fully managed infrastructure. Now that your functions run on the managed AWS infrastructure, you don’t need to think about the underlying servers—AWS takes care of this for you. This can result in significant savings on operational tasks such as upgrading the operating system or managing the network layer.
Automatic scaling. AWS Lambda creates the instances of your function as they are requested. There is no pre-scaled pool, no scale levels to worry about, no settings to tune—and at the same time your functions are available whenever the load increases or decreases. You only pay for each function’s run time.
Tight integration with other AWS products. AWS Lambda integrates with services like DynamoDB, S3 and API Gateway, allowing you to build functionally complete applications within your Lambda functions.
While AWS Lambda has many advantages, there are a few things you should know before using it in production.
When a function is started in response to an event, there may be a small amount of latency between the event and when the function runs. If your function hasn’t been used in the last 15 minutes, the latency can be as high as 5-10 seconds, making it hard to rely on Lambda for latency-critical applications. There are ways to work around it, including a method we wrote about in our blog.
The Lambda functions have a few limits applied to them:
Execution time/run time. A Lambda function will time out after running for 15 minutes. There is no way to change this limit. If running your function typically takes more than 15 minutes, AWS Lambda might not be a good solution for your task.
Memory available to the function. The options for the amount of RAM available to the Lambda functions range from 128MB to 3,008MB with a 64MB step.
Code package size. The zipped Lambda code package should not exceed 50MB in size, and the unzipped version shouldn’t be larger than 250MB.
Concurrency. By default, the concurrent execution for all AWS Lambda functions within a single AWS account are limited to 1,000. (You can request a limit increase for this number by contacting AWS support.)
Any Lambda executions triggered above your concurrency limit will be throttled and will be forced to wait until other functions finish running.
Payload size. When using Amazon API Gateway to trigger Lambda functions in response to HTTP requests (i.e. when building a web application), the maximum payload size that API Gateway can handle is 10MB.
On AWS Lambda, you pay only for the used function runtime (plus any associated charges like network traffic). This can produce significant cost savings for certain usage patterns, for example, with cron jobs or other on-demand tasks. However, when the load for your application increases, the AWS Lambda cost increases proportionally and might end up being higher than the cost of similar infrastructure on AWS EC2 or other cloud providers.
While AWS Lambda allows adding custom runtimes, creating them can be a lot of work. So if the version of the programming language you are using isn’t supported on Lambda, you might be better off using AWS EC2 or a different cloud provider.
A number of AWS Lambda executions are included with the AWS Free Tier with every AWS account. Unlike some other services, the Lambda free tier isn’t limited to 12 months. Both existing and new accounts get 1 million AWS Lambda requests plus 400,000 GB-seconds per month — Lambda’s measure of function runtime and the memory allocated to a function.
Beyond the free tier the pricing for AWS Lambda is as follows:
Aspect
Pricing
Comment
Requests
$0.20 per 1M requests
The free tier includes 1M requests.
Function memory and run time
$0.0000166667 per GB-second
The free tier includes 400,000 GB-seconds.
Inbound network traffic to the Lambda function
Free
Outbound network traffic—within the same AWS region
$0.01/GB
Outbound network traffic—to other AWS regions
$0.02/GB
Outbound network traffic—to public internet
$0.09/GB
Lower pricing per GB applies starting at 10TB/month.
Amazon API Gateway
$3.50 per 1M requests
If you are using API Gateway with Lambda functions. Lower pricing from 333M requests per month and up.
For each execution, the total cost will be the sum of all applicable factors, including the cost per request, the memory and run time, and the network traffic.
Scheduled jobs. Imagine that you run cron jobs in your AWS infrastructure that perform database rollovers. The job runs every night and the average run time is 10 minutes. The function uses 1GB of memory while running. There is no outbound network traffic generated by the function as it connects to your RDS database in the same availability zone.
Total compute: 30 days x 600 GB-seconds (10 minutes) = 18,000 GB-seconds Total requests: 30 days x 1 request per day = 30 requests
This usage is within the AWS free tier, so you’ll be charged $0 for AWS Lambda. Note: You’ll still pay for the RDS usage according to the RDS price list.
HTTP API. Let’s assume that you’re building a web application based entirely on an AWS Lambda backend. Let’s also assume that you’re great at marketing, so after a few months you’ll have 10,000 users in the app every day on average.
Each user’s actions within the app will result in 100 API requests per day, again, on average. Your API runs in Lambda functions that use 512MB of memory, and serving each API request takes 1 second.
Total compute: 30 days x 10,000 users x 100 requests x 0.5GB RAM x 1 second = 15,000,000 GB-seconds Total requests: 30 days x 10,000 users x 100 requests = 30,000,000 requests
For the 30M requests you’ll pay 30 x $0.20/1M requests = $6/month on AWS Lambda.
All these requests go through Amazon API Gateway, so there for the 30M requests you’ll pay 30 x $3.50/1M requests = $105/month on API Gateway.
For the monthly 15M GB-seconds of compute on AWS Lambda you’ll pay 15M * $0.0000166667/GB-second ~= $250/month.
So the total cost of the API layer will be around $360/month with this load.
In this section we cover the steps needed to create, deploy and secure AWS Lambda functions. We cover two approaches: using the AWS console and API directly, and using the Serverless Framework.
If you wish, you can use the AWS Lambda console to create your first function. In the AWS console, choose Lambda:
Once in the Lambda management console, click Create Function:
Add a name for your new function and choose the desired runtime. After that, click “Create function” to confirm the settings:
That’s it: the function is created, and you can now work on the function code and deploy the function directly in the Lambda console.
We don’t recommend creating production Lambda functions via the management console for a two reasons:
We recommend getting started with AWS Lambda by using Serverless Framework. With the Serverless Framework, you can create Lambda functions using the tools you’re familiar with on your local machine and deploy to AWS in seconds. With this approach, your function’s code and configuration are located in the same Git repository which makes collaboration, change tracking and deployment of Lambda functions easier.
1. Install Serverless Framework on your machine:
$ npm install serverless -g
2. Create a new service:
$ serverless
3. Add the resources your function needs to the serverless.yml file. Check out the AWS Intro doc for an example of this file and the list of options you can configure there.
4. Add code to your service. See the Serverless AWS provider docs for specific steps you can follow to create your functions.
5. Deploy to AWS by running the deploy step:
$ serverless deploy
That’s it! Your function will be deployed and you’ll see the URL of the function’s endpoint in your console.
Once your Lambda functions are deployed, you most likely want to secure and monitor them in order to serve production traffic adequately.
Once your function is deployed, you can use CloudWatch to set up the monitoring for your Lambda applications. CloudWatch provides a few default metrics that are available to you as soon as the function is deployed. To access these, head to the Lambda interface in the AWS console and choose Functions → Monitoring. You can view the metrics directly in the Lambda interface or head to CloudWatch to see more details. See the Lambda metrics doc for exact steps to follow. Keep in mind that the CloudWatch pricing applies for these default metrics. CloudWatch allows setting up basic alerts on the metrics using CloudWatch Alarms.
Many of the functions you deploy on AWS Lambda are likely to require access to other services or your internal infrastructure. We provide a number of recommendations on how to secure these credentials in our article titled Secrets Management for AWS Powered Serverless Applications.
If you’ve deployed your function using Serverless Framework, your functions are already secured and monitored. You don’t need to do anything else. Just head to the Serverless Dashboard to see the up-to-date metrics and security events for your function.
Note: to take advantage of the metrics and the built-in secrets management mechanism you need to run serverless login before deploying your Serverless application.
