AWS Lambda functions are a way to execute code without provisioning or managing your own servers. Rather than running an application that is still online, they perform 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 simple and straightforward computing service, and it’s probably the easiest of all. Rather than renting a server with a specific number of cores and an amount of RAM, you simply download your code and run the function. Usually, you will not run it manually; instead, you will configure it to run based on the actions of other AWS services. For example, executing a function to resize images each time a new file is placed in S3 (a method used by the Seattle Times to great effect) or query a database each time a request is sent to API Gateway.
IT resources are automatically assigned to the running function and it will use as much memory as necessary for the duration of the task. You are simply billed based on the number of function calls and the amount of memory used by each call.
This makes Lambda very flexible for use as a backend. Traditional applications are mostly monolithic; you have a server (or a fleet of them) running your application. You can have separate servers for web hosting, databases and other things, but many applications are designed this way: a large executable, many moving parts.
With everything that is so interconnected and without strict order, it can get very fast. It is also more difficult to evolve effectively; if you find that part of your application is the bottleneck, it can be difficult to eliminate it without upgrading the entire application and dramatically increasing your AWS bill in the process.
Instead, you can remove the bottleneck 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 very efficient and, when implemented correctly, can save you a lot of money. Postlight’s Adam Pash was able to drop his AWS monthly bill from over $ 10,000 to just $ 370, just by switching to Lambda and optimizing memory usage.
While it’s not as drastic or easy for every application, Lambda has great advantages that make it a crucial part of the AWS compute service portfolio.
For non mission critical applications, it also presents a very economical way to run an application that must make API requests. For example, you can broadcast a static web application without all servers, by storing your website in S3, serving it via CloudFront and connecting to a Lambda backend via API Gateway which communicates with a DynamoDB table.
How much do they cost?
Like most AWS, Lambda pricing is largely a “pay as you go” model. Rather than paying a lump sum price for the entire server, you will only pay for the exact amount of resources that your application uses – you never pay for idle time, not even a second. This obviously makes Lambda quite efficient, in addition to being able to eliminate bottlenecks in monolithic applications.
Lambda’s fees are as follows:
- $ 0.20 for 1 million requests
- $ 0.0000 16666 for each GB-second
The first charge makes the most sense; if you have 100 million requests per month, you will have to pay a fee of $ 20 for this.
The second charge is much more confused. Basically, you are billed based on the memory usage of your functions, as this is usually the limiting factor for AWS. If your function starts, allocates 1024 MB of RAM and runs for a single second, you will be billed $ 0.000001667 for that. This is a fairly low figure, but for 1 million requests, it is $ 1,667.
Naturally, you will want to choose an efficient runtime in memory. NodeJS is commonly used because it is quite lightweight compared to runs like Java. However, Java can be faster for tasks that take longer to complete, and since you do not pay for the time spent initializing the runtime (ie “cold start”), this n isn’t always as bad as it sounds on paper.
It’s all a balancing game, but you want to try to minimize two things: memory usage and time spent performing the function. There is no explicit charge for longer functions, but you are billed per second, per GB, so a 256 MB function that runs for two seconds will cost you the same price as a 512 function MB that runs for one.
Log in to your AWS account and access the Lambda management console.
There are two main tabs here. The first concerns applications; Lambda applications manage several functions and are specifically deployed automatically using a SAM model. This allows them to be tracked on Git and the managed version, which helps immensely when working with hundreds of functions.
The second tab concerns the individual functions. If you’re just creating a stand-alone Lambda function, or if you’re just trying to get a feel for it, you should start here and create a function from scratch, because it’s much 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. You can also choose to use a predefined template, or even download a function from the application repository without a Lambda server.
If you create it by yourself, you will have to choose a runtime. Lambda has a few default choices:
You can also bring your own runtime to run the language you want.
Once it is created, you can modify it from the function page. The standard NodeJS function exports a handler, which is called each time the function responds to events.
We recommend using the AWS Cloud9 IDE to work with Lambda functions. It is a web IDE based on the same editor as the one used on the default function editor, but with the added benefit of much easier testing and debugging.
If you want your function to respond to API requests, the easiest way to configure it is with API Gateway. You can create a new API and 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, for example each time an object is placed in a particular S3 compartment. You can also specify a destination to which the results will be sent, such as an SQS queue, an SNS topic, or another Lambda function.
The Lambda function will execute with the privileges granted to it by the execution role that has been created for it. If you access other AWS resources, you will need to authorize them to do so in the IAM Management Console.