aws-samples/bedrock-chat: a self-hosted Bedrock chat app you deploy into your own AWS account

What Bedrock Chat is, and the problem it removes

The repository describes itself as "a multilingual generative AI platform powered by Amazon Bedrock." The problem it addresses is not model access. Bedrock already gives you that. The problem is everything around it: a chat UI, per-user authentication, conversation history, retrieval over your own documents, and a way to publish a configured assistant to other people. Bedrock Chat packages those pieces as an AWS sample you deploy yourself.

The intended audience is an engineering team that already operates in AWS and wants an internal assistant without assembling a frontend, an identity layer and a vector store from scratch. The README points at Cognito for users, CloudFormation for the deployment, and OpenSearch Serverless as the default knowledge base backend. That is a specific kind of buyer: someone with an AWS account, not someone looking for a chat product to sign up for.

One governance detail is worth reading before anything else. The README states that only allowed users can create customized bots, and that the user must be a member of a Cognito group called `CreatingBotAllowed`. Bot creation is off by default. For a team rolling this out broadly, that group membership is the difference between a chat tool and a platform other people build on.

How the pieces fit: CDK, Cognito, DynamoDB and OpenSearch Serverless

The top level of the repository separates concerns cleanly: `cdk/` for infrastructure, `backend/` for the API, `frontend/` for the React app, `docs/` for the written material, and `examples/` with `agents/` and `notebooks/`. The topics list names FastAPI, React, WebSockets, Lambda and streaming responses, which matches the layout.

The data flow described in the README is worth tracing because it explains the limits later. A user signs in through a Cognito user pool. Bots are stored in DynamoDB; the README's own bulk migration command writes to a table referenced as `$BotTableNameV3` and updates a `BedrockKnowledgeBase.type` field to `'shared'`. Embedding work runs through a Step Functions state machine, referenced as `$EmbeddingStateMachineArn`, which is started explicitly after a bulk update. Retrieval runs against OpenSearch Serverless.

That last choice carries a real constraint. The README says to deploy in a region where OpenSearch Serverless and Ingestion APIs are available if you want bots and knowledge bases, and then lists the supported regions as of August 2025: us-east-1, us-east-2, us-west-1, us-west-2, ap-south-1, ap-northeast-1, ap-northeast-2, ap-southeast-1, ap-southeast-2, ca-central-1, eu-central-1, eu-west-1, eu-west-2, eu-south-2, eu-north-1 and sa-east-1. Separately, the `bedrock-region` parameter must point at a region where Bedrock itself is available. Those are two different region checks, and a deployment can satisfy one and fail the other.

Deploying Bedrock Chat from CloudShell and opening the UI

The README's deployment path assumes CloudShell in the region you want to deploy to, and it starts with a manual console step rather than a command. In us-east-1 you open Bedrock Model access, choose Manage model access, check the models you want, and save. Nothing in the stack grants that access for you.

After that, the documented sequence clones the repository, enters the directory, makes the script executable and runs it:

git clone https://github.com/aws-samples/bedrock-chat.git
cd bedrock-chat
chmod +x bin.sh
./bin.sh

The README notes that the script asks whether you are a new user or using v3, and that continuing users from v0 should answer accordingly. It also points at an Optional Parameters section for pinning a version or applying security policies, and warns that the v3 migration guide needs to be read carefully first.

For the knowledge base side, the README gives a bulk migration path for moving existing bots to multi-tenant mode. It is two commands, and the second one is easy to forget:

aws dynamodb execute-statement --statement "UPDATE \"$BotTableNameV3\" SET BedrockKnowledgeBase.type='shared' SET SyncStatus='QUEUED' WHERE PK='$UserID' AND SK='BOT#$BotID'"
# Execute for all target bots

aws stepfunctions start-execution --state-machine-arn $EmbeddingStateMachineArn

The first command flips the bot's knowledge setting to shared and queues a sync. The second starts the embedding state machine so the queued work actually runs. The README says to execute the update for all target bots, which means this is a loop you write, not a one-shot migration tool the project provides.

The 100 knowledge base ceiling and the multi-tenant workaround

The most concrete limitation in the README is a service quota. Amazon Bedrock Knowledge Bases limits an account to 100 knowledge bases by default, and the project's answer is multi-tenant mode: one knowledge base with common settings shared across many bots, with each bot's uploaded files 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 are moved by changing the bot's knowledge settings to "Create a tenant in a shared Knowledge Base." That is a sensible design, but it changes the isolation model. Files from different bots live in the same knowledge base and are separated by metadata filtering rather than by physical separation. If your requirement is hard tenant isolation at the storage layer, this is the wrong tool, and no amount of configuration fixes it.

The bulk path has a second sharp edge. The README's own example uses shell variables, `$BotTableNameV3`, `$UserID`, `$BotID` and `$EmbeddingStateMachineArn`, that you have to resolve yourself. The README does not document where `$BotTableNameV3` or `$EmbeddingStateMachineArn` come from beyond the general CloudFormation outputs guidance given for the user pool id. Get those wrong and you are issuing DynamoDB statements against the wrong table.

The v2 to v3 break, and why it is the first thing to read

The README carries a warning block that is unusually blunt for a sample project: v3 is released, you should carefully review the migration guide at `docs/migration/V2_TO_V3.md`, and without that care, "BOTS FROM V2 WILL BECOME UNUSABLE." That is not a deprecation notice. It is a statement that existing bot definitions do not survive the upgrade.

The default branch is `v3`, and the most recent release in the repository's release list is v3.17.0 from 2026-06-16, preceded by v3.16.0 and v3.15.6 in April 2026. The last push to the repository was on 2026-09-09. So the project is being touched between releases, but the release cadence itself is roughly every couple of months, which is worth knowing if you are planning to track upstream rather than pin a version.

The practical consequence for a team is that an upgrade is a project, not a pull. The migration guide is the only documented path, and the README's warning implies the failure mode is silent enough to require reading it before you start rather than after something breaks. If you have v2 bots carrying institutional knowledge, budget the migration before you touch `bin.sh`.

Publishing a bot as an API, and what that changes

The README documents a path from a customized bot to a stand-alone API, in `docs/PUBLISH_API.md`, alongside administrative features covering API management, marking bots as essential and analyzing usage for bots. This is the part that turns the project from a chat UI into something other systems can call.

It also changes the operational surface. A published bot API is a dependency for whatever consumes it, and the bot's behavior depends on its instruction, its knowledge base and the model behind it. When you migrate that bot to multi-tenant mode, or when you upgrade from v2 to v3, the API consumer inherits the change. The README does not document a versioning or rollback story for published bot APIs, so treat that as an open question you resolve in your own design rather than one the project answers.

The administrative analytics and API management features are documented in `docs/ADMINISTRATOR.md`. If your rollout plan is "let everyone create bots," read that first, because the `CreatingBotAllowed` group gate means the default state is the opposite.

Alternatives: Bedrock Chat versus a managed assistant or a plain Bedrock client

The closest thing to a managed alternative is Amazon Bedrock Agents and Knowledge Bases used directly through the AWS console and SDK, without this project's frontend, bot store or Cognito layer. The difference in approach is ownership of the UI and the multi-user model. Using Bedrock directly means you get the model and the retrieval service but you build the chat surface, the conversation storage and the sharing mechanism yourself. Bedrock Chat hands you those and asks you to operate the CDK stack that produces them.

On the other side, a thin client that calls the Bedrock API from a local script or notebook is a different trade-off again. The repository's own `examples/notebooks/` directory shows that pattern exists in the project, and it needs none of the infrastructure. If your actual need is one engineer querying a model, deploying Cognito, DynamoDB, Step Functions and OpenSearch Serverless is a large amount of machinery for that.

The honest framing is that Bedrock Chat sits between those two. It is more than a client and less than a product. The bot store, the `CreatingBotAllowed` governance gate and the multi-tenant knowledge base sharing are the features that justify the infrastructure, and they only pay off when more than one person uses the deployment.

Licence, maintenance and the cost of staying current

The repository is licensed MIT-0, which is the AWS sample licence that removes the attribution requirement. For a team embedding this in an internal platform, that is permissive in the practical sense: no copyleft obligation propagates to your own code. This is not legal advice, and the LICENSE file at the repository root is the authoritative text.

Maintenance signals are mixed and worth stating plainly. The last push was on 2026-09-09, so the repository is not dormant. The release list shows v3.17.0 on 2026-06-16, v3.16.0 on 2026-04-09 and v3.15.6 on 2026-04-08, which suggests a cadence measured in weeks to months rather than continuous delivery. The README's own version warning shows the project is willing to make breaking changes across major versions.

Upgrade cost is therefore the real ongoing expense. Every major version may require a migration guide, and the v2 to v3 case shows the cost can be bot-level, not just configuration-level. Pinning to a release tag rather than tracking `v3` is the lever the README itself points at through its Optional Parameters section. The other recurring cost is the AWS footprint: Cognito, DynamoDB, Step Functions, Lambda and OpenSearch Serverless all bill separately, and OpenSearch Serverless in particular is not a small line item for an idle deployment.

Editorial conclusion

Adopt Bedrock Chat if you want a Bedrock-native chat UI, bot store and RAG pipeline running inside your own AWS account and you are willing to own a CDK stack, Cognito user pools and OpenSearch Serverless. Do not adopt it if you need a hosted endpoint with no AWS account, or if you have v2 bots in production, because the README warns that bots from v2 become unusable without following the migration guide. Verify first that your target region appears in the supported list and that Bedrock model access is granted there, then read docs/migration/V2_TO_V3.md before running bin.sh.

Frequently asked questions

Official sources

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