AWS Day 42: Building and Managing NoSQL Databases with AWS DynamoDB

As part of my KodeKloud 100 Days of Cloud journey, Day 42 focused on working with Amazon DynamoDB, AWS's fully managed NoSQL database service.

For this task, the Nautilus DevOps team needed a simple database for a To-Do application. The application required a table where each task could be uniquely identified and additional information such as its description and current status could be stored.

The main requirements were:

• Create a DynamoDB table named datacenter-tasks

• Configure taskId as the primary key

• Use String as the data type for taskId

• Insert two tasks into the table

• Store the task description and status

• Verify that both records were inserted correctly

• Confirm the status of each task

This was a straightforward task, but it was useful for understanding how DynamoDB tables, partition keys, items, and attributes work.

Step 1: Open DynamoDB

I opened the AWS Management Console and navigated to:

AWS Console → DynamoDB → Tables

From the Tables section, I selected:

Create table

AWS provides a simple interface for creating the table and defining its primary key.

Step 2: Create the DynamoDB Table

Under Table name, I entered:

datacenter-tasks

For the partition key, I entered:

taskId

I selected:

String

as the data type.

The configuration was:

Table name  : datacenter-tasks
Partition key: taskId
Type        : String
Sort key    : Not configured

I did not configure a sort key because the task only required taskId to uniquely identify each task.

Step 3: Use Default Table Settings

For this lab, I kept the default table settings.

DynamoDB allows advanced configuration options for use cases that require additional control over capacity, backups, encryption, indexes, streams, and other features.

However, none of those additional settings were required for this task.

Using the default settings kept the table configuration simple and focused on the actual application requirement.

Step 4: Verify the Table

After creating the table, I opened the datacenter-tasks table from the DynamoDB Tables section.

The table showed the following primary key configuration:

Partition key: taskId (String)
Sort key     : -

This confirmed that the table was created with the correct primary key.

The table was ready to store the To-Do application records.

---

Step 5: Create the First Task

Next, I opened the table and selected the option to create an item.

For the first item, I entered:

taskId     : 1
description: Learn DynamoDB
status     : completed

The item therefore contained three attributes:

Attribute	Value	Type
taskId	1	String
description	Learn DynamoDB	String
status	completed	String

I saved the item successfully.

DynamoDB vs Traditional Relational Databases

One of the key differences between DynamoDB and relational databases is the data model.

A relational database might have a table such as:

tasks
--------------------------------
id | description | status
--------------------------------
1  | Learn ...   | completed
2  | Build ...   | in-progress

DynamoDB instead stores each record as an item containing attributes.

For example:

{
  "taskId": "1",
  "description": "Learn DynamoDB",
  "status": "completed"
}

This model makes DynamoDB particularly useful for applications where flexible attributes and predictable key-based access are important.

Conclusion

Day 42 focused on building a simple task management database using Amazon DynamoDB.

I created the datacenter-tasks table with taskId as the String partition key, then inserted two task records:

Task 1 → Learn DynamoDB → completed
Task 2 → Build To-Do App → in-progress

After inserting the records, I used the DynamoDB console to verify that both items were present and that their statuses matched the requirements.

Although this was a simple lab, it provided practical experience with the core DynamoDB concepts that are important when building serverless and cloud-native applications.

The key lesson from this task was that DynamoDB table design should be driven by access patterns, partition-key design, scalability, and application requirements rather than by simply trying to model a relational database in a NoSQL service.

Another AWS task completed in my KodeKloud 100 Days of Cloud journey, with a better understanding of how DynamoDB can be used to build scalable NoSQL applications.

---