DEV Community: Eric Rodríguez

Day 60: Decoupling State and CloudWatch FinOps

Eric Rodríguez — Sat, 18 Apr 2026 16:00:00 +0000

Today, on Day 60 of my 100 Days of Cloud challenge, I had to pause building new features to clean up some critical technical debt in my Serverless AI Financial Agent. When you are preparing an application to scale and handle real users, the little things you hardcoded during the sandbox phase will inevitably come back to haunt you. I faced two specific operational leaks today: one affecting my application's state, and the other quietly threatening my cloud billing.

Fix 1: Decoupling Identity with Lambda Environment Variables

My application was processing duplicate user reports, specifically sending two emails at the exact same time every afternoon. After thoroughly investigating Amazon DynamoDB and confirming the database was completely clean, I realized the issue was hiding inside the Lambda execution environment itself. During my initial testing weeks ago, I left a mock USER_ID hardcoded as a fallback in my Python logic.

Because this hardcoded ID didn't match my real Amazon Cognito UUID in the database, the code generated a fake profile in memory and merged it with the real database records just before processing the SQS queue. The solution was to completely decouple the configuration from the code. I stripped the hardcoded ID from the Python script and injected the target user securely via AWS Lambda Environment Variables. Now, the code is dynamic, stateless, and ready to handle multiple tenants without identity collisions. Your configuration should always live outside your code.

Fix 2: The Infinite Log Trap in Amazon CloudWatch

The second issue was a silent FinOps time bomb. If you use AWS Lambda, you know that it automatically logs all output to Amazon CloudWatch. However, you might not realize that by default, the retention policy for these Log Groups is set to "Never Expire".

If you have a high-traffic application, retaining debug logs indefinitely will eventually result in a hefty and unnecessary storage bill. I navigated to the CloudWatch console and changed the retention policy for my Lambda functions to 14 days. This quick 30-second fix acts as an automated garbage collector. It gives me a comfortable two-week sliding window to troubleshoot any bugs, while AWS automatically destroys the useless historical text logs before I have to pay for storing them.

Architecture is not just about what you build, but also about what you actively choose not to keep. Never hardcode your state, and never keep your logs forever!

Day 59: Fixing Race Conditions with DynamoDB Atomic Locks 🔒

Eric Rodríguez — Fri, 17 Apr 2026 15:00:00 +0000

Are your AWS Lambdas doing things twice? Here is how to fix it.

Today, my SQS queue delivered duplicate messages, and my Lambda function sent two emails to the same user. My initial code checked if a lock existed before writing it, but a classic "Race Condition" bypassed it.

The Fix: Use attribute_not_exists in DynamoDB.

Python
import botocore

email_lock_key = f"email_report_{today}_{user_id}"

try:
# ATOMIC OPERATION: Write ONLY if it doesn't exist
cache_table.put_item(
Item={
'cache_key': email_lock_key,
'status': 'sent',
'ttl': int(time.time()) + 86400, # 24h expiration
'user_id': user_id
},
ConditionExpression='attribute_not_exists(cache_key)'
)
except botocore.exceptions.ClientError as e:
if e.response['Error']['Code'] == 'ConditionalCheckFailedException':
print("Race condition intercepted! Lock already exists.")
# Abort duplicate process here
By doing this, you let DynamoDB act as the absolute source of truth. The hardest part? Having to manually delete these cache keys in the AWS Console just to be able to test the system again!

Day 58: Fix your Fintech app's calendar logic (The Payroll Offset)

Eric Rodríguez — Thu, 16 Apr 2026 15:00:00 +0000

When building AI-powered apps, your standard notification logic needs a serious rethink.

Today, I wanted my AI Financial Agent to send a daily morning email to all users by default.

The Problem: Traditional B2C apps send static templates (cheap). My app uses Amazon Bedrock to generate custom semantic text (expensive). If I blindly loop through 500 inactive or test users and call Bedrock 500 times just to send emails they will never read, my AWS bill will explode. 💥

The Fix: I added a "FinOps" guardrail in my EventBridge Orchestrator Lambda before it pushes tasks to the SQS worker queue.

Python

Before sending to SQS for AI processing, filter out the noise.

valid_users = []
for u in user_metadata_list:
# 1. Product Decision: Opt-out approach
wants_email = u.get('wants_daily_email', True)

# 2. FinOps Decision: Drop ghost/test accounts

is_test_account = str(u.get('user_id', '')).startswith('test_')

if wants_email and not is_test_account:

    valid_users.append(u)

ONLY push valid, engaged users to the expensive AI Worker queue

for user in valid_users:
sqs.send_message(QueueUrl=SQS_URL, MessageBody=json.dumps({"user_id": user['user_id']}))
By filtering test_ accounts and respecting user Opt-Outs at the router level, my AI Worker Lambda only invokes the LLM for users that actually matter.

Code for engagement, but architect for cost!

Day 58: Don't let GenAI bankrupt your Serverless App

Eric Rodríguez — Wed, 15 Apr 2026 15:00:00 +0000

When building AI-powered apps, be very careful with cron jobs.

Today I wanted to make my AI Financial Agent send a daily morning email to all users by default (like traditional finance apps do).

The Problem: Traditional apps send static templates. My app uses Amazon Bedrock to generate custom text. If I loop through 500 inactive users and call Bedrock 500 times just to send emails they won't read, my AWS bill will explode. 💥

The Fix: I added a "FinOps" filter in my EventBridge orchestrator before it sends tasks to the SQS queue.

Before sending to SQS for AI processing, filter out the noise.

valid_users = []
for u in all_users:
wants_email = u.get('wants_daily_email', True) # Opt-out approach
is_test = str(u.get('user_id', '')).startswith('test_')

if wants_email and not is_test:
    valid_users.append(u)

By filtering test_ accounts and respecting user Opt-Outs before the SQS queue, my AI worker Lambda only invokes Bedrock for users that actually matter. Code for engagement, architect for cost!

Day 57: Dynamic HTML Emails in AWS Lambda (FinTech UX) 🎨

Eric Rodríguez — Tue, 14 Apr 2026 15:00:00 +0000

Financial APIs like Plaid are great, but their data structures are built for accountants, not normal humans.

Today, I rewrote the notification engine for my AI Agent.

The Problem

My Lambda was sending emails that looked like a raw JSON dump. Refunds appeared as negative numbers (-4.22€), and expenses were mixed with income.

The Fix
I built a dynamic HTML builder in Python that conditionally renders sections based on the day's payload:

Separate transactions and fix signs
for t in transactions:
amount = float(t['amount'])
if amount < 0 or is_income_keyword(t['description']):
income_txs.append(t)
else:
expense_txs.append(t)

Conditionally render HTML

if income_txs:
html += "

Income / Credits

"
# Format negative API floats to positive UX strings
html += build_rows(abs(amount), color="#10b981")
Now, the emails are cleanly divided, visually color-coded, and highly readable. Plus, the AWS EventBridge orchestrator now perfectly balances hourly SMS alerts with the 9:00 AM daily SQS report.

Never underestimate the power of formatting your data before passing it to the user (or to the LLM!).

Day 56: Beating LLM Latency with Amazon SQS Decoupling ⚡

Eric Rodríguez — Mon, 13 Apr 2026 15:00:00 +0000

If you are building apps with LLMs, you already know the pain: generation takes seconds, and users hate waiting.

Today, I fixed the latency of my AI Financial Agent by implementing the Asynchronous Worker Pattern** using Amazon SQS.

The Problem
My AWS Lambda was running synchronously:
Fetch Bank Data -> Run Heavy AI Prompt -> Generate Email -> Return UI Data.
This caused 5+ second load times and occasional API timeouts.

The Solution
I split my Python lambda_handler to detect the event source.

If the request comes from API Gateway (React Frontend), it bypasses the heavy AI email generation completely and returns the dashboard data instantly.

If the request comes from my EventBridge daily cronjob, it acts as a Fan-Out orchestrator:

Scans DynamoDB and queues the heavy work
for user in users:
sqs.send_message(
QueueUrl=SQS_QUEUE_URL,
MessageBody=json.dumps({"task": "daily_report", "user_id": user['user_id']})
)

Then, SQS automatically invokes the Lambda in the background to handle the heavy Bedrock processing and SES email delivery.

By decoupling the architecture, UI latency dropped by over 70%. Stop making your users wait for background tasks! Have you implemented SQS in your serverless apps yet?

Day 55: Single Table Design for User Profiles in DynamoDB

Eric Rodríguez — Sat, 11 Apr 2026 16:00:00 +0000

Hardcoding variables is a developer habit. Building user configuration is a Product mindset. 🛠️

Up until today, my Serverless AI Financial Agent suffered from the classic "Minimum Viable Product" disease: hardcoded assumptions. The AI assumed a fixed €15 daily budget for everyone to maintain their savings streak, and it lazily parsed usernames directly from their Cognito JWT Token emails (e.g., turning ericridri11@gmail.com into "Ericridri11").

It worked for a proof of concept, but as a user experience? It was terrible.

For Day 55 of my #100DaysOfCloud challenge, it was time to mature the architecture and build a Stateful User Configuration Panel. The users need to take the wheel.

The Challenge: Database Bloat

The immediate thought of any developer is: "I need to save user preferences. Let's spin up a UserPreferences table in the database."

In relational databases (SQL), that's standard practice. But in the cloud, specifically with NoSQL databases like Amazon DynamoDB, compute is cheap but IOPS (Input/Output Operations Per Second) and maintaining multiple tables cost money and operational overhead.

How do we store custom user data without bloating our infrastructure?

The Solution: Single Table Design 🧠

Instead of provisioning a completely new DynamoDB table, I implemented an advanced NoSQL pattern called Single Table Design.

I overloaded my existing FinanceAgent-Transactions table. By querying a specific sort key formatted as PROFILE#{user_id}, I can retrieve a metadata record that acts as a container for user preferences, living right alongside their financial transactions.

With this single record, I can now store:
✅ Display Name (No more email parsing).
✅ Custom Daily Budget Goal (Dynamic streak calculation).
✅ Monthly Salary (For better FinOps forecasting).
✅ AI Personality Tone (Users can choose "Brutal", "Sarcastic", or "Polite").

Fun fact on the "Polite" tone: The app's core identity is "Tough Love". If a user selects "Polite", the system prompt instructs the AI to subtly mock them for being emotionally fragile and unable to handle the truth. The AI never loses!* 🤖

The Lambda Router

Since my entire backend runs on a single AWS Lambda Function URL, I had to upgrade my Python code to act as a basic RESTful router.

I added logic to intercept the HTTP method from the requestContext.

When the user hits "Save" on the React Frontend, a POST request is fired. The Lambda parses the JSON payload and updates the PROFILE record in DynamoDB.
When a standard GET request is made to load the dashboard, the Lambda fetches this profile first, and dynamically injects the user's real name and requested tone directly into the Amazon Nova Micro system prompt.

Here is a snippet of how I implemented the Profile extraction in Python using boto3:

def get_user_profile(user_id, default_name):
profile_id = f"PROFILE#{user_id}"
try:
response = table.get_item(Key={'user_id': user_id, 'transaction_date': profile_id})
if 'Item' in response:
return response['Item']
except Exception as e:
logger.error("Error fetching profile", extra={"details": str(e)})

# Return default schema if no profile exists yet
return {
    'user_id': user_id, 
    'transaction_date': profile_id, 
    'display_name': default_name, 
    'daily_budget': 15.00, 
    'ai_tone': 'brutal'
}

The Lesson

Building the engine is only half the battle. Giving the driver a steering wheel is what makes it a real application. Think about your data access patterns before provisioning new cloud resources. Overloading NoSQL tables is an absolute superpower for keeping costs down while scaling up features.

Day 55: Single Table Design for User Profiles in DynamoDB

Eric Rodríguez — Sat, 11 Apr 2026 16:00:00 +0000

Hardcoding variables is a developer habit. Building user configuration is a Product mindset. 🛠️

It worked for a proof of concept, but as a user experience? It was terrible.

For Day 55 of my #100DaysOfCloud challenge, it was time to mature the architecture and build a Stateful User Configuration Panel. The users need to take the wheel.

The Challenge: Database Bloat

The immediate thought of any developer is: "I need to save user preferences. Let's spin up a UserPreferences table in the database."

How do we store custom user data without bloating our infrastructure?

The Solution: Single Table Design 🧠

Instead of provisioning a completely new DynamoDB table, I implemented an advanced NoSQL pattern called Single Table Design.

The Lambda Router

Since my entire backend runs on a single AWS Lambda Function URL, I had to upgrade my Python code to act as a basic RESTful router.

I added logic to intercept the HTTP method from the requestContext.

When the user hits "Save" on the React Frontend, a POST request is fired. The Lambda parses the JSON payload and updates the PROFILE record in DynamoDB.
When a standard GET request is made to load the dashboard, the Lambda fetches this profile first, and dynamically injects the user's real name and requested tone directly into the Amazon Nova Micro system prompt.

Here is a snippet of how I implemented the Profile extraction in Python using boto3:

# Return default schema if no profile exists yet
return {
    'user_id': user_id, 
    'transaction_date': profile_id, 
    'display_name': default_name, 
    'daily_budget': 15.00, 
    'ai_tone': 'brutal'
}

The Lesson

Day 54: Giving an LLM Long-Term Memory with DynamoDB

Eric Rodríguez — Fri, 10 Apr 2026 16:00:00 +0000

One of the biggest limitations of stateless serverless applications using LLMs (like Amazon Bedrock or OpenAI) is amnesia. Every API call starts from zero.

Today, I built a persistent memory engine for my AI Financial Agent so it remembers a user's behavior from previous months.

The Architecture:
I created a DynamoDB table with user_id (from Cognito JWT) as the Partition Key and month_year as the Sort Key.

Before calling Bedrock, my Python Lambda fetches last month's summary:

def get_user_memory(user_id, prev_month_str):
# DynamoDB get_item logic...
I then inject this into the LLM prompt:

Plaintext
PREVIOUS MONTH MEMORY:
"{past_memory}"
Analyze the current transactions and compare them to the past memory.

The crucial part? I force the LLM to output a memory_for_next_month string in its JSON response.

{
"score_feedback": "You spent 50€ less on eating out than last month. Good job.",
"memory_for_next_month": "User successfully cut back on dining expenses but increased tech spending."
}

Lambda intercepts this key and saves it back to DynamoDB using the current month's timestamp. It creates an infinite loop of context, turning a basic API wrapper into a continuous AI companion!

Day 53: CI/CD for React on AWS S3 & CloudFront (No Access Keys!) 🚀

Eric Rodríguez — Thu, 09 Apr 2026 16:00:00 +0000

Deploying React to S3 manually gets old fast. If you are still dragging and dropping folders into the AWS Console, it's time to stop.

Today, I built a GitHub Actions pipeline that builds my React app, syncs it to S3, and clears the CloudFront cache automatically. Best part? Zero static AWS credentials.

The Workflow

Assuming you already have an OIDC Identity Provider set up in AWS IAM (which you should, to avoid storing Access Keys in GitHub Secrets), here is the workflow I wrote today:

YAML
name: Deploy Frontend
on:
push:
branches: [ main ]
paths: [ 'src/**', 'App.tsx', 'package.json' ]

permissions:
id-token: write
contents: read

jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '20' }

  - run: npm ci
  - run: npm run build
    env:
      VITE_AWS_REGION: "eu-north-1"
      VITE_USER_POOL_ID: "your-pool-id"

  - name: Configure AWS Credentials via OIDC
    uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::1234567890:role/GitHubDeployRole
      aws-region: eu-north-1

  - name: Sync to S3
    run: aws s3 sync dist/ s3://my-react-bucket --delete

  - name: Invalidate CloudFront
    run: aws cloudfront create-invalidation --distribution-id E1ABCD2345 --paths "/*"

Why the --delete flag?

Using aws s3 sync with --delete is crucial. It removes old JavaScript chunks from S3 that were generated in previous builds, preventing your bucket from growing infinitely with dead code.

My deployments now take 45 seconds and require zero clicks in the AWS console. Automate everything!

Day 52: How to build a Split-Screen Login & Parse JWTs in AWS Lambda 🔐

Eric Rodríguez — Wed, 08 Apr 2026 14:00:00 +0000

I hated the default Amazon Cognito login screen. It looked like a dashboard from 2015.

Today, I decided to build a custom Split-Screen Auth UI for my React app and update my AWS Lambda backend to actually read the JSON Web Tokens (JWT) sent by the frontend. Here is exactly how I did it.

The Frontend: Split-Screen Auth with Amplify

Instead of using the standard wrapper which forces a centered card, I used Authenticator.Provider. This gives you access to the useAuthenticator hook so you can render the login form exactly where you want it.

I built a two-column layout using Tailwind CSS. Left side: Branding. Right side: Login.

import { Authenticator, useAuthenticator } from '@aws-amplify/ui-react';

const CustomAuthWrapper = () => {
const { authStatus } = useAuthenticator((context) => [context.authStatus]);

if (authStatus === 'authenticated') return ;

return (

{/* Left Column: Branding */}

FinAI Agent

  {/* Right Column: Auth Form */}
  <div className="w-1/2 flex items-center justify-center">
       <Authenticator />
  </div>
</div>

);
};

Injecting the Bearer Token

To make the backend aware of who is calling it, we need to send the Cognito JWT. I updated my fetch calls in React to grab the session token dynamically:

JavaScript
import { fetchAuthSession } from 'aws-amplify/auth';

const { tokens } = await fetchAuthSession();
const jwtToken = tokens?.idToken?.toString();

const response = await fetch(API_URL, {
headers: { 'Authorization': Bearer ${jwtToken} }
});

The Backend: Parsing JWT in Python (AWS Lambda)

API Gateway handles the heavy lifting of verifying the signature, but I still needed my Lambda function to know who the user was to query DynamoDB correctly. I wrote a small base64 decoding snippet to extract the sub (user ID) and email.

Python
import base64
import json

def lambda_handler(event, context):
headers = event.get('headers', {})
auth_header = headers.get('authorization', headers.get('Authorization', ''))

if auth_header.startswith('Bearer '):
    token = auth_header.split(' ')[1]
    payload_b64 = token.split('.')[1]
    payload_b64 += '=' * (-len(payload_b64) % 4) # Add padding

    payload = json.loads(base64.b64decode(payload_b64).decode('utf-8'))

    user_id = payload.get('sub')
    user_email = payload.get('email')

    print(f"Authenticated: {user_email} (ID: {user_id})")

My Serverless app is now officially Multi-Tenant! Every user gets their own DynamoDB sandbox, and the AI greets them by their real name. 🚀

Day 51: I stopped building Login pages manually 🛑🔑

Eric Rodríguez — Tue, 07 Apr 2026 16:00:00 +0000

I am officially done writing

tags for login and registration.

Today (Day 51 of my cloud journey), I connected my React application to Amazon Cognito using AWS Amplify UI.

With just a few lines of configuration pointing to my User Pool ID and Client ID, I wrapped my app in the component.

What it gave me out of the box:

A clean UI for Sign-In and Sign-Up.

Automatic verification code emails (OTP).

Secure JWT session management in local storage.

A signOut hook to instantly kill the session.

If you are a frontend developer building on AWS, using the Amplify UI library is practically a superpower. My dashboard is now completely locked down.