Deploy a serverless application with AWS Lambda and API Gateway

A serverless application is a type of software architecture in which the application is built and run without the developer managing the underlying server infrastructure. Instead, the cloud service provider automatically handles server management tasks such as provisioning, scaling, and maintenance.

Using AWS Lambda for deployment of serverless applications has several advantages, some of which are as follows:

• Reduced cost: Lambda is a serverless service, so there are no costs for idle time and we are only charged for the actual compute time consumed by our function.

• Scalability: Lambda scales automatically based on the number of requests made to it. This removes the need for manual scaling to handle traffic spikes in traffic without manual intervention.

• Fully managed: Lambda is a fully managed service, so we don’t have to worry about infrastructure management-related tasks.

Now that we know the advantages of using Lambda to host serverless applications, let’s deploy one using it. We’ll deploy a simple storage application using which we’ll be able to perform CRUD operations on a DynamoDB table. Here’s the infrastructure that we’ll provision:

Step 1: Create the prerequired infrastructure

We’ll start with creating the resources the application and Lambda will use.

Create an IAM role

We’ll require an IAM role because Lambda mostly uses other AWS services, and AWS services are required to assume an IAM role to use other AWS services. The command below creates an IAM role for our Lambda function.

Enter your AWS Access_Key_ID and Secret_Access_Key in the widget below before running any commands. If you don’t have these keys, follow this Answer to generate them “How to generate AWS access keys.”

Note: The IAM user whose credentials are being used must have the permission to perform all the required actions.

In this command, the argument assume-role-policy-document specifies the services that will be allowed to assume this role. You’ll get detailed information about the newly created role. Copy the value of the ARN from the output and store it using the playground below in the iam_role_arn field, similar to how you entered your AWS access keys.

Now that the role has been created, let’s add the required permissions with it using the put-role-policy command.

The argument policy-document specifies the permissions that this role will have. We will use the Lambda function to perform CRUD operations on a DynamoDB table, so this IAM role, which will be assumed by the Lambda function, has been provided the necessary permissions as specified in lines 10–14.

Create a DynamoDB table

Next, we’ll create a DynamoDB table, which will be used by our application as a storage. All our CRUD requests will be directed to this table. The command below creates a DynamoDB table:

This table will have only one attribute, id of type string.

Step 2: Create a Lambda function

Now, we’ll create a Lambda function that will be used to host our application. We’ll also need to upload the application code to the Lambda function during its creation. The widget below contains the code of the application. This application is used to perform basic CRUD operations on a DynamoDB table. We’ll use it to perform CRUD operations on the DynamoDB table that we created earlier.

This code will be uploaded to the Lambda function as a zipped file. Click the “Run’’ button, and this code will be zipped to a file titled deployment_package.zip. After that, the script in main.sh file will execute. This script contains the command to create a Lambda function with eployment_package.zip as its deployment package.

Our application checks the incoming HTTP method and delegates the operation to corresponding asynchronous functions (getItems, createItem, deleteItem). These functions construct and execute DynamoDB queries based on the provided parameters, responding with appropriate status codes and messages.

Copy the ARN of the Lambda function from the response and store it in the lambda_function_arn field in the playground below.

Step 3: Create API Gateway

Now, the only thing remaining is to create and configure an API Gateway, which we’ll use to interact with the Lambda function and effectively with our application. Execute the command given below to create an API Gateway titled ServerlessAppAPI.

From the output, save the id in the api_id field and rootResourceId in the parent_id field, using the widget below.

Configure the API Gateway

The first part of configuring the created API Gateway is to create a resource in it. Resources shape up the URL of your API. We can use it to organize and structure our API to have multiple URLs based on different functionalities. The command below creates a resource in the API Gateway we created. Execute this command to create a resource myapp.

Note down the id from the response and save it in the resource_id field in the widget below. It will be used in the next steps. We can have multiple resources based on our requirements. These resources become part of the URI that we can use to call the API.

Now, we’ll create a method that will be used to call the API. We’ll create ANY method which accommodates all types of HTTP requests. Execute the command given below to create ANY method within the resource we created earlier.

We have configured our API as per our requirements. It has the path structure we want and accepts all HTTP requests. Our next step is to integrate our API with our Lambda function. To do that, we’ll use the put-integration command. Click the “Run’’ button to integrate our Lambda function with our API.

The request-templates argument contains the event data that will be sent to the Lambda function by the API when it’s invoked.

Now, finally, we’ll deploy the API to complete our configurations. Execute the command below to deploy the API.

Our infrastructure is now completely set up. All we need is the invoke URL of the API we created to test our infrastructure. Click the “Run’’ button below to get the invoke URL of the v1 deployment stage of our API.

Note down the URL we get in response and store it somewhere safe. This is the invoke URL of our API.

Step 4: Test the infrastructure

Now, let’s test our infrastructure using the playground given below. Follow these steps to do so:

Create an item

We’ll start with a POST call to create an item in our DynamoDB table using our serverless application. Replace the <invoke-URL> with the API URL we saved earlier. The details of the item we are creating will be sent as the body of the API call. After taking a look at the “Body’’ for this call, click the ‘‘Send’’ button to make the API call. We’ll get Item created successfully message in response.

View the items

Now let’s check if the item we created earlier actually exists in our DynamoDB table by making a GET call. Select “View Items” under “Collection”, replace the <invoke-URL> with the invoke URL of our API and click the “Send” button to make a GET call. We’ll get the item we saved earlier, as the response of this call indicating that our POST and GET calls are working.

Delete the item

The last thing to check for our application is whether the DELETE call is working. Select “Delete Item” under “Collection”, replace the <invoke-URL> with the invoke URL of our API and click the “Send’’ button to make a DELETE call. The item to be deleted will be sent as the body parameter of this call. After taking a look at the “Body” for this call, click the “Send’’ button to make the API call. We’ll get Item deleted successfully message in response. Now make another GET call and you’ll get an empty response indicating that the DELETE call actually deleted the specified item from the table.

Our serverless application is now fully functional.

So, we’ve deployed a completely functional application with serverless architecture. Using the serverless architecture to deploy this application saves us from the overhead tasks of managing the servers for our application. This allows our team to focus on writing code and developing features rather than dealing with server provisioning, scaling, and maintenance. Additionally, serverless services can automatically scale to handle varying workloads, providing cost efficiency by only charging for actual usage.