DEV Community: Martín Rivadavia

I Spent ~$363 in Two Days on Bedrock — Cheap Lesson or Expensive One?

Martín Rivadavia — Tue, 24 Mar 2026 16:48:50 +0000

The pricing page told me embeddings were "per thousand tokens." The bill told me what that actually means when you sync a corpus more than once while you are still learning.

This is the story of a two-day spike on my AWS account — mostly Amazon Bedrock — and what I took away from it. Spoiler: I do not think it was only money down the drain.

The receipt (literally)

I pulled up Cost Explorer after a weekend of experiments. Two consecutive days in December looked like this:

Roughly:

	Total (two days)
All services (shown)	~$363
Amazon Bedrock	~$353
Amazon OpenSearch Service	~$7

Most of that was not me chatting with Claude in the playground. It was Knowledge Base work: pointing Bedrock at data in S3, running ingestion / sync jobs, and re-running them while I changed chunking, parsers, and paths — before I had a clear picture of how embedding tokens accumulate across retries.

I had expected "some cost." I had not internalized how fast repeat syncs turn into repeat embeddings for the same underlying text.

What I thought I was doing

I was building a RAG-style pipeline over technical PDFs: extract text, get it into a Bedrock Knowledge Base, run retrieval, and eventually wire that into an application.

That sounds linear. In practice my early loop looked more like:

Upload or point at objects in S3.
Start a sync.
Notice something wrong — layout, chunk boundaries, metadata, or retrieval quality.
Change the preprocessing, upload again, sync again.
Repeat step 4 until I understood what "good" looked like.

Every pass felt like "fixing configuration." In billing terms, many passes looked like new embedding work. The console does not always feel like spending money; Cost Explorer does.

What the invoice taught me (that the docs had not fully sunk in yet)

GenAI on AWS is not one line item. For Knowledge Bases, the mental model that finally stuck:

Ingestion / embedding is where large PDFs hurt — you pay for tokens processed into the vector store, not for "having a PDF on disk."
Retrieval and downstream model calls are additional meters. Separating "sync cost" from "query cost" matters when you debug.
Re-syncing the same corpus while you tune chunking is not a free redo. You are often paying for another full pass over the same content unless you have designed for incremental or diff-aware updates.

None of that is a secret — it is all in the documentation. The bill was the tutorial that actually stuck.

¿Lección cara o barata?

If you judge only by the number on the screen, it was an expensive lesson.

If you judge by what I would pay for the same misunderstanding in production, under deadline, with a team and customer trust on the line — learning it on my own lab account starts to look cheap. I paid once in dollars and once in humility. I would rather do that before I ever optimize someone else's budget.

So my answer: it was both. Painful in the moment, valuable in context — and only "wasteful" if I pretended nothing needed to change afterward.

What I changed in how I build

1. Measure before sync.

I stopped treating "upload and sync" as the first step. I added local steps: approximate token counts, preview chunk boundaries, and sanity-check file sizes before triggering another full ingestion. That mindset is documented in Lab 02: KB Ingestion — Foundations First in the learning-journey repo — small CLI helpers, no cloud required for the first pass.

2. Separate "pipeline quality" from "vector store plumbing."

I invested in a clearer PDF → clean text → intentional chunks → S3 path in aws-pdf-rag-mr — the companion repo with the full pipeline code (Terraform, Lambda processor, Bedrock KB, S3 Vectors) that matches what Lab 02 points you toward after the foundations. That way Bedrock sees stable, deliberate chunks instead of whatever the default path produced on raw PDFs while I was still iterating.

3. Use the cloud bill as a design review.

Billing alerts and Cost Explorer by service are now part of my definition of done for experiments, not something I check when I get curious.

If you are about to do the same experiment

Start with tiny files — one short text, one sync, one retrieve — until the numbers make sense.
Read embedding and KB pricing as token math, then estimate tokens × price × number of sync attempts.
Treat re-sync as a budget line, not a config tweak.
Document decisions (I use ADRs) so the next you does not repeat the same loop "just one more time."

Closing

I did not write this to scare anyone away from Bedrock or Knowledge Bases. I still use them. I write it because the messy middle — including an invoice that made me stare at the screen — is part of learning in public honestly.

Documentation is not overhead. It is thinking made visible. So is a cost breakdown when it forces you to redraw your architecture.

If this story saved you one accidental full re-embedding of a giant PDF, it was worth more than those two days of spend.

Repos:

aws-genai-cert-learning-journey — learning path, ADRs, and Lab 02 docs (labs/lab-02-kb-ingestion-basics/).
aws-pdf-rag-mr — implementation code for the PDF → KB pipeline (the “after Lab 02” stack).

Tags I'll use when I share: #BuildToLearn #AWSGenAI #AmazonBedrock #LearnInPublic #RAG

Have you had a GenAI bill that taught you something the docs alone did not? I would genuinely like to hear what changed in your process afterward.

The Exam That Felt Like a Project Backlog: Passing AWS Certified Generative AI Developer – Professional

Martín Rivadavia — Thu, 12 Mar 2026 18:05:35 +0000

This is part of my Build-to-Learn with AWS GenAI series — where I share the messy middle of building production-grade GenAI systems on AWS, including the wrong turns.

Question 67. Beta exam. Eighty-five total questions. I almost lost it right there.

Not my composure, exactly — more like my thread. The kind of focused engagement you need to hold through a complex orchestration scenario when your cognitive reserves have been running for two-plus hours. For a moment, I felt the concentration starting to slip. And then something unexpected happened instead: my brain stopped trying to answer the question and started designing it. What if the routing layer worked this way? What if I extended this to handle the insurance claim pipeline I built? I caught myself, selected the answer, and kept moving. But the moment stayed with me.

That involuntary drift wasn't a lapse in focus. It was evidence. Evidence that the way I'd prepared had taken root at the right level — not as recall, but as judgment. I almost lost my thread at question 67. What I found instead was proof that months of building had encoded something harder to shake than concentration. And at the Professional tier, that kind of judgment is the only thing being tested.

I'd spent months preparing for this exam. More accurately: I'd spent months building, and the exam happened to follow.

AWS Certified Generative AI Developer – Professional · Early Adopter

Why This Certification, Why Now

The AWS Certified Generative AI Developer – Professional is new enough that when I signed up, there were no public pass rates to anchor expectations. No community wisdom about which topics showed up most. No data on what the difficulty curve felt like. I was taking it as a Beta, which meant I was part of the cohort helping AWS calibrate the exam itself — and it meant 85 questions instead of the standard 75.

That extra 10 is not trivial. By question 75 on an exam of this depth, your cognitive reserves have been running for hours. The later questions tend to be the more architecturally complex ones — multi-service integrations, guardrail trade-offs, agent orchestration patterns that require you to hold several moving parts in your head simultaneously. Adding 10 questions at the back end is a meaningful stamina tax, not just a scheduling footnote.

I signed up anyway, because it was the right next step in this series. If I'm building production GenAI systems on AWS and documenting every decision publicly, the Professional certification closes the loop. It says: I understand this domain deeply enough to reason through novel scenarios I've never seen before — not just reproduce patterns from documentation I've read.

There was a bonus I didn't know about when I registered: Beta cohort participants who pass receive an Early Adopter badge from AWS — a second credential recognizing that you helped define the exam itself. I didn't sign up for that badge. I signed up because the exam was there and the timing was right. But it's an accurate description of what taking a Beta actually means: you go in without a map, and if you make it through, you helped draw the map for everyone who comes after.

What I didn't fully appreciate until exam day was how much the work I'd already done would matter.

Starting With Skill Builder (And Why I Pivoted)

My first instinct was AWS Skill Builder. Official source. Authoritative. Comprehensive. The right instinct in principle.

Here's what I didn't anticipate: the material is genuinely good, and it is genuinely heavy. Skill Builder covers the conceptual foundations of foundation models, the architecture of Amazon Bedrock, the nuances of RAG pipelines, evaluation frameworks, responsible AI — all of it with the depth you'd expect from the people who built the services. For someone building their knowledge base from scratch, it's excellent. For someone who's already been building with these services and needs to sharpen scenario reasoning, reading through it sequentially felt like re-reading a reference manual.

I didn't abandon it. I still used Skill Builder as a reference layer — when a practice exam question surfaced a concept I couldn't fully explain, I went back to Skill Builder for the deep read. But it stopped being my primary study method about a month in, and I switched to two Udemy courses that fit how I actually learn.

The first — Ultimate AWS Certified Generative AI Developer Professional — gave me a more accessible conceptual ramp. Good structure, practical framing, the kind of explanations that build a mental model you can reason with rather than recall from. The second — Practice Exams AWS Certified Generative AI Developer Pro — I treated as a diagnostic tool rather than a score-chaser. Every wrong answer was a prompt for genuine investigation: not "why was I wrong" but "what would I build differently, and why?"

The combination worked. But neither was the real differentiator.

The Thing That Actually Mattered

In my previous article, I wrote about how a near-disaster — an infinite loop that would have cost thousands in AWS bills — crystallized the Build-to-Learn Framework. The lab that came out of that experience was Lab 01: an automated insurance claim document processing pipeline built on Amazon Bedrock, Lambda, and S3.

I built that lab months before finishing my certification prep. On purpose. That decision came with a risk I documented explicitly at the time:

ADR-002: Build Lab 01 Before Completing Certification Prep

Status: Accepted

Context:
  Conventional wisdom says finish studying before building.
  The Build-to-Learn thesis says building is the studying.
  Taking the Professional exam before completing all formal modules
  means entering with gaps in coverage.

Decision:
  Build Lab 01 now. Ship it. Write the ADR. Then return to formal study.

Rationale:
  Professional-level exams test scenario reasoning, not recall.
  Reasoning is built through decisions with real consequences.
  A production-adjacent lab creates those consequences in a way
  no module can replicate.

Consequences:
  - Risk: Formal knowledge gaps may surface on exam
  - Benefit: Implementation judgment built before exam; scenarios will feel familiar
  - Accepted tradeoff: depth of experience > breadth of coverage

The consequences played out exactly as written. There were moments on the exam where I wished I'd read one more Skill Builder module. There were far more moments where I recognized a pattern because I'd lived it.

The Build-to-Learn thesis is that building real systems before the exam encodes judgment, not just knowledge. And Professional-level exams don't test knowledge — they test judgment. They present scenarios you've never seen before and ask you to reason about what the right architecture would be, given a specific set of constraints and trade-offs. That kind of reasoning doesn't come from reading. It comes from having been in the situation.

When a question presented a multi-agent orchestration scenario, I recognized the architectural patterns because I'd designed one. When a question asked about guardrail configuration trade-offs, I'd made those decisions in code and felt the consequences. When a question surfaced the cost implications of different model invocation strategies, I'd worried about that in production. The hours spent debugging Lambda triggers, writing Architecture Decision Records, and arguing with IAM policies translated directly into the ability to reason through novel scenarios under pressure.

That's not a coincidence. That's the Framework, working.

What the Beta Exam Actually Feels Like

No study guide can prepare you for question 75 on an 85-question exam.

The experience is layered. The first 30 questions feel manageable — you're fresh, the cognitive load is still within capacity, and the scenarios are challenging but readable. By question 50, you're aware that you've been concentrating hard for a while. By question 70, your brain is doing something slightly different than it was at the start: it's working harder for the same output.

The Beta format adds its own texture. There's no score at the end. You complete the exam, submit, and walk out not knowing. AWS collects results from the Beta cohort, calibrates the difficulty model against how candidates performed, and notifies you later. The wait is a specific kind of uncomfortable — you can't iterate on what you don't know, so you just wait.

What I didn't expect was the moment at question 67 where my brain started drifting toward building rather than answering. It felt, in that moment, like distraction. In retrospect, it was a signal. The exam scenarios are written by people who think about these services the way builders think — as implementation decisions, not as trivia. When you've built with these tools, you speak the same language as the people writing the questions. The exam stops feeling like a test and starts feeling like a design discussion.

I passed. The score came through later, along with something I hadn't expected: an Early Adopter badge from AWS, issued to the Beta cohort who helped define the exam before it was publicly available. I didn't sign up for that badge — I signed up for the challenge. But it's a fitting symbol. Being early meant no benchmarks, no pass-rate data, no community notes to fall back on. It meant the only preparation that counted was the preparation you'd actually done.

The pass was less surprising than that moment at question 67 — because by then, the Framework had already proved its point. The Early Adopter badge just confirmed which cohort had been there first.

The Study Stack, Honestly Ranked

If you're preparing for this certification, here's what I'd actually recommend:

1. Build Something First

Not a tutorial. Not a sandbox. A real system with real architecture decisions, real trade-offs, and documentation that forces you to articulate why you made each choice. Write ADRs. Deploy it. Break it. Fix it. The judgment you build doing this is the single most transferable skill for a Professional-level exam.

2. Udemy Practice Exams — Scenario Reasoning Engine

Practice Exams AWS Certified Generative AI Developer Pro — Use these to find your gaps, then investigate the gaps with genuine curiosity. The questions are scenario-based at the right level of complexity. Don't chase scores. Chase understanding.

3. Udemy Course — Conceptual Architecture

Ultimate AWS Certified Generative AI Developer Professional — Good for building the mental model. More accessible than Skill Builder for daily study. Use it to cover the conceptual landscape before stress-testing it with practice exams.

4. AWS Skill Builder — Reference Layer

skillbuilder.aws — Use it for depth, not breadth. When something comes up in practice exams that you can't fully explain, this is where you go for the authoritative version. Don't try to read it front to back unless that's genuinely how you learn — treat it as a reference library.

What This Certification Actually Means

The certification isn't the story. The certification is the receipt.

What the receipt is for: months of building real systems, making architecture decisions with real stakes, documenting wrong turns, and learning in public. The exam measured the output of that process. It didn't create it.

I've said before that certifications are starting points, not destinations. Passing the Professional tier for GenAI development confirms that the domain knowledge is there — but it also clarifies what the next layer of questions looks like. The questions my brain was designing during the exam aren't going away. They're the next labs.

Build. Document. Share. Repeat.

What's Next

The GitHub repo for this series lives at github.com/rivadaviam/aws-genai-cert-learning-journey. Lab 01 is there with full code, architecture diagrams, and ADRs.

If you're preparing for this certification:

Low commitment: Star the repo and follow along as I build the next lab
Medium commitment: Try building your own version of Lab 01 before your exam. Document one decision with an ADR.
High commitment: Share what you build publicly. The accountability changes everything.

The messy middle is where learning lives. Welcome to it.

Have you taken this certification? What surprised you most about the exam? Drop it in the comments — I'd genuinely like to know.

BuildToLearn #AWSCommunity #LearnInPublic #AmazonBedrock

The Build-to-Learn Framework: How a Near-Disaster Taught Me to Learn in Public

Martín Rivadavia — Wed, 04 Feb 2026 22:20:47 +0000

I almost created an infinite loop that would have cost me thousands in AWS bills.

And I'm grateful it almost happened.

The Setup

When I decided to pursue the AWS Certified Generative AI Developer certification, I made myself a promise: I wouldn't just study for an exam. I would build real systems, make real mistakes, and share everything publicly—including the wrong turns.

The AWS Skill Builder course has these "Bonus Assignments" scattered throughout. Most people skip them or treat them as quick checkboxes.

I saw something different: each one was an invitation to build something production-ready.

My first assignment: an automated insurance claim processing pipeline using Amazon Bedrock.

User uploads to S3 → Lambda orchestrates 3-step Bedrock pipeline → Results saved to output bucket

The Near-Disaster

My initial architecture was elegant. One S3 bucket, two prefixes:

/input for uploaded documents
/output for processed results

Clean. Simple. Catastrophic.

Here's what happens with that design:

1. Document lands in /input
2. Lambda triggers, processes document
3. Result written to /output (same bucket)
4. S3 event triggers Lambda again
5. Lambda processes the output file...
6. → Infinite loop. Infinite cost.

I caught this because I was writing an Architecture Decision Record—ADR-002—explaining my bucket strategy.

The act of documenting forced me to think through the consequences. Mid-sentence, I realized what would happen in production.

# ADR-002: Separate S3 Buckets for Input and Output

## Decision
Use separate S3 buckets for input and output

## Consequences
- Prevents infinite loop scenarios
- Better security isolation
- Different lifecycle policies per bucket
- Slight increase in bucket management complexity

## Why This Choice
Following AWS best practices prevents production issues.
The slight complexity increase is worth avoiding infinite loops.

That ADR saved me real money. But more importantly, it taught me something:

Documentation isn't overhead. It's thinking made visible.

The Build-to-Learn Framework

That near-miss crystallized into a methodology I now follow for every lab: build real things, document every decision, and share the messy middle.

Not tutorials. Not sandboxes. Production-grade systems with real constraints — the kind where a wrong architecture choice costs actual money. For every significant decision, I write an Architecture Decision Record capturing the why, not just the what. And when I share the work, I don't polish away the wrong turns. The trade-offs, the moments of doubt, the diagrams I scrapped at midnight — those are the parts that actually help someone else learn.

The Implementation

Instead of one monolithic prompt, I designed a three-step AI pipeline where each step uses the optimal model:

Step	Model	Why
Document Understanding	Claude 3.5 Sonnet	Complex reasoning needed
Information Extraction	Claude 3.5 Sonnet	Precision for structured JSON
Summary Generation	Claude 3 Haiku	Cost-efficient for simple output

Step 1: Document Understanding

def process_document_understanding(document_text, model_id, template_manager):
    """Analyze and understand the document structure and content."""
    prompt = template_manager.get_prompt(
        "document_understanding",
        document_text=document_text
    )

    return invoke_bedrock_model(
        model_id,
        prompt,
        temperature=0.1,  # Low temperature for accuracy
        max_tokens=2000
    )

Why this step? Complex documents need context before extraction. Understanding the document type (auto claim vs. health expense) improves downstream accuracy.

Step 2: Information Extraction

def extract_information(document_text, model_id, template_manager):
    """Extract structured information from the document."""
    prompt = template_manager.get_prompt(
        "extract_info",
        document_text=document_text
    )

    result = invoke_bedrock_model(
        model_id,
        prompt,
        temperature=0.0,  # Zero temperature for deterministic output
        max_tokens=1500
    )
    return result

Key insight: Using temperature=0.0 ensures consistent, deterministic extraction. This matters when downstream systems depend on specific JSON fields.

Step 3: Summary Generation

def generate_summary(extracted_info, model_id, template_manager):
    """Generate a concise summary of the claim."""
    prompt = template_manager.get_prompt(
        "generate_summary",
        extracted_info=extracted_info
    )

    return invoke_bedrock_model(
        model_id,
        prompt,
        temperature=0.7,  # Higher temperature for natural language
        max_tokens=500
    )

Why Haiku here? The heavy lifting is done. We're just formatting extracted data into prose. Claude 3 Haiku does this well at ~10x lower cost than Sonnet.

This decision is captured in ADR-005:

# ADR-005: Use Claude 3 Haiku for Summary Generation

## Decision
Use Claude 3 Haiku for summary generation (not Sonnet)

## Rationale
- Summaries are the final step - context is already extracted
- Haiku is ~10x cheaper than Sonnet
- Quality is sufficient for 2-3 sentence summaries
- Maintains on-demand throughput support

## Trade-off
Slight quality reduction for significant cost savings

Model Selection: The Certification Question

If you're preparing for AIP-C01, model selection is a core exam topic — and this project gave me a real-world taste of the trade-offs involved.

One decision surprised me. Claude 3.5 Sonnet v2 is newer and, on paper, "better" than v1. But when I dug into availability, I discovered that on-demand throughput isn't guaranteed in all regions and might require Provisioned Throughput. For a learning project that other developers will clone and deploy in their own accounts, availability matters more than marginal quality improvements. So I chose v1 — a stable, widely available model that anyone can spin up without provisioning headaches. It was a small decision, but exactly the kind of reasoning the certification expects you to articulate.

The Infrastructure

The entire stack is defined in Terraform, which means anyone can deploy it with a single terraform apply. Here's the Lambda at the heart of it:

resource "aws_lambda_function" "processor" {
  function_name = "${var.project_name}-processor"
  runtime       = "python3.12"
  handler       = "lambda_handler.handler"
  timeout       = 300   # 5 minutes
  memory_size   = 512   # MB

  environment {
    variables = {
      OUTPUT_BUCKET               = aws_s3_bucket.output.id
      BEDROCK_MODEL_UNDERSTANDING = "anthropic.claude-3-5-sonnet-20240620-v1:0"
      BEDROCK_MODEL_EXTRACTION    = "anthropic.claude-3-5-sonnet-20240620-v1:0"
      BEDROCK_MODEL_SUMMARY       = "anthropic.claude-3-haiku-20240307-v1:0"
    }
  }
}

The numbers tell a story. A typical run — three sequential Bedrock calls — takes 30 to 90 seconds, but I set the timeout to 5 minutes to absorb cold starts, larger documents, and network latency. Memory sits at 512 MB: enough headroom for boto3 and JSON processing without overpaying for capacity the function will never touch. Both values came from testing, not guessing — another benefit of building before theorizing.

What I Learned (Beyond the Tech)

The biggest surprise wasn't technical — it was how much the act of writing things down changed my engineering decisions. ADRs forced me to justify every choice, and several times I reversed course mid-sentence because explaining a decision out loud revealed the flaw in it. Documentation isn't a chore you do after the code works; it's a design tool you use while the code is still taking shape.

Building locally first saved me real money, too. The system supports running the full pipeline on your own machine (python main.py --input claim.txt --output result.json), so I processed dozens of test documents before a single Lambda invocation or Bedrock API call ever hit my AWS bill.

And here's what connected everything back to the certification: every core topic from the Skill Builder course — model selection criteria, prompt engineering, cost optimization, security best practices, serverless patterns — showed up organically in this one project. I didn't have to memorize them. I had to use them, and that made them stick.

What's Next

This is just the beginning. I'm continuing to build through the AWS GenAI certification curriculum, turning each challenge into a production-ready implementation. More labs are coming — each one following the same Build-to-Learn principles: production-ready code you can actually deploy, every decision documented with ADRs, and the messy middle shared so you learn from my mistakes too.

Want to follow along? Star the repo or connect with me on LinkedIn to get notified when the next lab drops.

Try It Yourself

The entire project is open source. Clone it, read the ADRs, poke around the Terraform — and if you find a flaw in my implementation, open an issue. If you have a better approach, propose it.

rivadaviam / aws-genai-cert-learning-journey

Public learning journey for the AWS Generative AI Certification. Hands-on labs, bonus assignments, and real-world experiments designed to help others learn and build with AWS GenAI services.

AWS Generative AI Learning Journey

Learn in public, build in production. This repository is a hands-on journey through AWS Generative AI services, focusing on Amazon Bedrock and real-world use cases. Each lab is production-ready, well-documented, and designed to teach you not just what to build, but why we made these choices.

Why This Journey Exists

Generative AI is transforming how we build applications, but learning it can feel overwhelming. This repository breaks down complex AWS AI services into practical, reproducible labs. You'll build real systems, understand architectural trade-offs, and learn from decisions documented in Architecture Decision Records (ADRs).

What makes this different:

✅ Production-ready code - Not just demos, but real implementations
✅ Decision transparency - Every architectural choice is documented with rationale
✅ Learn from mistakes - We share what worked, what didn't, and why
✅ Community-first - Built to help others learn and contribute

Certification Context

This repository…

View on GitHub

# Clone and explore
git clone https://github.com/rivadaviam/aws-genai-cert-learning-journey.git
cd labs/lab-01-claims-doc-processing

# Read the full guide
cat README.md

# Deploy with Terraform
cd infra/terraform
terraform init && terraform apply

The Invitation

If you're preparing for a certification, don't just study. Build something real. Document your decisions. Share your journey. And if you build something using this framework, tell me about it — I want to see what you create.

Certifications prove you can learn.
Projects prove you can build.
Documentation proves you can teach.

The Build-to-Learn Framework asks: why not do all three?

Have questions? Connect with me on LinkedIn or drop a comment below.

Build. Document. Share. Repeat.

#BuildToLearn #AWSCommunity #LearnInPublic