Amazon Bedrock Knowledge Bases: Types, Deployment and Limits

---

A knowledge base is a very good answer to one question: where is the passage that mentions this? Atlan answers a different one, which is what the passage means, who certified it, and whether it is still true. Bedrock keeps handling document retrieval while Atlan supplies definitions, lineage, ownership and policy from the warehouses, BI tools and pipelines a document index never sees, delivered to the same agent over MCP. The two sit together rather than compete, which makes choosing between a knowledge base and an agent context layer a design decision rather than a procurement one.

---

What do Amazon Bedrock Knowledge Bases do?

Amazon Bedrock Knowledge Bases search proprietary content at query time and hand the most relevant passages to a model as context, using retrieval-augmented generation to ground responses. Retrieval-augmented generation is well understood by now, and so are the ways its accuracy breaks down.

With a knowledge base you can:

• Use retrieved information from data sources to answer user queries with grounded responses.
• Augment prompts by feeding returned information into the prompt.
• Include citations in the generated response so the original source can be verified.
• Include documents with visual resources, extracting and retrieving images in responses.
• Search using images as queries, or combine text and images through multimodal embedding models.
• Use reranking models to influence which results come back.

---

What are the two types of knowledge base?

AWS offers managed and customer-managed. The choice decides who runs the vector store, which connectors are available, and whether agents get agentic retrieval.

Managed Knowledge Base

AWS made Managed Knowledge Base generally available on 17 June 2026. Bedrock runs ingestion, storage, indexing and retrieval, and by default selects and maintains the embedding model, reranker and foundation model. For most teams, AWS recommends the managed type as the best balance of ease of use, accuracy and cost.

• Ingestion of multi-modal data, with storage auto-scaling.
• Agentic retrieval for multi-hop reasoning.
• Native connectors for Amazon S3, SharePoint, Confluence, Google Drive, OneDrive and Web Crawler at launch.
• Document-level permissions applied from supported sources at retrieval time, with Web Crawler sources excluded.
• Smart parsing that picks an approach per file type, covering PDFs, slides, Word files, scanned documents, embedded visuals, audio and video.
• Exposure of the knowledge base as a tool over MCP, discoverable by frameworks such as Strands Agents, LangGraph, CrewAI and LlamaIndex. That discovery happens over the Model Context Protocol.
• Native integration with AgentCore Observability for retrieval traces, agentic traces and per-knowledge-base metrics.

Customer-managed Knowledge Base

Here you run your own RAG pipeline, including the vector store, and you control ingestion, parsing and index settings.

• Vector stores: Amazon OpenSearch Serverless, OpenSearch managed clusters, Aurora PostgreSQL with pgvector, Amazon S3 Vectors, Pinecone, Redis Enterprise Cloud and MongoDB Atlas, as listed in AWS Prescriptive Guidance. A vector database and a metadata layer solve different halves of the retrieval problem.
• GraphRAG with Neptune Analytics: traverses graph relationships after the initial vector search to connect facts across documents, with S3 as the only supported source and 1,000 files per data source by default. GraphRAG is the technique, and Amazon Neptune is the store it runs on here.
• Amazon Kendra GenAI index: reuses an existing Kendra GenAI index as the retriever.
• Structured data stores: uses Amazon Redshift as a query engine to turn questions into SQL against Redshift or AWS Glue Data Catalog tables.
• Parser choice: default text parsing, a foundation model parser, or Amazon Bedrock Data Automation for documents with charts and figures.

That flexibility carries trade-offs. AWS lists third-party connectors, document-level permissions and native AgentCore Gateway integration as managed-only capabilities.

Managed vs customer-managed at a glance

Aspect	Managed Knowledge Base	Customer-managed knowledge base
Infrastructure	AWS runs and auto-scales the data store.	You provision, scale, and update the vector or text store.
Retrieval	Hybrid semantic and keyword search, plus optional agentic retrieval.	Search strategy you configure, with no agentic retrieval.
Connectors	S3, SharePoint, Confluence, Google Drive, OneDrive, Web Crawler, and custom.	S3 and custom.
Embeddings and reranking	Managed models included at no extra charge, or bring your own.	Choose Bedrock models, billed per use.
Parsing	Built-in multimodal parser.	Default text, foundation model, or Bedrock Data Automation.
Permission filtering	Document-level ACL filtering at retrieval.	Not offered as a native feature.
AgentCore Gateway	Native target type.	Not supported natively.
Pricing model	Per GB indexed plus per retrieval call.	Vector store, model inference, and per-request charges.
Best for	Managed RAG over common enterprise document sources.	Custom vector databases, GraphRAG, and text-to-SQL.

Running a custom RAG pipeline instead of the managed knowledge base pays for itself only past a fairly specific scale.

---

How do you create and deploy a Bedrock Knowledge Base?

You connect a supported data source to Bedrock. Structured sources include Redshift and the AWS Glue Data Catalog; unstructured sources include S3, Confluence, Google Drive, SharePoint and Web Crawler. The ingestion steps are:

1. Connect and parse: files are pulled from connected sources and converted to text, including content extracted from images, tables, audio and video when multimodal parsing is on.
2. Chunk: text is split into passages sized for retrieval. Chunking can be standard, hierarchical, semantic or multimodal, and the chunking strategy affects answer quality more than most teams expect.
3. Embed: an embedding model converts each chunk into a vector so text can be compared mathematically.
4. Index: vectors land in an index that keeps a mapping back to each source document.

Once ingestion completes, you query through Retrieve for source chunks, RetrieveAndGenerate for a natural-language answer, GenerateQuery to turn questions into machine-readable form for structured stores, AgenticRetrieveStream to decompose complex queries into sub-queries, and an optional reranking model so the most relevant passages rise to the top.

The managed deployment path AWS recommends runs in seven steps:

1. Settle type, Region and embedding model. Decide early: the embedding model cannot change after creation, and a custom embedding model turns off the managed reranker.
2. Create the knowledge base. Go to Built-in tools, then Knowledge Base, then Create Managed Knowledge Base.
3. Connect data sources and set parsing rules. Customer-managed adds choosing an embeddings model and a vector store, and multimodal content must come from S3 or custom sources.
4. Sync and ingest content. Route ingestion logs to CloudWatch Logs, Amazon S3 or Firehose to catch failed files early.
5. Test retrieval against real questions. This is the step teams skip, and evaluating context is not the same as testing data quality.
6. Connect agents and applications. Add the knowledge base as a target. AgentCore Gateway exposes it over MCP with auto-generated permissions, which is how most teams end up running enterprise agents on Bedrock.
7. Monitor usage and keep context current. Schedule syncs to match how fast each source changes, since group memberships and content are only as fresh as the last ingestion.

---

Where do knowledge bases stop?

A knowledge base answers from the documents it indexes. It has no built-in way to know which revenue definition finance certified, which Redshift table is the trusted source, who owns a policy, or whether a page was superseded last week. Four limits show up repeatedly:

• Document-first connectors: managed connectors reach file, wiki and web sources. Warehouses, BI dashboards, transformation models and pipeline code sit outside that list, and closing that gap is why teams reach for a data catalog as the LLM knowledge base.
• Text without business meaning: chunks hold text. Certified definitions, metric logic and relationships between business concepts live elsewhere, so two documents that disagree get retrieved side by side. Resolving that is what an agent context layer adds over RAG.
• Sync-bound freshness: content and permissions update on each sync, with no signal that a source was deprecated or its owner left. Knowledge base staleness is usually detected long after it starts costing answers.
• No shared vocabulary across agents: each knowledge base indexes its own sources, so ten agents over ten knowledge bases can hold ten versions of the same term, which is precisely the business context that no single index holds.

---

How does Atlan extend Bedrock Knowledge Bases?

Bedrock keeps handling document retrieval, while Atlan adds meaning, ownership and policy context from across the estate. Bedrock helps an agent find text in your files. Atlan helps the same agent understand the business logic and relationships behind that text, That difference is why AI agents need an enterprise context layer.

Pair the knowledge base with the Atlan MCP server

Through Atlan’s MCP Server, agents look up assets, lineage, glossary definitions, classifications, policy rules and data quality signals, and write corrections back. Whether to reach for MCP or a direct API depends on whether the agent needs to discover the capability or just call it.

Connect warehouses, BI tools and pipelines to agent context

Atlan’s Enterprise Data Graph connects warehouses, BI tools, pipelines and other systems into one map of assets, lineage, SQL history and usage. Agents get the structured side of the business a document index never sees, including the lineage that makes an answer auditable after the fact.

Give text-to-SQL the definitions it needs

Glossary terms, metrics, domains and their relationships live in Active Ontology, which is the context a text-to-SQL engine needs to pick the right table and filter. In Atlan’s AI Labs benchmark, adding this context improved text-to-SQL accuracy by 38%. Text-to-SQL at enterprise scale lives or dies on that context.

Test context before agents reach production

Context Engineering Studio bootstraps Context Repos from existing dashboards and SQL, then generates evaluation questions from reports teams already trust. Failed answers come with a diagnosis: the missing relationship, synonym or filter, plus a suggested fix, published as a versioned, model-agnostic repo that a Bedrock agent and any other MCP-compatible agent can share.

Keep context live as the business changes

Context Agents generate and enrich descriptions, glossary links and quality rules as systems change, and user corrections flow back into shared context rather than decaying into tribal knowledge. Underneath, the Context Lakehouse stores context in Apache Iceberg with time travel, so teams can reconstruct exactly what an agent saw when it answered.

---

Real stories from real customers building enterprise context layers with Atlan

---

Moving forward with Amazon Bedrock Knowledge Bases

Managed Knowledge Base lowers the bar for production RAG on AWS by packaging connectors, parsing, embeddings, reranking and agentic retrieval into one service with per-GB and per-call pricing. The customer-managed type remains the route for teams that need a specific vector database, graph retrieval, or text-to-SQL over structured data.

Answer quality still rests on what sits behind retrieval: current documents, reconciled definitions, clear ownership, and policy context that travels with the data. None of those are things an index can infer from the text it holds.

A practical path is to start with the managed type on one high-value document domain, test it against questions users already ask, and connect agents to a shared enterprise context layer over MCP so every agent works from the same definitions. The harder problem is not retrieval. It is agreeing on what the retrieved thing means.

Book a demo

---

FAQs about Amazon Bedrock Knowledge Bases

1. How much does an Amazon Bedrock Knowledge Base cost?

Pricing depends on the type. For a Managed Knowledge Base, AWS charges $5.00 per GB of raw indexed data per month for index storage, $1.00 per 1,000 Retrieve API calls for standard retrieval, and $4.00 per 1,000 agentic calls plus $1.00 per 1,000 underlying Retrieve calls for agentic retrieval. Managed parsing, managed embeddings and the managed reranker are included at no extra charge.

2. Is Amazon Bedrock similar to ChatGPT?

The two operate at different layers. ChatGPT is OpenAI’s assistant for writing, research, coding and file analysis, used through web and mobile apps. Amazon Bedrock is a managed AWS service giving developers access to foundation models for building their own applications and agents. A company could build a ChatGPT-style assistant on Bedrock and use a knowledge base to ground its answers in internal documents.

3. How do I create a Bedrock Knowledge Base?

Open Amazon Bedrock AgentCore, go to Built-in tools, select Knowledge Base, and choose Create Managed Knowledge Base. Keep the managed embedding model or pick a custom one, then set the IAM role and encryption key. Add a data source, adjust ingestion settings, and create the knowledge base. Sync the data source and run test queries before connecting agents. A customer-managed knowledge base adds two decisions: which embeddings model to use and which vector store holds the index.

4. Which vector databases do Amazon Bedrock Knowledge Bases support?

A Managed Knowledge Base does not ask you to choose, since Bedrock runs an auto-scaling store for embeddings, text and files. Customer-managed knowledge bases work with Amazon OpenSearch Serverless and managed clusters, Aurora PostgreSQL with pgvector, Amazon S3 Vectors, Neptune Analytics, Pinecone, Redis Enterprise Cloud and MongoDB Atlas. AWS Prescriptive Guidance positions S3 Vectors for cost-optimized RAG and Neptune Analytics for graph-based retrieval.

5. Can Amazon Bedrock Knowledge Bases query structured data?

Yes. A knowledge base connected to a structured data store converts natural-language questions into SQL, runs them through an Amazon Redshift query engine, and returns results from Redshift or AWS Glue Data Catalog tables. The GenerateQuery API can also return the SQL on its own. AWS recommends restricted, read-only roles, and answer accuracy depends heavily on how well tables and columns are described.

6. How do Amazon Bedrock Knowledge Bases handle access permissions?

Managed knowledge bases ingest document-level permissions, including allowed and denied users and groups, from supported sources. At query time your application passes the user’s email and the knowledge base returns only documents that user may access, with deny rules overriding allow rules. For SharePoint, OneDrive, Google Drive and Confluence, a real-time check catches permission changes made since the last sync. The feature filters results and does not authenticate users, so your application must verify identity first.

7. Should I use a knowledge base or fine-tune a model in Amazon Bedrock?

Use a knowledge base when answers depend on facts that change, when responses need citations, or when content must respect user permissions. AWS positions knowledge bases as a way to use private data without continually retraining a model. Fine-tuning suits stable changes to tone, format or task behavior. Many production systems combine both, with a customized model generating answers from passages a knowledge base retrieves.

---

Sources

1. AWS Docs | Amazon Bedrock Knowledge Bases
2. AWS | Managed Knowledge Base generally available, 17 June 2026
3. AWS Docs | Build a managed knowledge base
4. AWS Docs | How data ingestion works
5. AWS Docs | Chunking options
6. AWS Docs | Reranking
7. AWS Docs | Create a managed knowledge base
8. AWS Prescriptive Guidance | Choosing a vector database for RAG
9. AWS | Amazon Bedrock pricing