Amazon Bedrock Knowledge Bases lets you "integrate proprietary information into your generative-AI applications": you point it at where your documents live, it handles ingestion, indexing, and retrieval, and Claude (as a supported generation model — see RetrieveAndGenerate) answers questions with citations back to the sources. The first design decision is which of your document stores it can actually reach, and what happens to the permissions attached to those documents.
Two knowledge base types, different connector stories
Bedrock offers two knowledge base types. The Managed Knowledge Base — the one AWS recommends — has Bedrock manage ingestion, indexing, storage, and retrieval end to end, with service-managed embedding, re-ranking, and reasoning models by default, agentic multi-hop retrieval, and integration with AgentCore Gateway via MCP. The customer-managed type gives you control of the pipeline and vector store (OpenSearch Serverless, Aurora, or Neptune, for example) — see the managed-vs-customer comparison. The connector list below is documented for the managed type.
The out-of-the-box connectors
Managed Knowledge Bases connect to six data sources:
| Connector | Typical content | ACL permission filtering |
|---|---|---|
| Amazon S3 | Exported files, data lakes, document dumps | Yes |
| SharePoint | Corporate intranets, team sites | Yes |
| Confluence | Wikis, runbooks, engineering docs | Yes |
| Google Drive | Shared drives, working documents | Yes |
| OneDrive | Personal and team file storage | Yes |
| Web Crawler | Public or internal websites you designate | No |
If your documents live somewhere else — a proprietary DMS, a database, a ticketing system — you are outside the managed connector list. Options then are exporting into S3 on a schedule (see the knowledge-base sync pattern) or skipping Knowledge Bases in favor of your own retrieval passed to Claude via search_result blocks.
Document-level ACL filtering at retrieval time
The standout governance feature: managed connectors support document-level ACL permission filtering applied at retrieval time. An ACL (access-control list) is the set of users and groups allowed to see a document in its home system. Retrieval-time filtering means the knowledge base doesn't just copy documents into an index that anyone with query access can mine — when a query runs, results can be filtered to documents the requesting user is entitled to see. This addresses the classic RAG security failure, where an over-broad index quietly becomes a permissions bypass: an intern asks the chatbot about executive compensation and the vector index happily serves chunks from a restricted HR folder.
What the Web Crawler does and does not cover
The Web Crawler connector ingests web content you point it at — useful for public documentation, marketing sites, or help centers. It is also the documented exception to permission filtering: ACL-based filtering does not apply to crawled content. That is coherent (a crawled page has no ACL to import), but it carries a practical warning: anything the crawler ingests should be treated as visible to every user of the knowledge base. Don't crawl authenticated or semi-private web content into an index shared across audiences with different entitlements. For crawl scope, robots handling, and rate details, check the official documentation rather than assuming — the connector's boundaries are configured per data source.
Keeping the index honest
Connectors ingest via sync jobs, so the knowledge base reflects sources as of the last sync — build re-syncs into your operational cadence, and remember that citations in generated answers point back to source locations (S3 URIs, SharePoint items, web URLs), so stale or deleted sources degrade the user experience even when retrieval still works. For how ingested documents get split before indexing, continue to the five chunking modes.
Where to go next
Pair this with embedding model choice and the production checklist; for the security framing, see input data controls.