English | 日本語 | 한국어 | 中文 | Français | Deutsch | Español | Italian | Norsk | ไทย | Bahasa Indonesia | Bahasa Melayu | Tiếng Việt | Polski | Português Brasil

A multilingual generative AI platform powered by Amazon Bedrock. Supports chat, custom bots with knowledge (RAG), bot sharing via a bot store, and task automation using agents.

Add your own instruction and knowledge (a.k.a RAG. The bot can be shared among application users via bot store market place. The customized bot also can be published as stand-alone API (See the detail).

You can also import existing Amazon Bedrock's KnowledgeBase.

In Amazon Bedrock Knowledge Bases, by default, the number of Knowledge Bases that can be created in a single AWS account is limited to 100. To work around this limitation, you can use 'multi-tenant' mode, where a Knowledge Base with common settings is shared among multiple bots, and files uploaded by each bot are filtered by attaching the Bot ID as metadata.

Newly created bots will have multi-tenant mode enabled by default. To migrate existing bots to multi-tenant mode, change the bot's knowledge settings to "Create a tenant in a shared Knowledge Base."

To migrate multiple bots to multi-tenant mode in bulk, execute commands like the following:

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

API Management, Mark bots as essential, Analyze usage for bots. detail

)

By using the Agent functionality, your chatbot can automatically handle more complex tasks. For example, to answer a user's question, the Agent can retrieve necessary information from external tools or break down the task into multiple steps for processing.

A comprehensive workshop is available here.

• In the us-east-1 region, open Bedrock Model access > Manage model access > Check all of models you wish to use and then Save changes.

Please make sure that you deploy Bedrock Chat in a region where OpenSearch Serverless and Ingestion APIs are available, if you want to use bots and create knowledge bases (OpenSearch Serverless is the default choice). As of August 2025, the following regions are supported: 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, sa-east-1

For the bedrock-region parameter you need to choose a region where Bedrock is available.

• Open CloudShell at the region where you want to deploy
• Run deployment via following commands. If you want to specify the version to deploy or need to apply security policies, please specify the appropriate parameters from Optional Parameters.

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

• You will be asked if a new user or using v3. If you are not a continuing user from v0, please enter y.

You can specify the following parameters during deployment to enhance security and customization:

• --disable-self-register: Disable self-registration (default: enabled). If this flag is set, you will need to create all users on cognito and it will not allow users to self register their accounts.
• --enable-lambda-snapstart: Enable Lambda SnapStart (default: disabled). If this flag is set, improves cold start times for Lambda functions, providing faster response times for better user experience.
• --ipv4-ranges: Comma-separated list of allowed IPv4 ranges. (default: allow all ipv4 addresses)
• --ipv6-ranges: Comma-separated list of allowed IPv6 ranges. (default: allow all ipv6 addresses)
• --disable-ipv6: Disable connections over IPv6. (default: enabled)
• --allowed-signup-email-domains: Comma-separated list of allowed email domains for sign-up. (default: no domain restriction)
• --bedrock-region: Define the region where bedrock is available. (default: us-east-1)
• --repo-url: The custom repo of Bedrock Chat to deploy, if forked or custom source control. (default: https://github.com/aws-samples/bedrock-chat.git)
• --version: The version of Bedrock Chat to deploy. (default: latest version in development)
• --cdk-json-override: You can override any CDK context values during deployment using the override JSON block. This allows you to modify the configuration without editing the cdk.json file directly.

Example usage:

./bin.sh --cdk-json-override '{
  "context": {
    "selfSignUpEnabled": false,
    "enableLambdaSnapStart": true,
    "allowedIpV4AddressRanges": ["192.168.1.0/24"],
    "allowedCountries": ["US", "CA"],
    "allowedSignUpEmailDomains": ["example.com"],
    "globalAvailableModels": [
      "claude-v3.7-sonnet",
      "claude-v3.5-sonnet",
      "amazon-nova-pro",
      "amazon-nova-lite",
      "llama3-3-70b-instruct"
    ]
  }
}'

The override JSON must follow the same structure as cdk.json. You can override any context values including:

• selfSignUpEnabled
• enableLambdaSnapStart
• allowedIpV4AddressRanges
• allowedIpV6AddressRanges
• allowedCountries
• allowedSignUpEmailDomains
• bedrockRegion
• enableRagReplicas
• enableBedrockCrossRegionInference
• globalAvailableModels: accepts a list of model IDs to enable. The default value is an empty list, which enables all models.
• logoPath: relative path to the logo asset within the frontend public/ directory that appears at the top of the navigation drawer.
• And other context values defined in cdk.json

./bin.sh --disable-self-register --ipv4-ranges "192.0.2.0/25,192.0.2.128/25" --ipv6-ranges "2001:db8:1:2::/64,2001:db8:1:3::/64" --allowed-signup-email-domains "example.com,anotherexample.com" --bedrock-region "us-west-2" --version "v1.2.6"

• After about 35 minutes, you will get the following output, which you can access from your browser

Frontend URL: https://xxxxxxxxx.cloudfront.net

The sign-up screen will appear as shown above, where you can register your email and log in.

It's an architecture built on AWS managed services, eliminating the need for infrastructure management. Utilizing Amazon Bedrock, there's no need to communicate with APIs outside of AWS. This enables deploying scalable, reliable, and secure applications.

• Amazon DynamoDB: NoSQL database for conversation history storage
• Amazon API Gateway + AWS Lambda: Backend API endpoint (AWS Lambda Web Adapter, FastAPI)
• Amazon CloudFront + S3: Frontend application delivery (React, Tailwind CSS)
• AWS WAF: IP address restriction
• Amazon Cognito: User authentication
• Amazon Bedrock: Managed service to utilize foundational models via APIs
• Amazon Bedrock Knowledge Bases: Provides a managed interface for Retrieval-Augmented Generation (RAG), offering services for embedding and parsing documents
• Amazon EventBridge Pipes: Receiving deletion event of bots from DynamoDB stream and delete CloudFormation stack related to the bot
• AWS Step Functions: Orchestrating ingestion pipeline to embed external knowledge into Bedrock Knowledge Bases
• Amazon OpenSearch Serverless: Serves as the backend database for Bedrock Knowledge Bases, providing full-text search and vector search capabilities, enabling accurate retrieval of relevant information
• Amazon Athena: Query service to analyze S3 bucket

Super-easy Deployment uses AWS CodeBuild to perform deployment by CDK internally. This section describes the procedure for deploying directly with CDK.

• Please have UNIX, Docker and a Node.js runtime environment.

• Clone this repository

git clone https://github.com/aws-samples/bedrock-chat

• Install npm packages

cd bedrock-chat
cd cdk
npm ci

• If necessary, edit the following entries in cdk.json.

  • bedrockRegion: Region where Bedrock is available. NOTE: Bedrock does NOT support all regions for now.
  • allowedIpV4AddressRanges, allowedIpV6AddressRanges: Allowed IP Address range.
  • enableLambdaSnapStart: Defaults to true. Set to false if deploying to a region that doesn't support Lambda SnapStart for Python functions.
  • globalAvailableModels: Defaults to all. If set (list of model IDs), allows to globally control which models appear in dropdown menus across chats for all users and during bot creation in the Bedrock Chat application.
  • logoPath: Relative path under frontend/public that points to the image displayed at the top of the application drawer. The following model IDs are supported (please make sure that they are also enabled in the Bedrock console under Model access in your deployment region):

• Claude Models: claude-v4-opus, claude-v4.1-opus, claude-v4.5-opus, claude-v4.6-opus, claude-v4.7-opus, claude-v4-sonnet, claude-v4.5-sonnet, claude-v4.6-sonnet, claude-v3.5-sonnet, claude-v3.5-sonnet-v2, claude-v3.7-sonnet, claude-v3.5-haiku, claude-v3-haiku, claude-v3-opus

• Amazon Nova Models: amazon-nova-pro, amazon-nova-lite, amazon-nova-micro

• Mistral Models: mistral-7b-instruct, mixtral-8x7b-instruct, mistral-large, mistral-large-2

• DeepSeek Models: deepseek-r1

• Meta Llama Models: llama3-3-70b-instruct, llama3-2-1b-instruct, llama3-2-3b-instruct, llama3-2-11b-instruct, llama3-2-90b-instruct

The full list can be found in index.ts.

• Before deploying the CDK, you will need to work with Bootstrap once for the region you are deploying to.

npx cdk bootstrap

• Deploy this sample project

npx cdk deploy --require-approval never --all

• You will get output similar to the following. The URL of the web app will be output in BedrockChatStack.FrontendURL, so please access it from your browser.

 ✅  BedrockChatStack

✨  Deployment time: 78.57s

Outputs:
BedrockChatStack.AuthUserPoolClientIdXXXXX = xxxxxxx
BedrockChatStack.AuthUserPoolIdXXXXXX = ap-northeast-1_XXXX
BedrockChatStack.BackendApiBackendApiUrlXXXXX = https://xxxxx.execute-api.ap-northeast-1.amazonaws.com
BedrockChatStack.FrontendURL = https://xxxxx.cloudfront.net

You can define parameters for your deployment in two ways: using cdk.json or using the type-safe parameter.ts file.

The traditional way to configure parameters is by editing the cdk.json file. This approach is simple but lacks type checking:

{
  "app": "npx ts-node --prefer-ts-exts bin/bedrock-chat.ts",
  "context": {
    "bedrockRegion": "us-east-1",
    "allowedIpV4AddressRanges": ["0.0.0.0/1", "128.0.0.0/1"],
    "selfSignUpEnabled": true,
    "globalAvailableModels": [
      "claude-v3.7-sonnet",
      "claude-v3.5-sonnet",
      "amazon-nova-pro",
      "amazon-nova-lite",
      "llama3-3-70b-instruct"
    ]
  }
}

For better type safety and developer experience, you can use the parameter.ts file to define your parameters:

// Define parameters for the default environment
bedrockChatParams.set("default", {
  bedrockRegion: "us-east-1",
  allowedIpV4AddressRanges: ["192.168.0.0/16"],
  selfSignUpEnabled: true,
  globalAvailableModels: [
    "claude-v3.7-sonnet",
    "claude-v3.5-sonnet",
    "amazon-nova-pro",
    "amazon-nova-lite",
    "llama3-3-70b-instruct",
  ],
});

// Define parameters for additional environments
bedrockChatParams.set("dev", {
  bedrockRegion: "us-west-2",
  allowedIpV4AddressRanges: ["10.0.0.0/8"],
  enableRagReplicas: false, // Cost-saving for dev environment
  enableBotStoreReplicas: false, // Cost-saving for dev environment
});

bedrockChatParams.set("prod", {
  bedrockRegion: "us-east-1",
  allowedIpV4AddressRanges: ["172.16.0.0/12"],
  enableLambdaSnapStart: true,
  enableRagReplicas: true, // Enhanced availability for production
  enableBotStoreReplicas: true, // Enhanced availability for production
});

You can deploy multiple environments from the same codebase using the parameter.ts file and the -c envName option.

1. Define your environments in parameter.ts as shown above
2. Each environment will have its own set of resources with environment-specific prefixes

To deploy a specific environment:

# Deploy the dev environment
npx cdk deploy --all -c envName=dev

# Deploy the prod environment
npx cdk deploy --all -c envName=prod

If no environment is specified, the "default" environment is used:

# Deploy the default environment
npx cdk deploy --all

1. Stack Naming:

   • The main stacks for each environment will be prefixed with the environment name (e.g., dev-BedrockChatStack, prod-BedrockChatStack)
   • However, custom bot stacks (BrChatKbStack*) and API publishing stacks (ApiPublishmentStack*) do not receive environment prefixes as they are created dynamically at runtime

2. Resource Naming:

   • Only some resources receive environment prefixes in their names (e.g., dev_ddb_export table, dev-FrontendWebAcl)
   • Most resources maintain their original names but are isolated by being in different stacks

3. Environment Identification:

   • All resources are tagged with a CDKEnvironment tag containing the environment name
   • You can use this tag to identify which environment a resource belongs to
   • Example: CDKEnvironment: dev or CDKEnvironment: prod

4. Default Environment Override: If you define a "default" environment in parameter.ts, it will override the settings in cdk.json. To continue using cdk.json, don't define a "default" environment in parameter.ts.

5. Environment Requirements: To create environments other than "default", you must use parameter.ts. The -c envName option alone is not sufficient without corresponding environment definitions.

6. Resource Isolation: Each environment creates its own set of resources, allowing you to have development, testing, and production environments in the same AWS account without conflicts.

You can define parameters for your deployment in two ways: using cdk.json or using the type-safe parameter.ts file.

The traditional way to configure parameters is by editing the cdk.json file. This approach is simple but lacks type checking:

{
  "app": "npx ts-node --prefer-ts-exts bin/bedrock-chat.ts",
  "context": {
    "bedrockRegion": "us-east-1",
    "allowedIpV4AddressRanges": ["0.0.0.0/1", "128.0.0.0/1"],
    "selfSignUpEnabled": true
  }
}

For better type safety and developer experience, you can use the parameter.ts file to define your parameters:

// Define parameters for the default environment
bedrockChatParams.set("default", {
  bedrockRegion: "us-east-1",
  allowedIpV4AddressRanges: ["192.168.0.0/16"],
  selfSignUpEnabled: true,
});

// Define parameters for additional environments
bedrockChatParams.set("dev", {
  bedrockRegion: "us-west-2",
  allowedIpV4AddressRanges: ["10.0.0.0/8"],
  enableRagReplicas: false, // Cost-saving for dev environment
});

bedrockChatParams.set("prod", {
  bedrockRegion: "us-east-1",
  allowedIpV4AddressRanges: ["172.16.0.0/12"],
  enableLambdaSnapStart: true,
  enableRagReplicas: true, // Enhanced availability for production
});

You can deploy multiple environments from the same codebase using the parameter.ts file and the -c envName option.

1. Define your environments in parameter.ts as shown above
2. Each environment will have its own set of resources with environment-specific prefixes

To deploy a specific environment:

# Deploy the dev environment
npx cdk deploy --all -c envName=dev

# Deploy the prod environment
npx cdk deploy --all -c envName=prod

If no environment is specified, the "default" environment is used:

# Deploy the default environment
npx cdk deploy --all

1. Stack Naming:

   • The main stacks for each environment will be prefixed with the environment name (e.g., dev-BedrockChatStack, prod-BedrockChatStack)
   • However, custom bot stacks (BrChatKbStack*) and API publishing stacks (ApiPublishmentStack*) do not receive environment prefixes as they are created dynamically at runtime

2. Resource Naming:

   • Only some resources receive environment prefixes in their names (e.g., dev_ddb_export table, dev-FrontendWebAcl)
   • Most resources maintain their original names but are isolated by being in different stacks

3. Environment Identification:

   • All resources are tagged with a CDKEnvironment tag containing the environment name
   • You can use this tag to identify which environment a resource belongs to
   • Example: CDKEnvironment: dev or CDKEnvironment: prod

4. Default Environment Override: If you define a "default" environment in parameter.ts, it will override the settings in cdk.json. To continue using cdk.json, don't define a "default" environment in parameter.ts.

5. Environment Requirements: To create environments other than "default", you must use parameter.ts. The -c envName option alone is not sufficient without corresponding environment definitions.

6. Resource Isolation: Each environment creates its own set of resources, allowing you to have development, testing, and production environments in the same AWS account without conflicts.

If using cli and CDK, please npx cdk destroy. If not, access CloudFormation and then delete BedrockChatStack and FrontendWafStack manually. Please note that FrontendWafStack is in us-east-1 region.

This asset automatically detects the language using i18next-browser-languageDetector. You can switch languages from the application menu. Alternatively, you can use Query String to set the language as shown below.

https://example.com?lng=ja

This sample has self sign up enabled by default. To disable self sign up, open cdk.json and switch selfSignUpEnabled as false. If you configure external identity provider, the value will be ignored and automatically disabled.

By default, this sample does not restrict the domains for sign-up email addresses. To allow sign-ups only from specific domains, open cdk.json and specify the domains as a list in allowedSignUpEmailDomains.

"allowedSignUpEmailDomains": ["example.com"],

This sample supports external identity provider. Currently we support Google and custom OIDC provider.

For CloudFront distributions, AWS WAF WebACLs must be created in the us-east-1 region. In some organizations, creating resources outside the primary region is restricted by policy. In such environments, CDK deployment can fail when attempting to provision the Frontend WAF in us-east-1.

To accommodate these restrictions, the Frontend WAF stack is optional. When disabled, the CloudFront distribution is deployed without a WebACL. This means you won’t have IP allow/deny controls at the frontend edge. Authentication and all other application controls continue to work as usual. Note that this setting only affects the Frontend WAF (CloudFront scope); the Published API WAF (regional) remains unaffected.

To disable the Frontend WAF set the following in parameter.ts (Recommended Type-Safe Method):

bedrockChatParams.set("default", {
  enableFrontendWaf: false,
});

Or if using the legacy cdk/cdk.json set the following:

"enableFrontendWaf": false

This sample has the following groups to give permissions to users:

• Admin
• CreatingBotAllowed
• PublishAllowed

If you want newly created users to automatically join groups, you can specify them in cdk.json.

"autoJoinUserGroups": ["CreatingBotAllowed"],

By default, newly created users will be joined to the CreatingBotAllowed group.

enableRagReplicas is an option in cdk.json that controls the replica settings for the RAG database, specifically the Knowledge Bases using Amazon OpenSearch Serverless.

• Default: true
• true: Enhances availability by enabling additional replicas, making it suitable for production environments but increasing costs.
• false: Reduces costs by using fewer replicas, making it suitable for development and testing.

This is an account/region-level setting, affecting the entire application rather than individual bots.

The bot store feature allows users to share and discover custom bots. You can configure the bot store through the following settings in cdk.json:

{
  "context": {
    "enableBotStore": true,
    "enableBotStoreReplicas": false,
    "botStoreLanguage": "en"
  }
}

• enableBotStore: Controls whether the bot store feature is enabled (default: true)
• botStoreLanguage: Sets the primary language for bot search and discovery (default: "en"). This affects how bots are indexed and searched in the bot store, optimizing text analysis for the specified language.
• enableBotStoreReplicas: Controls whether standby replicas are enabled for the OpenSearch Serverless collection used by bot store (default: false). Setting it to true improves availability but increases costs, while false reduces costs but may affect availability.

  Important: You can't update this property after the collection is already created. If you attempt to modify this property, the collection continues to use the original value.

Cross-region and Global inference allows Amazon Bedrock to dynamically route model inference requests across multiple AWS regions, enhancing throughput and resilience during peak demand periods. Global inference routes the requests to the optimal region based on latency and availability anywhere in the world, while cross-region inference routes requests within the same AWS region, for example, within the US. Some SCPs may restrict on or the other or both and therefore you can configure them independently. By default both are enabled.

To configure change the following settings in cdk.json or parameters.ts:

"enableBedrockGlobalInference": false,
"enableBedrockCrossRegionInference": false,

By default, the application uses claude-v3.7-sonnet as the default model for new chat conversations and claude-v3-haiku for generating conversation titles. However, some AWS accounts may not have access to these specific models, or you may prefer to use different models as defaults.

You can configure the default models using the following parameters in parameter.ts:

bedrockChatParams.set("default", {
  // Model selected by default when users start a new chat
  defaultModel: "claude-v3.7-sonnet",
  
  // Model used for generating conversation titles (cost optimization)
  titleModel: "claude-v3-haiku",
});

• defaultModel (optional): The model pre-selected in the chat UI when users start a new conversation. If not set, defaults to claude-v3.7-sonnet.
• titleModel (optional): The model used to automatically generate conversation titles. If not set, falls back to defaultModel, then to claude-v3-haiku.

When to configure these settings:

• Your AWS account doesn't have access to the default models (claude-v3.7-sonnet or claude-v3-haiku)
• You want to use a different model as the default for your users
• You want to optimize costs by using a cheaper model (like claude-v3-haiku or amazon-nova-lite) for title generation
• You want to use the same model for both chat and title generation for consistency

Lambda SnapStart improves cold start times for Lambda functions, providing faster response times for better user experience. On the other hand, for Python functions, there is a charge depending on cache size and not available in some regions currently. To disable SnapStart, edit cdk.json.

"enableLambdaSnapStart": false

You can configure a custom domain for the CloudFront distribution by setting the following parameters in cdk.json:

{
  "alternateDomainName": "chat.example.com",
  "hostedZoneId": "Z0123456789ABCDEF"
}

• alternateDomainName: The custom domain name for your chat application (e.g., chat.example.com)
• hostedZoneId: The ID of your Route 53 hosted zone where the domain records will be created

When these parameters are provided, the deployment will automatically:

• Create an ACM certificate with DNS validation in us-east-1 region
• Create the necessary DNS records in your Route 53 hosted zone
• Configure CloudFront to use your custom domain

You can restrict access to Bedrock-Chat based on the country the client is accessing it from. Use the allowedCountries parameter in cdk.json which takes a list of ISO-3166 Country Codes. For example a New Zealand based business may decide that only IP addresses from New Zealand (NZ) and Australia (AU) can access the portal and everyone else should be denied access. To configure this behaviour use the following setting in cdk.json:

{
  "allowedCountries": ["NZ", "AU"]
}

Or, using parameter.ts (Recommended Type-Safe Method):

// Define parameters for the default environment
bedrockChatParams.set("default", {
  allowedCountries: ["NZ", "AU"],
});

The frontend gets both IP and IPv6 addresses by default. In some rare circumstances, you may need to disable IPv6 support explicitly. To do this, set the following parameter in parameter.ts or similarly in cdk.json:

"enableFrontendIpv6": false

If left unset the IPv6 support will be enabled by default.

See LOCAL DEVELOPMENT.

Thank you for considering contributing to this repository! We welcome bug fixes, language translations (i18n), feature enhancements, agent tools, and other improvements.

For feature enhancements and other improvements, before creating a Pull Request, we would greatly appreciate it if you could create a Feature Request Issue to discuss the implementation approach and details. For bug fixes and language translations (i18n), proceed with creating a Pull Request directly.

Please also take a look at the following guidelines before contributing:

• Local Development
• CONTRIBUTING

• Takehiro Suzuki
• Yusuke Wada
• Yukinobu Mine

• fsatsuki
• k70suK3-k06a7ash1

This library is licensed under the MIT-0 License. See the LICENSE file.