As you may already know, AWS Lambda is an event driven compute service. Great, but what does that mean? Well, Lambda is designed to run a function in response to an event. Essentially, you upload your code to Lambda, and Lambda runs your code for you—when it’s triggered.
Currently, there are three ways of running code in the AWS cloud: AWS EC2, AWS ECS, and AWS Elastic Beanstalk. EC2 is essentially Infrastructure as a Service (IaaS) while ECS gives you load balancing and high availabilty of EC2 instances. Elastic Beanstalk gives you easy access to load balancing, IaaS, and high availability too—but only for web applications. AWS Lambda sets itself apart from these other three services by charging you only for the compute time that you use.
OK, then what does Lambda do when your code isn’t running? Nothing, and that’s the benefit. Lambda only charges you for the time that your code is running (and also by the number of requests). So, unlike hosting your code on an EC2 instance where you would be billed hourly just to keep your application ready and waiting, Lambda only charges for the compute time.
Behind the scenes, Lambda is still running your application on an EC2 instance, but Lambda is managing those resources for you, which is another big benefit—no resource management needed to deploy your code. Even better, the Lambda infrastructure is highly available. So right away, your Lambda function is highly available, and you don’t have to manage the infrastructure whatsoever. Amazing, right?
Let’s take a look at how much running a Lambda function might cost. The first step to pricing a Lambda function is figuring out how much memory (MB) you want to allocate to your function. Memory starts at 128 MB and goes up to 1,536 MB. Let’s follow the first pricing example on the Lambda pricing page.
Let’s assume our Lambda function uses 256MB of memory, we call our function 5 million times, and each call lasts 500 ms:
Total compute (seconds) = 5M * (0.5s) = 2,500,000 seconds
Total compute (GB-s) = 2,500,000 * (256MB / 1024) = 625,000 GB-s
Total compute – Free tier compute = Billable compute GB-s = 625,000 GB-s – 400,000 free tier GB-s = 225,000 GB-s
Compute charges for 5 million calls lasting 500 ms each using 256 MB of memory = 225,000 * $0.00001667 = $3.75
Lambda charges $0.20 per 1 million requests, and the first 1 million requests are free.
Billable requests = 5,000,000 requests – 1,000,000 free tier requests = 4,000,000 billable requests
Request charges = 4M * ($0.20/M) = $0.80
Total cost = $3.75 + $0.80 = $4.55
Our example Lambda function ran for 2.5 million total seconds, and we were charged $4.55 to run it. Luckily, Amazon doesn’t have a $5 minimum to charge your credit card because otherwise we would have to send them $4.55 in the mail.
So, what kind of events can trigger a Lambda function? Of course, you can trigger Lambda functions with your own custom events using the AWS SDK, and also, as you would expect, Lambda plays nice with other AWS services. Here are a few of the AWS services that offer easy Lambda integration:
- • S3—basically any type of S3 operation (put, post, delete, copy, etc.)
- • SNS—publishing a message to an SNS topic
- • DynamoDB—table updates
- • Kinesis—record processing on streams
- • Cognito—user data synchronization events
- • API Gateway—uses a web API to act as a proxy to a Lambda function
These are all powerful integrations, but I want to draw attention to this last one–the API Gateway. AWS API Gateway acts as a thin layer of abstraction for your data and business logic. API Gateway also allows you to access a Lambda function through a web API endpoint, which means you have all the features available to a web API—query parameters, request headers, request bodies, etc. All of these features can act as inputs to the Lambda function.
Wait a second! So, using API Gateway gives me a highly available web API to my website or application with no infrastructure management, and I only pay for compute time? Wow.
As if this wasn’t enough, another notable feature is that API Gateway uses the HTTP method (GET, POST, etc.) to route to different Lambda functions. Associating an HTTP method to a particular Lambda function gives you the ability deploy changes to your web API on a per route and per method basis. This gives you the power to only update the POST function of a user account controller, for example. Being able to do these “micro-deployments” gives a development team lots of agility.
There’s no doubt that Lambda is extremely powerful, and I can’t wait to see where this takes us.
As with any new technology, there are a few limitations worth mentioning (and an exhaustive list of limitations is linked at the end of the article):
- • Lambda language support is limited to Node.js and Java 8
- • 60 second maximum execution duration per request
- • 1,024 maximum processes and threads per Lambda function
- • 50 MB maximum Lambda function deployment package size (.zip/.jar file)
Here are a few resources for more information on AWS Lambda and how to get started: