Study log: standing up RAG on AWS Bedrock in an afternoon

Part of interview prep. I had a technical interview coming up with a cloud partner whose work centers on Amazon Bedrock and agentic RAG, so I decided the best prep wasn't reading about their stack, it was building on it. Get familiar with the workflow and the concepts by actually doing the thing.

Why I did this

The company builds retrieval systems for clients on Bedrock: internal knowledge bases with RAG on top, custom UIs, agent workflows. Rather than walk in able to talk about RAG, I wanted to walk in having built one on their exact stack. So I set myself a small, real task: a question-answering system over a set of SEC filings.

What I built

A Bedrock Knowledge Base over a handful of Tesla filings (a 10-K and several 10-Qs, cleaned into per-section and per-quarter markdown). The pipeline: documents in S3, Bedrock chunks and embeds them into a managed vector store, and a query gets embedded, matched against the chunks, and answered by a model, grounded in the source with citations. I asked it single-document questions ("what are the main risk factors"), cross-period questions ("how did revenue change from Q1 2024 to Q1 2025"), and out-of-scope questions to check it declines instead of making things up. It handled all three.

What I learned

• Setup is genuinely simple. With default options, a working Knowledge Base is a short sequence: point it at an S3 bucket, let it pick a managed embedding model, sync, test. The managed path hides most of the machinery.
• It works well on the embedded documents, out of the box. Default chunking and the managed vector store gave clean, cited answers with no tuning. For cross-period questions it correctly pulled from different filings and compared them.
• The hard part isn't the model, it's the data. My first instinct was to feed it the raw filing HTML. It's 2.6 MB of XBRL-heavy markup that chunks badly. Cleaning it into small, well-labeled documents is what made retrieval sharp. And when I saw duplicate chunks come back, the cause wasn't the model, it was duplicate documents in my corpus. Retrieval quality kept turning out to be a data-quality problem, which matches everything else I've worked on.
• The console is for testing; the API is for production. The same Knowledge Base is callable from code, which is how a real app would use it. From there the path is clear: wrap the API in a service or a custom UI, or hand it to an agent as a tool, and add guardrails and evaluation.
• Region and data residency are real design choices. The Knowledge Base, its vector store, and the S3 source all have to sit in the same region (I learned this by hitting the error). And if a client's data legally can't leave their environment, the managed service isn't the fit, you self-host the vector store and RAG near the data.

Where I landed

I now have a solid, hands-on understanding of how to use Bedrock for RAG: what each piece does, how it goes to production, what it costs, and when to reach for a self-hosted stack instead. It took an afternoon to go from never having opened Bedrock to a working, cited, multi-document Q&A system I can explain end to end. That felt like the right way to prepare, learn the tool by building the thing they build.