Learning in Public: How I Broke (and Fixed) My First Serverless AI Architecture

Hello AWS Community! 👋

As I wrap up my submission for the "Zero to Shipped" hackathon and continue studying for the AWS Certified AI Practitioner (AIF-C01) exam, I wanted to take a moment to reflect on the actual process of building DeepPR—my automated AI code review agent.

Recently, I read that "I broke it and here's what I learned" is one of the most valuable kinds of technical writing. The AWS Community Builder program team values people who learn in public, not those who appear perfect. So, instead of just sharing the polished final product, I want to share the messy details, the misconfigurations, and the debugging that got me here.

Here are three major ways I "broke" my architecture this month, and what the cloud taught me in response.

What I broke: When setting up my AWS Lambda function to process GitHub PR webhooks, I didn't properly handle the asynchronous acknowledgment. GitHub kept thinking the request timed out (because Claude 3 Haiku took a few seconds to generate the review), so it kept retrying the webhook. My Lambda function kept re-triggering, creating a massive spike in invocations.
The Fix: I learned to decouple the architecture. I used Amazon API Gateway to immediately return a 200 OK to GitHub, and then placed the payload into an Amazon SQS queue. A separate Lambda function then processed the queue asynchronously to call Amazon Bedrock.
The Lesson: Always decouple your webhook receivers from your slow-running AI inference tasks!

What I broke: I wrote my FastAPI backend, wrapped it with Mangum, and deployed it to Lambda. But every time it tried to invoke Claude 3 Haiku via Amazon Bedrock, it crashed with an AccessDenied error. I assumed that because I was the root account owner, my Lambda function automatically had permissions.
The Fix: When you build, you can't hide behind abstractions forever. The cloud will politely (and repeatedly) demand evidence. I had to dive into IAM (Identity and Access Management) and explicitly attach the bedrock:InvokeModel policy to my Lambda's execution role.
The Lesson: The principle of least privilege is real. Services in AWS cannot talk to each other unless you explicitly grant them permission.

What I broke: Coming from a PostgreSQL background, I designed my Amazon DynamoDB tables like relational tables—one for Users, one for Repositories, and one for PRs. When I tried to query all PRs for a specific user, I ended up doing multiple expensive Scan operations instead of efficient Query operations.
The Fix: I had to unlearn my SQL habits. I researched "Single-Table Design" and restructured my DynamoDB setup using a combined Partition Key (PK) and Sort Key (SK) strategy.
The Lesson: You cannot force relational logic onto a NoSQL database. Understand your access patterns before you design your DynamoDB table.

Writing about what you tried, what failed, and what worked is incredibly rewarding. It forces you to document your understanding, not just showcase expertise.

For the experienced builders out there: What was the most memorable thing you broke when you first started using AWS, and what did it teach you? Share your battle scars in the comments below! Let's keep learning in public.