Bedrock Chat: A Self-Hosted Multi-Tenant Chatbot on Amazon Bedrock

The gap Bedrock Chat fills: chat plus RAG plus agents inside one AWS account

Most teams that want a Bedrock-backed assistant face the same fork. They can call the Bedrock API from a thin internal tool and own every piece of retrieval, user management and audit themselves, or they can buy a hosted chat product and lose control of where prompts and documents travel. Bedrock Chat sits between those options. It is an AWS sample, not a product, and it ships the whole stack: a React front end, a FastAPI backend, Cognito for identity, and DynamoDB for conversation and bot state. The README describes it as a multilingual platform supporting chat, custom bots with knowledge (RAG), bot sharing through a bot store, and task automation using agents. The audience is therefore specific. It is for engineers who have already decided their data stays in their own AWS account, and who would rather extend a working reference implementation than design one from a blank repository. It is not for someone who wants a chat UI by Friday and has no appetite for CloudFormation outputs, user pool groups or Step Functions state machines.

Architecture: Cognito identity, DynamoDB bot records, Step Functions ingestion

The repository layout and README make the data flow legible. Users authenticate through an Amazon Cognito user pool; the README points administrators to CloudFormation, BedrockChatStack, Outputs, AuthUserPoolIdxxxx to find the pool id. Bot definitions and conversation records live in DynamoDB tables, and the README refers to a BotTableV3 and a per-user partition key pattern of PK='$UserID' AND SK='BOT#$BotID' in its own migration command. Ingestion is asynchronous. The README's bulk migration snippet sets SyncStatus='QUEUED' on bot records and then starts a Step Functions execution against an embedding state machine, which implies a queue-then-embed pipeline rather than synchronous indexing at upload time. Retrieval defaults to OpenSearch Serverless, which is why the README constrains deployment regions to those where OpenSearch Serverless and the ingestion APIs exist. The front end talks to the backend over WebSockets for streaming responses, one of the repository topics. Two design consequences follow. First, the region list is not a suggestion: deploy outside it and bots and knowledge bases have no default vector store. Second, because ingestion is queued, a freshly uploaded document is not instantly searchable, and the SyncStatus field is the thing to watch rather than the upload response.

Multi-tenant Knowledge Base mode and the 100 KB account limit

This is the most interesting design decision in the project. Amazon Bedrock Knowledge Bases caps an account at 100 knowledge bases by default, and Bedrock Chat's answer is a shared-tenant mode. Rather than one knowledge base per bot, a single knowledge base with common settings is shared across bots, and files uploaded by each bot are filtered by attaching the Bot ID as metadata. The README states that newly created bots have multi-tenant mode enabled by default, and that existing bots migrate by changing the bot's knowledge settings to "Create a tenant in a shared Knowledge Base." Bulk migration is done with a DynamoDB PartiQL statement that sets BedrockKnowledgeBase.type='shared' and SyncStatus='QUEUED', followed by a Step Functions execution to re-embed. The trade-off is real and the README does not hide it: metadata filtering is now the isolation boundary. If your threat model requires physical separation between two bots' documents, shared mode is the wrong setting and you should keep dedicated knowledge bases, accepting the 100-per-account ceiling. The default is convenient for demos and internal tools; it is a decision worth making explicitly rather than inheriting.

Getting it running: bin.sh, CloudShell and the parameters you must set

Deployment is deliberately short. The README's path is to open CloudShell in the target region, clone the repository, and run the provided script: git clone https://github.com/aws-samples/bedrock-chat.git, cd bedrock-chat, chmod +x bin.sh, ./bin.sh. Before that, in us-east-1, you enable model access through the Bedrock console under Manage model access and save the changes. The script prompts whether you are a new user or continuing from v3, and the README points to Optional Parameters for pinning a version or applying security policies. Two parameters matter most. bedrock-region must be a region where Bedrock itself is available, which is not the same list as the OpenSearch Serverless regions. And the deployment region must support OpenSearch Serverless and ingestion APIs if you want bots and knowledge bases. Governance is configured outside the deploy script: creating customized bots requires membership in a Cognito group named CreatingBotAllowed, set up through the Cognito console or the AWS CLI. If you skip that step, bot creation is restricted, which is the intended default rather than a bug. The README also offers a workshop link for a guided walkthrough.

The V2 to V3 upgrade is the sharpest edge in this project

The README carries a warning block that is unusual in its directness: V3 released, review the migration guide at docs/migration/V2_TO_V3.md, and without care, bots from V2 will become unusable. That sentence should drive your upgrade plan. The table names changed to a V3 suffix, the bot record schema carries a BedrockKnowledgeBase field with a type of shared or otherwise, and the migration path involves editing records and re-running embedding through Step Functions. There is no in-place compatibility shim described in the supplied material. If you run Bedrock Chat in production and your users have accumulated bots and uploaded documents, treat the upgrade as a data migration with a rollback plan, not a version bump. The release cadence visible in the repository is steady (v3.15.6, v3.16.0 and v3.17.0 between April and June 2026), so pinning a tag rather than tracking the default branch is the safer posture for anyone who cannot absorb a schema change on short notice. The README does not describe an automated downgrade path, so back up the DynamoDB tables before you start.

Where Bedrock Chat is the wrong tool, and what to compare it against

Bedrock Chat assumes AWS. If your documents live in Google Cloud storage, your identity provider is Okta rather than Cognito, or your team has no CDK experience, the sample's convenience evaporates and you are maintaining a multi-service stack you did not design. Compare it with Dify, an open source LLM application platform that ships its own model abstraction layer and supports providers beyond Bedrock. The difference in approach is the point: Dify is model-agnostic and runs its own orchestration, so you can point it at OpenAI, Anthropic's API directly, or a local model, and you are not tied to a single cloud's identity and vector services. Bedrock Chat is the opposite bet. It gives up provider portability in exchange for tight integration with Cognito, DynamoDB, Step Functions and OpenSearch Serverless, and for the ability to call Bedrock models under your existing AWS agreements and IAM boundaries. If your requirement is "one chat interface across whichever model is cheapest this quarter," Dify's model layer is a better starting point. If your requirement is "the assistant runs inside our AWS account with our IAM and our VPC story," Bedrock Chat's coupling is the feature, not the cost.

Licence, maintenance and what you are actually signing up for

The repository is MIT-0, which is the permissive MIT licence with the attribution requirement removed. In practice that means you can take the code, modify it and ship it in a commercial product without carrying a notice file, subject to the usual absence of warranty. This is not legal advice; confirm the terms with your own counsel if the deployment is customer-facing. The maintenance cost is the part engineers underestimate. You are running a CDK application, not a container you can restart. Upgrades can change DynamoDB schemas and table names, as the V2 to V3 migration shows. The stack depends on Bedrock model access, OpenSearch Serverless capacity and Step Functions executions, so your AWS bill scales with ingestion and retrieval volume rather than seat count, and the README gives no cost figures. There is also no homepage listed for the project, so the repository and its docs directory are the documentation. Before adopting, read docs/ADMINISTRATOR.md for the API management and analytics features, docs/AGENT.md for the agent behaviour, and docs/PUBLISH_API.md if you intend to expose a bot as a standalone API, since that path changes your authentication surface.

Editorial conclusion

Adopt Bedrock Chat if you already run workloads in a supported AWS region and want chat, RAG bots and agent tasks inside your own account rather than in a vendor's. Do not adopt it if you cannot accept a CDK stack spanning Cognito, DynamoDB, Step Functions and OpenSearch Serverless, or if you are upgrading a live V2 deployment without reading docs/migration/V2_TO_V3.md first, since the README warns that V2 bots become unusable. Verify three things before committing: that your target region appears in the OpenSearch Serverless ingestion list, that the CreatingBotAllowed Cognito group exists so non-admins cannot create bots, and whether newly created bots default to shared Knowledge Base mode, which changes how uploaded files are filtered.

Official sources

1. aws-samples/bedrock-chat on GitHub
2. Issues
3. License: MIT-0
4. README
5. Releases