The Complete AWS Lambda Handbook for Beginners (Part 1)

Welcome to the Serverless world. One of the first things you’ll hear about is AWS Lambda – and you’ll continue to keep hearing about it! While architecture can be serverless without Lambdas involved, it’s very often the key component within a serverless application. In the first post of this 3-part AWS Lambda Handbook series, we run through what is AWS Lambda, dialling back to basics with the various terminology, how to create a Lambda function and how to run it.

Read part 2 and part 3 of this handbook.

What is AWS Lambda, and what does it do?

AWS Lambda is an event-driven serverless compute platform, spinning up the service in response to an event – find out more about Lambda triggers in part 1 and part 2 of our Complete Guide to Lambda Triggers series. Your code simply sits there as a file while AWS keeps a lookout for the trigger event you’ve set. When that event occurs, your code is executed and the required operations are carried out. It’s deemed ‘serverless’ because the server doesn’t exist until the user goes out to look for it – this is the epitome of Function-as-a-Service (FaaS).

Another bonus to Lambda is it’s auto-scalability managed by AWS, meaning you don’t need to think about infrastructure. The service will automatically accommodate growing needs and likewise, will scale down to conserve resources. All of this makes AWS Lambda a great solution to reduce waste of resources and budget.

Dashbird Book

Get your free Ebook!

Serverless Best Practices handbook

AWS Lambda Definitions Explained

Before getting into how to set up and configure Lambda, below are definitions and terminology commonly used and spoken about.

Lambda Function: a group of related statements that perform a specific task in your application. It consists of code and any dependencies that are associated with it. Each Lambda function has its associated configuration information (name, description, entry point, and resource requirements).

The function itself has the following important aspects associated with it:

  1. Trigger: A set of activities that invokes the function (runs the code you provide). The activity could be anything like a new object coming to your S3 bucket, a website or service going down, an API call, etc.
  2. The actual function: This is the run-time code that constitutes the function. AWS supports Python, Node.js, C#, Go and Java8 as runtime environments.
  3. Resources: Each function can be assigned certain Roles, which grants the function certain privileges such as reading S3 bucket contents, writing results to a database and so on.

The triggers are shown to the left, and in this case, an API gateway trigger is active. The resources are shown on the right, which in this case, are CloudWatch Logs and DynamoDB.

Event Sources: an entity that publishes events. An event source can be an AWS service or developer-created application that produces events that trigger a function to run.

Invocation: an invocation is called up to execute a specific Lambda function. These are triggers for the code of the function to start running. Invocations can be either synchronous or asynchronous.

Event Source Mapping: a configuration of AWS services in which an event source is tied to a specific Lambda function. It enables automatic invocation of a Lambda function when specific events occur.

Lambda Execution Model: When you create a Lambda function, you can specify configuration information, such as the amount of memory and maximum execution time that you allow for your function. When that function is invoked, AWS Lambda launches an Execution Context based on the configuration settings you have provided.

Cold Starts: A cold start happens when a Lambda function is invoked after not being used for an extended period of time, which results in increased invocation latency (more on this later).

AWS Lambda Configuration Elements

A Lambda function consists of the code and associated dependencies, and it also has configuration information within it. An API is also provided so you can update some of the configuration data. Lambda function configuration information comes with these critical elements:

  • Calculating the required resources: specifying the amount of memory that you wish to allocate for your Lambda function. AWS Lambda allocates CPU power in proportion to the memory by the same ratio as a general-purpose AWS EC2 instance type, like an M3 type.
  • Maximum execution time (timeout): specified to prevent the Lambda function from running non-stop. Since you’re paying for the AWS resources that are used to run your Lambda function, this is particularly important. Upon reaching the timeout, AWS Lambda is terminating the execution of your Lambda function. The recommended setting is valued upon the expected execution time.
  • IAM role (execution role): the role that AWS Lambda performs on your behalf when executing a Lambda function.
  • Handler name: the method of an entry point that runs your code with any event source dependencies included as a part of your Lambda function. You will be able to discover more details, and the quality features of monitoring and debugging AWS Lambda using this.

Creating a Simple AWS Lambda Function

Let’s create a simple Lambda function that is invoked by an API call, i.e. we generate a URL, which when entered in the browser would invoke the function. Our input would be passed into the function via this URL and the output would be returned and shown in the browser.

Step 1: Creating the function

In the Lambda console panel, click on create function. Give your function a name, in our case, it is DemoFunction. Also select the runtime as Python3, as we will be using that particular language for this example. Lastly, give your function’s role a name and, from Policy Templates, select Simple Microservice permissions.

Click on Create Function and you will be taken to the next screen where you can provide the actual code. We are authoring this API from scratch, but there are tons of templates from Amazon repository that you can explore.

The next page will have an inline text editor with a simple python function in there. Replace that with the following content:

import json

print('Loading function')

def lambda_handler(event, context):

    firstName = event['first']

    lastName = event['last']

    return 'Greetings, ' + firstName + ' ' + lastName +'!' 

The first line is for parsing the JSON using the JSON library in Python. The lambda_handler function gets the event as one of its parameters; this event brings along a set of data. The first and second line inside the function extracts whatever data is labelled first and second, and stores them into the respective variables.

The last line returns a message back and that’s what we will see in our browser.

We can add an API Gateway trigger right here, but for the sake of clarity, let’s do it separately. For now, we can click Save and move into the testing phase.

Step 2: Testing your function

To test your function, just click on the top right corner where it says ‘TestEvent’, then click on Configure Test Event.

Here we will have our first encounter with a JSON payload. In the template TestEvent.

Replace the file’s content with the following lines:


  "first": "Jane",

  "last": "Doe"


Now that we have saved the test event. Click on Test in the previous menu. Upon successful execution you should see:

Step 3: Setting up a Trigger

As mentioned before, our user would invoke the function by accessing a certain URL. To enable that go to the API Gateway Console under your AWS Services and click on Get Started or New API option.

Let’s create one from scratch:

Our API is named dashbird-api. After clicking on Create API. You will get the resources that the API has access to (listed in the next menu):

Since there are no resources, we just get a forward-slash. But you can create a new resource by using the Actions drop-down and picking Create Resource.

In the resource list, you can select this new resource (named greetings), click on Actions and select Create Method. Our HTTP request method is going to be a GET request since our aim is to get an appropriate response from invoking the function.

The method will have a Lambda integration option, select that and then enter the function name chosen by you earlier Step 2. Also, from Step 2’s screenshot, make note of the function’s ARN (top-right corner), it has the string eu-central-1 indicating the region it is in. Make sure that the same region is selected for the Lambda region also, as shown above. It would then ask permission for invoking the function; grant that and now we are ready for the final modification.

The GET method execution is explained in this diagram:

We still need to make sure that the input parameters are passed on correctly. For that, we need to modify the Integration Request stage from above. You can click on it to make modifications:

Leave everything as it is, except at the very bottom of the menu where you will find the Body Mapping Template here we get to describe our input template. The template is going to be of type application/json :

    "first": "$input.params('first')",

    "last": "$input.params('last')"


The dollar sign and the input.params() part act as a placeholder and helps us define the structure of a proper request. Now we can save our changes, and click on Actions and select Deploy API option. It will ask for a stage name; give it a suitable name (in our case it is called prod). All is set! We can now run this function in real-time.

Running the Function

The function can be invoked using a unique URL associated with it. In the API console, where we first selected Resources, select Stage submenu instead. Then drop down to greetings and then to the GET option.

It will give you an invoke URL, which you can click on for the function to run. However, on the first try, you might get an error message if you didn’t give any input. You can rectify this by modifying the URL like this:


Adding the last part to the URL would result in a successful execution of the function:

Options for Creating Lambda

Of course, the above is just one example using one method, so when creating Lambda for your own application it’s important to remember the other options available.

  • Writing Code: the supported languages are Node.js, Java, C#, Python and Go. These languages use specific tools for authoring code. Some of them are AWS Lambda console, Eclipse IDE, etc.
  • Deployment Packages: Deploying code and creating a Lambda function requires you to first package your code and dependencies in a deployment package in order to develop a Lambda function. Once done, you need to upload the deployment package to AWS Lambda, so it will allow you to create a Lambda function. Organizing your code and dependencies in specific ways is the first step towards building the deployment package. Deployment package instructions may vary depending on the language you have chosen to author the code.
  • Creating Lambda: You can choose between AWS Lambda console, AWS CLI, and AWS SDKs to create a Lambda function.

In the next part of our AWS Lambda Handbook for Beginners series, we’ll be explaining AWS Lambda pricing, sharing some facts that you may not have known about and great use cases. Stay tuned!

Read our blog

ANNOUNCEMENT: new pricing and the end of free tier

Today we are announcing a new, updated pricing model and the end of free tier for Dashbird.

4 Tips for AWS Lambda Performance Optimization

In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.

AWS Lambda Free Tier: Where Are The Limits?

In this article we’ll go through the ins and outs of AWS Lambda pricing model, how it works, what additional charges you might be looking at and what’s in the fine print.

More articles

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.