Gaps in APIs can occur before requests reach the APIs, within the code housing the APIs, and even along the path of the APIs’ communication with downstream services, dependencies, or other microservices.

Attackers leverage flaws in APIs to gain access to confidential data, harvest or manipulate data, or even make your service unavailable through distributed denial of service attacks.

In this article, you’ll learn to deploy your APIs in Lambda and apply some security measures pre-function, within the function, and post-function.

Table of Contents

• What is an API?

• Requirements/Prerequisites

• Project Goal

• Project Overall Architecture

  • AWS Set Up

  • Clone Project

  • Set Up Simple Notification Service

  • Set Up Secrets Manager

  • Set Up Internal Lambda

  • Set Up External Lambda

  • Configure Web Application Firewall

  • Configure Cognito User Pools

  • Configure API Gateway

  • Test Setup End-to-End

  • Clean Up

• Improvements

• Conclusion

What is an API?

The focus of this article is the security of Application Programming Interfaces (APIs). An API is an interface that connects two programms or applications, allowing them to exchange data and communicate.

An API can be internal to an organization or it can belong to a third-party that allows other users to consume their data through the API.

Requirements/Prerequisites

While this tutorial is beginner-friendly, you’ll need the following prerequisites to follow along seamlessly:

• A basic knowledge of the AWS Cloud.

• An AWS account with administrator access.

• AWS CLI. You can find the installation guide here. Follow the instructions for your operating system.

• Python. You can visit Python’s official documentation site for a guide on how to download and install Python for your specific operating system.

• Pipenv or any Python virtual environment creation tool. You can find the Pipenv installation guide here.

• A basic knowledge of Git.

• An API client, like Postman or Thunderclient.

Project Goal

By the end of this project, you should be able to deploy APIs in Lambda securely, leveraging AWS cloud-native security services.

Project Overall Architecture

Below is the architecture of the project workflow:

As shown in the architectural diagram, when a user sends a request (a JSON object consisting of the user’s name) to an API hosted in Lambda, the user first gets authenticated by an authentication service called Amazon Cognito.

The request passes through a Web Application Firewall, then an API Gateway. API Gateway will perform a check to see if the user is authorized to access the API using the token that the user sends with the request after authentication. API Gateway then allows the traffic to pass through to the API if the user is authorized.

The user’s request will first get to an External Lambda function, which will then save the user’s name as a message to a Simple Notification Service (SNS) topic. This will then invoke an Internal Lambda to run and log the output in Amazon CloudWatch logs. The SNS topic will be accessed by External Lambda using the SNS’s unique identifier stored in Amazon Secrets Manager.

AWS Set Up

You’ll need to set up an AWS environment to get started. This requires creating an account if you don’t already have one.

Following account creation, a root user is automatically created, with all privileges attached to the user. Security best practice is to create another user with administrator privileges and use this user for subsequent tasks.

Then, create an access key for this user, which usually consists of two parts (Access Key ID and Secret Access Key) by navigating to the following:

IAM —→ Users —→ Create Access key

Follow the prompts and choose the Command Line Interface option. Check the Confirmation box, and go on to create the key. Download the CSV file provided, or manually copy the Access Key ID and Secret Access Key. Save them securely.

Open up your terminal and run the following commands using the AWS CLI:

aws configure

The above command will give some prompts to provide the components of the Access Key created earlier and your default region (the AWS region hosting the service you intend to interact with).

Clone Project

In the next step, you’ll clone the GitHub repository containing the assets and resources used in the project implementation.

Visit the project URL and clone the repository locally.

git clone <repository_clone_url>

Set Up Simple Notification Service

Amazon Simple Notification Service (SNS) connects system components, enabling asynchronous communication and messaging among them.

Find SNS on the console, click on it, and create a topic that your APIs will send messages to. After successfully creating a topic, navigate to the topic, and in the topic details, you’ll find the topic’s ARN. An ARN is an Amazon Resource Name, and it’s a unique string attached to a resource you’ve created on AWS to help identify the resource. Copy the ARN of the topic.

Set Up Secrets Manager

Amazon Secrets Manager is used to store, manage, and retrieve sensitive information such as keys, credentials, tokens, and so on. You’ll store the Topic ARN created earlier. With this approach, you’ll demonstrate how your API can securely access the data and information it needs for its performance.

Go to Secrets Manager on the AWS console and create a secret. Provide the secret’s details, and add a new secret named TOPIC_ARN as the key and the actual SNS Topic ARN as the value.

Next, you’ll create some Lambda functions to serve your APIs and consume the output of the APIs. There’re three Lambda functions to set up. Two of the functions will host APIs, each of which can only be accessed by specific users. These will be referred to as ExternalLambda. The third Lambda will consume the output of the External Lambda functions through SNS.

Set Up Internal Lambda

AWS Lambda is a serverless service on AWS that users can leverage to run application functions or code when needed. You’re billed for your Lambda function based on the number of invocations of the function, the duration each invocation lasted, and the amount of memory allocated to the function. Lambda can be provisioned to use any runtime, such as Python or NodeJS. In this demonstration, you’ll focus on the NodeJS runtime.

Now that you know what Lambda is and does, you can create one. Let’s call the first Lambda function InternalLambda. On the AWS console, search for Lambda, and on the Lambda dashboard, click Create a function and provide the details. We’ll be using Node.js – JavaScript at the backend as the runtime of choice.

For the Permissions details, let Lambda create a default IAM Role. This default role is named according to your function, and the permissions attached to the role allow your Lambda function to send logs to CloudWatch, another AWS service used for monitoring and observability.

As you can see in the last image above, the Lambda function you’ve created needs a trigger and sometimes, a destination. For your InternalLambda, the trigger is the SNS topic we configured earlier. This Lambda will read the messages that’ve been published to it, and then you can access the message from your client or even CloudWatch logs.

To achieve this, click the Add trigger button and provide the details.

Next, you’ll provide the code you want to invoke through Lambda. Find the code in the GitHub repository that you cloned earlier. Paste the code in the Lambda function code space and click on Deploy to deploy the function.

secure-lambda/InternalLambda/index.js

export const handler = async (event) => {
    try {
        console.log('Request successfully received from SNS');                            

        let name = event['Records'][0]['Sns']['Message'];
        let response = {
            statusCode: 200,
            body: JSON.stringify(`Hello ${name}. Greetings from InternalLambda!`),
        };       
        console.log('Response: ', response);                                                
        return response;
    } catch (err) {                            
        let response = {
            statusCode: 500,
            body: JSON.stringify('An error occurred while processing your request.'),
        };

        console.error('Error processing event', err);
        return response;
    }   
};

The function defined in the index.js file above is simply taking the event object sent to it from SNS and extracting the Message attribute within it. We’re using console.log here to view outputs from the function and ensure it behaves as expected. Just don’t use this in a production-ready application.

Set Up External Lambda

You’ll be creating two external Lambda functions: 1 and 2. These two functions will receive user requests, process them, and publish messages to your SNS topic.

On the Lambda console, create another function and name it ExternalLambda1. Allow Lambda to create a default IAM Role, as previously.

Paste the code snippet below in the ExternalLambda1 code space:

secure-lambda/ExternalLambda1/insex.js

import {
  GetSecretValueCommand,
  SecretsManagerClient,
} from "@aws-sdk/client-secrets-manager";

import { SNSClient, 
    PublishCommand 
} from "@aws-sdk/client-sns";

const secretsManagerClient = new SecretsManagerClient();

const snsClient = new SNSClient({});

// Fetch topicArn from AWS Secrets Manager
async function getSecretValue(secretName) {
    try {
        const data = await secretsManagerClient.send(
                            new GetSecretValueCommand({
                            SecretId: secretName,
                            }),
                        );
        if (data.SecretString) {
            return JSON.parse(data.SecretString);
        }   else {
            let buff = Buffer.from(data.SecretBinary, 'base64');
            return JSON.parse(buff.toString("utf-8"));
        }
    } catch (err) {
        console.error('Error retrieving secret', err);                             // added for debugging
        throw err;
    }
}                                        

export const handler = async (event) => {

    let name = event['name'];
    console.log(`Request successfully received from ${name}`);    

    // Retrieve SNS Topic ARN from Secrets Manager
    let topicArn;
    let response;
    try {
        const secret = await getSecretValue('LambdaSNSTopicARN');
        topicArn = secret.TOPIC_ARN;
    } catch (err) {
        response = {
            statusCode: 500,
            body: JSON.stringify('An error occured, try again later.'),
        };
        console.error('Failed to load SNS Topic ARN from Secrets Manager', err);
        return response;        
    }

    // Publish to SNS topic
   try {
        const snsResponse = await snsClient.send(
        new PublishCommand({
            Message: name,
            TopicArn: topicArn,
        })
        );
        console.log("Message published successfully:", snsResponse.MessageId);
        response = {
            statusCode: 200,
            body: JSON.stringify(`Hello ${name}. Greetings from ExternalLambda1! Message forwarded to InternalLambda.`),
        };
        return response;
  } catch (err) {
        response = {
            statusCode: 500,
            body: JSON.stringify(`Sorry ${name}.An error occurred while processing your request.`),
        };
        console.error("Failed to publish message:", err);
        return response;
  }  
};

The code above leverages the AWS SDK to fetch the ARN of the SNS topic created earlier from Secrets Manager. It then publishes a message to the topic.

The SDK already comes installed in the Lambda function. Outside of Lambda, the SDK has to be explicitly installed. The function receives its event from the client via API Gateway, which we’ll configure later.

The SNS topic you created earlier will be the destination for this function. For Lambda to publish a topic to SNS, it needs the necessary permission attached to its IAM Role. AWS can automatically take care of that during your configuration, as shown below.

For the trigger, you’ll use another service known as API Gateway. More on that later.

Follow the same steps to provision another Lambda known as ExternalLambda2.

The outcome of the External Lambda setup is as shown below:

Paste the code below into ExternalLambda2. It performs the same function as ExternalLambda1, but their output differ. Each of the two Lambda functions will be receiving traffic to a specific user that’s authorized to access the function.

secure-lambda/ExternalLambda2/index.js

import {
  GetSecretValueCommand,
  SecretsManagerClient,
} from "@aws-sdk/client-secrets-manager";

import { SNSClient, 
    PublishCommand 
} from "@aws-sdk/client-sns";

const secretsManagerClient = new SecretsManagerClient();

const snsClient = new SNSClient({});

// Fetch topicArn from AWS Secrets Manager
async function getSecretValue(secretName) {
    try {
        const data = await secretsManagerClient.send(
                            new GetSecretValueCommand({
                            SecretId: secretName,
                            }),
                        );
        if (data.SecretString) {
            return JSON.parse(data.SecretString);
        }   else {
            let buff = Buffer.from(data.SecretBinary, 'base64');
            return JSON.parse(buff.toString("utf-8"));
        }
    } catch (err) {
        console.error('Error retrieving secret', err);  
        throw err;
    }
}                                        

export const handler = async (event) => {

    let name = event['name'];
    console.log(`Request successfully received from ${name}`);    

    // Retrieve SNS Topic ARN from Secrets Manager
    let topicArn;
    let response;
    try {
        const secret = await getSecretValue('LambdaSNSTopicARN');
        topicArn = secret.TOPIC_ARN;
    } catch (err) {
        response = {
            statusCode: 500,
            body: JSON.stringify('An error occured, try again later.'),
        };
        console.error('Failed to load SNS Topic ARN from Secrets Manager', err);
        return response;        
    }

    // Publish to SNS topic
   try {
        const snsResponse = await snsClient.send(
        new PublishCommand({
            Message: name,
            TopicArn: topicArn,
        })
        );
        console.log("Message published successfully:", snsResponse.MessageId);
        response = {
            statusCode: 200,
            body: JSON.stringify(`Hello ${name}. Greetings from ExternalLambda2! Message forwarded to InternalLambda.`),
        };
        return response;
  } catch (err) {
        response = {
            statusCode: 500,
            body: JSON.stringify(`Sorry ${name}.An error occurred while processing your request.`),
        };
        console.error("Failed to publish message:", err);
        return response;
  }              
};

Before moving on, you need to modify the External Lambda’s IAM Roles. Currently, IAM Roles only have permissions to write to CloudWatch and SNS (automatically added). External Lambda also needs permission to fetch the ARN of the SNS topic that was created earlier.

The point here is to show how to leverage a secrets manager, such as AWS Secrets Manager, to store sensitive information or data, and still access these securely. This approach is more secure than storing the ARN as an environment variable within Lambda.

Navigate to IAM, and click on Policies tab on the left. This brings you to a list of policies. Next, click on Create policy.

Search for secrets manager in the Policy editor.

Select the permissions Lambda needs to access Secrets Manager. In this case, that would be Read —> GetSecretValue.

Select Specific for Resources, and click on Add ARNs. On the next tab, add the details of the Secrets Manager Secret created earlier.

The Secret’s ARN will be populated here.

Next, give the policy a name and create it.

Next, navigate to Roles, and search for the IAM Roles assigned to the External Lambda functions. These are named according to the Lambda.

Click Add permissions to add a new permission to the IAM Role selected.

Configure Web Application Firewall

A firewall is a system placed in front of an application, workload, APIs, and so on to inspect traffic, filter it, and either allow or block the traffic based on some preconfigured rules.

For this project, you’ll use the AWS Web Application Firewall (WAF) service to inspect user requests before routing the traffic to your APIs running in Lambda.

Head over to the AWS console and search for WAF.

Click on the IP sets tab on the left. This will enable you to create a list of IP addresses that you want to allow (as in this case) or deny.

The IP addresses should include a CIDR block. For instance, if adding a single IP address, it should be X.X.X.X/32. The same applies to IP address ranges such as X.X.X.X/24.

Next, click on the Web ACLs tab, then Create web ACL.

Choose Regional resources as the Resource type, and enter your region. It’s best to keep all resources you’re creating in this project within the same region. Give your Web ACL a name, then click next.

Add rules to the Web ACL.

Choose a rule type. In this case, you’ll use IP set, and give the rule a name. Choose the IP set created earlier.

Select Source IP address, and Count as the Action. For this project, you’ll focus on counting the requests sent to your APIs. But as shown in the image below, you can perform other actions, such as allow, block, and so on.

Your final rule configuration will appear this way.

Scroll down, then click on Create web ACL.

Configure Cognito User Pools

Amazon Cognito is an identity management service used for creating and managing users. You can leverage it to authenticate and authorize users to applications, APIs, or other workloads.

You’ll create User Pools within Cognito and add a user to each pool. You’ll configure how these users can be authenticated and authorized to access the External Lambda functions already created.

Search for Cognito on AWS.

Click on Get started for free, then Create user pool.

Select Single-page application (SPA), give the User pool the name MyUserPool1, and select Email as an option for sign-in. This means the main attribute users will provide at signup and sign-in will be their email address. Leave everything else as the default. We’ll keep things as simple as possible.

After creating the User pool, you’ll find the page shown below. You can view the login and signup page for the pool you’ve just created by clicking on the View login page button.

You can add App clients to your User Pool. By default, a client named MyUserPool1 will be added to the pool. Navigate to your User pool, and click on App clients to see details of this client. Note the Client ID. You’ll also make some edits to the App client by clicking on the Edit button.

You’ll edit the Authentication flows field by ticking the Sign in with username and password… and Sign in with server-side administrative credentials… boxes. These changes will enable you to authenticate the user who will be added to this client programmatically, rather than through a UI. With this approach, we can fetch the token assigned to the user by Cognito and use this token to authorize access to Lambda.

Now, add a user to this pool. The user needs a valid email address. You’ll need the login page URL to create the user.

You need access to the email used to create the user. Fetch the code sent to the email address and submit to confirm the account.

Follow the same steps and create another User pool named MyUserPool2. Add a user with a different email to this pool.

Configure API Gateway

API Gateway is a service used to manage access and route traffic to API backend services such as APIs. It serves as a reverse proxy and provides an extra layer of security for backend services.

You’ll configure API Gateway to direct traffic to your Lambda functions.

Navigate to API Gateway and click on Create an API.

Select the REST API option —→ Build.

Select New API, provide a name, and choose Regional as the API endpoint type. IP address type can be IPv4 or Dualstack. We’ll select IPv4 here. Then create.

An important part of API Gateway configuration for this project is the Authorizer. API Gateway uses Authorizer to allow traffic from clients to backend services.

You’ll create two Authorizers. Each will be connected to one of the User pools you configured earlier. On the left-hand side of the API Gateway you configured, click on Authorizers —→ Create authorizer.

Provide the name AGAuthorizer1, and select Cognito as the Authorizer type. Add the User pool for MyUserPool1 created earlier. For the Token source, use Authorization. When you send a request from your API client, a token will be added to the request header for authorization. The token’s key will be named Authorization, while the value will be the token itself.

Create another Authorization for MyUserPool2 the same way.

Both Authorizers will appear this way.

Next, you’ll create resources and endpoints within the API Gateway that you’ve defined.

A resource in API Gateway is used to group certain endpoints within a specific path. You’ll define two resources within the API Gateway you’ve created. This will create two different paths, <BASE_URL>/<RESOURCE1> and <BASE_URL/RESOURCE2>.

On the API Gateway dashboard, navigate to your Gateway, click on Create resource, define your root path (‘/’ in your case), and provide the resource name (lambda1).

Create another resource named lambda2.

Now, click on /lambda1, then Create method to define an endpoint within this resource. You’ll use the POST method to send requests to the backend service via this endpoint.

For the backend service or Integration type, select Lambda function, and provide the ARN of ExternalLambda1.

For Authorization, select AWS IAM —→ Cognito user pool authorizers —→ AGAuthorizer1. Leave other configurations, then create the endpoint.

Repeat the same step to create a POST method for /lambda2 resource. The method should be attached to ExternalLambda2, and AGAuthorizer2.

The API Gateway you’ve created needs to be deployed to become accessible. Deployment is usually done to a Stage.

Click on Deploy API, select New stage and name the stage development. Then, deploy.

After deployment to a stage, an invoke URL will be provided. This will serve as the base URL for the endpoints you’ve defined.

The stage you’ve created needs some modifications for enhanced security. Firstly, you need to attach the WAF that you created earlier. Secondly, the default rate limit for the API deployed to this stage is 10000. Rate limit restricts excessive resource consumption and protects your API from abuse. For this project, you can reduce the limit to 50.

To test the API Gateway set up, click on the endpoint you want to test, then the Test button. This initial test doesn’t need any authorization, since the test is done directly within the Gateway.

Add JSON data as the Request body. The key will be name, and the value will be any string.

The response sent back from ExternalLambda1 shows a status code of 200, and a response body containing exactly the message expected from the Lambda function.

If you head over to CloudWatch Log groups, you should also find the Log groups that were automatically created for the Lambda functions. Click on the Log group for ExternalLambda1 and navigate to the latest Log stream. You should find the logs for the request you’ve just made from API Gateway.

Test Setup End-to-End

To test our setup properly, and from the internet, send the same request from your API client with no additional information in the request header. This should return a 401 error – Unauthorized. This is expected.

API Gateway expects an authorization token from each request it receives before routing traffic to the appropriate backend service. It validates this token through Cognito.

You’ll mimic a user login for each user added to Coginito User pools to get a token for the user. This token will then be sent alongside any request. To achieve this, you’ll use the two Python scripts I’ve provided below:

secure-lambda/auth-scripts/user1.py

import boto3

client = boto3.client("cognito-idp")

response = client.initiate_auth(
    AuthFlow="USER_PASSWORD_AUTH",  # or ADMIN_USER_PASSWORD_AUTH if using admin creds
    AuthParameters={
        "USERNAME": "",             # user1 email
        "PASSWORD": ""              # user1 password
    },
    ClientId=""                     # Cognito App Client ID
)

id_token = response["AuthenticationResult"]["IdToken"]
access_token = response["AuthenticationResult"]["AccessToken"]
refresh_token = response["AuthenticationResult"]["RefreshToken"]

print("ID Token:", id_token)

Using the Python boto3 library, you’ll initiate an authentication request to Cognito. Provide the email address and password of the user in MyUserPool1. Also, add the Client ID of the App client.

To run the script, create an isolated environment using Pipenv, uv, or a similar library. Install the dependency used in the project as defined in the Pipfile, and run the script with the Pipenv shell.

pipenv install
pipenv shell
Python secure-lambda/auth-scripts/user1.py

The Python command will return with a token assigned to the user. Next, you use this token to authorize a user to access ExternalLambda1.

Ensure that the URL for the POST request is in the format: <BASE_URL/lambda1>. You should receive a response from API Gateway indicating success.

Now try accessing ExternalLambda2 using User1 token. You should get an Unauthorized message. Note that user1 will always receive an unauthorized message when it tries accessing ExternalLambda1 without an Authorization token in the header, a wrong token, or when it tries accessing ExternalLambda2, which it is not authorized to access.

Repeat the process with User2 using the token generated for the user in MyUserPool2. First, test access to ExternalLambda2 without a token in the request header.

Then test access with the token.

Next, try accessing ExternalLambda1 using User2.

You can also view the outcome of some of the requests made by your client on CloudWatch Logs.

Also, since WAF has been configured previously to count requests (although, in a real scenario, you want to achieve much more with WAF, such as allow or block certain traffic), you can view activities captured by WAF by navigating to the service on AWS, then searching for the WAF you configured, and navigating to Traffic overview.

You can find other details, such as the client device types and where requests originated.

Clean Up

It’s important to clean up the resources created so far after the hands-on exercise. Due to the dependencies among the resources, trying to delete a resource that another resource depends on may lead to an error. So, you should delete them in this order:

• Secrets Manager

• Cognito – Users, App Client, then User Pool

• API Gateway – Endpoints/ Methods, Resources, API, Stage

• Web Application Firewall – IP Set, Web ACL

• All Lambda Functions

• Lambda IAM Roles and the policies attached to them

• CloudWatch Log Group for all the Lambda functions

• SNS Topic

Also, you can deactivate or delete the credentials created for your IAM Admin user if not in use.

Improvements

Consider the following areas to improve, apply best practices to, and enhance the security posture of your systems further.

1. Use of API keys

2. Third-party API consumption

3. API inventory management/ documentation

4. Resource provisioning using Infrastructure as Code

Conclusion

Security at every layer of an IT system is not negotiable. In this project, we’ve demonstrated how to leverage cloud-native solutions to secure APIs hosted in a serverless service, allowing only authorized users access to the APIs.

I’m Agnes Olorundare, and you can find out more about me on LinkedIn.

In this tutorial, we'll walk you through building a simple yet fully functional web application using several key AWS serverless services. You'll learn how to connect a frontend (what users see) with a powerful backend (what processes data) that can scale automatically and efficiently.

Table of Contents

• What We'll Build: A Serverless Sum Calculator

• Core AWS Services We'll Use

• Prerequisites: What You'll Need

• Getting Started: How to Build Our Serverless Web App

• How to Test Your Application: Is It Working?

• Common Issues and Solutions

• Next Steps: Enhance Your Application

• Conclusion

What We'll Build: A Serverless Sum Calculator

We're going to create a straightforward Sum Calculator web application. This app will allow users to enter two numbers, send them to our AWS backend for calculation, store the result, and then display the sum back to the user.

Here's how our calculator will work:

• First, it’ll take user input: You'll enter two numbers into a simple web page.

• Then the backend magic happens with AWS Lambda: These numbers will be sent to a special piece of code running on AWS Lambda, which will add them together.

• Next, the data is stored using DynamoDB: The calculation details (the two numbers, their sum, and when it happened) will be saved in a super-fast database called DynamoDB.

• Finally, it displays the results: The sum will be sent back to your web page and shown to you.

This project is a fantastic way to understand the core concepts of serverless architecture and how different AWS services work together to create a dynamic web application.

Core AWS Services We'll Use

Before we dive in, let's get familiar with the main AWS services we'll be using. Think of them as specialized tools, each with its own job, working together to build our app.

1. AWS Lambda: Imagine you have a tiny robot that only activates when it's given a specific task. That's Lambda! It's a "serverless compute" service, meaning you don't manage any servers. You just upload your code (our calculator logic, in this case), and Lambda runs it only when needed.

   Why we use it: It handles our backend math (adding numbers). When a user asks for a sum, Lambda "wakes up," does the calculation, and then goes back to sleep. This is efficient and cost-effective because you only pay for the time your code is actually running.

2. Amazon API Gateway: Think of this as the doorman or receptionist for your backend. When your web page wants to talk to your Lambda function, it doesn't talk directly. Instead, it sends a request to API Gateway.

   Why we use it: API Gateway securely receives requests from our web page (like "Please sum these two numbers") and then tells the correct Lambda function to wake up and handle it. It acts as the secure entry point to our backend, making sure only authorized requests get through.

3. Amazon DynamoDB: This is our super-fast, flexible database. Unlike traditional databases that are like filing cabinets, DynamoDB is a NoSQL (Not Only SQL) database, which is great for handling large amounts of data quickly and efficiently without a fixed structure.

   Why we use it: We'll use DynamoDB to store the history of our calculations (the numbers entered and their sums). It's designed to handle massive amounts of traffic without slowing down, making it perfect for web applications that need to store and retrieve data quickly.

4. AWS Amplify: Amplify is like your personal construction crew for web and mobile apps. It simplifies the process of building, deploying, and hosting your frontend application, and it integrates seamlessly with other AWS services.

   Why we use it: We'll use Amplify to host our simple HTML, CSS, and JavaScript web page. It provides an easy way to get our website live on the internet, handling all the complex deployment steps for us.

Prerequisites: What You'll Need

To follow along with this tutorial, you should have:

• An AWS account: This is essential to access all the AWS services. If you don't have one, you can sign up for a free tier account on the AWS website.

• Basic knowledge of Python: Our backend logic will be written in Python.

• Understanding of REST APIs: Knowing what an API (Application Programming Interface) is and how RESTful APIs work will be helpful, but we'll explain the key parts.

• Familiarity with HTML/CSS/JavaScript: Our frontend will be built using these standard web technologies.

• Basic knowledge of NoSQL: While not strictly required, understanding the concept of key-value pairs in databases can be beneficial.

Let's get started!

Getting Started: How to Build Our Serverless Web App

We'll build our application step-by-step, starting with the database, then our backend code, connecting them with an API, and finally, deploying our frontend.

Step 1: Set Up Your Database with Amazon DynamoDB

Our calculator needs a place to store the results of its calculations. For this, we'll use Amazon DynamoDB. You can follow these steps to get it all set up:

1. Navigate to the DynamoDB Console:

First, log in to your AWS Management Console. In the search bar at the top, type "DynamoDB" and select "DynamoDB" from the results. This will take you to the DynamoDB dashboard.

2. Create a New Table:

On the DynamoDB dashboard, look for and click the "Create table" button.

Figure 1: Creating a new table in the DynamoDB console.

3. Configure Your Table:

You’ll need to add the following information for the table:

• Table name: Enter myTable. This will be the name of our database table.

• Partition key: Enter ID.

But you might be wondering – what is a Partition Key? In DynamoDB, the "Partition Key" (also sometimes called a Hash Key) is like the primary identifier for each unique item in your table. Think of it as a unique ID number for each record. It helps DynamoDB quickly find and distribute your data. For our calculator, each calculation we store will get a unique ID.

Leave all other settings at their default values for this tutorial. These defaults are usually sufficient for basic use cases.

Figure 2: Configuring the 'myTable' with 'ID' as the Partition Key.

4. Finalize Table Creation:

Click the "Create table" button at the bottom of the page. DynamoDB will now create your table, which usually takes a few seconds.

5. Important: Note Down the Table ARN (Amazon Resource Name):

Once your table is created, click on its name (myTable) in the list to go to its details page. Under the "Summary" tab, you will find a section that displays the "ARN". This is a unique identifier for your DynamoDB table across AWS.

Copy this entire ARN and save it somewhere safe (like a notepad). We will need it later when we set up permissions for our Lambda function.

Figure 3: Locating and copying the ARN for your DynamoDB table.

Step 2: Creating Your Backend Logic with AWS Lambda

Now that we have our database, let's create the brain of our operation: the Lambda function that will perform the addition and save the results.

1. Navigate to the Lambda Console:

In the AWS Management Console search bar, type "Lambda" and select "Lambda" from the results. This will take you to the Lambda dashboard.

Then create a new function by clicking the "Create function" button on the dashboard.

2. Configure the Function:

Now, it’s time to configure your function:

• Author from scratch: Ensure this option is selected.

• Function name: Give your function a meaningful name, for example, SumCalculatorFunction or AddFunc.

• Runtime: This specifies the programming language your code is written in. For this tutorial, select "Python 3.9" (or the latest Python 3.x runtime available).

  • Note: Always choose a runtime that matches the code you're going to write!

• Architecture: Leave as x86_64 (default).

• Permissions: For now, you can leave the default execution role. We will modify its permissions shortly.

  

Figure 4: Configuring your Lambda function's name and runtime.

3. Create the Function:

Next, create the function by clicking the "Create function" button at the bottom.

4. Write Lambda Function Code:

Now it’s time to write your Lambda Function code. Once your function is created, you'll be taken to its configuration page. Scroll down to the "Code source" section. This is where you'll write or paste your Python code.

You'll see a default lambda_function.py file. Replace its contents with the following Python code:

import json
import boto3
import time
from botocore.exceptions import ClientError

# Create a DynamoDB client. This line creates a connection to the DynamoDB service.
# 'boto3' is the AWS SDK for Python, allowing our Python code to talk to AWS services.
dynamodb = boto3.resource('dynamodb')
# Specify the DynamoDB table we want to interact with. Make sure 'myTable' matches the name you created.
table = dynamodb.Table('myTable')

# This is the main function that Lambda will run when it's triggered.
# 'event' contains the data sent to our Lambda function (e.g., the numbers from our frontend).
# 'context' provides runtime information about the invocation, function, and execution environment.
def lambda_handler(event, context):
    # Extract the numbers from the 'event' data.
    # .get() is used to safely retrieve values, returning None if the key doesn't exist.
    num1 = event.get('num1')
    num2 = event.get('num2')

    # Basic validation: Check if both numbers were provided.
    if num1 is None or num2 is None:
        # If not, return an error message with a 400 (Bad Request) status code.
        return {
            'statusCode': 400,
            'body': json.dumps({'message': 'Both num1 and num2 are required'})
        }

    # Calculate the sum of the two numbers.
    sum_result = num1 + num2

    # Generate a unique ID for our DynamoDB item.
    # We use a timestamp (current time in milliseconds) to ensure uniqueness.
    partition_key = str(int(time.time() * 1000))

    # Generate a Sort Key (optional, but good practice for more complex data models).
    # Here, we're using a timestamp as well, but you could use other meaningful data.
    sort_key = str(int(time.time()))

    # Prepare the data (item) to be stored in our DynamoDB table.
    # Each key-value pair here represents an attribute in our database record.
    item = {
        'ID': partition_key,  # This matches our Partition Key in DynamoDB
        'Timestamp': sort_key, # An additional attribute to track when the calculation happened
        'num1': num1,
        'num2': num2,
        'sum': sum_result
    }

    # Attempt to store the item in the DynamoDB table.
    try:
        table.put_item(Item=item) # 'put_item' is the DynamoDB operation to add a new item.
    except ClientError as e:
        # If there's an error storing data (e.g., permission issues), return a 500 error.
        return {
            'statusCode': 500,
            'body': json.dumps({'message': f'Error storing data in DynamoDB: {e.response["Error"]["Message"]}'})
        }

    # If everything was successful, return a success message and the calculation details.
    # The 'statusCode: 200' indicates success.
    return {
        'statusCode': 200,
        'body': json.dumps({
            'message': 'Sum calculated and stored successfully',
            'result': {
                'ID': partition_key,
                'Timestamp': sort_key,
                'num1': num1,
                'num2': num2,
                'sum': sum_result
            }
        })
    }

I’ve added a lot of comments to the code, but here’s what’s going on in summary:

• import json, boto3, time, ClientError: These lines bring in necessary Python modules.

  • boto3 is crucial for interacting with AWS services like DynamoDB.

  • json helps us work with data in JSON format, which is common for web APIs.

  • time is used to generate unique IDs.

  • ClientError helps us catch specific AWS errors.

• dynamodb = boto3.resource('dynamodb'): This line creates a connection object to the DynamoDB service.

• table = dynamodb.Table('myTable'): This specifies which DynamoDB table (the one we just created) our Lambda function will work with.

• lambda_handler(event, context): This is the special function that AWS Lambda automatically calls when your function is triggered.

  • event: Contains all the information about the trigger. In our case, it will contain the num1 and num2 sent from our web frontend.

  • context: Provides runtime information about the Lambda function.

• num1 = event.get('num1'), num2 = event.get('num2'): These lines safely extract the numbers num1 and num2 from the incoming event data.

• if num1 is None or num2 is None:: This is a basic check to make sure both numbers were actually provided. If not, it sends back an error message.

• sum_result = num1 + num2: This is where the actual sum calculation happens.

• partition_key = str(int(time.time() * 1000)): This creates a unique ID for each record. We use the current timestamp (in milliseconds) to ensure it's always unique.

• item = {...}: This dictionary defines the data structure for the item we want to save into our myTable in DynamoDB.

• table.put_item(Item=item): This is the core line that tells DynamoDB to save our item into the myTable table. It's wrapped in a try-except block to catch any errors during the database operation.

• return { 'statusCode': 200, 'body': json.dumps({...}) }: This is the response our Lambda function sends back to whoever called it (which will be API Gateway, and then our web frontend). A statusCode of 200 means success. The body contains the message and the result of the calculation in JSON format.

Figure 5: Entering the Python code for your Sum Calculator Lambda function.

5. Deploy the Code:

Now it’s time to deploy your code. After pasting in the code, click the "Deploy" button above the code editor. This saves your changes and makes them active.

6. Test the Lambda Function:

And finally, once the code is deployed, you’ll want to test your Lambda Function (this is optional but recommended). Click the "Test" button next to the "Deploy" button. You'll be prompted to configure a test event.

Choose "New event" and for the "Event template", select "hello-world" (or leave it as default if "hello-world" isn't an option). Replace the sample JSON in the "Event JSON" box with the following test data:

{ "num1": 5, "num2": 10 }

Give your test event a name (for example, testSum). Then click "Save" and then "Test". You should see a "Status: Succeeded" message and in the "Execution result" tab, you'll see a statusCode: 200 and the calculated sum in the body. This confirms your Lambda function is working correctly!

Figure 6: We can see 200 ok after the test and deploy of your Lambda function.

Updating Lambda Function Permissions (IAM Role Policy)

Our Lambda function currently has default permissions, which usually don't include access to DynamoDB. We need to explicitly grant it permission to write data to our myTable. We’ll do this through an IAM (Identity and Access Management) role policy.

1. Navigate to Permissions:

On your Lambda function's configuration page, click on the "Configuration" tab. Then, select the "Permissions" sub-tab.

You will see an "Execution role" section with a "Role name". Click on this "Role name" (it will be a link). This will take you to the IAM console, specifically to the details of the role associated with your Lambda function.

Figure 7: Locating the IAM role associated with your Lambda function.

2. Add Permissions:

On the IAM role's page, you'll see a section titled "Permissions policies". Click on "Add permissions" and then select "Create inline policy". An "inline policy" is a policy that is embedded directly into a specific IAM identity (in this case, our Lambda's execution role).

Figure 8: Adding an inline policy to the Lambda function's IAM role.

3. Configure the Policy:

You'll be presented with a "Policy editor". Click on the "Visual editor" tab (if not already selected).

• Service: Click on "Choose a service" and search for and select "DynamoDB".

• Actions: In the "Actions" section, expand "Write". We need to give our Lambda function permission to "put" items into DynamoDB.

  • Search for PutItem and select the checkbox next to PutItem. Why PutItem? Our Python code uses table.put_item(Item=item) to store data. This PutItem action directly corresponds to that operation.

• Resources: This is crucial! We need to specify which DynamoDB table our Lambda function is allowed to write to.

  • Click on "Specific" under the "Resources" section.

  • Click "Add ARN" next to "table".

  • In the pop-up, paste the DynamoDB Table ARN you copied earlier from Step 1.

  • Click "Add ARN" again in the pop-up to confirm.

Figure 9: Configuring the IAM policy to allow Lambda to perform PutItem actions on your DynamoDB table.

4. Review and Create Policy:

Click "Next: Tags" (if applicable, skip tags). Then click "Next: Review policy". Give your policy a meaningful name, for example, DynamoDBPutItemPolicy.

Review the policy JSON to ensure it grants dynamodb:PutItem permission on your specific myTable ARN. Then click "Create policy".

Your Lambda function now has the necessary permissions to write to your DynamoDB table!

Step 3: Connect the Frontend to the Backend with Amazon API Gateway

Now that we have our Lambda function ready, we need a way for our web page to talk to it. That's where API Gateway comes in.

In the AWS Management Console search bar, type "API Gateway" and select "API Gateway" from the results.

1. Create a New API:

On the API Gateway dashboard, under "REST API" (not Private, WebSocket, or HTTP API), click the "Build" button.

Figure 10: Starting the creation of a new REST API in API Gateway.

2. Configure API Settings:

• Choose the protocol: Select REST.

• Create new API: Select New API.

• API name: Give your API a clear name, e.g., SumCalculatorAPI.

• Endpoint Type: Choose Regional (default).

Then click "Create API".

3. Create a Resource:

After creating the API, you'll be taken to its dashboard. From the "Actions" dropdown menu, select "Create Resource".

• Resource Name: You can leave this as calculator or whatever makes sense. For a simple calculator endpoint, we can even leave it empty, and just work with the root / path. Let's keep it simple for now, and apply the method directly to the root resource (/). If you're building a more complex API with many functions, creating specific resources is good practice.

• Path Part: Leave as / (root path).

Then click "Create Resource".

4. Create a Method (POST):

With the root resource (/) selected in the left navigation panel, from the "Actions" dropdown menu, select "Create Method".

Choose "POST" from the dropdown that appears and click the checkmark button next to it. We use a POST request because we are sending data (the two numbers) to the server to create a new calculation record (or perform an action that changes data).

Here are the setup details:

• Integration type: Select Lambda Function.

• Use Lambda Proxy integration: Check this box.

  • What is Lambda Proxy Integration? This tells API Gateway to send the entire incoming request (headers, body, query parameters) directly to your Lambda function as part of the event object, and also to take the entire response from Lambda and pass it back directly to the client. It simplifies the setup because you don't have to map specific request/response fields.

• Lambda Region: Select the AWS region where you created your Lambda function (e.g., us-east-1 if you used that).

• Lambda Function: Start typing the name of your Lambda function (e.g., SumCalculatorFunction or AddFunc) and select it from the dropdown list.

Then click "Save". You'll likely get a pop-up asking to confirm adding permissions to Lambda. Click "OK". This automatically grants API Gateway permission to invoke your Lambda function.

Figure 11: Configuring the POST method to integrate with your Lambda function.

5. Enable CORS (Cross-Origin Resource Sharing):

This is a crucial step! Our frontend (which will be hosted on AWS Amplify, a different domain) needs permission to talk to our API Gateway endpoint. CORS is a security feature built into web browsers that prevents web pages from making requests to a different domain than the one they originated from, unless explicitly allowed.

With the root resource (/) still selected, from the "Actions" dropdown menu, select "Enable CORS". A dialog box will appear. You can usually accept the default settings for this simple app. Ensure POST is selected under "Methods" and that "Access-Control-Allow-Origin" is set to '*' (meaning any origin is allowed, which is fine for a public demo).

Then click "Enable CORS and replace existing CORS headers". Click "Yes, replace existing values" when prompted.

Figure 12: Enabling CORS for your API Gateway endpoint to allow frontend access.

6. Deploy Your API:

Changes made to API Gateway methods aren't live until the API is "deployed" to a "stage." From the "Actions" dropdown menu, select "Deploy API".

• Deployment stage: Select "[New Stage]".

• Stage name: Give your stage a name, for example, dev (for development), prod (for production), and so on. dev is a good choice for this tutorial.

• Stage description: (Optional) Add a description like "Development stage for calculator API."

Then click "Deploy".

Figure 13: Deploying your API to a new stage called 'dev'.

7. Note Down the Invoke URL:

After deployment, you'll be taken to the "Stages" view. Click on your newly created stage (for example, dev) in the left navigation panel.

You will see an "Invoke URL". This is the public URL of your API endpoint.

Copy this entire Invoke URL and save it somewhere safe. This is the URL our frontend will use to send numbers to our Lambda function! It will look something like https://xxxxxxxxxx.execute-api.us-east-1.amazonaws.com/dev.

Figure 14: Copying the Invoke URL for your deployed API.

Step 4: Create Your Frontend Web Application

Now that our backend is ready to receive requests and process calculations, let's build the simple web page that users will interact with. We'll use basic HTML, CSS, and JavaScript.

You'll need to create three files in a new folder on your computer: index.html, app.js, and style.css.

1. index.html (The Structure of Our Web Page)

This file defines the basic layout and content of our calculator.

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Sum Calculator</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <h1>SUM CALCULATOR</h1>

    <form id="calculatorForm">
        <label for="num1">Number 1:</label>
        <input type="number" id="num1" required>

        <label for="num2">Number 2:</label>
        <input type="number" id="num2" required>

        <button type="submit" id="calculateBtn">
            <span id="btnText">CALCULATE</span>
            <span id="loadingSpinner" class="spinner d-none"></span> 
        </button>
    </form>

    <div id="errorAlert" class="alert d-none">
        <strong style="color: red;">Error!</strong> <span id="errorMessage"></span>
    </div>

    <div id="resultSection" class="result-box d-none">
        <h2>Calculation Result:</h2>
        <p><strong>Transaction ID:</strong> <span id="resultId"></span></p>
        <p><strong>Timestamp:</strong> <span id="resultTimestamp"></span></p>
        <p><strong>Numbers:</strong> <span id="resultNum1"></span> + <span id="resultNum2"></span></p>
        <p><strong>Sum:</strong> <span id="resultSum"></span></p>
    </div>

    <script src="app.js"></script>
</body>
</html>

• HTML code explanation:

  • <!DOCTYPE html>, <html>, <head>, <body>: These are standard HTML boilerplate tags that define the document structure.

  • <title>Sum Calculator</title>: Sets the title that appears in the browser tab.

  • <link rel="stylesheet" href="style.css">: This line links our HTML file to our style.css file, which will make our page look nice.

  • <h1>SUM CALCULATOR</h1>: The main heading of our page.

  • <form id="calculatorForm">: This is the container for our input fields and button. The id="calculatorForm" allows our JavaScript to easily find and interact with this form.

  • <label for="num1">, <input type="number" id="num1" required>: These create labels and input boxes where users can type numbers. type="number" ensures only numbers can be entered, and required means the field must be filled.

  • <button type="submit" id="calculateBtn">: This is the button that, when clicked, will trigger our JavaScript to send data to the API. type="submit" means it's part of a form submission.

  • <span id="btnText">CALCULATE</span>, <span id="loadingSpinner" class="spinner d-none"></span>: These are for managing the text on the button and showing a little spinner animation when the calculation is in progress. d-none initially hides the spinner.

  • <div id="errorAlert" ...>: A hidden section to display any error messages.

  • <div id="resultSection" ...>: A hidden section to display the results of a successful calculation. We use <span> tags with IDs inside to update specific pieces of information (like resultId, resultSum, and so on) using JavaScript.

  • <script src="app.js"></script>: This line links our HTML file to our app.js file. This is where all the interactive logic for our calculator will reside. It's placed at the end of the <body> so that the HTML elements are fully loaded before the JavaScript tries to access them.

2. app.js (The Brains of Our Frontend)

This JavaScript file handles the interaction on the web page: getting numbers, sending them to our API, and displaying the results or errors.

Remember to replace <YOUR Invoke URL> with the actual Invoke URL you copied from API Gateway in Step 3 above!

document.addEventListener('DOMContentLoaded', function() {
    // Define the API endpoint. REPLACE THIS WITH YOUR ACTUAL API GATEWAY INVOKE URL!
    const API_ENDPOINT = 'https://YOUR_API_GATEWAY_INVOKE_URL_HERE.execute-api.us-east-1.amazonaws.com/dev'; // Example: https://5nur6rhsjb.execute-api.us-east-1.amazonaws.com/dev

    // Get references to our HTML elements so we can interact with them.
    const calculatorForm = document.getElementById('calculatorForm');
    const num1Input = document.getElementById('num1');
    const num2Input = document.getElementById('num2');
    const calculateBtn = document.getElementById('calculateBtn');
    const btnText = document.getElementById('btnText');
    const loadingSpinner = document.getElementById('loadingSpinner');
    const errorAlert = document.getElementById('errorAlert');
    const errorMessage = document.getElementById('errorMessage');
    const resultSection = document.getElementById('resultSection');

    // References to the elements where we'll display the results.
    const resultId = document.getElementById('resultId');
    const resultTimestamp = document.getElementById('resultTimestamp');
    const resultNum1 = document.getElementById('resultNum1');
    const resultNum2 = document.getElementById('resultNum2');
    const resultSum = document.getElementById('resultSum');

    // Listen for when the calculator form is submitted (i.e., when the "CALCULATE" button is clicked).
    calculatorForm.addEventListener('submit', function(event) {
        event.preventDefault(); // Prevent the default form submission behavior (which would refresh the page).

        // Hide any previous error messages or results before a new calculation.
        errorAlert.classList.add('d-none'); // 'd-none' is a class (from our CSS) to hide elements.
        resultSection.classList.add('d-none');

        // Get the values entered by the user in the input fields and convert them to numbers.
        const num1 = parseFloat(num1Input.value);
        const num2 = parseFloat(num2Input.value);

        // Basic input validation: Check if the values are actually numbers.
        if (isNaN(num1) || isNaN(num2)) {
            showError('Please enter valid numbers'); // Display an error if inputs are not numbers.
            return; // Stop the function here.
        }

        // Show a loading state on the button to indicate that a calculation is in progress.
        setLoadingState(true);

        // Prepare the data to be sent to our API Gateway in JSON format.
        const requestData = {
            num1: num1,
            num2: num2
        };

        // Use the Fetch API to send a POST request to our API Gateway endpoint.
        fetch(API_ENDPOINT, {
            method: 'POST', // We are sending data, so it's a POST request.
            headers: {
                'Content-Type': 'application/json' // Tell the API we're sending JSON data.
            },
            body: JSON.stringify(requestData) // Convert our JavaScript object to a JSON string.
        })
        .then(response => {
            // Check if the network response was OK (status code 200-299).
            if (!response.ok) {
                // If not OK, try to parse the error message from the response body.
                return response.json().then(errData => {
                    throw new Error(errData.message || 'Server error');
                });
            }
            // If OK, parse the successful response body as JSON.
            return response.json();
        })
        .then(data => {
            // Once we get a response, hide the loading state.
            setLoadingState(false);

            // Process the response from our Lambda function.
            // Our Lambda function wraps the actual result in a 'body' string, so we need to parse it again.
            if (data.statusCode && data.statusCode === 200 && data.body) {
                try {
                    // Try to parse the nested 'body' string into a JavaScript object.
                    const resultData = typeof data.body === 'string' 
                        ? JSON.parse(data.body) 
                        : data.body;

                    // Display the calculation result on the page.
                    displayResult(resultData);
                } catch (err) {
                    showError('Error parsing the result: ' + err.message);
                }
            } else {
                showError('Unexpected API response format'); // If the response isn't what we expect.
            }
        })
        .catch(error => {
            // Catch any errors that occurred during the fetch operation (e.g., network issues, API errors).
            setLoadingState(false); // Hide loading state even on error.
            showError(error.message || 'An error occurred while communicating with the API');
        });
    });

    // Helper function to display an error message.
    function showError(message) {
        errorMessage.textContent = message; // Set the error message text.
        errorAlert.classList.remove('d-none'); // Show the error alert.
    }

    // Helper function to manage the button's loading state.
    function setLoadingState(isLoading) {
        if (isLoading) {
            btnText.textContent = 'Calculating...'; // Change button text.
            loadingSpinner.classList.remove('d-none'); // Show spinner.
            calculateBtn.disabled = true; // Disable button to prevent multiple clicks.
        } else {
            btnText.textContent = 'CALCULATE'; // Reset button text.
            loadingSpinner.classList.add('d-none'); // Hide spinner.
            calculateBtn.disabled = false; // Enable button.
        }
    }

    // Helper function to display the successful calculation result.
    function displayResult(data) {
        // Ensure we have the 'result' object from the API response.
        if (!data.result) {
            showError('No result data in the API response');
            return;
        }

        const result = data.result;

        // Format the timestamp into a human-readable date and time.
        let timestampDisplay = result.Timestamp;
        if (result.Timestamp && !isNaN(result.Timestamp)) {
            const date = new Date(parseInt(result.Timestamp) * 1000); // Convert milliseconds to Date object.
            timestampDisplay = date.toLocaleString(); // Format to local date/time string.
        }

        // Update the text content of our result display elements.
        resultId.textContent = result.ID || 'N/A';
        resultTimestamp.textContent = timestampDisplay || 'N/A';
        resultNum1.textContent = result.num1;
        resultNum2.textContent = result.num2;
        resultSum.textContent = result.sum;

        // Show the result section.
        resultSection.classList.remove('d-none');
    }
});

• JavaScript code explanation – there’s a lot going on here:

  • document.addEventListener('DOMContentLoaded', function() { ... });: This ensures our JavaScript code runs only after the entire HTML document has been loaded and parsed.

  • const API_ENDPOINT = '...';: This is where you MUST paste your API Gateway Invoke URL from step 3 above. This line defines where our frontend will send its requests.

  • document.getElementById(...): These lines are how JavaScript "grabs" specific elements from our HTML using their id attributes. This allows us to read values from inputs or change the text/visibility of other elements.

  • calculatorForm.addEventListener('submit', function(event) { ... });: This sets up an "event listener." It waits for the calculatorForm to be submitted (when the "CALCULATE" button is clicked) and then runs the code inside this function. event.preventDefault() stops the browser from reloading the page, which is the default behavior for form submissions.

  • parseFloat(num1Input.value): This gets the text value from the input fields and converts them into decimal numbers.

  • if (isNaN(num1) || isNaN(num2)): This checks if the user entered actual numbers. isNaN means "is Not a Number."

  • fetch(API_ENDPOINT, { ... }): This is the core part that communicates with our backend.

    • method: 'POST': Specifies that we're sending data.

    • headers: { 'Content-Type': 'application/json' }: Tells the API Gateway that the data we're sending is in JSON format.

    • body: JSON.stringify(requestData): Converts our JavaScript requestData object into a JSON string that can be sent over the network.

  • .then(response => response.json()): After the fetch call, these .then() blocks handle the response. The first one checks if the network request was successful (response.ok) and then parses the response body as JSON.

  • .then(data => { ... }): This block is executed once the JSON data from the API is received. It updates the frontend with the result or shows an errorAlert. Notice JSON.parse(data.body) is used because our Lambda function returns the actual data inside a body string within the overall JSON response.

  • .catch(error => { ... }): This block catches any errors that happen during the fetch operation (for example, network issues, or errors returned from the API).

  • showError(), setLoadingState(), displayResult(): These are helper functions to keep our code organized. They handle showing messages, toggling the loading spinner, and updating the result display.

  • classList.add('d-none'), classList.remove('d-none'): These are used to dynamically hide and show HTML elements by adding or removing a CSS class named d-none.

3. style.css (The Look of Our Web Page)

This CSS file adds some basic styling to make our calculator look presentable.

/* Basic styling for the body */
body {
    background-color: #222629; /* Dark background */
    color: #FFFFFF; /* White text for contrast */
    font-family: system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;
    padding: 20px;
    display: flex;
    flex-direction: column;
    align-items: center; /* Center content horizontally */
    min-height: 100vh; /* Full viewport height */
    margin: 0;
}

h1 {
    color: #86C232; /* A vibrant green for the heading */
    margin-bottom: 30px;
}

/* Styling for labels (text next to input fields) */
label {
    font-size: 18px;
    margin-right: 10px;
    display: inline-block; /* Allows labels and inputs to be on the same line */
    width: 80px; /* Give labels a consistent width */
    text-align: right;
}

/* Styling for input fields */
input[type="number"] {
    background-color: #333;
    border: 1px solid #444;
    color: #FFFFFF;
    padding: 8px 12px;
    font-size: 16px;
    border-radius: 5px;
    margin-bottom: 15px; /* Space below each input row */
    width: 150px; /* Consistent width for inputs */
    outline: none; /* Remove default outline */
}

input[type="number"]:focus {
    border-color: #86C232; /* Highlight border on focus */
    box-shadow: 0 0 0 3px rgba(134, 194, 50, 0.5); /* Green glow on focus */
}

/* Styling for the CALCULATE button */
button {
    background-color: #86C232; /* Green background */
    border: none; /* No border */
    color: #FFFFFF; /* White text */
    font-size: 18px;
    font-weight: bold;
    padding: 10px 20px;
    border-radius: 5px;
    cursor: pointer; /* Indicate it's clickable */
    transition: background-color 0.3s ease; /* Smooth transition for hover effect */
    display: flex; /* Allow spinner inside */
    align-items: center;
    justify-content: center;
    gap: 10px; /* Space between text and spinner */
    margin-top: 20px;
    width: 180px; /* Consistent width */
}

button:hover:not(:disabled) {
    background-color: #6a9b2b; /* Darker green on hover */
}

button:disabled {
    background-color: #555; /* Grey out when disabled */
    cursor: not-allowed;
}

/* Styling for the form container */
#calculatorForm {
    background-color: #333;
    padding: 30px;
    border-radius: 8px;
    box-shadow: 0 4px 8px rgba(0, 0, 0, 0.2);
    display: flex;
    flex-direction: column;
    align-items: flex-start; /* Align form elements to the left */
    margin-bottom: 30px;
}

/* Styling for the loading spinner */
.spinner {
    border: 3px solid rgba(255, 255, 255, 0.3);
    border-top: 3px solid #FFFFFF;
    border-radius: 50%;
    width: 20px;
    height: 20px;
    animation: spin 1s linear infinite; /* Animation for spinning */
}

@keyframes spin {
    0% { transform: rotate(0deg); }
    100% { transform: rotate(360deg); }
}

/* Styling for the error message alert */
.alert {
    background-color: #330d0d; /* Dark red background for errors */
    border: 1px solid #ff4d4d; /* Red border */
    color: #ff4d4d; /* Red text */
    padding: 10px 15px;
    border-radius: 5px;
    margin-top: 20px;
    width: 100%;
    max-width: 400px;
    text-align: center;
}

/* Styling for the result display box */
.result-box {
    background-color: #333;
    border: 1px solid #86C232; /* Green border for results */
    padding: 20px;
    border-radius: 8px;
    box-shadow: 0 4px 8px rgba(0, 0, 0, 0.2);
    width: 100%;
    max-width: 400px;
    margin-top: 20px;
    animation: fadeIn 0.5s ease-in-out; /* Fade-in animation */
}

.result-box h2 {
    color: #86C232;
    margin-top: 0;
    border-bottom: 1px solid #444;
    padding-bottom: 10px;
    margin-bottom: 15px;
}

.result-box p {
    margin-bottom: 8px;
}

.result-box strong {
    color: #99EE33; /* Slightly brighter green for strong text */
}

/* Utility class to hide elements */
.d-none {
    display: none !important;
}

/* Keyframe animation for fade-in effect */
@keyframes fadeIn {
    from { opacity: 0; transform: translateY(10px); }
    to { opacity: 1; transform: translateY(0); }
}

• CSS code explanation:

  • body { ... }: Styles the overall page background, text color, font, and centers the content.

  • h1 { ... }: Styles the main heading.

  • label { ... }, input[type="number"] { ... }: Styles the input fields and their labels, making them look consistent and user-friendly. input:focus adds a visual highlight when an input field is clicked.

  • button { ... }: Styles the "CALCULATE" button, giving it a distinct look and adding a hover effect. button:disabled changes its appearance when it's temporarily inactive.

  • #calculatorForm { ... }: Styles the container for our input form, giving it a background, padding, and a subtle shadow.

  • .spinner { ... }, @keyframes spin { ... }: These define the style and animation for the loading spinner that appears on the button while the calculation is in progress.

  • .alert { ... }: Styles the error message box, giving it a red background and text to clearly indicate an error.

  • .result-box { ... }: Styles the box where the calculation results are displayed, giving it a green border and a fade-in animation.

  • .d-none { display: none !important; }: This is a utility class. When this class is added to an HTML element via JavaScript, it will completely hide that element from the page. Removing the class makes it visible again. The !important ensures this style overrides any other conflicting display styles.

  • @keyframes fadeIn { ... }: This defines a simple animation that makes an element gradually appear (fade in) while slightly moving upwards, making the appearance of results smoother.

Step 5: Deploy Your Frontend with AWS Amplify

Finally, let's get our frontend web application online using AWS Amplify. Amplify makes it incredibly easy to host static websites.

1. Prepare Your Frontend Files:

Make sure you have all three files (index.html, app.js, style.css) in a single folder on your computer.

Compress this folder into a ZIP file. Ensure the index.html file is at the root of the ZIP file (not nested inside another subfolder within the ZIP).

2. Navigate to the AWS Amplify Console:

In the AWS Management Console search bar, type "Amplify" and select "AWS Amplify" from the results.

3. Deploy Without a Git Provider:

On the Amplify console, you'll see options to connect to a Git provider (like GitHub, GitLab, and so on). For simplicity in this tutorial, we'll choose to deploy manually.

Under "Deploy without Git provider", click "Deploy".

Figure 15: Choosing to deploy your web app manually with AWS Amplify.

4. Upload Your Files:

• App name: Give your application a name, e.g., SumCalculatorWebApp.

• Environment name: You can use dev or main.

• Drag and drop or browse files: Click on the "drag and drop" area or "Choose files" button.

• Select the ZIP file you created in step 5 above.

  

Figure 16: Naming your Amplify app and uploading the ZIP file containing your frontend.

5. Review and Deploy:

Now, click "Save and Deploy". Amplify will now take your ZIP file, extract its contents, and deploy your static website to a global content delivery network (CDN) provided by AWS CloudFront. This makes your website load quickly for users anywhere in the world. This process may take a few minutes.

6. Access Your Live Application:

Once the deployment is complete, Amplify will provide you with a "Domain" URL. Click on this URL. This is your live, public web application!

Figure 17: Your deployed Sum Calculator web app with its public URL.

How to Test Your Application: Is It Working?

Now for the exciting part – let's test our fully serverless web application by following these steps:

1. Open your amplify app URL: Navigate to the "Domain" URL provided by AWS Amplify (from Step 5.6).

2. Enter numbers: In the "Number 1" and "Number 2" input fields, type in any two numbers (e.g., 5 and 10).

3. Click "CALCULATE": Click the "CALCULATE" button. You should briefly see "Calculating..." on the button.

4. Observe the Result: If everything is set up correctly, you should see the "Calculation Result" box appear below the form, displaying the Transaction ID, Timestamp, the numbers, and their sum!

5. Verify in DynamoDB (Optional):

   • Go back to your DynamoDB console.

   • Click on your myTable.

   • Click on the "Explore table items" tab.

   • You should now see new entries (items) corresponding to each calculation you performed on your web app, with the ID, Timestamp, num1, num2, and sum stored!

Common Issues and Solutions

Sometimes things don't work perfectly on the first try. Here are some common problems and how to fix them:

CORS Errors (Cross-Origin Resource Sharing):

• Symptom: Your web browser's developer console (usually accessible by pressing F12 or right-clicking and selecting "Inspect") shows errors like "Access to fetch at '...' from origin '...' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present..."

• Solution: This means your frontend isn't allowed to talk to your API Gateway. Go back to Step 3, part 5 (Enable CORS) in API Gateway and ensure you've enabled CORS for your API. Make sure POST is selected and that the Access-Control-Allow-Origin is properly configured (for this tutorial, '*' is fine, but in production, you'd specify your Amplify domain).

Lambda Timeouts:

• Symptom: Your web app keeps showing "Calculating..." or gets a generic error, and in your Lambda function's logs (CloudWatch Logs), you see "Task timed out".

• Solution: Your Lambda function took too long to execute. For a simple sum calculator, this is unlikely, but for more complex operations, you might need to increase the "Timeout" setting for your Lambda function. You can find this under your Lambda function's "Configuration" tab, in the "General configuration" section.

DynamoDB Permissions Errors:

• Symptom: Your Lambda function execution fails, and in its CloudWatch logs, you see an error like "User: arn:aws:sts::... is not authorized to perform: dynamodb:PutItem on resource: arn:aws:dynamodb:..."

• Solution: This means your Lambda function doesn't have the necessary permissions to write to your DynamoDB table. Go back to Step 2, part 2 (about updating Lambda Function permissions) and ensure you've correctly added the dynamodb:PutItem action and specified your myTable's ARN as the resource.

Incorrect API Gateway Invoke URL:

• Symptom: Your frontend makes a request, but it either fails immediately, or you get a network error in the browser console.

• Solution: Double-check that the API_ENDPOINT constant in your app.js file is exactly the Invoke URL you copied from API Gateway. Even a tiny typo can break the connection.

Next Steps: Enhance Your Application

This calculator is a great starting point, but you can expand it significantly:

• Add authentication: Implement user login and signup (for example, using AWS Amplify Auth with Amazon Cognito) so only authorized users can use the calculator.

• Implement error handling: Make the frontend more robust by displaying specific error messages based on what the backend sends.

• Create a calculation history view: Extend your frontend to fetch and display a list of all past calculations stored in DynamoDB. This would involve another Lambda function and API Gateway endpoint (for example, a GET method).

• Add input validation: Implement more robust validation on both the frontend (JavaScript) and backend (Lambda) to handle non-numeric inputs or other edge cases.

• Implement real-time updates: Use AWS AppSync (GraphQL) or WebSockets with API Gateway to push new calculation results to the frontend in real-time, without needing a page refresh.

Conclusion

Congratulations! You've successfully built and deployed a fully functional serverless web application on AWS. You've seen how to leverage powerful services like AWS Lambda, Amazon API Gateway, Amazon DynamoDB, and AWS Amplify to create a scalable, cost-effective, and low-maintenance application.

This architecture is incredibly powerful because it can scale automatically to handle thousands or even millions of users without you needing to manage a single server. Remember to clean up your AWS resources when you're done experimenting to avoid unnecessary charges.

Resources for Further Learning

• AWS Lambda Documentation: Dive deeper into serverless functions.

• Amazon DynamoDB Developer Guide: Learn more about NoSQL databases.

• Amazon API Gateway Tutorials: Explore building various types of APIs.

• AWS Amplify Documentation: Discover more features for building and deploying full-stack applications.

But here’s the thing: traditionally, to do this, you would have to manage lots of infrastructure – resources on which your application will be deployed – which can be a real headache. You’d have servers (VM instances or physical computers) to configure, databases to scale, load balancers to monitor...it’s a whole lot 😩

This is where Serverless architecture comes to the rescue. With the Serverless model, you can deploy your applications to handle thousands of users without you having to worry about incurring too much cost, managing infrastructure, servers, networking, and so on.

In this article, you’ll learn about Serverless Architecture: what it’s all about, and how to deploy your very own application using AWS Lambda. We’ll walk through the entire process step-by-step:

• How to clone your application repository using Git.

• How to build an image of your application using Docker.

• How to install the AWS CLI on your local machine and create AWS IAM users with the right permissions to push your Docker image to AWS Elastic Container Registry (ECR).

Once the image is up and running on ECR, we’ll then connect it to AWS Lambda and deploy the container to Lambda for a fully serverless experience. 💡✨

Ready to go serverless? Let’s get started! 🚀

Table of Contents

1. What is Serverless Architecture?

2. Differences Between Serverless and Other Deployment Models ⚡

3. 🧠 Prerequisites — What You Should Know Before Following Along!

4. How to Set Up the Application Using Git 🐙

5. Understanding the Codebase 🔎

6. How to Create a Docker Image of the Application 🐋

7. How to Create a Container Registry on AWS Elastic Container Registry (ECR) 📁

8. IAM with AWS: How to Create a User on AWS IAM to Allow Access to Your AWS ECR 👤🔐

9. How to Upload Your Docker Image to the AWS ECR repository ⬆️

10. How to Deploy the Application Container to AWS Lambda from the Image on AWS ECR 🚀

11. Advantages of Adopting the Serverless Model in Businesses 💼

12. Disadvantages of the Serverless Model 🚫

13. When to Adopt the Serverless Model 🤔

14. Conclusion 📝

15. About the Author 👨‍💻

What is Serverless Architecture?

Before we dive deeper, let’s break down what we mean by Servers. In the tech world, servers are powerful computers that store, process, and manage data. Think of them as the behind-the-scenes workhorses that:

• Store your data: Like a central filing cabinet for your digital documents.

• Run your applications: They execute the code that keeps your app or website running.

• Handle requests: Servers respond to user requests – like loading a webpage or processing a login.

Alright, now let’s talk about Serverless Architecture – but first, let’s clear up a common misconception. When most people hear the word "Serverless", they immediately think, "Wait… no servers? How does that even work?!" 😅

Here’s the truth: Serverless doesn’t mean there are no servers involved (surprise, surprise! 😉). Instead, it means you, as a developer, don’t have to worry about managing the servers that your application runs on. The server-side infrastructure is fully handled by the cloud provider – in this case, AWS Lambda. You just focus on writing code and deploying it, and AWS takes care of the rest.

So, What’s the Big Deal with Serverless?

In a traditional setup, when you deploy your application, you’re responsible for things like:

• Provisioning servers (how many servers do you need? What size?)

• Scaling resources (how do you handle traffic spikes without overpaying?)

• Monitoring and keeping everything running smoothly.

Sounds like a lot, right? 🤯 Well, Serverless Architecture simplifies all of that by letting you focus purely on your application code. With Lambda, you can run code in response to events (like an HTTP request, a file upload, or a database change) without worrying about the infrastructure behind it. AWS automatically scales the compute resources as needed, charging you only for the time your code is actually running. ⏱️💸

Imagine you’re at a restaurant. Instead of running the kitchen yourself (like managing your own servers), you just place an order (your code) and the chef (AWS Lambda) makes it for you, on-demand, based on what you need. 🍽️🍴

Differences Between Serverless and Other Deployment Models ⚡

Now that you understand how Serverless works, let’s take a little detour and explore the other models used to deploy applications. After all, Serverless isn’t the only kid on the block, and this will give you some important perspective when choosing the right model for your use case. 👀

When you build an app, you need somewhere to host it – a home for your code to live and run. Over the years, the tech world has come up with different ways to handle this, and each one gives you a different level of control (and responsibility) over your servers.

Let’s break it down.

🏠 Infrastructure as a Service (IaaS)

With IaaS, cloud providers like AWS, Google Cloud, or Microsoft Azure give you the building blocks – virtual servers (also called instances), storage, and networking tools – but it’s still your job to set everything up.

It’s like renting an empty apartment. You get the walls, the doors, and the roof, but you still have to bring your own furniture, set up your Wi-Fi, and clean the place regularly. 🏡🧹

When you choose IaaS, you’re responsible for:

• Configuring the servers (choosing the size, the operating system, and installing software).

• Handling updates, patches, and security.

• Scaling up or down when traffic changes.

Example: Amazon EC2 (Elastic Compute Cloud) is a classic IaaS service. You rent a virtual machine, set it up yourself, and manage it like a digital landlord.

🎯 Platform as a Service (PaaS)

Next up, we’ve got PaaS – a more polished setup.

In this model, the cloud provider takes care of the infrastructure and the underlying operating system, so you don’t have to. You just upload your code, configure a few settings, and the platform runs your app.

It’s like moving into a fully furnished apartment — the kitchen works, the lights are on, and the Wi-Fi is already connected. You just show up with your bags and get to work! 🧳✨

Example: AWS Elastic Beanstalk, Heroku, or Google App Engine.

🌩️ Serverless: The Special PaaS

Now here’s where things get interesting: Serverless actually falls under the PaaS umbrella, but it deserves its own spotlight. Why? Because it takes the convenience of PaaS and pushes it to the next level.

In a traditional PaaS model (like AWS Fargate or Heroku), your application is running 24/7, whether you have visitors using it or not. You pay for the reserved space and compute power all month long, just like renting an apartment. Even if you didn’t sleep there the entire month, the bill still comes at the end. 💸🏡

But with Serverless, the rules change. You only pay when your code is actually being used.

How Applications Run in the Serverless Model ⚙️

In a Serverless model, your application isn’t just sitting there running all day. It “wakes up” only when it’s needed. But what exactly causes it to wake up? That’s where triggers come in.

Triggers are events that tell your Serverless application, “Hey, it’s time to do something!” These events could be all sorts of things, like:

• A user visiting your website and clicking a button.

• Someone uploading a file to your cloud storage (like an image or document).

• A new row being added to a database.

• An automated schedule (like a reminder that runs every day at 8 AM).

When one of these events happens, your application instantly comes to life, runs the exact task you programmed, and then goes back to “sleep” until the next trigger. This is how Serverless keeps your cloud costs low and your resources efficient – no constant running in the background, only action when there’s actually something to do!.⚡😎

For example, if a user sends a request that triggers your application to run for just 10 seconds and uses 20MB of memory, that’s all you pay for — the exact time and resources consumed.

No users? No requests? No payment. Now that’s a smart way to save money. 🧠💰

💡 Quick Comparison: PaaS vs Serverless

🧠 Prerequisites — What You Should Know Before Following Along

Before we dive in, here’s the best part: I wrote this article to be super beginner-friendly and detailed, so even if you have little to no programming background, you’ll still be able to follow along.

Whether you’re a developer, a tech-curious startup, or a business leader trying to understand modern cloud solutions, this guide was written for you.

That said, having some light knowledge in these areas will make the ride even smoother:

• 🧑‍💻 Basic Programming Concepts – like how Node.js apps run and what a server does.

• 💡 Familiarity with Common Tech Terms – words like “deploy,” “application,” “CPU,” and “software” will pop up, but don’t worry: I’ve done my best to break these down into simple, relatable explanations.

No prior cloud experience? No problem! This guide holds your hand all the way from setup to deployment – all in plain language, no jargon.

So buckle up, and let’s proceed with deploying your very own application to AWS Lambda. 😁

How to Set Up the Application Using Git 🐙

Before we jump into writing code or deploying anything, the very first step is to grab the application we’ll be working with — and for that, we’ll be using Git.

But wait... what’s Git? — It’s a Version Control System (VCS) that helps developers track changes to their code, collaborate with teammates without stepping on each other’s toes, and safely store their work in a central place — like GitHub.

Clone the Application Repository 🧑‍💻

I’ve already created a simple project for us to use in this tutorial — it’s sitting pretty on GitHub, waiting for you.

To clone the project onto your local machine, open up your terminal and run:

git clone https://github.com/onukwilip/lambda-tutorial.git

This command will download all the code from the lambda-tutorial repository into a folder on your computer. 📁

Once the cloning is done, navigate into the project directory like this:

cd lambda-tutorial

Boom — just like that, your local machine is now set up with the same code that’s stored in the GitHub repo. 🏡

Understanding the Codebase 🔎

Open the Codebase in Your Favorite IDE 🧑‍💻

For this tutorial, we’ll be using Visual Studio Code (VS Code), but feel free to use any editor you’re comfortable with.

Once you open the lambda-tutorial project folder, you’ll notice it’s a simple Node.js web server. Nothing too fancy — just a server that can handle requests and respond with some data.

Now, it’s important to understand what’s going on inside our codebase, especially if you’re coming from deploying on platforms like Render, Vercel, or Google Cloud Run.

Deploying to Lambda vs Other Serverless Platforms ⚡

When you deploy to platforms like Vercel, Render, or Google Cloud Run, you usually package your web server just the way you wrote it – whether it’s a Node.js Express server or a Next.js app – and the platform handles it pretty much as-is.

Those platforms run your server like a mini container (or microservice) that’s always ready to handle incoming traffic, just like a waiter standing by at your table, waiting for your order.

But AWS Lambda works a little differently.

Lambda expects your code to be organized around functions – not full web servers. Think of Lambda as a chef that only shows up the moment an order is placed, cooks the food, and disappears once the job is done. 👨‍🍳🍽️

So if you’ve got a full-blown Node.js Express server, you’ll need to do a tiny bit of “translation” to fit Lambda’s expectations – and that’s where the lambda.js file comes in.

The lambda.js File — Your Lambda Translator 🔀

Here’s what the file looks like:

const serverless = require("serverless-http");
const app = require("./app");

const handler = serverless(app);
module.exports.handler = handler;

Let’s break it down:

• const serverless = require("serverless-http");: This imports a handy little library called serverless-http. (The serverless-http library is important for our platform to run properly on AWS Lambda.) It acts like a translator: it takes your regular Express app and wraps it so that AWS Lambda can understand it.

• const handler = serverless(app);: Here’s the magic. This wraps your Express app into a Lambda-compatible function.

• module.exports.handler = handler;: This exports your wrapped function so AWS Lambda can call it when the application is triggered.

So, instead of starting your server like this:

app.listen(5000, () => {
  console.log("Server running on port 5000");
});

You’re handing your app over to Lambda and letting it handle incoming requests, scale, and run the app only when it’s needed.

The app.js File — Your Classic Express App 💻

Your app.js is where the main application logic lives. Here is usually where you:

• Set up Express.

• Define routes (like /api, /users, /hello).

• Apply middleware (like JSON parsing, logging, CORS, and so on).

• Handle HTTP requests and send back responses.

In a normal deployment (Render, Google Cloud Run, DigitalOcean, or your own server), you’d start the server using app.listen(PORT) at the bottom of this file.

But since we’re deploying to Lambda, you don’t directly start the server here. Instead, you export the app like this:

module.exports = app;

This way, your application stays “server-agnostic” – it’s not hardcoded to run on a traditional server. Lambda (via the lambda.js file) takes care of starting and stopping your app whenever it’s triggered by an event (like an HTTP request). Smart, right? 💡

Why this setup? 🤔

This little separation gives you flexibility:

• You can write your Node.js app like you always would (using Express) inside app.js.

• And you only tweak the entry point (via lambda.js) to fit AWS Lambda’s expectations.

How to Create a Docker Image of the Application 🐋

Now that we’ve had a good look at the code, let’s package it up the smart way — using Docker.

What is Docker? 🐳

Now, you might be wondering, "Why are we using Docker?"

Docker is a software for creating images of your applications and running those images as containers. Just like real-world shipping containers hold goods securely, Docker containers hold your app, bundled with everything it needs to run: its code, libraries, dependencies, and settings. Everything is all wrapped up neatly, so your app runs the same way everywhere, whether on your laptop, AWS Lambda, or even your friend’s machine.

Let’s Take a Look at the Dockerfile 🔍

Inside your project folder, you’ll find a file named Dockerfile. This is basically the recipe that Docker uses to build your app’s container image.

Here’s what it looks like:

FROM node:18-slim AS builder

WORKDIR /app

COPY package.json .

RUN npm i -f

COPY . .

USER root

FROM amazon/aws-lambda-nodejs

ENV PORT=5000

COPY --from=builder /app/ ${LAMBDA_TASK_ROOT}
COPY --from=builder /app/node_modules ${LAMBDA_TASK_ROOT}/node_modules
COPY --from=builder /app/package.json ${LAMBDA_TASK_ROOT}
COPY --from=builder /app/package-lock.json ${LAMBDA_TASK_ROOT}

EXPOSE 5000

CMD [ "lambda.handler" ]

Let’s break down the important steps— in plain English: 😎

• FROM node:18-slim AS builder: We start by using a lightweight version of Node.js called node:18-slim and give it a tag named builder (think of it as Stage 1). This gives us the tools we need to build a Node.js app, but without extra stuff that makes the image heavy. The tag builder enables us to re-use the content of this build in the next stage

• WORKDIR /app: We set the working directory inside the container to /app. Think of this as telling Docker: "Hey, this is the folder where I’ll be working from!"

• COPY package.json .: This copies the package.json file (which lists your app’s dependencies) into the /app folder inside the container.

• RUN npm i -f: This installs all the Node.js dependencies (the packages your app needs to work).
  The -f flag forces npm to resolve conflicts if any pop up.

• COPY . .: This copies the rest of your project files from your computer into the container.

• USER root: This sets the user to root (administrator level) inside the container. Useful when extra permissions are needed for certain tasks.

• FROM amazon/aws-lambda-nodejs: Now here’s the switch: we swap to the official AWS Lambda base image for Node.js! That is, Stage 2. This image is designed to work smoothly when deploying containers to Lambda.

• ENV PORT=5000: We set an environment variable for the server port. Our app will listen on port 5000.

• COPY --from=builder /app/ ${LAMBDA_TASK_ROOT}: This grabs all the files from the builder stage and copies them into Lambda’s special working directory (${LAMBDA_TASK_ROOT}).

• COPY --from=builder /app/node_modules ${LAMBDA_TASK_ROOT}/node_modules: Same thing, but this one specifically copies the node_modules folder (all your installed dependencies) into Lambda’s working directory.

• COPY --from=builder /app/package.json ${LAMBDA_TASK_ROOT}: Copies the package.json file into Lambda’s working directory.

• COPY --from=builder /app/package-lock.json ${LAMBDA_TASK_ROOT}: Copies the lock file for your dependencies – so Lambda knows exactly which versions of libraries to use.

• EXPOSE 5000: This tells Docker, “Hey, my app is going to listen for requests on port 5000!" (Though Lambda doesn’t use this directly, it’s useful for local testing.)

• CMD [ "lambda.handler" ]: This tells AWS Lambda which function to run when the container starts.
  In this case, it’s looking for a handler function inside your app – that’s the entry point!

How to Create Our Own Docker Image

Before we proceed, you need to have Docker running on your machine. If you haven’t installed Docker yet, check out the official installation guide here: Docker Installation Tutorial. It’s a great resource to get Docker up and running.

Ensure Docker is Running

Make sure Docker Desktop is installed and running. You can usually tell by the Docker icon in your system tray. If it’s not running, start it up before proceeding.

Build the Docker Image

Now, it’s time to create a Docker image of our application. In your terminal, navigate to the root directory of your project (where your Dockerfile is located). Then run the following command:

docker build -t demo-lambda-project:latest .

• The docker build command tells Docker to create an image.

• The -t demo-lambda-project:latest flag assigns a tag (or name) to your image (we’ll change this later to the image naming convention supported by AWS Elastic Container Registry – ECR).

  • Here, demo-lambda-project is the name, and latest is the tag indicating the most recent build.

• The . at the end tells Docker to look for the Dockerfile in the current directory.

What This Does

Docker will now follow the instructions in your Dockerfile step-by-step. It starts by building your Node.js app (using the lightweight Node 18 image), installs the dependencies, and then copies everything over to an AWS Lambda-ready image. Once done, you have a neat image tagged as demo-lambda-project:latest that’s ready for deployment.

How to Create a Container Registry on AWS Elastic Container Registry (ECR) 📁

Okay, let’s dive into creating an image registry on AWS Elastic Container Registry (ECR). Follow these steps closely to set up your repository named lambda-practice:

Step 1: Sign In and Navigate to AWS ECR

Log in to your AWS Management Console: https://console.aws.amazon.com/console/home.

In the search bar at the top, type "ECR". You should see Amazon ECR pop up in the dropdown results. Click on it to navigate to the Elastic Container Registry section.

Step 2: Start Creating Your Repository

Once you’re in the ECR section, look for a button that says "Create repository". Click this button to start setting up your new container registry.

Step 3: Configuring the Repository Details

You’ll need to add some info like:

• Repository name: In the form that appears, enter lambda-practice as the repository name. This name will be used to reference your repository later when uploading your Docker image.

• Tag mutability: You’ll also see an option for Tag Mutability. For this tutorial, set it to Mutable. This means that if you need to update or change a tag on your image later, you can do so. (Keep in mind that in some scenarios, you might want immutable tags for images used in production environments – but mutable tags are great for testing and development, especially since we want to use the tag latest for our images.)

When you’re happy with the settings, click the "Create repository" button at the bottom of the form.

Repository Created – Now Let's Take a Look

After creating the repository, AWS will redirect you to the page listing your repositories.

Find the repository named lambda-practice in the list. This is your newly created container registry where you can push Docker images.

Copy the lambda-practice repository URI, which we’ll need later when we push our image from our local machine. The URI should be in a format similar to this - <aws_account_id>.dkr.ecr.<region>.amazonaws.com/lambda-practice

And that’s it! You’ve now successfully created a container registry on AWS ECR and have your repository (lambda-practice) ready to receive your Docker image. 🚀

IAM with AWS: How to Create a User on AWS IAM to Allow Access to Your AWS ECR 👤🔐

Now that we’ve successfully created our AWS ECR container registry (the home for our Docker image), it's time to make sure our local machine has the necessary permissions to interact with that registry. Without proper authorization, we won’t be able to upload our image.

To do that, we’ll create an IAM user with the appropriate permissions.

Step 1: Access the IAM Console

Start by logging in to your AWS Management Console: https://console.aws.amazon.com/console/home.

In the search bar at the top, type "IAM" and select the IAM service from the dropdown. This brings you to the IAM dashboard where you can manage users, roles, policies, and more.

Step 2: Navigate to the Users Section

On the left sidebar of the IAM dashboard, click on "Users". Here you'll see a list of existing users, and this is where you'll add a new one.

Step 3: Create a New User

Click the "Add users" button at the top. In the "Set user details" step, enter the username as lambda-practice.

Step 4: Attach Permissions Directly

In the "Set permissions" step, choose "Attach policies directly". In the search box, type AmazonEC2ContainerRegistryPowerUser. Select the AmazonEC2ContainerRegistryPowerUser policy by ticking its checkbox. This policy grants the necessary permissions to work with AWS ECR, such as pushing and pulling Docker images.

Click Next, and verify that the username is lambda-practice and that the AmazonEC2ContainerRegistryPowerUser policy is attached. If everything looks good, click "Create user".

Step 5: Generate Access Keys for the User

Once the user is created, you’ll be redirected to the page listing all IAM users. Locate and click on the user lambda-practice. This action will take you to the user’s summary page.

• Navigate to the "Security credentials" tab.

• Under "Access keys", click the "Create access key" button.

• A page will appear for configuring the new access key.

In the "Access key best practices & alternatives" step, select "Command Line Interface (CLI)".

Why should you select this option? Choosing CLI ensures that the generated access key is optimized for use with the AWS CLI and other command-line tools (like Docker commands that push images to ECR), which is exactly what we need for our workflow.

Leave the other configurations as their default settings, and then click "Create access key".

Once the key is created, you’ll see the new Access key ID and Secret access key. Make sure to copy and store these credentials securely. They are essential for authorizing your local machine to access AWS ECR and perform operations with the permissions assigned to the lambda-practice user.

How to Authorize Your Local PC to Publish Images to the AWS ECR Repository

Now that we have our IAM user set up and the access keys in hand, it’s time to authenticate our local PC so we can securely push our Docker images to AWS ECR using the AWS CLI. Follow these steps:

Step 1: Install the AWS CLI

If you haven’t installed the AWS CLI on your machine yet, download and install it using the official guide here: Install the AWS CLI.

This tool allows you to interact with your AWS account right from the command line, which is essential for pushing images to ECR.

Step 2: Configure Your AWS CLI Credentials

Once installed, you need to configure your AWS CLI to use the credentials associated with the lambda-practice user. Open your terminal and run the following command to set up a new profile named lambda:

aws configure --profile lambda

You’ll be prompted to enter the following details:

• AWS Access Key ID: Paste the access key ID that you generated for the lambda-practice user.

• AWS Secret Access Key: Paste the corresponding secret access key.

• Default region name: Enter your preferred AWS region (for example, us-east-1 or your relevant region).

• Default output format: You can leave this as json or choose your preferred format.

This command configures a new CLI profile called lambda with the credentials of our IAM user.

Step 3: Verify the Configuration

To ensure everything is set up correctly, run:

aws sts get-caller-identity --profile lambda

This command will return details about the IAM user configured for the lambda profile, confirming that your local PC is now authenticated correctly.

Now you’re all set! Your AWS CLI is configured with the lambda profile, meaning your local machine has the right credentials to interact with your AWS ECR repository and push Docker images using the permissions assigned to your lambda-practice IAM user.

How to Upload Your Docker Image to the AWS ECR repository ⬆️

Uploading your Docker image to AWS ECR is the moment when your hard work gets sent off to your repository so AWS Lambda can later grab and run your container. Now that your PC is authorized to talk to ECR, let’s take a look at how to upload the image.

Step 1: Log in to ECR with Docker

Before you can push your image, you need to authenticate Docker to your AWS ECR account. You do this by running a command that gets an authentication token from AWS and pipes it to Docker. For example:

aws ecr get-login-password --region <YOUR_REGION> --profile lambda | docker login --username AWS --password-stdin <YOUR_AWS_ACCOUNT_ID>.dkr.ecr.<YOUR_REGION>.amazonaws.com

Let’s break it down:

• aws ecr get-login-password --region <YOUR_REGION> --profile lambda: This part uses the AWS CLI to get a temporary login password for ECR. Be sure to replace <YOUR_REGION> with the region in which your ECR repository was created (for example, us-east-1).

• | docker login --username AWS --password-stdin <YOUR_AWS_ACCOUNT_ID>.dkr.ecr.<YOUR_REGION>.amazonaws.com: The pipe (|) takes the password from the AWS CLI command and passes it as input to docker login. The login command then logs Docker into ECR using the provided username (AWS) and the password. Replace <YOUR_AWS_ACCOUNT_ID> with your actual AWS account ID.

Step 2: Environment Considerations

This command works on shell environments like Powershell, zsh, and bash.

Windows Users (CMD):
If you’re using the classic Windows Command Prompt (CMD), the piping syntax might not work the same way. In that case, you might consider using Windows PowerShell or Git Bash. Alternatively, you can run the command in an environment like Windows Subsystem for Linux (WSL).

Why Use the Correct Region?

It is crucial to use the exact region where your ECR repository was created. The region is a part of your repository URI. If you use the wrong region, the login will fail because it won’t find the correct repository endpoint.

How to Check the Region:

Log in to your AWS Console, navigate to the ECR section, and select your repository. The URI will look similar to this: <YOUR_AWS_ACCOUNT_ID>.dkr.ecr.<YOUR_REGION>.amazonaws.com/lambda-practice. Here, <YOUR_REGION> is the region you must use in your login command.

Step 3: Build Your Docker Image with the Correct Tag

Before pushing the image to ECR, you need to build it on your local machine and tag it with your repository’s name. In your terminal, navigate to your project’s root folder (where your Dockerfile is located), then run (replace <YOUR_AWS_ACCOUNT_ID> and <YOUR_REGION> placeholders with your AWS Account ID and AWS ECR repository region):

docker build -t <YOUR_AWS_ACCOUNT_ID>.dkr.ecr.<YOUR_REGION>.amazonaws.com/lambda-practice:latest

Step 4: Push Your Docker Image to AWS ECR

Once your image is built and tagged, it’s time to push it to your remote ECR repository. Run the following command:

docker push <YOUR_AWS_ACCOUNT_ID>.dkr.ecr.<YOUR_REGION>.amazonaws.com/lambda-practice:latest

This command tells Docker to upload (or “push”) your image to the repository you created earlier.

• Make sure the repository URI and tag match what you used in the build command.

• Remember, if you use a different region than the one in your repository URI, the push will fail because AWS won’t recognize the repository endpoint.

How to Deploy the Application Container to AWS Lambda from the Image on AWS ECR 🚀

You can deploy your function on AWS Lambda in several ways, each catering to different use cases. Here’s a quick rundown:

1. ZIP file upload: Simply compress your code and dependencies into a ZIP file, then upload it directly via the AWS Lambda console. This traditional method is great for small codebases that don’t require custom runtimes.

2. Direct editing in the console: Write or edit your function code directly in the AWS Lambda code editor. Handy for quick tweaks, but not ideal for larger projects.

3. Container image: Package your application as a Docker container image and deploy it. This approach is particularly useful if you have complex dependencies, need a custom runtime, or want consistent environments across development and production.

In this tutorial, we’re taking the container image route because it offers flexibility, consistency, and scalability – all while letting us reuse our existing Docker configuration. Let’s walk through the steps for deploying your containerized application to AWS Lambda:

Step 1: Access the AWS Lambda Console

Log into your AWS Management Console. In the search bar at the top, type "Lambda" and select the AWS Lambda service from the dropdown results.

Step 2: Create a New Lambda Function

Once on the Lambda page, click the "Create function" button. You’ll see multiple function creation options. For our purposes, select the "Container image" option. This choice tells AWS that you’ll be deploying a containerized application instead of uploading a ZIP file.

Step 3: Name Your Function

In the function setup screen, enter lambda-practice as the name of your new Lambda function. This name identifies your function in AWS.

Step 4: Configure the Container Image

Under the “Container image” settings, click the "Browse images" button. A new window should appear, listing your available images from AWS Elastic Container Registry (ECR).

Select the repository you previously created (for instance, the one named lambda-practice), and pick the image tagged as latest.

Step 5: Finalize and Create

Now you’ll want to review the basic settings. In this step, you might also configure additional options such as memory allocation, timeout limits, and environment variables, depending on your application needs.

Once everything is set, click "Create function" to finalize the deployment.

How to Enable Access to Your Lambda Function

Awesome – hurray, you’ve successfully deployed your image from AWS ECR to AWS Lambda! Now the next step is to make sure your function is up and running and can be triggered properly. But you might be wondering, “How do I actually access my Lambda function to see if it’s working?” Let's break it down:

Understanding Lambda Function Triggers

There are several ways to invoke a Lambda function, and AWS supports multiple trigger options. Here are a few:

• Event Source Mapping: Automatically triggers your function in response to changes in services like DynamoDB, Kinesis, or S3.

• Scheduled Events: Set up cron-like scheduled invocations via Amazon CloudWatch Events.

• API Gateway: Create RESTful APIs that call your function.

• AWS SDK/CLI: Directly invoke the function using the AWS SDK or CLI commands.

• Function URLs: A simple way to expose your function over HTTPS, giving you a public URL that users or applications can call directly.

In this tutorial, we’re going to use a Function URL to trigger our Lambda function via an HTTP event. This method allows you to invoke your function from the public internet and is perfect for testing or building public-facing APIs.

How to Create a Function URL for Your Lambda Function

Now that you're on your Lambda function's details page, here’s how to create a Function URL step-by-step:

First, on your Lambda function’s page, click the "Configuration" tab at the top. Within the Configuration section, find and select the "Function URL" sub-tab. This is where you manage the public URL for your function.

Click on the "Create Function URL" button. This will open a new configuration screen for setting up your Function URL.

• Authentication type: Set the Auth type to NONE. This setting allows public, unauthenticated access to your function from the internet, which means anyone with the URL can invoke it. (This is great for testing or building public services, but be cautious with security in production environments!)

• Additional settings: Under the Additional Settings section, enable Configure cross-origin resource sharing (CORS). This is useful if you plan to call your function from client-side applications hosted on different domains. Think of it as opening a window for your app to communicate with other web pages or services.

After configuring your settings, click the appropriate button to create or save the Function URL.

Verify Your Function URL

Once configured, you’ll see the Function URL displayed on the same page. You can now copy this URL.

Paste the URL into a browser or use tools like curl or Postman to send an HTTP request, triggering your Lambda function and verifying that it works as expected.

You should get a response just like this on your browser:

And that’s it! You’ve successfully set up a public HTTP endpoint that triggers your AWS Lambda function. Whether you're testing your deployment or building a public-facing API, the Function URL makes it easy for anyone to interact with your function.

Congrats — You did it!

You've just walked through the entire journey of deploying a Node.js web server, containerized with Docker, all the way to AWS Lambda using AWS ECR as your image repository. 🚀

From writing and containerizing your Node.js application, creating an AWS ECR repository, setting up IAM users and access keys, pushing your Docker image to ECR, to deploying it on Lambda – you’ve covered it all like a pro. 💪

Not only that, but you also configured a public-facing Function URL so your serverless app can now handle requests from anywhere in the world 🌍.

You’ve just combined modern cloud-native workflows with serverless deployment – giving you flexibility, scalability, and lightning-fast response times without the headache of managing servers 😁.

👏 Give yourself a pat on the back. You’ve officially containerized and deployed your Node.js web server to AWS Lambda!

Advantages of Adopting the Serverless Model in Businesses 💼

When it comes to deploying applications in the cloud, the serverless model has truly flipped the old playbook and has helped businesses save on Cloud costs! Let’s break it down in simple, real-world terms.

Cost-Efficiency 💰

For most businesses – especially startups – serverless offers a major financial advantage. Here’s why:

In traditional models like IaaS (Infrastructure as a Service) and PaaS (Platform as a Service), such as using AWS EC2 or AWS Elastic Beanstalk, you provision resources upfront.

For example: You spin up a server with 4 GB RAM and 4 vCPUs, and AWS charges you $100/month (this covers 730 hours – the whole month). Even if your app barely does anything – say it only serves real requests for 120 hours, and uses just 1 GB of memory – you still pay the full $100, because the resources were reserved and waiting for traffic 24/7.

But with Serverless:

• You don’t pre-allocate or reserve compute power.

• Your application only runs when someone actually needs it (for example, when a user makes an HTTP request).

• You only pay for the actual execution time and the resources used.

For instance, if your function only runs for 50 hours in a month and uses 1.5 GB RAM, you might pay something like $30, compared to the flat $100 you'd have paid on EC2 or Elastic Beanstalk.

Scalability Without Stress 📈

Serverless platforms like AWS Lambda automatically handle:

• Scaling up during high demand.

• Scaling down to zero when idle.

This means your team won’t need to predict or provision for resources during traffic surges. Whether 1 or 1 million users visit your app, the cloud provider handles the rest.

Simplified Operations ⚙️

For your software team:

• No more babysitting servers, patching security updates, or worrying about load balancers.

• You focus purely on writing the business logic and shipping code.

• The cloud provider handles the infrastructure behind the scenes.

This frees up your team’s time, cuts maintenance tasks, and speeds up development times.

Better Return on Investment (ROI) 📊

Because you only pay for what you use, the cost-to-value ratio improves significantly. Startups and businesses can:

• Launch faster.

• Experiment without financial risk.

• Scale without surprise bills.

• Avoid overpaying for idle resources.

Disadvantages of the Serverless Model 🚫

As exciting and cost-friendly as the serverless model seems, the golden rule in tech still applies:
every solution comes with trade-offs.

Let’s walk through a few important downsides you should consider:

No Built-in Support for Background Jobs ⏰

Unlike traditional servers where you can run background processes – like sending out newsletters at midnight or cleaning up databases at scheduled times – serverless platforms such as AWS Lambda don’t natively support background tasks or recurring jobs.

For example, let’s say you wanted your app to automatically generate reports every day at 3 AM. In a typical server setup, you’d just write a cron job and call it a day.

But with Lambda or serverless, you can’t do this directly inside your deployed function. Instead, you need external tools like:

• AWS EventBridge (for scheduling and triggering Lambda functions)

• Or other cloud-native schedulers.

This adds a bit of extra setup, management, and sometimes extra cost.

Unpredictable Cloud Costs 💸

One of the biggest selling points of serverless is “pay-as-you-use” – but this can also become a financial blind spot, because:

• Costs depend on traffic volume and resource usage.

• If your app suddenly goes viral or experiences a traffic spike, your cloud bill could skyrocket without warning.

For example, an app that runs stable at $30/month for low traffic could unexpectedly hit $1000+ if a marketing campaign or external event drives huge numbers of users to your service. While this means your app is succeeding, your budget might take a hit.

In contrast, with traditional models like AWS EC2 or Elastic Beanstalk, your costs are usually predictable – even if your server sits idle all month.

When to Adopt the Serverless Model 🤔

So, is Serverless always the right choice? Not necessarily!

If you expect:

• Steady, predictable workloads, EC2 or Elastic Beanstalk might offer more cost certainty.

• Long-running background tasks, serverless isn’t ideal without extra services.

• Real-time control over resource limits, traditional servers give you more flexibility.

But if your app has burst traffic (users come and go), event-driven logic (like APIs or webhooks), or you want minimal ops overhead, then Serverless can save time, effort, and money.

When Serverless is the Perfect Fit: A Startup Building an Event-Driven API

Imagine you’re running a small tech startup that just launched an app for booking fitness classes. Your team is small, budgets are tight, and traffic is unpredictable – some days you have 50 users, some days 5,000.

In this case:

• Your backend mostly handles HTTP requests: new sign-ups, class bookings, cancellations, and payments.

• Traffic spikes during lunch breaks and weekends, but is quiet at night.

• You don’t want to hire a full-time DevOps engineer just to manage servers.

👉 Why Serverless is perfect in this case:

• You only pay when people use your app.

• No need to manage or provision servers.

• AWS Lambda auto-scales based on demand.

• Fast to deploy, easy to connect to other AWS services (like DynamoDB for your database, S3 for images, and SES for emails).

By using Serverless in this case, you can save money, scale automatically, and stay laser-focused on features – not infrastructure.

When Serverless is Not a Good Fit: A Video Streaming Platform

Now imagine you’re building the next YouTube-like service for a niche audience – say, education-based content for universities.

In this case:

• Your platform requires continuous background processing: encoding videos, generating thumbnails, and pushing them to CDN.

• Users stream content 24/7, meaning your app is always under load.

• Background jobs like recommendation engine updates or nightly reports need to run frequently.

👉 Why Serverless might be a bad idea:

• Functions like AWS Lambda have a timeout limit (for example 15 minutes max per execution).

• Continuous processing or streaming doesn’t fit the on-demand, short-lived nature of serverless.

• Costs could skyrocket since the app runs almost all the time, making it more expensive than a dedicated EC2 or Kubernetes cluster.

Better alternative:
For this kind of use case, a traditional server-based setup – like EC2 or container orchestration via ECS or Kubernetes – would offer more control, predictable pricing, and support for long-running processes

✅ Bottom line:
Serverless is fantastic for modern apps, but like any tool, it’s best used when its strengths match your project’s needs.

Conclusion 📝

Congratulations on making it to the end of this tutorial! 🚀

In this article, we explored the power of serverless computing by walking step-by-step through the process of deploying a Node.js web server using Docker and AWS Lambda.

From building your container image, pushing it to AWS ECR, and finally deploying it on Lambda – you’ve now seen how easy it is to get an app running without the hassle of provisioning servers.

We also discussed the advantages of adopting the Serverless model in deploying your applications, it’s disadvantages, and real-world use cases in which you should adopt the serverless approach.

About the Author 👨‍💻

Hi, I’m Prince! I’m a DevOps engineer and Cloud architect passionate about building, deploying, and managing scalable applications and sharing knowledge with the tech community.

If you enjoyed this article, you can learn more about me by exploring more of my blogs and projects on my LinkedIn profile. You can find my LinkedIn articles here. You can also visit my website to read more of my articles as well. Let’s connect and grow together! 😊

AWS also offers an API Gateway, allowing developers to invoke AWS Lambda functions, which provides enhanced security and performance features like rate limiting. But even with the API Gateway, you have to coordinate these microservices, as your client applications likely each have unique data needs. Data might need to be transformed, filtered, or combined before it is returned to the client.

These orchestration tasks can reduce your productivity and take time and effort away from solving the business problem your application is trying to solve.

Apollo GraphQL is an API orchestration layer that helps teams ship new features faster and more independently by composing any number of underlying services and data sources into a single endpoint. This allows clients on-demand access to precisely what the experience needs, regardless of the source of that data.

This article will teach you how to orchestrate AWS Lambda functions using Apollo GraphQL. Specifically, here’s what we will cover:

• GraphQL Primer

• Tutorial Overview

• Prerequisites

• Section 1: Create the AWS Resources

• Section 2: Create an Apollo Connector

• Section 3: How to Use Apollo Sandbox

• Summary

GraphQL Primer

For those unfamiliar with GraphQL, here’s a primer that offers some background on the challenges GraphQL addresses and how data is typically managed through REST APIs in GraphQL before the emergence of Apollo Connectors. If you’re familiar with GraphQL, feel free to skip this section.

GraphQL is a query language for APIs. This query language and corresponding runtime enable clients to specify exactly the data they require, minimizing over-fetching and under-fetching.

In contrast to REST, which necessitates multiple endpoints for various data requirements, GraphQL streamlines queries into a single request, enhancing performance and reducing network latency.

GraphQL also uses a strongly typed schema. This improves API documentation and makes validation, early error detection, and immersive developer tooling easy.

To illustrate the difference between REST APIs and GraphQL, consider the following REST API call: /user/123

Response:

{
  "id": 123,
  "name": "Alice Johnson",
  "email": "alice@example.com",
  "phone": "555-1234",
  "address": {
    "street": "123 Main St",
    "city": "Springfield",
    "state": "IL",
    "zip": "62704"
  },
  "createdAt": "2022-01-01T12:00:00Z",
  "updatedAt": "2022-05-15T14:30:00Z",
  "isAdmin": false
}

If you were only interested in the name and email, using REST would be a lot of data returned from the network to the client for no reason. Using GraphQL, the GraphQL query to return the name and email would be the following:

query {
  user(id: 123) {
    name
    email
  }
}

The result set is just the data the client needs:

{
  "data": {
    "user": {
      "name": "Alice Johnson",
      "email": "alice@example.com"
    }
  }
}

This is a simple example showing the benefit of not over-fetching data, but GraphQL has many other advantages. One of them is the separation between client and server. Since both parties leverage and respect the GraphQL type schema, both teams can operate more independently with the back end defining where the data resides and the front end only asking for data it needs.

So how does GraphQL know how to populate data for every field in your schema? It does this through resolvers. Resolvers can fetch data from a back-end databases or third-party API such as REST APIs, gRPC, and so on. These functions comprise procedural code compiled and maintained for each field in the schema. Thus, one field can have a resolver that queries a REST API and another can query a gRPC endpoint.

To illustrate resolvers, consider the example above. Let’s add a field, status, that queries a REST API to determine if the user is full-time, part-time, or terminated.

First we have defined our schema as:

type User {
  id: ID!
  name: String!
  email: String!
  status: String!  # Need this from an external REST API
}

type Query {
  user(id: ID!): User
}

The user query in this case will accept a user id and return a type User. The resolver function to support the data fetching resembles the following:

const resolvers = {
  Query: {
    user: async (_, { id }) => {
      // Fetch user details from one REST API
      const userResponse = await fetch(`https://api.company.com/users/${id}`);
      const userData = await userResponse.json();

      // Fetch employee status from another REST API
      const statusResponse = await fetch(`https://api.company.com/employees/${id}/status`);
      const statusData = await statusResponse.json();

      return {
        id: userData.id,
        name: userData.name,
        email: userData.email,
        status: statusData.status, // e.g., "Full-Time", "Part-Time", "Terminated"
      };
    },
  },
};

Notice that not only are there two fetches needed to obtain the information the query requires, but we also need to write procedural code and deploy it.

A better approach would be to declaratively specify to GraphQL where the REST API is located and what data to return. Apollo Connectors is the solution to this challenge, simplifying the process and allowing you to declaratively integrate REST API data without requiring code compilation and maintenance.

Now that you have a general idea of GraphQL and the challenges it addresses, let’s delve into the example we will build out.

Tutorial Overview

In this tutorial, you will create two AWS Lambda functions that return product information, which are described as follows:

Products Request:

POST /2015-03-31/functions/products/invocations

Response:

{
  "statusCode": 200,
  "body": [
    {
      "id": "RANQi6AZkUXCbZ",
      "name": "OG Olive Putter - Blade",
      "description": "The traditional Block in a blade shape is made from a solid block of Olive wood. The head weight is approximately 360 grams with the addition of pure tungsten weights. Paired with a walnut center-line and white accents colors.",
      "image": "https://keynote-strapi-production.up.railway.app/uploads/thumbnail_IMG_9102_3119483fac.png"
    },
    {
      "id": "RANYrWRy876AA5",
      "name": "Butter Knife Olive Putter- Blade",
      "description": "The traditional Block in a extremely thin blade shape (~1\") is made from a solid block of Olive wood. The head weight is approximately 330 grams with the addition of pure tungsten weights.",
      "image": "https://keynote-strapi-production.up.railway.app/uploads/thumbnail_IMG_9104_97c221e79c.png"
    },...

Product-price request:

POST: /2015-03-31/functions/product-price/invocations

Response:

{
  "default_price": 49900,
  "is_active": true,
  "currency": "usd",
  "billing_schema": "per_unit",
  "recurring": {
    "interval": 0,
    "interval_count": 3
  }
}

To expose these two lambda microservices, you need to create API Gateway triggers. This involves either setting up a distinct API Gateway for each lambda or consolidating them under one or a few API Gateway instances with specified routes for each lambda.

Creating a trigger may feel tedious and repetitive in a microservices setup. But there is an alternative available. You could directly invoke those functions via REST using the InvokeFunction permission assigned to an IAM user. This article will show you this method and guide you through function creation, necessary AWS IAM permissions, and configuring the Apollo Connector to invoke the function.

Prerequisites

To follow along in this tutorial, you will need to have a basic understanding of AWS Lambda functions as well as AWS security. You’ll also need access to the following:

• An AWS account with permissions to create IAM Users and Policies

• An Apollo GraphQL account, you can sign up for a free plan here.

We will also use the following tools:

• VS Code: Microsoft VS Code is a free source code editor from Microsoft

• Apollo Rover CLI: Rover is the command-line interface for managing and maintaining graphs

• Apollo Studio: A web-based portal used for managing all aspects of your graph

• Apollo Connectors Mapping Playground: A website that takes a JSON document and helps developers create the selection mapping used with Apollo Connectors

Section 1: Create the AWS Resources

First, let’s configure our AWS environment, starting with security. In our scenario, we will create an IAM User, “ConnectorUser,” with access to an AWS Policy, “ConnectorLambdaPolicy,” with the minimum permissions needed to access the AWS Lambda functions.

Note that you could create user groups and assign permission policies to those groups in a production environment. But for this article, we are reducing the number of administrative steps to focus on the core integration with GraphQL.

Step 1: Create an AWS Policy

To create a policy, navigate to IAM within the AWS Management console, then select “Policies” under Access Management. Click “Create Policy”. This will open the policy editor page, as shown below:

Choose the “Lambda” service and under the Access level select “InvokeFunction” from the Write drop down menu as shown below:

Under the Resources menu, you can choose either All ARNs or a specific option. It's a best practice to be as granular as possible when defining security configurations. In this example, let’s limit our selection to the “us-east-1” region by clicking on the “Specific” option and then “Add ARNs.” Enter “us-east-1” in the resource region and select “Any function name.”

With the policy created, we can assign an IAM user to that policy.

Step 2: Create the IAM User and Attach a Policy

Click on Users under “Access Management” then Create User. Provide a name for the user, “ConnectorUser”.

Next, select “Attach policies directly,” choose the policy we just created, “ConnectorLambdaPolicy,” and click “Create User.”

Step 3: Create AWS Lambda Functions

In your AWS console, create a new NodeJS AWS Lambda function, “products”.

Select “Node.JS” for the runtime then click “Create function”. Once created, paste in the the function code from this Gist.

Repeat this process, creating another function for, “product-price” and use the function code from this Gist.

Section 2: Create an Apollo Connector

In this section, we will install the Apollo Rover CLI tool, create an Apollo Studio free tier account, and clone the Apollo Connectors repository. If you already have an Apollo environment available, you can skip steps 1 and 2.

Step 1: Install Rover

Rover is the command-line interface for managing and maintaining graphs. It also provides a modern hot-reloading experience for developing and running your connectors locally. If you don’t have Rover installed, install it by following the steps here.

Step 2: Create an Apollo Studio Free Tier Account

Apollo Studio is a cloud-based management platform designed to explore, deliver, and collaborate on graphs. If you do not have an Apollo Studio account, create one on a free plan by navigating here.

Step 3: Clone the Apollo Connectors Repository

To help you start your first Apollo Connector, a GitHub repository provides sample connectors and a template script. When run, this script will create all the necessary files and configurations you need to begin.

Go ahead and clone the repository from here.

Note: While not required, I recommended using VS Code, as this repo leverages VS Code-specific settings files.

Step 4: Create a .env File

Before you run the Create Connectors template script, create a .env locally with a user API key from your Apollo Studio. You can create and obtain this key here. Populating this .env file will add this API key to the connector template you create in the next step.

Step 5: Create Your New Connector from a Template

Execute npm start and provide a location to create the connector template. You can use default values for the remaining questions.

This script will create all the necessary files to run a local Apollo GraphQL instance in the specified directory. Load the newly created connector using VS Code or your preferred code editor. You will return to this editor soon, but first, we need to obtain some access keys from AWS.

Step 6: Create an AWS Access Key

Since we connect to AWS using SigV4, we must create an AWS access key and enter the KEY values in the settings.json file. Return to the AWS IAM Console and select the ConnectorUser you created in Step 1. Create a new access key by clicking on “Create access key”.

You will be presented with multiple options as far as where the use of this key will originate. Since we are first running locally, select “Third-party service” and then continue the wizard until you are presented with the key and secret key as shown below:

Add the access key and secret access key to the settings.json file as “AWS_ACCESS_KEY_ID” and “AWS_SECRET_ACCESS_KEY” respectively.

You'll need to reload the window since VS Code only loads these files under the .vscode directory once.

Note: In this step, we saved the key to the settings.json file. While this is acceptable for development, consider saving environment variables in .env files.

Step 7: Configure the Graph

The supergraph.yaml file is used to define all the subgraphs that are part of this federation. Modify the supergraph.yaml file as follows:

federation_version: =2.10.0
subgraphs:
  awsconnector:
    routing_url: http://lambda
    schema:
      file: connector.graphql

Step 8: Configure Apollo Router

Apollo Router supports AWS SigV4 authentication. To configure the connector to use this, modify the router.yaml file and add an authentication section as follows:

authentication:
  connector:
    sources:
      awsconnector.lambda:   # subgraph name . connector source name
        aws_sig_v4:
          default_chain:
            region: "us-east-1"
            service_name: "lambda"

There are other AWS security configuration options available, including using assume role. The full documentation for subgraph authentication is available here.

Step 9: Build the connector

Now that we have configured the environment variables and authentication information, we are ready to build the connector. Open the connector.graphql file and erase the contents. Next, copy the following extend schema:

extend schema
  @link(
    url: "https://specs.apollo.dev/federation/v2.10"
    import: ["@key"]
  )
  @link(
    url: "https://specs.apollo.dev/connect/v0.1"
    import: ["@source", "@connect"]
  )

  @source(
    name: "lambda"
    http: { baseURL: "https://lambda.us-east-1.amazonaws.com" }
  )

Extend schema is used to link the Apollo Connectors directives into the current schema. In this article we are defining the base URL of our lambda function. If your REST API has HTTP headers that apply to all references of this source, such as Content-Length restrictions, you can add them here in the @source declaration. Next, let’s define the Product schema:

type Product {
  id: ID!
  name: String
  description: String
  image: String
  price: Price
    @connect(
      source: "lambda"
      http: {
        POST: "/2015-03-31/functions/product-price/invocations"
        body: """
        product_id: $this.id
        """
      }
      selection: """
      amount: default_price
      isActive: is_active
      currency
      recurringInterval: recurring.interval -> match(
        [0,"ONE_TIME"],
        [1,"DAILY"],
        [2,"MONTHLY"],
        [3,"ANNUALLY"],
      )
      recurringCount: recurring.interval_count
      """
    )
}

Notice our query Products has an @connect directive that defines, at a minimum, the source name. Here, you can add the HTTP-specific configuration you need for this field, such as Authorizations headers. In this scenario, since we only defined a baseUrl in the extend schema section, we need to put the specific URL for the InvokeFunction, which is /2015-03-31/functions/product-price/invocations.

The selection field allows you to transform and map values returned from the REST API using the mapping definition defined in the selection field. While a complete discussion of selection mapping is beyond the scope of this article, check out the documentation for a detailed look at Mapping GraphQL Responses. Apollo provides a free online tool that makes building mappings intuitive and fast.

Next, let’s define the Price schema and products Query.

type Price {
  amount: Float
  isActive: Boolean
  currency: String
  recurringInterval: RecurringInterval
  recurringCount: Int
}
enum RecurringInterval {
  ONE_TIME
  DAILY
  MONTHLY
  ANNUALLY
}

type Query {
  products: [Product]
    # https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html
    @connect(
      source: "lambda"
      http: { POST: "/2015-03-31/functions/products/invocations" }
      selection: """
      $.body {
        id
        name
        description
        image
      }
      """
    )
}

Now we're ready to run our connector and issue queries to our graph! The complete configuration script is available at this Gist.

Step 10: Run the Connector

If you're using VS Code, the repository includes a tasks.json file that adds a “rover dev” task, which launches Rover locally.

{
    "version": "2.0.0",
    "tasks": [{
        "label": "rover dev",
        "command": "rover", // Could be any other shell command
        "args": ["dev", "--supergraph-config","supergraph.yaml", "--router-config","router.yaml"],
        "type": "shell",
        "problemMatcher": [],
    }]
}

If you are not using VS Code, you can start your graph by executing rover dev –supergraph-config supergraph.yaml –router-config router.yaml from a terminal window.

If everything is configured correctly, you’ll see the following:

Section 3: How to Use Apollo Sandbox

The rover dev command you launched in the previous step configures a local Apollo Router instance for development mode. This mode makes it easy for developers to create, execute, and debug ad-hoc GraphQL queries using the Apollo Sandbox web portal. This portal is located at http://localhost:4000 by default.

Launch the portal and click on the products field. This will populate the Operation pane with all the available fields in the schema. In the operation pane, you can modify and build your GraphQL query. Clicking the Run button (which displays the query name, Products, in our example) will execute the query and show the results in the Response panel, as illustrated in the figure above.

In this example, you can see that data has been returned from our AWS Lambda function. To confirm, you can view the query plan by selecting "Query Plan” from the Response drop-down menu.

The query plan illustrates the orchestration of our two AWS Lambda functions that fetch product and product price data.

A helpful debugging feature is the Connectors Debugger, available in the drop-down as shown in the previous figure.

The Connection Debugger provides a comprehensive view of the HTTP request, including headers, body, response code, and the selection mapping used in the query. If you’re experiencing difficulties running queries, use this debugger – it will save you a lot of time.

Summary

In this article, you learned how to:

• Set up AWS IAM User, Policies, and Lambda functions

• Create an Apollo Connector to obtain data from an AWS Lambda function

• Configure the Apollo Router

• Execute and debug queries using Apollo Sandbox

Integrating AWS Lambda with Apollo Connectors offers a simplified, resolver-free method for incorporating cloud functions into your GraphQL API. By utilizing Apollo Connectors, you can declaratively link REST-based Lambda functions to your supergraph while ensuring secure authentication with AWS SigV4.

You can learn more about Apollo Connectors from the following resources:

1. Tutorial: GraphQL meets REST, with Apollo Connectors

2. Blog: Discover how Apollo Connectors integrate with Apollo Federation through insights from Apollo's Founder & CTO: REST API Orchestration with GraphQL.

3. Blog: Delve into the engineering journey behind Apollo Connectors and the process of their creation: Our Journey to Apollo Connectors

4. Webinar: Apollo Connectors GA Launch Webinar

In this tutorial, I’ll show you how to use AWS Lambda with three other services:

• Amazon S3 for storing files, images, and videos

• Amazon Simple Notification Service (SNS) for sending notifications

• Amazon EventBridge for scheduling messages

We’ll go through everything step by step.

By the end, with the integration of the other services, you will have built a Goal Manifestation Quote App that sends random inspirational messages to keep you motivated and focused on your goals.

Prerequisites

• An AWS account: If you don’t have one, sign up here.

• A GitHub repository: This is for storing your source code. If you don’t have a GitHub account, you can create one here.

• An Integrated Development Environment (IDE) such as Visual Studio Code or Sublime Text.

• A basic knowledge of web development and any programming language of your choice. I used Python for this tutorial.

• Zenquote Random API

What You'll Learn

• How to create an Amazon S3 bucket

• How to use Amazon Simple Notification Service (SNS)

• How to use Amazon Lambda

• How to use Amazon EventBridge

Table of Contents

1. Step 1: Set Up Your Development Environment

2. Step 2: Create an Amazon Simple Storage Service (S3)

3. Step 3: Create an Amazon Simple Notification Service (SNS)

4. Step 4: Create an IAM Policy

5. Step 5: Create an Amazon Lambda function

6. Step 6: Create an EventBridge

7. Step 7. Upload Your Code

8. Conclusion

Step 1: Set Up Your Development Environment

In this step, you'll get everything set up. Start by signing in to your AWS account, then install Python if you don't have it on your IDE.

Step 2: Create an Amazon Simple Storage Service (S3)

Before we begin creating an S3 bucket, let's first understand what Amazon S3 is:

Amazon S3 (Simple Storage Service) is a service from Amazon that allows you to store and access any amount or type of data, such as photos, videos, documents, and backups, whenever you need it.

Now that you know the basics of what Amazon S3 is, let's return to the tutorial.

Create an S3 Bucket

There are several ways to create an S3 bucket, but for this tutorial, we'll use the Ubuntu command line (CMD), your terminal, or Amazon CloudShell, depending on what you're most comfortable with.

• Type boto3 s3 in the web search bar to view a list of related documentation.

• Click on the first result.

• Once the documentation is open, copy the first command you see.

• Paste it on your CMD OR terminal of your choice – but before then remember to "cd" into the right directory.

• In the documentation, scroll down and click on "create_bucket.

• Once it's open, scroll down to "Request Syntax." Copy the bucket name and the bucket configuration.

• Other variables listed in the request syntax are optional.

• Once this is done, make sure you save.

• Go back and call the script:

#python3 your file name

• Running the script automatically creates an S3 bucket in your Amazon S3.

• Now you can go to the console to check if it has been created:

Upload Files

With the bucket created, we can now upload files through the console. I believe there's also a programmatic way to upload files and test, but I haven't explored all the methods in the documentation yet.

Click on the bucket name to be redirected to the object page. This is where you will upload your files for storage.

Click on the Upload button to upload a file. Remember, we're creating a Goal Manifestation Quote Application.

Now that we've set up a storage bucket:

• Open a tool like Google Drive, MS Word, WPS, or any other document editor.

• Write down the goals you want to achieve.

• Save the file in either PDF or DOCX format.

• Take the document and upload it to your Amazon S3.o

To verify if it's the correct file:

• Navigate to the Permissions tab.

• Scroll down to Block public access.

• Click on Edit and uncheck the box.

As shown above, it is currently set to "on." Uncheck it to turn it "off."

• On the same bucket settings page, modify the policy.

• Scroll down, and you'll see that a bucket policy has been auto-generated.

• Go ahead and copy the policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

• Go back to the bucket policy editor and paste the policy.

Once you've completed these steps, your object will have public access.

Return to the Objects tab and click on the Object URL provided below:

With this URL, your upload is now visible.

Step 3: Create an Amazon Simple Notification Service (SNS)

SNS is a fully managed messaging service provided by AWS. It enables communication between applications or directly with users by sending notifications.

To create an SNS, follow these steps:

1. Log in to the AWS management console

Then go to Amazon SNS. Navigate to the SNS Dashboard and select Topics from the left-hand menu.

To create a topic:

• Click Create topic.

• Choose a Topic type: Standard (default) or FIFO (for ordered messages).

• Enter a Name for your topic. (for example, MyFirstSNSTopic).

  

• Configure optional settings like encryption, delivery retry policies, or tags.

• Click Create topic.

2. Add Subscriptions:

Once the topic is created, click on it to open the details page. Select the Subscriptions tab.

Click Create Subscription and choose:

• Protocol can be Email, SMS, HTTP/S, Lambda, or SQS.

• Endpoints such as email address, phone number, or URL.

Click Create Subscription.

3. Confirm the Subscription:

If you selected email or SMS, a confirmation link or code will be sent to the provided endpoint. Follow the instructions to confirm the subscription.

Now that we’ve done this, let's create an Amazon Lambda function that will trigger the SNS so that the message will be sent to your mail.

Step 4: Create an IAM Policy

This policy is created to authorize Amazon Lambda to trigger the event and to ensure that CloudWatch is automatically triggered to monitor the application's events.

To create a policy, follow these steps:

1. Log in to the AWS Management console.

In the left-hand menu, select Policies. Then:

• Click Create policy.

• Choose the Visual tab, then select the SNS service.

• Next, click the Choose tab to create a custom policy.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sns:Publish",
            "Resource": "arn:aws:sns:REGION:ACCOUNT_ID:goal_topic"
        }
    ]
}

Then, replace the following placeholders with your info:

• region: Your AWS region (for example, us-east-1).

• account-id: Your AWS account ID.

• topic-name: Your SNS topic name.

2. View and create the policy:

You can do this by following these steps:

• Click on the Review button.

• Give your policy a Name (for example, LambdaSNSPolicy), and optionally, a Description.

• Click Create policy.

3. Attach policy to the Lambda Execution Role

Now, you need to attach the policy to your Lambda Execution Role. To do that, follow these steps:

• Go to the Roles section in the IAM Console.

• Search for and select the execution role.

• Next, search for the policy you just created and select it.

• Click Attach policy.

Both policies will be automatically attached.

Step 5: Create an Amazon Lambda function

Amazon Lambda is a service from AWS that lets you run code without managing servers. You upload your code, and Lambda automatically runs and scales it when needed.

Follow these steps to create an Amazon Lambda function:

1. Log in to AWS Management Console:

Navigate to AWS Lambda.

2. Create a Function:

Click on the Create function and choose the option Author from scratch.

Fill in the details:

• Function name: Enter a unique name (for example, SNSLambdaFunction).

• Runtime: Select the runtime (for example, Python, Node.js, Java, and so on).

• Role: Choose or create a role. If you already have a role, select Use an existing role. Otherwise, select Create a new role with basic Lambda permissions.

• Click the Create function button.

3. Paste in the code:

On the Lambda function’s page, go to the Configuration tab:

Remember, we are trying to fetch a quote. I'll add the ARN of the topic we created here and include my API keys. But for this tutorial, I will use the API directly to fetch the data.

4. Write the Lambda Code:

Go to the Code tab in your Lambda function. Then write or paste the code from your IDE to process the incoming SNS messages.

Example:

Here’s the code:

import os
import json
import urllib.request
import boto3

def fetch_random_quote():
    """
    Fetches a random quote from the ZenQuotes API.
    """
    api_url = "https://zenquotes.io/api/random"
    try:
        with urllib.request.urlopen(api_url) as response:
            data = json.loads(response.read().decode())
            if data and isinstance(data, list):
                # Format the quote and author
                quote = data[0].get("q", "No quote available")
                author = data[0].get("a", "Unknown author")
                return f'"{quote}" - {author}'
            else:
                return "No quote available."
    except Exception as e:
        print(f"Error fetching random quote: {e}")
        return "Failed to fetch quote."

def lambda_handler(event, context):
    """
    AWS Lambda handler function to fetch a random quote and publish it to an SNS topic.
    """
    # Get the SNS topic ARN from environment variables
    sns_topic_arn = os.getenv("SNS_TOPIC_ARN")
    sns_client = boto3.client("sns")

    # Fetch a random quote
    quote = fetch_random_quote()
    print(f"Fetched Quote: {quote}")

    # Publish the quote to SNS
    try:
        sns_client.publish(
            TopicArn=sns_topic_arn,
            Message=quote,
            Subject="Daily Random Quote to help you stay motivated and inspired to achieve your goals",
        )
        print("Quote published to SNS successfully.")
    except Exception as e:
        print(f"Error publishing to SNS: {e}")
        return {"statusCode": 500, "body": "Error publishing to SNS"}

    return {"statusCode": 200, "body": "Quote sent to SNS"}

5. Save:

Click on the deploy button to save.

6. Test Your Lambda Function:

Go to the Test tab and create a new test event.

Then save and run the test. If it’s successful, a message will be sent:

This means the message has been created for you

Finally, check your email or SMS, depending on the endpoint you used for this tutorial. In my case, I used email.

Step 6: Create an EventBridge

Amazon EventBridge is a service that helps you connect applications and AWS services such as the Amazon SNS and Amazon Lambda.

To create an Amazon EventBridge rule, follow these steps:

1. Navigate to EventBridge:

In the search bar, type EventBridge and select it from the services list.

2. Create a Rule:

In the EventBridge console, click Rules on the left panel. Then click the Create rule button.

3. Set Up the Rule Details:

• Name: Enter a unique name for your rule.

• Description (optional): Add a description to explain what this rule does.

4. Choose the Event Bus:

Select Default event bus (or another event bus if you've created one).

5. Define the Event Pattern or Schedule:

For Event Pattern:

• Choose an AWS Service as the event source.

• Select the specific event type (for example, an S3 file upload or an EC2 instance state change).

For Schedule:

• Choose the Schedule option to run the rule on a fixed interval (for example, every 5 minutes).

• Click on continue. This takes you to the specific details page where:

• Scroll down and click on the cron scheduler. The cron scheduler specifies what time the message will be sent.

• Select "Off" for the flexible time window option.

• Review the rule details to confirm everything is correct.

• Click the "Next" button to proceed to the Target page.

  

  The picture above shows when the time the messages will be sent.

  • On the Target page, select AWS Lambda to invoke your function.

• Scroll down to invoke and choose the function you created.

• Click the "Next" button to proceed. This will take you to the settings page. Under the permissions section, select "Use existing rule."

• Lastly, go to the review and create a schedule:

• The next page shows you all the details:

Using the EventBrige creates a scheduler for the users.

Step 7: Upload Your Code

Finally, upload your code to GitHub and include proper documentation to help explain how the code works.

Check this documentation out if you don’t know how: Uploading a project to GitHub.

Conclusion

If you’ve followed all these steps, you will have created a Goal Manifestation Quote App using AWS Lambda, Amazon S3, Amazon SNS, and Amazon EventBridge. This app fetches motivational quotes and sends them to subscribers on a schedule.

You can find the repository link here.

Feel free to share your progress or ask questions if you have any issues.

If you found this article helpful, share it with others.

Stay updated with my projects by following me on Twitter, LinkedIn and GitHub

Thank you for reading 💖.

Disclaimer:
The resources shown in this article, including the S3 bucket and its ARN, have been deleted and no longer exist. The details visible in the screenshots are used solely for demonstration purposes.

In the realm of serverless computing, AWS Lambda stands out as a leading platform for running serverless functions in a scalable and cost-effective manner.

Table of Contents

• What is Serverless Framework?
• Purpose and Scope of the Guide
• Prerequisites
• How to Configure the AWS CLI
• How to Create the IAM Role
• How to Create a Serverless Project
• How to Write the Python Function
• How to Define Serverless Configuration
• How to Deploy the Python Function
• How to Test the API
• Monitoring and Logging
• Conclusion

What is Serverless Framework?

Serverless Framework is a powerful tool that simplifies the deployment and management of serverless applications across various cloud providers, including Amazon Web Services (AWS). This guide aims to walk you through the process of using the Serverless Framework to deploy a simple Python function to AWS Lambda, expose it via API Gateway, and monitor it using AWS CloudWatch.

Purpose and Scope of the Guide

The purpose of this guide is to provide you with a step-by-step tutorial on deploying a serverless Python function on AWS using the Serverless Framework. Whether you're new to serverless computing or looking to expand your skills, this tutorial is designed to help you with the following:

• How to set up the necessary prerequisites, including AWS account configuration.
• How to create a new serverless project using the Serverless Framework.
• How to write a Python function that will be deployed to AWS Lambda.
• How to define the serverless configuration in a serverless.yml file.
• How to deploy the Python function and API Gateway.
• How to test the deployed API using various tools like cURL or Postman.
• How to set up monitoring and logging with AWS CloudWatch.

By the end of this article, you'll have a clear understanding of how to leverage the Serverless Framework to deploy and manage serverless applications on AWS.

You'll also gain practical experience in deploying serverless functions and exposing them through an API endpoint, paving the way for building and scaling serverless applications in your projects.

Now, let's dive into the prerequisites needed to get started with this tutorial.

Prerequisites

To follow along with this tutorial, you'll need the following:

• An AWS account.
• The AWS CLI (Command Line Interface).
• The Serverless Framework.

How to Configure the AWS CLI

You'll need to set the AWS credentials for the AWS CLI if you have not done that already. You'll be using it along with the Serverless Framework to deploy the resources on AWS.

You can create the AWS credentials file by entering the following command in the terminal:

 cat <<EOF > ~/.aws/credentials
    [default]
    aws_access_key_id = <REPLACE_WITH_YOUR_SECRET_KEY>
    aws_secret_access_key = <REPLACE_WITH_YOUR_ACCESS_KEY> 
  EOF

  cat <<EOF > ~/.aws/config
    [default]
    region = eu-west-1
    output = json
  EOF

How to Create the IAM Role

The IAM role is also used by the Serverless Framework to deploy the resources on AWS. Enter the following command to create the role:

 aws iam create-role --role-name serverlessLabs --assume-role-policy-document '{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}'

This policy allows the role to be used by the AWS Lambda service.

Enter the following command to attach the AWSLambdaBasicExecutionRole policy to the role:

aws iam attach-role-policy --role-name serverlessLabs --policy-arn arn:aws:iam::aws:policy/AWSLambda_FullAccess

To verify that the role has been created successfully, you can run the following command to get information about the IAM role:

aws iam get-role --role-name serverlessLabs

Here's what the information should look like:

How to Create a Serverless Project

This project is a simple python function that is deployed to AWS Lambda, API Gateway, and CloudWatch using the Serverless Framework.

The function is triggered by an HTTP GET request and returns a simple string. The function is deployed to the eu-west-1 region.

First, install Serverless Framework using npm:

npm install -g serverless

Next, create a new Serverless Framework project using the serverless command and then follow the prompt:

serverless

Then choose AWS Python Starter from the template list. Give it any name of your choice – I used serverless-lab.

After the command runs successfully, you will see the two main components created: serverless.yaml, and handler.py.

How to Write the Python Function

To keep things organized, let's create a folder named functions, and create a file named __init__.py inside it. You can do that using this command:

mkdir functions  touch functions/__init__.py

Create your first function by creating a file named first_function.py inside the functions folder:

touch functions/first_function.py

Then open the first_function.py file, and paste the following Python code to define the function you'll deploy:

def first_function(event, context):
  print("The first function has been invoked!!")
  return {
    'statusCode': 200,
    'body': "Hello, World!.\n This is the first function."
  }

This code above is a simple Python function that returns a JSON object with status code and body values. As you can see, we inserted the two parameters — event and context — required from the functions as a Serverless Framework convention.

Next, open the handler.py file and delete its content and paste the following Python code to define the handler that will be invoked when the function is triggered:

from functions.first_function import first_function

The code above exposes the function you created in the first_function.py file. We imported the function, and exposed it to the framework.

How to Define Serverless Configuration

To start with the configuration, open the serverless.yaml file and delete all of its content and paste the following YAML code to define the microservice you will deploy:

service: serverless-lab

provider:
  name: aws
  runtime: python3.7
  lambdaHashingVersion: 20201221
  region: eu-west-1
  timeout: 10 # You set a timeout of 10 seconds for the functions
  role: arn:aws:iam::155318317806:role/serverlessLabs # Enter your Arn role here
  memorySize: 512

functions:
  first_function:
    handler: handler.first_function
    events:
    - http:
        path: first
        method: get

Let's break down each section line by line:

service: serverless-lab

**service** specifies the name of your Serverless service or project. In this case, it's named "serverless-lab," which will be used as the service name when deploying to AWS.

provider:
  name: aws
  runtime: python3.7
  lambdaHashingVersion: 20201221
  region: eu-west-1 # enter your region
  profile: personalCaesarAcc
  timeout: 10 # You set a timeout of 10 seconds for the functions
  role: arn:aws:iam::155318317806:role/serverlessLabs # Enter your Arn role here
  memorySize: 512

**provider** defines the AWS provider for your service. It specifies various configuration settings for AWS Lambda functions and other AWS resources.

• name: aws specifies that you are using AWS as your cloud provider.
• runtime: python3.7 sets the runtime for AWS Lambda functions to Python 3.7.
• lambdaHashingVersion: 20201221 specifies the Lambda function hashing version. This is an internal AWS setting.
• region: eu-west-1 specifies the AWS region where your service will be deployed. You can replace "eu-west-1" with your desired AWS region.
• timeout: 10 sets a timeout of 10 seconds for AWS Lambda functions. This means that each function should complete its execution within 10 seconds.
• role: arn:aws:iam::155318317806:role/serverlessLabs specifies the AWS IAM role ARN that your Lambda functions will assume. This role defines the permissions your functions have within AWS services. You can replace this with the ARN of your desired IAM role.

functions:
  first_function:
    handler: handler.first_function
    events:
    - http:
        path: first
        method: get

**functions** defines the AWS Lambda functions in your service.

• first_function denotes the name of your AWS Lambda function.
• handler: handler.first_function specifies the entry point for this function, which is handler.first_function in the handler module. This is typically in the <module_name>.<function_name> format.
• events specifies the events that triggers the function.
• - http indicates that the function is triggered by an HTTP event (API Gateway).
• path: first specifies the API endpoint path (/first) that triggers the function.
• method: get specifies that this function is triggered when an HTTP GET request is made to the specified path.

How to Deploy the Python Function

You can use the command below to deploy the microservice on AWS:

serverless deploy

After a while, the deployment will be completed and you can see information like the endpoint, hosted on API Gateway, to trigger the function you just deployed.

The framework deployed the function on AWS Lambda and, because you attached an HTTP trigger to it. It has deployed an API on API Gateway to let the function be reachable.

How to Test the API

From the deployment, you have a single function named first_function, and a single HTTP GET endpoint.

Using the GET endpoint (the endpoint generated in the terminal after deploying the function) in your browser, you can call the function:

The image above shows the functionality created in the deployed function running in the browser.

Monitoring and Logging

The log group is automatically saved on AWS CloudWatch because there is a print statement defined in the function. Enter the following command to access the function's logs:

serverless logs -f first_function

AWS CloudWatch is the native AWS logging service that lets you monitor and access logs from your applications. You can find log groups, and you can also apply filter expressions on logs to retrieve those you need.

You can delete the microservice and resources you just deployed using the serverless remove command.

Check out my GitHub repository to see the full code

Conclusion

In this comprehensive guide, we've explored the powerful world of serverless computing and demonstrated how to harness its capabilities using the Serverless Framework and Amazon Web Services (AWS).

You've embarked on a journey from setting up your development environment to deploying a simple Python function as an AWS Lambda-backed API, all while gaining insights into monitoring and logging with AWS CloudWatch.

This guide serves as a starting point for your serverless journey. As you become more proficient with the Serverless Framework and AWS, you'll be able to build and deploy sophisticated serverless applications that scale dynamically and meet the demands of modern, cloud-native architectures.

As always, I hope you enjoyed the article and learned something new. If you want, you can also follow me on LinkedIn or Twitter.

In this article, I'll go over some of the most commonly asked questions that come up in interviews about AWS Lambda.

Note that this is not an exhaustive list – but you can use this guide as a reference to refresh your knowledge and get pointers for further study.

Most of the questions will be based on your experience or on certain scenarios. The questions are in the headings and you'll find the notes for the rationale behind asking the questions just below them.

Explain your last project involving AWS Lambda

The interviewer wants to know about your real-life experience using AWS Lambda. Don't bluff here, as the interviewer may ask further questions based on the answers to this question.

You might have built a serverless API, systems involving microservices, image/video conversion, log analysis, and many more. Just explain your project in detail and tell about the business benefits of that project so that the interviewer knows you're seeing the big picture.

What services have you integrated with AWS Lambda?

This is an extension of the previous question. This is not a laundry list of all event sources that can connect to AWS Lambda. Only tell about the services that you've really used.

You may have used S3, SNS, SQS, Kinesis, DynamoDB, SES, or others. Not all projects will be completely serverless.

If you've used any non-serverless component along with AWS Lambda, mention those too. For example, you might've used AWS Lambda with RDS. If you've used such a configuration, you can explain about that along with your reasoning.

Explain the concept of cold and warm starts in AWS Lambda

There are 2 reasons for asking this question. They want to know the runtimes that you've used, and they want to know if you know the other runtimes that could cause a cold start.

Lambda services receive a request to run a lambda function. The service prepares the execution environment by downloading the handler function code and by allocating memory along with other configuration.

Even though you're not billed for this execution environment preparation time, you'll have to face the delay in invoking your lambda function. This delay is called a "cold start".

The cold start timing is less significant for TypeScript and Python runtime environments, whereas it's a bit higher for Java or C# runtime environments.

To improve performance, the lambda service will keep the execution environment for some time. When you receive the request for the same lambda function again during this period, your handler can start executing immediately. This type of invocation is called a "warm start".

Image source

What's the difference between synchronous and asynchronous invocation in AWS Lambda?

Even though this seems to be straightforward question, this has many implications for your design and error handling.

In synchronous invocation, the caller will wait for the execution to complete. But in asynchronous invocation, the caller will put the event in an internal queue which will later be processed in the lambda function.

Image source

An important point to note here is that you can't dictate the type of invocation and it depends on the service that you use with AWS Lambda.

For example, if you're building serverless APIs using API Gateway, it'll be a synchronous invocation. But if you're using S3, it'll be an asynchronous invocation.

How do you implement error handling and retry logic in Lambda?

Any component in event driven system that may fail will fail. So interviewer wants to know how you've handled the error and how you retried in your previous projects. Below are some examples. Always explain with concrete examples.

This depends on the service that you're using with AWS Lambda. Let's discuss this with some examples.

If you're building a serverless API, it is better to return that error to the calling client (could be a front end app in this case). Then you let your front end logic decide what to display to the user based on the type of the error.

If you're using Lambda with SQS, it is better to use a Dead Letter Queue so that you know what messages have failed to process. For this same reason, many of the systems that use SNS may use SQS, too.

In the below code, we're using a dead letter queue. If any message fails to process after a certain number of times (as specified by maxReceiveCount), it's sent to the dead letter queue. This behaviour is specific to lambda when used along with queues.

const queue = new sqs.Queue(this, 'AwsLambdaSqsQueue', {
      visibilityTimeout: cdk.Duration.seconds(300),
      receiveMessageWaitTime: cdk.Duration.seconds(20),
      deadLetterQueue: {
        queue: new sqs.Queue(this, 'AwsLambdaDlq'),
        maxReceiveCount: 5,
      },
    });

When lambda is invoked with any other services, you can configure the number of retries with a maximum value of 2. This means that you can have maximum of 2 retries apart from the initial invocation. For example, you want to trigger based on the S3 object upload and your lambda will try at most 3 times.

Explain your workflows for development and deployment of AWS Lambda functions

Talk about the frameworks that you've used. The interviewer may expect you to talk about testing lambda functions as well.

You can explain which framework(s) you've used to develop and deploy lambda functions. You can also talk about any IaC (Infrastructure as Code) tool that you've used.

Below is non-exhaustive list of the most commonly used frameworks:

• Serverless
• AWS CDK
• AWS SAM
• CloudFormation
• Pulumi

If you've used Terraform, you can talk about that as well.

Can Lambda be invoked when you get an email to a particular support email address? If yes, design that system. If not, explain why.

Yes, you can. You can create receipt rule set and add a rule which triggers the lambda function.

You should store the email to S3 and trigger the lambda after that so that you can have the copy of the email for any further reference.

You can refer to this article on how to receive emails from a contact form.

Image source

Can one lambda function call another lambda function?

The interviewer wants to know whether you know this anti-pattern.

You can do this, but it is not recommended. If you want to design a workflow which involves multiple lambda functions, you can use step functions.

Image source

You can read more about step functions here.

Another standard approach is to emit an event and trigger a lambda based on the event. You can use SQS, SNS, or EventBridge as intermediary for these events.

Can you execute queries on an RDS instance (in a private subnet) using Lambda?

Yes, you can execute the query in RDS using AWS Lambda. For that you can have your lambda inside the same VPC.

There may be some performance implications if you use AWS Lambda directly with RDS because of the database connection creation time. To avoid those, you can use an RDS Proxy.

Image source

Here's a detailed step by step guide that shows you how to do that.

AWS Lambda provides many benefits. What are the cons of using AWS Lambda?

The interviewer wants to know about your thought process. Don't say AWS Lambda solves all the problems :-)

Yeah, Lambda provides many benefits such as cost and scalability without any need to maintain the servers. But it's not the answer to everything – like any service, it has its own problems (and you should be able to discuss them):

• Debugging: If you're using serverless architectures using Lambda, you might have to rely on logging to find the root cause of the issue. This is because your application will be distributed across many services/ lambda functions.
• Testing: You can mock AWS services in your local testing. But it is better to have a separate environment in AWS to test your lambdas. This makes testing a bit complex.
• Background jobs: Lambda has a timeout limit of 15 minutes. If you want any particular task to take more than 15 minutes, you might have to move to Fargate or some other solution.
• Cost: If you're running a high traffic application which processes the requests 24/7, using lambda can be expensive. It is better to use Fargate, EC2 or other services, if you have constant high traffic.

How do you manage concurrency and scaling in AWS Lambda?

Bonus points if you talk about the issues that you've faced in these situations.

Concurrency is the ability to execute multiple lambda functions at the same time. Scaling is the process of increasing the number of copies of your lambda function to handle the incoming requests.

You can control concurrency by setting the value of reserved concurrency so that only the mentioned number of lambda functions will be invoked.

Below is the high level diagram of how lambda scales in accordance with number of messages in the queue.

Image source

Note: There is some weird behavior if you try to throttle AWS Lambda when used with SQS standard queue. You can use a FIFO queue to solve that issue.

How do you pass environment variables to AWS Lambda?

The interviewer might want to know how you pass sensitive information, for example.

There are different ways to pass environment variables to AWS Lambda, and it depends on the type of value is getting passed.

Non-sensitive data: If you want to pass any non-sensitive information, you can pass the values directly to your lambda function environment variables. But these values would be visible in the AWS console in the Lambda service.

In the below code example, we're passing the name of the DynamoDB table directly as environment variable, as it is not sensitive data:

   const readDDBLambdaFn = new NodejsFunction(this, 'readDDBLambdaFn', {
      entry: path.join(__dirname, '../src/lambdas', 'read-ddb.ts'),
      ...nodeJsFunctionProps,
      functionName: 'readDDBLambdaFn',
      environment: {
        tableName: table.tableName,
      },
    });

Sensitive data: If you want to pass sensitive data such as passwords and API keys, you can use either a Secret Manager or Parameter store. But, you need to make sure you provide necessary roles to Lambda for accessing and decrypting secrets from the respective services.

In the below code snippet, we're NOT passing the actual secret. Instead, we're just passing the ARN (Amazon Resource Name) of the secret.

const rdsLambdaFn = new NodejsFunction(this, 'rdsLambdaFn', {
      entry: path.join(__dirname, '../src/lambdas', 'rds-lambda.ts'),
      ...nodeJsFunctionProps,
      functionName: 'rdsLambdaFn',
      environment: {
        DB_ENDPOINT_ADDRESS: dbInstance.dbInstanceEndpointAddress,
        DB_NAME: databaseName,
        DB_SECRET_ARN: dbInstance.secret?.secretFullArn || '',
      },
      vpc,
      vpcSubnets: vpc.selectSubnets({
        subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
      }),
    });

Then, in lambda you can get the actual secret dynamically within the lambda function as shown below:

export const handler = async (event: any, context: any): Promise<any> => {
    const host = process.env.DB_ENDPOINT_ADDRESS || '';
    const database = process.env.DB_NAME || '';
    const dbSecretArn = process.env.DB_SECRET_ARN || '';
    const secretManager = new AWS.SecretsManager({
      region: 'us-east-1',
    });
    const secretParams: AWS.SecretsManager.GetSecretValueRequest = {
      SecretId: dbSecretArn,
    };
    const dbSecret = await secretManager.getSecretValue(secretParams).promise();
    const secretString = dbSecret.SecretString || '';

    const { password } = JSON.parse(secretString);

}

I've written a detailed tutorial here on the same topic.

Say you have a Windows-dependent executable sometool.exe. You can upload it into an S3 bucket. Can you execute this binary with some parameters using AWS Lambda?

This is more of a question to make sure you understand the AWS Lambda execution environment – specifically the operating system it uses.

No, you would not be able to do that as AWS Lambda uses Linux as its operating system. Linux would not be able to execute a Windows-dependent binary.

How do you re-use code across AWS Lambda functions?

There are 2 ways to re-use code across many AWS Lambda functions:

• Use Lambda Layers: You can store your code or logic in lambda layers, which you can re-use across different lambda functions.

Below is some high level code for creating and consuming lambda layers using aws cdk:

    const logicLayer = new lambda.LayerVersion(this, 'logic-layer', {
      compatibleRuntimes: [
        lambda.Runtime.NODEJS_14_X,
        lambda.Runtime.NODEJS_16_X,
      ],
      layerVersionName: 'business-logic-layer',
      code: lambda.Code.fromAsset('src/layers/business-logic'),
      description: 'Business logic layer',
    });


    const lambdaWithLayer = new NodejsFunction(this, 'lambdaWithLayer', {
      entry: path.join(__dirname, '../src/lambdas', 'lambda.ts'),
      ...nodeJsFnProps,
      functionName: 'lambdaWithLayer',
      handler: 'handler',
      layers: [logicLayer, utilsLayer],
    });

• Use monorepo: You can use mono repo and dynamically build packages at deploy time.

What happens to your lambda functions if you delete a Lambda Layer?

In this question, the interviewer wants to see how well you understand lambda layers.

Existing lambda functions which use that deleted layer will continue to work – as lambda layers are merged with lambda functions at deployment time.

But you can't create a new lambda function using that deleted lambda layer.

You can learn more about Lambda layers here and I've written a guide on the same topic here.

Can you increase the size of a deployment package if you use Lambda Layers?

No, you can't increase the size of the deployment package if you use Lambda Layers. The maximum deployment size of 50 MB zipped includes both the size of the lambda function and its associated lambda layers.

If you have a large codebase and want to increase the deployment, you can run containers in AWS Lambda.

Can I take my existing dockerized web application and run it using Lambda?

Nope. You can't take any Express, Springboot, or .NET Core application (or any other application for that matter) as they are and put them inside lambda.

But that being said, there are a few libraries which allow you to put applications that use these web frameworks into AWS Lambda. Internally, those libraries convert those web applications into AWS lambda-compatible APIs. You can see one such example here.

By using these frameworks, the size of your lambda functions will be bigger and will result in longer start up times.

Remember that even when using containers with Lambda, the existing runtime API of Lambda remains the same. Lambda will still:

• be a single function
• be invoked by an event or manually
• have a timeout of 15 minutes.

As you can see in the below code, there will be no change to the lambda API. The advantage of using Docker is that you would be able to use large packages without worrying about size.

import { Context, APIGatewayProxyResult, APIGatewayEvent } from 'aws-lambda';

export const handler = async (
  event: APIGatewayEvent,
  context: Context
): Promise<APIGatewayProxyResult> => {
  console.log(`Event: ${JSON.stringify(event, null, 2)}`);
  console.log(`Context: ${JSON.stringify(context, null, 2)}`);
  return {
    statusCode: 200,
    body: JSON.stringify({
      message: 'Running this handler from docker',
    }),
  };
};

And, this is how you use it:

 const repo = ecr.Repository.fromRepositoryName(
      this,
      'dockerLambda',
      'docker-lambda'
    );

    const dockerLambda = new lambda.DockerImageFunction(
      this,
      'DockerLambdaFunction',
      {
        code: lambda.DockerImageCode.fromEcr(repo),
      }
    );

I wrote a step-by-step tutorial on running Docker containers for your application in aws lambda here.

How do you share large files between lambda functions?

You can use the Elastic File System (EFS) to share large files between different functions.

You can create an access point in the created EFS with the appropriate permissions and use that access point in your mount path in your lambda.

Any files written on that mount path will be accessible to all other lambda functions provided they have the mount path with appropriate permissions.

Below is the high level logical diagram on how to use AWS Lambda with Elastic File System (EFS):

Image source

You can read about this here (bit old). I wrote a more recent practical step-by-step guide here on EFS with Lambda functions.

Conclusion

I hope this article helped you to prepare for interviews involving AWS Lambda.

Thanks for reading to this point. I write about aws and serverless technologies at https://www.cloudtechsimplified.com. If you're interested, you can subscribe to my blog.

In this article, we're going to learn about how to communicate with AWS RDS from AWS Lambda.

In this tutorial, we'll be using AWS CDK. It's an open source software development framework that lets you define cloud infrastructure.

AWS CDK supports many languages including TypeScript, Python, C#, Java and others. We're going to use TypeScript in this tutorial.

When deploying (using the cdk deploy command), your code is converted to Cloudformation templates, and all the corresponding AWS resources are created. Only basic knowledge of CDK and TypeScript is required for trying this tutorial. Of course, you need to have an AWS account to create AWS resources.

You can learn more about AWS CDK from the docs here, and I wrote a beginner's guide to it on my blog here.

Introduction to AWS Lambda and RDS

AWS Lambda is a serverless, event-driven compute service which lets you run your code without having to provision servers.

AWS RDS is a managed relational database service from AWS and supports various RDMBS such as MySQL, Postgres, Oracle, SQL Server and so on. AWS takes care of setting up, patching, and maintaining these database servers.

Why would you use RDS with Lambda?

AWS Lambda is just a compute service and it does not have any recommendation about data stores. In fact, some of your lambda functions will not even interact with data stores of any kind. Even if you want to use a data store, you could use any type of database based on your needs.

However, most of the serverless architectures use DynamoDB as a data store just to reduce costs and eliminate the need to maintain database servers.

DynamoDB is great and has its use cases. But using DynamoDB for all projects involving lambda is not possible for the following reasons:

Dynamic access patterns: If you're using DynamoDB, you would have to design your querying patterns in advance. This isn't always possible, as your product (and its associated requirements) might evolve based on customer feedback.

Limited access patterns: DynamoDB does not provide flexibility in writing your queries. You can't do group by functionality just as you do in RDBMS. You need to export the data and have some other system to provide that functionality.

Existing database: If you have an existing RDBMS database, you wouldn't want to migrate to DynamoDB unless there is a compelling reason to do so. Even if you want to use DynamoDB, you might have to re-write your entire data access layer to use DynamoDB instead of a regular RDBMS.

Pros for using RDBMS:

Relationship between entities: RDBMS allows relationships between entities. You can define foreign keys to restrict any invalid data from getting stored in the database.

Access patterns: RDMBS allows you to use dynamic access patterns. A new entity can be brought in without much change to any of the existing models. And, it has many functionalities such as group by – so that you don't need to have any external system to do such functionalities.

Familiarity with SQL: Most developers are familiar with SQL to query databases, and you have a wide range of databases to choose from, including Oracle, Postgres, and MySQL.

You might choose RDMBS if you have following requirements:

• You have an existing RDBMS database and you'd like to adapt serverless compute provided by AWS Lambda
• You have dynamic access patterns and you don't want to change much of your existing models

With that out of our way, let's discuss how we're going to connect to RDS from Lambda.

Project Architecture

In almost all cases, your RDBMS database will be in a private subnet of the Virtual Private Cloud (VPC) so that no one from outside of the VPC can access it. As your lambda function will contain business logic, this lambda might also be in a private subnet.

We're going to use Postgres as our database in this tutorial. But the process here is applicable for any database (MySQL, Oracle, MS SQL and so on) that you want to use. The architecture will remain the same.

Below is the architecture for this project:

We're going to use AWS CDK as an Infrastructure as Code (IaC) tool to create the AWS resources

How to Create a Virtual Private Cloud to Host our Lambda and RDBMS

We're going to create 2 subnets – a private subnet and a public subnet. In the private subnet, we'll have our Postgres database.

const vpc = new ec2.Vpc(this, 'VpcLambda', {
      maxAzs: 2,
      subnetConfiguration: [
        {
          cidrMask: 24,
          name: 'privatelambda',
          subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
        },
        {
          cidrMask: 24,
          name: 'public',
          subnetType: ec2.SubnetType.PUBLIC,
        },
      ],
    });

When you create a subnet of type PRIVATE_WITH_EGRESS in AWS CDK, it will also create a NAT Gateway and will place that NAT Gateway in the public subnet.

The purpose of the NAT Gateway is to allow only the outbound connections from your private subnet to the internet. No one can initiate connections to your private subnet from the public internet.

Why Are We Using NAT Gateway for Internet Connectivity?

You may be wondering why you need an internet connection, as we have both lambda and the RDS database in the same private subnet.

Secrets Manager is a service from AWS for storing and managing secrets such as database passwords, certificates, and so on. The password for connecting to the database is stored in secrets manager which is accessible by public endpoint.

Either you can use NAT Gateway to access the public endpoint of the secrets manager service or you can create an interface endpoint to connect to secrets manager using AWS Network without going to the public internet.

Both will cost money, but NAT Gateway can be re-used for making internet connections from the lambda too (say if you're calling any public external API) whereas in an interface endpoint you would not be able to do that.

How to Create an RDS Database Instance to Store Our Data:

We're going to use a small instance type for the database – just for the sake of this tutorial. But in production environments, you'll likely be using instances of larger sizes.

We're creating a new security group for the database so that we can control who can access the database instance and through which port.

const dbSecurityGroup = new ec2.SecurityGroup(this, 'DbSecurityGroup', {
      vpc,
    });

    const databaseName = 'cloudtechsimplified';

    const dbInstance = new rds.DatabaseInstance(this, 'Instance', {
      engine: rds.DatabaseInstanceEngine.postgres({
        version: rds.PostgresEngineVersion.VER_13,
      }),
      // optional, defaults to m5.large
      instanceType: ec2.InstanceType.of(
        ec2.InstanceClass.BURSTABLE3,
        ec2.InstanceSize.SMALL
      ),
      vpc,
      vpcSubnets: vpc.selectSubnets({
        subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
      }),
      databaseName,
      securityGroups: [dbSecurityGroup],
      credentials: rds.Credentials.fromGeneratedSecret('postgres'),
      maxAllocatedStorage: 200,
    });

The above CDK code will create a database instance and place it in the private subnet (as per the subnet selection that we've made).

The method fromGeneratedSecret will create the secret in the secret manager service with the user name passed as a parameter. We want the database username to be postgres, so we're passing that value.

And finally, we're allocating 200GB of storage space for the database.

How to Configure Lambda Function Properties

We're using Node16 for writing our lambda function, and below are the generic properties for the lambda.

We want timeout to be 3 minutes instead of the default 3 seconds, and we want to allocate 256 MB for the lambda function.

As aws-sdk is provided by the lambda runtime itself, we want to exclude the aws-sdk library while bundling the lambda.

We've installed the pg npm package for communicating with the Postgres database and we're excluding the pg-native package as we don't need it.

 const nodeJsFunctionProps: NodejsFunctionProps = {
      bundling: {
        externalModules: [
          'aws-sdk', // Use the 'aws-sdk' available in the Lambda runtime
          'pg-native',
        ],
      },
      runtime: Runtime.NODEJS_16_X,
      timeout: Duration.minutes(3), // Default is 3 seconds
      memorySize: 256,
    };

Next, we'll create a security group for the lambda function. Our lambda function should have information about the endpoint, user name, and password of the database so that lambda can connect to the database.

We're going to pass these values as environment variables to the lambda function.

 const lambdaSG = new ec2.SecurityGroup(this, 'LambdaSG', {
      vpc,
    });

    const rdsLambdaFn = new NodejsFunction(this, 'rdsLambdaFn', {
      entry: path.join(__dirname, '../src/lambdas', 'rds-lambda.ts'),
      ...nodeJsFunctionProps,
      functionName: 'rdsLambdaFn',
      environment: {
        DB_ENDPOINT_ADDRESS: dbInstance.dbInstanceEndpointAddress,
        DB_NAME: databaseName,
        DB_SECRET_ARN: dbInstance.secret?.secretFullArn || '',
      },
      vpc,
      vpcSubnets: vpc.selectSubnets({
        subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
      }),
      securityGroups: [lambdaSG],
    });

Important note: We're not passing the database password as an environment variable to the lambda. Instead, we're passing the ARN(Amazon Resource Name) to the lambda and we'll be fetching the actual password (dynamically at runtime ) from the secret manager within lambda for better security.

Permissions for Lambda to Access the Database Password

Even though we pass the secret arn to lambda as an environment variable, lambda should have the necessary permissions to fetch the secret (database password, in our case) from the secrets manager service.

The below line of code provides those permissions:

dbInstance.secret?.grantRead(rdsLambdaFn);

The above cdk line will create a role for the lambda with 2 permissions DescribeSecret and GetSecretValue of the secrets manager so that our lambda will have permissions to get the secret value (database password, in our case) before talking to the database.

You can see the same in the AWS console in Lambda service.

AWS Lambda Permissions for Secrets Manager

Security Group for RDS Database Instance

We don't want to allow the connection to the database to be open for all and we want the database connections to be allowed from lambda.

The below cdk code adds an ingress rule for allowing connectivity from our lambda function to the RDS instance through the port 5432 (port for the Postgres database):

  dbSecurityGroup.addIngressRule(
      lambdaSG,
      ec2.Port.tcp(5432),
      'Lambda to Postgres database'
    );

Lambda Function Code to Communicate with the Database

The actual lambda function code where it talks to the database is pretty simple. As we're using a Postgres database, we're using the pg package to communicate with Postgres from the nodejs environment.

Before initiating the connection to the database, we're fetching the secret string from the secrets manager service. This secret string is a JSON string which contains both username and password. Just parse the JSON string and take only the password.

import * as AWS from 'aws-sdk';
import { Client } from 'pg';

export const handler = async (event: any, context: any): Promise<any> => {
  try {
    const host = process.env.DB_ENDPOINT_ADDRESS || '';
    console.log(`host:${host}`);
    const database = process.env.DB_NAME || '';
    const dbSecretArn = process.env.DB_SECRET_ARN || '';
    const secretManager = new AWS.SecretsManager({
      region: 'us-east-1',
    });
    const secretParams: AWS.SecretsManager.GetSecretValueRequest = {
      SecretId: dbSecretArn,
    };
    const dbSecret = await secretManager.getSecretValue(secretParams).promise();
    const secretString = dbSecret.SecretString || '';

    if (!secretString) {
      throw new Error('secret string is empty');
    }

    const { password } = JSON.parse(secretString);

    const client = new Client({
      user: 'postgres',
      host,
      database,
      password,
      port: 5432,
    });
    await client.connect();
    const res = await client.query('SELECT $1::text as message', [
      'Hello world!',
    ]);
    console.log(res.rows[0].message); // Hello world!
    await client.end();
  } catch (err) {
    console.log('error while trying to connect to db');
  }
};

And, finally we're running a simple select query in our database.

How to Test the Project

Now, you can log-in to your AWS console for testing. Select the Lambda service and select your lambda function – in our case, it would be rdsLambdaFn .

You don't need to worry about the event property of lambda for this tutorial, as we're not using it in our lambda function code. Click the Test button, and you'll be able to see the logs.

Test Lambda function

The Performance Problem

Lambda is well-suited for functions which don't take much time. In fact, the maximum timeout limit of a lambda function is 15 minutes.

As you can see from the lambda code, we're initiating the connection to the database every time the lambda function is invoked.

Depending on the event source for the lambda (SQS queue, for instance), this would create connections at a higher rate and would disconnect at the end of the lambda function.

This increases the load on the RDS server significantly which in turn reduces the performance. So how do we fix this problem?

How to Use RDS Proxy

Instead of directly creating connections from lambda to the database, we can have an RDS Proxy sit in between the lambda and the RDS database.

The purpose of RDS proxy is to maintain pool of connections so that any consumer can connect to proxy and can get the database connection. Note that we're NOT creating a connection here – we're just getting connecting which were created already.

Using RDS Proxy with Lambda

There are 2 advantages of following this approach:

1. Reduced load on the database server: As we don't need to create a connection for every lambda invocation in the database server, the load on the server is reduced significantly.
2. Improved lambda performance: From lambda, we're just getting a connection from the RDS proxy and we're not creating a new connection. This increases performance of the lambda function.

Required Changes to Use the RDS Proxy

We don't need to make many changes either to our architecture or to our code. We just need to do a couple of things:

• Create the RDS proxy and associate the db security group that we've created earlier
• Update the environment variable of the lambda endpoint so that lambda can connect to the RDS proxy instead of RDS directly

You don't need to change your lambda code.

Updated Architecture

Below is the updated architecture diagram

RDS Proxy with Lambda - Architecture

How to Create the RDS Proxy

We need to create the RDS Proxy and add the database instance as the proxy target.

const dbProxy = new rds.DatabaseProxy(this, 'Proxy', {
      proxyTarget: rds.ProxyTarget.fromInstance(dbInstance),
      secrets: [dbInstance.secret!],
      securityGroups: [dbSecurityGroup],
      vpc,
      requireTLS: false,
      vpcSubnets: vpc.selectSubnets({
        subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
      }),
    });

Note that we're passing the database secret to this proxy too, as it is responsible for maintaining connections. We're using the same security group of the database as we did to open the port 5432 .

How to Update the Endpoint for Lambda

We don't need to change the lambda code. We just need to update the endpoint which is passed as the environment variable.

 environment: {
        DB_ENDPOINT_ADDRESS: dbProxy.endpoint,
        DB_NAME: databaseName,
        DB_SECRET_ARN: dbInstance.secret?.secretFullArn || '',
      },

There will be no change to any other code.

Performance Improvements

When you test the lambda function, you can see that the lambda is getting connected to the proxy instead of the database instance (as we're printing endpoint information as host).

You should also notice that performance is improved significantly. Before, it took around 500ms to connect. Now, it is taking around 50 ms.

Performance of lambda with RDS Proxy

Note that it may take additional time when you're getting the initial connection from RDS proxy. And, getting any further connections will be fast, as shown above.

Conclusion

I hope this tutorial helped you learn how to connect to RDS from AWS Lambda.

Thanks for reading to this point. I write about aws lambda, fargate, ci/cd pipeline and serverless technologies at https://www.cloudtechsimplified.com. If you're interested, you can subscribe here.

As developers, we are always trying to optimize everything from how people communicate to how people buy things. The goal is to make humans arguably more productive.

In the spirit of making humans more productive, the software development landscape has seen a dramatic rise in the emergence of developer productivity tools.

This is especially true of the software infrastructure space. Innovators are creating solutions that allow developers to focus more on writing actual business logic and less on mundane deployment concerns.

The need to improve developer experience and cut down costs are some of the core drivers of serverless computing. But what is serverless computing? That's the crux of this guide. It's the one question that matters here, and we will get to it.

To help you walk through this guide, I've divided it into two parts:

• In part one, we are going to start off by learning what serverless is.
• In part two, we will set up a rudimentary serverless REST API with AWS Lambda and API Gateway.

Let's get started already, shall we?

What is Serverless?

To understand what serverless is, first we need to understand what servers are and how they had evolved over time. Wait, servers?

Yes, when we build software systems, most times we build them for people. For that reason, we make these applications findable on the interwebs.

Making an application discoverable, ideally, entails uploading that application to a special computer that runs 24/7 and is super fast. This special computer is called a server.

The Evolution of Servers

Two decades ago, when companies wanted to upload a piece of software they'd built to a server, they'd have to purchase a physical computer, configure the computer, and then deploy their application to that computer.

In cases where they needed to upload several applications, they'd have to get and setup multiple servers, too. Everything was done on-premise.

But it didn't take long for people to notice the many problems that came with approaching servers that way.

There is the problem of developer productivity: a developer's attention is divided between writing code and dealing with the infrastructure that serves the code. This issue could easily be addressed by getting other people to deal with the infrastructure issues – but this leads to a second problem:

The problem of cost. These people dealing with the infrastructure concerns would have to be paid, right? In fact, just having to purchase a server even for seemingly basic test applications is in itself a costly affair.

Furthermore, if we begin to factor in other elements like scaling a server's computing capability when there's a spike in traffic or simply just updating the server's OS and drivers over time...well, you'll begin to see how exhausting it is to keep an in-house server. People craved something better. There was a need.

Amazon responded to that need when it announced the release of Amazon Web Services (AWS) in 2006. AWS notoriously disrupted the software infrastructure domain. It was a revolutionary shift from traditional servers.

AWS took away the need for organizations to set up their in-house server. Instead, organizations and even individuals could just upload their applications to Amazon's computers over the internet for some fee. And this server-as-a-service model announced the start of cloud computing.

What is Cloud Computing?

Cloud Computing is fundamentally about storing files or executing code (sometimes both) on someone else's computer, usually, over a network.

Cloud computing platforms like AWS, Microsoft Azure, Google Cloud Platform, Heroku, and others exist to save people the stress of having to setup and maintain their own servers.

What is outstandingly unique about cloud computing is the fact that you could be in Nigeria, and rent a computer that's in the US. You can then access that computer you've rented and do stuff with it over the internet. Essentially, cloud vendors provide us with compute environments to upload and run our custom software.

The environment we get from these providers is something that has progressed, and now exists in different forms.

In cloud computing parlance, we use the term cloud computing models to refer to the different environments most cloud vendors offer. Each new model in the cloud computing scene is usually created to enhance developer productivity and shrink infrastructure and labor costs.

For example, when AWS was first launched, it had the Elastic Compute Cloud (EC2) service. The EC2 is structurally a bare-bones machine. People that pay for EC2 service would have to do a lot of configuration like installing an OS, a database, and maintaining these things for as long as they own the service.

While EC2 offers lots of flexibility (for example, you can install whatever OS you want), it also requires lots of effort to work with. EC2 and other services like it across other cloud providers fall under the cloud computing model called Infrastructure as a Service (IaaS).

Not having to purchase a physical machine and set it up on-premise makes the IaaS model quite superior to the on-premise server model. But still, the fact that owners have to configure and maintain lots of things makes the IaaS model makes it a not so easy model to work with.

The somewhat labor intensive requirements (from the developer's/customer's perspective) of the IaaS model eventually also became a source of concern. To address that, the next cloud computing model, Platform as a Service (PaaS), was born.

The major problem with IaaS is having to configure and maintain a lot of things. For example, OS installation, patch upgrades, discovery, and so on.

In the PaaS model, all that is abstracted. A machine in the PaaS model comes pre-installed with an OS, and patch upgrades on the machine amongst others are the vendor's responsibility.

In the PaaS model, developers only deploy their applications, and the cloud providers handle some of the low level stuff. While this model is easier to work with, it also implies less flexibility. Elastic Beanstalk from AWS and Heroku are some of the examples of offerings in this model.

The PaaS model undeniably took away most of the dreary configuration and maintenance tasks. But beyond just the tasks that make our software available on the internet, people began to recognize some of the limitations of the PaaS model too.

For example, in both the IaaS and PaaS models, developers had to manually deal with scaling up/down a server's computing capability. Additionally, with both the IaaS and PaaS platforms, most vendors charge a flat fee (Think Heroku) for their services – it's not based on usage.

In situations where the fee is based on usage, it's usually not very precise. Lastly, in both the IaaS and PaaS models, applications are long-lived (always running even when there are no requests coming in). That in turn results in the inefficient use of server resources.

The above concerns stirred the next evolution of the cloud.

The Rise of Serverless Computing

Just like IaaS and PaaS, Serverless is a cloud computing model. It is the most recent evolution of the cloud just after PaaS. Like IaaS and PaaS, with serverless, you don't have to buy physical computers.

Furthermore, just as it is in the PaaS model, you don't have to significantly configure and maintain servers. Additionally, the serverless model went a step further: it took away the need to manage long lived application instances, and to manually scale server resources up or down based on traffic. Payment is precisely based on usage, and security concerns are also abstracted.

In the serverless model, you no longer have to worry about anything infrastructure-related because the cloud providers handle all that. And this is exactly what the serverless model is all about: allowing developers and whole organizations to focus on the dynamic aspects of their project while leaving all the infrastructure concerns to the cloud provider.

Literally all the infrastructure concerns from setting up and maintaining the server to auto scaling server resources up from and down to zero and security concerns. And in fact one of the killer features of the serverless model is the fact that users are charged precisely based on the number of requests the software they deployed has handled.

So we can now say that serverless is the term we use to refer to any cloud solution that takes away all the infrastructure concerns we normally would have to worry about. For example, AWS Lambda, Azure functions, and others.

We also use the term serverless to describe applications that are designed to be deployed to or interact with a serverless environment. Hmmm, how so?

Function as a Service vs Backend as a Service

All serverless solutions belong to one of two categories:

• Function as a Service (FaaS) and
• Backend as a Service (BaaS).

BaaS, FaaS – Nyior, this is getting quite complicated :-(

I know, but don't worry – you'll get it <3

A cloud offering is considered a BaaS and by extension serverless if it replaces certain components of our application that we'd normally code or manage ourselves.

For example, when you use Google's Firebase authentication service or Amazon's Cognito service to handle user authentication in your project, then you've leveraged a BaaS offering.

A cloud offering is considered a FaaS and by extension serverless if it takes away the need to deploy our applications as single instances that are then run as processes within a host. Instead, we break down our application into granular functions (with each function ideally encapsulating the logic of a single operation). Each function is then deployed to the FaaS platform.

Way too abstract? Okay, see the image below:

From Left-to-Right: Deploying an Application to a FaaS platform, Deploying an application to a non-FaaS platform. Source: Author

From the image above you can see that FaaS platforms offer an entirely different way of deploying applications. We've seen nothing like it before: there are no hosts and application processes. As a result, we don't have some code that's constantly running and listening for requests.

Instead, we have functions that only run when invoked, and they're being torn down as soon as they're done processing the task they were called upon to perform.

If these functions aren't always running and listening for requests, how then are they invoked, you might ask?

All FaaS platforms are event-driven. Essentially, every function we deploy is mapped to some event. And when that event occurs, the function is triggered.

Summarily, we use the term serverless to describe a Function as a Service or Backend as Service cloud solution where:

1. We don't have to manage long lived application instances or hosts for applications we deploy.
2. We don't have to manually scale up/down computing resources depending on traffic because the server automatically does that for us.
3. The pricing is precisely based on usage

Also, any application that's built on a significant number of BaaS solutions or designed to be deployed to a FaaS platform or even both can also be considered serverless.

Now that we're fully grounded in what serverless is, let's see how we can set up a minimal serverless REST API with AWS Lambda in tandem with AWS API Gateway.

Serverless Example Project

Here, we will be setting up a minimal, perhaps uninteresting serverless REST API with AWS lambda and API Gateway.

AWS Lambda, API Gateway – What are these things please?

They're serverless cloud solutions. Remember we stated that all serverless cloud solutions belong to one of two categories: BaaS and FaaS. AWS Lambda is a Function as a Service platform and API Gateway is a Backend as a Service solution.

How is API Gateway a Backend as a Service platform, you might ask?

Well, normally we implement routing in our applications ourselves. With API Gateway, we don't have to do that – instead, we cede the routing task to API Gateway.

AWS Lambda, API Gateway, Our Application – How are all these connected?

The connection is simple. AWS Lambda is where we will be deploying our actual application code. But because AWS Lambda is a FaaS platform, we are going to break our application into granular functions, with each function handling a single operation. We'll then deploy each function to AWS Lambda.

Oh okay, but where does API Gateway come in?

AWS Lambda, like all other FaaS platforms, is event-driven. What that means is, when you deploy a function to the platform, that function only does something when some event it's tied to happens.

An event could be anything from an HTTP request to a file being uploaded to s3.

In our case, we will be deploying a minimal REST API backend. Because we are going serverless and more specifically the FaaS way, we are going to break down our REST backend into independent functions. Each function will be tied to some HTTP request.

Actually, we will only be writing one function.

API Gateway is the tool that we will use to tie a request to a function we've deployed. So when that particular request comes in, the function is invoked.

Think of API Gateway as routing-as-a-service-tool :-). The image below depicts the relationship between the above entities.

API Gateway + AWS Lambda. Source: Author

Ok, I get the connection. What's next?

Let's Configure Stuff on AWS xD

The primary task here is to build a minimal paraphrasing tool. We are going to create a REST endpoint that accepts a POST request with some text as the payload. Our endpoint will then return a paraphrased version of that text as the response.

To achieve that, we will code a lambda function that does the actual paraphrasing of text blocks. We will then connect our function to the API gateway, just so whenever there is a POST request, our function will be triggered.

But first, there are certain things we need to configure. Follow the steps in the following sections to configure all that you'd need to complete the task in this part.

Note: Some of the steps in the subsequent sections were adapted directly from AWS' tutorial on serverless.

Step 1: Create an AWS Account

To create an account on AWS, follow the steps in module 1 of this guide.

Step 2: Code our Lambda Function on AWS

Remember, we are going to need a function that does the actual text paraphrasing, and this is where we do that. Follow the steps below to create the lambda function:

1. Login to your AWS account using the credentials in step 1. In the search field, input 'lambda', and then select Lambda from the list of services displayed.
2. Click the create function button on the Lambda page.
3. Keep the default Author from scratch card selected.
4. Enter _paraphrasetext in the Name field.
5. Select Python 3.9 for the Runtime.
6. Leave all the other default settings as they are and click on create function.
7. Scroll down to the Function code section and replace the exiting code in the lamda_function.py code editor with the code below:

import http.client

def lambda_handler(event, context):
    # TODO implement
    conn = http.client.HTTPSConnection("paraphrasing-tool1.p.rapidapi.com")

    payload = event['body']
    headers = {
        'content-type': "application/json",
        'x-rapidapi-host': "paraphrasing-tool1.p.rapidapi.com",
        'x-rapidapi-key': "your api key here"
    }

    conn.request("POST", "/api/rewrite", payload, headers)
    res = conn.getresponse()
    data = res.read()

    return {
        'statusCode': 200,
        'body': data
    }
`

We are using this API for the paraphrasing functionality. Head over to that page, subscribe to the basic plan, and grab the API key (it's free).

Step 3: Test our Lambda Function on AWS

Here, we'll test our lambda function with a sample input to see that it produces the expected behavior: paraphrasing whatever text it is passed.

To test your just created lambda function, follow the following steps:

1. From the main edit screen for your function, select Configure test event from the Test dropdown.
2. Keep Create new test event selected.
3. Enter TestRequestEvent in the Event name field
4. Copy and paste the following test event into the editor:

{
  "path": "/paraphrase",
  "httpMethod": "POST",
  "headers": {
    "Accept": "*/*",
    "content-type": "application/json; charset=UTF-8"
  },
  "queryStringParameters": null,
  "pathParameters": null,
  "body": "{\r\"sourceText\": \"The bone of contention right now is how to make plenty money. \"\r\r\n    }"
}

You can replace the body text with whatever content you want. Once you're done pasting the above code, proceed with the following steps:

1. Click create.
2. On the main function edit screen, click Test with TestRequestEvent selected in the dropdown.
3. Scroll to the top of the page and expand the Details section of the Execution result section.
4. Verify that the execution succeeded and that the function result looks like the following:

Response
{
  "statusCode": 200,
  "body": "{\"newText\":\"The stumbling block right now is how to make big bucks.\"}"
}

As seen above, the original text we passed our lambda function has been paraphrased.

Step 3: Exposing our Lambda Function Via the API Gateway.

Now that we've coded our lambda function and it works, here, we'll expose the function through a REST endpoint that accepts a POST request. Once a request is sent to that endpoint, our lambda function will be called.

Follow the steps below to expose your lambda function via the API Gateway:

Create the API

1. In the search field, search and select API Gateway
2. On the API Gateway page, there are four cards under the choose an API type heading. Go to the REST API card and click build.
3. Next, provide all the required information as shown in the image below and click Create API.

For endpoint type, select Edge optimized

Create the Resource and Method

Resource, Method? In the steps above we created an API. But an API usually has endpoint(s). An endpoint usually specifies a path and the HTTP method it supports. For example GET /get-user. Here, we call the path resource, and the HTTP verb tied to a path a method. Thus, resource + method = REST endpoint.

Here, we are going to create one REST endpoint that will allow users pass a text block to be paraphrased to our lambda function. Follow the steps below to accomplish that:

• First from the Actions dropdown select Create Resource. Next, fill the input fields and tick the check-box as shown in the image below and click Create Resource.

You could replace resource name and resource path with anything you see fit. Notice how we've also enable CORS.

• With the newly created /paraphrase resource selected, from the Action dropdown select Create Method.
• Select POST from the new dropdown that appears, then click the checkmark.
• Provide all the other info shown in the image below and click save.

lambda function is the name of the function we create in one of the previous steps.

Deploy the API

• In the Actions drop-down list, select Deploy API.
• Select [New Stage] in the Deployment stage drop-down list.
• Enter production or whatever you wish for the Stage Name.
• Choose Deploy.
• Note the invoke URL is your API's base URL. It should look something like this: https://wrl34unbe0.execute-api.eu-central-1.amazonaws.com/{stage name}
• To test your endpoint, you can use postman or curl. Append the path to your endpoint to the end of the invoke URL like so: https://wrl34unbe0.execute-api.eu-central-1.amazonaws.com/{stage name}/paraphrase. And of course the request method should be POST.
• When testing, also add the expected payload to the request like so:

{
    "sourceText": "The bone of contention right now is how to make plenty money.   
}

Wrapping Things up

Well that's it. First we learned all about the term serverless and then we went on to set up a light weight serverless REST API with AWS Lambda and API Gateway.

Serverless doesn't imply the total absence of servers, though. It is essentially about having a deployment flow where you don't have to worry about servers. The servers are still present, but they are being taken care of by the cloud provider.

We are going serverless each time if we build a significant components of our application on top of BaaS technologies or whenever we structure our application to be compatible with any FaaS platform (or when we do both).

Thank you for reading to this point. Want to connect? You can find me on Twitter, LinkedIn, or GitHub.

References

Cover Image: hestabit.com

Serverless Development has been around since the release of AWS Lambda in 2014, but in the last few years things have exploded.

Startups and smart tech companies have started taking advantage of the scalability, reliability, and power of serverless to rapidly grow – and now they need more serverless developers than ever.

Being a "Serverless Developer" means you build solutions with managed services from the likes of AWS, Google Cloud (GCP), or Azure. You build solutions by piecing together different services and running all of your business logic in AWS Lambda or CGP Cloud Functions instead of on a server.

With your cloud platform dealing with almost all of the operations (security, redundancy, scalability, and networking), you're left to focus on building the best solutions you can. This means features can be built quicker and companies don't need to hire operations specialists.

This article will cover the 5 steps to learning how to become a serverless developer so you can build some kick-butt products.

In Summary

1. Have solid JavaScript or Python skills. You don't have to be a wizard but being comfortable write an Express or Flask server will make the rest much easier.

2. Pick your framework – choose either The Serverless Framework or AWS CDK.

3. Follow a tutorial to start learning to build with your framework. Start with building an API with API Gateway and Lambda.

4. Learn more about the services you're using. What are the benefits, limitations, good use cases and bad ones?

5. Build what you've learnt in the tutorials into your own project.

Now you've learnt to build an API, add some more services, repeating steps 3-5 each time. A good order could be:

• DynamoDB – getting and writing data

• S3 – reading and writing files

• DynamoDB – with secondary indexes and queries

• Cognito – Authorisation for your API

• AppSync – GraphQL API

1. Solid JavaScript or Python Skills

Before trying to build serverless systems, you really need to have a good grasp on the fundamentals of one of the common programming languages. You don't need to be a wizard, but being comfortable using your chosen language is key.

The reason you need to be comfortable writing good code is that it has a massive effect on the software you build. Serverless is like building blocks and the Lambda code is like the glue. In that code, you write the logic for connecting each part.

You could have the perfect architecture but if your Lambda code is buggy, your solution will be, too.

I recommend either JavaScript (TypeScript) or Python. The reason I recommend these two languages is that most of the companies that will be using Serverless Architecture will be using one of these two languages. Luckily they're also the two languages taught here on FreeCodeCamp 🎉 .

Being the most widely used they also have more tutorials and a bigger community to help when you get stuck.

Another reason that I recommend these languages is that you can write the framework code with the same language you write the Lambda code with. You'll be constantly jumping between lambda code and frameworks config. Not having to switch between languages will save a LOT of you brain juice 🧠

2. Pick your Framework

With a solid grasp of your language, you need a tool to help you create the serverless components in AWS.

There are LOT out there, but I would say you should pick either the Serverless Framework or AWS CDK. I have a bias towards the Serverless Framework as I have a Youtube channel with over 50 videos on building with it. If you're a Python developer then maybe the AWS CDK might be better suited for you.

Why use a framework?

When building a solution it is possible to do it all in the AWS Console. That's how I started my AWS journey.

The issue is that it is not controllable, manageable or scalable. If you want to copy this setup to another account (separate dev and prod accounts) you have to remember all the steps you've done. Working with multiple team members can get messy.

That is why it's helpful to use a framework to allow us to write Infrastructure-as-Code (IaC). This allows us to use Git for version control. This makes working as a team much easier, enables multi-environment deployments, even continuous integration and deployment. All things that are required when running production workloads

The Serverless Framework

• Proven in large, production workloads

• Easy to get started

• Large community

• Lots of tutorials

• Lots of plugins to make many jobs easier

• Not as easy when doing things that aren't serverless

• If you're using Python, you'll have to configure it with YAML

AWS CDK

• From AWS and is actively developed by them

• Good support for almost anything in AWS

• Some cool ways to create re-usable constructs

• Growing community and pool of tutorials

• Can define the config using Python

• Not the same 'Plugins' ecosystem as the Serverless Framework

Other Frameworks

Some of you may say "What about all of the other frameworks?" and I'll address those.

AWS SAM & AWS Amplify

These frameworks are designed to be very easy to do simple things. If you're reading this then you could probably use these to create an API and website quickly and easily.

This is great if that is all you want to do. But if you want more control over how they are deployed or want to deploy more complex systems then you're going to struggle.

Terraform & Ansible

These frameworks have been around for a long time and are used in enterprise as their Infrastructure as Code (IaC) tool.

The reasons I wouldn't learn these as my first framework are:

1. You have to learn a new language. Terraform uses HCL (Hashcorp Language) and Ansible uses YAML. Leaning a new language whilst trying to learn about Serverless architecture isn't ideal. Also switching into that language when you need to create infrastructure is brain zapping.

2. They are opinionated and strict. Getting a small thing not configured perfectly will just not work, often with a hard to understand error.

3. They're not as flexible or powerful as CDK or Serverless Framework.

Webiny & Serverless Cloud

These are very new frameworks that are trying to make IaC as simple but as powerful as possible.

The reason that I would avoid these for now is that they're just too new. This has two drawbacks:

1. The community isn't as big. This means fewer tutorials and fewer people to ask if you get stuck

2. Things change quickly. Best practices and common structure, but sometimes APIs, methods and parameters too. When learning a framework you don't want to have to deal with this stuff.

If there is a feature you absolutely need to use and you have someone who is very experienced with that specific framework, then it could work. I would still recommend one of the main two.

3. Follow a tutorial

With your framework chosen, you can now start building things with it.

The first thing you should build is an API using just Lambda and API Gateway. This is very simple but will get you practice with the core fundamentals of the framework. Understanding the fundamentals will make learning more advanced things much easier.

Why Follow a Tutorial

When learning a new service, it may be tempting to try and learn it by adding it straight into an existing project. I would recommend always trying to follow a tutorial the first time you work with any new service or tool.

When you follow a tutorial it should work without any issues. This means you can focus on learning about the service and how it fits in with everything else.

Adding it into your own project means if something doesn't work you've got to debug it on your own. You might not know whether you've used the service wrong or if there is a bug connecting it to your existing system.

4. Learn more about the services you're using

Now that you've used the new service, it's a good idea to learn a bit more about it. The key things I would want to know about a service I use are:

1. What are its strengths, weaknesses, and limitations?

2. What are some ideal use cases for using the service?

3. What are some use cases where you should avoid using this service?

Knowing these three things, you will be much better able to decide whether a service will be a good fit for the solution you are currently building.

You can learn from a range of places: tutorials, articles, and even the AWS Docs.

For example, AWS Lambda is great for most APIs, but can't run for more than 15 minutes. If I need to build an API that does some batch processing that takes 10-20 minutes then it would time out half of the time. Therefore I need to find another solution.

Again you don't need to understand every little detail about every service, just enough to know when it is a good idea to use and when not to.

5. Build your own projects

Now you know how to build with the new service (from the tutorials) and have a good understanding of when to use the service.

From here it is time to use these services in your own projects.

I would recommend starting with a personal project that you use just for practicing using new services in. That way you don't have to worry about breaking things and you can focus on how the service is working.

You can now start using it in production apps and this is where you'll learn a lot about the details of a service. You learn how to make it meet the business requirements and how it works with other services. If you can do this as part of your job, even better. Else have a deployed app that you treat with the same care.

Repeat steps 3-5

Congratulations! You've learnt how to build an API using a framework.

That isn't the end, as there's always more to learn and a way to become a better serverless developer. Pick a new topic, service, or design pattern and repeat steps 3-5.

If you've just made your first serverless API, then here are the next topics and services I would learn to continue your journey.

• DynamoDB – creating a simple table, getting and writing data

• S3 – creating an S3 bucket, reading and writing files

• DynamoDB – with secondary indexes and queries

• Cognito – Authorisation for your API

• AppSync – GraphQL API

After that, focus on creating features for your solutions and use that to guide what to learn next.

If you're a JavaScript developer wanting to use the Serverless Framework, then a great place to start is my Youtube channel where we create tutorials on becoming the best Serverless Developer that you can be.

One night in June, 2017 I stumbled across a website called freecodecamp.org. I was a teacher at the time who was looking for a career change. But I assumed being a programmer was out of my reach.

After all, I didn’t consider myself a math whiz, never went to school for computer science, and felt I was too old to get into coding.

Thankfully, freeCodeCamp helped me take my first steps toward becoming a developer, and I soon shed each of those self-limiting thoughts.

Now, as a Samsung software engineer and three-time certified AWS developer, I look back at those nights and weekends I spent working through the freeCodeCamp curriculum and see them as a major contributor to my successful work transition and my accomplishments as a programmer.

With my teacher-heart still present, though, I wrote this post to encourage other freeCodeCamp students to continue with their learning as well as to supplement their freeCodeCamp curriculum.

Familiarity with cloud computing, like AWS, Azure, or Google Cloud, is an increasingly present requirement in job postings.

This post will give any newbie who is still working through freeCodeCamp’s curriculum a simple introduction into the vast world of cloud computing. I'll show you how to take one of your freeCodeCamp front end projects and deploy it on AWS in a variety of ways.

Enjoy, and thank you freeCodeCamp!

Prerequisites

The point of this post is to extend your learning from the Front End Development Libraries Projects portion of the freeCodeCamp curriculum by deploying them to AWS.

So the prerequisites are:

1. finish one of the Front End Libraries Project challenges
2. have an AWS account (go here to sign up)

Why Deploy Your Project to AWS?

As you work through the freeCodeCamp curriculum and you finish your Front End Libraries Projects, you submit those projects via CodePen where freeCodeCamp has a series of unit tests to verify that you correctly completed their user stories.

Confetti falls, you see some inspirational phrase, and you’re probably very proud of your project. You might even want to share that accomplishment with your friends and family.

Sure, you could share your CodePen link with them, but in the real world when a company finishes a project they don’t make it available via CodePen – they deploy it. So, let’s do that too!

Just a quick note: when I say “deploy”, I mean taking your code from a local environment (your computer, or the freeCodeCamp or CodePen editors) and putting it on a server. That server, which is just another computer, is networked in such a way for the world to access your site.

If you wanted to, you could set up a pc in your home and do the proper networking for it to serve your project to the world. Or, you could subscribe to a hosting company for them to serve your website for you.

There are a variety of approaches to deploy code, but one very popular method is to use a cloud computing platform like Amazon Web Services (AWS). More on that next.

What is AWS? A Brief Intro to the Cloud

Amazon Web Services (AWS) offers a “cloud computing platform”. That’s a little jargon with a lot packed into it. Let’s unpack.

AWS has services ranging from simply storing files, running servers, converting speech to text or text to speech, machine learning, private cloud networks, and about 200+ other services.

The basic idea behind cloud computing is to gain on-demand IT resources. The alternative, like we talked about earlier, is for you to own those IT resources.

There are a number of benefits to using a cloud computing platform instead of owning, one of the main ones being the cost savings.

Imagine trying to pay for all the physical IT resources that it would take to run the 200+ services AWS offers. That upfront cost is something most companies cannot afford, and fewer could pay for the engineers to configure.

Also, since the resources are on-demand, cloud platforms allows you to launch resources much faster than an IT department could.

In short, with a cloud computing platform like AWS you save on cost and deployment time, plus many more benefits not the least of which is security. Needless to say, cloud computing is the new sexy approach to IT and AWS is leading the pack.

Why does this matter to you? If you intend to pursue a career in development, regardless of your focus (backend, frontend, web technologies, mobile apps, gaming, desktop applications, and so on) you will find that many job postings include a reference to cloud compute platform experience.

So the more you can become familiar with one, like AWS, the more you’ll separate yourself from other candidates.

How to Deploy your freeCodeCamp Project with AWS S3

What is AWS S3?

Throughout this post we’ll deploy your freeCodeCamp front end project using various services on AWS.

Our first approach is through the AWS service called S3. S3 stands for Simple Storage Solution. As you might have guessed from that name, the service lets you simply store stuff, more specifically objects.

You can find tutorials and courses on S3 that are hours and days long. On the surface though, it’s just a place where you can store objects. Objects can be things like image files, video files, even HTML, CSS, and JavaScript files.

As you dive deeper into S3, you’ll learn that S3 allows you to do a lot of things to and with those objects. But for our project, we just want to learn how to store objects and look at a single one of those deeper features – using S3 as a website hosting service.

Thats right, AWS S3 is a service we can use to deploy a website.

How to Get Your Project Ready for Deployment

Throughout this post, I’ll be using the Random Quote Machine project. I am using the code from the example provided in the instructions.

We need to take your CSS, HTML, and JS code from CodePen and put them into their own separate files in a text editor.

Open Your IDE (for example, Visual Studio Code)

In the CodePen environment, CodePen links your CSS to your HTML code, as well as your JS file to your HTML. We need to account for this before we deploy to S3, so we are going to test locally first.

Open your editor of choice, and create a new directory (folder) to hold your three CodePen files. I called mine random-quote-machine. Next, create three new files:

• index.html
• styles.css
• main.js

Three empty files: main.js, styles.css, and index.html

Go ahead and copy your CodePen HTML file into index.html, CodePen JS file into main.js, and CodePen CSS file into styles.css.

Check your tags

CodePen does not require the <body> tag, but it’s good practice to add that. Make sure your HTML content has one. Look back at your fCC curriculum if you don’t remember where these go.

Add and

You will now need to link your styles.css and main.js to your index.html, since CodePen no longer does it for you.

Above your <body> opening tag, add <link rel="stylesheet" href="style.css" /> which will make your css in styles.css take effect.

Below your <body> closing tag add <script src="main.js"></script> which will link your JavaScript in main.js file accessibly to index.html.

Verify that Your Site Still Works Locally

It’s time to test that our code is working. Open a web browser, and then type ctrl+o to select a local file to display in the browser. Navigate to your folder with our three files, and then double click on index.html to open it.

If everything is working, great! It wasn’t for me though. The code I used had SASS styling, which I needed to make some adjustments to.

If you imported any libraries via CodePen, those would need to be imported, likely through the CDN. A simple Google search for those libraries’ documentation should help you to find out how to import them.

Make whatever changes you find necessary to get your project in working order, but remember, the purpose of this exercise is to learn about deploying a website on AWS S3. So if you’re getting bogged down with something small but the site mostly works, continue on with this tutorial to keep the momentum going and then at a later time resolve whatever CSS or JS issues you have.

Once your site works locally, even if not 100% to your liking, let's get into AWS.

How to Work with the S3 Management Console

After logging into AWS, in the top search bar type “S3” and then select the option that says “S3”, not “S3 Glacier”.

Searching for S3 in the AWS Management Console

Alternatively, instead of the search bar you could expand the “Services” dropdown and enjoy looking at all the AWS service offerings. Either way, let’s click on S3.

You should now see the S3 Management Console. Something like this…

The S3 Management Console

This is what AWS calls the Management Console. It’s the website interface to interact with AWS and create resources and services.

There is a Management Console for all of the AWS services, but this console is not the only way you can interact with AWS. There is also a CLI (command line interface), which allows you to script to AWS what you would like to do.

Instead of clicking on buttons, in the CLI you type what you would otherwise have clicked on (though less verbosely). We are going to stick with the console for now.

Here you can view all of your S3 buckets. S3 is composed of buckets, and a bucket is basically a big container where we get to put files. Think of a bucket as a drive on your computer (like your C: drive). It technically isn’t – it’s a method for routing in S3 – but for now it’s fine to see the bucket in this way.

Create Your S3 Bucket

Click on the Create bucket. Then, enter a unique name for your bucket (no spaces allowed).

The name of your buckets must be globally unique. So, if you try to create one named test, there is probably someone in the world who used that already so it won’t be available.

Entering my new S3 bucket name

After inputting your bucket’s name, scroll down to the section called Block Public Access settings for this bucket. We want to uncheck the Block all public access checkbox, and then further down check to acknowledge the warning box that appears.

Your settings should match this

Security and permissions in AWS is a lengthy topic, but, as you can see by the warning, you typically do not want to unblock public access to your files.

In our case, we want our website’s visitors’ web browsers to be able to access our index.html file so that they can see our project.

There are other methods we could use to unblock access to our bucket’s content, but for now this is sufficient for our goal of introducing you to S3 and deploying a project on AWS.

Scroll down to the bottom of the form. Click the Create bucket button at the bottom. If your name was unique, you just made your first AWS S3 bucket, congrats!

It’s pretty amazing to stop and think that in that short amount of time, AWS just made space available for you in their network to store an unlimited amount of data. That’s right, unlimited!

Although the maximum size for a single object in your bucket is 5 terabytes (good luck hitting that), your new bucket can hold as much as you want in it.

Upload Your Files to Your Bucket

Next, back in the S3 console view, click on the link to your newly created S3 bucket. Once inside, we want to click on the Upload button. Select your three files (index.html, styles.css, and main.js).

After you see their names show up in the list of items about to be uploaded, scroll down to the bottom of the upload form.

Expand the Additional upload options, and then scroll down to the Access control list (ACL). Check the Read boxes for Everyone (public access), and then check the acknowledgement box that appears underneath, just like when we created our bucket.

Your selections should look like this

Scroll down the rest of the way and click the Upload button.

Enable Hosting on the S3 Bucket

Now we have our S3 bucket, we have our files, we have them publicly accessible, but we’re not quite done.

S3 buckets by default are not configured to be treated like web servers. Most of the time companies want the contents of S3 buckets kept private (like hospitals storing medical records, or banks saving financial statements). To make the bucket act like a web server, providing us with a URL to access our files, we need to adjust a setting.

Back at your bucket’s main menu view, click on the Properties tab.

Select the Properties tab

Scroll down to the bottom until you find Static website hosting, and click the Edit button. Set Static website hosting to Enable, and then in the Index document and Error document type index.html. Then click the Save changes button.

Your selections should match this

You’ll return to the Properties tab of your bucket. Scroll back down to the Static website hosting section, and there you’ll find a link.

Reading that URL you’ll notice the name of your bucket is in it. By typing index.html in the two fields during the configuration, we told AWS that when this bucket’s URL is opened to use the index.html page to load.

You should see your bucket’s website endpoint now

If you click on that link, your project should now be viewable.

Troubleshooting

If your site worked locally, but is not working when you open the S3 website endpoint link, there are a few common problems to try and resolve.

First, make sure you selected the same files that worked locally. Reopen the local files in a web browser to make sure they work. If it works locally but not through S3, try re-uploading them and ensure you select the same files.

Next, go to your bucket’s Permissions tab and make sure you have the Block all public access set to Off.

Lastly, delete your files you uploaded, and re-upload them, ensuring that you select the Read checkboxes described above, as well as the acknowledgement box.

If you are still having problems, feel free to comment with your issue and I’ll be happy to help. Don’t get too discouraged either. AWS can take a while to learn so go easy on yourself if things aren’t falling into place the first time.

You Did It!

Now, instead of sharing a CodePen URL to your friends and family, you have your very own S3 bucket website endpoint to share.

Granted, it’s still not your own personalized domain, but hey, it’s still cool to know you just deployed a website the same way thousands of businesses do.

You’ve now not only learned the front end skills associated with freeCodeCamp’s Front End Libraries Projects, but you also took your first steps into cloud computing with a deployment of a website. You should be very proud!

More on S3

Configuring an S3 bucket to be a website endpoint is just one of many ways to use S3. We could also use S3 to store data that we want to pull into an application. For example, the quotes on our Random Quote Machine could be stored in S3 as a JSON file, and then our front end could request them.

That might seem like an odd adjustment to make when they could just be listed in our main.js file. But if we had other apps that needed access to those quotes then S3 could act as a central repository for them.

This is in fact the most popular way to use S3, as a data store for applications. We could also use the Glacier option of S3 to archive objects that we don’t anticipate accessing frequently, which would save us money from the standard S3 bucket configuration.

One last idea, though not the last way to use S3, is that we could save logs from a running application to an S3 bucket so that if there was a bug we could inspect those logs to help identify the source of the problem.

Whatever the use case, the concept of S3 is the same: we are storing objects in a bucket and those objects have permission settings to determine who can view, edit, or delete them (remember, we set our files to be publicly readable).

Next Up!

As stated before, AWS has hundreds of services, which means there are sometimes multiple ways to do a job. We walked through one way to host a site, but there are two more worth noting that will help you gain more exposure to AWS as a whole.

How to Deploy your freeCodeCamp Project with AWS Elastic Beanstalk

Now we're going to learn more about the AWS cloud platform services and see an alternative way to deploy your code so you can experience more that AWS has to offer.

Specifically, we are going to get an introduction into several of the core AWS services and resources: EC2s, Load Balancers, Auto Scaling Groups, and Security Groups.

Wow, that’s a lot of topics to cover. In the first part above, we only looked at S3 – how are we going to learn about all these other services?

Well, thankfully AWS offers a service called Elastic Beanstalk which bootstraps the deployment process for web applications. By deploying your freeCodeCamp project via Elastic Beanstalk you can quickly gain experience with these core AWS services and resources.

We will use the AWS service called Elastic Beanstalk to deploy

Before We Jump Back into AWS

We discussed in Part 1 that to “deploy” code means to configure a computer in a way to serve the project and make it accessible to visitors. The nice thing about cloud computing platforms is that the configuration of that server can be done for us if we want.

Consider our S3 deployment for a second. Our files were stored on a machine owned by AWS, and AWS took care of configuring that computer to serve the index.html page and give us an endpoint for viewing the project.

Aside from telling S3 the name of our index.html file, we did none of that configuration and yet we still walked away with a deployed project and an endpoint to view it.

When we use Elastic Beanstalk, it will similarly include AWS handling a lot of configuration for us. But this time we are also going to do a bit of configuring ourselves.

By doing this, we will see an alternative and very popular method for deploying a web application. This time, we will add code that “serves” the index.html but we’ll let AWS handle the launching of the hardware and giving us an endpoint to view our project.

Let’s Configure!

We are going to add some code to our project to serve our index.html. Remember, S3 did this behind the scenes for us.

I have created a Git repository for you to clone or download and use for this tutorial. If you’re familiar with Git, then feel free to clone the repo and jump ahead to Paste Your Code. But if you’re not familiar with Git, then follow the instructions for downloading this repo.

Download the Repo

• Go to https://github.com/dalumiller/fcc-to-aws-part2
• Click on the green Code dropdown menu and then select Download Zip
• Unzip/extract the files from the zipped download

Paste Your Code

In the newly downloaded/cloned folder (which I'll refer to as fcc-to-aws-part2 folder), we want to paste your index.html, main.js, and styles.css files that we uploaded to S3.

In the fcc-to-aws-part2 folder, there is another folder named public which has empty index.html, main.js, and styles.css files. Go ahead and paste your code into those.

After pasting, let’s confirm everything is working so far.

Open a new browser tab, and then type ctrl+o and navigate to fcc-to-aws-part2/public/index.html. Open index.html in that new tab. Your app should be running now.

If it is not, stop and make sure you pasted the correct code into the correct .html, .js, and .css files. Also, make sure you’re using that same code that worked during your S3 deployment.

With that working, we are now ready to discuss what this extra stuff is in the fcc-to-aws-part2 folder. Make sure you do not make any changes to any files other than the index.html, main.js, and styles.css.

Configuration with Node.js & Express.js

Remember I said we were going to do some configuration this time? Node.js (aka Node) and Express.js are what we’re using to accomplish that configuration.

freeCodeCamp has a tutorial on Node and Express, so if you’d like to pause and go through that feel free. But I’ll also provide a brief introduction explaining why and how we are using Node and Express.

Why Use Node?

Node.js is a JavaScript runtime for server-side applications. That is a lot of jargon, so let’s break it down a bit.

“Node is a JavaScript runtime” – a runtime, in the world of programming, is an execution model. In other words, it is a process that implements how to execute code. So, Node, is a process that implements how to execute JavaScript code.

When we have JavaScript code like this:

console.log("Hello World")

Node knows what to do with that code.

“…for server-side applications”- remember that we are trying to deploy our code to be served by a server, and that a server is just a computer. Also, note that a server is different from a client, and in the case of a website the client is the web browser.

When you open your project in a web browser, the browser handles reading the index.html, main.js, and styles.css files. That’s right, the browser (client) knows how to read and execute JavaScript code, so that when it sees console.log("Hello World") it knows what to do.

Our main.js file is JavaScript code that is being run client-side, by the browser. But, Node is for server-side JavaScript. So, your browser knows how to run that JavaScript code, but how does the computer that serves our website know how to run JavaScript? Node.

JavaScript can run on the client (ie: web browser) and server

So, all together, “Node is a JavaScript runtime for server-side applications” means that Node is a process for implementing how to execute JavaScript code on a server, as opposed to a client like a web browser.

Without Node, the computer/server does not know how to run JavaScript code.

Why Use Express?

Expres.js a web application framework for Node.js

While Node gives us the server-side runtime, which is that environment where we can run JavaScript code, Express gives us a framework for serving web applications.

When we deployed via S3, we told S3 the file name we wanted served (index.html). Now, Express will be where we configure what file we want served.

If we had a website with different routes (ie: www.example.com/home, /media, /about, /contact), then we might have different HTML files for each of those pages. We would use Express to manage serving those pages if the web browser requested them.

For example, when the web browser requested www.example.com/contact, Express would get that request from the browser and respond with contact.html.

app.js

Now we know that Node is what lets us run JavaScript code on the server and Express is handling our requests from the browser. So let’s look in fcc-to-aws-part2 at our app.js file and read it line by line to understand what we’ve added to our project.

First…

const express = require("express");

This declares a variable called express, and then the = sign means we are assigning it a value. But what’s this require(“express”)?

The require function is just a function Node is aware of, and when Node sees it then Node will look for a folder in the node_modules folder by the same name. You have this node_modules folder in your fcc-to-aws-part2 folder.

Once Node finds express inside the node_modules folder, it will import the code from the express folder and assign it to the variable we declared. This lets us use the code that comes from the express folder without having to write it ourselves. This importing code into our code is the concept of modules.

A module is just a bundle of code. It could be one line long or much longer. Therefore, a NODE_module (emphasis added to node) is a bundle of code that can run in the Node runtime. We are using, or require-ing, the express module.

The express module is the Express.js web application framework we discussed earlier.

I won’t got into how to add modules to the node_modules folder, but for now know that by declaring the variable express and using the require(“express”) syntax, we are bringing in that Express.js framework and making it accessible via the variable we assigned it to.

There was a lot packed into those previous four paragraphs, I recommend slowing down and reading it again to make sure you really got it!

Next up…

const path = require("path");

Ah! This should look familiar now. We are bringing in another module, this time the path module. We’re assigning it to the path variable.

You might have noticed a pattern that the variable name we use matches the module name. It doesn’t have to be that way. We could assign the path module to the foobar variable. But it makes more sense to name it what it is.

What does the path module do? It is a module (just a bundle of code) that lets us work with file and folder paths. This way we can use a JavaScript syntax that Node understands in order to access files/folders on our server. That will come in handy when we want to reference where index.html is located in our project.

Alright, moving on…

const app = express();

Express, again? That’s right. The first time we were just importing the module, now we are using it.

To use the Express framework we have to instantiate it, meaning we have to run this express function, express(), and now we’re assigning it to the app variable.

“Whoa, but Luke, why not have this line of code right after the earlier express line of code?”

Good question. It is a common pattern to import (or use require()) all the modules you’ll need at the top of your code, and then use them after you’re done importing.

Now for the big banana…

app.use(express.static(path.join(__dirname, "public")));

Whoa there! Let’s break this apart a little.

First, we are calling a function, the app.use() function. This is telling our Express application that we want to USE another function in our app. Makes sense.

The function we are telling Express that we want run is the express.static() function being called inside of the .use() function parameter. So, app.use() is telling Express we want to use some code in the app, and specifically here we are wanting to USE express.static(path.join(__dirname, “public”)).

Now, express.static() is an Express function which we can use since it’s part of the module that we imported and assigned to the express variable.

The .static() function handles serving static files. I hope your ears perked up and eyes opened wide! I’ll say it again. The .static() function handles SERVING static files. Serving!

Remember, in this deployment approach we are handling a bit more of the configuration to SERVE our project. Here is the Express function that we are using to say, “I want to serve some static files”. Static files means our index.html file.

So, app.use() was saying, “Hey, I want to run some code for this app inside my function parameter”. Specifically we want to run express.static() which says, “I want to deliver static files, like an index.html”, and then its function parameter tells us where to find those static files.

So let’s look at path.join(__dirname, “public”) to understand how it’s telling us where our static files are.

Earlier we imported the path module to be able to access files in our server/computer.

Well, we want to access the index.html file, which is the public folder. We use the path function .join() to say, “hey, from our current directory (or, folder), go to the public folder to find the files I want”. That will return the index.html, main.js, and styles.css to the express.static(), which will return to the app.use() function that is handling what files to serve (SERVE!) our visitors.

All together now!

app.use() = “when the browser requests the app, I want to run express.static()"

express.static() = “I am going to deliver some static files and they are located here…"

path.join(__dirname, “public”) = “grab the files in the public folder”

Yay! We did it! We configured out Express app running in the Node runtime to deliver the index.html, main.js, and styles.css files when someone visits our site.

But wait…there’s more:

const port = 8080;
app.listen(port);

Remember that the app variable is our instance of the Express framework. The .listen() function is the app telling the computer, “hey, any requests made on port 8080, bring them my way!”

Ports and sockets are a more advanced topic, so we won’t get into it now. But just know that a computer/server has many ports, which are like access points, and we are configuring Node/Express app to only listen to one access point, 8080.

Lastly…

console.log("listening on port: " + port);

This is standard practice for Express apps, where we are just logging out on the computer what port we’re running. It gives us some verification that the Express application works.

Great job! That was a lot of code to walk through.

Now, if you’re familiar enough with how to navigate via a terminal, we can test this Express app locally on our computer before moving on to AWS. Ensuring it works locally before we go to AWS will help us in case we have errors in AWS because we’ll know the errors can’t be related to our Express app not working.

How to Test Our Node/Express.js App

If you open the package.json file, you’ll see a “scripts” section. This package.json file is metadata for our Node application, and it also can contain configurable commands to run in the “scripts” section.

I’ve included the “start” script, which runs the app.js file in the Node environment, which in turn runs our Express.js code we just discussed. This “start” script is how we run our project.

To test this out, in your terminal navigate to our fcc-to-aws-part2 folder, enter npm start to start the app.

Terminal command to run our app

After running that command, you should immediately see our console.log() message informing us that the app is running on port 8080.

You should see the “listening on port: 8080” message to know it’s running

Now, to view your project, open a web browser and enter localhost:8080 in your address bar and click Enter. You should now see your project running!

If you don’t, make sure you are using the correct index.html, main.js, and styles.css files, and that you didn’t alter any of the code from fcc-to-aws-part2.

Woohoo!

Alright, now we have configured Node and Express to serve our project. Our local computer is acting as the server at the moment, but we want anyone in the world to be able to view our project and they can’t do that via our localhost:8080 address.

So, we are going to use AWS to host a server for us, put our app on it, and then let AWS manage the configuration necessary to generate the URL endpoint for the world to access. That’s where the AWS service called Elastic Beanstalk comes into play. Let’s get to it!

Go to AWS Elastic Beanstalk

After logging into your AWS account, search for the Elastic Beanstalk service in the top search bar. Once there, click the Create Application button.

The Main Console page for AWS Elastic Beanstalk

Next we’ll add the name for our Elastic Beanstalk application.

Enter your desired application name

Skip the Tags section, and let’s enter information for the Platform and Application Code sections.

Our Platform is Node.js, the Platform Branch is Node.js 14 running on 64bit Amazon Linux 2 (that’s telling us what kind of server is running Node), and Platform Version is whatever AWS recommends. Then for Application code, we are going to upload our code.

Our settings for the Elastic Beanstalk app

Click the Create Application button.

Upload And Deploy

Before we click the Upload and Deploy button, we need to zip our project. Open the fcc-to-aws-part2 folder, and select all of the files in it and zip them up. DO NOT zip the fcc-to-aws-part2 folder itself – that won’t work.

The contents of fcc-to-aws-part2 zipped together, not fcc-to-aws-part2 zipped

Now, with your files zipped, click the Upload and Deploy button in your Elastic Beanstalk environment. Select your zipped file.

Upload your zipped project

After uploading your code, a black box will appear giving us a series of logs which are the steps being taken to launch the Elastic Beanstalk application. Revel in the fact that with each log entry, that is a configuration we did not have to do.

The start of our logs

Once it finishes, you’ll be navigated to the main view of your app. You’ll see your environment has a Health status that is probably red at the start.

Do not be alarmed by this. AWS is now going through the configuration process that we don’t want to do, namely the launching of the server, the creation of the URL endpoint, and then running our app. It takes a few minutes for that to finish.

This is when Elastic Beanstalk is doing all of that configuration for us that makes cloud computing platforms so handy!

Notice at the top that you already have a URL endpoint given to you. Once the Health improves you should be able to open that link to see your project.

Your url can be found here (under Randomquotemachine-env-1)

If your health status never changes to orange and then green, then something is wrong. The best thing to do is re-download the fcc-to-aws-part2, paste your code in, and then re-zip the contents of fcc-to-aws-part2, not the fcc-to-aws-part2 folder itself, and upload it again to Elastic Beanstalk.

Once the health status improves, you should be able to open the link and see your project. More importantly, anyone in the world can now see your project with that link!

A healthy app, time to go check it out!

You Did It!

Congratulations!

I know this was a longer and more detailed process than the S3 deployment, but you did it.

We took on doing some of the configuration ourselves this time by creating a Node/Express app to serve our static files, but we still let AWS handle creating and configuring the server, its environment, and the endpoint for us to run our project on and view.

Even with our time spent going through the Express code, the amount time it took to deploy this project is minimal since AWS is automating so much for us.

We didn’t have to take the time to buy a server, install programs onto it, set up a URL endpoint for it, or install our project onto it. That’s the benefit of cloud computing platforms like AWS.

NOTICE: Be sure to stop or terminate your EC2 Instance, or delete your Elastic Beanstalk Application when you’re done with it. If you do not, you’l be charged for however long your application runs.

The Underlying Services of Elastic Beanstalk

I mentioned at the start of this section that the beauty of Elastic Beanstalk is that by using this service we actually get an introduction to many services: EC2, Load Balancers, Auto Scaling Groups, and even Cloud Watch.

Below is a brief explanation of those to further your learning about AWS and its services.

To get a better visual to see some of the depth of configuration Elastic Beanstalk did for us, navigate to the Configurations link and scroll through the page.

An overview of the configurations Elastic Beanstalk does for us

EC2

In the Configuration Overview there is a category called Instances.

The Instances configuration category

Instances is another word used for server, or computer. Remember that we’re deploying our code to a server, well AWS calls those servers Instances, and more specifically they’re called EC2 Instances.

EC2, short for Elastic Computer Container, is a service by AWS that lets you launch EC2 Instances very quickly. We can “spin up” a server quickly using EC2 and put whatever we want on it.

In our case, Elastic Beanstalk ran the EC2 service for us and started an EC2 Instance for our application to be hosted on.

If you still have your Elastic Beanstalk app running we can go look at your EC2 Instance. At the top of your screen, in the AWS search bar, enter EC2 and click enter.

You should see that you have one instance running, like this…

Your EC2 Management Console

If you click on the Instances (running) link you’ll get to look at the specifics of the EC2 instance. This EC2, again, is just a computer running in some AWS site that has your code on it. The EC2 was launched by Elastic Beanstalk for us.

Load Balancer

Not only did the Elastic Beanstalk create an EC2 Instance for us, it also created a Load Balancer for us. In the EC2 Management Console, on the left navigation panel scroll down to Load Balancers and click the link to see the one made for you.

A load balancer’s purpose is to distribute incoming traffic across multiple targets. That target in our case is an EC2, but we only have one running, so a load balancer is not all that useful at the moment.

Let’s pretend for a moment that our app went viral and we had tens of thousands of people trying to access the endpoint Elastic Beanstalk gave us. That single EC2 Instance would be overwhelmed with traffic. Requests would timeout, visitors would get frustrated, and our site would suffer since we don’t have enough EC2s to handle the load.

But! If we DID have more EC2 Instances running, each with our project deployed on it, we’d be able to handle going viral.

Though there is a problem that arises from having mulitple EC2s. We need each EC2 instance to be reachable by that same Elastic Beanstalk endpoint, and that’s tricky networking.

That’s where the Load Balancer comes in. It provides a single access point for our Elastic Beanstalk to target, and the Load Balancer then handles keeping traffic organized between the different EC2s and the Beanstalk.

If you look at your Load Balancers Basic Configuration, you’ll see a DNS Name, which looks a lot like the Elastic Beanstalk endpoint. If you open it, your app should run. That’s because the Elastic Beanstalk endpoint actually points to this endpoint which is able to balance traffic among multiple endpoints.

Load Balancer view in the EC2 Management Console

Now, you might be wondering “Luke, how do I get more EC2s to launch so that I can capitalize on this sweet load balancing action?” Glad you asked! The answer is Auto Scaling Groups!

Auto Scaling Group

As the name suggests, this AWS service automatically scales a group of EC2 Instances based on a set of criteria. We currently have only one EC2 Instance running that our Load Balancer targets, but an Auto Scaling Group has configurable thresholds to determine when to add or remove instances.

To see your Auto Scaling Group, in your EC2 Mangement Console’s left-side navigation scroll down towards the bottom until you find Auto Scaling Group and click on the checkbox next to the single Auto Scaling Group listed.

Auto Scaling Groups list in your EC2 Management Console

Feel free to peruse the various details found in the tabs, but I want to point out a few details.

First, click on the Details tab, and look at the Desired, Minimum, Maximum Capacity settings. It should default to 1, 1, and 4 respectively. These values are configurable and they're our way of telling AWS how many EC2 Instances we want running.

Since EC2 Instances cost money to run, companies want to fine tune how often new ones are added or removed. Ours says that we only want one running, minimum of one instance running, and four at maximum. If you edit the desired value to 2 you’ll see that a new instance will launch.

Our Auto Scaling Group capacity settings

But how does Auto Scaling Group know when to add/remove instances? Click on the Automatic Scaling tab to see our current configuration for determining when to add/remove instances.

Threshold settings for our Auto Scaling Group

Here we have two policies: one for scaling in and one for scaling out. I’ve highlighted the current threshold that needs to be hit in order for either to be triggered.

What this says is “if there is a network issue on an EC2 Instance for more than one five minute period, add an EC2 if we haven’t hit our maximum capacity” and “if there are no network issues for five minutes, remove an EC2 if we haven’t already hit our desired capacity.”

And just like that, our application can grow/reduce based on our configurations of the Auto Scaling Group. Our application can now handle the additional load of going viral!

But, one last question: how does the Auto Scaling Group know about our EC2 network errors? Enter, CloudWatch.

CloudWatch

If you click on the Monitoring tab in your Auto Scaling Group, you’ll see links that will take you to CloudWatch. Once in the CloudWatch Management Console, you’ll see a variety of AWS services and resources listed and their associated metrics.

Browsing through the list you’ll find EC2 and Auto Scaling Group, and monitoring details for each. Where did all of these metrics come from? AWS provides them for your automatically, along with this helpful dashboard, allowing us to do some pretty cool dynamic networking and programming based on individual metrics or a composite, such as Auto Scaling.

The Auto Scaling Group we have has access to these metrics, and watches the NetworkOut metric of our EC2 Instances to determine if a scaling in/out action should occur.

Just another example of the leverage we gain from a cloud computing platform.

ElasticBeanstalk Deployment Recap

We took a look at a second method for deploying an application: Elastic Beanstalk. Compared to our S3 deployment, this route required us to add more code for configuring the serving of our index.html.

We used Express.js, a Node.js web application framework, to serve our front end, and then uploaded our newly updated project to Elastic Beanstalk. This in turn launched a myriad of AWS resources and services for us.

We learned about EC2, Load Balancer, Auto Scaling Group, and CloudWatch, and how they work together to deliver our project by a globally accessible url endpoint.

There are even more settings, services, and resources Elastic Beanstalk configuring and provisioned for us that we did not discuss, but for now you’ve gained a good first step into the benefits of a cloud hosting provider and a few of the key AWS services.

How to Deploy Your freeCodeCamp Project with AWS Lambda

For our final part of this post, we are going to deploy our code to a serverless environment. Serverless infrastructures are becoming increasingly popular and preferred over a dedicated on-premise server or even a hosted server (like EC2).

Not only is the serverless route more cost-effective, it lends itself to a different software architectural approach: microservices.

To gain an introduction into the serverless world, we are going to deploy our code via AWS’s serverless service called Lambda and another AWS service, API Gateway. Let’s get started!

What is Serverless?!

Say, what?! This whole time we’ve been talking about servers delivering our code when the web browser requests it, so what’s serverless mean?

To start off, it doesn’t mean there is no server. There has to be one, since a server is a computer and we need our program running on a computer.

So, serverless doesn’t mean no-server. It means you and I, the code deployers, do not ever see the server and have no configurations to set for that server. The server belongs to AWS, and it just runs our code without us doing anything else.

Serverless means that for you and me in all practicality there is no server, but in reality there is.

Sounds pretty simple, right? It is! We have no server to configure, AWS has the server and handles everything. We just hand over the code.

You might be asking yourself, how is that different from EC2? Good question.

There's Less Configuration

Do you remember all the configuration options that we could mess with on Elastic Beanstalk, and in the EC2 management console, and the Auto Scaling Group, and the Load Balancer?

Some of the Elastic Beanstalk configurations available to us

Then, Elastic Beanstalk created more resources all with their own configurations, like the Load Balancer and Auto Scaling Group.

Well, as nice as it is that we can configure those, it can also be a pain to setup. More importantly, it takes more time to setup, which takes us away from time spent developing our actual application.

With a Lambda (an AWS serverless service), we just say, “hey, we want a Node.js environment to run our code“, and then after that there is no more configurations to make about the server itself. We can get back to writing more code.

It's Cheaper

Also, that EC2 is costing us money for as long as it runs. Now it’s simple to terminate or temporarily stop to save us money, and is usually cheaper than purchasing your own physical server – but it still costs money at all times of the day that it’s running, even if no one is trying to reach your website.

So, what if there was an option that only charged us a fee for the time the code ran? That’s serverless!

With AWS Lambda, we have our code able to be run at any time, it’s sitting on a server. But it only runs our program when asked for and we are only paying for those times it runs. The cost savings are huge.

Microservice Architecture

Because most programs have been written and deployed onto a server to run, all the code for that application has been bundled together so that that server could access and run the entire application. That makes sense!

But, if you have a way to run code with a serverless approach, which only runs that code asked for, you could break up that one application into many applications. That breaking apart an application into smaller sub-applications is the idea of microservices.

One of the main benefits of a microservice approach is the update process. If we have a monolithic application (one that is all bundled together on an EC2), and need to update one small piece of code, then we have to redeploy the entire application, which may mean service interruptions.

Alternatively, a microservice approach means we only update the minor-application of the whole that deals with that small piece of code. This is a less abrupt approach to deployment, and one of the primary benefits of a microservice approach that AWS Lambda allows us to do.

I should note that serverless has its own drawbacks as well. For starters, if you have a microservice architecture via serverless, then the integration of those microservices to talk to each other requires extra work that a monolithic application doesn’t have to deal with.

That being said, it’s an approach that is massively popular and growing in use, so it’s worth your knowing.

Disclaimer: Now, technically Part 1’s use of S3 was a serverless deployment, but typically when people discuss serverless and AWS they’re talking about Lambda.

How to Get Started with AWS Lambda

So, Lambdas allow us to execute code without worrying about server configuration or cost. That’s it. They run on a server owned by AWS, configured by AWS, managed by AWS, and never seen by us.

For the most part, all we control and care about is the function. This is what’s referred to as function as a service in cloud computing. It lets us focus on code without needing to think about the complexities of infrastructure.

So now that we know that Lambdas are just functions running on an AWS server that we don’t have to configure, let’s get started with ours.

How to Create Our Lambda

Head over to the AWS Lambda Management Console. Click on the Create Function button. On the next screen, we are going to keep the Author from scratch selection, enter our function’s name (aka, the name for our Lambda), and then select the Node.js 14.x runtime.

That’s all we need to do for now, go ahead and click the Create Function button in the bottom right.

Our screen when creating our Lambda function

The next screen that loads will be our console for managing a Lambda. If you scroll down a bit you’ll find an embedded code editor and file system. A directory (aka folder) with the name of your Lambda is already there along with an index.js file. Click File and create a new file called index.html.

You should have an index.js and index.html files

Adjust Your Project’s Code

Due to the nature of this deployment, we need to adjust our code a little bit. Instead of using the <link href="styles.css" /> tag and the <script src="main.js"></script> tag in our freeCodeCamp project’s index.html that links our .css and .js code to our HTML code, we are going to add them directly into the HTML file.

If we don’t do this, then when we try to open our app, it will look for those files at a different URL route than we want.

To change the code to work for us in Lambda, do the following:

1. Replace the <link href="styles.css"/> line in your index.html file with <style></style> (this should be right above your <body> opening tag)
2. Open your styles.css file, copy all of the CSS, and paste it between the two <style> tags (like <style> _your pasted code_ ).
3. Do the same thing with our main.js – remove the src="main.js" inside the opening <script> tag.
4. Open your main.js file, copy all of your JS code, and paste it between the two <script> tags at the bottom of our index.html file (ie: <script> _your main.js code_

I was recently building a simple landing page website for a client who wanted to receive emails through their website without sharing their email.

Honestly, I had never tried to implement that functionality myself before. I was always used to having a simple "Contact Us" button with an anchor tag and a mailto in the href attribute like this:

<button>
    <a href="mailto:myemail@example.com">Contact Me</a>
</button>

But this approach has two inconveniences:

1. It forces both parties, the user who wants to send the message and the site owner who receives it, to share their emails with one another. While this is OK for some, it is not ideal for privacy-minded individuals.
2. For the site visitor, clicking the link forces them to open their default mail program on their device, and that can be frustrating. What if they're using a public computer? What if they're not logged in? What if they simply don't want to use their mail program?
   Yes, technically they can just grab the recipient's email address and send the message via their browser or wherever they're logged in. But those are all extra steps and hurdles that can discourage users from sending their messages and the business might lose potential feedback or opportunities.

For this reason, we chose to go with an email form from which the user can simply write in their message and click submit, sending an email to the site's owner without ever leaving the website.

A quick Google search shows that there are third party tools/widgets that you could embed in a website, but most of them are branded and require paid subscription for full customization.

And unless you are using a CMS like WordPress that has a built-in plugin that can do that, that's an inconvenient recurring cost.

I instead chose to code that feature myself so I would have full control.

For the purposes of this guide I will recreate the steps I took to implement that functionality using HTML and AWS services.

The HTML Form

I'll keep it super simple here and go with a basic HTML form with no CSS, just to test our desired functionality.

<h2>Contact Us</h2>
<form>
  <label for="name">Name:</label>
  <input name="name" type="text"/><br/><br/>
  <label for="email">Email:</label>
  <input name="email" type="email"/><br/><br/>
  <label for="name">Message:</label>
  <textarea name="message"></textarea><br/><br/>
  <input type="submit"/>
  <div>
    <p id="result-text"></p>
  </div>
</form>

Nothing fancy to see here...

Now we want to handle the submit functionality with JavaScript.

const form = document.querySelector('form')
form.addEventListener('submit', event => {
  // prevent the form submit from refreshing the page
  event.preventDefault()

  const { name, email, message } = event.target
  console.log('Name: ', name.value)
  console.log('email: ', email.value)
  console.log('Message: ', message.value)

})

At this point, we have a form that gets input from the user and JavaScript code that just displays the results to the console.

We can leave it at that for now and start working on the backend services that will receive the form data and send an email with that data.

The Backend Overview

Let's dive into AWS and what services we are going to use and how.

As mentioned in the title, we will use AWS Lambda and Simple Email Service (SES). SES is a serverless messaging service that allows you to send email messages when invoked. AWS Lambda allows you to write server-side code to execute in response to events.

We will also use API Gateway which enables us to invoke Lambda functions via HTTP.

In this case, when our form is submitted, the following workflow will happen:

1. Our browser (JavaScript) will make a post request, with the form data in the request body, to an endpoint URL specified by AWS API Gateway
2. The API Gateway will validate this request. Then it will trigger the Lambda function which accepts an event parameter. API Gateway will put the form data in the body property of the event parameter.
3. Our Lambda function will extract the data from the event body and we will then use this data to build the body of the email we want to send as well as its recipients. Our function will then use the AWS SDK to invoke SES with the email data.
4. Once SES gets the sendMail request, it turns the email data into an actual text email and sends it to the recipient via AWS's own mail servers.

Once the email is sent, our browser will receive a response with status code 200 and a success message. If any step in the AWS cloud fails, the response will have a 500 status code.

Step 1: How to Set Up SES

We're actually going to set up each one of these steps in the reverse order, beginning with SES, which is going to be easier.

First in your AWS console, go to the SES service —> then click on Email Addresses in the side menu —> then click on the "Verify a New Email Address" button.

In the dialogue that opens up, enter the email address that you want the SES service to put as the sender when it sends the email.

This will send an email to the email address you put with a link to click to verify. This is how AWS knows that the owner of the email consents to having their email address used as the sender address.

Until you verify the email, the SES email dashboard will keep the verification status as pending.

Once the email owner opens the email they received from AWS and clicks the verification link in it, the verification status should change to verified (refresh the page to see the change).

And that's all you have to do for SES. You can optionally test the service by selecting your verified email in the list and clicking the "Send a Test Email" button. This will let you put in a recipient's email address, a subject, and a message and send it.

The email sent is going to be signed by AWS servers and your verified address should be the sender. It should look like this:

Step 2: How to Set Up Lambda

Now this is the most fun part. We are going to create a function that is going to receive the form data and call SES.

The beauty of Lambda functions is that you don't have to worry about running your backend code on a server 24/7 and maintaining that server. It's serverless.

But that doesn't mean there are no servers involved. AWS is going to take care of that under the hood so you can only focus on writing code, not maintaining servers. Additionally, you only get billed for the number of times your function gets called and the amount of time it takes to execute, and it's incredibly cheap!

Create an IAM Role and Configure it

Before we start writing our lambda function, we need to create an IAM role to attach it to the function and grant it permissions (referred to as policies in AWS) to invoke the SES service.

From your AWS console, go to the IAM service —> click on Policies in the side menu —> then click on the "Create Policy" button.

In the policy creation page, go to the JSON tab and paste the following permissions, then click Next.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ses:SendEmail",
                "ses:SendRawEmail"
            ],
            "Resource": "*"
        }
    ]
}

In the third screen, name the policy and click the "Create Policy" button.

Now we create an IAM role which will be attached to the lambda and link it to the permissions policy which we just created.

From the IAM side menu, click Roles then click the "Create role" button.

In the role creation screen, make sure the type selected is "AWS service" and select the Lambda case then click on the "Next:Permissions" button.

On the next screen, search for the policy we created earlier by its name and select it, then click next.

On the review screen, give the role a name you can remember then click on "Create role".

Now we can create a new lambda function. Go to the Lambda service dashboard and click the "Create Function" button.

In the function creation screen, name your function, select the "Author from scratch" option, and choose Node.js as the runtime.

Under "Change default execution role" choose the "Use an existing role" option then choose the name of the role you created in the previous step from the "Existing role" drop down.

Finally, click the "Create function" button to create the function.

Write the Code and Test it

In the editor, open the index.js file (this is the file that will be executed when your lambda is called), and replace its content with the following code:

const aws = require("aws-sdk");
const ses = new aws.SES({ region: "us-east-1" });
exports.handler = async function (event) {
  console.log('EVENT: ', event)
  const params = {
    Destination: {
      ToAddresses: ["your@email.com"],
    },
    Message: {
      Body: {
        Text: { 
            Data: `Hello from Lambda!` 
        },
      },
      Subject: { Data: `Message from AWS Lambda` },
    },
    Source: "your@email.com",
  };

  return ses.sendEmail(params).promise()
};

Notice that on line 2 we are using the AWS SDK and creating an SES instance. The reason I chose us-east-1 as the region is because that's where I registered & verified my email. Be sure to replace the email and use the AWS region where you registered your email.

Now to test this function, click on the "Deploy" button. Then click on the Test button —> Configure test event which should open up a test configuration dialogue where you can create a new test event.

In the test event body editor, enter the following JSON which mimics what will eventually come from our browser request. Then click create.

{
  "body": {
        "senderName": "Namo",
        "senderEmail": "namo@trains.com",
        "message": "I love trains!"
    }
}

Now clicking the test button will run the test we just created. It should open a new tab in the editor to show us the logs created from running the function, which should look like this:

Notice the event object we logged out shows here under Function logs with the body data we used in the test event.

This test should have sent an email to my inbox as well – let's see if that happened.

Yep, just as expected. And that happened almost immediately after running the test.

Now let's modify our function code to get a more meaningful message from the test data.

const aws = require("aws-sdk");
const ses = new aws.SES({ region: "us-east-1" });
exports.handler = async function (event) {
  console.log('EVENT: ', event)
    // Extract the properties from the event body
  const { senderEmail, senderName, message } = JSON.parse(event.body)
  const params = {
    Destination: {
      ToAddresses: ["the.benhawy@gmail.com"],
    },
        // Interpolate the data in the strings to send
    Message: {
      Body: {
        Text: { 
            Data: `You just got a message from ${senderName} - ${senderEmail}:
            ${message}` 
        },
      },
      Subject: { Data: `Message from ${senderName}` },
    },
    Source: "the.benhawy@gmail.com",
  };

  return ses.sendEmail(params).promise();
};

It's important to note that when API Gateway calls our function it will pass a string to the event body. This is why I use JSON.parse on event.body, to turn it into JSON and extract our sender's email, name, and message. Then I use those variables in the email body text and subject using string interpolation.

If you try the test it, the code will return an error. This is because the test is passing a JSON object to event.body and we are using JSON.parse on JSON, which causes an error in JavaScript.

Sadly, the test editor doesn't allow us to pass strings to the event, so we'll have to test that later from somewhere else.

Step 3: How to Set Up API Gateway

Next, the last AWS service we are going to use is API Gateway, which will enable our browser to send HTTP requests to the Lambda function we created.

Without leaving your lambda function page, expand the "Function overview" section and click on "Add trigger".

Next, choose API Gateway from the dropdown, HTTP API as the API type, "Open" as the security mechanism, and check the CORS checkbox option. Then click "Add".

You should be redirected to the "Configuration" tab of your function, showing you the new API Gateway trigger you just created. From there, note the API endpoint. This is the URL we are going to be calling from our browser with the form data.

Back to the HTML

We can finally test the form to see if it sends emails or not.

Let's modify our JavaScript to handle sending the request when the form is submitted.

const form = document.querySelector("form");
form.addEventListener("submit", (event) => {
  // prevent the form submit from refreshing the page
  event.preventDefault();

  const { name, email, message } = event.target;

    // Use your API endpoint URL you copied from the previous step
  const endpoint =
    "<https://5ntvcwwmec.execute-api.us-east-1.amazonaws.com/default/sendContactEmail>";
  // We use JSON.stringify here so the data can be sent as a string via HTTP
    const body = JSON.stringify({
    senderName: name.value,
    senderEmail: email.value,
    message: message.value
  });
  const requestOptions = {
    method: "POST",
    body
  };

  fetch(endpoint, requestOptions)
    .then((response) => {
      if (!response.ok) throw new Error("Error in fetch");
      return response.json();
    })
    .then((response) => {
      document.getElementById("result-text").innerText =
        "Email sent successfully!";
    })
    .catch((error) => {
      document.getElementById("result-text").innerText =
        "An unkown error occured.";
    });
});

Now, the moment of truth: fill in the form and click submit. If you see the success message, that means the email was sent.

Since I own the email the message was sent to, I take a quick look at my inbox to see that I received an email from myself with the details I used in the form!

If you've followed along, you now have a functioning "Contact Us" form that you can plug into any website. And you'll only get billed for when it is actually used.

I don't know about you, but I think this is pretty awesome and almost magical! And it's a nice, practical way to use cloud computing/services in your workflow.

Of course you can customize this flow in terms of using a framework on the frontend like React or Vue or a different programming language for the Lambda like Python or Go.

Before you go...

Thank you for reading this far! I write posts about JavaScript, cloud development, and my personal educational & professional experiences as a self-taught developer. So feel free to follow me on twitter @adham_benhawy where I tweet about them too!

Resources

• https://aws.amazon.com/premiumsupport/knowledge-center/lambda-send-email-ses/
• https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html
• https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html?icmpid=docs_lambda_console

Recently, I really wanted to find a way to build an API that would take in a URL and save a screenshot.

My initial use case was simple: if I was analyzing phishing emails, I wanted an easy way to get a screenshot of the URL that the email was trying to direct their targets to.

To build this, I used Terraform to create all of the infrastructure necessary to set it up in AWS, using Selenium, chromedriver, and headless Chrome to obtain the screenshots.

High level diagram illustrating what will be built in AWS by Terraform

Note: All code samples are from PowerShell, so please excuse the ".\" notation.

Requirements

• An AWS account
• Terraform binary
• Existing S3 bucket to store Terraform state (https://www.terraform.io/docs/backends/types/s3.html)
• AWS IAM user and access key created with appropriate permissions (programmatic access, administrative group) for Terraform usage

How to Set Up the Project

Create your new directory and initialize Terraform like this:

mkdir .\screenshot-service
cd .\screenshot-service
.\terraform init

Configure the AWS Provider

Create a file called provider.tf in the root of your project directory. Then configure with appropriate values for the AWS access key and secret key, as well as the name of an existing S3 bucket that will be used to store the Terraform state file.

provider "aws" {
  region = "us-east-1"

  access_key = "ACCESSKEY"
  secret_key = "SECRETKEY"
}

terraform {
  backend "s3" {
    bucket = "EXISTING_BUCKET"
    region = "us-east-1"
    key = "KEYFORSTATE"
    access_key = "ACCESSKEY"
    secret_key = "SECRETKEY"
    encrypt = "true"
  }
}

Configure the S3 Bucket

We will be using an S3 bucket to store all of our screenshots. To configure the S3 service, create a new file in the root of your project called s3.tf and add the following:

resource "aws_s3_bucket" "screenshot_bucket" {
  bucket        = "STORAGE_BUCKET_NAME"
  force_destroy = true
  acl = "public-read"

  versioning {
    enabled = false
  }
}

Create the Lambda Layer

Let's start by creating the lambda layer which will contain the necessary binaries. First, from the root of the project, create a folder called chromedriver_layer: mkdir .\chromedriver_layer.

Next, download the chromedriver and chromium binaries:

cd .\chromedriver_layer
wget https://chromedriver.storage.googleapis.com/2.41/chromedriver_linux64.zip -OutFile .\chromedriver.zip
wget https://github.com/adieuadieu/serverless-chrome/releases/download/v1.0.0-54/stable-headless-chromium-amazonlinux-2017-03.zip -OutFile .\headless-chromium.zip
Expand-Archive .\headless-chromium.zip
rm *.zip

Last, we need to zip this up nicely for Terraform:

cd ..\
Compress-Archive .\chromedriver_layer -DestinationPath \chromedriver_layer.zip

How to Configure Lambda

Lambda Infrastructure

Create a file called lambda.tf in the root of your project directory. First, we will create the execution role required for our function:

resource "aws_iam_role" "lambda_exec_role" {
  name        = "lambda_exec_role"
  description = "Execution role for Lambda functions"

  assume_role_policy = <<EOF
{
        "Version"  : "2012-10-17",
        "Statement": [
            {
                "Action"   : "sts:AssumeRole",
                "Principal": {  
                    "Service": "lambda.amazonaws.com"
                },
                "Effect": "Allow",
                "Sid"   : ""
            }
        ]
}
EOF
}

Next, we will add a few policies to the execution role we have created that will enable our function to access required services:

resource "aws_iam_role_policy" "lambda_logging" {
  name = "lambda_logging"

  role = aws_iam_role.lambda_exec_role.id

  policy = <<EOF
{
    "Version"  : "2012-10-17",
    "Statement": [
        {
            "Effect"  : "Allow",
            "Resource": "*",
            "Action"  : [
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "logs:CreateLogGroup"
            ]
        }
    ]
}
EOF
}

resource "aws_iam_role_policy" "lambda_s3_access" {
  name = "lambda_s3_access"

  role = aws_iam_role.lambda_exec_role.id

  # TODO: Change resource to be more restrictive
  policy = <<EOF
{
  "Version"  : "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBuckets",
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:GetObjectAcl"
      ],
      "Resource": ["*"]
    }
  ]
}
EOF
}

There, now our function will be able to access S3 and log to CloudWatch. Let's define our function:

resource "aws_lambda_function" "take_screenshot" {
  filename      = "./screenshot-service.zip"
  function_name = "take_screenshot"
  role          = aws_iam_role.lambda_exec_role.arn
  handler       = "screenshot-service.handler"
  runtime       = "python3.7"

  source_code_hash = filebase64sha256("./screenshot-service.zip")
  timeout          = 600
  memory_size      = 512 
  layers = ["${aws_lambda_layer_version.chromedriver_layer.arn}"]

  environment {
    variables = {
      s3_bucket = "${aws_s3_bucket.screenshot_bucket.bucket}"
    }
  }
}

The above code specifies that we are uploading a lambda function package using a Python 3.7 runtime, and that the function that will be called is named "handler".

I have set the timeout to 600 seconds, but feel free to change that as you will. Also, feel free to play with the memory_size – for me, this has led to super quick screenshots.

We also set an environment variable called s3_bucket which will be passed to the function, containing the name of the bucket used to store the screenshot.

The Lambda function itself

Create a folder called lambda in the root of the project directory and create a file called screenshot-service.py in that folder.

Add the following imports and logging configuration to the file:

#!/usr/bin/env python
# -*- coding utf-8 -*-

import json
import logging
from urllib.parse import urlparse, unquote # TODO: Can I use urllib3?
from selenium import webdriver
from datetime import datetime
import os
from shutil import copyfile
import boto3
import stat
import urllib.request
import tldextract

# Configure logging
logger = logging.getLogger()
logger.setLevel(logging.DEBUG)

Next, we will create a function that will copy the binaries from our lambda layer and make them executable:

def configure_binaries():
    """Copy the binary files from the lambda layer to /tmp and make them executable"""
    copyfile("/opt/chromedriver", "/tmp/chromedriver")
    copyfile("/opt/headless-chromium", "/tmp/headless-chromium")

    os.chmod("/tmp/chromedriver", 755)
    os.chmod("/tmp/headless-chromium", 755)

Next, we will create the function that will take the screenshot of the provided domain. We will be passing in the URL and the S3 bucket name.

We will add an optional parameter allowing for the title of the image to be set by the user. The screenshot is taken by Selenium automating the headless Chrome browser we downloaded.

def get_screenshot(url, s3_bucket, screenshot_title = None):     
    configure_binaries()

    chrome_options = webdriver.ChromeOptions()
    chrome_options.add_argument('--headless')
    chrome_options.add_argument("disable-infobars")
    chrome_options.add_argument("enable-automation")

    chrome_options.add_argument('--no-sandbox')
    chrome_options.add_argument('--disable-gpu')
    chrome_options.add_argument('--window-size=1280x1696')
    chrome_options.add_argument('--user-data-dir=/tmp/user-data')
    chrome_options.add_argument('--hide-scrollbars')
    chrome_options.add_argument('--enable-logging')
    chrome_options.add_argument('--log-level=0')
    chrome_options.add_argument('--disable-dev-shm-usage')
    chrome_options.add_argument('--v=99')
    chrome_options.add_argument('--single-process')
    chrome_options.add_argument('--data-path=/tmp/data-path')
    chrome_options.add_argument('--ignore-certificate-errors')
    chrome_options.add_argument('--homedir=/tmp')
    chrome_options.add_argument('--disk-cache-dir=/tmp/cache-dir')
    chrome_options.add_argument(
        'user-agent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36')
    chrome_options.binary_location = "/tmp/headless-chromium"

    if screenshot_title is None: 
        ext = tldextract.extract(url)
        domain = f"{''.join(ext[:2])}:{urlparse(url).port}.{ext[2]}"
        screenshot_title = f"{domain}_{datetime.utcnow().strftime('%Y%m%d_%H%M%S')}"
    logger.debug(f"Screenshot title: {screenshot_title}")

    with webdriver.Chrome(chrome_options=chrome_options, executable_path="/tmp/chromedriver", service_log_path="/tmp/selenium.log") as driver: 
        driver.set_window_size(1024, 768)

        logger.info(f"Obtaining screenshot for {url}")
        driver.get(url)     

        driver.save_screenshot(f"/tmp/{screenshot_title}.png") # TODO: Delete the screenshot after
        logger.info(f"Uploading /tmp/{screenshot_title}.png to S3 bucket {s3_bucket}/{screenshot_title}.png")
        s3 = boto3.client("s3")
        s3.upload_file(f"/tmp/{screenshot_title}.png", s3_bucket, f"{screenshot_title}.png", ExtraArgs={'ContentType': 'image/png', 'ACL': 'public-read'})
    return f"https://{s3_bucket}.s3.amazonaws.com/{screenshot_title}.png"

Last, let's create our handler, which will be invoked when the API Gateway receives a legitimate request:

def handler(event, context): 
    logger.debug("## ENVIRONMENT VARIABLES ##")
    logger.debug(os.environ)
    logger.debug("## EVENT ##")
    logger.debug(event)

    bucket_name = os.environ["s3_bucket"]
    logger.debug(f"bucket_name: {bucket_name}")

    logger.info("Validating url")  

    if event["httpMethod"] == "GET":
        if event["queryStringParameters"]:
            try:
                url = event["queryStringParameters"]["url"]
            except Exception as e:
                logger.error(e)
                raise e
        else:
            return {
                "statusCode": 400,
                "body": json.dumps("No URL provided...")
            }
    elif event["httpMethod"] == "POST":
        if event["body"]:
            try:
                body = json.loads(event["body"])
                url = body["url"]
            except Exception as e:
                logger.error(e)
                raise e
        else:
            return {
                "statusCode": 400,
                "body": json.dumps("No URL provided...")
            }
    else:
        return {
            "statusCode": 405,
            "body": json.dumps(f"Invalid HTTP Method {event['httpMethod']} supplied")
        }

    logger.info(f"Decoding {url}")
    url = unquote(url)

    logger.info(f"Parsing {url}")
    try: 
        parsed_url = urlparse(url)
        if parsed_url.scheme != "http" and parsed_url.scheme != "https":
            logger.info("No valid scheme found, defaulting to http://")
            parsed_url = urlparse(f"http://{url}")
        if parsed_url.port is None:
            if parsed_url.scheme == "http":
                parsed_url = urlparse(f"{parsed_url.geturl()}:80")
            elif parsed_url.scheme == "https":
                parsed_url = urlparse(f"{parsed_url.geturl()}:443")

    except Exception as e: 
        logger.error(e)
        raise e

    logger.info("Getting screenshot")
    try: 
        screenshot_url = get_screenshot(parsed_url.geturl(), bucket_name) # TODO: Variable!
    except Exception as e:  
        logger.error(e)
        raise e

    response_body = {
        "message": f"Successfully captured screenshot of {parsed_url.geturl()}",
        "screenshot_url": screenshot_url
    }

    return {
        "statusCode": 200,
        "body"      : json.dumps(response_body)
    }

Next, we need to install all packages that the lambda function uses into the lambda directory since these packages are not installed by default in AWS.

Then we need to create the zip archive (once created, Terraform will continue to update it if you make changes to your code):

cd .\lambda
pip install selenium tldextract -t .\
cd ..\
Compress-Archive .\lambda -DestinationPath .\screenshot-service.zip

How to Configure API Gateway

Create a file called apigw.tf in the root of your project directory. First, we will configure the REST API:

resource "aws_api_gateway_rest_api" "screenshot_api" {
  name        = "screenshot_api"
  description = "Lambda-powered screenshot API"
  depends_on = [
    aws_lambda_function.take_screenshot
  ]
}

This API will be used to direct all requests that are made for the screenshot service. We use the depends_on feature to ensure that the gateway and its related components are only created after the lambda function is created.

Next, let's create the API Gateway resource for the lambda function:

resource "aws_api_gateway_resource" "screenshot_api_gateway" {
  path_part   = "screenshot"
  parent_id   = aws_api_gateway_rest_api.screenshot_api.root_resource_id
  rest_api_id = aws_api_gateway_rest_api.screenshot_api.id
}

We have now defined a resource that will respond at the /screenshot endpoint for the API service.

Next up we will create a stage for the API. A stage is a fancy way of naming our deployment of the API. You can configure caching, logging, request throttling, and more using a stage.

resource "aws_api_gateway_stage" "prod_stage" {
  stage_name = "prod"
  rest_api_id = aws_api_gateway_rest_api.screenshot_api.id
  deployment_id = aws_api_gateway_deployment.api_gateway_deployment_get.id
}

Next we will create an API key and usage plan tied to our stage, so that only users with knowledge of the key can use this service. (Note: If you want this publicly accessible, skip this step.)

resource "aws_api_gateway_usage_plan" "apigw_usage_plan" {
  name = "apigw_usage_plan"

  api_stages {
    api_id = aws_api_gateway_rest_api.screenshot_api.id
    stage = aws_api_gateway_stage.prod_stage.stage_name
  }
}

resource "aws_api_gateway_usage_plan_key" "apigw_usage_plan_key" {
  key_id = aws_api_gateway_api_key.apigw_prod_key.id
  key_type = "API_KEY"
  usage_plan_id = aws_api_gateway_usage_plan.apigw_usage_plan.id
}

resource "aws_api_gateway_api_key" "apigw_prod_key" {
  name = "prod_key"
}

Let's now configure the API to respond to either a GET or POST request if a valid API Gateway Key is provided (set the value to false if you want the method open to the public):

resource "aws_api_gateway_method" "take_screenshot_get" {
  rest_api_id   = aws_api_gateway_rest_api.screenshot_api.id
  resource_id   = aws_api_gateway_resource.screenshot_api_gateway.id
  http_method   = "GET"
  authorization = "NONE"
  api_key_required = true
}

resource "aws_api_gateway_method" "take_screenshot_post" {
  rest_api_id   = aws_api_gateway_rest_api.screenshot_api.id
  resource_id   = aws_api_gateway_resource.screenshot_api_gateway.id
  http_method   = "POST"
  authorization = "NONE"
  api_key_required = true
}

We now need to give the API Gateway permission to invoke the lambda function we created:

resource "aws_lambda_permission" "apigw" {
  statement_id  = "AllowAPIGatewayInvoke"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.take_screenshot.arn
  principal     = "apigateway.amazonaws.com"

  source_arn = "${aws_api_gateway_rest_api.screenshot_api.execution_arn}/*/*/*"
}

Great, we now have the appropriate permissions. Let's set up our integration with the lambda function:

resource "aws_api_gateway_integration" "lambda_integration_get" {
  depends_on = [
    aws_lambda_permission.apigw
  ]
  rest_api_id = aws_api_gateway_rest_api.screenshot_api.id
  resource_id = aws_api_gateway_method.take_screenshot_get.resource_id
  http_method = aws_api_gateway_method.take_screenshot_get.http_method

  integration_http_method = "POST" # https://github.com/hashicorp/terraform/issues/9271 Lambda requires POST as the integration type
  type                    = "AWS_PROXY"
  uri                     = aws_lambda_function.take_screenshot.invoke_arn
}

resource "aws_api_gateway_integration" "lambda_integration_post" {
  depends_on = [
    aws_lambda_permission.apigw
  ]
  rest_api_id = aws_api_gateway_rest_api.screenshot_api.id
  resource_id = aws_api_gateway_method.take_screenshot_post.resource_id
  http_method = aws_api_gateway_method.take_screenshot_post.http_method

  integration_http_method = "POST" # https://github.com/hashicorp/terraform/issues/9271 Lambda requires POST as the integration type
  type                    = "AWS_PROXY"
  uri                     = aws_lambda_function.take_screenshot.invoke_arn
}

This integration tells the API Gateway what lambda function to invoke when it receives a request at the specified endpoint and HTTP method.

Almost done with the gateway, I promise. As a last step, let's make sure that our API can send logs to CloudWatch:

resource "aws_api_gateway_account" "apigw_account" {
  cloudwatch_role_arn = aws_iam_role.apigw_cloudwatch.arn
}

resource "aws_iam_role" "apigw_cloudwatch" {
  # https://gist.github.com/edonosotti/6e826a70c2712d024b730f61d8b8edfc
  name = "api_gateway_cloudwatch_global"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "apigateway.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF
}

resource "aws_iam_role_policy" "apigw_cloudwatch" {
  name = "default"
  role = aws_iam_role.apigw_cloudwatch.id

  policy = <<EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:DescribeLogGroups",
                "logs:DescribeLogStreams",
                "logs:PutLogEvents",
                "logs:GetLogEvents",
                "logs:FilterLogEvents"
            ],
            "Resource": "*"
        }
    ]
}
EOF
}

We have now given API Gateway the requisite permissions in order to write logs to CloudWatch.

Last but not least, we deploy our API. We use depends_on to ensure that the deployment occurs after all dependencies are created.

resource "aws_api_gateway_deployment" "api_gateway_deployment_get" {
  depends_on = [aws_api_gateway_integration.lambda_integration_get,  aws_api_gateway_method.take_screenshot_get, aws_api_gateway_integration.lambda_integration_post, aws_api_gateway_method.take_screenshot_post]

  rest_api_id = aws_api_gateway_rest_api.screenshot_api.id
}

Lambda packaging

In main.tf, add the following:

data "archive_file" "screenshot_service_zip" {
  type        = "zip"
  source_dir  = "./lambda"
  output_path = "./screenshot-service.zip"
}

data "archive_file" "screenshot_service_layer_zip" {
  type = "zip"
  source_dir = "./chromedriver_layer"
  output_path = "./chromedriver_lambda_layer.zip"
}

Outputs

Create a file called output.tf in the root of your project directory and add the following:

output "api_gateway_url" {
  value = "${aws_api_gateway_stage.prod_stage.invoke_url}/${aws_api_gateway_resource.screenshot_api_gateway.path_part}"
}

output "api_key" {
  value = aws_api_gateway_api_key.apigw_prod_key.value
}

Now once you run .\terraform apply you will get output with the URL of the API and the associated API key.

Congrats! You now have a working screenshot service. To view the code I've used, feel free to check out my Github repository.

In this article, you'll learn how to inject custom packages on AWS Lambda Functions' Runtime by using AWS Lambda Layers. You'll also use Amplify to develop, deploy, and distribute your applications.

Serverless applications are great for those who don't want to pay for idle machines or even manage cloud infrastructures. This post will focus on a gentle introduction to the Amplify Framework using Node.js. You'll install a custom Node.js package once and inject it on all your functions using AWS Lambda Layers.

By the end of this post you will have learned how to deploy serverless functions on AWS by:

• Creating a Node.js Web API using Express.js as a serverless function using the Amplify Framework
• Injecting a custom package on AWS Lambda functions' runtime using AWS Lambda Layers to monitor and extend HTTP requests.

Requirements

In the next steps, you'll create a real application and publish it on the AWS Infrastructure. Before starting to code make sure you have the following requirements set up on your environment:

• An AWS Active Account
• AWS CLI
• Node.js v14

Introduction

One of my favorites cloud platforms that provides serverless infrastructure is Amazon Web Services. They have long been developing and shipping platforms that empower companies to release software faster than if they had to configure and handle repetitive configurations.

If you're familiar with Serverless applications, you might have heard about the Serverless Framework. It's a multi-cloud framework for managing serverless architectures by using configuration files, deploying and running apps using a single command.

Even so, developers still need install plugins and manage configuration files by themselves and it could take a while to build a complex workflow.

So, what kind of CLI do you like most? A CLI that would ask you about what you want such as external connections (Database, Storage, Queue, etc), authentication flow, external permissions, and so on? Yeah my friend, welcome to AWS Amplify.

AWS Amplify

Amplify Framework website

AWS Amplify is an ecosystem that helps back end, front end, and integration developers. If you take a look at its official docs, you'll see the huge list of possible libraries and examples to work on both back end and front and applications.

When you have your AWS CLI configured and your environment set, run the following command to install AWS Amplify globally on your machine:

npm install -g amplify-cli

Next, let's initialize a work directory by creating a folder:

mkdir app && cd app

Now, you'll initialize an amplify project by running the command below. To do so, you'll need to check a few options on the CLI wizard. Notice that when prompted you can press Enter on your keyboard to choose default values.

amplify init

Choose the options according to the bold text below:

• Enter a name for the project app
• Enter a name for the environment dev
• Choose your default editor: Visual Studio Code
• Choose the type of app that you're building javascript

Please tell us about your project

• What javascript framework are you using none
• Source Directory Path: src
• Distribution Directory Path: dist
• Build Command: npm run-script build
• Start Command: npm run-script start

Initialising the shared project

Through the next steps, you'll create a function. This function will be used to store dependencies which will be injected later into functions around the AWS Lambda Functions ecosystem.

Running the command below will guide you towards steps to create your Lambda Layer:

amplify function add

Choose the options according to the bold text options below. Notice that for the compatible runtimes, you'll need to hit the space key on your keyboard to select the runtime.

• Select which capability you want to add: Lambda layer (shared code & resource used across functions)
• Provide a name for your Lambda layer: apmAgentLayer
• Select up to 2 compatible runtimes: NodeJS
• The current AWS account will always have access to this layer.
• Optionally, configure who else can access this layer. (Hit to skip) Public

✅ Lambda layer folders and files created: amplify/backend/function/apmAgentLayer

Installing custom modules

Going to the Layer's path amplify/backend/function/apmAgentLayer you may have seen a few folders created by Amplify. As we're working on a Node.js project, all node modules must be installed on lib/nodejs.

I built an example of an Application Performance Monitor to show how to use the Node.js performance hooks feature to measure duration between requests and change HTTP response readers. It will help show you other possibilities to implement shared code and extend Node.js behaviour.

NPM package to measure duration between requests

The first step here is to install the shared dependencies and upload them to the AWS. Go to the path generated by the CLI amplify/backend/function/apmAgentLayer/lib/nodejs and then install the package using the following commands:

cd amplify/backend/function/apmAgentLayer/lib/nodejs
npm i @erickwendel/ew-agent

Deploying

Once you've installed your package you can just deploy it and inspect it later via the AWS Console. Notice that we haven't added any code yet. The goal at this point is just to prepare this library for further use.

Run the following command to upload your Lambda Layer:

amplify push

running amplify push command and seeing output

Creating the Web API function

At this point, you already have a local Amplify infrastructure project ready to add API Routes, Routines, link with AWS services, and so on.

The command below will be useful for generating an ExpressJS-based project and an AWS Lambda function. It'll also link the function on your nearly created AWS Lambda Layer and expose it on the AWS API Gateway.

amplify api add

Choose the options according to the bold text below:

• Please select from one of the below mentioned services: REST
• Provide a friendly name for your resource to be used as a label for this category in the project: myApi
• Provide a path (e.g., /book/{isbn}): /hi
• Choose a Lambda source Create a new Lambda function
• Provide a friendly name for your resource to be used as a label for this category in the project: myApi
• Provide the AWS Lambda function name: myApi
• Choose the runtime that you want to use: NodeJS
• Choose the function template that you want to use: Serverless ExpressJS function (Integration with API Gateway)
• Do you want to access other resources in this project from your Lambda function? No
• Do you want to invoke this function on a recurring schedule? No
• Do you want to configure Lambda layers for this function? Yes
• Provide existing layers or select layers in this project to access from this function (pick
  up to 5): apmAgentLayer
• Select a version for apmAgentLayer: 1
• Do you want to edit the local lambda function now? Yes

As I'm using VSCode, the last wizard's answer will open the app.js file on my editor so I can edit. Now without adding other dependencies, let's import the Lambda Layer shared module on the first line of this file using the code below:

require('@erickwendel/ew-agent').start()

code added on the file's head

After editing the file, go to the terminal and hit Enter and choose the answers showed in bold below:

• Restrict API access No
• Do you want to add another path? No

At the time of writing, we can't test Lambda Layers locally using AWS Amplify. But you're going deploy your project to AWS and test it in production by running the amplify push command again.

Notice that it will print out which resources need to be updated and which resources will be created on this deploy. It'd take a while to perform all operations and your output should look like the below:

deploying API

As your terminal may have shown, your API has now a URL. My generated URL is https://nlq7x7onj0.execute-api.us-east-1.amazonaws.com/dev and the route will be hi, which we created together in the previous steps.

Let's trigger a request using the cURL (or even your browser) to see check what happens:

curl -i https://nlq7x7onj0.execute-api.us-east-1.amazonaws.com/dev/hi

After running it, the API should respond with a JSON response with the following content {"success":"get call succeed!","url":"/hi"}. The Lambda Layer was injected and it should have changed your response headers adding the x-instrumented-by and x-request-id keys like this:

x-instrumented-by: ErickWendel
x-request-id: 5ddf1343-e42e-4e33-b1e1-936c303c14c8

If you're curious about what Amplify has managed for you during this tutorial, run amplify console and browse on the dashboard. You can see mine below:

dashboard and seeing function logs on AWS

Cleaning up

To remove all resources created by Amplify, run amplify delete.

Conclusion

There are a lot of ways to improve your experience on serverless applications. The Amplify Framework can help you build next-generation apps and avoid repetitive tasks.

Check the official docs to see other possibilities to build powerful APIs using cutting-edge technologies such as GraphQL and AWS AppSync. I'm sure it'll help you a lot!

Thank you for reading

I really appreciate the time we spent together. I hope this content will be more than just text. I hope it will have made you a better thinker and also a better programmer. Follow me on Twitter and check out my personal blog where I share all my valuable content.

See ya! ?

Cron jobs are usually used to schedule commands at a specific time. You can use them for tasks like running backups, monitoring the status of the system, or running system maintenance tasks.

Cron jobs are a helpful utility for system administrators. And when you are administering a system in the cloud, cron jobs are still very useful – you still have to do a lot of administrative tasks on your systems.

One way of running cron jobs in the cloud is to use a function as a service (FaaS), like Lambda in the AWS ecosystem.

Functions execute when they are triggered to do so, and they run code in the cloud without the need to provision or maintain any infrastructure. Also functions can be configured to run at a certain time or with certain periodicity, like traditional cron jobs.

In this blog post, I will use the AWS ecosystem to show you a concrete example on how to create a cron job using a function in the cloud.

Amazon CloudWatch events

In order to use a Lambda function as a cron job, we need to understand Amazon CloudWatch events.

Amazon CloudWatch events are sent when there are changes in the AWS resources. These events can trigger an AWS Lambda function. When your AWS resources change state, they automatically send CloudWatch events to the event stream.

Therefore, you can create a rule that triggers a specific Lambda function when something happens. For example, you can automatically invoke a Lambda function when there is a change in an AutoScaling group.

In addition, CloudWatch events can invoke a Lambda function to execute on a regular schedule. And in this way you can have, for example, a Lambda function that turns off all your testing and development EC2 instances after 6pm and another one that turns them on after 8am.

When there is a change in an autoscaling group the cloud watch event generated triggers a Lambda function

Setting up the demo

I want to show you an example of a Lambda function that can perform actions on your EC2 instances. I will be using AWS SAM to define my Lambda function as infrastructure as code.

If you want to try this demo out, you need to have an AWS account and one or more EC2 instances configured in your AWS account. These are the ones that we are going to manipulate from the Lambda functions. EC2 instances are the AWS version of virtual machines in the cloud.

You can try the demo on AWS Cloud9 IDE (a browser based IDE), as AWS SAM is already configured in that IDE. If you want to know how to use AWS Cloud9 IDE to operate Lambda functions you can check out this video.

In this example, we are going to start and stop EC2 instances using two different AWS Lambdas that get triggered at a given time. We are starting the instances at 8am everyday and turning them off at 6pm when the day is over.

For that we are going to use a CloudWatch event to trigger the Lambda at the right time and also the AWS SDK to perform the operations in the instances.

At an specific time a Lambda function is triggered that will operate on a set of EC2 instances

The finalised code for this example is available in this GitHub repository. To get this code working in AWS Cloud9 IDE, you need to configure your GitHub account in the IDE to be able to clone the project and then clone it inside the IDE.

When you have that ready, just run this command inside the cloned directory:

$ sam deploy --guided

When running that command you will get a set of questions that you need to answer in order to configure this project to run successfully.

How to deploy the project to the cloud using AWS SAM CLI

The first thing you need to define is a name for your project. Then you'll set the region where it is getting deployed - pick the same where your EC2 instances are. Next we need to give the deploy script a list of the instances that we want to manipulate. And then we are done – it will deploy the project to our AWS account.

Defining the AWS Lambda function

The first thing I want to show you is how we define a AWS Lambda function that gets triggered in a specific time using AWS SAM. This definition will be in the file called "template.yml".

AWS SAM of the StartInstance function

This is how a function looks. Let's look at the important lines:

The first line is the name of the function, in this case “StartInstanceFunction”.

Then we have the “Properties” definition. The first property is the “Handler”. Here we will specify the module (file) where the code that needs to execute is and then the method inside that module.

And then we have the “CodeUri”, which is the path that shows you where to find that file. In this case, our code will be inside a directory called “cron” in a file called “handler.js” and in a method called “startInstance”.

After that we have the “Runtime” definition. I will be using NodeJS version 12, but you can use Python, Java, Go, C#, or whatever makes you happy. Lambda supports multiple runtimes out of the box and you can bring your own runtime if you want to.

Then we have the “Environment” definition that we will use to define the one environmental variable. This variable will allow us to send to the code dynamically different instances ids, depending on the configuration when we deploy.

After that we have a section called “Policies” which is where we define the permissions that this particular Lambda function will have.

It is important to know that all Lambda functions are created without any permissions. That means that they cannot do anything on any other AWS resources.

In order for this Lambda function to start an EC2 instance, it needs permissions to do that particular action on that particular AWS resource. In this particular policy we are granting permissions to start ALL EC2 instances in this AWS account. ALL is represented with the “*” in the resources section.

If you have this piece of code running in production, I recommend that you limit the resources to exactly the ones that you want this Lambda to be able to start.

And finally, the last section is the “Events” section. Here we will define how this Lambda function will get triggered. This function will get triggered with a scheduled CloudWatch event that triggers the Lambda everyday at 8 in the morning. Basically at 8 every day it will turn on all the EC2 instances that you specify.

There are many rules to form this cron expression: for example, to say that you would like this to run only Monday through Friday, write cron(0 8 ? MON-FRI ). You can find more info in the documentation site of CloudWatch events here: https://docs.aws.amazon.com/lambda/latest/dg/services-cloudwatchevents-expressions.html.

Coding the AWS Lambda function

Now that we have defined the Lambda function we need to provide some code to it. In the folder “cron”, in the file “handler.js”, we need to add the method called “startInstance” that looks like this:

Code of the startInstance function

This method will get called when the function is triggered every day at 8 am. It will get the list of EC2 instances from an environmental variable that we passed all the instances ids during deployment time. Then it will create an array of them.

When it has that, it will call the AWS SDK and send the array of instances id as a parameter. And if there is any error it will log it and complete. Immediately after this Lambda finishes execution, you can go to your EC2 console and see how your instances turn on.

EC2 instances starting automatically when the Lambda function executes

The function to turn off the EC2 instances is very similar with a few differences. You can find the code for that function in this link and check it out.

Running the cron job

To run this cron job, there is not much left to do. After the two functions are deployed in your AWS account, in the same region as your instances, they will execute and do what they were programmed to do.

AWS Lambda functions for starting and stopping instances deployed in my AWS account

Now you need to wait until 8am or 6pm to see if they work. Or if you want to test it out right now, change the event time in the Lambda definition to a time that works for you. Make sure that the instance is on if you are planning to turn them off or the other way around, so you can see the changes.

Now wait and see what happens in the EC2 console. Right after the time you set up, you will see the instance go off or on and then do the opposite at the other time you setup. This will go forever until you remove the Lambda functions.

Cleaning up your AWS account

After completing this demo I recommend you that you turn off (or remove the instance you created to test) and remove the Lambda functions you just created.

Removing the lambda functions is as easy as going into your CloudFormation service in your AWS management console and removing the stack of resources that AWS SAM created.

Also don’t forget to terminate and remove the EC2 instances if you created them for this demo.

How to remove the AWS Lambda functions we created in this demo

To conclude

AWS Lambda functions are a very useful tool to perform all kinds of tasks in your AWS account. You can basically get notifications of any changes in the AWS resources through CloudWatch events and then you can access almost all the services using the AWS SDK. So you can perform all kinds of maintenance tasks and automated tasks over your infrastructure.

Thanks for reading.

I’m Marcia Villalba, Developer Advocate for AWS and the host of a youtube channel called FooBar where I have over 250 video tutorials on Serverless, AWS and software engineer practices.

• Twitter: https://twitter.com/mavi888uy
• Youtube: https://youtube.com/foobar_codes