标签：#bedrock

AWS released Managed Knowledge Bases for Amazon Bedrock on 17 June 2026. The feature significantly reduces the operational complexity of building Retrieval-Augmented Generation (RAG) solutions by allowing Bedrock to manage the vector storage, indexing, embeddings, and retrieval infrastructure on your behalf. For teams looking to deliver an Agent Core proof of concept or their first production RAG workload quickly, this can be a compelling option. However, there are some important trade-offs to understand before committing to the managed approach. Traditionally, a Bedrock Knowledge Base required a customer-managed vector store such as: OpenSearch Serverless OpenSearch Managed Clusters Aurora PostgreSQL with pgvector Pinecone DocumentDB Other supported vector databases With a Managed Knowledge Base, Bedrock handles the underlying vector infrastructure and embedding model selection for you. Creating one from the AWS CLI is straightforward: aws bedrock-agent create-knowledge-base \ --name "my-managed-kb" \ --role-arn "arn:aws:iam:: ${ AWS_ACCOUNT_ID } :role/service-role/AmazonBedrockExecutionRoleForKnowledgeBase_ihv1p" \ --knowledge-base-configuration '{ "type": "MANAGED", "managedKnowledgeBaseConfiguration": { "embeddingModelType": "MANAGED" } }' Advantages Lower operational overhead There is no need to provision, secure, monitor, patch, or scale a separate vector database. Lower costs S3 storage is cheaper than database storage. Pay only for each ingestion and retrieval operation. Indexing and searching compute is free. No 24/7 server costs. Faster time-to-value Managed Knowledge Bases make it possible to stand up a RAG solution in minutes rather than days. Automatic embedding management Bedrock manages embedding selection and indexing, reducing the number of architectural decisions required from development teams. Cost-effective for smaller workloads The managed model can be attractive for: Proofs of Concept Departmental knowledge bases Agent Core pilots Workloads wi

Provisioning a Bedrock RAG knowledge base with S3 Vectors, without the hallucinated API calls. If you've asked an AI coding agent to set up AWS, you've seen it confidently invent a parameter, reach for a deprecated service, or burn ten minutes retrying against a service it never saw in training. The failure mode that bites hardest is the silent one: the agent thinks it succeeded, and you find out an hour later. I hit two of these while standing up the retrieval layer for a LangGraph support bot, an Amazon Bedrock Knowledge Base backed by Amazon S3 Vectors. I'd love to say I caught both with deep AWS expertise. I caught them because the Agent Toolkit for AWS read the docs I hadn't. Both would have shipped, and neither did. The 30-second setup The goal: take a folder of markdown product docs and make them queryable by meaning, so an agent can answer "is this safe for color-treated hair?" from the real docs instead of guessing. Think of it as giving the agent a library it can search instead of making things up. That's the retrieval half of RAG, the foundation a LangGraph agent will later call as a tool. Four moving parts, wrapped in one managed service: Source bucket : an S3 bucket holding the docs. Embeddings : Amazon Titan Text Embeddings V2 (1024-dim vectors). Vector store : Amazon S3 Vectors. I chose it over OpenSearch Serverless because it has no always-on compute, the difference between cents and a monthly surprise for a demo that sits idle. Knowledge Base : Amazon Bedrock Knowledge Bases ties it together into one thing you can query with a retrieve call. To follow along, you need an AWS account, a non-root IAM identity with credentials configured locally, uv installed, and the toolkit installed in your agent. The fastest path across Kiro, Claude Code, Cursor, and Codex is the AWS CLI installer, aws configure agent-toolkit ; in Kiro you can instead add the AWS MCP Server to .kiro/settings/mcp.json (pin the mcp-proxy-for-aws version) and run npx skills add aws/age

My AWS Bedrock Experiment Cost Me $8.43 in Just One Day What I learned about AWS Bedrock pricing the hard way, and why budget alerts saved me Why I Even Tried Claude Code on Bedrock I have been using Claude Code for a while now, connected to Anthropic directly. It works well. But two things were bothering me. First, the usage limits. Claude Code on Anthropic's native setup has 5hours session limit and a weekly usage cap. Once you hit it, you have to wait. If you are in the middle of something or just want to experiment freely, that gets frustrating fast. Second, billing. I already manage everything on AWS. I'm very familiar with it, the invoices go to one place, and I understand how to track and control costs there. Adding a separate Anthropic subscription meant one more billing account, one more credit card charge, one more thing to track. I just wanted everything under one roof. So I thought, why not try Claude Code connected to Amazon Bedrock? Same tool, runs on AWS, billed through AWS. Seemed like a clean solution to both problems. What happened next is why I am writing this post. The Two Ways to Run Claude Code Most people do not realise Claude Code can be configured to run in two different ways. Option 1: Claude Code via Anthropic directly You connect Claude Code to Anthropic's API or use it under your Claude subscription. Billing goes through Anthropic. If you are on a subscription plan, you pay a flat monthly fee and the usage limits apply to how much you can do within that. Option 2: Claude Code via Amazon Bedrock You connect Claude Code to AWS Bedrock as the backend. Same Claude models, but now AWS is your provider. Billing goes through your AWS account. No Anthropic subscription needed. From the outside, it looks and feels the same. But the billing model underneath is completely different, and that is where things get interesting. What Happened When I Tried It I set up Claude Code to use Bedrock and gave it a prompt. A fairly detailed one, nothing unusual