Getting started with AWS Lambdas

What I stumbled upon & learnt that you should benefit from, all through hands-on application.

This is the first blog of many blogs on various AWS services to build seamless, ready to ship serverless features: checkout the whole series here.

AWS lambdas are serverless functions which offer compute without any care of building and maintaining a server. They can be connected to a database and be triggered by either API endpoints, Time based triggers or various other services by AWS.

Points of Discussion:

1. What is Execution Environment of AWS Lambdas?

2. Error: Function.ResponseSizeTooLarge

3. Lambda invocation, timeout & global variables

0. Hubble captured a black hole, it’s lambda execution env :)

Execution Environment & Lifecycle

Lambda’s execution environment is a combination of virtual machine and a container- the best of both worlds. The virtualization stack is VMM (Virtual Machine Monitor) at core that provides and manages the resources required to set up the environment.

The stripped down VMM based on container provides low latency and scaling options for lambdas. This hybridization gets best of both worlds, container and VM, originated to bring forward AWS Firecracker.

This execution environment is loaded whenever we make changes in the function configuration.

Lambda can run the next invocation request on an existing, running execution environment, by simply invoking your Lambda function handler method with a new request payload (1).

Observe the CloudWatch logs for each execution environment, they store entries about how application is running regarding third party integrations, setting up lambda permissions and logging data and response produced.

Response Limit

"errorType": "Function.ResponseSizeTooLarge",
  "errorMessage": "Response payload size exceeded maximum allowed
                    payload size (6291556 bytes)."

When we send a response from lambda, specifically the payload in the response body, we convert the JSON response to string (JSON.stringify()) before sending.

The result, once parsed on the client side, is generally an array of objects containing the information requested from the API endpoint that triggers the lambda.

There is a limit to the size of the payload that lambda may send back to the API endpoint that triggers it and give ResponseSizeTooLarge error. Here, AWS outline all the limits related to AWS lambdas where it mentions 6 MiB limit on response body in case of synchronous calls which is quite easy to break.

The document says 6MB but after some testing I understood it should Mib, which is:

6 * 1024 * 1024 or 6,291,456 bytes

While measuring your response size, make sure to account for:

1. The “quotes” used in sending the body as string are counted in the response size, which takes 2 bytes.
2. Lambda uses UTF-8 encoding for its responses which appends £ symbol that consumes 2 bytes.

In such cases, the general practice outlined by various serverless engineers is to go for paginated APIs or you can go with API gateway proxies, removing lambdas from equation and connecting API gateway directly to S3.

Invocation of Lambda

Lambda prepares the environment for code handling, invoking and shutting down when idle. This happens in three stages- init phase, invoke phase and shutdown phase.

1. Execution Lifecycle

INIT phase: Any code outside the Handler method (exports.handler=async()=>{}) is executed by the initialization code (2). This happens only on first invocation. Next incoming requests don’t go through this time cost when using same execution environment, as INIT only happens on cold starts .These cold starts last up to 10sec and paves way for latency.

INVOKE phase: Handles subsequent requests incoming towards lambda.

There is default value for timeout set to 15 seconds by default, it can be edited increased to maximum of 15 minutes.

SHUTDOWN phase: The execution environment is killed via SIGKILL if the lambda is not triggered for a while and its resources are not used. elsewhere.

As mentioned in (1) & (2), we observe that any global variables (basically, overall global context) declared are reused in the same execution environment for subsequent invocations which needs to be noted.

Further reading👩‍💻:

How AWS’s Firecracker virtual machines work — Amazon Science