AWS Lambda 101

On the previous page we’ve seen a screen like this one. If we look a bit deeper into it, we can use it to try and explain what AWS Lambda is, how you can configure functions, how the billing works and so on.

The basics

AWS Lambda is the serverless compute service from AWS. With it, you can run code without provisioning or managing servers.

Language support

It supports the following languages (or runtimes):

  • NodeJS
  • Python
  • Java
  • Ruby
  • Go
  • .NET

and if those are not enough, you can also run your own Docker container.

Triggers

The code you upload can be executed based on several triggers:

  • a schedule (every X minutes, like a cronjob)
  • an event

Events

An event is a JSON-formatted document that contains data for your function. They could be custom events you produce or one of the ~200 service events generated by other AWS services.

A service event can be generated when a file is uploaded or when a specific API endpoint receives a request (we will be using those today).

An example event coming from the API Gateway could look like this (shortened for brevity):

Compute resources

Each Lambda function you create is configured with an amount of memory available to it; from 128MB to 10GB. CPU resources are assigned to them also and they scale with memory - the more memory the more CPU time it gets.

Storage

It is possible to attach persistent storage to your Lambda functions by leveraging AWS EFS mount targets.

If needed, an ephemeral storage volume up to 10GB in size, can be available at /tmp for reading/writing temporary files. This opens up many new use cases for Lambda functions that work with large files.

Billing

Billing model for Lambda functions is pay-per-use. You are charged based on the number of requests to your functions and their duration.

A “request” is counted each time a function starts executing in response to a trigger (event or schedule).

Duration is calculated from the time your code begins executing until it terminates (with a return or an error). Duration is rounded up to the nearest millisecond.

In the end, the price depends on the amount of memory configured for the function and the duration that function executed for.

An example

Let’s assume you have a function configured with 1GB of memory (with no additional storage which is priced separately) and this function receives events from the API Gateway. Each request is processed in approx. 120ms.

Price per 1ms for 1024MB of memory is $0.0000000167. Price per 1 million requests is $0.2. AWS Lambda includes 400 000 GB-seconds and 1 million free requests per month.

For 5 million invocations per month, the calculation would be as follows:

Scaling

The first time you invoke your function, AWS Lambda creates an instance of the function and processes the event. When the function returns a response, it stays active and waits to process additional events. If you invoke the function again while the first event is being processed, Lambda initializes another instance, and the function processes the two events concurrently. As more events come in, Lambda routes them to available instances and creates new instances as needed. When the number of requests decreases, Lambda stops unused instances to free up scaling capacity for other functions.

The default number of concurrent instances is 1000 across all functions and can be increased.

Pros and Cons

Pros

  • Pay per use
  • Completely managed infrastructure, including scaling
  • Integration with other AWS services

Cons

  • Execution time: up to 15 minutes
  • Code package size: 50MB zipped, 250MB unzipped
  • Payload size for HTTP requests: 10MB (limitation of AWS API Gateway)

Now that you understand the basics of AWS Lambda it’s time to build the first feature of our application which is donor sign-up.