If you’re just starting out working with AWS Lambda there are a LOT of things for you to understand. And of course, one of those areas is going to be: testing.

How to test AWS Lambda? AWS Lambda can be tested manually using the AWS console with test events. In addition to manual testing, AWS Lambda can also be tested through local replication with tools like as docker-lambda. Or finally, testing AWS Lambda can be done using an automated (CI) pipeline for running unit, component and integration tests. 

There’s a few different ways you can go about testing AWS Lambda, today we’ll run through these different options, and I’ll let you know what has worked best in my experience and where I’d suggest you spend your energy on.

Ah, so you’ve reached that point: you’ve been through the euphoria and the buzz of setting up a Lambda function, and the eureka moment when everything is running… but then everything comes crashing down when you realise how painful debugging AWS Lambda is! I know, because I’ve been there too.

How to debug AWS Lambda? Debugging AWS Lambda is achieved through a range of different methods: using local debugging tools e.g. docker-lambda and serverless offline, through monitoring tools e.g. CloudWatch and through the implementation of a test harness. 

The topic of debugging an AWS Lambda function can get complicated quickly, as there’s lots of different options and approaches. Today I’ll walk you through all the different options that you have at your disposal for debugging AWS Lambda. Today we’ll cover everything from Docker Lambda to CloudWatch. 

This month AWS announced a new feature called Lambda Extensions (Source). AWS release so many features it is hard to keep up. With each new feature we often need to ask ourselves, is this something we should pay attention to or not?

What is Lambda Extensions, and who should pay attention to it? Lambda Extensions are an addition to the Lambda Runtime API, allowing additional control, setup and tooling. Lambda Extensions are mainly aimed at third-party vendors, particularly monitoring but also configuration and security. Lambda Extensions will also be interesting to heavy users of AWS Lambda functions who need standardisation or greater control on their setups. 

Now let’s get into more detail on what Lambda Extensions actually are to help you understand whether or not they might be useful in your situation. Let’s start by looking at a core difficulty that Lambda Extensions help solve.

There are a few reasons why you may want to stop a Lambda. Either the Lambda is buggy or performing incorrectly, your Lambda is reading an event source like kinesis and you need to pause it, or your Lambda is being constantly retried.

Can you stop an AWS Lambda Function? There is no way to stop a currently executing AWS Lambda function. But you can stop future invocations by setting concurrency to zero or disabling integrations. 

So, there’s a few different aspects to the topic of stopping a Lambda. Let me take you through some different options for stopping your AWS Lambda function so that you can decide which one makes most sense for your situation.

Architecting solutions using AWS Lambda means understanding many nuances in how AWS works, and a main consideration for our application architecture is the database. So we’ll need to need to know whether AWS Lambda can connect to a database at all, and what our options are.

Can AWS lambda access a database? Yes. AWS Lambda can connect to an AWS hosted databases such as RDS or DynamoDB. AWS Lambda can also connect to external databases which are public or grant network access. 

Dependent on the database you’re using (or intending to use) there are some considerations you should address. Let’s now go through the different options you have for integrating a database with AWS Lambda, and address some of those considerations so you can make an informed decision.

Are you creating a lambda function? Are you currently debugging wondering where you can access the output of your console.log entries?

Understanding how logs work is a common confusion area when working with AWS Lambda. Today, we’re going to clear up the confusion and get your hands on your AWS Lambda logs so that you can start to debug your Lambda function.

By the end of this article you’ll understand how and where console.log output goes from an AWS Lambda function, and also how to debug your AWS Lambda setup if you’re still not seeing log output. 

When it comes to working with Serverless and AWS Lambda there are many different tools and approaches to choose from. You may have heard about a few already and might be wondering about the differences. To be quite frank with you—there were some aspects I wasn’t event totally sure of myself.

Working with Serverless requires overcoming a few obstacles: How to run your functions locally? How to create your infrastructure? How to deploy your applications? Today we’ll take a look at five main serverless approaches that attempt to help with these obstacles: manually configuring, using Serverless Framework, Terraform, CloudFormation, and SAM.

By the end of this article you should understand what the main approaches to Serverless are and when to consider using them.