DEV Community: Eric Rodríguez

Day 78: Hunting Silent IAM Bugs & Securing DynamoDB

Eric Rodríguez — Sat, 09 May 2026 15:00:00 +0000

aws #serverless #react #webdev

published: true
date: "2026-05-08 21:30:00 UTC"
Today was one of those days where the code was technically correct, but the infrastructure said "No." I had to dive deep into AWS CloudWatch to fix a cascading series of silent failures in my AI Financial Agent.

Here is the breakdown of today's architecture fixes:

The Silent IAM Policy Trap
I built a full account annihilation flow. The user clicks "Delete," and Lambda is supposed to wipe their DynamoDB history and Cognito identity. But it didn't work. The API returned a success status, but the data remained.
Checking CloudWatch revealed an AccessDeniedException. My Lambda role lacked the dynamodb:BatchWriteItem and cognito-idp:AdminDeleteUser permissions. In serverless, if your IAM policies are strictly scoped (as they should be), you must account for every single AWS SDK method you call. I updated the inline policies, and the nuclear button finally worked.
DynamoDB Deletion Protection
While running manual boto3 cleanup scripts to fix the IAM mess, I realized a single typo in my Table() definition could wipe my production database. To fix this, I enabled Deletion Protection on my FinanceAgent-Transactions table. It's a simple toggle in the AWS Console that makes it impossible to delete the table without explicitly disabling the protection first. A 30-second fix for ultimate peace of mind.
React Data Hydration Flash
On the frontend, my UI had an annoying flash when loading the user's avatar. I was trying to be clever with Tailwind opacity-0 transitions and onLoad events. I ripped that out. By relying purely on localStorage caching and removing artificial CSS delays, the avatar now renders instantly on mount.
Context-Aware AWS SES Emails
My backend was lazily recycling the "Daily Report" HTML template for new users, resulting in welcome emails that said "Yesterday's Expenses: 0.00". I refactored email_engine.py to include a dedicated, structurally clean generate_welcome_email() function, and tied it to a strict welcome_email_sent flag in DynamoDB to guarantee it only fires once per user.

Infrastructure is messy, but today the system is drastically more resilient.

Day 77: Fixing React Hydration & AWS SES Identities

Eric Rodríguez — Fri, 08 May 2026 16:00:00 +0000

Sometimes you architect a robust Serverless backend only to realize your frontend feels clunky and your automated emails look like spam. Today, I fixed two glaring UI/UX issues in my AI Financial Agent.

The React Avatar Flash I had a classic Data Hydration issue. When a user logged in, React synchronously rendered a default avatar, waited 200ms for DynamoDB to return the real profile picture URL, and then aggressively snapped the new image into place.

The fix? Stop rendering placeholders if you are in a loading state. I modified my React component to leave the avatar space as a clean white circle (!isAvatarLoading && ) while the network request resolves. Paired with localStorage caching, returning users get instant loads, and new users get a clean experience without jarring layout shifts.

The Robot Email in AWS SES My Python Lambda was sending daily reports via SES using Source="ai@duromoney.com". While technically correct, it looked completely untrustworthy in an inbox.

By changing the Boto3 payload to Source="DuroAI ai@duromoney.com", Gmail and Outlook now display "DuroAI" as the sender name. I also used this opportunity to wire up an Event-Driven Welcome Email. The moment a user's profile is saved for the first time in DynamoDB, the Lambda router intercepts the payload and triggers a custom SES welcome template.

Code for functionality, but architect for trust!

Day 76: Supercharging my React App with AWS CloudFront CDN

Eric Rodríguez — Thu, 07 May 2026 15:00:00 +0000

Today I tackled one of the most common UI annoyances: slow-loading profile pictures.

My serverless financial app uses AWS S3 to store user avatars. It works perfectly, but S3 object URLs can be slow to resolve depending on where the user is physically located.

(The Upgrade: Amazon CloudFront)
To fix this, I put a CDN in front of my bucket. I created a CloudFront distribution pointing to my S3 origin. This allows AWS to cache the images at edge locations globally. If a user in Spain requests their avatar, it is served from a local cache rather than traveling all the way to my bucket in Sweden.

(The Backend Fix)
I updated my Python Lambda function so that when a user uploads a new photo, the backend returns the new cloudfront.net URL instead of the raw S3 endpoint.

(The Frontend Fix)
To make it even faster, I implemented a local caching strategy in React. I mapped my useState hook for the avatar to localStorage. Now, the browser remembers the CloudFront URL instantly on page load, eliminating the awkward UI flash while React waits for the API response.

Next time you use S3 for public assets, put CloudFront in front of it. Your users (and your bandwidth bill) will thank you!

Day 75: Building a "Nuclear" Delete Button and S3 Avatar Uploads

Eric Rodríguez — Wed, 06 May 2026 16:00:00 +0000

Today I tackled user profile management in my serverless financial app. I added AWS S3 for profile pictures and a Nuclear Button for absolute data deletion.

(The Avatar Upload)
Sending binary files through API Gateway can be tricky. Instead of dealing with multipart/form-data natively in the API Gateway, I converted the images to base64 in React. My Python Lambda takes this string, decodes it, and uses boto3 (s3_client.put_object) to store the image in an S3 bucket with an ACL of 'public-read'.

(The Nuclear Button)
Soft deletes are easy, but real privacy requires hard deletes. When a user clicks "Delete Account" in the React Danger Zone, the Lambda function executes two critical steps:

DynamoDB Purge: It queries the Single-Table design for the user's ID and uses a batch_writer to destroy every single record (transactions, preferences, semantic profiles).
Cognito Annihilation: It uses the cognito-idp client (admin_delete_user) to completely remove the user identity from the User Pool.

If you are building SaaS tools, give your users a real exit door. It builds trust and keeps your database clean of inactive data!

Day 74: Use Glassmorphism and Narrative to Tame Your AI App First-Log-In Latency

Eric Rodríguez — Tue, 05 May 2026 16:00:00 +0000

When building AI-powered apps, GenAI is not the only source of latency. External banking APIs, database insertions, and model context generation add measurable seconds during initial user provisioning.

For a new user, 10 seconds of a raw spinner or a blank screen means this app is broken.

Today, I scrapped generic raw spinners. I moved away from a passive loading component and architected an immersive Provisioning state in React to manage cold-boot anxiety.

React detects a new user (no transactions and no name in database). It forces a profile modal first. Only when the user hits Save does the application trigger the expensive data fetch and immediately invoke a conditional state. This activates a backdrop-blur glassmorphism full-screen overlay.

The overlay replaces the Raw Spinner with a narrative sequence: provisioning agent, retrieving footprint, training models. The wait feels productive and professional, not broken.

By managing anxiety rather than just optimizing code, we achieved a professional Fintech onboarding flow. Code for speed, architect for sanity!

Day 73: Stop AWS Cognito from duplicating your users

Eric Rodríguez — Mon, 04 May 2026 16:00:00 +0000

Integrating Social SSO into your React app is supposed to make life easier. But if you aren't careful with how your backend handles identities, you will create a massive headache for yourself.

Today, I realized my AWS Cognito integration was silently creating duplicate accounts.

The Problem: I had users who originally signed up with an email and password. When I added "Sign in with Google", Cognito treated those returning users as completely new entities because they had a new internal sub ID. My DynamoDB tables were fragmenting. Worse, my AI Engine (Amazon Bedrock) was being invoked from scratch for these returning users, driving up my cloud bill unnecessarily and destroying loading times.

The Architectural Fix (Lambda Interceptor)
I couldn't let Cognito dictate my database schema. I modified my main Lambda router to intercept the incoming JWTs from the React frontend before they hit the database.

Instead of blindly querying DynamoDB using the sub provided by the auth header, I decoded the token to extract the raw email.


python
# Inside the Lambda Authorizer / Router
token = auth_header.split(' ')[1]
payload = json.loads(base64.b64decode(payload_b64).decode('utf-8'))

user_email_jwt = payload.get('email', '')
real_name = payload.get('name') or payload.get('given_name')

# Force Unification: Use email as the absolute DB key
if user_email_jwt:
    user_id = user_email_jwt.lower()
    user_name = real_name if real_name else user_email_jwt.split('@')[0].capitalize()
else:
    user_id = payload.get('sub', DEFAULT_USER_ID)

By enforcing the email as the Primary Key in DynamoDB, the data source of truth shifted back to my backend. Immediate load times were restored.

The Frontend Polish
While I was at it, I fixed two nagging local development bugs:

Vite Port Binding: Vite kept binding to random ports when I used the --host flag, breaking my strict Cognito Allowed Callback URLs. I updated my App.tsx to dynamically read window.location.origin so I don't have to hardcode ports anymore.

Session Contamination: To ensure the dual-identity bug didn't leave cached artifacts behind, I overrode the AWS Amplify signOut function to completely wipe localStorage before redirecting the user.

Own your user data logic. Code for engagement, but architect for sanity!

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zlwuk92ldmqbzqmb90rt.png)

Day 71: OpenGraph Meta Tags & Preparing Google OAuth

Eric Rodríguez — Sat, 02 May 2026 15:00:00 +0000

Today I fixed two critical "Top of Funnel" issues in my Serverless app: Link Previews and Login Friction.

The OpenGraph Fix If you paste your React app's link in Slack or Discord and it looks blank, you are missing OpenGraph tags. I updated my index.html :

Added og:image and og:description for standard previews.

Added twitter:card="summary_large_image" (Yes, it's still called twitter under the hood!).

Updated apple-touch-icon for mobile bookmarks.

Preparing Google Auth for AWS Cognito I hate passwords. To implement "Sign in with Google", you need a bridge. Today I went into the Google Cloud Console:

Created an OAuth Consent Screen.

Generated an OAuth 2.0 Client ID.

Set the Redirect URI to match my AWS Cognito Domain endpoint (https://.auth..amazoncognito.com/oauth2/idpresponse).

Day 71: Secure your Naked Domain & Stop SQS from DDOSing your API

Eric Rodríguez — Fri, 01 May 2026 15:00:00 +0000

Today I fixed two major production risks in my Serverless Fintech app.

Fixing the HTTPS "Not Secure" warning on Apex Domains
If users type duromoney.com, they shouldn't see a security error.
Fix: Go to your DNS registrar (e.g., IONOS) and delete standard redirects. Create an A-Record for @ pointing to your hosting provider's Load Balancer IP. Then, provision an SSL certificate that explicitly covers both the root and www domains.
Preventing SQS from breaking downstream APIs
My SES email limit is 14/sec. If SQS dumps 10k messages into AWS Lambda, the system crashes from 429 Rate Exceeded errors.
Fix: Do NOT use Lambda Reserved Concurrency (it blocks your web API traffic if you use a Fat Lambda pattern). Instead, set the Maximum Concurrency directly on the SQS Trigger (Event Source Mapping) to 10. SQS is now bottlenecked at the source, processing messages smoothly without hitting rate limits.

Build for speed, but configure for control!

Build a Python recommendation engine for your Fintech app 💳

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

Day 70 of my #100DaysOfCloud journey! Today I focused on the business side of engineering: Monetization.

I wanted my React dashboard to show tailored financial offers (like high-yield accounts or cheap transfer apps) based on the user's actual spending habits.

The Backend Logic (Python + AWS Lambda):
Instead of random ads, I built a smart router. It calculates the user's projected surplus and injects a specific JSON offer.

Python
def generate_financial_offers(fin_score, surplus):
offers = []

# Investor Profile
if surplus > 1000 and fin_score >= 70:
    offers.append({
        "title": "Make your surplus work for you",
        "description": f"You have ~{surplus}€ uninvested. Earn 4% APY.",
        "cta_text": "Explore Brokers"
    })
# High-Burn Profile
elif surplus < 200:
    offers.append({
        "title": "Lower your banking fees",
        "description": "Stop bleeding money on transfers.",
        "cta_text": "Open Zero-Fee Account"
    })

return offers

Why this matters:
This is the Adapter Pattern. Right now, the offers are hardcoded mocks. But the frontend doesn't know that. When I get approved for real Fintech Affiliate APIs, I will just swap out this Python function to fetch live data, and the React UI won't need a single line of code changed.

Decoupling your business logic from your UI is key! 🚀

How to stop your AI from hallucinating financial data 🛑🤖

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

Day 69 of my #100DaysOfCloud challenge! Today was all about QA testing my AI Prompts.

If you let a standard LLM loose on financial questions, it will eventually hallucinate fake statistics to sound smart. I wanted to see if the System Prompts I built for my AWS Bedrock agent would hold up.

I asked my agent to compare my food spending against the "national average for 28-year-olds".

The Response:
"You've spent €54.66 on McDonald's and Starbucks this month, but there's no reliable demographic average to compare it with because you're the only 28-year-old I've ever met who orders fast food 28 times a day."

Why this is an architectural win:
The AI correctly pulled the true data from my DynamoDB database (€54.66). However, because I strictly sandboxed its knowledge base to only my provided transaction context, it realized it had no demographic data. Instead of inventing a fake number, it defaulted to its "Tough Love" persona and mocked me.

Takeaway for builders:
When writing prompts for data-heavy apps, always give the AI an "exit route" (like sarcasm or a hard 'I don't know') for when it lacks data. A funny refusal is infinitely better than a confident lie.

I found a 1650% cost spike in my AWS Account

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

Day 68 of my #100DaysOfCloud challenge! I was short on time today, so I went to the console to do a quick 5-minute FinOps check.

I opened AWS Cost Anomaly Detection, expecting to set it up from scratch. Instead, I found out it had already caught a massive anomaly: a 1650% spike in my daily spend a few days ago!

Luckily, because I'm using Serverless free-tier services mostly, the spike only cost me $0.33. But the lesson is huge.

Why static budgets aren't enough:
If you set a budget for $10, AWS will only warn you when you hit $10. But if an infinite loop in your Lambda function causes a 2000% spike in executions, you want to know immediately, not 5 days later when it finally hits the $10 mark.

Cost Anomaly Detection uses Machine Learning to learn your normal pattern and warns you about the behavior, not just the total sum.

Action item for today:
Go to your AWS Billing Console, check Cost Anomaly Detection, and most importantly: click on Alert subscriptions to ensure it actually emails you when things go wrong! 🛡️

Day 67: Escaping the Sandbox. Wiring a Live Banking API to AWS Lambda

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

Today was the day my financial SaaS stopped being a toy. For Day 67, I replaced my simulated Plaid data with a live connection to the Wise API.

The Challenge:
Mock data is clean and predictable. Live data is messy. When I updated my Lambda orchestrator to pull real EUR transactions, I immediately hit issues with data duplication in my DynamoDB tables and aggressive caching from my React frontend.

The Debugging Process:
When the UI wouldn't update, I had to drop down to the browser console. I wrote a quick script to extract my JWT token from localStorage and fired a direct fetch request to my Lambda URL, appending ?sync=true to force a fresh pull from Wise.

Seeing that { "status": "success" } response and the array of 100 real transactions log into the console was the highlight of the week.

Next up: refining the multi-tenant routing so I can seamlessly switch between simulated demo users and live production accounts.