View a markdown version of this page

Règles d'activation de la télémétrie - Amazon CloudWatch

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Règles d'activation de la télémétrie

Vous pouvez créer des règles d'activation de la télémétrie afin de configurer automatiquement la collecte de télémétrie pour vos ressources. AWS Les règles vous aident à standardiser la collecte de données télémétriques au sein de votre organisation ou de vos comptes et à garantir une couverture de surveillance cohérente.

Comment fonctionnent les règles

La configuration de la télémétrie suit des modèles spécifiques lors de l'évaluation et de l'application des règles.

Hiérarchie d'évaluation des règles

Les règles d’activation sont évaluées selon un modèle hiérarchique. Les règles organisationnelles sont évaluées en premier, puis les règles qui s’appliquent aux unité organisationnelle (UO) et enfin les règles qui s’appliquent aux comptes individuels. Les règles au niveau organisationnel fournissent les données de télémétrie de base requises pour votre organisation. Les règles au niveau de l’unité organisationnelle et des comptes peuvent collecter des données de télémétrie supplémentaires, mais elles ne peuvent pas collecter moins de données de télémétrie. Si une telle règle est créée, elle entraînera un conflit de règles.

Dans chaque portée (organisation, unité organisationnelle ou compte), les règles doivent conserver leur caractère unique en fonction de leur type de ressource, de leur type de télémétrie et de leur configuration de destination. Les règles en double déclenchent une exception de conflit. Si la même règle existe dans différents domaines d'application, par exemple une règle au niveau de l'organisation pour les journaux Amazon VPC Flow CloudWatch et une règle au niveau de l'unité d'organisation pour les journaux Amazon VPC Flow, la règle la plus élevée dans la hiérarchie est appliquée. Toutefois, s'il existe plusieurs règles contradictoires, aucune des règles n'est appliquée.

Lorsque plusieurs règles s’appliquent à la même ressource, la configuration de télémétrie résout les conflits en utilisant les priorités suivantes :

  1. Organizational-level les règles ont priorité sur les règles au niveau du compte

  2. Les correspondances de balises plus spécifiques ont priorité sur les règles générales

  3. S'il existe plusieurs règles contradictoires, aucune règle n'est appliquée. Vous devez d'abord résoudre les conflits.

Comportement des règles lors des mises à

Si vous mettez à jour une règle d'activation, seules les nouvelles ressources qui correspondent à la règle adoptent la configuration mise à jour. Les paramètres de télémétrie existants restent inchangés pour les ressources existantes. Si une ressource devient non conforme à une règle existante en raison de la suppression manuelle des données de télémétrie, la nouvelle règle d'activation est adoptée une fois la ressource remise en conformité.

Pour les journaux Amazon VPC Flow, la configuration de télémétrie crée de nouveaux journaux de flux uniquement pour les ressources qui correspondent à la portée de la règle. Elle ne supprime ni n'affecte les journaux Amazon VPC Flow précédemment établis, même s'ils diffèrent des paramètres de règles actuels. Pour les CloudWatch journaux, les groupes de journaux existants sont gérés à condition qu'ils correspondent au modèle de ressources.

Intégration à AWS Config

CloudWatch l'audit et la configuration de la télémétrie s'intègrent AWS Config pour découvrir automatiquement les ressources qui correspondent à votre règle d'activation et les appliquer à votre collecte de données de télémétrie. Lorsque vous créez une règle d'activation, la configuration de télémétrie crée un enregistreur correspondant. AWS Config Cet enregistreur comprend des éléments de configuration pour les types de ressources spécifiques que vous définissez dans la règle d’activation.

Amazon CloudWatch utilise l'enregistreur lié au service AWS Config Internal. Les CI CloudWatch utilisés dans le cadre des enregistreurs liés aux services internes ne vous sont pas facturés.

Note

Lorsque vous créez une règle d'activation, nous découvrons les ressources non conformes (celles pour lesquelles la télémétrie n'est pas activée) via les éléments de AWS configuration (CI) avant de les activer en fonction de la portée de votre règle d'activation. La découverte initiale des ressources peut prendre jusqu'à 24 heures dans certains cas.

La configuration de télémétrie permet de : AWS Config

  • Détecter les ressources au sein de votre organisation ou de vos comptes

  • Suivre les modifications de configuration de télémétrie

Règles applicables à toutes les régions

Lorsque vous créez une règle avec des régions cibles, la région actuelle devient la région d'origine de cette règle. La règle est automatiquement répliquée dans les régions en étoile que vous sélectionnez.

Concepts clés des règles multirégionales :

  • Les règles répliquées ne peuvent pas être modifiées ou supprimées dans les régions parlées. Vous devez accéder à la région d'origine pour les modifier ou les supprimer.

  • Si vous sélectionnez Toutes les régions, les nouvelles régions sont automatiquement incluses lorsque vous les choisissez.

  • Le système réconcilie périodiquement les règles entre les régions afin de corriger toute dérive entre la région d'origine et les régions relais.

  • Les balises appliquées aux règles de la région d'origine sont répliquées dans les régions associées.

Lorsqu'une règle répliquée est créée, mise à jour ou supprimée dans une région en étoile, en AWS CloudTrail enregistre une AwsServiceEvent dans la région en étoile. Ces événements sont enregistrés en observabilityadmin.amazonaws.com tant que service d'appel et incluent la règle ARN dans la région de rayon. Vous pouvez utiliser ces événements pour auditer l'activité de réplication de règles multirégionales.

Voici un exemple d' AWS CloudTrail événement enregistré lorsqu'une règle répliquée est créée dans une région de rayons :

{ "eventVersion": "1.11", "userIdentity": { "accountId": "123456789012", "invokedBy": "observabilityadmin.amazonaws.com" }, "eventTime": "2026-04-06T19:50:37Z", "eventSource": "observabilityadmin.amazonaws.com", "eventName": "CreateTelemetryRule", "awsRegion": "us-east-1", "sourceIPAddress": "observabilityadmin.amazonaws.com", "userAgent": "observabilityadmin.amazonaws.com", "requestParameters": null, "responseElements": null, "eventID": "435d6da2-d099-4775-8944-1e039418de6f", "readOnly": false, "resources": [ { "accountId": "123456789012", "type": "AWS::ObservabilityAdmin::TelemetryRule", "ARN": "arn:aws:observabilityadmin:us-east-1:123456789012:telemetry-rule/my-multi-region-rule" } ], "eventType": "AwsServiceEvent", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management" }

Le eventName champ reflète l'opération effectuée sur la règle répliquée : CreateTelemetryRuleUpdateTelemetryRule, ouDeleteTelemetryRule. Cela eventType est toujours AwsServiceEvent dû au fait que l'opération est effectuée par le ObservabilityAdmin service pour le compte du client, et non par un appel d'API direct au client.

Création d'une règle d'activation de la télémétrie

Lorsque vous créez une règle d’activation de télémétrie, vous spécifiez :

  • La portée de la règle (organisation, unité organisationnelle ou compte)

  • Les types de ressources auxquels la règle s’applique

  • Les types de télémétrie à activer (métriques, journaux ou traces)

  • Les balises facultatives pour filtrer les ressources concernées par la règle

  • Régions cibles facultatives pour répliquer la règle dans plusieurs régions

  • ARN de AWS KMS clé optionnel pour chiffrer les groupes de journaux créés par la règle à l'aide d'une clé gérée par le client

Pour créer une règle d’activation de télémétrie
  1. Ouvrez la CloudWatch console à l'adresse https://console.aws.amazon.com/cloudwatch/.

  2. Dans le volet de navigation, choisissez Ingestion.

  3. Sélectionnez l’onglet Règles d’activation.

  4. Choisissez Ajouter une règle.

  5. Pour Nom de la règle, entrez un nom pour votre règle.

  6. Pour Portée de la règle, sélectionnez l’une des options suivantes :

    • Organisation — La règle s'applique à l'ensemble de votre organisation AWS Organizations

    • Unité organisationnelle — La règle s'applique à une UO spécifique

    • Compte — La règle s'applique à un seul compte

  7. Pour Source de données, sélectionnez le AWS service à configurer.

  8. Pour Type de télémétrie, sélectionnez les types de télémétrie à activer.

  9. (Facultatif) Ajoutez des balises pour filtrer les ressources concernées par la règle.

  10. (Facultatif) Pour les régions cibles, sélectionnez les régions dans lesquelles vous souhaitez que cette règle s'applique. La région actuelle est automatiquement désignée comme région d'origine de la règle. Si vous sélectionnez Toutes les régions, les nouvelles régions sont automatiquement incluses lorsque vous les choisissez.

  11. (Facultatif) Pour l'ARN de la clé KMS, entrez l'ARN d'une AWS KMS clé pour chiffrer les groupes de journaux créés par cette règle. Pour les règles interrégionales, vous devez utiliser une clé multirégion (l'ID de clé commence mrk- par). Pour de plus amples informations, veuillez consulter Chiffrement de groupes de journaux à l'aide de clés gérées par le client.

  12. Choisissez Créer une règle.

Gestion des règles de télémétrie

Après avoir créé des règles, vous pouvez les modifier ou les supprimer. Vous pouvez également afficher les ressources concernées par chaque règle et surveiller la conformité aux règles.

Pour gérer une règle existante
  1. Ouvrez la CloudWatch console à l'adresse https://console.aws.amazon.com/cloudwatch/.

  2. Dans le volet de navigation, choisissez Ingestion.

  3. Sélectionnez l’onglet Règles d’activation.

  4. Sélectionnez une règle pour afficher ses détails ou choisissez l’une des actions suivantes :

    • Modifier la règle — Modifier les paramètres de la règle

    • Supprimer — Supprimer la règle

Gestion des règles répliquées

Lorsque vous visualisez une règle répliquée dans une région en étoile, la console affiche une alerte d'information indiquant que la règle a été répliquée depuis une autre région. Les actions Modifier la règle et Supprimer sont désactivées pour les règles répliquées dans les régions à rayons.

Pour modifier ou supprimer une règle répliquée, accédez à la région d'accueil dans laquelle la règle a été créée à l'origine. La région d'origine est affichée dans l'alerte d'information.

Vous pouvez ajouter ou modifier des balises sur des règles répliquées dans les régions à rayons. Les modifications de balises effectuées dans les régions relais s'appliquent uniquement à la copie locale de la règle et ne sont pas répliquées dans la région d'origine.

Chiffrement de groupes de journaux à l'aide de clés gérées par le client

Vous pouvez chiffrer les groupes de journaux créés par les règles d'activation de la télémétrie à l'aide d'une clé gérée par le client. AWS KMS Le chiffrement des groupes de journaux à l'aide d'une clé gérée par le client vous permet de contrôler la rotation des clés et de répondre aux exigences de conformité. Lorsque vous spécifiez un ARN AWS KMS clé dans la configuration de destination de votre règle, associe CloudWatch automatiquement la clé à chaque groupe de journaux créé lors de la correction.

Exigences relatives aux clés KMS

  • Pour les règles interrégionales, vous devez utiliser une clé multirégion. AWS KMS Multi-Region les clés ont un identifiant qui commence parmrk-. Cela garantit un chiffrement cohérent dans toutes les régions où la règle est appliquée.

  • Pour les règles qui ciblent une seule région, les clés à région unique et à région multiple sont acceptées.

  • La AWS KMS clé doit être activée et accessible au rôle lié au service utilisé par les règles de télémétrie.

  • Lorsque vous créez ou mettez à jour une règle avec un ARN de AWS KMS clé, le service vérifie que la clé existe et qu'elle est activée en appelantkms:DescribeKey.

Politique de clé KMS requise

Votre politique de AWS KMS clé doit autoriser le service CloudWatch Logs à utiliser la clé pour le chiffrement. Ajoutez la déclaration suivante à votre politique clé :

{ "Sid": "AllowCloudWatchLogsToUseKey", "Effect": "Allow", "Principal": { "Service": "logs.amazonaws.com" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceOrgID": "your-organization-id" }, "ArnLike": { "kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:*:*:log-group:*" } } }

Remplacez-le your-organization-id par AWS Organizations l'identifiant de votre organisation. Cette aws:SourceOrgID condition garantit que seuls les comptes de votre organisation peuvent utiliser la clé pour le chiffrement des groupes de journaux.

Note

Pour les règles à l'échelle de l'organisation qui corrigent les problèmes entre les comptes membres, cette politique clé autorise le service CloudWatch Logs des comptes membres à crypter et déchiffrer les données des journaux à l'aide de votre clé. Le rôle lié au service des règles de télémétrie n'effectue pas directement le chiffrement ou le déchiffrement ; il associe uniquement la clé au groupe de journaux.

Service-linked autorisations de rôle pour le chiffrement

Le rôle lié au service des règles de télémétrie nécessite des autorisations supplémentaires pour prendre en charge le chiffrement par clé. AWS KMS Les autorisations suivantes sont automatiquement ajoutées au rôle lié à un service lorsque vous utilisez le AWS KMS chiffrement avec des règles de télémétrie :

  • kms:DescribeKey— Permet au service de vérifier que la AWS KMS clé existe, qu'elle est activée et qu'il s'agit d'une clé multirégionale (pour les règles interrégionales). Cette autorisation est utilisée lors de la création de règles et de la validation des mises à jour. L'appel se fait toujours sur le même compte (le rôle lié au service décrit la clé dans le compte du créateur de la règle).

  • logs:AssociateKmsKey— Permet au service d'associer la AWS KMS clé aux groupes de journaux créés lors de la correction. Cette autorisation est limitée aux groupes de journaux qui sont balisésCloudWatchTelemetryRuleManaged: true, ce qui limite l'association aux groupes de journaux gérés par des règles de télémétrie.

Note

Le rôle lié à un service n'effectue pas directement le chiffrement ou le déchiffrement des données du journal. Une fois que le service a associé la AWS KMS clé à un groupe de CloudWatch journaux, Logs utilise la clé pour toutes les opérations de chiffrement et de déchiffrement ultérieures sur ce groupe de journaux. Cross-account AWS KMS l'accès pendant la correction est géré par la politique AWS KMS clé (octroi de l'accès principal au logs.amazonaws.com service), et non par le rôle lié au service.

Comment les clés multirégions fonctionnent avec les règles de télémétrie

Multi-Region AWS KMS les clés partagent le même identifiant de clé d'une région à l'autre. Lorsqu'une règle de télémétrie comportant une AWS KMS clé est appliquée dans plusieurs régions, le service attribue automatiquement l'ARN clé à la région cible. Par exemple, si vous fournissez la clé ARN arn:aws:kms:us-east-1:123456789012:key/mrk-1234abcd et que la règle crée un groupe de journaux danseu-west-1, le service l'utilise arn:aws:kms:eu-west-1:123456789012:key/mrk-1234abcd pour le chiffrement dans cette région.

Vous devez vous assurer que la clé multirégion est répliquée dans toutes les régions où la règle s'applique. Si la clé n'a pas été répliquée dans une région cible, la correction des ressources de cette région échoue et le service recommence l'opération.

Mise à jour des paramètres de chiffrement

Lorsque vous mettez à jour une règle pour ajouter une AWS KMS clé, le service applique la clé uniquement aux groupes de journaux créés par la règle après la mise à jour. Le service ne chiffre pas rétroactivement les groupes de journaux créés par la règle avant l'ajout de la clé.

Lorsque vous supprimez la AWS KMS clé ARN d'une règle, le service modifie la configuration de chiffrement qu'il appliquait précédemment aux groupes de journaux gérés de la règle.

Sources de données prises en charge

Les sources de données suivantes sont prises en charge par les règles d'activation de la télémétrie. Chaque source de données est soumise à des considérations de comportement et de configuration spécifiques.

Journaux de flux Amazon VPC

Lors de la création de journaux de flux :

  • Utilise le modèle par défaut/aws/vpc/vpc-id si aucun n'est spécifié

  • Les journaux de flux existants créés par le client sont conservés

  • Les mises à jour des règles n’affectent que les nouveaux journaux de flux

  • Vous pouvez utiliser <vpc-id>des <account-id>macros pour diviser les groupes de journaux.

  • CloudWatch ne crée pas de journaux de flux pour les VPC qui ingèrent déjà des journaux dans Logs CloudWatch

  • Lorsque vous activez les mises à jour automatiques de configuration sur une règle, surveillez CloudWatch les journaux de flux qu'elle a créés et remédiez à la dérive de configuration. La dérive se produit lorsque le format du journal, le type de trafic, l'intervalle d'agrégation maximal ou le modèle de nom du groupe de journaux de destination d'un journal de flux géré par des règles ne correspondent plus à la règle. Pour y remédier, CloudWatch créez un nouveau journal de flux avec la configuration correcte, puis supprimez le journal obsolète.

  • Les mises à jour automatiques de configuration s'appliquent uniquement à Amazon VPC Flow Logs. CloudWatch ne modifie ni ne supprime jamais les journaux de flux que vous avez créés.

Journaux du plan de contrôle Amazon EKS

Lorsque vous activez la journalisation du plan de contrôle :

  • Utilise le modèle de groupe de CloudWatch journaux par défaut/aws/eks/<cluster-name>/cluster. Amazon EKS crée automatiquement un groupe de journaux par cluster.

  • Les mises à jour des règles concernent uniquement les nouveaux clusters ou uniquement les clusters pour lesquels les types de journaux délimités ne sont pas activés

  • Peut activer des types de journaux spécifiques : API, audit, authentificateur, ControllerManager, planificateur

AWS Journaux d'ACL Web WAF

Lors de la création de journaux WAF :

  • Utilise le modèle de groupe de CloudWatch journaux par défaut et préfixe toujours par aws-waf-logs-

  • Les mises à jour des règles concernent uniquement les nouvelles listes de contrôle d'accès Web ou les listes de contrôle d'accès Web existantes pour lesquelles la journalisation n'est pas activée dans les journaux CloudWatch

  • CloudWatch n'active pas les journaux pour les listes ACL Web qui ingèrent déjà des journaux dans Logs CloudWatch

Journaux du résolveur Amazon Route 53

Lorsque vous activez la journalisation des requêtes du résolveur :

  • Utilise le modèle de groupe de CloudWatch journaux par défaut/aws/route53resolver si aucun n'est spécifié

  • Vous pouvez utiliser <account-id>des macros pour diviser les groupes de journaux.

  • CloudWatch ne crée pas de journaux de requêtes du résolveur pour les VPC qui ingèrent déjà des journaux dans Logs CloudWatch

  • Les règles d'activation configurent la journalisation des requêtes Route 53 pour vos VPC en fonction de la portée des règles. CloudWatch ne découvre pas les profils Route 53 et les configurations associées.

Journaux d'accès NLB

Lorsque vous activez les journaux d'accès :

  • Utilise le modèle de groupe de CloudWatch journaux par défaut avec le préfixe/aws/nlb/access-logs si aucun n'est spécifié

  • CloudWatch n'active pas les livraisons de journaux pour les NLB qui ingèrent déjà des journaux dans Logs CloudWatch

CloudTrail Journaux utilisant un canal lié à un service

Lorsque vous activez CloudTrail les journaux à l'aide du chemin SLC :

  • Utilise des groupes de CloudWatch journaux gérés aws/cloudtrail/<event-types>

  • Les configurations de transfert de CloudTrail pistes existantes créées par le client sont préservées

  • CloudWatch Les règles d'activation utilisent uniquement un canal lié à un service pour ingérer les journaux

  • Les événements utilisent la période de conservation configurée pour le groupe de journaux

  • Pour les CloudTrail événements, dans le cadre de l'assistant d'activation, vous pouvez choisir au moins un type d'événement dans lequel vous souhaitez effectuer l'ingestion. CloudWatch

  • Si les événements sont livrés avec retard (indiqué par la raison de l'addendum DELIVERY_DELAY) et que vous avez précédemment configuré une période de conservation plus courte, les événements différés peuvent ne être disponibles que pendant la durée de la période de conservation la plus courte.

Astuce

Pour configurer CloudTrail les journaux dans plusieurs régions, utilisez le sélecteur de régions cibles lors de la création de votre règle d'activation. Cela permet de répliquer automatiquement la règle dans les régions que vous avez sélectionnées à partir de la région d'origine.

Statistiques détaillées d'Amazon Amazon EC2

Lorsque vous activez la surveillance détaillée :

  • Les changements d'état des instances peuvent affecter la collecte des métriques

AWS Hub de sécurité

Lorsque vous activez la journalisation de Security Hub :

  • Utilise le aws/securityhub_cspm modèle/résultats des groupes de CloudWatch journaux gérés

  • CloudWatch n'active pas les livraisons de journaux pour Security Hub qui ingèrent déjà des journaux dans des journaux gérés CloudWatch

Amazon Bedrock AgentCore
  • Activez à la fois les journaux et les traces émis par toutes les AgentCore primitives Bedrock disponibles, telles que Runtime, Browser Tools, Code Interpreter Tools, etc. Suivez l'expérience de la console Telemetry Configure pour créer une règle de distribution des journaux, puis créez une règle de livraison des traces.

  • Lors de la création d'une règle de transmission de traces, la recherche de transactions sera activée et une politique d'autorisation supplémentaire sera créée pour CloudWatch X-Ray permettre d'envoyer une trace corrélée au groupe de journaux géré de votre compte. En outre, une politique de X-Ray ressources sera créée pour permettre aux AgentCore primitives Bedrock actuelles et nouvelles de fournir des traces à votre compte.

Passerelle Amazon Bedrock Agentcore

Lorsque vous activez la journalisation de Bedrock Agentcore Gateway :

  • Utilise le modèle de groupe de CloudWatch journaux par défaut/aws/bedrock/agentcore si aucun n'est spécifié

  • CloudWatch n'active pas les livraisons de journaux pour Bedrock Agentcore Gateway qui ingère déjà des journaux dans Logs CloudWatch

Mémoire Amazon Bedrock Agentcore

Lorsque vous activez la journalisation de la mémoire Bedrock Agentcore :

  • Utilise le modèle de groupe de CloudWatch journaux par défaut/aws/bedrock/agentcore si aucun n'est spécifié

  • CloudWatch n'active pas les livraisons de journaux pour la mémoire Bedrock Agentcore qui ingère déjà des journaux dans Logs CloudWatch

CloudFront Distribution sur Amazon

Lorsque vous activez CloudFront la journalisation de la distribution :

  • CloudWatch n'active pas les livraisons de journaux pour les CloudFront distributions qui ingèrent déjà des journaux dans Logs CloudWatch

Journaux d'accès au serveur Amazon S3

La journalisation des accès au serveur S3 présente les contraintes suivantes :

  • Prend en charge le type de télémétrie LOGS avec le type de journal uniquement. S3_SERVER_ACCESS_LOGS

  • Ne prend en charge que les CloudWatch journaux comme type de destination.

  • Prend en charge uniquement les critères de sélection basés sur des balises pour cibler des compartiments S3 spécifiques.

Métriques du cluster Amazon MSK

Lorsque vous activez les métriques MSK Cluster :

  • Ne prend en charge que le type de télémétrie METRICS

  • Vous pouvez configurer des niveaux de surveillance améliorés (PER_BROKER, PER_TOPIC_PER_BROKER, etc.) pour contrôler la granularité des métriques collectées

  • Des règles avec différents niveaux de surveillance améliorés peuvent coexister pour le même cluster MSK

OpenTelemetry Métriques d'enrichissement

Lorsque vous activez les métriques OpenTelemetry d'enrichissement :

  • Ne prend en charge que le type de télémétrie METRICS

  • Il s'agit d'une activation au niveau du compte sans destination configurable par l'utilisateur

  • Resource-level les critères de sélection ne sont pas pris en charge

Identité des charges de travail Amazon Bedrock Agentcore

Lorsque vous activez la journalisation de l'identité de la charge de travail Bedrock Agentcore :

  • Utilise le modèle de groupe de CloudWatch journaux par défaut/aws/bedrock/agentcore si aucun n'est spécifié

  • CloudWatch n'active pas les livraisons de journaux pour Bedrock Agentcore Workload Identity qui ingère déjà des journaux dans Logs CloudWatch

Journaux de l'équilibreur de charge des applications Elastic Load Balancing

Lorsque vous activez la journalisation de l'équilibreur de charge des applications :

  • Prend en charge le type de télémétrie LOGS avec les types de journalALB_ACCESS_LOGS,ALB_CONNECTION_LOGS, et. ALB_HEALTH_CHECK_LOGS

  • Ne prend en charge que les CloudWatch journaux comme type de destination.

  • CloudWatch n'active pas les livraisons de journaux pour les équilibreurs de charge d'applications qui ingèrent déjà les types de journaux spécifiés dans Logs CloudWatch

Base de connaissances Amazon Bedrock

Lorsque vous activez la télémétrie de la base de connaissances Bedrock :

  • Supporte le type de télémétrie LOGS avec le type de journal. APPLICATION_LOGS

  • Supporte le type de télémétrie TRACES.

  • Pour les LOGS, seuls les CloudWatch journaux sont pris en charge comme type de destination.

  • CloudWatch n'active pas les livraisons de journaux pour les bases de connaissances Bedrock qui ingèrent déjà les types de journaux spécifiés dans Logs CloudWatch