Bedrock Knowledge Base Chunking Strategies: How to Choose (and What Changed in 2026)

Bedrock Knowledge Base chunking is no longer one decision inside one product. Since 17 June 2026, AWS has offered two architectural paths: a customer-managed Knowledge Base with a broad tuning surface, and the new Managed Knowledge Base where AWS owns more of the retrieval stack. Choose that fork before you compare chunk sizes.

The launch of Amazon Bedrock Managed Knowledge Base changed the question from “Which chunking strategy should I use?” to “How much of RAG do I want to operate?” A customer-managed Knowledge Base lets you choose and maintain the vector store, select the embedding model, and use fixed-size, semantic, hierarchical, no chunking, or a custom Lambda transformation. A Managed Knowledge Base owns ingestion, storage, indexing, and retrieval infrastructure, with a managed embedding model by default and agentic retrieval available.

That convenience deliberately narrows ingestion tuning. In the current Managed Knowledge Base setup, the text choices are default fixed-size chunking, configurable fixed-size chunking, or NONE for documents you have already split. Semantic chunking is explicitly unsupported, and hierarchical chunking is not offered. So the 2026 decision is architectural: accept opinionated retrieval in exchange for less infrastructure, or keep the customer-managed path when chunking behavior is part of your product advantage.

Before upgrading the model, inspect what retrieval is actually putting into its context window.

Chunking is usually the retrieval lever.

A chunk is the unit the retriever can find and pass downstream. Make it too large and a good sentence is embedded alongside several unrelated ones. The vector becomes a blurred average, retrieval brings noise, and generation spends context budget reading around the answer. Make it too small and the match may be precise but useless: the exception is retrieved without the rule, the metric without its date range, or the API parameter without the method it configures.

A larger model cannot recover context that retrieval never supplied. It may write a more fluent guess, which is worse. When a RAG answer is vague or confidently wrong, inspect the retrieved chunks first: did the right source appear, did it contain enough surrounding meaning, and how much irrelevant text arrived with it?

Treat the data source as a one-way door.

Bedrock asks for chunking when the data source is created. AWS states that you cannot change the strategy after connecting the source, and the UpdateDataSource API requires the existing configuration. In practice, testing another strategy means creating a replacement data source and ingesting the corpus again. HashiCorp marks the corresponding Terraform fields Forces new resource for the same reason.

Put the strategy and its parameters in infrastructure code, retain the evaluation results that justified them, and budget for parallel indexes during a production migration. Do not discover this constraint after the first million documents are embedded.

Choose the strategy from the document shape.

Default: establish a baseline

On a customer-managed data source, omitting chunkingConfiguration produces chunks of roughly 300 tokens while preserving sentence boundaries. Managed Knowledge Bases define their default as 300-token fixed-size chunks with 20% overlap. Use the default to get a baseline quickly. Avoid treating it as an AWS-certified optimum; it knows nothing about your queries or document structure.

FIXED_SIZE: predictable and cheap

Use when: the corpus is uniform prose—FAQs, policies, runbooks, or product documentation with sections of similar density. Set a maximum token count and an overlap percentage. Start around 300–500 tokens with 10–20% overlap, then measure. Avoid when: one file abruptly switches among unrelated subjects; equal-length chunks can combine the end of one topic with the start of another.

SEMANTIC: follow changes in meaning

Use when: meeting transcripts, case histories, research notes, or exports interleave topics and their boundaries are not reliably marked. Bedrock compares neighboring sentences and splits at semantic discontinuities. You control a maximum token count, a zero-or-one-sentence buffer, and a breakpoint percentile. Avoid when: headings already provide strong structure, ingest cost is sensitive, or the corpus is mostly code and tables. AWS charges additional model cost for semantic chunking, and it remains unavailable in Managed Knowledge Bases.

HIERARCHICAL: retrieve precisely, answer with context

Use when: long manuals, standards, contracts, and technical guides have clean section hierarchy. Configure one larger parent level and one smaller child level. Bedrock searches the children, then replaces a matched child with its parent so the model receives the surrounding section. Avoid when: documents do not have coherent parent sections, extra returned context hurts more than it helps, or you use an S3 vector bucket—AWS does not recommend that combination.

That last detail causes confusing tests. numberOfResults selects child matches; it does not guarantee the same number of final parents. If several children belong to one parent, Bedrock deduplicates them into that parent. Ask for ten and you may receive six without anything being broken.

NONE: bring your own boundaries

Use when: an upstream pipeline already produces one retrieval-ready file per article, ticket, clause, or code symbol. Bedrock treats each file as one chunk. Avoid when: source files are large or inconsistently shaped. Also note that NONE removes page-number citations and the corresponding page-number metadata filter.

Custom Lambda: when boundaries encode domain knowledge

Custom chunking is for boundaries Bedrock cannot infer reliably: preserving a table with its caption, keeping code signatures with docstrings, or attaching access and product metadata to every chunk. Select NONE, configure a transformation Lambda, and provide an S3 location for intermediate input and output. The Lambda writes chunked files back and returns their references.

{
  "chunkingConfiguration": { "chunkingStrategy": "NONE" },
  "customTransformationConfiguration": {
    "intermediateStorage": {
      "s3Location": { "uri": "s3://my-kb-transform/chunks/" }
    },
    "transformations": [{
      "stepToApply": "POST_CHUNKING",
      "transformationFunction": {
        "transformationLambdaConfiguration": {
          "lambdaArn": "arn:aws:lambda:eu-west-1:123456789012:function:chunk-kb"
        }
      }
    }]
  }
}

The honest trade-off is another production component: Lambda execution, S3 I/O, permissions, observability, failure handling, and longer ingestion. Use it when the measurable retrieval gain pays that bill, not because a custom splitter feels more sophisticated.

A decision table worth testing, not worshipping.

These are starting hypotheses for English text. Token density, parser output, model, query style, and answer length can all move the optimum.

Verify with retrieval evidence, not vibes.

Build a small evaluation set before comparing strategies. Thirty real user questions is enough to expose obvious mistakes: ten direct lookups, ten questions that need surrounding context, and ten ambiguous or cross-section questions. For each one, label the source document and passage that should be retrieved. Keep the questions fixed while you rebuild the candidate data sources.

Measure retrieval hit rate at 5 first: did any of the top five results contain the labelled evidence? Add mean reciprocal rank when result order matters, retrieved tokens per query to expose context bloat, and p95 latency. Then run answer evaluation for groundedness and completeness, but do not let a persuasive generator hide a missed retrieval. Record ingestion time and cost too, especially for semantic or custom chunking.

Change one dimension at a time. Comparing chunking strategy, embedding model, reranker, and prompt simultaneously produces a winner but no reusable knowledge. Promote the smallest configuration that clears your retrieval target, then retest whenever the corpus or query mix changes materially.

Make replacement explicit in Terraform.

This customer-managed example keeps development cheaper and makes the production parameters deliberate. Both environments still require evaluation; the map is a rollout mechanism, not a claim that production documents magically need larger chunks.

variable "environment" {
  type    = string
  default = "dev"

  validation {
    condition     = contains(["dev", "prod"], var.environment)
    error_message = "environment must be dev or prod"
  }
}

locals {
  chunking = {
    dev  = { max_tokens = 300, overlap_percentage = 10 }
    prod = { max_tokens = 500, overlap_percentage = 15 }
  }[var.environment]
}

resource "aws_bedrockagent_data_source" "docs" {
  knowledge_base_id = aws_bedrockagent_knowledge_base.docs.id
  name              = "docs-${var.environment}"

  data_source_configuration {
    type = "S3"
    s3_configuration {
      bucket_arn = aws_s3_bucket.docs.arn
    }
  }

  vector_ingestion_configuration {
    chunking_configuration {
      chunking_strategy = "FIXED_SIZE"
      fixed_size_chunking_configuration {
        max_tokens         = local.chunking.max_tokens
        overlap_percentage = local.chunking.overlap_percentage
      }
    }
  }
}

The Terraform resource documentation supports FIXED_SIZE, SEMANTIC, HIERARCHICAL, and NONE. Changing the chunking block replaces this resource, so review the plan for re-ingestion impact and use a parallel data source when downtime is not acceptable.

What I would do.

I would start with Managed Knowledge Base when the goal is to ship reliable enterprise search without owning another datastore, and I would leave its default chunking alone until the eval set proves a problem. I would choose customer-managed only when I need a specific vector store, semantic or hierarchical chunking, or domain-aware Lambda transformations—and when the measured lift is worth operating them. For ordinary customer-managed prose, I would begin with 300-token default and fixed-size baselines, run the same thirty questions against both, and let retrieval hit rate earn every extra moving part.

Chunking is not preprocessing trivia. It defines what your RAG system is capable of finding, what it can afford to read, and which facts survive the trip to the model.