Mapping

Authoritative source. This file captures a validated capability map, not a complete specification. The authoritative source for current create-time behavior, accepted enums, chunking/parsing, and embedding-model rules is the Amazon Bedrock User Guide — chiefly Create a managed knowledge base (opens in a new tab), Customize ingestion for a data source (opens in a new tab) (parsing and chunking strategies for managed KBs), and How content chunking works for knowledge bases (opens in a new tab). Check those pages before quoting specific enums, token/overlap figures, or model rules — accepted values change, and the service, not this file, is the final authority.

Contents

• Key validated findings
• Managed-only capabilities — what MANAGED adds
• 1:1 mapping
• Adjusted mapping (adjusted tier)
• Handled differently on managed (no direct knob) — incl. the closed blocker list
• Gap coverage — how managed handles each difference, and what covers it
• Background — self-managed KB building blocks
• Public reference links

Key validated findings

• Chunking on MANAGED depends on the embedding-model type — this is the governing rule.
  • Managed embedding model (the default): emit NO chunkingConfiguration at all. Specifying any chunking strategy — including FIXED_SIZE or NONE — is rejected at create time with ValidationException: "A chunking strategy cannot be specified with a managed embedding model" (observed on a live create). Omit the block; the managed default (fixed-size, honoring sentence boundaries; size and overlap on the Customize ingestion page) applies. This restriction is not stated in the AWS user guide (the Customize ingestion (opens in a new tab) page lists DEFAULT/FIXED_SIZE/NONE as accepted and does not mention the managed-embedder exception) — so do not “correct” this rule from the docs page; the live create is the authority.
  • Custom embedding model on a MANAGED KB: FIXED_SIZE or NONE may be carried over (values are retained); DEFAULT, HIERARCHICAL and SEMANTIC are still rejected server-side, so for a SEMANTIC/HIERARCHICAL source omit chunkingConfiguration and let the default apply.
• CUSTOM data sources ARE supported on MANAGED — via the connector, not the top-level type. The self-managed dataSourceConfiguration.type: CUSTOM is rejected ("Unsupported data source type for MANAGED knowledge base type."), but type: MANAGED_KNOWLEDGE_BASE_CONNECTOR with connectorParameters.type: CUSTOM is accepted (the data source goes straight to AVAILABLE) and gives direct document ingestion via IngestKnowledgeBaseDocuments — no S3 staging. See managed-kb-api.md §2d.
• Retrieve is HYBRID-only on MANAGED (overrideSearchType does not exist on the managed wrapper); self-managed accepts both. Scores are on different, non-portable scales, and on MANAGED the scale also depends on the reranking mode — re-tune any threshold after migration (full caller list: managed-kb-api.md §3 “What changes for existing Retrieve callers”). Retrieve is not the only query surface: MANAGED also exposes AgenticRetrieveStream, a planning-loop retrieval API that does not exist on VECTOR at all — see “Managed-only capabilities” below and managed-kb-api.md §3.
• numberOfMetadataDocumentsScanned is not a health signal. Do not expect a particular value; metadata filtering works either way.
• Auth-based connectors (Confluence/SharePoint/OneDrive/GoogleDrive) need a Secrets Manager secret; SharePoint siteUrls must be a JSON array. See managed-kb-api.md §2b.
• Embedding output has one fixed dimension and data type on MANAGED (the create page states them; validated live — other values are rejected, not silently defaulted): a smaller dimensions value → "MANAGED knowledge base type supports only 1024 embedding dimensions"; embeddingDataType: BINARY → "... supports only FLOAT32 embedding data type". A source KB on a reduced dimension or BINARY must be re-embedded at the managed dimension and data type.
• Embedding on MANAGED: default service-managed, or a CUSTOM bring-your-own model (text OR multimodal). Don’t hardcode the supported set — it changes; fetch it at create time from kb-managed-create.md#kb-managed-embedding-models (+ knowledge-base-supported.md / kb-managed-regions.md for Region) via curl + .md. Always-true constraints: a CUSTOM text model must use the dimension and data type the create page requires (the errors above name them), and CUSTOM disables the managed reranker (the default keeps it). A CUSTOM multimodal model is different: it takes no dimensions, takes a modelConfiguration block (version "1") and a required supplementalDataStorageConfiguration S3 location (a different bucket from the data source), ingests only with the MULTI_MODAL_EMBEDDINGS parsing strategy (no text chunking), and is queried only with Retrieve and text queries (kb-managed-native-multimodal (opens in a new tab)). Read the supported multimodal models from the create page. This is documented, not migration-tested: say so, and check the CloudFormation / Terraform schema for the multimodal fields before emitting IaC. An unlisted model → "The specified embedding model ... is not supported".
• Environment caveat: ingestion can be healthy in one region/environment and broken in another — validate in the actual target environment.

Retrieval accuracy: roughly on par with self-managed on rank-1 retrieval; forced SMART_PARSING makes MANAGED beat self-managed’s default parser on image-bearing PDFs; parity on pure text; tables weakest on both. A text embedding model does not cover image/audio/video-only answers, whereas a multimodal CUSTOM model (if the docs list one) embeds that content directly. State this as a capability difference if the user asks — do not assess, classify, or advise on what the user’s corpus contains; corpus content type is out of scope for this tool.

These are single-shot Retrieve comparisons. Agentic retrieval is a different surface with its own documented gains on a different benchmark (below). Never blend the two sets of numbers — “on par with self-managed” and the agentic benchmark gains describe different APIs answering different question shapes, and quoting them together implies a comparison neither measurement made.

Managed-only capabilities — what MANAGED adds

Three source tiers, kept distinct. “Key validated findings” above is live-tested (the service is ground truth). This section mixes two lower tiers, and the difference matters when you quote it:

1. Contract-verified — the retrieval request members that differ between self-managed and managed, checked against the botocore bedrock-agent-runtime model with client-side parameter validation plus a live us-west-2 call, and the applied managed chunking/parsing config read back from live managed KBs. The caller-impact consequences are in managed-kb-api.md §3. Neither this file nor managed-kb-api.md carries runtime request shapes — for those the user goes to the AWS API reference or --generate-cli-skeleton, never to an example.
2. Documented only — the capability narrative and every benchmark or limit figure (MuSiQue gains, parsing size ceilings, the number of KBs one agentic call can route across, per-call prices, real-time ACL checks, incremental sync). Read, not measured. Quote these as documented and re-verify anything load-bearing.

Never present a documented figure as something this tool measured. If a doc you fetch disagrees with a finding recorded here about a shape or an error you can reproduce, prefer the recorded finding and say the documentation differs. A page that documents a connector or capability this file does not list wins: absence here is not evidence. Re-check either way, because a verified contract is still a snapshot: the model ships per botocore release, server-side validation is stricter than client-side, and quotas move independently of shapes, so check the docs whenever a call errors rather than assuming these files are current.

A VECTOR KB is a set of parts the customer assembles and operates: a store, an embedding model, a parser, a chunker, retrieval logic. MANAGED collapses them into one primitive. Five sections below say why the result is not merely simpler but frequently more accurate: three capabilities (§1–§3), the scale and quota differences (§4), and the capabilities that have no self-managed equivalent at all (§5). Each pairs with a configuration difference in “Gap coverage” below, which is where the two are matched up explicitly.

1. Smart Parsing — the ingestion model

Managed forces SMART_PARSING (there is no parsingConfiguration — managed-kb-api.md §2). It is not one parser but a per-content-type strategy selected automatically, built from three documented pieces:

• Connector-specific data models. Each connector preserves the structure its source actually has: the WEB connector keeps HTML structure including embedded images and tables; SharePoint keeps document hierarchy and the relationships between files. This is why the connector choice affects retrieval quality, not just where documents come from.
• Multimodal processing. It identifies bounding boxes within documents and sends those regions to foundation models for data extraction, captioning, and — in video — scene description. Tables, charts, diagrams and mixed layouts are handled with no configuration.
• FM-driven, structure-aware chunking. Documented as using foundation models to understand document structure so complex mixed-format documents index correctly, with defaults balancing retrieval accuracy against performance per document type and content structure.

Documented ingestion ceilings: the per-file size limits for visual documents, audio and video are on the managed KB docs and the enterprise-search blog (links at the end); fetch them before quoting a figure, and if the page you fetch does not state one, say so.

Default chunking. The applied managed default is fixed-size chunking (its size and overlap are on the Customize ingestion page, and matched measured chunks), with only [FIXED_SIZE, NONE] accepted as an explicit strategy — and only on a custom-embedding KB; a managed-embedding KB rejects every strategy, so you omit the config there (see Key findings). Structure awareness lives in parsing, upstream of the chunker — which is why the default can be fixed-size without the ingestion being structure-blind. Two details govern how to describe it:

• On a managed data source created without chunkingConfiguration, vectorIngestionConfiguration reads back as null — the service stores and echoes nothing. So the managed default is not a readable setting: quote its size from the docs page, not as a config value you can verify with get-data-source. Say it that way.
• On a managed data source created with an explicit FIXED_SIZE config, the values are retained: a live source built with an explicit maxTokens and overlapPercentage reads those values back unchanged. Explicit FIXED_SIZE is genuinely supported, not silently discarded — but only on a KB using a custom embedding model. On a managed-embedding KB, an explicit FIXED_SIZE (or any strategy) is rejected outright (see Key findings); you cannot set or read a chunking config there at all.
• The rejection of DEFAULT/HIERARCHICAL/SEMANTIC is server-side only. The API model’s enum is the full [FIXED_SIZE, NONE, HIERARCHICAL, SEMANTIC] (shared with self-managed), so SEMANTIC passes client-side validation and fails only on the live create. Independently, on a managed-embedding KB the server rejects every strategy including FIXED_SIZE/NONE — also invisible client-side. Both are why live testing, not the schema, is the authority here (managed-kb-api.md §6).

Do not tell a user their SEMANTIC chunking is replaced by something semantically equivalent. State the substitution (managed default chunking, not customer-readable) and, if it matters to them, that the structure awareness lives in parsing rather than in the chunker.

Two cases beyond the plain fixed-size default, both embedding-model-driven. (1) Managed embedding model: no chunking config is accepted at all — omit it (see Key findings). (2) Native multimodal embedding model (parsing strategy MULTI_MODAL_EMBEDDINGS): files are sent straight to the embedding model instead of being parsed into text, so the text chunking strategy is ignored for that content — you control audio/video segmentation instead. Only a custom text embedding model actually carries a FIXED_SIZE/NONE chunking config. Confirm against Customize ingestion for a data source (opens in a new tab) before quoting specifics — note that page does not document the managed-embedder rejection (case 1).

2. Agentic Retrieval — a second retrieval surface, and MANAGED-only

Retrieve (managed-kb-api.md §3) is not the only query surface. AgenticRetrieveStream runs an FM-driven planning loop instead of a single similarity search: it decomposes the query into sub-queries, retrieves per sub-query, judges whether the evidence is sufficient, and iterates — then generates a grounded answer in the same call by default. How it behaves, when to choose it, and its cost and permission shape: managed-kb-api.md §3 (a conceptual overview — running it is the user’s step, so no request shapes there).

This is the largest capability MANAGED adds, and it does not exist on a VECTOR KB at all — AgenticRetrieveStream is documented as Managed-KB-only. A team that hand-built a plan → retrieve → evaluate loop on top of Retrieve is maintaining in every application what this API does natively, with its own latency, cost and reliability risk.

Why this is an accuracy argument and not a convenience one: a multi-intent question (“compare how we talked about hiring and long-term investment in 2020 vs 2023”) has no single point in embedding space that represents it well, so single-shot top-k returns an average of competing sub-intents. Decomposition is what fixes that, and the documented benchmark gain grows with difficulty — the agentic-retrieval blog (link at the end) reports recall gains on the public MuSiQue multi-hop benchmark that rise with the number of hops, and small gains on single-hop questions. Quote the figures from the blog you fetch, attributed to agentic retrieval. It is not a blanket upgrade — it is the right surface for multi-part, comparative, exploratory and cross-KB questions, and the wrong one for direct lookups.

It also routes across several knowledge bases in one request, picking per sub-query from a natural-language description attached to each retriever. That is the capability to reach for whenever a migration splits one KB into several (the data-sources-per-KB split) — see “Gap coverage”. How many KBs one call may route across is a server-side quota, not a contract bound (verified: the retrievers list has min=1 and no maximum in the API model), so read it from the quotas page and don’t expect client validation to catch one too many.

3. Service-managed storage — the accuracy argument, not only the ops one

Dropping storageConfiguration is usually framed as losing control. What is gained is documented and concrete:

• Auto-provisioned — no vector-dimension or similarity-metric decision to get wrong.
• Auto-scales from gigabytes to terabytes with no intervention.
• Hybrid search continuously on, keyword plus semantic, with no separate index configuration to manage. This is the flip side of the HYBRID-only finding: the constraint and the feature are the same fact.
• Encrypted at rest and in transit with AWS KMS keys, AWS-managed or customer-managed.
• The multimodal parser, the managed embedding model and the managed re-ranker are included at no extra cost on the default path — which is exactly why a cost comparison has to count those line items on the self-managed side (cost-analysis.md).

Two production behaviors round it out, neither of which is simply “the self-managed thing but managed”:

• ACL-aware retrieval — document-level access control in two stages: pre-retrieval filtering (the connector crawls allowed/denied users and groups during ingestion, and query results are filtered against the user context you supply) plus real-time ACL verification (a live call to the source confirming the user still has access, catching permission changes since the last sync). Deny always overrides allow, and the pipeline fails closed — a group-resolution failure, verification timeout or internal error withholds the affected documents rather than returning them. Pre-filtered documents are transient for the life of the API call and never exposed to the model or the user. Verified details in managed-kb-api.md §3b.

  State the boundary every time: ACL awareness is not authorization. The AWS documentation is explicit — this is ACL-aware filtering, not a security boundary. Managed KB does not authenticate end users; the application must authenticate them and pass verified identity context, and because the service cannot check the authenticity of that context, it must not be relied on as a sole access-control mechanism without upstream authentication. Presenting this as “managed handles your authorization” would be a security misrepresentation, not just an overstatement.

• Incremental sync — subsequent syncs process only new or modified documents, which is what keeps re-sync time and cost proportional to change rather than to corpus size.

4. Scale and quota differences — the biggest gap, and the easiest to verify

Read every limit live; never quote one from this file or from memory. AWS’s own pages disagree on several of these (values and whether they can be raised), so the customer’s account is the only source. Whenever limits come up (Explore or Plan), run, for each quota code below (READ-ONLY, pre-approved):

Quote Quota.Value and Quota.Adjustable exactly as returned. If a call fails (denied, throttled, no such code), say “check Service Quotas in your account” for that quota and give no number for it. Note the official terminology: AWS calls the self-managed type a Customer-managed Knowledge Base; this file says “self-managed” / VECTOR for the same thing.

How to frame throughput. Self-managed Retrieve is one ceiling shared by every KB in the account; managed has an account ceiling plus a separate per-KB allowance. State both managed numbers as returned. Do not describe managed as slower.

Two of these change migration design, not just talking points (confirm the numbers live first):

• The data-source jump reverses the usual direction of a split. A self-managed estate is often fragmented because of its per-KB data-source limit. On managed, many more fit in one KB — so a migration frequently consolidates rather than splits.
• The KB-count jump removes per-account KB scarcity as a design constraint, which is what makes “a KB per team / per tenant” viable at all.

Report the managed storage ceiling per KB (L-BEE3FA31) alongside these, as returned.

5. Capabilities that simply do not exist on self-managed

From the AWS comparison table — these are “Supported” vs “Not supported” rows, not degrees:

The connector row needs care — do not overstate it. AWS’s comparison table lists Customer-managed as “S3 and Custom”, and that is the line to quote. But the shared API model still exposes WEB, CONFLUENCE, SHAREPOINT and SALESFORCE as VECTOR data-source types, and real customer estates use them — this tool’s own migration mapping exists precisely to translate them. So never tell a user their existing self-managed Confluence, SharePoint or Salesforce connector “doesn’t exist.” The defensible claims are: managed’s native connector suite is the documented differentiator, and it is broader than self-managed’s — managed adds Google Drive, OneDrive, Box, Zendesk and Confluence Data Center, and Salesforce, Zendesk and Confluence (Cloud and Data Center) are native managed connectors (see §”The managed connector set” below). There is no connector that self-managed has and managed lacks that still blocks a migration. Confirm the live set from the connector docs rather than reciting a list or a count.

Managed gain (R1), state it where connectors come up: new Confluence, SharePoint, Salesforce and Web Crawler connectors cannot be created on customer-managed (VECTOR) KBs — existing ones keep working, but for these sources new work goes on managed and AWS recommends managed by name (https://docs.aws.amazon.com/bedrock/latest/userguide/salesforce-data-source-connector.html (opens in a new tab)).

AWS states its own preference plainly on that page — managed is recommended for the combination of ease-of-use, accuracy and cost. That is a citable position, not this tool’s opinion.

How to state the parsing and search claims

• The parsing claim is qualitative. What is supportable: multimodal handling, per-connector data models, and this tool’s live finding that managed beats the self-managed default parser on image-bearing PDFs. Attach no accuracy percentage to parsing — the documented retrieval-accuracy figures belong to agentic retrieval (§2), and the correct terms for the parser are “Managed parser” / SMART_PARSING.
• Hybrid search is a separate, verified claim — always on, per §3. Keep it distinct from parsing; the shared word is not a bridge between the two.

1:1 mapping

Adjusted mapping (adjusted tier) — managed reaches the same outcome a different way

These settings aren’t passed through verbatim, but each has a supported, validated path on the managed KB that reaches the same — often better — result. The decision-trace tier keyword is adjusted.

Handled differently on managed (no direct knob)

A few self-managed-only features have no one-to-one managed setting (decision-trace tier keyword: no-mapping). For some there is a supported managed approach; for others there is no managed path, and the customer must be directed to AWS Support — do not propose a workaround.

The blocker list is CLOSED — exactly two features block a migration

Only these two make a knowledge base ineligible. Nothing else on this page, and nothing absent from this page, is a blocker:

1. Custom transformation (Lambda) — no managed equivalent for an in-pipeline customTransformationConfiguration hook. Removing it would silently change what gets indexed. Contact AWS Support.
2. Context enrichment / GraphRAG (Neptune Analytics) — no managed graph store, and standard managed vector retrieval is a different capability, not a substitute for relationship-aware retrieval. Contact AWS Support.

No workaround for a blocker. Do not offer a way around it: not removing or disabling the Lambda, not moving the transform upstream or into a pre-processing step, not a migrated file “if you drop it”, and not an offer to build on any of these. Each one changes what gets indexed, which is a decision for the customer and AWS Support, not a migration step. Say “this KB can’t move yet — contact AWS Support”, and what managed would give them once it is resolved.

Before keeping either, check the managed KB docs for an equivalent; keep it only if the docs show none (both were re-checked against kb-managed-connect-ds.md and the managed KB user guide, which document no in-pipeline transform hook and no equivalent managed graph store). Salesforce migrates — managed has native Salesforce and Zendesk connectors and a native Confluence Data Center connector, so Salesforce, Zendesk and Confluence (Cloud and Data Center) sources all migrate. See “The managed connector set” below.

Plus, by extension: any connector genuinely absent from the managed set. Check the live docs before concluding a connector is missing (plan → “Before recording a connector as blocked”) — WEB, GOOGLEDRIVE, SALESFORCE, ZENDESK, CONFLUENCEONPREM, BOX and SERVICENOW are all present under those names.

The managed connector set

The managed connector type is given by managedKnowledgeBaseConnectorConfiguration.connectorParameters.type (with version: "1"); the wrapping dataSourceConfiguration.type is MANAGED_KNOWLEDGE_BASE_CONNECTOR. Documented connectors and their type values (each confirmed from its own connector page — fetch the page for the full connectionConfiguration shape, never invent fields):

Do not write a connector count — the connect-ds overview’s “Supported type values” sentence has not been updated for the newest connectors, and the set is expanding; rely on each connector’s own page and confirm the live set from the docs. If a connector exists but its exact config shape is not documented on a page you can fetch, state that the connector exists and mark the shape not documented rather than inventing it.

An adjusted row is NEVER a blocker

Everything in the Adjusted mapping table is a supported migration, not an exclusion. If a setting has an adjusted row the knowledge base is READY: apply the substitution, record the adjusted decision with what changes, and emit the resource. Reduced dimensions / BINARY, SEMANTIC/HIERARCHICAL chunking, a third-party vector store, a foundation-model parser, supplemental data storage, RETAIN, data-source-level SSE and cross-account direct index access are all adjusted — refusing to migrate any of them is a false exclusion, and it is the more damaging error, because the customer is told to open a support case for something that migrates today.

A feature that appears nowhere on this page is not a blocker either. Absence here means “unmapped”, not “impossible”. Before excluding anything not in the closed list: check the live resource schema and the managed API/connector docs (iac-schema.md §0, managed-kb-api.md), and say what you checked. If it has a managed home, the KB is READY and this file should gain a row. Only if the checks confirm there is no managed path does it become an exclusion — reported as a newly discovered blocker, named explicitly, not folded silently into the closed list above.

Gap coverage — how managed handles each difference, and what covers it

Every adjusted row above is something managed handles differently. Most are covered by something managed adds; a few genuinely are not, and saying which is which plainly is what makes the rest credible. This is how to present any difference — use it whenever a difference comes up (including when the user asks “what do I lose?”), when Plan lists substitutions, and when Implement reports caller impacts.

Frame each row as what’s different and how managed does it, not as what the user gives up. A wording rule, not a softening of the grades: the residual on a Partly and an honest No still have to be stated. It is also the more accurate framing — the index-tuning surface goes away because the decisions it existed to make go away with it, and direct store access is replaced by an access path that still supports querying and writing documents.

Never name a difference without its pairing in the same breath. A bare list of removed knobs is a misdescription, because it reports the control and omits the capability that replaced it. Every difference you raise carries three things: how managed does it instead, the acceptable substitute where one exists — stated explicitly, not left for the user to infer — and the Covers? grade.

A Partly row the customer says they need: state the gap accurately, say what managed offers instead, and say which parts of the workload can move without it. A hard requirement managed cannot meet is a real exception (see the SEMANTIC-only row); say so plainly, with the fact behind it.

The Covers? value is the claim you are allowed to make. Do not upgrade it.

• Yes — the gap is closed. The managed capability does the same job or better; migrate and say so.
• Partly — the gap is narrowed and the residual is named. State both halves; never round up to Yes.
• No — no managed capability covers it. Say so plainly with its consequence, give the real alternative where one exists (for direct index access that alternative is architectural — the retrieval APIs, direct ingestion, or an AgentCore Gateway/MCP target), and never offer one of the three capabilities as a substitute for something it doesn’t actually replace.

Why most of these are not really tradeoffs

A user can read the adjusted list as a column of losses and reasonably ask whether migrating is a downgrade. It generally isn’t, and the argument does not depend on rhetoric — it depends on noticing that almost every apparent loss is the removal of a control, while the gains are removals of limits. Use this framing when a user pushes back, and keep it factual:

1. The controls being removed mostly existed to compensate for running your own store. Index tuning, dimension reduction, similarity-metric choice and parser selection are all work that exists because the infrastructure is yours. Managed does not take the outcome away — it takes away the need to produce it, and ships a managed embedding model and managed re-ranker at no extra cost where self-managed offers none.
2. The limits being removed are order-of-magnitude, and they are the ones that shape architecture: data sources per KB, KBs per account, concurrent ingestion jobs and query characters. Quote the values read live from Service Quotas (§4), never fixed numbers. Those are not conveniences; they decide whether “a KB per team” or “one KB for the whole estate” is even expressible. One apparent migration cost, splitting a KB across several, is an artifact of self-managed limits that managed simply doesn’t have.
3. Three capabilities have no self-managed equivalent at all — agentic retrieval, AgentCore Gateway integration, and resource-based policies for cross-account access are documented as “Not supported” on VECTOR. A migration that trades index tuning gains a retrieval mode, an MCP access path, and a sharing mechanism that were previously impossible.
4. AWS’s own recommendation is citable. The user guide recommends managed for the combination of ease-of-use, accuracy and cost. Offer it as a documented position, not as this tool’s enthusiasm.

What keeps this honest — always pair it with the residuals. The genuine, non-rhetorical residuals are: a per-KB raw-storage ceiling (read live, L-BEE3FA31); no customer-visible index, so a consumer doing raw index queries must change how it works; no reduced-dimension or BINARY footprint, so the index gets larger; no supplemental-media bucket you own; ACL awareness is filtering, not authorization; and callers must change Retrieve request bodies and re-tune score thresholds. Lead with the reframing, then name these without being asked. A user who discovers an unmentioned residual later will discount everything else in the table.

None of this reopens the blocker list. The same two features block: the Lambda transform and GraphRAG. Agentic retrieval narrows the GraphRAG use case and must never be used to reclassify it as READY.

Background — self-managed KB building blocks (orientation)

• Vector store options (self-managed): OpenSearch Serverless, OpenSearch managed cluster, Aurora PostgreSQL (pgvector), Neptune Analytics, S3 Vectors, Pinecone, MongoDB Atlas, Redis Enterprise. Appears under knowledgeBase.storageConfiguration in get-knowledge-base. A MANAGED KB has no customer storageConfiguration — the store is auto-provisioned.
• Embedding model appears under ...vectorKnowledgeBaseConfiguration.embeddingModelArn (self-managed) or ...managedKnowledgeBaseConfiguration.embeddingModelArn (MANAGED). Model and vector dimensions must be compatible with the store.
• Data sources (S3, web crawler, other connectors) are separate resources attached to a KB; chunking and parsing live in the data source’s vectorIngestionConfiguration.
• Migration reality: a KB’s vector store generally cannot be changed in place. Migration means creating a NEW KB on the new store/type, attaching equivalent data sources, syncing to rebuild embeddings, validating retrieval, then cutting over. Re-embedding is expected.

Public reference links

Reading these: fetch via curl + .md (swap .html→.md), never web_fetch — full rule in safety-and-iam (opens in a new tab) → “Reading public AWS docs”. Re-verify against live docs; prefer the user’s Region.

• Embedding-model options (authoritative CUSTOM model list — fetch, don’t hardcode): https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-create.html#kb-managed-embedding-models (opens in a new tab)
• Create a managed knowledge base (managed vs custom embedding rules; console parsing/chunking flow; CreateDataSource vectorIngestionConfiguration): https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-create.html (opens in a new tab)
• Customize ingestion for a data source (accepted managed chunking strategies DEFAULT/FIXED_SIZE/NONE, SEMANTIC unsupported, the default chunking size; native-multimodal caveat — note: this page does NOT yet document that the managed embedding model rejects all chunking config; see Key findings): https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-customize-ingestion.html (opens in a new tab)
• How content chunking works for knowledge bases (chunking strategy definitions): https://docs.aws.amazon.com/bedrock/latest/userguide/kb-chunking-parsing.html (opens in a new tab)
• AgenticRetrieveStream API reference (the second retrieval surface — §3; this is where request shapes come from): https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_AgenticRetrieveStream.html (opens in a new tab)
• Retrieve API reference: https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_Retrieve.html (opens in a new tab)
• Managed vs Customer-managed comparison table + AWS’s own recommendation (source for “Capabilities that simply do not exist on self-managed”): https://docs.aws.amazon.com/bedrock/latest/userguide/kb-build-managed.html (opens in a new tab)
• Managed knowledge base quotas (KBs per account, data sources per KB, concurrent ingestion jobs, raw storage per KB, query characters): https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-quotas.html (opens in a new tab)
• All Bedrock service quotas — the self-managed side of every comparison (the same quota names for self-managed KBs): https://docs.aws.amazon.com/general/latest/gr/bedrock.html#limits_bedrock (opens in a new tab)
• ACL-aware retrieval, incl. the “not authorization” boundary and the connector support matrix: https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-acl.html (opens in a new tab)
• ACL-aware retrieval request syntax (passing user context): https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-retrieve-acl.html (opens in a new tab)
• Resource policies for managed KBs (cross-account; VECTOR does not support these): https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-cross-account.html (opens in a new tab)
• AgentCore Gateway target for a knowledge base: https://docs.aws.amazon.com/bedrock/latest/userguide/kb-gateway-target.html (opens in a new tab)
• Supported models and Regions for knowledge bases: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-supported.html (opens in a new tab)
• Supported Regions for managed knowledge bases: https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-regions.html (opens in a new tab)
• Create a knowledge base: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-create.html (opens in a new tab)
• Sync / ingest data: https://docs.aws.amazon.com/bedrock/latest/userguide/kb-data-source-sync-ingest.html (opens in a new tab)
• StorageConfiguration API reference: https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_StorageConfiguration.html (opens in a new tab)
• AWS CLI bedrock-agent reference: https://docs.aws.amazon.com/cli/latest/reference/bedrock-agent/ (opens in a new tab)

Capability announcements (source for “Managed-only capabilities”)

These are aws.amazon.com/blogs posts, not docs.aws.amazon.com pages — they have no .md twin, so the curl + .md rule does not apply to them. They are the source for the capability descriptions, benchmark figures and documented limits in “Managed-only capabilities” and “Gap coverage”. They are narrative, dated, and not an API contract: for any request shape, parameter name, enum, quota or Region list, the API/user-guide pages above win, and a live-tested finding wins over both. Treat a figure quoted from here as documented-at-publication, and re-verify anything load-bearing.

Take capability descriptions from these posts, never request shapes. Request shapes come from the AWS API reference or --generate-cli-skeleton — the skills carry none for the runtime surfaces, because querying a knowledge base is the user’s step.

• Managed Knowledge Base announcement (Smart Parsing, Agentic Retriever, connectors, AgentCore Gateway target, pricing dimensions): https://aws.amazon.com/blogs/aws/introducing-amazon-bedrock-managed-knowledge-base-for-faster-more-accurate-enterprise-ai-applications/ (opens in a new tab)
• Enterprise search deep-dive (service-managed storage, real-time ACL checks, incremental sync, parsing size ceilings, three-call setup, Gateway/MCP): https://aws.amazon.com/blogs/machine-learning/build-enterprise-search-for-agents-with-amazon-bedrock-managed-knowledge-base/ (opens in a new tab)
• Agentic retrieval deep-dive (AgenticRetrieveStream planning loop, trace events, multi-KB routing, MuSiQue results, Retrieve-vs-Agentic comparison, per-call pricing, IAM actions): https://aws.amazon.com/blogs/machine-learning/agentic-retrieval-for-amazon-bedrock-managed-knowledge-base/ (opens in a new tab)