From Static Storage to Managed Databases: Learning Amazon RDS, DynamoDB & AWS Lambda (Day 5)

Source: Dev.to

🚀 The Objective

Today’s goal was to understand how cloud applications manage and process data.
The focus areas were:

• Deploying a managed relational database and connecting an application server to it
• Learning NoSQL database architecture
• Executing backend logic using serverless functions

This involved three key AWS services:

• Amazon RDS
• Amazon DynamoDB
• AWS Lambda

🗄️ Step 1: Understanding Amazon RDS

Amazon RDS (Relational Database Service) is a managed database offering that abstracts away common operational tasks:

• OS patching
• Backups
• High‑availability configuration
• Scaling

Supported engines include MySQL, PostgreSQL, MariaDB, Oracle Database, and Microsoft SQL Server.

For practice, I created a MySQL RDS instance.

⚙️ Step 2: Launching an RDS Database

Using the AWS console I provisioned a free‑tier‑eligible instance with the following configuration:

After creation, AWS supplied a database endpoint, e.g.:

mydb.xxxxxx.ap-south-1.rds.amazonaws.com

This endpoint serves as the address applications use to connect to the database.

🔗 Step 3: Connecting EC2 to RDS

To link an Amazon EC2 instance with the RDS database, I performed the following steps:

1. Security group configuration – allowed inbound MySQL traffic (port 3306) from the EC2 security group.
2. Use the RDS endpoint – referenced the endpoint in the connection string.
3. Connect via MySQL client – executed mysql -h <endpoint> -u <user> -p from the EC2 server.

Once connected, I could:

• Create databases and tables
• Insert and retrieve data

This demonstrates a typical pattern where application servers interact with managed relational databases.

🧩 Step 4: Understanding DynamoDB (NoSQL)

Amazon DynamoDB is a fully managed NoSQL service built for high scalability and low latency. Data is organized into:

• Tables – containers for items
• Items – analogous to rows
• Attributes – analogous to columns

Key advantages

• Automatic scaling
• Millisecond‑level latency
• Serverless architecture
• Fully managed infrastructure

Typical use cases include mobile apps, gaming back‑ends, real‑time analytics, and other serverless workloads.

⚡ Step 5: Running Serverless Code with AWS Lambda

AWS Lambda lets developers run code without provisioning or managing servers. Functions are invoked only when triggered, such as by:

• API requests (via API Gateway)
• S3 file uploads
• DynamoDB streams
• Scheduled CloudWatch events

For practice, I created a Lambda function that performed CRUD operations on a DynamoDB table. The flow looked like:

1. Client request → triggers Lambda via API Gateway
2. Lambda execution → interacts with DynamoDB
3. Response → returned to the client

Lambda abstracts away infrastructure, scaling, and the execution environment, allowing developers to focus solely on business logic.

🧠 Key Technical Takeaways

• Amazon RDS provides managed relational databases, handling patching, backups, and scaling.
• EC2 applications can securely connect to RDS using endpoints and proper security groups.
• SQL vs. NoSQL: relational databases enforce schemas; DynamoDB offers flexible, schema‑less storage with automatic scaling.
• DynamoDB excels at high‑throughput, low‑latency workloads.
• AWS Lambda enables serverless back‑end logic, automatically managing compute resources.
• Serverless architecture simplifies infrastructure management and allows rapid scaling.

A central realization: cloud platforms give developers the flexibility to choose the most appropriate architecture—traditional servers, object storage, or serverless services—based on application requirements.

🎯 Reflection

In just a few days of cloud engineering learning, I’ve explored three distinct deployment models:

Each approach solves different problems, and understanding when to apply each is the essence of effective cloud engineering. The journey continues—more exploration ahead! 🚀