Before building the backend portion of my project—specifically the Lambda functions and DynamoDB tables—I wanted to make sure I had proper cost monitoring in place.

AWS provides a powerful platform, but with that flexibility comes responsibility. A misconfigured service, an unexpected spike in traffic, or a forgotten resource can quickly lead to charges that exceed the Free Tier. To avoid surprises, I set up proactive cost controls with AWS Budgets. Budgets tracks account spend and emails me when thresholds are crossed, so I do not need CloudWatch billing alarms for this safety net.

Step 1: Creating a Monthly Cost Budget

In Billing and Cost Management, I opened Budgets and created a cost budget for the whole account.

• Budget type: Cost budget
• Period: Monthly
• Budget amount: $10.00
• Scope: Overall account spending

A $10 monthly ceiling is enough headroom for this Cloud Resume project while still catching runaway usage early. Once the budget is active, AWS shows its health status in the Budgets console so I can confirm it is tracking correctly.

Step 2: Configuring Budget Alert Thresholds

Budgets can notify me directly by email when actual or forecasted spend approaches the limit. I configured threshold alerts so I get warned before the full amount is used:

• Early warning: notify when actual costs reach a percentage of the budget (for example 50% or 80%)
• Limit reached: notify when actual costs reach 100% of the $10 budget
• Optional forecast alert: notify if AWS forecasts that the month will exceed the budget

These notifications are managed by AWS Budgets itself. I do not create CloudWatch alarms on EstimatedCharges or wire SNS topics just to get billing emails for this project.

Step 3: Why Budgets Instead of CloudWatch Alerts

CloudWatch billing alarms are a valid pattern, but for account-level spend control AWS Budgets is the clearer fit:

• Budgets are purpose-built for cost and usage thresholds
• Alerting is configured on the budget, without a separate CloudWatch metric alarm
• I can track actual and forecasted spend in one place
• The console health view makes it obvious the control is active

For this stage of the challenge, one monthly cost budget with email thresholds is enough. I can add service filters or tighter limits later if the architecture grows.

Why Proactive Monitoring Matters

Setting up cost monitoring early is part of responsible cloud architecture. As I move into the backend phase, I will use Lambda, DynamoDB, and API Gateway. Those services scale easily—and so can the bill if something misbehaves (for example a loop or unexpected traffic).

With AWS Budgets watching a $10 monthly limit, I can experiment knowing unusual spend will trigger an email before it becomes a surprise invoice.

What's Next?

With cost monitoring in place and the frontend infrastructure fully automated, it's time to begin building the dynamic backend components of the website.

In the next post, I'll walk through how I created a serverless visitor counter using AWS Lambda and DynamoDB. This feature tracks how many people visit the site and displays the count directly on the homepage.