Forem: Eric Rodríguez

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.

Day 50 🎉: Securing my GenAI API with Amazon Cognito

Eric Rodríguez — Mon, 06 Apr 2026 16:00:00 +0000

I hit Day 50 of my #100DaysOfCloud challenge today! To celebrate, I decided to tackle the scariest part of any GenAI side project: Billing Spikes from unprotected APIs.

My AI Financial Agent uses Amazon Bedrock under the hood. Until today, the API was open. To fix this, I set up Amazon Cognito.

Instead of building a custom login system (and probably hashing passwords wrong), I let AWS handle it.

My Cognito Setup:

Authentication: Email & Password.

App Client: Public Client (for my React SPA).

Security: AWS handles the heavy lifting of issuing JWTs (ID, Access, and Refresh tokens).

Tomorrow, I will connect this User Pool to my React frontend using AWS Amplify, and configure my backend to validate the tokens. No Token = No AI generation = Safe Budget!

If you are building with GenAI, put authentication in front of your APIs on Day 1 (or Day 50, better late than never!).

Day 49: Adding a Monetization Layer to my Serverless App 💸

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

If you are building a SaaS or Fintech application, eventually you need to figure out how to monetize it. Today, I added a Cross-Selling Recommendation Engine to my Serverless AI Financial Agent.

The Concept:
My backend already calculates a Financial Score (0-100) based on the user's spending habits. I created a new Python function that evaluates this score alongside their available cashflow to recommend specific financial products.

Python
def generate_financial_offers(score, income, expenses):
net_surplus = income - expenses
offers = []

# High Score + Cashflow = Credit Card Upsell
if score >= 70 and net_surplus > 500:
    offers.append({
        "type": "CREDIT_CARD",
        "title": "FinAI Premium Rewards",
        "description": "Pre-qualified for our 2% cashback card."
    })
# Low Score + Debt = Consolidation Loan
elif score < 50 and net_surplus < 0:
    offers.append({
        "type": "LOAN",
        "title": "Debt Consolidation Loan",
        "description": "Consolidate your debt today with a 5.9% APR loan."
    })

return offers

This logic runs inside AWS Lambda and attaches the offers directly to the JSON response consumed by React. Next up, I'll be building out the UI components to display these offers!

Day 48: Deploy AWS Lambda without ClickOps (Using GitHub Actions & OIDC)

Eric Rodríguez — Fri, 03 Apr 2026 14:00:00 +0000

Uploading .zip files to the AWS console gets old really fast. Today, I completely automated my serverless backend deployments.

Instead of taking the easy route and storing AWS Access Keys in my GitHub Secrets (a major security anti-pattern), I implemented OIDC (OpenID Connect) authentication.

How it works:

Trust: AWS IAM is configured to trust GitHub's OIDC provider.

Assume Role: My GitHub Action workflow uses aws-actions/configure-aws-credentials to assume a specific IAM role.

Deploy: On every git push, the action packages my Python code and updates the Lambda function via the AWS CLI.

The funny part? The automation worked so well that my Lambda executed faster than my third-party banking API (Plaid) could generate test data, throwing a PRODUCT_NOT_READY timeout error! A quick time.sleep(8) fixed the race condition.

YAML

The magic step in the workflow

name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789012:role/GitHubActions-LambdaDeployRole aws-region: eu-north-1

Now, my deployments take 15 seconds, and I have zero static credentials lying around. Escaping ClickOps feels great.