AWS Lambda functions are a way to run code without provisioning or managing your own servers. Rather than running an always-online application, they run a single function in the cloud, which can be triggered in response to API events or other events in your AWS account.
How Do You Use Lambda Functions?
Lambda is a compute service, plain and simple, and it’s probably the simplest of them all. Rather than renting out a server with a specific number of cores and amount of RAM, you simply upload your code, and run the function. Usually, you won’t run it manually; instead, you’ll set it to run based on actions from other AWS services. For example, running a function to resize images whenever a new file is placed into S3 (a method used by the Seattle Times to great effect), or querying a database whenever a request is sent to API Gateway.
Computer resources are automatically given to the running function, and it will use as much memory as it needs for as long as the task continues. You’re simply billed based on the number of function invocations and the amount of memory each invocation uses.
This makes Lambda highly flexible for use as a backend. Traditional applications are mostly monolithic; you have one server (or a fleet of them) running your application. You may have separate servers for web hosting, databases, and other things, but a lot of applications are built this way—one big executable, many moving parts.
With everything so interconnected, and without strict order, this can get messy really quick. It’s also harder to scale effectively; if you find that one part of your application is the bottleneck, it may be hard to eliminate without scaling the entire application and greatly increasing your AWS bill in the process.
Instead, you can cut the bottleneck out entirely, and move it to Lambda. After all, Lambda doesn’t care if you run your function ten times a month, or ten million times a month.
This allows Lambda to be highly efficient, and, when implemented properly, can save you a lot of money. Adam Pash from Postlight was able to drop their monthly AWS bill from over $10,000 to just $370, just by switching to Lambda and optimizing memory usage.
While it’s not going to be this drastic or easy for every application, Lambda has some great benefits that make it a crucial part of AWS’s lineup of compute services.
For non-mission critical applications, it also presents a very cheap way to run an application that needs to make API requests. For example, you could serve a static web app without any servers at all, by storing your website in S3, serving it through CloudFront, and connecting to a Lambda backend through API Gateway that communicates with a DynamoDB table.
How Much Do They Cost?
Like most of AWS, Lambda’s pricing is very much “pay-as-you-go” model. Rather than paying a flat price for the whole server, you will only pay for the exact amount of resources your application is using—you’re never paying for idle time, not even a second of it. This obviously makes Lambda quite efficient, on top of being able to eliminate bottlenecks in monolithic applications.
Lambda’s charges are as follows, for
- $0.20 per 1M requests
- $0.000016667 for every GB-second
The first charge makes the most sense; if you have 100 million requests in a month, you’ll be paying a $20 fee for that.
The second charge is a lot more confusing. Basically, you’re charged based on the memory usage of your functions, since that’s usually the limiting factor for AWS. If your function boots up, allocates 1024 MB of RAM, and runs for a single second, you’ll be charged $0.000001667 for that. That’s a pretty low number, but across 1M requests, it’s $1.667.
Naturally, you’ll want to choose a runtime that’s memory efficient. NodeJS is commonly used, as it’s fairly lightweight compared to runtimes like Java. However, Java can be faster for tasks that take longer to complete, and since you don’t pay for time spent initializing the runtime (i.e., a “cold start”), it’s not always as bad as it looks on paper.
It’s all a balancing game, but you want to look to minimize two things—memory usage, and time spent running the function. There’s no explicit charge for longer running functions, but you’re charged by the second, per GB, so a 256 MB function that runs for two seconds will cost you the same as a 512 MB function that runs for one.
Sign in to your AWS account and head over to the Lambda Management Console.
There are two primary tabs here. The first is for Applications; Lambda applications manage multiple functions, and are specifically deployed automatically using a SAM template. This allows them to be tracked on Git and version managed, which helps immensely when working with hundreds of functions.
The second tab is for individual functions. If you’re just making a standalone Lambda function, or are just messing around to get the feel for it, you should start here and create a function from scratch, as it’s much more simpler.
You can create a new function from the “Functions” tab:
You have a few options here. You can create the function entirely from scratch, which will initialize the function with nothing more than a hello world. You can also choose to use a prebuilt template, or even download a function from the Lambda serverless application repository.
If you’re creating it by yourself, you’ll have to choose a runtime. Lambda has a few to choose from by default:
You can also bring your own runtime to run whatever language you want.
Once it’s created, you can edit it from the function’s page. The standard NodeJS function exports a handler, which is called whenever the function responds to events.
We recommend using AWS’s Cloud9 IDE for working with Lambda functions. It’s a web-based IDE built on the same editor used on the default function editor, but with the added benefit of much easier testing and debugging.
If you want to have your function respond to API requests, the easiest method to set that up is with API Gateway. You can create a new API and have it route certain endpoints directly to a specific Lambda function, which will handle the request and return a response.
Otherwise, you can specify a trigger in the “Designer” at the top, such as whenever an object is placed in a particular S3 bucket. You can also specify a destination that the results get sent to, such as an SQS queue, SNS topic, or other Lambda function.
The Lambda function will run with the privileges given to it by the execution role that was created for it. If you’re accessing other AWS resources, you’ll need to give it permission to do so in the IAM Management Console.