Kendra & Amazon Q

Kendra vs. Knowledge Base advanced

Here's the mistake that costs a team three sprints. Someone is asked to "let employees ask questions over our internal docs," and — because they just finished the Knowledge Base chapter (W4) — they reach for a Bedrock Knowledge Base. They stand up a vector store, write an ingestion job, then discover the docs live in SharePoint and Confluence and ServiceNow, each behind its own permissions. Now they're writing connectors and re-implementing access control by hand — rebuilding, badly, a product AWS already sells. The lesson isn't "KBs are bad." It's that two services that both "search your documents" solve completely different jobs, and picking the wrong one means building the other one yourself.

Think of it as the difference between a library card catalog and a research assistant you're hiring and training. Amazon Kendra is the catalog: a managed enterprise search service you point at your existing systems. Its whole value is breadth and turnkey plumbing — 40+ connectors (SharePoint, S3, Confluence, ServiceNow, and more) that crawl those sources on a schedule, natural-language ranking so "how do I request prod access?" beats keyword matching, and — crucially — access control that respects who's allowed to see each document. You query Kendra; you don't build it. A Bedrock Knowledge Base is the assistant you're assembling: a vector store you own, that you wire into your own RAG generation loop, where you control the chunking, the embeddings, the prompt, and the model.

So the deciding question is not "which is better search?" — it's "am I buying search, or building a RAG application?" If the value is finding answers scattered across many enterprise systems, and you'd rather not own the ingestion/ACL machinery, that's Kendra. If the value is a custom RAG app where you need to shape retrieval and generation to your product, that's a Knowledge Base. The common trap is treating this as a capability comparison when it's really a build-vs-buy decision — and the two aren't even mutually exclusive: because Kendra is such a strong retriever, you can use it as the retrieval step and feed its ranked passages to Claude for generation. That hybrid is the best of both, and it's exactly what the lab and exercises below build toward.

Query Kendra advanced

The first time you call Kendra, you'll expect a paragraph of answer and get a list of documents instead — and that surprise is the whole point. People who've only used chatbots assume every "ask a question" API hands back generated prose. Kendra doesn't. Ask it "how do I request production access?" and it returns ranked source documents with titles and matching excerpts — no invented sentences, no hallucinations, just the real passages that best answer you. If you were expecting a written reply, that feels underwhelming; once you understand why, it feels like a feature. Kendra is a retriever, not a generator, and keeping those two jobs separate is what lets you trust the results.

Picture the "very good internal Google" your company never built. You type a plain-English question; behind the scenes Kendra has already crawled your connected sources, indexed them into an index (identified by an IndexId), and now ranks every stored passage against your query — best-first, using natural-language understanding rather than raw keyword overlap. The call itself is deliberately small: you hand query() two things, the index to search and the QueryText, and it returns a dictionary whose ResultItems list is already sorted from most to least relevant. Each item carries a DocumentTitle and a DocumentExcerpt — the snippet of matching text — so you can show a human where the answer lives, not just what it might be.

The one habit worth forming early is defensive field access. Those nested fields (DocumentTitle.Text, DocumentExcerpt.Text) aren't guaranteed to be present on every hit, and reaching into a missing key throws an error that kills your loop mid-results. The fix you'll see in the lab is item.get("DocumentTitle", {}).get("Text", "") — ask for the field, but fall back to an empty default if it's absent, so one odd document can't crash the whole response. This is a small thing that separates a demo from something you'd run against a live index. And keep the mental model sharp: Kendra finds and ranks; it does not write. The moment you want a synthesized, cited answer, you take these top excerpts and pass them to a generation model like Claude — Kendra supplies the sources, the model supplies the wording. That separation is exactly the RAG-by-hand pattern the exercises build.

kendra_query.pyimport boto3
kendra = boto3.client("kendra", region_name="us-east-1")

resp = kendra.query(
    IndexId="index-abc123",
    QueryText="how do I request production access?",
)
for item in resp["ResultItems"][:3]:
    title = item.get("DocumentTitle", {}).get("Text", "")
    excerpt = item.get("DocumentExcerpt", {}).get("Text", "")
    print(f"- {title}: {excerpt[:80]}")

Amazon Q expert

Imagine leadership wants an internal help-desk assistant live in two weeks. You could build one from parts — wire Kendra to Claude, add auth, host a UI, handle retrieval and citations yourself — and in two weeks you'd have a fragile demo and a burned-out team. Or you could ask a different question: has AWS already built this? For a large class of "assistant over our stuff" and "AWS-aware coding help" needs, the answer is yes, and it's called Amazon Q. Reaching for Q instead of assembling the same thing by hand is often the difference between shipping and slipping — which is why this section sits at the far buy end of everything you've learned.

The key reframe: with Q, you configure, you don't build. It comes in two flavors aimed at two different audiences. Q Developer is a coding assistant that lives in your IDE and CLI, and its differentiator is that it's AWS-aware — it knows about your resources, IAM, and AWS APIs in a way a generic autocomplete doesn't; it sits in the same family as the tools you met in AI-Assisted Development. Q Business is the managed assistant over your connected company data: you point it at your sources and AWS handles the retrieval, the security and access control, and the chat UI. The parts you'd otherwise sweat over — ingestion, ACLs, a front end — come in the box.

Here's the way to hold the whole chapter in one line: it's a build-vs-buy spectrum, and every service you've seen has a place on it. At the far buy end sit Q Developer and Q Business — fastest to value, least control, someone else owns the plumbing. In the middle is Kendra — managed search you query but still assemble around. At the far build end is a Bedrock Agent (W5) — full control over tools and the reasoning loop, but you wire and maintain all of it. Neither end is "right"; the skill an interviewer is probing for is knowing which end a given problem wants. Zero code, tight deadline, "over our existing systems"? That's the buy end, almost always Q. Need custom actions, bespoke tools, or control over every hop? Now you've earned the extra work of building. The most senior answer is frequently phased: buy Q to go live fast, then migrate only the hot paths that genuinely need custom control to a Bedrock Agent later — you'll encode exactly that decision in the practice ladder.

import boto3

kendra = boto3.client("kendra", region_name="us-east-1")
resp = kendra.query(
    IndexId="index-abc123",
    QueryText="how do I request production access?",
)
for item in resp["ResultItems"]:
    title = item.get("DocumentTitle", {}).get("Text", "")
    excerpt = item.get("DocumentExcerpt", {}).get("Text", "")
    print(title, "::", excerpt[:60])

def search_choice(need_many_connectors, building_rag_app):
    if building_rag_app and not need_many_connectors:
        return "bedrock-knowledge-base"   # you own the RAG generation
    if need_many_connectors:
        return "kendra"                    # search across SharePoint/S3/etc.
    return "kendra"

print(search_choice(True,  False))   # kendra
print(search_choice(False, True))    # bedrock-knowledge-base

import boto3

kendra = boto3.client("kendra", region_name="us-east-1")
brt = boto3.client("bedrock-runtime", region_name="us-east-1")

q = "What is the on-call escalation path?"
hits = kendra.query(IndexId="index-abc123", QueryText=q)["ResultItems"]
context = "\n---\n".join(h.get("DocumentExcerpt", {}).get("Text", "")
                          for h in hits[:3])
prompt = f"Context:\n{context}\n\nQuestion: {q}\nAnswer from context only."
r = brt.converse(modelId="anthropic.claude-3-5-sonnet-20241022-v2:0",
    messages=[{"role":"user","content":[{"text": prompt}]}])
print(r["output"]["message"]["content"][0]["text"])

SPECTRUM = {
    "q-business":    ("buy",  "managed assistant over connected company data"),
    "q-developer":   ("buy",  "AWS-aware coding assistant in the IDE/CLI"),
    "kendra":        ("mid",  "managed enterprise search you query"),
    "bedrock-agent": ("build","full control, you wire tools + loop"),
}

def recommend(zero_code, over_connectors):
    if zero_code and over_connectors:
        return "q-business"
    return "bedrock-agent"

print(recommend(True, True))   # q-business
print(SPECTRUM["q-business"])

ORDER = {"VERY_HIGH": 4, "HIGH": 3, "MEDIUM": 2, "LOW": 1}

def strong_hits(items, min_conf="HIGH"):
    floor = ORDER[min_conf]
    out = []
    for it in items:
        conf = it.get("ScoreAttributes", {}).get("ScoreConfidence", "LOW")
        if ORDER.get(conf, 0) >= floor:
            out.append(it)
    return out

items = [{"ScoreAttributes": {"ScoreConfidence": "VERY_HIGH"}},
         {"ScoreAttributes": {"ScoreConfidence": "LOW"}}]
print(len(strong_hits(items)))   # 1

def plan(deadline_weeks, need_custom_actions_now):
    phase1 = "q-business"    # connectors + zero code -> live fast
    phase2 = "bedrock-agent" if need_custom_actions_now else "revisit later"
    fast = deadline_weeks <= 3
    return {"phase1": phase1 if fast else "bedrock-agent",
            "phase2": phase2}

print(plan(2, need_custom_actions_now=False))
# phase1 q-business (2 wks, connectors, no code);
# phase2 revisit later -> migrate hot paths to a Bedrock Agent when custom
# actions are needed. Buy first for speed, build later for control.

Knowledge check check yourself