The Lambda you no longer have to write
Earlier in this series, giving an agent access to a knowledge base meant writing a Lambda that wraps bedrock:Retrieve, registering that Lambda as an AgentCore Gateway target, and letting the agent call it as an MCP tool. It worked. The Lambda was pure glue — it existed only to translate an MCP tool call into a Bedrock retrieval API call and translate the response back. You owned its code, its IAM role, its deployment, its cold starts, and its bugs, for a function that did nothing but forward a query.
AgentCore now has a native bedrock-knowledge-bases connector. You attach a Bedrock Knowledge Base directly to a Gateway as a managed-connector target, and the Gateway exposes the retrieval tools over MCP with no Lambda in the path. I replaced the wrapper with the connector, probed it over MCP, and found the one constraint that decides whether you can use it at all.
What the connector exposes
I attached a Knowledge Base to an existing Gateway as a bedrock-knowledge-bases connector target, then ran a SigV4-signed MCP tools/list against the Gateway. Two tools came back, auto-discovered, with no schema I had to write:
Retrieve— “Search the managed knowledge base for relevant source passages.” A single hybrid search returning the most relevant passages (1–100, defaulting to 10). This is the direct analogue of what my old Lambda wrapped.AgenticRetrieveStream— the interesting one. Per AWS’s docs it “plans a retrieval strategy, runs multiple retrieval steps across your managed knowledge bases, optionally expands to full documents, and streams back both the supporting results and a synthesized, citation-backed answer.” It takes a conversation (query + history), not just a string, and does multi-step retrieval with planning rather than a single lookup.
That second tool is a real capability jump. The Lambda wrapper only ever did single-shot retrieval, because writing a planning-and-multi-step-retrieval loop into a glue Lambda would have been a project. Here it arrives as a discovered tool the agent can call.
The Gateway handles schema management, endpoint resolution, and service authentication itself — the docs are explicit that the knowledge base tools are auto-discovered through tools/list and available to the agent without additional configuration. My probe confirmed it: both tools present, correct input schemas, no wrapper code anywhere.
The finding: the Lambda actually goes away
The point wasn’t “a KB tool works” — the wrapper already proved that. It was whether the managed connector genuinely removes the custom infrastructure or just hides it.
Comparing the two targets on the same Gateway directly:
| Old path | New path | |
|---|---|---|
| Target kind | lambda | managed_connector |
| Backend | a Lambda function | connectorId: bedrock-knowledge-bases |
| Custom code | a retrieval Lambda you own | none |
| Tools | one (whatever you coded) | Retrieve + AgenticRetrieveStream |
The old target pointed at a Lambda ARN. The new target points at a connector ID. Lambda removed from new path: verified true. That is the whole value proposition: the retrieval integration moves from code you operate to configuration the platform operates, and you gain the agentic tool you wouldn’t have built yourself. Same Gateway, same MCP surface, same auth model — one fewer thing to own.
The caveat that decides everything: Managed only
Here is the constraint that isn’t obvious until it stops you. The connector is supported only for Amazon Bedrock Managed Knowledge Bases — not customer-managed ones.
Bedrock has two kinds of KB. A customer-managed KB is the classic one: you set up and operate the vector store (OpenSearch Serverless, Aurora, Neptune) and control ingestion, parsing, and indexing. A managed KB hands all of that to Bedrock — no vector store to provision, no retrieval infrastructure to run.
The connector only talks to the managed kind. So before I could attach anything, I had to create a managed KB and ingest the corpus into it — I couldn’t point the connector at a pre-existing customer-managed KB. That’s a real migration cost the feature grid doesn’t foreground: “native Gateway integration” quietly assumes you’re already on (or willing to move to) managed KBs. If your organization standardized on customer-managed KBs for control over the vector store, adopting this connector isn’t a config change — it’s a re-platforming of the knowledge base itself.
That’s the honest trade. You delete a Lambda, but the price of entry is a Managed KB.
Governance stays where you’d want it
The reason this fits the “governed hub” pattern rather than being a pure convenience feature: the governance surface doesn’t degrade when the Lambda disappears.
- Least-privilege IAM survives. The Gateway service role needs only
bedrock:Retrieve(and the agentic action) on the specific KB ARN — the same narrow grant the Lambda’s role needed. TheknowledgeBaseIdis bound in the target’s parameter values, not exposed to the model, so the agent can’t redirect the query at a different KB by talking its way there. - Observability survives. I enabled Gateway vended-log delivery for the connector and captured lifecycle events for managed-KB calls in CloudWatch, plus Gateway metrics — the same audit trail the rest of the Gateway tools get. A retrieval tool with no audit trail is a liability; this one keeps the trail.
- The MCP auth boundary is unchanged. Callers still reach the tool through the Gateway’s existing auth (SigV4,
aws_service="bedrock-agentcore"), so whatever inbound authorization and Cedar policy you’ve layered on the Gateway still applies. The connector didn’t punch a hole around your controls; it slotted into them.
That’s the right shape: less infrastructure to own, no loss of the controls that make a retrieval tool safe to expose to an agent.
So what
The bedrock-knowledge-bases connector is a clean win with a clear boundary. If you’re on Managed Knowledge Bases, it deletes the retrieval Lambda outright, hands you an agentic multi-step retrieval tool you wouldn’t have built, and keeps IAM, observability, and MCP auth exactly where they were. If you’re on customer-managed KBs, the connector isn’t for you yet — adopting it means migrating the knowledge base, not just re-pointing a target.
The broader pattern is the one this series keeps hitting: AgentCore is steadily replacing glue you operate with connectors the platform operates — first for APIs (the Gateway itself), then web search, now retrieval. Each one removes a Lambda and keeps the governance. The catch is always in the fine print of what the managed version requires — here, that your KB is the managed kind.
What I haven’t tested yet is per-user access control at the document level within the KB. The managed connector works with IAM scoping (the Gateway role can only retrieve from this KB), but per-user authorization inside the KB — whether Cedar at the Gateway is enough, or whether you need managed KB document-level controls — remains an open question.