Why Serverless ?

By adopting a serverless architecture, we can enjoy several advantages. Firstly, we don’t need to manage any server infrastructure as AWS Lambda automatically handles the scaling, capacity provisioning, and fault tolerance. Secondly, we only pay for the compute resources used during the execution of the Lambda functions, allowing for cost optimization. Lastly, the decoupled nature of serverless components provides flexibility and enables independent development and scaling.

The Problem :

For example, we have data of 10 accounts in DynamoDB => 4 are active and 6 are inactive. We need the Ids of inactive account to make them active and allocate them to their further use cases. When multiple users trigger lambdas to fetch data directly from DynamoDB to get their temporary account Ids, two lambdas may receive the same ID from the DynamoDB, when these two item fall under the same category of being Inactive.

Solution:

This is solved by a simple method, i.e. by using Amazon SQS service.
Amazon SQS is a reliable, highly-scalable hosted queue for storing messages as they travel between applications or microservices. Amazon SQS moves data between distributed application components and helps you decouple these components.

Setup :

Dynamo DB :

For simplicity in this example, we are designing a simple DynamoDB Structure with only 2 Attributes:

1. AccountID (String) => Partition Key
2. Status (String)

Example Table:

SQS :

Go to the SQS service and click on the create queue option.
Select Standard Queue as the type of queue, keep everything else as default and proceed to creating the queue.

After creation of the queue, go into “myTestQueue”.

In the details block, take note of the sqs url which will used later in our serverless functions.
We can later check the contents of our queue by clicking on the “send and receive messages” button.

We will be creating 3 lambda functions:

1) dumpIntoSQS
2) receiveID
3) pushIntoSQS_uponChange

We will be using the AWS SDK for Python : Boto3

1) dumpIntoSQS

This function will dump the ids of all the inactive accounts present in our dynamodb table. This sets up the automation in motion.

1. use environment variables for “SQS URL” and “DYNAMO DB NAME”. This can be set up in lambda funciton -> configuration -> environment variables (use environment variables in all the lambda functions for sensitive information like url, arn values etc)
2. “Status” is a reserved key word for dynamodb, thus we are using FilterExpression and ExpressionAttributeNames to make :s_val as a placeholder for the status attribute
3. For the Lambda to execute we need to give appropriate permissions to our lambda role. Go to Functions > dumpIntoSQS > Configuration > Permissions > Execution Role which will redirect you to IAM policies of our lambda role.

• Click on Add Permissions > Attach Policy. Attach the following policies to our role.
  • AmazonDynamoDBFullAccess
  • AmazonSQSFullAccess

2) receiveID

This function performs three tasks:

• Receive an account id of an inactive account from the queue.
• to change the status of accounts from inactive to active in the table once the accounts are assigned from the queue.
• Delete the assigned id from queue

For the Lambda to execute we need to give appropriate permissions to our lambda role. Go to Functions > dumpIntoSQS > Configuration > Permissions > Execution Role which will redirect you to IAM policies of our lambda role.

• Click on Add Permissions > Attach Policy. Attach the following policies to our role.
  • AmazonDynamoDBFullAccess
  • AmazonSQSFullAccess

3) pushIntoSQS_uponChange

This lambda will send a message to SQS, i.e. pushes into the queue, containing the ID of the account that has been changed from Active to Inactive after completion of its usage.

For the Lambda to execute we need to give appropriate permissions to our lambda role. Go to Functions > dumpIntoSQS > Configuration > Permissions > Execution Role which will redirect you to IAM policies of our lambda role.

• Click on Add Permissions > Attach Policy. Attach the following policies to our role.
  • AWSLambdaSQSQueueExecutionRole
  • AmazonSQSFullAccess

To trigger the lambda we need to setup a DynamoDB Stream.

To Set up the DynamoDB Stream go to the Table -> Exports and Streams

Once the DynamoDB Stream is turned on. We need to add trigger, so that this stream can trigger the execution of a lambda function

Now we have created the DB Stream and have set it as the trigger for our lambda.

After setting up the lambda, test it by changing one of the values of active attribute to inactive or by creating a new account ID with inactive status. Then check your SQS Queue for messages and you can see a message received which looks this the following:

Conclusion:

In this blog, we explored how to build a serverless program using AWS Lambda, DynamoDB, and SQS. By implementing three Lambda functions, we automated the processing of managing active and inactive accounts. We utilized DynamoDB Streams to trigger a Lambda function whenever an account’s status changed and added the account ID to an SQS queue. Finally, we created a Lambda function to consume the account IDs from the queue and perform necessary actions.

*Documentation and references: *
Dynamo DB
SQS
Code(github)

Note:
The policies attached to the lambda roles are of full access for the purpose of smooth operations in the example. However, One should follow the principle of least privilege and only give necessary policies to the role.

This blog is for knowledge purposes only. Use the resources wisely and responsibly.