{"slug": "choosing-amazon-bedrock-managed-knowledge-bases-an-architecture-decision-in-my", "title": "Choosing Amazon Bedrock Managed Knowledge Bases: An Architecture Decision in My RAG Application", "summary": "A developer building an internal AI assistant chose Amazon Bedrock Managed Knowledge Bases over a self-managed RAG pipeline, delegating document parsing, chunking, embedding generation, indexing, and retrieval to the managed AWS service. The application retains responsibility for business logic, orchestration, model invocation, and user experience, with source documents kept in Amazon S3. The developer argues the managed Knowledge Base should not be viewed as merely a vector database, since it absorbs most of the RAG data pipeline.", "body_md": "When I started designing the RAG architecture for the internal AI assistant project, one of the first decisions I had to make was:\n\n**Where should the application's knowledge live, and which component should be responsible for turning that knowledge into something the model can retrieve?**\n\nThere are several ways to build a RAG system on AWS.\n\nI could assemble and manage the retrieval components myself, use a vector database directly, or use Amazon Bedrock Knowledge Bases to manage much of the RAG data pipeline.\n\nDuring the project, I explored the architecture from both perspectives before settling on an Amazon Bedrock Managed Knowledge Base.\n\nThis article explains that decision and the technical tradeoffs behind it.\n\nThe application needed to answer questions using internal company documents.\n\nThe source documents included:\n\n```\nBrand Guidelines\nScript Bank\nCaption Bank\nClient Proposal Template\n```\n\nMy initial mental model was:\n\n```\nDocuments\n ↓\nAmazon S3\n ↓\nVector Storage\n ↓\nSimilarity Search\n ↓\nFoundation Model\n ↓\nResponse\n```\n\nBut implementing that architecture means taking responsibility for considerably more than vector storage.\n\nThe complete pipeline involves:\n\n```\nDocument ingestion\n ↓\nDocument parsing\n ↓\nChunking\n ↓\nEmbedding generation\n ↓\nVector indexing\n ↓\nMetadata\n ↓\nSimilarity search\n ↓\nRetrieval\n ↓\nContext construction\n ↓\nModel invocation\n ↓\nSource attribution\n```\n\nAt that point, the most important architectural question became:\n\n**Which parts of the RAG pipeline should my application own, and which parts should I delegate to a managed AWS service?**\n\nThat question led me toward Amazon Bedrock Managed Knowledge Bases.\n\nAmazon Bedrock Knowledge Bases provides a managed abstraction for building RAG applications.\n\nInstead of my application owning every component of the retrieval pipeline, the architecture becomes:\n\n```\n Company Documents\n │\n ▼\n Amazon S3\n │\n ▼\n ┌───────────────────────┐\n │ Amazon Bedrock │\n │ Managed Knowledge │\n │ Base │\n │ │\n │ Parsing │\n │ Chunking │\n │ Embeddings │\n │ Indexing │\n │ Retrieval │\n └───────────┬───────────┘\n │\n Relevant Context\n │\n ▼\n Application Layer\n │\n ▼\n Foundation Model\n │\n ▼\n Response\n```\n\nThat creates a significantly different responsibility boundary.\n\nMy application remains responsible for the business logic, orchestration, model invocation, and user experience.\n\nThe Knowledge Base handles much of the document ingestion and retrieval pipeline.\n\nIt is important not to think of a managed Knowledge Base as simply \"a vector database.\"\n\nThat misses most of the abstraction it provides.\n\nDuring ingestion, Amazon Bedrock processes the source content, splits it into chunks, generates embeddings, and indexes the resulting vectors for retrieval while maintaining their relationship to the source documents.\n\nConceptually:\n\n```\nSource Document\n │\n ▼\n Parsing\n │\n ▼\n Chunking\n │\n ▼\n Embeddings\n │\n ▼\n Vector Index\n │\n ▼\n Retrieval\n```\n\nThis means the Knowledge Base owns a substantial portion of the RAG data pipeline that would otherwise have to be implemented and operated by the application.\n\nI wanted the original company documents to remain in an object-storage layer rather than making the vector index the primary source of truth.\n\nAmazon S3 became that source layer.\n\nThe document structure was:\n\n```\nai-creative-content/\n\n├── brand-guidelines/\n├── past-scripts/\n├── captions/\n└── proposals/\n```\n\nThis gives the architecture a clear separation:\n\n```\nS3\n│\n└── Original company documents\n\nKnowledge Base\n│\n└── Searchable representation of those documents\n```\n\nThe S3 data source can be configured with inclusion prefixes, allowing the Knowledge Base to process specific paths within the bucket. It also supports synchronization when documents are added, modified, or deleted.\n\nThat separation became particularly useful because the original documents remain easy to manage independently of the retrieval layer.\n\nAt the AWS API level, the Knowledge Base data source can be configured with an S3 bucket and optional inclusion prefixes.\n\nFor example:\n\n```\n{\n \"s3Configuration\": {\n \"bucketArn\": \"arn:aws:s3:::ai-creative-content\",\n \"inclusionPrefixes\": [\n \"brand-guidelines/\",\n \"past-scripts/\",\n \"captions/\",\n \"proposals/\"\n ]\n },\n \"type\": \"S3\"\n}\n```\n\nThe important part is that the Knowledge Base is not simply scanning an arbitrary bucket.\n\nThe data source configuration tells Bedrock which S3 location contains the documents that belong to the Knowledge Base.\n\nThe S3 bucket and Knowledge Base also need to satisfy the regional requirements, and the Knowledge Base service role needs permission to access the configured data source.\n\nUploading a document to S3 is only the beginning.\n\nThe document must be ingested into the Knowledge Base before it can participate in retrieval.\n\nThe high-level flow is:\n\n```\nPDF\n │\n ▼\nAmazon S3\n │\n ▼\nKnowledge Base Data Source\n │\n ▼\nIngestion Job\n │\n ├── Parse\n ├── Chunk\n ├── Generate Embeddings\n └── Index\n │\n ▼\nQueryable Knowledge Base\n```\n\nIngestion transforms the source content into representations that can be searched semantically.\n\nThis distinction is important:\n\n```\nS3 upload\n ≠\nKnowledge Base ingestion\n```\n\nA document existing in S3 does not automatically mean it is available for retrieval.\n\nOnce the S3 data source is configured, an ingestion job can be started through the AWS Console or CLI.\n\n```\naws bedrock-agent start-ingestion-job \\\n --knowledge-base-id \\\n --data-source-id \\\n --region us-east-1\n```\n\nThe command starts an ingestion job for the specified Knowledge Base and data source.\n\nThe response includes an ingestion job ID, which can then be used to monitor the job:\n\n```\naws bedrock-agent get-ingestion-job \\\n --knowledge-base-id \\\n --data-source-id \\\n --ingestion-job-id \\\n --region us-east-1\n```\n\nThe operational flow is therefore:\n\n```\nStartIngestionJob\n │\n ▼\nIngestion Job\n │\n ▼\nMonitor Status\n │\n ▼\n COMPLETE\n │\n ▼\nKnowledge Base Ready\nfor Retrieval\n```\n\nThis became an important operational distinction during the project.\n\nWhen troubleshooting RAG, I could no longer assume that:\n\n```\n\"The file exists in S3\"\n```\n\nmeant:\n\n```\n\"The Knowledge Base can retrieve it.\"\n```\n\nThe document has to successfully pass through the ingestion pipeline first.\n\nAnother useful property of the S3 data source is incremental synchronization.\n\nSuppose the Knowledge Base already contains:\n\n```\nBrand Guidelines\nScript Bank\nCaption Bank\nProposal Template\n```\n\nThen the caption bank is updated.\n\nThe architecture does not require me to manually rebuild the entire retrieval system.\n\nAfter synchronization, the affected content can be reprocessed:\n\n```\n Existing Knowledge Base\n │\n Document Change\n │\n ▼\n Amazon S3\n │\n ▼\n Sync\n │\n ▼\n Detect Changed Content\n │\n ▼\n Re-process Content\n │\n ┌────────┼────────┐\n ▼ ▼ ▼\n Parsing Chunking Embedding\n │\n ▼\n Index\n │\n ▼\n Updated Knowledge Base\n```\n\nThis is one of the operational advantages of using a managed data source rather than implementing a custom document synchronization pipeline.\n\nChunking is one of the most important stages of the ingestion process.\n\nA document can contain hundreds or thousands of lines. Treating the entire document as one retrieval unit makes precise retrieval difficult.\n\nInstead, the document is divided into smaller chunks.\n\n```\nBrand Guidelines\n │\n ├── Chunk 1: Company overview\n ├── Chunk 2: Brand positioning\n ├── Chunk 3: Brand voice\n ├── Chunk 4: Social media guidelines\n ├── Chunk 5: Visual identity\n └── ...\n```\n\nAmazon Bedrock supports multiple chunking strategies, including fixed-size, hierarchical, semantic, and no-chunking configurations depending on the Knowledge Base setup.\n\nThe resulting chunks are then embedded and indexed for retrieval.\n\nThis is an important architectural detail because retrieval quality is influenced not only by the vector store, but also by how the original documents were divided before indexing.\n\nAfter chunking, each chunk needs a numerical representation that allows semantic similarity to be calculated.\n\n```\nDocument Chunk\n │\n ▼\nEmbedding Model\n │\n ▼\nVector Representation\n │\n ▼\nVector Index\n```\n\nAt query time, the user's question is also represented in a form that can be compared against the indexed content:\n\n```\nUser Question\n │\n ▼\nQuery Representation\n │\n ▼\nSimilarity Search\n │\n ▼\nRelevant Chunks\n```\n\nThe Knowledge Base uses the embedding configuration selected during its creation to generate the vector representations used for retrieval.\n\nThis is another responsibility I did not have to implement as a separate application pipeline.\n\nOnce ingestion succeeds, the Knowledge Base can be queried.\n\nSuppose a staff member asks:\n\n\"What tone should our social media captions use?\"\n\nThe retrieval flow becomes:\n\n```\nUser Question\n │\n ▼\nKnowledge Base\n │\n ▼\nSemantic Retrieval\n │\n ├── Brand Guidelines chunk\n ├── Caption Bank chunk\n └── Other relevant chunk\n │\n ▼\nRetrieved Context\n```\n\nAmazon Bedrock provides the `Retrieve` operation for retrieving source chunks relevant to a query.\n\nThis was important to my architecture because I wanted retrieval to remain an explicit stage of the application flow rather than hiding it behind a single black-box operation.\n\nThe number of chunks retrieved is another configuration decision.\n\nFor managed Knowledge Bases, `numberOfResults` controls the maximum number of source chunks returned. The actual number can be lower if fewer relevant results are available.\n\n```\n{\n \"retrievalConfiguration\": {\n \"managedSearchConfiguration\": {\n \"numberOfResults\": 5\n }\n }\n}\n```\n\nThe important word is **maximum**.\n\nSetting:\n\n```\nnumberOfResults = 5\n```\n\ndoes not mean:\n\n```\nAlways return exactly five chunks.\n```\n\nIt means:\n\n```\nReturn up to five relevant chunks.\n```\n\nMore retrieved content is not automatically better.\n\nIf a question can be answered using two highly relevant chunks, adding several loosely related chunks may introduce unnecessary context into the model prompt.\n\nSo retrieval count becomes a tuning parameter influenced by:\n\n```\nDocument structure\nChunking strategy\nQuestion complexity\nRetrieval quality\nModel context requirements\n```\n\nAnother important architectural distinction is separating retrieval from generation.\n\nThe Knowledge Base can retrieve the relevant source material, while the application remains responsible for passing that context to the foundation model.\n\nFor my architecture:\n\n```\nUser Question\n │\n ▼\nRetrieve\n │\n ▼\nRelevant Chunks\n │\n ▼\nApplication Orchestrator\n │\n ▼\nClaude Sonnet 4.5\n │\n ▼\nGenerated Response\n```\n\nThis separation gives the application control over how retrieved information is incorporated into the model request.\n\nIt also makes the system easier to debug.\n\nInstead of treating the final answer as one opaque operation, I can inspect two separate stages:\n\n```\nRetrieval\n ↓\nDid I retrieve the right information?\n\nGeneration\n ↓\nDid the model produce the right answer from that information?\n```\n\nThose are fundamentally different failure modes.\n\nThe application was not intended to be an autonomous agent.\n\nIt was designed as an internal creative assistant with human review.\n\nSo I wanted the architecture to remain explicit:\n\n```\nStaff\n │\n ▼\nApplication\n │\n ▼\nRetrieve Company Knowledge\n │\n ▼\nConstruct Context\n │\n ▼\nClaude\n │\n ▼\nDraft Response\n │\n ▼\nHuman Review\n```\n\nThis creates a clear boundary between:\n\n```\nRetrieval\n```\n\nand:\n\n```\nGeneration\n```\n\nThat boundary is useful both architecturally and operationally.\n\nIf an answer is incorrect, I can investigate whether:\n\nThat is much more actionable than simply knowing that \"the AI got it wrong.\"\n\nRetrieval should also remain observable.\n\nA useful RAG system should allow the application to understand where retrieved information came from.\n\nThe `Retrieve` response includes the retrieved source content and source-location information.\n\n```\nGenerated Response\n │\n ├── Source: Brand Guidelines\n ├── Source: Caption Bank\n └── Source: Script Bank\n```\n\nFor an internal assistant, this provides an additional layer of transparency.\n\nThe employee should not have to blindly trust a generated response. The application should be able to associate the response with the company information used to produce it.\n\nThe biggest advantage was a clearer responsibility boundary.\n\nMy application owns:\n\n```\nAuthentication\nAPI\nApplication Logic\nPrompt Construction\nModel Invocation\nUser Interface\nHuman Review\nAccess Control\nObservability\n```\n\nThe managed Knowledge Base handles much of:\n\n```\nData Source Integration\nDocument Ingestion\nParsing\nChunking\nEmbedding Generation\nVector Indexing\nRetrieval\n```\n\nThat means fewer retrieval-specific components become part of my application code and operational surface.\n\nChoosing a managed abstraction also means giving up some low-level control.\n\nThat tradeoff is important.\n\n| Lower-level / Self-managed | Managed Knowledge Base | \n|---|---|\n| More direct control over vector infrastructure | Higher-level AWS abstraction | \n| More control over retrieval implementation | Bedrock-managed retrieval | \n| More responsibility for ingestion | Managed ingestion workflow | \n| More infrastructure to configure | Less application-owned infrastructure | \n| More flexibility at the infrastructure layer | Less low-level control | \n| More operational responsibility | Lower operational overhead | \n\nSo I would not describe the managed Knowledge Base as universally better.\n\nThe appropriate architecture depends on the application's requirements.\n\nIf an application required highly customized vector infrastructure or retrieval behavior, a lower-level architecture could make sense.\n\nFor this project, I valued the managed ingestion and retrieval pipeline more than having complete ownership of the underlying vector infrastructure.\n\nAfter working through those tradeoffs, the AI architecture became:\n\n```\n Company Documents\n │\n ▼\n Amazon S3\n │\n ▼\n S3 Data Source\n │\n ▼\n Ingestion / Sync\n │\n ┌─────────────┴─────────────┐\n │ │\n Parsing Chunking\n │ │\n └─────────────┬─────────────┘\n │\n ▼\n Embeddings\n │\n ▼\n Vector Index\n │\n ▼\n Retrieval\n │\n ▼\n Relevant Context\n │\n ▼\n Application Orchestrator\n │\n ▼\n Claude Sonnet 4.5\n │\n ▼\n Draft Response\n │\n ▼\n Human Review\n```\n\nThe broader application architecture was:\n\n```\n Staff User\n │\n ▼\n Cognito\n │\n ▼\n API Gateway\n │\n ▼\n Chat Orchestrator\n │\n ┌──────────┴──────────┐\n │ │\n ▼ ▼\n Bedrock Knowledge Claude Sonnet 4.5\n Base │\n │ │\n └──── Retrieved ───────┘\n Context\n │\n ▼\n Draft Response\n │\n ▼\n Human Review\n```\n\nAnd the knowledge pipeline was:\n\n```\nCompany Documents\n │\n ▼\n S3\n │\n ▼\nKnowledge Base Data Source\n │\n ▼\n Ingestion\n │\n ├── Parsing\n ├── Chunking\n ├── Embeddings\n └── Indexing\n │\n ▼\n Retrieval\n```\n\nIf I had to summarize the decision:\n\n**I chose Amazon Bedrock Managed Knowledge Bases because I wanted AWS to handle much of the operational complexity of the RAG ingestion and retrieval pipeline while my application focused on authentication, orchestration, generation, and the user experience.**\n\nThat is a more useful way to think about managed services than simply saying:\n\n\"AWS has a service that does this for me.\"\n\nThe important architectural question is:\n\n**Where should responsibility live?**\n\nThe biggest lesson was that cloud architecture is not simply about choosing the most powerful service or building everything yourself.\n\nIt is about defining boundaries.\n\n```\nS3\n ↓\nVector Database\n ↓\nLLM\n```\n\nAfter building the system, my mental model became:\n\n```\n SOURCE\n │\n ▼\n S3\n │\n ▼\n INGESTION\n │\n ┌────────┼────────┐\n ▼ ▼ ▼\n Parsing Chunking Embedding\n │\n ▼\n Index\n │\n ▼\n Retrieval\n │\n ▼\n Application\n Context\n │\n ▼\n Claude\n │\n ▼\n Response\n │\n ▼\n Human Review\n```\n\nThat shift was one of the most valuable parts of the architecture decision.\n\nI stopped thinking about RAG as simply:\n\n\"Put documents in a vector database and ask an LLM questions.\"\n\nInstead, I started thinking about it as a pipeline with explicit responsibilities:\n\n```\nStorage\n ↓\nIngestion\n ↓\nRepresentation\n ↓\nRetrieval\n ↓\nContext\n ↓\nGeneration\n ↓\nReview\n```\n\nThat mental model made it much easier to reason about where managed AWS infrastructure could provide value and where application-level control was still necessary.\n\nAmazon Bedrock Managed Knowledge Bases was not simply a shortcut for me.\n\nIt was an architectural choice.\n\nI could have owned more of the ingestion and vector-search infrastructure myself. Instead, I chose to delegate that responsibility to a managed AWS service and keep my application focused on the parts that were specific to the product.\n\nThe resulting responsibility boundaries were:\n\n```\nAmazon S3\n → Source documents\n\nBedrock Knowledge Base\n → Ingestion + retrieval\n\nApplication\n → Orchestration + context construction\n\nClaude\n → Generation\n\nHuman\n → Final review\n```\n\nFor this project, that division of responsibility gave me the balance I was looking for: enough control over application behavior without unnecessarily taking ownership of infrastructure that AWS could manage for me.", "url": "https://wpnews.pro/news/choosing-amazon-bedrock-managed-knowledge-bases-an-architecture-decision-in-my", "canonical_source": "https://dev.to/duubemmm/choosing-amazon-bedrock-managed-knowledge-bases-an-architecture-decision-in-my-rag-application-5afj", "published_at": "2026-09-23 11:32:10+00:00", "updated_at": "2026-09-23 11:59:05.186445+00:00", "lang": "en", "topics": ["ai-infrastructure", "large-language-models", "ai-products", "mlops"], "entities": ["Amazon Bedrock", "Amazon Bedrock Knowledge Bases", "Amazon S3", "AWS"], "alternates": {"html": "https://wpnews.pro/news/choosing-amazon-bedrock-managed-knowledge-bases-an-architecture-decision-in-my", "markdown": "https://wpnews.pro/news/choosing-amazon-bedrock-managed-knowledge-bases-an-architecture-decision-in-my.md", "text": "https://wpnews.pro/news/choosing-amazon-bedrock-managed-knowledge-bases-an-architecture-decision-in-my.txt", "jsonld": "https://wpnews.pro/news/choosing-amazon-bedrock-managed-knowledge-bases-an-architecture-decision-in-my.jsonld"}}