Bedrock Knowledge Bases End to End

Amazon Bedrock Knowledge Bases is the managed RAG pipeline in Bedrock. You point it at data you already have, tell it which embedding model and which vector store to use, and it handles ingestion, chunking, embedding and indexing. You then query it with a single API call. The value is that you do not write or operate the ingestion pipeline yourself.

The five moving parts

1. Data source. Where the raw documents live. Amazon S3 is the common case; there are also connectors for Confluence, Salesforce, SharePoint and a web crawler, a custom data source you push documents into directly through the API, and structured-data sources that query a SQL store instead of embedding anything. A knowledge base can have more than one data source, each with its own configuration.
2. Chunking. Documents are split into passages before embedding, because an embedding of a whole 80-page PDF is too blurry to match anything. You choose the strategy per data source.
3. Embedding model. Each chunk is converted into a vector. Amazon Titan Text Embeddings and Cohere Embed are the usual choices. Titan Text Embeddings V2 lets you pick the output dimension, which trades index size against precision.
4. Vector store. Where the vectors, the chunk text and the metadata are written. Bedrock does not host this for you in the general case — you supply an OpenSearch Serverless collection, an Aurora PostgreSQL cluster, or one of the other supported stores, and Bedrock writes into it.
5. Sync (ingestion job). Nothing happens until you start an ingestion job. It walks the data source, chunks, embeds and indexes. Subsequent syncs are incremental: new and changed files are re-processed, deleted files have their vectors removed.

What you own versus what Bedrock owns

Bedrock owns the pipeline logic. You own the bucket, the vector store, the encryption keys and the IAM service role that lets Bedrock read the source and write the index. That role is the usual first failure: the knowledge base creates fine and then the ingestion job fails because the role cannot read the S3 prefix or reach the collection. In OpenSearch Serverless you also need a data access policy granting the role index permissions — an IAM policy alone is not enough.

The sync model

Ingestion is a batch job, not a stream. A document dropped into S3 is invisible to retrieval until the next sync runs, so freshness is bounded by how often you sync. Trigger jobs on a schedule, or event-driven from S3 notifications through Lambda or EventBridge. For genuinely low-latency writes, the custom data source lets you ingest documents directly through the API without waiting for a crawl.

Each ingestion job reports counts of documents scanned, indexed and failed. Failures are per-document — a corrupt PDF does not fail the job — so check the counts rather than only the job status.

The trade-off

Managed means opinionated. The chunking and embedding configuration is fixed at creation time: you cannot change a data source's chunking strategy after you create it, and changing the embedding model means a new index, because vectors from different models are not comparable. Both changes mean recreating and re-ingesting. Decide chunking and embedding deliberately before you load a large corpus, or accept a full rebuild later.

import boto3

agent = boto3.client("bedrock-agent")

kb = agent.create_knowledge_base(
    name="policy-docs-kb",
    roleArn="arn:aws:iam::111122223333:role/AmazonBedrockExecutionRoleForKnowledgeBase_policy",
    knowledgeBaseConfiguration={
        "type": "VECTOR",
        "vectorKnowledgeBaseConfiguration": {
            "embeddingModelArn": (
                "arn:aws:bedrock:eu-west-1::foundation-model/amazon.titan-embed-text-v2:0"
            ),
            "embeddingModelConfiguration": {
                "bedrockEmbeddingModelConfiguration": {"dimensions": 1024}
            },
        },
    },
    storageConfiguration={
        "type": "OPENSEARCH_SERVERLESS",
        "opensearchServerlessConfiguration": {
            "collectionArn": "arn:aws:aoss:eu-west-1:111122223333:collection/abc123xyz",
            "vectorIndexName": "bedrock-kb-index",
            "fieldMapping": {
                "vectorField": "bedrock-kb-vector",
                "textField": "AMAZON_BEDROCK_TEXT_CHUNK",
                "metadataField": "AMAZON_BEDROCK_METADATA",
            },
        },
    },
)
kb_id = kb["knowledgeBase"]["knowledgeBaseId"]

ds = agent.create_data_source(
    knowledgeBaseId=kb_id,
    name="s3-published-policies",
    dataSourceConfiguration={
        "type": "S3",
        "s3Configuration": {
            "bucketArn": "arn:aws:s3:::acme-policy-docs",
            "inclusionPrefixes": ["published/"],
        },
    },
    vectorIngestionConfiguration={
        "chunkingConfiguration": {
            "chunkingStrategy": "FIXED_SIZE",
            "fixedSizeChunkingConfiguration": {
                "maxTokens": 300,
                "overlapPercentage": 20,
            },
        }
    },
)

# Nothing is searchable until a sync runs.
job = agent.start_ingestion_job(
    knowledgeBaseId=kb_id,
    dataSourceId=ds["dataSource"]["dataSourceId"],
)
print(job["ingestionJob"]["status"])