WebGuardian Series: Why DynamoDB & Lambda Are the Most Cost-Effective Backend Choices (Part 1)

The Journey Begins

To sharpen my skills in building active-active architectures using AWS, I decided to develop WebGuardian, a powerful web application designed to monitor websites by performing regular health checks and sending real-time notifications based on user preferences.

When choosing the tech stack, I explored various AWS services—database options like RDS, Timestream, and DynamoDB; compute services like EC2 and Lambda; and storage services like S3 and EFS. My mission was clear: select the most cost-efficient solution that keeps the architecture simple, scalable, and ready for future enhancements.

What We’ll Cover

In this article, I’ll walk you through why I chose DynamoDB for the database and Lambda for the backend compute service for WebGuardian. We’ll break down the costs, explain the design choices, and see how these AWS services support a serverless and highly-available architecture. Future articles will dive into the front end, networking, and total project cost. For now, let’s focus on the backend infrastructure, If you don’t want to miss these insights, sign up for my newsletter to get all the updates delivered straight to your inbox. You’ll gain tips on how to build scalable, cost-efficient solutions for your own projects.

Introducing WebGuardian

WebGuardian is your website’s guardian angel! By performing health checks based on the protocol, domain name, and path you provide, it ensures that your website is always up and running. Each health check produces a 390-byte record, and the system is designed to perform hourly checks for simplicity.

To decide which AWS database service was the best fit, I used the AWS Pricing Calculator to compare costs. In this article, we’ll focus on three key factors:

1. Data volume
2. Access patterns
3. Architectural considerations

Let’s dive into the details!

Data Volume Calculations

The first step was estimating how much data WebGuardian generates. Here’s what I found:

• Record size: 390 bytes
• Records per minute: 1,000 websites
• Daily records: 1.44 million (1,000 records × 24 hours × 60 minutes)
• Monthly records: 43.2 million
• Monthly data volume: 16.85 GB (43.2 million × 390 bytes)

These numbers helped me estimate the storage needs and evaluate which database could handle the load most efficiently.

Understanding the Access Patterns

For writes, the health check system consistently writes 1,000 records per minute. This is a predictable, continuous pattern, which simplifies the database design since no peak periods need to be considered.

For reads, I assumed 100 users, each monitoring 5 websites. The system would handle sporadic, user-initiated reads, with each user reading 1–2 health checks per website every month.

These access patterns were key to understanding the read and write capacity required for the database.

Database Options Analysis

With data volume and access patterns in mind, I analyzed the costs and architectural benefits of three AWS database services: DynamoDB, RDS, and Timestream.

1. Amazon DynamoDB

Why It Works for WebGuardian

DynamoDB’s serverless architecture is a perfect match for Lambda, making it an ideal choice for WebGuardian. Its auto-scaling capabilities and global table support make it easy to implement a highly-available active-active architecture across multiple regions.

DynamoDB Cost Breakdown for Detailed Status:

DynamoDB Performance:

• Write latency: 1–2ms
• Read latency: 5–10ms
• Consistent performance, no cold starts
• Simple global tables for active-active setups

2. Amazon Aurora PostgreSQL

Aurora Considerations

Aurora is a powerful relational database but requires active instance management, and the setup for active-active deployments is complex. It also needs connection pooling for Lambda, making the setup more challenging compared to DynamoDB.

Aurora Cost Breakdown for Detailed Status:

Aurora Performance:

• Write latency: 5–10ms
• Read latency: 10–20ms
• Requires warm-up periods, adds complexity

3. Amazon RDS PostgreSQL

RDS Considerations

RDS offers a more traditional relational database experience, but it lacks serverless capabilities. Its manual scaling and complex active-active setup make it less desirable compared to DynamoDB.

RDS Cost Breakdown for Detailed Status:

RDS Performance:

• Write latency: 5–15ms
• Read latency: 10–30ms
• Predictable performance with SQL flexibility

4. Amazon Timestream

Timestream Considerations

Timestream is purpose-built for time-series data with automatic lifecycle management. While its performance is optimized for time-series queries, its higher costs and less flexible general-purpose querying made it a less attractive option for WebGuardian.

Timestream Cost Breakdown for Detailed Status:

Timestream Performance:

• Write latency: 2–5ms
• Read latency: 20–50ms
• Automatic data tiering and time-series optimized queries

Unified Cost Comparison Table (Detailed Status Only):

DynamoDB emerges as the clear winner, offering the best balance of cost and performance for WebGuardian. It is the most affordable solution while providing reliable, low-latency performance and automatic scaling.

Lambda Execution Cost

Using EC2 for WebGuardian’s periodic tasks would be costly and inefficient, as running an instance 24/7 to process simple health checks is overkill. Instead, I chose AWS Lambda, which triggers a cron job to run every minute for an event-driven architecture. Here’s a breakdown of the cost:

each Lambda function runs for approximately 30 seconds, checking 1000 websites:

• 1,000 websites, running every minute
• Total monthly executions = 1,000 websites × 60 runs per hour × 24 hours per day × 30 days per month = 43,200 executions
• Cost per execution (for a 128 MB Lambda function running for 30 seconds) ≈ $0.00005001.

Total monthly Lambda cost = 43,200 executions × $0.00001667 * 3 ≈ $2.16/month.

At just about 3 dollars a month, Lambda provides an affordable and scalable way to handle WebGuardian’s backend processing.

DynamoDB Capacity Provisioning for WebGuardian

WebGuardian requires 17 Write Capacity Units (WCU) to handle 1,000 writes per minute, or 16.67 writes per second. For Read Capacity Units (RCU), 100 users reading 5 websites each sporadically requires 5 RCU. With 17 WCU for writes and 5 RPU for user reads, this configuration ensures smooth performance for both reads and writes.

Wrapping Up

In the end, DynamoDB and Lambda together provide a highly cost-effective, serverless, and scalable solution for WebGuardian. The low total cost, fast performance, and ability to handle millions of records monthly make DynamoDB the optimal choice. Lambda adds the flexibility to scale as needed without requiring dedicated instances, keeping costs low at just about $15/month for backend processing.

By carefully evaluating each option, I’ve created a system that is highly available, efficient, and most importantly, cost-effective—perfect for a web monitoring application like WebGuardian.

Want more? Future articles will dive deep into the front-end design, networking setup, and a detailed breakdown of the total project costs. I’ll also be sharing insights on how to scale, enhance performance, and even optimize your AWS costs further.