A few notes about AWS Lambda

I’ve just finished “AWS Lambda — A practical Guide” and it was very handy for my professional daily life because helped me to better understand the tasks I am working on. During the course, Daniel Galati shares his on experience using AWS and a lot of tips of good practice and how to take advantage of the resources available.

I decided to keep some notes here because I’ll be always returning to check the content which is very useful for my work. So the criteria for the points bellow was just how immediately applicable they are for me now. I strongly recommend you to watch the whole course (you’ll like it, I promise!).

Lambda

The most important point of all this is to keep the ability to run our code, host our APIs and process events, using functions. A function is the primary unit of Lambda, it’s basically a block of code.

>> How to check logs?

CLOUDWATCH then LOGS, here you have two options:

• LOG GROUPS (it bring TOO much data)
• INSIGHTS (this one can be a better option)

>> Common triggers / event source mappings

• Cloudwatch events (for timer based jobs)
• API Gateway (for REST APIs) — when your endpoint in API Gateway is triggered, it will invoke your lambda function.
• SNS or SQS (for event processing)
• DynamoDB Streams (for record changes)
• S3 (for object creation/updates)

Dead Letter Queue

Let’s say the request processing doesn’t work for some reason. Then lambda returns it to be retried for X times. If it still doesn’t work, there must be a way to handle failure.

And how do we handle failure? Dead Letter Queue (DLQ)

A DLQ is a destination to temporarily hold failed invocation message content. It makes more sense in the context of message processing applications.

This DLQ is a SQS, which is used when something goes wrong. So, a good idea is to create an alarm based on the rule that if there is one or more messages there, it should send you an email.

Why does this matter?

• Synchronous can have cost implications. If there is a lambda that calls another one and so on… The first one will be waiting to finish and you will pay for the duration of the invocation.
• Asynchronous can be more suitable for fault tolerant cases. As the process doesn’t stop, if something breaks, the process will return there later.
• Different failure behaviors. When dealing with synchronous, you can found out failures immediately and do something to fix it. Differently, with asynchronous, it will take a while until you found out failures.

RDS Proxy

When you invoke a lambda, it provides a Load Balancer and loads your code into a EC2 machine. When calling a relational database, you have a limited number of connections available. Then at a certain point your request will fail and because of this, there is the RDS Proxy.

Instead of establishing connections directly with the PostgreSQL instances, now they are made with the RDS Proxy, which supports a huge number of connections at the same time without compromise the DB performance.

Memory

Increasing memory setting can reduce the impact of cold start. Some languages demand less memory and this cold start is faster, as Node and Python.

• Start with low memory settings.
• Once you collect enough invocation history, use the Compute Optimizer Tool.

>> Lambda Power Tuning -> cost optimization

This tool helps with the memory settings to minimize cost and run functions at the best possible performance level. It’ll analyze the log results based on the function, execution time and amount of memory, and suggest in a graph the best cost x benefit.

What is Lambda Concurrency?

Concurrency is basically the number of requests being served at a given moment. It is a major scaling consideration, and can cause applications to fail due to throttling (when lambda rejects a request).

Default: 1000 units of concurrency per AWS account per region — this number can be raised via AWS Support ticket. It means that all lambdas of the same account in the same region use the same amount of concurrency.

It is important to remember that if you see something like Rate Exceeded (exception) in the logs, it will be probably related to concurrency issues. Because of this it can be a good idea to set an alarm for when throttles are different from zero, and also 80% rule to concurrent executions.

Lambda Layers and File System

They manage external dependencies which you want to add to your function.

• Layer: allows you to easily add external libraries, data, configuration files to your function. (Remember that X-Ray comes here — side note to myself).
• File System: you can mount an Elastic File System volume to make its contents accessible to your function.

X-Ray: what is it?

It is an application level debugging feature, useful because the latency is distributed across the different dependencies that you may be calling.

Let’s say that a part of your code makes an http request to outside AWS and you want to know how long all this process is taking, so you can add custom segments to your code. It means you can monitor the time taken by the dependencies and also by an specific part of your code.

>>Required dependencies and command to

from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.core import patch_all

patch_all()

The module “patch_all” is not automatically available, you have to add a layer to the lambda.

If there is a method that you want to know how long it is taking to execute, you can use an annotation to create a section in the XRay log:

@xray_recorder.capture("NAME OF THE SECTION YOU WANT TO CREATE")
def filter_items(items: list) -> list:
result = []
... so on

You need to enable it on:

LAMBDA -> CONFIGURATION -> MONITORING AND OPERATIONS TOOLS -> Active Tracing

You click on Edit, change and save it. Monitor it on Cloudwatch.

Again: those are meaningful points for me and what I’m currently using at work. To get a more dept understanding of this content and a lot more, check out “AWS Lambda — A practical Guide”.