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

Une plateforme d'IA générative multilingue alimentée par Amazon Bedrock. Prend en charge le chat, les bots personnalisés avec connaissances (RAG), le partage de bots via une boutique de bots et l'automatisation des tâches à l'aide d'agents.

Ajoutez vos propres instructions et connaissances (aussi appelé RAG. Le bot peut être partagé entre les utilisateurs de l'application via la boutique de bots. Le bot personnalisé peut également être publié en tant qu'API autonome (Voir les détails).

Gestion des API, Marquer les bots comme essentiels, Analyser l'utilisation des bots. détails

En utilisant la fonctionnalité d'Agent, votre chatbot peut automatiquement gérer des tâches plus complexes. Par exemple, pour répondre à la question d'un utilisateur, l'Agent peut récupérer les informations nécessaires à partir d'outils externes ou décomposer la tâche en plusieurs étapes pour le traitement.

• Dans la région us-east-1, ouvrez Bedrock Model access > Manage model access > Cochez tous les modèles que vous souhaitez utiliser puis Save changes.

Veuillez vous assurer de déployer Bedrock Chat dans une région où OpenSearch Serverless et les API d'ingestion sont disponibles, si vous souhaitez utiliser des bots et créer des bases de connaissances (OpenSearch Serverless est le choix par défaut). En août 2025, les régions suivantes sont prises en charge : 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

Pour le paramètre bedrock-region, vous devez choisir une région où Bedrock est disponible.

• Ouvrez CloudShell dans la région où vous souhaitez déployer
• Exécutez le déploiement via les commandes suivantes. Si vous souhaitez spécifier la version à déployer ou devez appliquer des politiques de sécurité, veuillez spécifier les paramètres appropriés dans Paramètres optionnels.

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

• On vous demandera si vous êtes un nouvel utilisateur ou si vous utilisez v3. Si vous n'êtes pas un utilisateur continu depuis v0, veuillez entrer y.

Vous pouvez spécifier les paramètres suivants lors du déploiement pour améliorer la sécurité et la personnalisation :

• --disable-self-register : Désactive l'auto-inscription (activée par défaut). Si ce drapeau est défini, vous devrez créer tous les utilisateurs sur cognito et il ne permettra pas aux utilisateurs de s'inscrire eux-mêmes.
• --enable-lambda-snapstart : Active Lambda SnapStart (désactivé par défaut). Si ce drapeau est défini, améliore les temps de démarrage à froid des fonctions Lambda, offrant des temps de réponse plus rapides pour une meilleure expérience utilisateur.
• --ipv4-ranges : Liste séparée par des virgules des plages IPv4 autorisées. (par défaut : autorise toutes les adresses ipv4)
• --ipv6-ranges : Liste séparée par des virgules des plages IPv6 autorisées. (par défaut : autorise toutes les adresses ipv6)
• --disable-ipv6 : Désactive les connexions via IPv6. (activé par défaut)
• --allowed-signup-email-domains : Liste séparée par des virgules des domaines d'e-mail autorisés pour l'inscription. (par défaut : aucune restriction de domaine)
• --bedrock-region : Définit la région où bedrock est disponible. (par défaut : us-east-1)
• --repo-url : Le dépôt personnalisé de Bedrock Chat à déployer, si forké ou contrôle de source personnalisé. (par défaut : https://github.com/aws-samples/bedrock-chat.git)
• --version : La version de Bedrock Chat à déployer. (par défaut : dernière version en développement)
• --cdk-json-override : Vous pouvez remplacer n'importe quelle valeur de contexte CDK pendant le déploiement en utilisant le bloc JSON de remplacement. Cela vous permet de modifier la configuration sans éditer directement le fichier cdk.json.

Exemple d'utilisation :

./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"
    ]
  }
}'

Le JSON de remplacement doit suivre la même structure que cdk.json. Vous pouvez remplacer n'importe quelle valeur de contexte, notamment :

• selfSignUpEnabled
• enableLambdaSnapStart
• allowedIpV4AddressRanges
• allowedIpV6AddressRanges
• allowedCountries
• allowedSignUpEmailDomains
• bedrockRegion
• enableRagReplicas
• enableBedrockCrossRegionInference
• globalAvailableModels : accepte une liste d'ID de modèles à activer. La valeur par défaut est une liste vide, qui active tous les modèles.
• logoPath : chemin relatif vers l'actif du logo dans le répertoire frontend public/ qui apparaît en haut du tiroir de navigation.
• Et d'autres valeurs de contexte définies dans 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"

• Après environ 35 minutes, vous obtiendrez la sortie suivante, à laquelle vous pourrez accéder depuis votre navigateur

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

L'écran d'inscription apparaîtra comme montré ci-dessus, où vous pourrez enregistrer votre e-mail et vous connecter.

C'est une architecture construite sur des services managés AWS, éliminant le besoin de gérer l'infrastructure. En utilisant Amazon Bedrock, il n'est pas nécessaire de communiquer avec des API externes à AWS. Cela permet de déployer des applications évolutives, fiables et sécurisées.

• Amazon DynamoDB : Base de données NoSQL pour le stockage de l'historique des conversations
• Amazon API Gateway + AWS Lambda : Point de terminaison API backend (AWS Lambda Web Adapter, FastAPI)
• Amazon CloudFront + S3 : Distribution de l'application frontend (React, Tailwind CSS)
• AWS WAF : Restriction des adresses IP
• Amazon Cognito : Authentification des utilisateurs
• Amazon Bedrock : Service managé pour utiliser des modèles fondamentaux via des API
• Amazon Bedrock Knowledge Bases : Fournit une interface managée pour la Génération Augmentée par Récupération (RAG), offrant des services pour l'intégration et l'analyse de documents
• Amazon EventBridge Pipes : Réception d'événements depuis le flux DynamoDB et lancement de Step Functions pour intégrer des connaissances externes
• AWS Step Functions : Orchestration du pipeline d'ingestion pour intégrer des connaissances externes dans Bedrock Knowledge Bases
• Amazon OpenSearch Serverless : Sert de base de données backend pour Bedrock Knowledge Bases, fournissant des capacités de recherche plein texte et de recherche vectorielle, permettant une récupération précise des informations pertinentes
• Amazon Athena : Service de requête pour analyser le bucket S3

Le déploiement Super-easy utilise AWS CodeBuild pour effectuer le déploiement via CDK en interne. Cette section décrit la procédure de déploiement direct avec CDK.

• Veuillez disposer d'un environnement UNIX, Docker et Node.js.

• Clonez ce dépôt

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

• Installez les packages npm

cd bedrock-chat
cd cdk
npm ci

• Si nécessaire, modifiez les entrées suivantes dans cdk.json.

  • bedrockRegion : Région où Bedrock est disponible. NOTE : Bedrock ne prend PAS en charge toutes les régions pour l'instant.
  • allowedIpV4AddressRanges, allowedIpV6AddressRanges : Plage d'adresses IP autorisées.
  • enableLambdaSnapStart : Par défaut à true. Mettre à false si le déploiement se fait dans une région qui ne prend pas en charge Lambda SnapStart pour les fonctions Python.
  • globalAvailableModels : Par défaut tous. Si défini (liste d'ID de modèles), permet de contrôler globalement quels modèles apparaissent dans les menus déroulants des chats pour tous les utilisateurs et lors de la création de bots dans l'application Bedrock Chat.
  • logoPath : Chemin relatif sous frontend/public qui pointe vers l'image affichée en haut du tiroir de l'application. Les ID de modèles suivants sont pris en charge (assurez-vous qu'ils sont également activés dans la console Bedrock sous Model access dans votre région de déploiement) :

• Modèles Claude : claude-v4-opus, claude-v4.1-opus, claude-v4-sonnet, claude-v3.5-sonnet, claude-v3.5-sonnet-v2, claude-v3.7-sonnet, claude-v3.5-haiku, claude-v3-haiku, claude-v3-opus

• Modèles Amazon Nova : amazon-nova-pro, amazon-nova-lite, amazon-nova-micro

• Modèles Mistral : mistral-7b-instruct, mixtral-8x7b-instruct, mistral-large, mistral-large-2

• Modèles DeepSeek : deepseek-r1

• Modèles Meta Llama : llama3-3-70b-instruct, llama3-2-1b-instruct, llama3-2-3b-instruct, llama3-2-11b-instruct, llama3-2-90b-instruct

La liste complète se trouve dans index.ts.

• Avant de déployer le CDK, vous devrez effectuer un Bootstrap une fois pour la région dans laquelle vous déployez.

npx cdk bootstrap

• Déployez ce projet exemple

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

• Vous obtiendrez une sortie similaire à ce qui suit. L'URL de l'application web sera affichée dans BedrockChatStack.FrontendURL, veuillez y accéder depuis votre navigateur.

 ✅  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

Vous pouvez définir les paramètres de votre déploiement de deux manières : en utilisant cdk.json ou en utilisant le fichier parameter.ts avec typage sûr.

La façon traditionnelle de configurer les paramètres consiste à éditer le fichier cdk.json. Cette approche est simple mais manque de vérification des types :

{
  "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"
    ],
  }
}

Pour une meilleure sécurité des types et une meilleure expérience développeur, vous pouvez utiliser le fichier parameter.ts pour définir vos paramètres :

// Définir les paramètres pour l'environnement par défaut
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"
    ],
});

// Définir les paramètres pour les environnements supplémentaires
bedrockChatParams.set("dev", {
  bedrockRegion: "us-west-2",
  allowedIpV4AddressRanges: ["10.0.0.0/8"],
  enableRagReplicas: false, // Économie de coûts pour l'environnement de dev
  enableBotStoreReplicas: false, // Économie de coûts pour l'environnement de dev
});

bedrockChatParams.set("prod", {
  bedrockRegion: "us-east-1",
  allowedIpV4AddressRanges: ["172.16.0.0/12"],
  enableLambdaSnapStart: true,
  enableRagReplicas: true, // Disponibilité améliorée pour la production
  enableBotStoreReplicas: true, // Disponibilité améliorée pour la production
});

Vous pouvez déployer plusieurs environnements à partir du même code source en utilisant le fichier parameter.ts et l'option -c envName.

1. Définissez vos environnements dans parameter.ts comme montré ci-dessus
2. Chaque environnement aura son propre ensemble de ressources avec des préfixes spécifiques à l'environnement

Pour déployer un environnement spécifique :

# Déployer l'environnement dev
npx cdk deploy --all -c envName=dev

# Déployer l'environnement prod
npx cdk deploy --all -c envName=prod

Si aucun environnement n'est spécifié, l'environnement "default" est utilisé :

# Déployer l'environnement par défaut
npx cdk deploy --all

1. Nommage des stacks :

   • Les stacks principales pour chaque environnement seront préfixées avec le nom de l'environnement (par exemple, dev-BedrockChatStack, prod-BedrockChatStack)
   • Cependant, les stacks de bots personnalisés (BrChatKbStack*) et les stacks de publication d'API (ApiPublishmentStack*) ne reçoivent pas de préfixes d'environnement car ils sont créés dynamiquement à l'exécution

2. Nommage des ressources :

   • Seules certaines ressources reçoivent des préfixes d'environnement dans leurs noms (par exemple, table dev_ddb_export, dev-FrontendWebAcl)
   • La plupart des ressources conservent leurs noms d'origine mais sont isolées en étant dans différentes stacks

3. Identification de l'environnement :

   • Toutes les ressources sont étiquetées avec un tag CDKEnvironment contenant le nom de l'environnement
   • Vous pouvez utiliser ce tag pour identifier à quel environnement appartient une ressource
   • Exemple : CDKEnvironment: dev ou CDKEnvironment: prod

4. Remplacement de l'environnement par défaut : Si vous définissez un environnement "default" dans parameter.ts, il remplacera les paramètres dans cdk.json. Pour continuer à utiliser cdk.json, ne définissez pas d'environnement "default" dans parameter.ts.

5. Exigences d'environnement : Pour créer des environnements autres que "default", vous devez utiliser parameter.ts. L'option -c envName seule n'est pas suffisante sans définitions d'environnement correspondantes.

6. Isolation des ressources : Chaque environnement crée son propre ensemble de ressources, vous permettant d'avoir des environnements de développement, de test et de production dans le même compte AWS sans conflits.

Vous pouvez définir les paramètres de votre déploiement de deux manières : en utilisant cdk.json ou en utilisant le fichier parameter.ts avec typage sécurisé.

La façon traditionnelle de configurer les paramètres consiste à modifier le fichier cdk.json. Cette approche est simple mais ne dispose pas de vérification des types :

{
  "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
  }
}

Pour une meilleure sécurité des types et une meilleure expérience développeur, vous pouvez utiliser le fichier parameter.ts pour définir vos paramètres :

// 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
});

Vous pouvez déployer plusieurs environnements à partir du même code source en utilisant le fichier parameter.ts et l'option -c envName.

1. Définissez vos environnements dans parameter.ts comme montré ci-dessus
2. Chaque environnement aura son propre ensemble de ressources avec des préfixes spécifiques

Pour déployer un environnement spécifique :

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

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

Si aucun environnement n'est spécifié, l'environnement "default" est utilisé :

# Deploy the default environment
npx cdk deploy --all

1. Nommage des stacks :

   • Les stacks principales pour chaque environnement auront un préfixe avec le nom de l'environnement (ex : dev-BedrockChatStack, prod-BedrockChatStack)
   • Cependant, les stacks de bot personnalisées (BrChatKbStack*) et les stacks de publication d'API (ApiPublishmentStack*) ne reçoivent pas de préfixes d'environnement car elles sont créées dynamiquement à l'exécution

2. Nommage des ressources :

   • Seules certaines ressources reçoivent des préfixes d'environnement dans leurs noms (ex : table dev_ddb_export, dev-FrontendWebAcl)
   • La plupart des ressources conservent leurs noms d'origine mais sont isolées en étant dans différentes stacks

3. Identification de l'environnement :

   • Toutes les ressources sont étiquetées avec une balise CDKEnvironment contenant le nom de l'environnement
   • Vous pouvez utiliser cette balise pour identifier à quel environnement appartient une ressource
   • Exemple : CDKEnvironment: dev ou CDKEnvironment: prod

4. Remplacement de l'environnement par défaut : Si vous définissez un environnement "default" dans parameter.ts, il remplacera les paramètres dans cdk.json. Pour continuer à utiliser cdk.json, ne définissez pas d'environnement "default" dans parameter.ts.

5. Exigences d'environnement : Pour créer des environnements autres que "default", vous devez utiliser parameter.ts. L'option -c envName seule n'est pas suffisante sans les définitions d'environnement correspondantes.

6. Isolation des ressources : Chaque environnement crée son propre ensemble de ressources, vous permettant d'avoir des environnements de développement, de test et de production dans le même compte AWS sans conflits.

Si vous utilisez cli et CDK, veuillez exécuter npx cdk destroy. Sinon, accédez à CloudFormation puis supprimez manuellement BedrockChatStack et FrontendWafStack. Veuillez noter que FrontendWafStack se trouve dans la région us-east-1.

Cet outil détecte automatiquement la langue en utilisant i18next-browser-languageDetector. Vous pouvez changer de langue depuis le menu de l'application. Alternativement, vous pouvez utiliser une chaîne de requête pour définir la langue comme indiqué ci-dessous.

https://example.com?lng=ja

Cet exemple a l'auto-inscription activée par défaut. Pour désactiver l'auto-inscription, ouvrez cdk.json et changez selfSignUpEnabled en false. Si vous configurez un fournisseur d'identité externe, cette valeur sera ignorée et automatiquement désactivée.

Par défaut, cet exemple ne restreint pas les domaines pour les adresses e-mail d'inscription. Pour autoriser les inscriptions uniquement à partir de domaines spécifiques, ouvrez cdk.json et spécifiez les domaines dans une liste dans allowedSignUpEmailDomains.

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

Cet exemple prend en charge les fournisseurs d'identité externes. Actuellement, nous supportons Google et les fournisseurs OIDC personnalisés.

Pour les distributions CloudFront, les WebACL AWS WAF doivent être créés dans la région us-east-1. Dans certaines organisations, la création de ressources en dehors de la région principale est restreinte par des politiques. Dans de tels environnements, le déploiement CDK peut échouer lors de la tentative de provisionnement du WAF Frontend en us-east-1.

Pour s'adapter à ces restrictions, la pile WAF Frontend est optionnelle. Lorsqu'elle est désactivée, la distribution CloudFront est déployée sans WebACL. Cela signifie que vous n'aurez pas de contrôles d'autorisation/refus d'IP au niveau du frontend. L'authentification et tous les autres contrôles d'application continuent de fonctionner normalement. Notez que ce paramètre n'affecte que le WAF Frontend (portée CloudFront) ; le WAF de l'API publiée (régional) reste inchangé.

Pour désactiver le WAF Frontend, définissez ce qui suit dans parameter.ts (Méthode recommandée avec typage) :

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

Ou si vous utilisez le cdk/cdk.json traditionnel, définissez :

"enableFrontendWaf": false

Cet exemple comporte les groupes suivants pour donner des autorisations aux utilisateurs :

• Admin
• CreatingBotAllowed
• PublishAllowed

Si vous souhaitez que les nouveaux utilisateurs rejoignent automatiquement des groupes, vous pouvez les spécifier dans cdk.json.

"autoJoinUserGroups": ["CreatingBotAllowed"],

Par défaut, les nouveaux utilisateurs seront ajoutés au groupe CreatingBotAllowed.

enableRagReplicas est une option dans cdk.json qui contrôle les paramètres de réplication pour la base de données RAG, spécifiquement les bases de connaissances utilisant Amazon OpenSearch Serverless.

• Par défaut : true
• true : Améliore la disponibilité en activant des réplicas supplémentaires, ce qui convient aux environnements de production mais augmente les coûts.
• false : Réduit les coûts en utilisant moins de réplicas, ce qui convient au développement et aux tests.

C'est un paramètre au niveau du compte/région qui affecte toute l'application plutôt que des bots individuels.

La fonctionnalité de bot store permet aux utilisateurs de partager et de découvrir des bots personnalisés. Vous pouvez configurer le bot store via les paramètres suivants dans cdk.json :

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

• enableBotStore : Contrôle si la fonctionnalité de bot store est activée (par défaut : true)
• botStoreLanguage : Définit la langue principale pour la recherche et la découverte de bots (par défaut : "en"). Cela affecte la façon dont les bots sont indexés et recherchés dans le bot store, optimisant l'analyse de texte pour la langue spécifiée.
• enableBotStoreReplicas : Contrôle si les réplicas de secours sont activés pour la collection OpenSearch Serverless utilisée par le bot store (par défaut : false). Le régler sur true améliore la disponibilité mais augmente les coûts, tandis que false réduit les coûts mais peut affecter la disponibilité.

  Important : Vous ne pouvez pas mettre à jour cette propriété une fois que la collection est déjà créée. Si vous tentez de modifier cette propriété, la collection continuera d'utiliser la valeur d'origine.

L'inférence inter-régions permet à Amazon Bedrock de router dynamiquement les requêtes d'inférence de modèle à travers plusieurs régions AWS, améliorant le débit et la résilience pendant les périodes de forte demande. Pour configurer, modifiez cdk.json.

"enableBedrockCrossRegionInference": true

Lambda SnapStart améliore les temps de démarrage à froid des fonctions Lambda, offrant des temps de réponse plus rapides pour une meilleure expérience utilisateur. En revanche, pour les fonctions Python, il y a des frais en fonction de la taille du cache et ce n'est pas disponible dans certaines régions actuellement. Pour désactiver SnapStart, modifiez cdk.json.

"enableLambdaSnapStart": false

Vous pouvez configurer un domaine personnalisé pour la distribution CloudFront en définissant les paramètres suivants dans cdk.json :

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

• alternateDomainName : Le nom de domaine personnalisé pour votre application de chat (par exemple, chat.example.com)
• hostedZoneId : L'ID de votre zone hébergée Route 53 où les enregistrements DNS seront créés

Lorsque ces paramètres sont fournis, le déploiement va automatiquement :

• Créer un certificat ACM avec validation DNS dans la région us-east-1
• Créer les enregistrements DNS nécessaires dans votre zone hébergée Route 53
• Configurer CloudFront pour utiliser votre domaine personnalisé

Vous pouvez restreindre l'accès à Bedrock-Chat en fonction du pays d'où le client y accède. Utilisez le paramètre allowedCountries dans cdk.json qui prend une liste de codes pays ISO-3166. Par exemple, une entreprise basée en Nouvelle-Zélande peut décider que seules les adresses IP de Nouvelle-Zélande (NZ) et d'Australie (AU) peuvent accéder au portail et que tout le monde ailleurs devrait se voir refuser l'accès. Pour configurer ce comportement, utilisez le paramètre suivant dans cdk.json :

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

Ou, en utilisant parameter.ts (Méthode recommandée avec typage) :

// Définir les paramètres pour l'environnement par défaut
bedrockChatParams.set("default", {
  allowedCountries: ["NZ", "AU"],
});

Le frontend obtient par défaut des adresses IP et IPv6. Dans certains cas rares, vous pourriez avoir besoin de désactiver explicitement le support IPv6. Pour ce faire, définissez le paramètre suivant dans parameter.ts ou de manière similaire dans cdk.json :

"enableFrontendIpv6": false

Si non défini, le support IPv6 sera activé par défaut.

Voir LOCAL DEVELOPMENT.

Merci d'envisager de contribuer à ce dépôt ! Nous accueillons les corrections de bugs, les traductions (i18n), les améliorations de fonctionnalités, les outils d'agent, et autres améliorations.

Pour les améliorations de fonctionnalités et autres améliorations, avant de créer une Pull Request, nous vous serions très reconnaissants de créer une Issue de demande de fonctionnalité pour discuter de l'approche et des détails de l'implémentation. Pour les corrections de bugs et les traductions (i18n), procédez directement à la création d'une Pull Request.

Veuillez également consulter les directives suivantes avant de contribuer :

• Développement local
• CONTRIBUTING

• Takehiro Suzuki
• Yusuke Wada
• Yukinobu Mine

Note: As per requirements, personal names and URLs remain untranslated. The word "Contacts" was translated to French as it's a section heading.

• fsatsuki
• k70suK3-k06a7ash1

Cette bibliothèque est distribuée sous la licence MIT-0. Consultez le fichier LICENSE.