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.
# Caractéristiques et concepts clés d'Amazon MSK
Les clusters Amazon MSK Provisioned offrent un large éventail de fonctionnalités et de capacités pour vous aider à optimiser les performances de votre cluster et à répondre à vos besoins de streaming. Les rubriques ci-dessous décrivent ces fonctionnalités en détail.
+ L'interface [AWS Management Console](https://console.aws.amazon.com/msk)
+ La [référence de l'API Amazon MSK](https://docs.aws.amazon.com/msk/1.0/apireference)
+ La [référence des commandes de la CLI Amazon MSK](https://docs.aws.amazon.com/cli/latest/reference/kafka/index.html)
**Topics**
+ [Types d’agents Amazon MSK](broker-instance-types.md)
+ [Tailles des agents Amazon MSK](broker-instance-sizes.md)
+ [Gestion du stockage pour les courtiers standard](msk-storage-management.md)
+ [Configuration provisionnée d'Amazon MSK](msk-configuration.md)
+ [Rééquilibrage intelligent pour les clusters](intelligent-rebalancing.md)
+ [Application de correctifs sur des clusters provisionnés par MSK](patching-impact.md)
+ [Broker hors ligne et basculement du client](troubleshooting-offlinebroker-clientfailover.md)
+ [Sécurité dans Amazon MSK](security.md)
+ [Journalisation Amazon MSK](msk-logging.md)
+ [Gestion des métadonnées](metadata-management.md)
+ [Opérations du sujet](msk-topic-operations-information.md)
+ [Ressources Amazon MSK](resources.md)
+ [Versions Apache Kafka](kafka-versions.md)
+ [Résoudre les problèmes liés à votre cluster Amazon MSK](troubleshooting.md)
# Types d’agents Amazon MSK
MSK Provisioned propose deux types de courtiers : Standard et Express. Les courtiers standard vous offrent la plus grande flexibilité pour configurer vos clusters, tandis que les courtiers Express offrent davantage d'élasticité, de débit, de résilience et permettent d'exécuter ease-of-use des applications de streaming à hautes performances.
Consultez les rubriques suivantes pour plus de détails sur chaque offre. Le tableau suivant met également en évidence la comparaison des principales fonctionnalités entre les courtiers Standard et Express.
| Fonctionnalité | Courtier standard | Courtier express |
| --- | --- | --- |
| [Gestion du stockage](msk-storage-management.md) | Géré par le client (les fonctionnalités incluent le stockage EBS, le stockage hiérarchisé, le débit de stockage provisionné, le dimensionnement automatique, les alertes de capacité de stockage) | Entièrement géré par MSK |
| [Instances prises en charge](broker-instance-sizes.md) | T3, M5, M7g | M7g |
| [Considérations relatives au dimensionnement et à l'échelle](bestpractices-intro.md) | Débit, connexions, partitions, stockage | Débit, connexions, partitions |
| [Dimensionnement des courtiers](msk-update-broker-count.md) | Mise à l'échelle verticale et horizontale | Mise à l'échelle verticale et horizontale |
| [Versions de Kafka](kafka-versions.md) | Consultez [Versions Apache Kafka](kafka-versions.md) | À partir de la version 3.6 |
| [Configuration d’Apache Kafka](msk-configuration.md) | Plus configurable | Principalement géré par MSK pour une meilleure résilience |
| [Sécurité](security.md) | Chiffrement, Private/Public accès, authentification et autorisation - IAM, SASL/SCRAM, mTLS, texte en clair, Kafka ACLs | Chiffrement, Private/Public accès, authentification et autorisation - IAM, SASL/SCRAM, mTLS, texte en clair, Kafka ACLs |
| [Surveillance](monitoring.md) | CloudWatch, Surveillance ouverte | CloudWatch, Surveillance ouverte |
**Note**
Vous ne pouvez pas faire passer un cluster MSK d'un type de courtier standard à un type de courtier Express en changeant de type de courtier à l'aide de l'API MSK. Vous devez créer un nouveau cluster avec le type de courtier souhaité (Standard ou Express).
**Topics**
+ [Courtiers Amazon MSK Standard](msk-broker-types-standard.md)
+ [Courtiers Amazon MSK Express](msk-broker-types-express.md)
# Courtiers Amazon MSK Standard
Les courtiers standard pour MSK Provisioned offrent la plus grande flexibilité pour configurer les performances de votre cluster. Vous pouvez choisir parmi une large gamme de configurations de clusters pour obtenir les caractéristiques de disponibilité, de durabilité, de débit et de latence requises pour vos applications. Vous pouvez également allouer de la capacité de stockage et l'augmenter selon vos besoins. Amazon MSK gère la maintenance matérielle des courtiers standard et des ressources de stockage associées, en réparant automatiquement les problèmes matériels qui peuvent survenir. Vous trouverez plus de détails dans ce document sur divers sujets liés aux courtiers standard, notamment les sujets relatifs à la [gestion du stockage](msk-storage-management.md), aux [configurations](msk-configuration-standard.md) et à la [maintenance](patching-impact.md#patching-standard-brokers).
# Courtiers Amazon MSK Express
Les courtiers Express pour MSK Provisioned simplifient la gestion d'Apache Kafka, le rendent plus rentable à exécuter à grande échelle et le rendent plus élastique grâce à la faible latence que vous attendez. Les courtiers incluent pay-as-you-go un stockage qui évolue automatiquement et ne nécessite aucun dimensionnement, provisionnement ou surveillance proactive. En fonction de la taille d'instance sélectionnée, chaque nœud de courtier peut fournir jusqu'à 3 fois plus de débit par courtier, évoluer jusqu'à 20 fois plus vite et récupérer 90 % plus rapidement que les courtiers Apache Kafka standard. Les courtiers Express sont préconfigurés avec les meilleures pratiques par défaut d'Amazon MSK et appliquent des quotas de débit pour les clients afin de minimiser les conflits de ressources entre les clients et les opérations en arrière-plan de Kafka.
Voici quelques facteurs et fonctionnalités clés à prendre en compte lors de l'utilisation des courtiers Express.
+ **Aucune gestion du stockage** : les courtiers Express éliminent le besoin de [provisionner ou de gérer des ressources de stockage](msk-storage-management.md). Vous bénéficiez d'un stockage élastique pay-as-you-go, pratiquement illimité et entièrement géré. Pour les cas d'utilisation à haut débit, il n'est pas nécessaire de raisonner sur les interactions entre les instances de calcul et les volumes de stockage, ni sur les goulots d'étranglement associés au débit. Ces fonctionnalités simplifient la gestion des clusters et éliminent les frais opérationnels liés à la gestion du stockage.
+ **Mise à l'échelle plus rapide** : les courtiers Express vous permettent de faire évoluer votre cluster et de déplacer des partitions jusqu'à 20 fois plus rapidement que les courtiers standard. Cette fonctionnalité est essentielle lorsque vous devez étendre votre cluster pour faire face aux pics de charge à venir ou si vous devez le faire évoluer pour réduire les coûts. Consultez les sections relatives à l'[extension de votre cluster](msk-update-broker-count.md), à la [suppression de courtiers](msk-remove-broker.md), à la [réattribution de partitions](msk-update-broker-type.md) et [à LinkedIn la configuration du régulateur de vitesse pour le rééquilibrage](cruise-control.md) pour plus de détails sur le dimensionnement de votre cluster.
+ **Débit supérieur** : les courtiers Express offrent jusqu'à 3 fois plus de débit par courtier que les courtiers standard. Par exemple, vous pouvez écrire des données en toute sécurité jusqu'à 500 MBps avec chaque broker Express de taille m7g.16xlarge, contre 153,8 MBps sur le broker Standard équivalent (les deux chiffres supposent une allocation de bande passante suffisante pour les opérations en arrière-plan, telles que la réplication et le rééquilibrage).
+ **Configuré pour une résilience élevée** : les courtiers Express proposent automatiquement diverses meilleures pratiques pour améliorer la résilience de votre cluster. Il s'agit notamment de garde-fous sur les configurations critiques d'Apache Kafka, de quotas de débit et de réservations de capacité pour les opérations en arrière-plan et les réparations imprévues. Ces fonctionnalités rendent l'exécution d'applications Apache Kafka à grande échelle plus sûre et plus facile. Consultez les sections sur [Configurations Express Broker](msk-configuration-express.md) et [Quota de courtiers Amazon MSK Express](limits.md#msk-express-quota) pour plus de détails.
+ **Aucune fenêtre de maintenance** : aucune fenêtre de maintenance n'est prévue pour les courtiers Express. Amazon MSK met automatiquement à jour le matériel de votre cluster de manière continue. Consultez [Patching for Express Brokers](https://docs.aws.amazon.com/msk/latest/developerguide/patching-impact.html#patching-express-brokers) pour plus de détails.
## Informations supplémentaires sur les courtiers Express
+ Les courtiers Express travaillent avec Apache Kafka APIs, mais ne prennent pas encore totalement en charge les KStreams API.
+ Les courtiers express ne sont disponibles que dans une AZs configuration 3.
+ Les courtiers Express ne sont disponibles que pour certaines tailles d'instance. Consultez les [tarifs Amazon MSK](https://aws.amazon.com/msk/pricing/) pour obtenir la liste mise à jour.
+ Les courtiers Express sont pris en charge sur les versions suivantes d'Apache Kafka : 3.6, 3.8 et 3.9.
+ Les courtiers express peuvent être créés avec le KRaft mode à partir de la version 3.9 d'Apache Kafka.
**Consultez ces blogs**
Pour plus d'informations sur les courtiers MSK Express et pour voir un exemple concret de courtiers Express utilisés, consultez les blogs suivants :
[Présentation d'Express Brokers pour Amazon MSK afin de fournir un débit élevé et une mise à l'échelle plus rapide pour vos clusters Kafka](https://aws.amazon.com/blogs/aws/introducing-express-brokers-for-amazon-msk-to-deliver-high-throughput-and-faster-scaling-for-your-kafka-clusters/)
[Express Brokers pour Amazon MSK : mise à l'échelle accélérée de Kafka avec des performances jusqu'à 20 fois plus rapides](https://aws.amazon.com/blogs/big-data/express-brokers-for-amazon-msk-turbo-charged-kafka-scaling-with-up-to-20-times-faster-performance/)
Ce blog explique comment les courtiers Express :
Fournissez un débit plus rapide, une évolutivité rapide et un temps de reprise amélioré en cas de panne
Éliminez les complexités liées à la gestion du stockage
# Tailles des agents Amazon MSK
Lorsque vous créez un cluster Amazon MSK Provisioned, vous spécifiez la taille des courtiers que vous souhaitez lui attribuer. Selon le [type de courtier](broker-instance-types.md), Amazon MSK prend en charge les tailles de courtier suivantes.
**Tailles de courtier standard**
+ kafka.t3.small
+ kafka.m5.large, kafka.m5.xlarge, kafka.m5.2xlarge, kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge, kafka.m5.24xlarge
+ kafka.m7g.large, kafka.m7g.xlarge, kafka.m7g.2xlarge, kafka.m7g.4xlarge, kafka.m7g.8xlarge, kafka.m7g.12xlarge, kafka.m7g.16xlarge
**Tailles des courtiers Express**
+ express.m7g.large, express.m7g.xlarge, express.m7g.2xlarge, express.m7g.4xlarge, express.m7g.8xlarge, express.m7g.12xlarge, express.m7g.16xlarge
**Note**
Certaines tailles de courtiers peuvent ne pas être disponibles dans certaines AWS régions. Consultez les tableaux de tarification des instances de courtier mis à jour sur la [page de tarification d'Amazon MSK](https://aws.amazon.com/msk/pricing/) pour obtenir la dernière liste des instances disponibles par région.
## Autres remarques sur la taille des courtiers
+ Les courtiers m7G utilisent des processeurs AWS Graviton (processeurs ARM personnalisés conçus par Amazon Web Services). Les courtiers M7g offrent une meilleure performance en termes de prix par rapport aux instances M5 comparables. Les courtiers M7g consomment moins d'énergie que les instances M5 comparables.
+ Amazon MSK prend en charge les courtiers m7G sur les clusters provisionnés par MSK exécutant les versions 2.8.2 et 3.3.2 de Kafka et supérieures.
+ Les courtiers M7g et M5 présentent des performances de débit de référence supérieures à celles des courtiers T3 et sont recommandés pour les charges de travail de production. Les courtiers M7g et M5 peuvent également avoir plus de partitions par courtier que les courtiers T3. Utilisez les courtiers M7g ou M5 si vous exécutez des charges de travail de production plus importantes ou si vous avez besoin d'un plus grand nombre de partitions. Pour en savoir plus sur les tailles d'instance M7g et M5, consultez [Amazon EC2 General](https://aws.amazon.com/ec2/instance-types/) Purpose Instances.
+ Les agents T3 ont la possibilité d'utiliser des crédits CPU pour augmenter temporairement les performances. Utilisez les agents T3 pour le développement à faible coût, si vous testez de petites ou de moyennes charges de travail de streaming ou si vous avez des charges de travail de streaming à faible débit qui peuvent connaître des pics. Nous vous recommandons d' proof-of-concepteffectuer un test pour déterminer si les courtiers T3 sont suffisants pour la production ou pour une charge de travail critique. Pour en savoir plus sur la taille des courtiers T3, consultez [Amazon EC2 T3 Instances](https://aws.amazon.com/ec2/instance-types/t3/).
Pour plus d'informations sur le choix de la taille des courtiers, consultez[Bonnes pratiques pour les courtiers Standard et Express](bestpractices-intro.md).
# Gestion du stockage pour les courtiers standard
Amazon MSK propose des fonctionnalités qui vous aident à gérer le stockage sur vos clusters MSK.
**Note**
Avec [les courtiers Express](msk-broker-types-express.md), vous n'avez pas besoin de provisionner ou de gérer les ressources de stockage utilisées pour vos données. Cela simplifie la gestion des clusters et élimine l'une des causes les plus fréquentes des problèmes opérationnels liés aux clusters Apache Kafka. Vous dépensez également moins, car vous n'avez pas à fournir de capacité de stockage inutilisée et vous ne payez que pour ce que vous utilisez.
**Type de courtier standard**
Avec [les courtiers standard](msk-broker-types-standard.md), vous pouvez choisir parmi une variété d'options et de fonctionnalités de stockage. Amazon MSK propose des fonctionnalités qui vous aident à gérer le stockage sur vos clusters MSK.
Pour plus d'informations sur la gestion du débit, consultez[Provisionner le débit de stockage pour les courtiers standard dans un cluster Amazon MSK](msk-provision-throughput.md).
**Topics**
+ [Stockage hiérarchisé pour les courtiers standard](msk-tiered-storage.md)
+ [Augmentez le stockage des courtiers Amazon MSK Standard](msk-update-storage.md)
+ [Gérez le débit de stockage pour les courtiers standard dans un cluster Amazon MSK](msk-provision-throughput-management.md)
# Stockage hiérarchisé pour les courtiers standard
Le stockage hiérarchisé est un niveau de stockage peu coûteux pour Amazon MSK qui évolue vers un stockage pratiquement illimité, ce qui rend rentable le développement d'applications de streaming de données.
Vous pouvez créer un cluster Amazon MSK configuré avec un stockage hiérarchisé qui équilibre les performances et les coûts. Amazon MSK stocke les données de streaming dans un niveau de stockage principal optimisé pour les performances jusqu'à ce qu'elles atteignent les limites de conservation des rubriques Apache Kafka. Amazon MSK déplace ensuite automatiquement les données vers le nouveau niveau de stockage à faible coût.
Lorsque votre application commence à lire des données depuis le stockage hiérarchisé, vous pouvez vous attendre à une augmentation de la latence de lecture pour les premiers octets. Lorsque vous commencez à lire les données restantes de manière séquentielle à partir du niveau à faible coût, vous pouvez vous attendre à des latences similaires à celles du niveau de stockage principal. Vous n'avez pas besoin de provisionner de stockage pour le stockage hiérarchisé à faible coût ni de gérer l'infrastructure. Vous pouvez stocker n'importe quelle quantité de données et ne payer que ce que vous utilisez. Cette fonctionnalité est compatible avec celle APIs introduite dans le [KIP-405 : Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage) Tiered Storage.
Pour plus d'informations sur le dimensionnement, la surveillance et l'optimisation de votre cluster de stockage hiérarchisé MSK, consultez [Meilleures pratiques pour exécuter des charges de travail de production à l'aide du stockage hiérarchisé Amazon](https://aws.amazon.com/blogs/big-data/best-practices-for-running-production-workloads-using-amazon-msk-tiered-storage/) MSK.
Certaines des fonctionnalités du stockage hiérarchisé sont décrites ci-dessous :
+ Vous pouvez passer à un espace de stockage pratiquement illimité. Vous n'avez pas à deviner comment mettre à l'échelle votre infrastructure Apache Kafka.
+ Vous pouvez conserver les données plus longtemps dans vos rubriques Apache Kafka ou augmenter le stockage de vos rubriques, sans avoir à augmenter le nombre d'agents.
+ Il fournit un tampon de sécurité de plus longue durée pour gérer les retards imprévus dans le traitement.
+ Vous pouvez retraiter les anciennes données dans leur ordre de production exact à l'aide de votre code de traitement des flux existant et de Kafka APIs.
+ Les partitions se rééquilibrent plus rapidement car les données du stockage secondaire ne nécessitent pas de réplication sur les disques de l'agent.
+ Les données entre les agents et le stockage hiérarchisé sont transférées au sein du VPC et ne transitent pas par Internet.
+ Un ordinateur client peut utiliser le même processus pour se connecter à de nouveaux clusters avec le stockage hiérarchisé activé que pour se connecter à un cluster sans stockage hiérarchisé activé. Consultez la section [Créer un ordinateur client](https://docs.aws.amazon.com/msk/latest/developerguide/create-client-machine.html).
## Exigences de stockage hiérarchisé pour les clusters Amazon MSK
+ Vous devez utiliser le client Apache Kafka version 3.0.0 ou supérieure pour créer une nouvelle rubrique avec le stockage hiérarchisé activé. Pour faire passer une rubrique existante au stockage hiérarchisé, vous pouvez reconfigurer un ordinateur client qui utilise une version du client Kafka antérieure à la version 3.0.0 (la version minimale d'Apache Kafka prise en charge est 2.8.2) pour activer le stockage hiérarchisé. Consultez [Étape 4 : créer une rubrique dans le cluster Amazon MSK](create-topic.md).
+ Le cluster Amazon MSK sur lequel le stockage hiérarchisé est activé doit utiliser la version 3.6.0 ou supérieure, ou la version 2.8.2.
## Contraintes et limites du stockage hiérarchisé pour les clusters Amazon MSK
Le stockage hiérarchisé présente les contraintes et limites suivantes :
+ Assurez-vous que les clients ne sont pas configurés pour `read_committed` lire depuis le remote\$1tier dans Amazon MSK, sauf si l'application utilise activement la fonctionnalité de transactions.
+ Le stockage hiérarchisé n'est pas disponible dans les régions AWS GovCloud (États-Unis).
+ Le stockage hiérarchisé s'applique uniquement aux clusters en mode provisionné.
+ Le stockage hiérarchisé ne prend pas en charge la taille du broker t3.small.
+ La période de conservation minimale dans le stockage à faible coût est de 3 jours. Il n'y a pas de durée de conservation minimale pour le stockage principal.
+ Le stockage hiérarchisé ne prend pas en charge les répertoires de journaux multiples sur un agent (fonctionnalités liées au JBOD).
+ Le stockage hiérarchisé ne prend pas en charge les sujets compactés. Assurez-vous que le fichier cleanup.policy de toutes les rubriques pour lesquelles le stockage hiérarchisé est activé est configuré sur « DELETE » uniquement.
+ Le cluster de stockage hiérarchisé ne prend pas en charge la modification de la politique log.cleanup.policy d'un sujet après sa création.
+ Le stockage hiérarchisé peut être désactivé pour des sujets individuels, mais pas pour l'ensemble du cluster. Une fois désactivé, le stockage hiérarchisé ne peut pas être réactivé pour une rubrique.
+ Si vous utilisez Amazon MSK version 2.8.2.tiered, vous ne pouvez migrer que vers une autre version d'Apache Kafka compatible avec le stockage hiérarchisé. Si vous ne souhaitez pas continuer à utiliser une version compatible avec le stockage hiérarchisé, créez un nouveau cluster MSK et migrez vos données vers celui-ci.
+ L' kafka-log-dirsoutil ne peut pas indiquer la taille des données de stockage hiérarchisé. L'outil indique uniquement la taille des segments de journaux dans le stockage principal.
Pour plus d'informations sur les paramètres par défaut et les contraintes dont vous devez tenir compte lorsque vous configurez le stockage hiérarchisé au niveau de la rubrique, voir[Directives relatives à la configuration du stockage hiérarchisé Amazon MSK au niveau des sujets](msk-guidelines-tiered-storage-topic-level-config.md).
# Comment les segments de journal sont copiés vers un stockage hiérarchisé pour une rubrique Amazon MSK
Lorsque vous activez le stockage hiérarchisé pour une rubrique nouvelle ou existante, Apache Kafka copie les segments de journaux fermés du stockage principal vers le stockage hiérarchisé.
+ Apache Kafka copie uniquement les segments de journaux fermés. Il copie tous les messages contenus dans le segment du journal vers un stockage hiérarchisé.
+ Les segments actifs ne sont pas éligibles à la hiérarchisation. La taille du segment de journal (segment.bytes) ou le temps d'exécution du segment (segment.ms) contrôlent le taux de fermeture des segments, et le taux auquel Apache Kafka les copie ensuite vers un stockage hiérarchisé.
Les paramètres de conservation d'une rubrique pour laquelle le stockage hiérarchisé est activé sont différents des paramètres d'une rubrique sans stockage hiérarchisé activé. Les règles suivantes contrôlent la conservation des messages dans les rubriques pour lesquelles le stockage hiérarchisé est activé :
+ Vous définissez la rétention dans Apache Kafka avec deux paramètres : log.retention.ms (heure) et log.retention.bytes (taille). Ces paramètres déterminent la durée totale et la taille des données conservées par Apache Kafka dans le cluster. Que vous activiez ou non le mode de stockage hiérarchisé, vous définissez ces configurations au niveau du cluster. Vous pouvez remplacer les paramètres au niveau de la rubrique par des configurations de rubrique.
+ Lorsque vous activez le stockage hiérarchisé, vous pouvez également spécifier la durée pendant laquelle le niveau de stockage hautes performances principal stocke les données. Par exemple, si une rubrique possède un paramètre de conservation globale (log.retention.ms) de 7 jours et une rétention locale (local.retention.ms) de 12 heures, le stockage principal du cluster ne conserve les données que pendant les 12 premières heures. Le niveau de stockage à faible coût conserve les données pendant 7 jours complets.
+ Les paramètres de conservation habituels s'appliquent à l'intégralité du journal. Cela inclut ses parties principales et hiérarchisées.
+ Les paramètres local.retention.ms ou local.retention.bytes contrôlent la conservation des messages dans le stockage principal. Apache Kafka copie les segments de journal fermés vers un stockage hiérarchisé dès leur fermeture (sur la base de segment.bytes ou segment.ms), indépendamment des paramètres de rétention locaux. Une fois les segments copiés vers le stockage hiérarchisé, ils restent dans le stockage principal jusqu'à ce que les seuils local.retention.ms ou local.retention.bytes soient atteints. À ce stade, les données sont supprimées du stockage principal mais restent disponibles dans le stockage hiérarchisé. Cela vous permet de conserver les données récentes sur le stockage principal à hautes performances pour un accès rapide, tandis que les données plus anciennes sont traitées à partir du stockage hiérarchisé à faible coût.
+ Lorsqu'Apache Kafka copie un message d'un segment de journal vers un stockage hiérarchisé, il le supprime du cluster en fonction des paramètres retention.ms ou retention.bytes.
## Exemple de scénario de stockage hiérarchisé Amazon MSK
Ce scénario illustre le comportement d'une rubrique existante contenant des messages dans le stockage principal lorsque le stockage hiérarchisé est activé. Pour activer le stockage hiérarchisé sur ce sujet, vous devez définir remote.storage.enable sur `true`. Dans cet exemple, retention.ms est défini sur 5 jours et local.retention.ms est défini sur 2 jours. Voici la suite des événements lorsqu'un segment expire.
**Temps T0 - Avant d'activer le stockage hiérarchisé.**
Avant d'activer le stockage hiérarchisé pour cette rubrique, il existe deux segments de journal. L'un des segments est actif pour une partition de rubrique 0 existante.
![\[Temps T0 - Avant d'activer le stockage hiérarchisé.\]](http://docs.aws.amazon.com/fr_fr/msk/latest/developerguide/images/tiered-storage-segments-1.png)
**Temps T1 (< 2 jours) - Stockage hiérarchisé activé. Segment 0 copié vers le stockage hiérarchisé.**
Après avoir activé le stockage hiérarchisé pour cette rubrique, Apache Kafka copie le segment 0 du journal fermé vers le stockage hiérarchisé dès sa fermeture. Le segment se ferme en fonction des paramètres segment.bytes ou segment.ms, et non en fonction des paramètres de rétention. Apache Kafka en conserve également une copie dans le stockage principal. Le segment 1 actif ne peut pas encore être copié vers un stockage hiérarchisé car il est toujours actif et n'est pas fermé. Dans cette chronologie, Amazon MSK n'applique encore aucun des paramètres de rétention pour les messages des segments 0 et 1. (local.rétention). bytes/ms, retention.ms/bytes)
![\[Temps T1 (< 2 jours) - Stockage hiérarchisé activé. Segment 0 copié vers le stockage hiérarchisé.\]](http://docs.aws.amazon.com/fr_fr/msk/latest/developerguide/images/tiered-storage-segments-2.png)
**Temps T2 - Conservation locale en vigueur.**
Après 2 jours, le seuil de rétention local est atteint pour le segment 0. C'est le paramétrage de local.retention.ms sur 2 jours qui détermine cela. Le segment 0 est désormais supprimé du stockage principal, mais il reste disponible dans le stockage hiérarchisé. Notez que le segment 0 était déjà copié vers le stockage hiérarchisé à l'heure T1 lors de sa fermeture, et non à l'heure T2 lorsque la rétention locale a expiré. Le segment 1 actif n'est pas encore éligible à la suppression ni à la copie vers un stockage hiérarchisé, car il est toujours actif.
![\[Temps T2 - Conservation locale en vigueur.\]](http://docs.aws.amazon.com/fr_fr/msk/latest/developerguide/images/tiered-storage-segments-3.png)
**Temps T3 - Conservation globale en vigueur.**
Après 5 jours, les paramètres de conservation prennent effet et Kafka efface le segment 0 du journal et les messages associés du stockage hiérarchisé. Le segment 1 n'est pas encore éligible à l'expiration ni à la copie sur un stockage hiérarchisé, car il est actif. Le segment 1 n'est pas encore fermé, il n'est donc pas éligible au déploiement de segment.
![\[Temps T3 - Conservation globale en vigueur.\]](http://docs.aws.amazon.com/fr_fr/msk/latest/developerguide/images/tiered-storage-segments-4.png)
# Créez un cluster Amazon MSK avec un stockage hiérarchisé avec AWS Management Console
Ce processus décrit comment créer un cluster Amazon MSK de stockage hiérarchisé à l'aide du. AWS Management Console
1. Ouvrez la console Amazon MSK à l'adresse [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Choisissez **Créer un cluster**.
1. Choisissez **Création personnalisée** pour le stockage hiérarchisé.
1. Attribuez un nom au cluster.
1. Dans le **type de cluster**, sélectionnez **Provisionné**.
1. Choisissez une version d’Amazon Kafka prenant en charge le stockage hiérarchisé qu’Amazon MSK utilisera pour créer le cluster.
1. Spécifiez une taille de broker autre que **kafka.t3.small**.
1. Spécifiez le nombre d'agents qu'Amazon MSK doit créer dans chaque zone de disponibilité. Le minimum est d'un agent par zone de disponibilité et le maximum est de 30 agents par cluster.
1. Spécifiez le nombre de zones dans lesquelles les agents sont répartis.
1. Spécifiez le nombre d'agents Apache Kafka déployés par zone.
1. Sélectionnez **Options de stockage**. Cela inclut le **stockage hiérarchisé et le stockage EBS** pour activer le mode de stockage hiérarchisé.
1. Suivez les étapes restantes de l'assistant de création de cluster. Une fois l'opération terminée, le **stockage hiérarchisé et le stockage EBS** apparaissent comme mode de stockage du cluster dans la vue **Vérifier et créer**.
1. Sélectionnez **Créer un cluster**.
# Créez un cluster Amazon MSK avec un stockage hiérarchisé avec AWS CLI
Pour activer le stockage hiérarchisé sur un cluster, créez le cluster avec la version et l'attribut Apache Kafka appropriés pour le stockage hiérarchisé. Suivez l'exemple de code ci-dessous. Suivez également les étapes décrites dans la prochaine section [Créez un sujet Kafka avec le stockage hiérarchisé activé avec AWS CLI](#msk-create-topic-tiered-storage-cli).
Voir [create-cluster](https://docs.aws.amazon.com//cli/latest/reference/kafka/create-cluster.html) pour une liste complète des attributs pris en charge pour la création de clusters.
```
aws kafka create-cluster \
—cluster-name "MessagingCluster" \
—broker-node-group-info file://brokernodegroupinfo.json \
—number-of-broker-nodes 3 \
--kafka-version "3.6.0" \
--storage-mode "TIERED"
```
## Créez un sujet Kafka avec le stockage hiérarchisé activé avec AWS CLI
Pour terminer le processus que vous avez entamé lorsque vous avez créé un cluster avec le stockage hiérarchisé activé, créez également une rubrique avec le stockage hiérarchisé activé avec les attributs du dernier exemple de code. Les attributs spécifiques au stockage hiérarchisé sont les suivants :
+ `local.retention.ms` (par exemple, 10 minutes) pour les paramètres de conservation basés sur le temps ou `local.retention.bytes` pour les limites de taille des segments de journaux.
+ `remote.storage.enable` défini sur `true` pour activer le stockage hiérarchisé.
La configuration suivante utilise local.retention.ms, mais vous pouvez remplacer cet attribut par local.retention.bytes. Cet attribut contrôle le temps qui peut s'écouler ou le nombre d'octets qu'Apache Kafka peut copier avant que ce dernier ne copie les données du stockage principal vers le stockage hiérarchisé. Voir [Configuration au niveau des rubriques](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration) pour plus de détails sur les attributs de configuration pris en charge.
**Note**
Vous devez utiliser le client Apache Kafka version 3.0.0 ou supérieure. Ces versions prennent en charge un paramètre appelé `remote.storage.enable` uniquement dans les versions clientes de `kafka-topics.sh`. Pour activer le stockage hiérarchisé sur une rubrique existante qui utilise une version antérieure d'Apache Kafka, consultez la section [Activation du stockage hiérarchisé sur une rubrique Amazon MSK existante](msk-enable-disable-topic-tiered-storage-cli.md#msk-enable-topic-tiered-storage-cli).
```
bin/kafka-topics.sh --create --bootstrap-server $bs --replication-factor 2 --partitions 6 --topic MSKTutorialTopic --config remote.storage.enable=true --config local.retention.ms=100000 --config retention.ms=604800000 --config segment.bytes=134217728
```
# Activer et désactiver le stockage hiérarchisé sur une rubrique Amazon MSK existante
Ces sections expliquent comment activer et désactiver le stockage hiérarchisé sur une rubrique que vous avez déjà créée. Pour créer un nouveau cluster et une nouvelle rubrique avec le stockage hiérarchisé activé, voir [Création d'un cluster avec stockage hiérarchisé à l'aide d' AWS Management Console](https://docs.aws.amazon.com//msk/latest/developerguide/msk-create-cluster-tiered-storage-console).
## Activation du stockage hiérarchisé sur une rubrique Amazon MSK existante
Pour activer le stockage hiérarchisé sur une rubrique existante, utilisez la syntaxe de commande `alter` de l'exemple suivant. Lorsque vous activez le stockage hiérarchisé sur une rubrique existante, vous n'êtes pas limité à une certaine version du client Apache Kafka.
```
bin/kafka-configs.sh --bootstrap-server $bsrv --alter --entity-type topics --entity-name msk-ts-topic --add-config 'remote.storage.enable=true, local.retention.ms=604800000, retention.ms=15550000000'
```
## Désactiver le stockage hiérarchisé sur une rubrique Amazon MSK existante
Pour désactiver le stockage hiérarchisé sur une rubrique existante, utilisez la syntaxe de commande `alter` dans le même ordre que lorsque vous activez le stockage hiérarchisé.
```
bin/kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name MSKTutorialTopic --add-config 'remote.log.msk.disable.policy=Delete, remote.storage.enable=false'
```
**Note**
Lorsque vous désactivez le stockage hiérarchisé, vous supprimez complètement les données des rubriques dans le stockage hiérarchisé. Apache Kafka conserve les données de stockage principales, mais applique toujours les règles de conservation principales basées sur `local.retention.ms`. Lorsque vous désactivez le stockage hiérarchisé sur une rubrique, vous ne pouvez pas le réactiver. Si vous souhaitez désactiver le stockage hiérarchisé sur une rubrique existante, vous n'êtes pas limité à une certaine version du client Apache Kafka.
# Activez le stockage hiérarchisé sur un cluster Amazon MSK existant à l'aide de la CLI AWS
**Note**
Vous ne pouvez activer le stockage hiérarchisé que si log.cleanup.policy de votre cluster est défini sur `delete`, car les rubriques compactées ne sont pas prises en charge sur le stockage hiérarchisé. Plus tard, vous pourrez configurer le log.cleanup.policy d'une rubrique individuelle sur `compact` si le stockage hiérarchisé n'est pas activé sur cette rubrique en particulier. Voir [Configuration au niveau des rubriques](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration) pour plus de détails sur les attributs de configuration pris en charge.
1. **Mettez à jour la version de Kafka** : les versions de cluster ne sont pas de simples entiers. Pour trouver la version actuelle du cluster, utilisez l'`DescribeCluster`opération ou la commande `describe-cluster` AWS CLI. Voici un exemple de version : `KTVPDKIKX0DER`.
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version 3.6.0
```
1. Modifiez le mode de stockage en cluster. L'exemple de code suivant montre comment modifier le mode de stockage du cluster en `TIERED` à l'aide de l'API [https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html).
```
aws kafka update-storage --current-version Current-Cluster-Version --cluster-arn Cluster-arn --storage-mode TIERED
```
# Mettre à jour le stockage hiérarchisé sur un cluster Amazon MSK existant à l'aide de la console
Ce processus décrit comment mettre à jour un cluster Amazon MSK de stockage hiérarchisé à l'aide du. AWS Management Console
Assurez-vous que la version actuelle d'Apache Kafka de votre cluster MSK est 2.8.2.tiered. Reportez-vous à section [Mise à jour de la version Apache Kafka](https://docs.aws.amazon.com/msk/latest/developerguide/version-upgrades.html) si vous devez mettre à niveau votre cluster MSK vers la version 2.8.2.tiered.
**Note**
Vous ne pouvez activer le stockage hiérarchisé que si log.cleanup.policy de votre cluster est défini sur `delete`, car les rubriques compactées ne sont pas prises en charge sur le stockage hiérarchisé. Plus tard, vous pourrez configurer le log.cleanup.policy d'une rubrique individuelle sur `compact` si le stockage hiérarchisé n'est pas activé sur cette rubrique en particulier. Voir [Configuration au niveau des rubriques](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration) pour plus de détails sur les attributs de configuration pris en charge.
1. Ouvrez la console Amazon MSK à l'adresse [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Accédez à la page de résumé du cluster et choisissez **Propriétés**.
1. Accédez à la section **Stockage** et choisissez **Modifier le mode de stockage du cluster**.
1. Choisissez **Stockage hiérarchisé et stockage EBS**, puis **Enregistrer les modifications**.
# Augmentez le stockage des courtiers Amazon MSK Standard
Vous pouvez augmenter la quantité de stockage EBS par agent. Vous ne pouvez pas réduire le stockage.
Les volumes de stockage restent disponibles pendant cette opération de mise à l'échelle.
**Important**
Lorsque le stockage est dimensionné pour un cluster MSK, le stockage supplémentaire est immédiatement disponible. Toutefois, le cluster a besoin d'une période de refroidissement après chaque événement de mise à l'échelle du stockage. Amazon MSK utilise cette période de refroidissement pour optimiser le cluster avant qu'il ne puisse être redimensionné. Cette période peut aller d'un minimum de 6 heures à plus de 24 heures, en fonction de la taille du stockage et de l'utilisation du cluster, ainsi que du trafic. Cela s'applique à la fois aux événements de mise à l'échelle automatique et à la mise à l'échelle manuelle à l'aide de l'[UpdateBrokerStorage](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage)opération. Pour plus d'informations sur la mise à l'échelle correcte de votre stockage, consultez [Bonnes pratiques pour les courtiers standard](bestpractices.md).
Vous pouvez utiliser le stockage hiérarchisé pour augmenter et passer en illimité le volume de stockage de votre agent. Consultez [Stockage hiérarchisé pour les courtiers standard](msk-tiered-storage.md).
**Topics**
+ [Dimensionnement automatique pour les clusters Amazon MSK](msk-autoexpand.md)
+ [Mise à l'échelle manuelle pour les courtiers standard](manually-expand-storage.md)
# Dimensionnement automatique pour les clusters Amazon MSK
Pour étendre automatiquement le stockage de votre cluster en réponse à une utilisation accrue, vous pouvez configurer une politique de mise à l'échelle automatique (autoscaling) des applications pour Amazon MSK. Dans une politique de type autoscaling, vous définissez l'utilisation du disque cible et la capacité de mise à l'échelle maximale.
Avant d'utiliser la mise à l'échelle automatique (autoscaling) pour Amazon MSK, vous devez tenir compte des points suivants :
+
**Important**
Une action de mise à l'échelle du stockage ne peut avoir lieu qu'une fois toutes les six heures.
Nous vous recommandons de commencer par un volume de stockage de taille adaptée à vos besoins de stockage. Pour obtenir des conseils sur la mise à l'échelle correcte de votre cluster, consultez [Dimensionnez correctement votre cluster : nombre de courtiers standard par cluster](bestpractices.md#brokers-per-cluster).
+ Amazon MSK ne réduit pas le stockage de cluster en réponse à une utilisation réduite. Amazon MSK ne prend pas en charge la réduction de la taille des volumes de stockage. Si vous devez réduire la taille de votre stockage de cluster, vous devez migrer votre cluster existant vers un cluster ayant un espace de stockage plus petit. Pour en savoir plus sur la migration d'un cluster, consultez [Migrer vers un cluster MSK](migration.md).
+ Amazon MSK ne prend pas en charge le dimensionnement automatique dans les régions Asie-Pacifique (Osaka), Afrique (Le Cap) et Asie-Pacifique (Malaisie).
+ Lorsque vous associez une politique d'auto-scaling à votre cluster, Amazon EC2 Auto Scaling crée automatiquement une CloudWatch alarme Amazon pour le suivi des cibles. Si vous supprimez un cluster doté d'une politique d'auto-scaling, cette CloudWatch alarme persiste. Pour supprimer l' CloudWatch alarme, vous devez supprimer une politique d'auto-scaling d'un cluster avant de le supprimer. Pour en savoir plus sur le suivi des cibles, consultez [Politiques de mise à l'échelle de suivi des cibles pour Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) dans le *Guide de l'utilisateur Amazon EC2 Auto Scaling*.
**Topics**
+ [Détails de la politique de dimensionnement automatique pour Amazon MSK](msk-autoexpand-details.md)
+ [Configurer le dimensionnement automatique pour votre cluster Amazon MSK](msk-autoexpand-setup.md)
# Détails de la politique de dimensionnement automatique pour Amazon MSK
Votre politique autoscaling définit les paramètres suivants pour votre cluster :
+ **Cible d'utilisation du stockage** : seuil d'utilisation du stockage utilisé par Amazon MSK pour déclencher une opération de mise à l'échelle automatique (autoscaling). Vous pouvez définir la cible d'utilisation entre 10 % et 80 % de la capacité de stockage actuelle. Nous vous recommandons de définir la cible d'utilisation du stockage entre 50 % et 60 %.
+ **Capacité de stockage maximale** : limite de mise à l'échelle maximale qu'Amazon MSK peut définir pour le stockage de votre agent. Vous pouvez définir une capacité de stockage maximale de 16 TiO par agent. Pour de plus amples informations, veuillez consulter [Quota d'Amazon MSK](limits.md).
Lorsqu'Amazon MSK détecte que votre métrique `Maximum Disk Utilization` est égale ou supérieure au paramètre `Storage Utilization Target`, il augmente votre capacité de stockage d'une quantité égale au plus grand des deux chiffres : 10 GiO ou 10 % du stockage actuel. Par exemple, si vous avez 1 000 GiO, cette quantité est de 100 GiO. Le service vérifie l'utilisation de votre stockage toutes les minutes. Les opérations de mise à l'échelle supplémentaires continuent d'augmenter le stockage d'une quantité égale au plus grand des deux nombres : 10 GiO ou 10 % du stockage actuel.
Pour déterminer si des opérations d'auto-scaling ont eu lieu, utilisez l'[ ListClusterOperations](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-operations.html#ListClusterOperations)opération.
# Configurer le dimensionnement automatique pour votre cluster Amazon MSK
Vous pouvez utiliser la console Amazon MSK, l'API Amazon MSK ou CloudFormation implémenter le dimensionnement automatique pour le stockage. CloudFormation le support est disponible via [Application Auto Scaling](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html).
**Note**
Vous ne pouvez pas implémenter de mécanisme d'autoscaling lorsque vous créez un cluster. Vous devez d'abord créer le cluster, puis créer et activer une politique d'autoscaling pour celui-ci. Toutefois, vous pouvez créer la politique pendant que le service Amazon MSK crée votre cluster.
**Topics**
+ [Configurer le dimensionnement automatique à l'aide de l'Amazon MSK AWS Management Console](msk-autoexpand-setup-console.md)
+ [Configurer le dimensionnement automatique à l'aide de la CLI](msk-autoexpand-setup-cli.md)
+ [Configurer le dimensionnement automatique pour Amazon MSK à l'aide de l'API](msk-autoexpand-setup-api.md)
# Configurer le dimensionnement automatique à l'aide de l'Amazon MSK AWS Management Console
Ce processus décrit comment utiliser la console Amazon MSK pour implémenter le dimensionnement automatique pour le stockage.
1. Connectez-vous à la AWS Management Console console Amazon MSK et ouvrez-la [https://console.aws.amazon.com/msk/chez vous ? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dans la liste des clusters, choisissez votre cluster. Cela vous amène à une page répertoriant les détails du cluster.
1. Dans la section **Autoscaling pour le stockage**, choisissez **Configurer**.
1. Créez et nommez une politique d'autoscaling Spécifiez la cible d'utilisation du stockage, la capacité de stockage maximale et la métrique cible.
1. Sélectionnez `Save changes`.
Lorsque vous enregistrez et activez la nouvelle politique, celle-ci devient active pour le cluster. Amazon MSK étend ensuite le stockage du cluster une fois la cible d'utilisation du stockage atteinte.
# Configurer le dimensionnement automatique à l'aide de la CLI
Ce processus décrit comment utiliser la CLI Amazon MSK pour implémenter le dimensionnement automatique pour le stockage.
1. Utilisez la [ RegisterScalableTarget](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands)commande pour enregistrer un objectif d'utilisation du stockage.
1. Utilisez la [ PutScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands)commande pour créer une politique d'extension automatique.
# Configurer le dimensionnement automatique pour Amazon MSK à l'aide de l'API
Ce processus décrit comment utiliser l'API Amazon MSK pour implémenter le dimensionnement automatique pour le stockage.
1. Utilisez l'[ RegisterScalableTarget](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_RegisterScalableTarget.html)API pour enregistrer un objectif d'utilisation du stockage.
1. Utilisez l'[ PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html)API pour créer une politique d'extension automatique.
# Mise à l'échelle manuelle pour les courtiers standard
Pour augmenter le stockage, attendez que l'état du cluster soit `ACTIVE`. La mise à l'échelle du stockage est soumise à une période de refroidissement d'au moins six heures entre les événements. Même si l'opération met immédiatement à disposition du stockage supplémentaire, le service effectue des optimisations sur votre cluster qui peuvent prendre jusqu'à 24 heures ou plus. La durée de ces optimisations est proportionnelle à la taille de votre stockage.
## Augmenter le stockage des courtiers à l'aide du AWS Management Console
1. Ouvrez la console Amazon MSK à l'adresse [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Choisissez le cluster MSK pour lequel vous souhaitez mettre à jour le stockage d'agent.
1. Dans la section **Stockage**, sélectionnez **Modifier**.
1. Spécifiez le volume de stockage souhaité. Vous pouvez uniquement augmenter la quantité de stockage, vous ne pouvez pas la diminuer.
1. Sélectionnez **Enregistrer les modifications**.
## Augmenter le stockage des courtiers à l'aide du AWS CLI
Exécutez la commande suivante, en la *ClusterArn* remplaçant par le Amazon Resource Name (ARN) que vous avez obtenu lors de la création de votre cluster. Si vous n'avez pas l'ARN pour votre cluster, vous pouvez le trouver en listant tous les clusters. Pour de plus amples informations, veuillez consulter [Répertorier les clusters Amazon MSK](msk-list-clusters.md).
Remplacez *Current-Cluster-Version* par la version actuelle du cluster.
**Important**
Les versions de cluster ne sont pas des entiers simples. Pour trouver la version actuelle du cluster, utilisez l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)opération ou la commande [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html) AWS CLI . Voici un exemple de version : `KTVPDKIKX0DER`.
Le *Target-Volume-in-GiB* paramètre représente la quantité de stockage que vous souhaitez attribuer à chaque broker. Il est seulement possible de mettre à jour le stockage pour tous les agents. Vous ne pouvez pas spécifier d'agents individuels pour lesquels mettre à jour le stockage. La valeur que vous spécifiez *Target-Volume-in-GiB* doit être un nombre entier supérieur à 100 GiB. Le stockage par agent après l'opération de mise à jour ne peut pas dépasser 16 384 Gio.
```
aws kafka update-broker-storage --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-broker-ebs-volume-info '{"KafkaBrokerNodeId": "All", "VolumeSizeGB": Target-Volume-in-GiB}'
```
## Mise à l'échelle du stockage d'agent à l'aide de l'API
Pour mettre à jour le stockage d'un broker à l'aide de l'API, consultez [UpdateBrokerStorage](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage).
# Gérez le débit de stockage pour les courtiers standard dans un cluster Amazon MSK
Pour plus d'informations sur la manière de provisionner le débit à l'aide de la console, de la CLI et de l'API Amazon MSK, consultez. [Provisionner le débit de stockage pour les courtiers standard dans un cluster Amazon MSK](msk-provision-throughput.md)
**Topics**
+ [Problèmes de débit et paramètres de débit maximum pour les courtiers Amazon MSK](#throughput-bottlenecks)
+ [Mesurer le débit de stockage d'un cluster Amazon MSK](#throughput-metrics)
+ [Valeurs de mise à jour de configuration pour le stockage provisionné dans un cluster Amazon MSK](#provisioned-throughput-config)
+ [Provisionner le débit de stockage pour les courtiers standard dans un cluster Amazon MSK](msk-provision-throughput.md)
## Problèmes de débit et paramètres de débit maximum pour les courtiers Amazon MSK
Les goulots d'étranglement du débit des agents ont plusieurs causes : le débit du volume, le débit du réseau Amazon EC2 vers Amazon EBS et le débit de sortie d'Amazon EC2. Vous pouvez activer le débit de stockage provisionné pour ajuster le débit du volume. Cependant, les limites de débit des agents peuvent être causées par le débit du réseau Amazon EC2 vers Amazon EBS et le débit de sortie d'Amazon EC2.
Le débit de sortie d'Amazon EC2 dépend du nombre de groupes de consommateurs et du nombre de consommateurs par groupe de consommateurs. En outre, le débit du réseau Amazon EC2 vers Amazon EBS et le débit de sortie Amazon EC2 sont plus élevés pour les courtiers de grande taille.
Pour des volumes de 10 Go ou plus, vous pouvez provisionner un débit de stockage de 250 Mio par seconde ou plus. 250 Mio par seconde est la valeur par défaut. Pour provisionner le débit de stockage, vous devez choisir la taille du broker kafka.m5.4xlarge ou supérieure (ou kafka.m7g.2xlarge ou supérieure), et vous pouvez spécifier le débit maximal comme indiqué dans le tableau suivant.
****
| taille du courtier | Débit de stockage maximal (Mio/s) |
| --- | --- |
| kafka.m5.4xlarge | 593 |
| kafka.m5.8xlarge | 850 |
| kafka.m5.12xlarge | 1 000 |
| kafka.m5.16xlarge | 1 000 |
| kafka.m5.24xlarge | 1 000 |
| kafka.m7g.2xlarge | 312,5 |
| kafka.m7g.4xlarge | 625 |
| kafka.m7g.8xlarge | 1 000 |
| kafka.m7g, 12 x large | 1 000 |
| kafka.m7g, 16 x large | 1 000 |
## Mesurer le débit de stockage d'un cluster Amazon MSK
Vous pouvez utiliser les métriques `VolumeReadBytes` et `VolumeWriteBytes` pour mesurer le débit de stockage moyen d'un cluster. La somme de ces deux mesures donne le débit de stockage moyen en octets. Pour obtenir le débit de stockage moyen d'un cluster, définissez ces deux métriques sur SUM et sur la période 1 minute, puis utilisez la formule suivante.
```
Average storage throughput in MiB/s = (Sum(VolumeReadBytes) + Sum(VolumeWriteBytes)) / (60 * 1024 * 1024)
```
Pour obtenir des informations sur les métriques `VolumeReadBytes` et `VolumeWriteBytes`, consultez [Surveillance de niveau `PER_BROKER`](metrics-details.md#broker-metrics).
## Valeurs de mise à jour de configuration pour le stockage provisionné dans un cluster Amazon MSK
Vous pouvez mettre à jour votre configuration Amazon MSK avant ou après avoir activé le débit provisionné. Toutefois, vous ne verrez pas le débit souhaité tant que vous n'aurez pas effectué les deux actions suivantes : mettre à jour le paramètre de configuration `num.replica.fetchers` et activer le débit provisionné.
Dans la configuration Amazon MSK par défaut, `num.replica.fetchers` a une valeur de 2. Pour mettre à jour votre `num.replica.fetchers`, vous pouvez utiliser les valeurs suggérées dans le tableau suivant. Ces valeurs sont fournies à titre indicatif. Nous vous recommandons d'ajuster ces valeurs en fonction de votre cas d'utilisation.
****
| taille du courtier | num.replica.fetchers |
| --- | --- |
| kafka.m5.4xlarge | 4 |
| kafka.m5.8xlarge | 8 |
| kafka.m5.12xlarge | 14 |
| kafka.m5.16xlarge | 16 |
| kafka.m5.24xlarge | 16 |
Votre configuration mise à jour peut ne pas prendre effet avant 24 heures et peut prendre plus de temps lorsqu'un volume source n'est pas entièrement utilisé. Toutefois, les performances des volumes de transition sont au moins égales aux performances des volumes de stockage source pendant la période de migration. Un volume de 1 Tio entièrement utilisé prend généralement environ six heures pour migrer vers une configuration mise à jour.
# Provisionner le débit de stockage pour les courtiers standard dans un cluster Amazon MSK
Les agents Amazon MSK conservent les données relatives sur des volumes de stockage. I/O Le stockage est consommé lorsque les producteurs écrivent dans le cluster, lorsque les données sont répliquées entre courtiers et lorsque les consommateurs lisent des données qui ne sont pas en mémoire. Le débit de stockage en volume est le taux auquel les données peuvent être écrites et lues sur un volume de stockage. Le débit de stockage provisionné est la capacité de spécifier ce taux pour les agents de votre cluster.
Vous pouvez spécifier le débit provisionné en Mio par seconde pour les clusters dont les courtiers sont de taille supérieure ou égale à 10 GiB et si le volume de stockage est supérieur `kafka.m5.4xlarge` ou égal à 10 GiB. Il est possible de spécifier le débit provisionné lors de la création du cluster. Vous pouvez également activer ou désactiver le débit provisionné pour un cluster qui est dans l'état `ACTIVE`.
Pour plus d'informations sur la gestion du débit, consultez[Gérez le débit de stockage pour les courtiers standard dans un cluster Amazon MSK](msk-provision-throughput-management.md).
**Topics**
+ [Provisionnez le débit de stockage du cluster Amazon MSK à l'aide du AWS Management Console](#provisioned-throughput-console)
+ [Provisionnez le débit de stockage du cluster Amazon MSK à l'aide du AWS CLI](#provisioned-throughput-cli)
+ [Provisionner le débit de stockage lors de la création d'un cluster Amazon MSK à l'aide de l'API](#provisioned-throughput-api)
## Provisionnez le débit de stockage du cluster Amazon MSK à l'aide du AWS Management Console
Ce processus montre un exemple de la façon dont vous pouvez utiliser le AWS Management Console pour créer un cluster Amazon MSK avec le débit provisionné activé.
1. Connectez-vous à la AWS Management Console console Amazon MSK et ouvrez-la [https://console.aws.amazon.com/msk/chez vous ? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Choisissez **Créer un cluster**.
1. Choisissez **Création personnalisée**.
1. Attribuez un nom au cluster.
1. Dans la section **Stockage**, sélectionnez **Activer**.
1. Choisissez une valeur pour le débit de stockage par agent.
1. Choisissez un VPC, des zones, des sous-réseaux, ainsi qu'un groupe de sécurité.
1. Choisissez **Suivant**.
1. Au bas de l'étape **Sécurité**, choisissez **Suivant**.
1. Au bas de l'étape **Surveillance et identifications**, choisissez **Suivant**.
1. Vérifiez les paramètres du cluster, puis choisissez **Créer un cluster**.
## Provisionnez le débit de stockage du cluster Amazon MSK à l'aide du AWS CLI
Ce processus montre un exemple de la façon dont vous pouvez utiliser le AWS CLI pour créer un cluster avec le débit provisionné activé.
1. Copiez le code JSON suivant dans un fichier et collez-le dans un fichier. Remplacez les espaces réservés aux identifiants de sous-réseau IDs et de groupe de sécurité par les valeurs de votre compte. Nommez le fichier `cluster-creation.json` et enregistrez-le.
```
{
"Provisioned": {
"BrokerNodeGroupInfo":{
"InstanceType":"kafka.m5.4xlarge",
"ClientSubnets":[
"Subnet-1-ID",
"Subnet-2-ID"
],
"SecurityGroups":[
"Security-Group-ID"
],
"StorageInfo": {
"EbsStorageInfo": {
"VolumeSize": 10,
"ProvisionedThroughput": {
"Enabled": true,
"VolumeThroughput": 250
}
}
}
},
"EncryptionInfo": {
"EncryptionInTransit": {
"InCluster": false,
"ClientBroker": "PLAINTEXT"
}
},
"KafkaVersion":"2.8.1",
"NumberOfBrokerNodes": 2
},
"ClusterName": "provisioned-throughput-example"
}
```
1. Exécutez la AWS CLI commande suivante depuis le répertoire dans lequel vous avez enregistré le fichier JSON à l'étape précédente.
```
aws kafka create-cluster-v2 --cli-input-json file://cluster-creation.json
```
## Provisionner le débit de stockage lors de la création d'un cluster Amazon MSK à l'aide de l'API
[Pour configurer le débit de stockage provisionné lors de la création d'un cluster, utilisez CreateCluster la version V2.](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2)
# Configuration provisionnée d'Amazon MSK
Amazon MSK fournit des configurations par défaut pour les courtiers, les rubriques et les nœuds de métadonnées. Vous pouvez également créer des configurations personnalisées et les utiliser pour créer de nouveaux clusters MSK ou pour mettre à jour des clusters existants. Une configuration MSK consiste en un ensemble de propriétés et leurs valeurs correspondantes. Selon le type de courtier que vous utilisez dans votre cluster, il existe différents ensembles de paramètres de configuration par défaut et différents ensembles de configurations que vous pouvez modifier. Consultez les sections ci-dessous pour plus de détails sur la configuration de vos courtiers Standard et Express.
**Topics**
+ [Configurations de courtier standard](msk-configuration-standard.md)
+ [Configurations Express Broker](msk-configuration-express.md)
+ [Opérations de configuration du broker](msk-configuration-operations.md)
# Configurations de courtier standard
Cette section décrit les propriétés de configuration des courtiers standard.
**Topics**
+ [Configurations Amazon MSK personnalisées](msk-configuration-properties.md)
+ [Configuration par défaut d'Amazon MSK](msk-default-configuration.md)
+ [Directives relatives à la configuration du stockage hiérarchisé Amazon MSK au niveau des sujets](msk-guidelines-tiered-storage-topic-level-config.md)
# Configurations Amazon MSK personnalisées
Vous pouvez utiliser Amazon MSK pour créer une configuration MSK personnalisée dans laquelle vous définissez les propriétés de configuration Apache Kafka suivantes. Les propriétés que vous ne définissez pas obtiennent explicitement les valeurs qu'elles ont dans [Configuration par défaut d'Amazon MSK](msk-default-configuration.md). Pour de plus amples informations sur les propriétés de configuration, veuillez consulter [Configuration d'Apache Kafka](https://kafka.apache.org/documentation/#configuration).
| Nom | Description |
| --- | --- |
| allow.everyone.if.no.acl.found | Si vous souhaitez définir cette propriété surfalse, assurez-vous d'abord de définir Apache Kafka ACLs pour votre cluster. Si vous attribuez à cette propriété false la valeur sans définir Apache Kafka au préalable ACLs, vous perdez l'accès au cluster. Dans ce cas, vous pouvez à nouveau mettre à jour la configuration et définir cette propriété sur true pour accéder de nouveau au cluster. |
| auto.create.topics.enable | Active la création automatique de rubriques sur le serveur. |
| compression.type | Type de compression final pour une rubrique donnée. Vous pouvez définir cette propriété sur les codecs de compression standard (gzip, snappy, lz4 et zstd). Il accepte en outre uncompressed. Cette valeur équivaut à l'absence de compression. Si vous définissez la valeur sur producer, cela implique de retenir le codec de compression d'origine défini par le producteur. |
| connections.max.idle.ms | Délai d'expiration des connexions inactives en millisecondes. Les threads du processeur de socket de serveur ferment les connexions inactives pendant une durée supérieure à la valeur que vous avez définie pour cette propriété. |
| default.replication.factor | Facteur de réplication par défaut pour les rubriques créées automatiquement. |
| delete.topic.enable | Active l'opération de suppression de rubrique. Si vous désactivez cette configuration, vous ne pouvez pas supprimer une rubrique via l'outil d'administration. |
| group.initial.rebalance.delay.ms | Temps pendant lequel le coordinateur du groupe attend que davantage de consommateurs de données rejoignent un nouveau groupe avant d'effectuer le premier rééquilibrage. Un délai plus long signifie potentiellement moins de rééquilibrages, mais augmente le temps jusqu'au début du traitement. |
| group.max.session.timeout.ms | Délai maximal de session pour les consommateurs enregistrés. Les délais d'expiration plus longs donnent aux consommateurs plus de temps pour traiter les messages entre les battements de cœur, au prix d'un délai plus long pour détecter les défaillances. |
| group.min.session.timeout.ms | Délai d'expiration minimum de session pour les consommateurs enregistrés. Des délais d'expiration plus courts entraînent une détection plus rapide des défaillances, au prix des battements de cœur plus fréquents des consommateurs. Cela peut surcharger les ressources des agents. |
| leader.imbalance.per.broker.pourcentage | Ratio de déséquilibre de leader autorisé par courtier. Le contrôleur déclenche un équilibrage de leader s'il dépasse cette valeur par agent. Cette valeur est spécifiée en pourcentage. |
| log.cleaner.delete.retention.ms | Durée pendant laquelle vous souhaitez qu'Apache Kafka conserve les enregistrements supprimés. La valeur minimale est 0. |
| log.cleaner.min.cleanable.ratio | Cette propriété de configuration peut avoir des valeurs comprises entre 0 et 1. Cette valeur détermine la fréquence à laquelle le compacteur de journal tente de nettoyer le journal (si le compactage du journal est activé). Par défaut, Apache Kafka évite de nettoyer un journal si plus de 50 % du journal a été compacté. Ce ratio limite l'espace maximal que le journal gaspille avec des doublons (à 50 %, cela signifie que le journal peut contenir tout au plus 50 % de doublons). Un ratio plus élevé signifie moins de nettoyages, plus efficaces, mais aussi plus d'espace perdu dans le journal. |
| log.cleanup.policy | Stratégie de nettoyage par défaut pour les segments au-delà de la fenêtre de rétention. Liste de stratégies valides séparées par des virgules. Les stratégies valides sont delete et compact. Pour les clusters compatibles avec le stockage hiérarchisé, la politique valide est delete uniquement. |
| log.flush.interval.messages | Nombre de messages accumulés sur une partition de journal avant que les messages ne soient vidés sur le disque. |
| log.flush.interval.ms | Durée maximale en millisecondes pendant laquelle un message dans une rubrique est conservé en mémoire avant d'être vidé sur le disque. Si vous ne définissez pas cette valeur, la valeur de log.flush.scheduler.interval.ms est utilisée. La valeur minimale est 0. |
| log.message.timestamp.difference.max.ms | Cette configuration est obsolète dans Kafka 3.6.0. Deux configurations, log.message.timestamp.before.max.ms etlog.message.timestamp.after.max.ms, ont été ajoutées. Différence de temps maximale autorisée entre l'horodatage lorsqu'un agent reçoit un message et l'horodatage spécifié dans le message. Si log.message.timestamp.type=CreateTime, un message est rejeté si la différence d'horodatage dépasse ce seuil. Cette configuration est ignorée si LogAppendTime log.message.timestamp.type=. |
| log.message.timestamp.type | Spécifie si l'horodatage du message est l'heure de création du message ou l'heure d'ajout du journal. Les valeurs autorisées sont CreateTime et LogAppendTime. |
| log.retention.bytes | Taille maximale du journal avant de le supprimer. |
| log.retention.hours | Nombre d'heures pour conserver un fichier journal avant de le supprimer, tertiaire à la propriété log.retention.ms. |
| log.retention.minutes | Nombre de minutes de conservation d'un fichier journal avant de le supprimer, secondaire à la propriété log.retention.ms. Si vous ne définissez pas cette valeur, la valeur de log.retention.hours est utilisée. |
| log.retention.ms | Nombre de millisecondes pour conserver un fichier journal avant de le supprimer (en millisecondes), si ce n'est pas défini, la valeur dans log.retention.minutes est utilisée. |
| log.roll.ms | Durée maximale avant le déploiement d'un nouveau segment de journal (en millisecondes). Si vous ne définissez pas cette valeur, la valeur de log.roll.hours est utilisée. La valeur minimale possible pour cette propriété est 1. |
| log.segment.bytes | Taille maximale d'un seul fichier journal. |
| max.incremental.fetch.session.cache.slots | Nombre maximal de sessions d'extraction incrémentielle qui sont maintenues. |
| message.max.octets | La plus grande taille de lot d'enregistrement autorisée par Kafka. Si vous augmentez la valeur et qu'il y a des consommateurs plus anciens que 0.10.2, vous devez aussi augmenter la taille d'extraction des consommateurs afin qu'ils puissent récupérer des lots d'enregistrements aussi volumineux. La dernière version de format de message regroupe toujours les massages en lots pour plus d'efficacité. Les versions de format de message précédentes ne regroupent pas les enregistrements non compressés en lots et dans ce cas, cette limite ne s'applique qu'à un seul enregistrement. Vous pouvez définir cette valeur par rubrique avec le niveau de rubrique max.message.bytes config. |
| min.insync.replicas | Lorsqu'un producteur définit acks sur `"all"` (ou `"-1"`), la valeur de min.insync.replicas spécifie le nombre minimum de réplicas qui doivent reconnaître une écriture pour que celle-ci soit considérée comme réussie. Si ce minimum ne peut être atteint, le producteur émet une exception ( NotEnoughReplicas ou NotEnoughReplicasAfterAppend). Vous pouvez utiliser des valeurs dans min.insync.replicas et acks pour appliquer de meilleures garanties de durabilité. Par exemple, vous pouvez créer une rubrique avec un facteur de réplication de 3, définir min.insync.replicas sur 2 et produire avec des acks de `"all"`. Cela garantit que le producteur déclenche une exception si la majorité des réplicas ne reçoivent pas d'écriture. |
| num.io.threads | Nombre de threads utilisés par le serveur pour le traitement des demandes, qui peuvent inclure des E/S de disque. |
| num.network.threads | Nombre de threads que le serveur utilise pour recevoir des demandes du réseau et lui envoyer des réponses. |
| num.partitions | Nombre par défaut de partitions de journal par rubrique. |
| num.recovery.threads.per.data.dir | Nombre de threads par répertoire de données à utiliser pour récupérer des journaux au démarrage et pour leur vidage lors de l'arrêt. |
| num.replica.fetchers | Nombre de threads de récupération utilisés pour répliquer les messages d'un broker source. Si vous augmentez cette valeur, vous pouvez augmenter le degré de I/O parallélisme dans le broker suiveur. |
| offsets.retention.minutes | Lorsqu'un groupe de consommateurs perd tous ses consommateurs (c'est-à-dire qu'il devient vide), ses compensations sont conservées pour cette période de rétention avant d'être jetées. Pour les consommateurs autonomes (c'est-à-dire ceux qui utilisent l'affectation manuelle), les décalages expirent après l'heure de la dernière validation plus cette période de conservation. |
| offsets.topic.replication.factor | Facteur de réplication de la rubrique des décalages. Définissez cette valeur à un niveau supérieur pour garantir la disponibilité. La création de rubrique interne échoue jusqu'à ce que la taille du cluster réponde à cette exigence de facteur de réplication. |
| réplica.fetch.max.bytes | Nombre d'octets de messages à essayer de récupérer pour chaque partition. Ce n'est pas un maximum absolu. Si le premier lot d'enregistrements de la première partition non vide de l'extraction est supérieur à cette valeur, le lot d'enregistrements est renvoyé pour assurer la progression. Les message.max.bytes (broker config) ou max.message.bytes (topic config) définissent la taille maximale du lot d'enregistrements que l'agent accepte. |
| replica.fetch.response.max.bytes | Nombre maximal d'octets attendu pour l'ensemble de la réponse de récupération. Les enregistrements sont récupérés par lots, et si le premier lot d'enregistrements de la première partition non vide de l'extraction est supérieur à cette valeur, le lot d'enregistrements sera toujours renvoyé pour assurer la progression. Ce n'est pas un maximum absolu. Les propriétés message.max.bytes (broker config) ou max.message.bytes (topic config) spécifient la taille maximale du lot d'enregistrements que le broker accepte. |
| replica.lag.time.max.ms | Si un suiveur n'a envoyé aucune demande d'extraction ou n'a pas consommé le décalage de fin existant avec le journal du leader pendant au moins ce nombre de millisecondes, le leader supprime le suiveur de l'ISR.MinValue: 10000MaxValue = 30000 |
| replica.selector.class | Le nom de classe complet qui implémente ReplicaSelector. L'agent utilise cette valeur pour trouver le réplica en lecture préféré. Si vous utilisez Apache Kafka, version 2.4.1 ou supérieure, et que vous souhaitez permettre aux consommateurs de récupérer le réplica le plus proche, définissez cette propriété sur org.apache.kafka.common.replica.RackAwareReplicaSelector. Pour de plus amples informations, veuillez consulter [Apache Kafka version 2.4.1 (utilisez plutôt 2.4.1.1)](supported-kafka-versions.md#2.4.1). |
| replica.socket.receive.buffer.bytes | Tampon de réception du socket pour les demandes réseau. |
| socket.receive.buffer.bytes | Tampon SO\$1RCVBUF des sockets de serveur de socket. La valeur minimale que vous pouvez définir pour cette propriété est -1. Si la valeur est -1, Amazon MSK utilise le système d'exploitation par défaut. |
| socket.request.max.octets | Nombre maximal d'octets dans une requête socket. |
| socket.send.buffer.bytes | Tampon SO\$1SNDBUF des sockets de serveur de socket. La valeur minimale que vous pouvez définir pour cette propriété est -1. Si la valeur est -1, Amazon MSK utilise le système d'exploitation par défaut. |
| transaction.max.timeout.ms | Délai maximal pour les transactions. Si le temps de transaction demandé à un client dépasse cette valeur, le courtier renvoie une erreur InitProducerIdRequest. Cela évite au client un délai d'expiration trop important et cela peut empêcher les consommateurs de lire des rubriques incluses dans la transaction. |
| transaction.state.log.min.isr | Configuration min.insync.replicas remplacée pour la rubrique de la transaction. |
| transaction.state.log.replication.factor | Facteur de réplication de la rubrique de la transaction. Configurez cette propriété sur une valeur plus élevée pour augmenter la disponibilité. La création de rubrique interne échoue jusqu'à ce que la taille du cluster réponde à cette exigence de facteur de réplication. |
| transactional.id.expiration.ms | Durée en millisecondes pendant laquelle le coordinateur de transactions attend de recevoir les mises à jour du statut de la transaction en cours avant que l'ID transactionnel du coordinateur n'expire. Ce paramètre influence également l'expiration de l'identifiant du producteur, car il entraîne l' IDsexpiration du producteur lorsque ce délai s'écoule après la dernière écriture avec l'identifiant de producteur donné. Le producteur IDs peut expirer plus tôt si la dernière écriture provenant de l'identifiant du producteur est supprimée en raison des paramètres de conservation du sujet. La valeur minimale pour cette propriété est 1 milliseconde. |
| unclean.leader.election.enable | Indique si les réplicas ne figurant pas dans l'ensemble ISR doivent servir de leader en dernier recours, même si cela peut entraîner une perte de données. |
| zookeeper.connection.timeout.ms | ZooKeeper clusters de modes. Durée maximale pendant laquelle le client attend avant d'établir une connexion. ZooKeeper Si vous ne définissez pas cette valeur, la valeur de zookeeper.session.timeout.ms est utilisée. MinValue = 6000 MaxValue (inclus) = 18000 Nous vous recommandons de définir cette valeur sur 10 000 sur T3.small pour éviter les interruptions de service du cluster. |
| zookeeper.session.timeout.ms | ZooKeeper clusters de modes. Le délai d'expiration de ZooKeeper la session Apache en millisecondes. MinValue = 6000 MaxValue (inclus) = 18000 |
Pour savoir comment créer une configuration MSK personnalisée, dresser une liste de toutes les configurations ou les décrire, veuillez consulter [Opérations de configuration du broker](msk-configuration-operations.md). Pour créer un cluster MSK à l'aide d'une configuration MSK personnalisée ou pour mettre à jour un cluster avec une nouvelle configuration personnalisée, consultez [Caractéristiques et concepts clés d'Amazon MSK](operations.md).
Lorsque vous mettez à jour votre cluster MSK existant avec une configuration MSK personnalisée, Amazon MSK redémarre la propagation lorsque nécessaire et utilise les bonnes pratiques pour limiter les temps d'arrêt du client. Par exemple, après qu'Amazon MSK a redémarré chaque agent, il essaie de laisser l'agent rattraper les données que l'agent a pu manquer lors de la mise à jour de la configuration avant de passer à l'agent suivant.
## Configuration dynamique d'Amazon MSK
Outre les propriétés de configuration fournies par Amazon MSK, vous pouvez définir dynamiquement les propriétés de configuration au niveau du cluster et de l'agent qui ne nécessitent pas de redémarrage de l'agent. Vous pouvez définir certaines propriétés de configuration de manière dynamique. Il s'agit des propriétés qui ne sont pas marquées en lecture seule dans la table sous [Configurations de l'agent](https://kafka.apache.org/documentation/#brokerconfigs) dans la documentation Apache Kafka. Pour de plus amples informations sur la configuration dynamique et les exemples de commandes, consultez [Mise à jour des configurations de l'agent](https://kafka.apache.org/documentation/#dynamicbrokerconfigs) dans la documentation Apache Kafka.
**Note**
Vous pouvez définir la propriété `advertised.listeners`, mais pas la propriété `listeners`.
## Configuration Amazon MSK au niveau du sujet
Vous pouvez utiliser les commandes Apache Kafka pour définir ou modifier les propriétés de configuration au niveau des rubriques nouvelles et existantes. Pour de plus amples informations sur les propriétés de configuration au niveau de la rubrique et pour obtenir des exemples de définition, consultez [Configurations au niveau de la rubrique](https://kafka.apache.org/documentation/#topicconfigs) dans la documentation Apache Kafka.
# Configuration par défaut d'Amazon MSK
Lorsque vous créez un cluster MSK et que vous ne spécifiez pas de configuration MSK personnalisée, Amazon MSK crée et utilise une configuration par défaut avec les valeurs indiquées dans le tableau suivant. Pour les propriétés qui ne figurent pas dans cette table, Amazon MSK utilise les valeurs par défaut associées à votre version d'Apache Kafka. Pour obtenir la liste de ces valeurs par défaut, consultez [Apache Kafka Configuration](https://kafka.apache.org/documentation/#configuration).
| Nom | Description | Valeur par défaut d'un cluster de stockage non hiérarchisé | Valeur par défaut d'un cluster de stockage hiérarchisé |
| --- | --- | --- | --- |
| allow.everyone.if.no.acl.found | Si aucun modèle de ressource ne correspond à une ressource spécifique, celle-ci n'est associée à aucune ressource ACLs. Dans ce cas, si vous définissez cette propriété sur true, tous les utilisateurs peuvent accéder à la ressource, et pas seulement les super utilisateurs. | true | true |
| auto.create.topics.enable | Active la création automatique d'une rubrique sur le serveur. | false | false |
| auto.leader.rebalance.enable | Active l'équilibrage automatique du leader. Un thread d'arrière-plan vérifie et lance un équilibrage de leader si nécessaire à intervalles réguliers. | true | true |
| default.replication.factor | Facteurs de réplication par défaut pour les rubriques créées automatiquement. | 3 pour les clusters situés dans 3 zones de disponibilité et 2 pour les clusters situés dans 2 zones de disponibilité. | 3 pour les clusters situés dans 3 zones de disponibilité et 2 pour les clusters situés dans 2 zones de disponibilité. |
| local.retention.bytes | Taille maximale des segments de journal locaux pour une partition avant la suppression des anciens segments. Si vous ne définissez pas cette valeur, la valeur de log.retention.bytes est utilisée. La valeur effective doit toujours être inférieure ou égale à la valeur de log.retention.bytes. Une valeur par défaut de -2 signifie qu'aucune limite n'est appliquée à la conservation locale. Cela correspond au paramètre retention.ms/bytes de -1. Les propriétés local.retention.ms et local.retention.bytes sont similaires à log.retention, car elles sont utilisées pour déterminer la durée pendant laquelle les segments de journal doivent être conservés dans le stockage local. Les configurations log.retention.\$1 existantes sont des configurations de conservation pour la partition de la rubrique. Cela inclut le stockage local et distant. Valeurs valides : nombres entiers compris entre [-2 ; \$1Inf] | -2 pour un nombre illimité | -2 pour un nombre illimité |
| local.retention.ms | Nombre de millisecondes pour retenir le segment de journal local avant sa suppression. Si vous ne définissez pas cette valeur, Amazon MSK utilise la valeur de log.retention.ms. La valeur effective doit toujours être inférieure ou égale à la valeur de log.retention.bytes. Une valeur par défaut de -2 signifie qu'aucune limite n'est appliquée à la conservation locale. Cela correspond au paramètre retention.ms/bytes de -1.Les valeurs local.retention.ms et local.retention.bytes sont similaires à celles de log.retention. MSK utilise cette configuration pour déterminer la durée pendant laquelle les segments de journal doivent être conservés dans le stockage local. Les configurations log.retention.\$1 existantes sont des configurations de conservation pour la partition de la rubrique. Cela inclut le stockage local et distant. Les valeurs valides sont des nombres entiers supérieurs à 0. | -2 pour un nombre illimité | -2 pour un nombre illimité |
| log.message.timestamp.difference.max.ms | Cette configuration est obsolète dans Kafka 3.6.0. Deux configurations, log.message.timestamp.before.max.ms etlog.message.timestamp.after.max.ms, ont été ajoutées. Différence maximale autorisée entre l'horodatage lorsqu'un broker reçoit un message et l'horodatage spécifié dans le message. Si log.message.timestamp.type=CreateTime, un message sera rejeté si la différence d'horodatage dépasse ce seuil. Cette configuration est ignorée si LogAppendTime log.message.timestamp.type=. La différence d'horodatage maximale autorisée ne doit pas être supérieure à log.retention.ms afin d'éviter la propagation de journaux inutilement fréquente. | 9223372036854775807 | 86400000 pour Kafka 2.8.2.tiered et Kafka 3.7.x hiérarchisé. |
| log.segment.bytes | Taille maximale d'un seul fichier journal. | 1073741824 | 134217728 |
| min.insync.replicas | Lorsqu'un producteur définit la valeur de acks (accusé de réception reçu par le producteur de l'agent Kafka) sur `"all"` (ou `"-1"`), la valeur de min.insync.replicas spécifie le nombre minimum de réplicas qui doivent reconnaître une écriture pour que celle-ci soit considérée comme réussie. Si cette valeur n'atteint pas ce minimum, le producteur déclenche une exception ( NotEnoughReplicas ou NotEnoughReplicasAfterAppend). Lorsque vous utilisez les valeurs de min.insync.replicas et acks ensemble, vous pouvez appliquer de meilleures garanties de durabilité. Par exemple, vous pouvez créer une rubrique avec un facteur de réplication de 3, définir min.insync.replicas sur 2 et produire avec des acks de `"all"`. Cela garantit que le producteur déclenche une exception si la majorité des réplicas ne reçoivent pas d'écriture. | 2 pour les clusters situés dans 3 zones de disponibilité et 1 pour les clusters situés dans 2 zones de disponibilité. | 2 pour les clusters situés dans 3 zones de disponibilité et 1 pour les clusters situés dans 2 zones de disponibilité. |
| num.io.threads | Nombre de threads utilisés par le serveur pour produire des demandes, qui peuvent inclure des E/S de disque. | 8 | max (8, vCPUs) où v CPUs dépend de la taille de l'instance du broker |
| num.network.threads | Nombre de threads utilisés par le serveur pour recevoir les demandes du réseau et envoyer des réponses au réseau. | 5 | max (5, vCPUs /2) où v CPUs dépend de la taille de l'instance du broker |
| num.partitions | Nombre par défaut de partitions de journal par rubrique. | 1 | 1 |
| num.replica.fetchers | Nombre de threads de récupération utilisés pour répliquer les messages provenant d'un courtier source. Si vous augmentez cette valeur, vous pouvez augmenter le degré de I/O parallélisme dans le courtier suiveur. | 2 | max (2, vCPUs /4) où v CPUs dépend de la taille de l'instance du broker |
| remote.log.msk.disable.policy | Utilisé avec remote.storage.enable pour désactiver le stockage hiérarchisé. Définissez cette politique sur Supprimer, pour indiquer que les données du stockage hiérarchisé sont supprimées lorsque vous définissez remote.storage.enable sur false. | N/A | Aucune |
| remote.log.reader.threads | Taille du pool de threads du lecteur de journaux distant, qui est utilisée pour planifier des tâches visant à récupérer des données à partir d'un stockage distant. | N/A | max (10, v CPUs \$1 0,67) où v CPUs dépend de la taille de l'instance du broker |
| remote.storage.enable | Active le stockage (distant) hiérarchisé pour une rubrique s'il est défini sur true. Désactive le stockage hiérarchisé au niveau de la rubrique s'il est défini sur false et remote.log.msk.disable.policy est défini sur Supprimer. Lorsque vous désactivez le stockage hiérarchisé, vous supprimez les données du stockage distant. Lorsque vous désactivez le stockage hiérarchisé pour une rubrique, vous ne pouvez pas le réactiver. | false | false |
| replica.lag.time.max.ms | Si un suiveur n'a envoyé aucune demande d'extraction ou n'a pas consommé le décalage de fin existant avec le journal du leader pendant au moins ce nombre de millisecondes, le leader supprime le suiveur de l'ISR. | 30 000 | 30 000 |
| retention.ms | Champ obligatoire. La durée minimale est de 3 jours. Le paramètre étant obligatoire, il n'y a pas de valeur par défaut. Amazon MSK utilise la valeur retention.ms avec local.retention.ms pour déterminer à quel moment les données sont transférées du stockage local vers le stockage hiérarchisé. La valeur local.retention.ms indique quand déplacer les données du stockage local vers le stockage hiérarchisé. La valeur retention.ms indique à quel moment les données doivent être supprimées du stockage hiérarchisé (c'est-à-dire lorsqu'elles sont supprimées du cluster). Valeurs valides : nombres entiers compris entre [-1 ; \$1Inf] | Minimum 259 200 000 millisecondes (3 jours). -1 pour une conservation illimitée. | Minimum 259 200 000 millisecondes (3 jours). -1 pour une conservation illimitée. |
| socket.receive.buffer.bytes | Tampon SO\$1RCVBUF tampon des sockets de serveur de socket. Si la valeur est -1, le système d'exploitation par défaut est utilisé. | 102400 | 102400 |
| socket.request.max.octets | Nombre maximal d'octets dans une requête socket. | 104857600 | 104857600 |
| socket.send.buffer.bytes | Tampon SO\$1SNDBUF des sockets de serveur de socket. Si la valeur est -1, le système d'exploitation par défaut est utilisé. | 102400 | 102400 |
| unclean.leader.election.enable | Indique si vous souhaiter que les réplicas ne figurant pas dans l'ensemble ISR servent de leader en dernier recours, même si cela peut entraîner une perte de données. | vrai | false |
| zookeeper.session.timeout.ms | Le délai d'expiration de ZooKeeper la session Apache en millisecondes. | 18000 | 18000 |
| zookeeper.set.acl | Le client configuré pour utiliser Secure ACLs. | false | false |
Pour plus d'informations sur la manière de spécifier des valeurs de configuration personnalisées, consultez[Configurations Amazon MSK personnalisées](msk-configuration-properties.md).
# Directives relatives à la configuration du stockage hiérarchisé Amazon MSK au niveau des sujets
Vous trouverez ci-dessous les paramètres et les limites par défaut lorsque vous configurez le stockage hiérarchisé au niveau de la rubrique.
+ Amazon MSK ne prend pas en charge les segments de journal de plus petite taille pour les rubriques pour lesquelles le stockage hiérarchisé est activé. Si vous souhaitez créer un segment, la taille minimale du segment de journal est de 48 Mio, ou le temps d'exécution des segments est d'au moins 10 minutes. Ces valeurs correspondent aux propriétés segment.bytes et segment.ms.
+ La valeur de local.retention. ms/bytes can't equal or exceed the retention.ms/bytes. Il s'agit du paramètre de conservation du stockage hiérarchisé.
+ La valeur par défaut pour for local.retention. ms/bytes is -2. This means that the retention.ms value is used for local.retention.ms/bytes. Dans ce cas, les données restent à la fois dans le stockage local et dans le stockage hiérarchisé (une copie dans chaque cas), et elles expirent en même temps. Pour cette option, une copie des données locales est conservée sur le stockage distant. Dans ce cas, les données lues à partir du trafic de consommation proviennent du stockage local.
+ La valeur par défaut de retention.ms est de 7 jours. Il n'existe aucune limite de taille par défaut pour retention.bytes.
+ La valeur minimale de retention.ms/bytes est -1. Cela signifie une conservation infinie.
+ La valeur minimale pour local.retention. ms/bytes is -2. This means infinite retention for local storage. It matches with the retention.ms/bytesréglage sur -1.
+ Le fichier de configuration au niveau thématique retention.ms est obligatoire pour les sujets pour lesquels le stockage hiérarchisé est activé. La valeur minimale de retention.ms est de 3 jours.
Pour plus d'informations sur les contraintes de stockage hiérarchisé, consultez[Contraintes et limites du stockage hiérarchisé pour les clusters Amazon MSK](msk-tiered-storage.md#msk-tiered-storage-constraints).
# Configurations Express Broker
Apache Kafka propose des centaines de configurations de broker que vous pouvez utiliser pour optimiser les performances de votre cluster MSK Provisioned. La définition de valeurs erronées ou sous-optimales peut affecter la fiabilité et les performances du cluster. Les courtiers Express améliorent la disponibilité et la durabilité de vos clusters provisionnés par MSK en définissant des valeurs optimales pour les configurations critiques et en les protégeant contre les erreurs de configuration courantes. Il existe trois catégories de configurations basées sur l'accès en lecture et en écriture : les configurations en [lecture/écriture (modifiables)](msk-configuration-express-read-write.md), en [lecture seule](msk-configuration-express-read-only.md) et les configurations sans lecture/écriture. Certaines configurations utilisent toujours la valeur par défaut d'Apache Kafka pour la version d'Apache Kafka exécutée par le cluster. Nous les marquons comme Apache Kafka par défaut.
**Topics**
+ [Configurations de broker MSK Express personnalisées (accès en lecture/écriture)](msk-configuration-express-read-write.md)
+ [Configurations en lecture seule d'Express Brokers](msk-configuration-express-read-only.md)
# Configurations de broker MSK Express personnalisées (accès en lecture/écriture)
Vous pouvez mettre à jour les configurations des read/write courtiers en utilisant la [fonctionnalité de mise à jour de configuration](msk-update-cluster-config.md) d'Amazon MSK ou en utilisant l'API d'Apache Kafka. AlterConfig Les configurations du broker Apache Kafka sont statiques ou dynamiques. Les configurations statiques nécessitent un redémarrage du courtier pour que la configuration soit appliquée, tandis que les configurations dynamiques n'ont pas besoin d'un redémarrage du courtier. Pour plus d'informations sur les propriétés de configuration et les modes de mise à jour, consultez la section [Mise à jour des configurations des courtiers](https://kafka.apache.org/documentation/#dynamicbrokerconfigs).
**Topics**
+ [Configurations statiques sur les courtiers MSK Express](#msk-configuration-express-static-configuration)
+ [Configurations dynamiques sur Express Brokers](#msk-configuration-express-dynamic-configuration)
+ [Configurations thématiques sur Express Brokers](#msk-configuration-express-topic-configuration)
## Configurations statiques sur les courtiers MSK Express
Vous pouvez utiliser Amazon MSK pour créer un fichier de configuration MSK personnalisé afin de définir les propriétés statiques suivantes. Amazon MSK définit et gère toutes les autres propriétés que vous ne définissez pas. Vous pouvez créer et mettre à jour des fichiers de configuration statiques à partir de la console MSK ou à l'aide de la [commande configurations](msk-configuration-operations-create.md).
| Propriété | Description | Valeur par défaut |
| --- | --- | --- |
| allow.everyone.if.no.acl.found | Si vous souhaitez définir cette propriété sur false, assurez-vous d'abord de définir Apache Kafka ACLs pour votre cluster. Si vous définissez cette propriété sur false et que vous ne définissez pas d'abord Apache Kafka ACLs, vous perdez l'accès au cluster. Dans ce cas, vous pouvez à nouveau mettre à jour la configuration et attribuer à cette propriété la valeur true pour retrouver l'accès au cluster. | true |
| auto.create.topics.enable | Active la création automatique d'une rubrique sur le serveur. | false |
| compression.type | Spécifiez le type de compression final pour un sujet donné. Cette configuration accepte les codecs de compression standard : gzip, snappy, lz4, zstd. Cette configuration accepte également`uncompressed`, ce qui équivaut à l'absence de compression`producer`, et donc à conserver le codec de compression d'origine défini par le producteur. | Apache Kafka par défaut |
| connections.max.idle.ms | Délai d'expiration des connexions inactives en millisecondes. Les threads du processeur de socket de serveur ferment les connexions inactives pendant une durée supérieure à la valeur que vous avez définie pour cette propriété. | Apache Kafka par défaut |
| delete.topic.enable | Active l'opération de suppression de rubrique. Si vous désactivez cette configuration, vous ne pouvez pas supprimer une rubrique via l'outil d'administration. | Apache Kafka par défaut |
| group.initial.rebalance.delay.ms | Temps pendant lequel le coordinateur du groupe attend que davantage de consommateurs de données rejoignent un nouveau groupe avant d'effectuer le premier rééquilibrage. Un délai plus long signifie potentiellement moins de rééquilibrages, mais augmente le temps jusqu'au début du traitement. | Apache Kafka par défaut |
| group.max.session.timeout.ms | Délai maximal de session pour les consommateurs enregistrés. Les délais d'expiration plus longs donnent aux consommateurs plus de temps pour traiter les messages entre les battements de cœur, au prix d'un délai plus long pour détecter les défaillances. | Apache Kafka par défaut |
| leader.imbalance.per.broker.pourcentage | Ratio de déséquilibre de leader autorisé par courtier. Le contrôleur déclenche un équilibrage de leader s'il dépasse cette valeur par agent. Cette valeur est spécifiée en pourcentage. | Apache Kafka par défaut |
| log.cleanup.policy | Stratégie de nettoyage par défaut pour les segments au-delà de la fenêtre de rétention. Liste de stratégies valides séparées par des virgules. Les stratégies valides sont delete et compact. Pour les clusters compatibles avec le stockage hiérarchisé, la politique valide est uniquement valable. delete | Apache Kafka par défaut |
| log.message.timestamp.after.max.ms | Différence d'horodatage autorisée entre l'horodatage du message et l'horodatage du courtier. L'horodatage du message peut être supérieur ou égal à l'horodatage du courtier, la différence maximale autorisée étant déterminée par la valeur définie dans cette configuration. Si`log.message.timestamp.type=CreateTime`, le message sera rejeté si la différence d'horodatage dépasse ce seuil spécifié. Cette configuration est ignorée si`log.message.timestamp.type=LogAppendTime`. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, soit 1 jour) |
| log.message.timestamp.before.max.ms | Différence d'horodatage autorisée entre l'horodatage du courtier et l'horodatage du message. L'horodatage du message peut être antérieur ou égal à l'horodatage du courtier, la différence maximale autorisée étant déterminée par la valeur définie dans cette configuration. Si`log.message.timestamp.type=CreateTime`, le message sera rejeté si la différence d'horodatage dépasse ce seuil spécifié. Cette configuration est ignorée si`log.message.timestamp.type=LogAppendTime`. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, soit 1 jour) |
| log.message.timestamp.type | Spécifie si l'horodatage du message est l'heure de création du message ou l'heure d'ajout du journal. Les valeurs autorisées sont CreateTime et LogAppendTime. | Apache Kafka par défaut |
| log.retention.bytes | Taille maximale du journal avant de le supprimer. | Apache Kafka par défaut |
| log.retention.ms | Nombre de millisecondes nécessaires pour conserver un fichier journal avant de le supprimer. | Apache Kafka par défaut |
| max.connections.per .ip | Le nombre maximum de connexions autorisées à partir de chaque adresse IP. Cela peut être défini sur 0 si des remplacements sont configurés à l'aide de cette max.connections.per.ip.overrides propriété. Les nouvelles connexions à partir de l'adresse IP sont supprimées si la limite est atteinte. | Apache Kafka par défaut |
| max.incremental.fetch.session.cache.slots | Nombre maximal de sessions d'extraction incrémentielle qui sont maintenues. | Apache Kafka par défaut |
| message.max.octets | La plus grande taille de lot d'enregistrement autorisée par Kafka. Si vous augmentez la valeur et qu'il y a des consommateurs plus anciens que 0.10.2, vous devez aussi augmenter la taille d'extraction des consommateurs afin qu'ils puissent récupérer des lots d'enregistrements aussi volumineux. La dernière version de format de message regroupe toujours les massages en lots pour plus d'efficacité. Les versions de format de message précédentes ne regroupent pas les enregistrements non compressés en lots et dans ce cas, cette limite ne s'applique qu'à un seul enregistrement. Vous pouvez définir cette valeur par sujet à l'aide de la `max.message.bytes` configuration au niveau du sujet. | Apache Kafka par défaut |
| num.partitions | Nombre de partitions par défaut par sujet. | 1 |
| offsets.retention.minutes | Lorsqu'un groupe de consommateurs perd tous ses consommateurs (c'est-à-dire qu'il devient vide), ses compensations sont conservées pour cette période de rétention avant d'être jetées. Pour les consommateurs autonomes (c'est-à-dire ceux qui utilisent l'attribution manuelle), les offsets expirent après la date du dernier commit plus cette période de conservation. | Apache Kafka par défaut |
| réplica.fetch.max.bytes | Nombre d'octets de messages à essayer de récupérer pour chaque partition. Ce n'est pas un maximum absolu. Si le premier lot d'enregistrements de la première partition non vide de l'extraction est supérieur à cette valeur, le lot d'enregistrements est renvoyé pour assurer la progression. Les message.max.bytes (broker config) ou max.message.bytes (topic config) définissent la taille maximale du lot d'enregistrements que l'agent accepte. | Apache Kafka par défaut |
| replica.selector.class | Le nom de classe complet qui implémente ReplicaSelector. L'agent utilise cette valeur pour trouver le réplica en lecture préféré. Si vous souhaitez autoriser les consommateurs à récupérer des données depuis la réplique la plus proche, attribuez à `org.apache.kafka.common.replica.RackAwareReplicaSelector` cette propriété la valeur. | Apache Kafka par défaut |
| socket.receive.buffer.bytes | Tampon SO\$1RCVBUF tampon des sockets de serveur de socket. Si la valeur est -1, le système d'exploitation par défaut est utilisé. | 102400 |
| socket.request.max.octets | Nombre maximal d'octets dans une requête socket. | 104857600 |
| socket.send.buffer.bytes | Tampon SO\$1SNDBUF des sockets de serveur de socket. Si la valeur est -1, le système d'exploitation par défaut est utilisé. | 102400 |
| transaction.max.timeout.ms | Délai maximal pour les transactions. Si le temps de transaction demandé à un client dépasse cette valeur, le courtier renvoie une erreur InitProducerIdRequest. Cela évite au client un délai d'expiration trop important et cela peut empêcher les consommateurs de lire des rubriques incluses dans la transaction. | Apache Kafka par défaut |
| transactional.id.expiration.ms | Durée en millisecondes pendant laquelle le coordinateur de transactions attend de recevoir les mises à jour du statut de la transaction en cours avant que l'ID transactionnel du coordinateur n'expire. Ce paramètre influence également l'expiration de l'identifiant du producteur, car il entraîne IDs l'expiration du producteur lorsque ce délai s'écoule après la dernière écriture avec l'identifiant de producteur donné. Le producteur IDs peut expirer plus tôt si la dernière écriture provenant de l'identifiant du producteur est supprimée en raison des paramètres de conservation du sujet. La valeur minimale pour cette propriété est 1 milliseconde. | Apache Kafka par défaut |
## Configurations dynamiques sur Express Brokers
Vous pouvez utiliser l' AlterConfig API Apache Kafka ou l'outil Kafka-configs.sh pour modifier les configurations dynamiques suivantes. Amazon MSK définit et gère toutes les autres propriétés que vous ne définissez pas. Vous pouvez définir dynamiquement des propriétés de configuration au niveau du cluster et au niveau du courtier qui ne nécessitent pas le redémarrage du courtier.
| Propriété | Description | Valeur par défaut |
| --- | --- | --- |
| publicités.auditeurs | Écouteurs à publier pour que les clients puissent les utiliser, s'ils sont différents de la propriété de `listeners` configuration. Dans les environnements IaaS, cela peut devoir être différent de l'interface à laquelle le broker se lie. Si ce n'est pas le cas, la valeur pour les auditeurs sera utilisée. Contrairement aux écouteurs, il n'est pas valide de publier la méta-adresse 0.0.0.0. Contrairement à cela`listeners`, cette propriété peut comporter des ports dupliqués, de sorte qu'un écouteur peut être configuré pour publier l'adresse d'un autre écouteur. Cela peut être utile dans certains cas où des équilibreurs de charge externes sont utilisés. Cette propriété est définie au niveau de chaque courtier. | null |
| compression.type | Type de compression final pour une rubrique donnée. Vous pouvez définir cette propriété sur les codecs de compression standard (`gzip`, `snappy`, `lz4` et `zstd`). Il accepte en outre `uncompressed`. Cette valeur équivaut à l'absence de compression. Si vous définissez la valeur sur `producer`, cela implique de retenir le codec de compression d'origine défini par le producteur. | Apache Kafka par défaut |
| log.cleaner.delete.retention.ms | Durée de conservation des marqueurs de pierre tombale supprimés pour les sujets compactés dans les journaux. Ce paramètre définit également le temps pendant lequel un consommateur doit terminer une lecture s'il part du décalage 0 afin de s'assurer d'obtenir un instantané valide de l'étape finale. Sinon, les pierres tombales supprimées pourraient être collectées avant qu'elles ne terminent leur numérisation. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, soit 1 jour), Apache Kafka par défaut |
| log.cleaner.min.compaction.lag.ms | Durée minimale pendant laquelle un message restera non compacté dans le journal. Ce paramètre ne s'applique qu'aux journaux en cours de compactage. | 0, Apache Kafka par défaut |
| log.cleaner.max.compaction.lag.ms | Durée maximale pendant laquelle un message restera inéligible au compactage dans le journal. Ce paramètre ne s'applique qu'aux journaux en cours de compactage. Cette configuration serait limitée à [7 jours, Long.Max]. | 9223372036854775807, Apache Kafka par défaut |
| log.cleanup.policy | Stratégie de nettoyage par défaut pour les segments au-delà de la fenêtre de rétention. Liste de stratégies valides séparées par des virgules. Les stratégies valides sont `delete` et `compact`. Pour les clusters compatibles avec le stockage hiérarchisé, la politique valide est uniquement valable. `delete` | Apache Kafka par défaut |
| log.message.timestamp.after.max.ms | Différence d'horodatage autorisée entre l'horodatage du message et l'horodatage du courtier. L'horodatage du message peut être supérieur ou égal à l'horodatage du courtier, la différence maximale autorisée étant déterminée par la valeur définie dans cette configuration. Si`log.message.timestamp.type=CreateTime`, le message sera rejeté si la différence d'horodatage dépasse ce seuil spécifié. Cette configuration est ignorée si`log.message.timestamp.type=LogAppendTime`. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, soit 1 jour) |
| log.message.timestamp.before.max.ms | Différence d'horodatage autorisée entre l'horodatage du courtier et l'horodatage du message. L'horodatage du message peut être antérieur ou égal à l'horodatage du courtier, la différence maximale autorisée étant déterminée par la valeur définie dans cette configuration. Si`log.message.timestamp.type=CreateTime`, le message sera rejeté si la différence d'horodatage dépasse ce seuil spécifié. Cette configuration est ignorée si`log.message.timestamp.type=LogAppendTime`. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, soit 1 jour) |
| log.message.timestamp.type | Spécifie si l'horodatage du message est l'heure de création du message ou l'heure d'ajout du journal. Les valeurs autorisées sont `CreateTime` et `LogAppendTime`. | Apache Kafka par défaut |
| log.retention.bytes | Taille maximale du journal avant de le supprimer. | Apache Kafka par défaut |
| log.retention.ms | Nombre de millisecondes nécessaires pour conserver un fichier journal avant de le supprimer. | Apache Kafka par défaut |
| max.connection.creation.rate | Le taux de création de connexion maximal autorisé dans le broker à tout moment. | Apache Kafka par défaut |
| connexions max. | Le nombre maximum de connexions autorisées dans le broker à tout moment. Cette limite est appliquée en plus des limites par adresse IP configurées à l'aide `max.connections.per.ip` de. | Apache Kafka par défaut |
| max.connections.per .ip | Le nombre maximum de connexions autorisées à partir de chaque adresse IP. Cela peut être défini sur `0` si des remplacements sont configurés à l'aide de la propriété max.connections.per.ip.overrides. Les nouvelles connexions à partir de l'adresse IP sont supprimées si la limite est atteinte. | Apache Kafka par défaut |
| max.connections.per.ip.overrides | Une liste séparée par virgule d'adresses IP ou de noms d'hôte remplace le nombre maximal de connexions par défaut. Un exemple de valeur est `hostName:100,127.0.0.1:200` | Apache Kafka par défaut |
| message.max.octets | La plus grande taille de lot d'enregistrement autorisée par Kafka. Si vous augmentez la valeur et qu'il y a des consommateurs plus anciens que 0.10.2, vous devez aussi augmenter la taille d'extraction des consommateurs afin qu'ils puissent récupérer des lots d'enregistrements aussi volumineux. La dernière version de format de message regroupe toujours les massages en lots pour plus d'efficacité. Les versions de format de message précédentes ne regroupent pas les enregistrements non compressés en lots et dans ce cas, cette limite ne s'applique qu'à un seul enregistrement. Vous pouvez définir cette valeur par sujet à l'aide de la `max.message.bytes` configuration au niveau du sujet. | Apache Kafka par défaut |
| producteur.id.expiration.ms | Le temps, en ms, qu'un responsable de partition de sujets attendra avant d'expirer en tant que producteur IDs. Le producteur n' IDs expirera pas tant qu'une transaction qui lui est associée est toujours en cours. Notez que le producteur IDs peut expirer plus tôt si la dernière écriture provenant de l'identifiant du producteur est supprimée en raison des paramètres de conservation du sujet. La définition de cette valeur égale ou supérieure à cette valeur `delivery.timeout.ms` permet d'éviter l'expiration lors des nouvelles tentatives et de protéger contre la duplication des messages, mais la valeur par défaut doit être raisonnable dans la plupart des cas d'utilisation. | Apache Kafka par défaut |
## Configurations thématiques sur Express Brokers
Vous pouvez utiliser les commandes Apache Kafka pour définir ou modifier les propriétés de configuration au niveau des rubriques nouvelles et existantes. Si vous ne pouvez donner aucune configuration au niveau du sujet, Amazon MSK utilise le broker par défaut. Comme pour les configurations au niveau des courtiers, Amazon MSK protège certaines propriétés de configuration thématiques contre toute modification. Les exemples incluent le facteur de réplication `min.insync.replicas` et`unclean.leader.election.enable`. Si vous essayez de créer un sujet avec une valeur de facteur de réplication autre que`3`, Amazon MSK créera le sujet avec un facteur de réplication `3` par défaut. Pour de plus amples informations sur les propriétés de configuration au niveau de la rubrique et pour obtenir des exemples de définition, consultez [Configurations au niveau de la rubrique](https://kafka.apache.org/documentation/#topicconfigs) dans la documentation Apache Kafka.
| Propriété | Description |
| --- | --- |
| cleanup.policy | Cette configuration indique la politique de rétention à utiliser sur les segments de log. La politique de « suppression » (qui est la règle par défaut) supprimera les anciens segments lorsque leur durée de conservation ou leur limite de taille seront atteintes. La politique « compacte » activera le compactage du journal, qui conserve la dernière valeur pour chaque clé. Il est également possible de spécifier les deux politiques dans une liste séparée par des virgules (par exemple, « supprimer, compacter »). Dans ce cas, les anciens segments seront supprimés conformément à la durée de rétention et à la configuration de taille, tandis que les segments conservés seront compactés. Le compactage sur les courtiers Express est déclenché lorsque les données d'une partition atteignent 256 Mo. |
| compression.type | Spécifiez le type de compression final pour un sujet donné. Cette configuration accepte les codecs de compression standard (`gzip`,, `snappy``lz4`,`zstd`). Il accepte également `uncompressed` ce qui équivaut à l'absence de compression ; `producer` ce qui signifie conserver le codec de compression d'origine défini par le producteur. |
| supprimer.retention.ms | Durée de conservation des marqueurs de pierre tombale supprimés pour les sujets compactés dans les journaux. Ce paramètre définit également le temps pendant lequel un consommateur doit terminer une lecture s'il part du décalage 0 afin de s'assurer d'obtenir un instantané valide de l'étape finale. Sinon, les pierres tombales supprimées pourraient être collectées avant qu'elles ne terminent leur numérisation. La valeur par défaut de ce paramètre est 86400000 (24 \$1 60 \$1 60 \$1 1 000 ms, soit 1 jour), Apache Kafka par défaut |
| max.message.bytes | La plus grande taille de lot d'enregistrements autorisée par Kafka (après compression, si la compression est activée). Si ce chiffre est augmenté et que certains consommateurs sont plus âgés que cela`0.10.2`, la taille de récupération par les consommateurs doit également être augmentée afin qu'ils puissent récupérer des lots records de cette taille. Dans la dernière version du format de message, les enregistrements sont toujours regroupés en lots pour plus d'efficacité. Dans les versions de format de message précédentes, les enregistrements non compressés ne sont pas regroupés en lots et cette limite ne s'applique qu'à un seul enregistrement dans ce cas. Cela peut être défini par sujet avec le niveau du sujet`max.message.bytes config`. |
| message.timestamp.after.max.ms | Cette configuration définit la différence d'horodatage autorisée entre l'horodatage du message et l'horodatage du courtier. L'horodatage du message peut être supérieur ou égal à l'horodatage du courtier, la différence maximale autorisée étant déterminée par la valeur définie dans cette configuration. Si`message.timestamp.type=CreateTime`, le message sera rejeté si la différence d'horodatage dépasse ce seuil spécifié. Cette configuration est ignorée si`message.timestamp.type=LogAppendTime`. |
| message.timestamp.before.max.ms | Cette configuration définit la différence d'horodatage autorisée entre l'horodatage du broker et l'horodatage du message. L'horodatage du message peut être antérieur ou égal à l'horodatage du courtier, la différence maximale autorisée étant déterminée par la valeur définie dans cette configuration. Si`message.timestamp.type=CreateTime`, le message sera rejeté si la différence d'horodatage dépasse ce seuil spécifié. Cette configuration est ignorée si`message.timestamp.type=LogAppendTime`. |
| message.timestamp.type | Définissez si l'horodatage du message est l'heure de création du message ou l'heure d'ajout du journal. La valeur doit être `CreateTime` soit `LogAppendTime` |
| min.compaction.lag.ms | Durée minimale pendant laquelle un message restera non compacté dans le journal. Ce paramètre ne s'applique qu'aux journaux en cours de compactage. La valeur par défaut de ce paramètre est 0, Apache Kafka par défaut |
| max.compactage.lag.ms | Durée maximale pendant laquelle un message restera inéligible au compactage dans le journal. Ce paramètre ne s'applique qu'aux journaux en cours de compactage. Cette configuration serait limitée à [7 jours, Long.Max]. La valeur par défaut de ce paramètre est 9223372036854775807, Apache Kafka Default. |
| retention.bytes | Cette configuration contrôle la taille maximale qu'une partition (composée de segments de journal) peut atteindre avant que nous ne supprimions les anciens segments de journal pour libérer de l'espace si nous utilisons la politique de rétention « supprimer ». Par défaut, il n'y a pas de limite de taille, seulement une limite de temps. Comme cette limite est appliquée au niveau de la partition, multipliez-la par le nombre de partitions pour calculer la rétention du sujet en octets. De plus, `retention.bytes configuration` fonctionne indépendamment des `segment.bytes` configurations `segment.ms` et des configurations. De plus, il déclenche le lancement d'un nouveau segment s'`retention.bytes`il est configuré à zéro. |
| retention.ms | Cette configuration contrôle la durée maximale pendant laquelle nous conserverons un journal avant de supprimer les anciens segments de journal afin de libérer de l'espace si nous utilisons la politique de conservation « supprimer ». Cela représente un SLA sur le délai dans lequel les consommateurs doivent lire leurs données. Si ce paramètre est défini sur`-1`, aucune limite de temps n'est appliquée. De plus, `retention.ms` la configuration fonctionne indépendamment `segment.ms` des `segment.bytes` configurations. De plus, il déclenche le lancement d'un nouveau segment si la `retention.ms` condition est satisfaite. |
# Configurations en lecture seule d'Express Brokers
Amazon MSK définit les valeurs de ces configurations et les protège des modifications susceptibles d'affecter la disponibilité de votre cluster. Ces valeurs peuvent changer en fonction de la version d'Apache Kafka exécutée sur le cluster. Pensez donc à vérifier les valeurs de votre cluster spécifique.
Le tableau suivant répertorie les configurations en lecture seule pour les courtiers Express.
| Propriété | Description | Valeur d'Express Broker |
| --- | --- | --- |
| broker.id | L'identifiant du courtier pour ce serveur. | 1,2,3... |
| broker.rack | Rack du courtier. Cela sera utilisé dans l'attribution de réplication adaptée au rack pour la tolérance aux pannes. Exemples : `RACK1`, `us-east-1d` | ID AZ ou ID de sous-réseau |
| default.replication.factor | Facteurs de réplication par défaut pour toutes les rubriques. | 3 |
| récupérer un maximum d'octets | Le nombre maximum d'octets que nous retournerons pour une demande de récupération. | Apache Kafka par défaut |
| taille maximale du groupe | Le nombre maximum de consommateurs qu'un seul groupe de consommateurs peut accueillir. | Apache Kafka par défaut |
| inter.broker.listener.name | Nom de l'auditeur utilisé pour les communications entre les courtiers. | REPLICATION\$1SECURE ou REPLICATION |
| inter.broker.protocol.version | Spécifie la version du protocole inter-broker utilisée. | Apache Kafka par défaut |
| écouteurs | Liste des auditeurs : liste séparée par des virgules des noms des auditeurs et des personnes URIs que nous écouterons. Vous pouvez définir leadvertised.listeners property, mais pas la listeners propriété. | Généré par MSK |
| log.message.format.version | Spécifiez la version du format de message que le courtier utilisera pour ajouter des messages aux journaux. | Apache Kafka par défaut |
| min.insync.replicas | Lorsqu'un producteur attribue à acks la valeur `all` (ou`-1`), la valeur in `min.insync.replicas` indique le nombre minimum de répliques qui doivent accuser réception d'une écriture pour que celle-ci soit considérée comme réussie. Si ce minimum ne peut être atteint, le producteur émet une exception (`NotEnoughReplicas`ou`NotEnoughReplicasAfterAppend`). Vous pouvez utiliser la valeur des sacs fournis par votre producteur pour renforcer les garanties de durabilité. En réglant les packs sur « tous ». Cela garantit que le producteur déclenche une exception si la majorité des réplicas ne reçoivent pas d'écriture. | 2 |
| num.io.threads | Nombre de threads utilisés par le serveur pour produire des requêtes, qui peuvent inclure des E/S sur disque. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 16), (m7g.4xlarge, 32), (m7g.8xlarge, 64), (m7g.12xlarge, 96), (m7g.16xlarge, 128) | En fonction du type d'instance. = Math.max (8, 2\$1 v) CPUs |
| num.network.threads | Nombre de threads utilisés par le serveur pour recevoir les demandes du réseau et envoyer des réponses au réseau. (7 mg.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 8), (m7g.4 x large, 16), (m7g.8xlarge, 32), (m7g.12 x large, 48), (m7g.16 x large, 64) | En fonction du type d'instance. = Math.max (8, v) CPUs |
| replica.fetch.response.max.bytes | Nombre maximal d'octets attendu pour l'ensemble de la réponse de récupération. Les enregistrements sont récupérés par lots, et si le premier lot d'enregistrements de la première partition non vide de l'extraction est supérieur à cette valeur, le lot d'enregistrements sera toujours renvoyé pour assurer la progression. Ce n'est pas un maximum absolu. Les propriétés message.max.bytes (configuration du courtier) ou max.message.bytes (configuration du sujet) spécifient la taille maximale du lot d'enregistrements acceptée par le courtier. | Apache Kafka par défaut |
| request.timeout.ms | La configuration contrôle la durée maximale pendant laquelle le client attendra la réponse à une demande. Si la réponse n'est pas reçue avant l'expiration du délai imparti, le client renverra la demande si nécessaire ou échouera si les nouvelles tentatives sont épuisées. | Apache Kafka par défaut |
| transaction.state.log.min.isr | min.insync.replicasConfiguration remplacée pour le sujet de transaction. | 2 |
| transaction.state.log.replication.factor | Facteur de réplication de la rubrique de la transaction. | Apache Kafka par défaut |
| unclean.leader.election.enable | Permet aux répliques ne figurant pas dans l'ISR de servir de référence en dernier recours, même si cela peut entraîner une perte de données. | FALSE |
# Opérations de configuration du broker
Les configurations du broker Apache Kafka sont statiques ou dynamiques. Les configurations statiques nécessitent le redémarrage du broker pour que la configuration soit appliquée. Les configurations dynamiques ne nécessitent pas le redémarrage d'un broker pour que la configuration soit mise à jour. Pour plus d'informations sur les propriétés de configuration et les modes de mise à jour, consultez la section Configuration d'Apache Kafka.
Cette rubrique décrit comment créer des configurations MSK personnalisées et effectuer des opérations sur celles-ci. Pour de plus amples informations sur l'utilisation des configurations MSK pour créer ou mettre à jour des clusters, reportez-vous à la section [Caractéristiques et concepts clés d'Amazon MSK](operations.md).
**Topics**
+ [Créer une configuration](msk-configuration-operations-create.md)
+ [Mise à jour de la configuration](msk-configuration-operations-update.md)
+ [Supprimer la configuration](msk-configuration-operations-delete.md)
+ [Obtenir les métadonnées de configuration](msk-configuration-operations-describe.md)
+ [Obtenir des informations sur la révision de la configuration](msk-configuration-operations-describe-revision.md)
+ [Répertorier les configurations de votre compte pour la région actuelle](msk-configuration-operations-list.md)
+ [États de configuration d'Amazon MSK](msk-configuration-states.md)
# Créer une configuration
Ce processus décrit comment créer une configuration Amazon MSK personnalisée et comment effectuer des opérations sur celle-ci.
1. Créez un fichier dans lequel vous spécifiez les propriétés de configuration à définir et les valeurs que vous souhaitez leur attribuer. Voici le contenu d'un exemple de fichier de configuration.
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
1. Exécutez la AWS CLI commande suivante et *config-file-path* remplacez-la par le chemin du fichier dans lequel vous avez enregistré votre configuration à l'étape précédente.
**Note**
Le nom que vous choisissez pour votre configuration doit correspondre à la regex suivante : « ^[0-9A-Za-z][0-9A-Za-z-]\$10,\$1\$1 ».
```
aws kafka create-configuration --name "ExampleConfigurationName" --description "Example configuration description." --kafka-versions "1.1.1" --server-properties fileb://config-file-path
```
Voici un exemple de réponse réussie après l'exécution de cette commande.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-21T19:37:40.626Z",
"LatestRevision": {
"CreationTime": "2019-05-21T19:37:40.626Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
```
1. La commande précédente renvoie un Amazon Resource Name (ARN) pour votre nouvelle configuration. Enregistrez cet ARN car vous en avez besoin pour faire référence à cette configuration dans d'autres commandes. Si vous perdez votre ARN de configuration, vous pouvez répertorier toutes les configurations de votre compte pour le retrouver.
# Mise à jour de la configuration
Ce processus décrit comment mettre à jour une configuration Amazon MSK personnalisée.
1. Créez un fichier dans lequel vous spécifiez les propriétés de configuration que vous souhaitez mettre à jour et les valeurs que vous souhaitez leur attribuer. Voici le contenu d'un exemple de fichier de configuration.
```
auto.create.topics.enable = true
min.insync.replicas = 2
```
1. Exécutez la AWS CLI commande suivante et *config-file-path* remplacez-la par le chemin du fichier dans lequel vous avez enregistré votre configuration à l'étape précédente.
*configuration-arn*Remplacez-le par l'ARN que vous avez obtenu lors de la création de la configuration. Si vous n'avez pas enregistré l'ARN lorsque vous avez créé la configuration, vous pouvez utiliser la commande `list-configurations` pour répertorier toutes les configurations de votre compte. La configuration que vous souhaitez voir figurer dans la liste apparaît dans la réponse. L'ARN de la configuration apparaît également dans cette liste.
```
aws kafka update-configuration --arn configuration-arn --description "Example configuration revision description." --server-properties fileb://config-file-path
```
1. Voici un exemple de réponse réussie après l'exécution de cette commande.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"LatestRevision": {
"CreationTime": "2020-08-27T19:37:40.626Z",
"Description": "Example configuration revision description.",
"Revision": 2
}
}
```
# Supprimer la configuration
La procédure suivante explique comment supprimer une configuration qui n'est pas attachée à un cluster. Vous ne pouvez pas supprimer une configuration attachée à un cluster.
1. Pour exécuter cet exemple, remplacez-le *configuration-arn* par l'ARN que vous avez obtenu lors de la création de la configuration. Si vous n'avez pas enregistré l'ARN lorsque vous avez créé la configuration, vous pouvez utiliser la commande `list-configurations` pour répertorier toutes les configurations de votre compte. La configuration que vous souhaitez voir figurer dans la liste apparaît dans la réponse. L'ARN de la configuration apparaît également dans cette liste.
```
aws kafka delete-configuration --arn configuration-arn
```
1. Voici un exemple de réponse réussie après l'exécution de cette commande.
```
{
"arn": " arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"state": "DELETING"
}
```
# Obtenir les métadonnées de configuration
La procédure suivante explique comment décrire une configuration Amazon MSK pour obtenir des métadonnées relatives à cette configuration.
1. La commande suivante renvoie les métadonnées relatives à la configuration. Pour obtenir une description détaillée de la configuration, exécutez le `describe-configuration-revision`.
Pour exécuter cet exemple, remplacez-le *configuration-arn* par l'ARN que vous avez obtenu lors de la création de la configuration. Si vous n'avez pas enregistré l'ARN lorsque vous avez créé la configuration, vous pouvez utiliser la commande `list-configurations` pour répertorier toutes les configurations de votre compte. La configuration que vous souhaitez voir figurer dans la liste apparaît dans la réponse. L'ARN de la configuration apparaît également dans cette liste.
```
aws kafka describe-configuration --arn configuration-arn
```
1. Voici un exemple de réponse réussie après l'exécution de cette commande.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
}
```
# Obtenir des informations sur la révision de la configuration
Ce processus vous permet d'obtenir une description détaillée de la révision de la configuration Amazon MSK.
Si vous utilisez la commande `describe-configuration` pour décrire une configuration MSK, vous voyez les métadonnées de la configuration. Pour obtenir une description de la configuration, utilisez la commande `describe-configuration-revision`.
+ Exécutez la commande suivante et remplacez-la *configuration-arn* par l'ARN que vous avez obtenu lors de la création de la configuration. Si vous n'avez pas enregistré l'ARN lorsque vous avez créé la configuration, vous pouvez utiliser la commande `list-configurations` pour répertorier toutes les configurations de votre compte. La configuration que vous souhaitez voir figurer dans la liste apparaît dans la réponse. L'ARN de la configuration apparaît également dans cette liste.
```
aws kafka describe-configuration-revision --arn configuration-arn --revision 1
```
Voici un exemple de réponse réussie après l'exécution de cette commande.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1,
"ServerProperties": "YXV0by5jcmVhdGUudG9waWNzLmVuYWJsZSA9IHRydWUKCgp6b29rZWVwZXIuY29ubmVjdGlvbi50aW1lb3V0Lm1zID0gMTAwMAoKCmxvZy5yb2xsLm1zID0gNjA0ODAwMDAw"
}
```
La valeur de `ServerProperties` est codée à l'aide de base64. Si vous utilisez un décodeur base64 (par exemple, https://www.base64decode.org/) pour le décoder manuellement, vous obtenez le contenu du fichier de configuration d'origine utilisé pour créer la configuration personnalisée. Dans ce cas, vous obtenez ce qui suit :
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
# Répertorier les configurations de votre compte pour la région actuelle
Ce processus décrit comment répertorier toutes les configurations Amazon MSK de votre compte pour la AWS région actuelle.
+ Exécutez la commande suivante.
```
aws kafka list-configurations
```
Voici un exemple de réponse réussie après l'exécution de cette commande.
```
{
"Configurations": [
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
},
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
]
}
```
# États de configuration d'Amazon MSK
Une configuration Amazon MSK peut avoir l'un des états suivants. Pour effectuer une opération sur une configuration, celle-ci doit être à l'état `ACTIVE` ou `DELETE_FAILED` :
+ `ACTIVE`
+ `DELETING`
+ `DELETE_FAILED`
# Rééquilibrage intelligent pour les clusters
Amazon MSK fournit un rééquilibrage intelligent pour tous les nouveaux clusters provisionnés par MSK avec des courtiers Express. Cette fonctionnalité gère automatiquement les opérations de distribution des partitions et de dimensionnement des clusters, éliminant ainsi le recours à des outils tiers. Le rééquilibrage intelligent rééquilibre automatiquement les partitions lorsque vous augmentez ou diminuez les clusters. Il surveille également en permanence l'état de santé de votre cluster pour détecter tout déséquilibre ou surcharge des ressources et redistribue la charge de travail.
Le rééquilibrage intelligent permet des opérations de mise à l'échelle rapides qui se terminent en 30 minutes et n'ont aucun impact sur la disponibilité du cluster pendant le dimensionnement. Il est activé par défaut pour tous les nouveaux clusters provisionnés basés sur MSK Express et fonctionne avec la limite de partition maximale recommandée de 20 000 partitions par broker. De plus, cette fonctionnalité est disponible sans frais supplémentaires et ne nécessite aucune configuration.
À compter du 20 novembre 2025, le rééquilibrage intelligent est disponible dans toutes les AWS régions où les courtiers Amazon MSK Express sont pris en charge.
**Topics**
+ [Comment fonctionne le rééquilibrage intelligent](#how-intelligent-rebalancing-works)
+ [Surveillance des mesures de rééquilibrage intelligentes](#intelligent-rebalancing-metrics)
+ [Considérations relatives à l'utilisation du rééquilibrage intelligent](#intelligent-rebalancing-considerations)
+ [Dimensionnement des clusters Amazon MSK à la hausse ou à la baisse en une seule opération](intelligent-rebalancing-scaling-clusters.md)
+ [Rééquilibrage permanent pour les clusters Amazon MSK](intelligent-rebalancing-self-balancing-paritions.md)
## Comment fonctionne le rééquilibrage intelligent
Le rééquilibrage intelligent est activé par défaut pour tous les nouveaux clusters provisionnés par MSK auprès d'Express Brokers. Il inclut une assistance pour les situations suivantes :
+ **Mise à l'échelle ascendante ou descendante** : vous permet d'ajouter ou de supprimer des courtiers à vos clusters basés sur MSK Express en un seul clic. Une fois que vous avez indiqué les courtiers à ajouter ou à supprimer, le rééquilibrage intelligent redistribue automatiquement les partitions dans la nouvelle configuration du cluster en fonction des AWS meilleures pratiques internes.
+ **Rééquilibrage en régime permanent** : en régime permanent, cette fonction surveille en permanence l'état de santé de votre cluster et rééquilibre automatiquement les partitions lorsque :
+ L'utilisation des ressources devient biaisée entre les courtiers.
+ Les courtiers sont surapprovisionnés ou sous-utilisés.
+ De nouveaux courtiers sont ajoutés ou des courtiers existants sont supprimés.
**Note**
Si le rééquilibrage intelligent est activé, vous ne pourrez pas utiliser d'outils tiers, tels que le régulateur de vitesse, pour rééquilibrer les partitions. Vous devez d'abord suspendre le rééquilibrage intelligent pour utiliser l'API de réattribution de partition fournie par ces outils tiers.
Vous pouvez utiliser cette fonctionnalité dans la console Amazon MSK. Vous pouvez également utiliser cette fonctionnalité à l' AWS CLI aide d'Amazon MSK APIs ou du AWS SDK, et. AWS CloudFormation Pour plus d’informations, consultez [Dimensionnement des clusters Amazon MSK](intelligent-rebalancing-scaling-clusters.md) et [Rééquilibrage en régime permanent](intelligent-rebalancing-self-balancing-paritions.md).
## Surveillance des mesures de rééquilibrage intelligentes
Vous pouvez surveiller l'état des opérations de rééquilibrage intelligent en cours et historiques à l'aide des CloudWatch indicateurs Amazon suivants :
+ `RebalanceInProgress`: Cette métrique est publiée toutes les minutes avec une valeur de 1 lorsque le rééquilibrage est en cours et de 0 dans le cas contraire.
+ `UnderProvisioned`: indique qu'un cluster est actuellement sous-provisionné et qu'aucun rééquilibrage de partition ne peut être effectué. Vous devez soit ajouter d'autres courtiers, soit augmenter le type d'instance de votre cluster.
Pour plus d'informations sur la surveillance d'un cluster provisionné MSK, reportez-vous [](monitoring.md) aux sections et. [](cloudwatch-metrics.md)
## Considérations relatives à l'utilisation du rééquilibrage intelligent
+ Support pour le rééquilibrage intelligent n'est disponible que pour les nouveaux clusters provisionnés par MSK auprès d'Express Brokers.
+ Pour la réattribution automatique des partitions, une prise en charge maximale de 20 000 partitions par courtier est disponible.
+ Vous ne pouvez pas utiliser de réattribution de partition APIs ou d'outils de rééquilibrage tiers lorsque le rééquilibrage intelligent est activé. Pour utiliser de tels outils APIs ou des outils tiers, vous devez d'abord suspendre le rééquilibrage intelligent de votre cluster basé sur MSK Express.
# Dimensionnement des clusters Amazon MSK à la hausse ou à la baisse en une seule opération
Grâce au rééquilibrage intelligent, vous pouvez augmenter ou diminuer vos clusters en modifiant le nombre de courtiers dans vos clusters en une seule action. Vous pouvez le faire dans la console Amazon MSK, ou en utilisant Amazon MSK APIs ou le AWS SDK AWS CLI, et. AWS CloudFormation Lorsque vous modifiez le nombre de courtiers, Amazon MSK effectue les opérations suivantes :
+ Distribue automatiquement les partitions aux nouveaux courtiers.
+ Déplace les partitions des courtiers en cours de suppression.
Lorsque vous augmentez ou diminuez la taille de vos clusters, la disponibilité des clusters pour que les clients puissent produire et consommer des données reste inchangée.
**Topics**
------
#### [ Scaling clusters using AWS Management Console ]
1. Vous voulez ouvrir la console Amazon MSK à la [https://console.aws.amazon.com/msk/maison ? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Sur la page **Clusters**, choisissez un cluster basé sur Express récemment créé. Pour plus d'informations sur la création d'un cluster basé sur Express provisionné, consultez. [Étape 1 : Création d'un cluster provisionné MSK](create-cluster.md)
1. Dans la liste déroulante **Actions**, sélectionnez **Modifier le nombre de courtiers**.
1. Sur la page **Modifier le nombre de courtiers par zone**, effectuez l'une des opérations suivantes :
+ Pour ajouter d'autres courtiers à votre cluster, choisissez **Ajouter des courtiers à chaque zone de disponibilité**, puis entrez le nombre de courtiers que vous souhaitez ajouter.
+ Pour supprimer des courtiers de votre cluster, choisissez **Supprimer un courtier de chaque zone de disponibilité**.
1. Sélectionnez **Enregistrer les modifications**.
------
#### [ Scaling clusters using AWS CLI ]
Vous pouvez augmenter ou diminuer le nombre de vos clusters en modifiant leur nombre de courtiers. Pour ce faire AWS CLI, utilisez la [update-broker-count](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-broker-count.html)commande, comme indiqué dans l'exemple suivant. Dans cette commande, spécifiez le nombre de courtiers que vous souhaitez dans votre cluster dans le `target-broker-count` paramètre.
```
aws msk update-broker-count --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1 --current-version ABCDEF1GHIJK0L --target-broker-count 6
```
------
#### [ Scaling clusters using AWS SDK ]
Vous pouvez augmenter ou diminuer vos clusters en modifiant par programmation le nombre de courtiers. Pour ce faire, utilisez le AWS SDK, utilisez l'[UpdateBrokerCount](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-count.html#UpdateBrokerCount)API, comme indiqué dans l'exemple suivant. Pour le `TargetNumberOfBrokerNodes` paramètre, spécifiez le nombre de courtiers que vous souhaitez dans votre cluster.
```
update_broker_count_response = client.update_broker_count(
ClusterArn='arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1',
CurrentVersion='ABCDEF1GHIJK0L',
TargetNumberOfBrokerNodes=6
)
```
------
# Rééquilibrage permanent pour les clusters Amazon MSK
Le rééquilibrage en régime permanent fait partie de la fonction de rééquilibrage intelligent, qui est activée par défaut pour tous les nouveaux clusters provisionnés par MSK auprès d'Express Brokers. Lorsque vous augmentez ou diminuez la taille de vos clusters, Amazon MSK gère automatiquement la gestion des partitions en distribuant les partitions aux nouveaux courtiers et en déplaçant les partitions des courtiers en attente de suppression. Pour garantir une répartition optimale de la charge de travail entre les courtiers, le rééquilibrage intelligent utilise les meilleures pratiques d'Amazon MSK pour déterminer les seuils permettant de lancer automatiquement le rééquilibrage pour vos courtiers.
Vous pouvez faire une pause et reprendre le rééquilibrage en régime permanent en cas de besoin. Le rééquilibrage en régime permanent surveille en permanence votre cluster et effectue les opérations suivantes :
+ Suit l'utilisation des ressources du courtier (processeur, réseau, stockage).
+ Ajuste automatiquement le placement des partitions sans aucun impact sur la disponibilité des données.
+ Réalise les opérations de rééquilibrage jusqu'à 180 fois plus rapidement pour les courtiers Express que pour les courtiers standard.
+ Maintient les performances du cluster.
**Topics**
------
#### [ Pause and resume steady state rebalancing in AWS Management Console ]
1. Vous voulez ouvrir la console Amazon MSK à la [https://console.aws.amazon.com/msk/maison ? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Sur la page **Clusters**, choisissez un cluster basé sur Express. Pour plus d'informations sur la création d'un cluster basé sur Express provisionné, consultez. [Étape 1 : Création d'un cluster provisionné MSK](create-cluster.md)
1. Sur la page détaillée du cluster, vérifiez que l'état de **rééquilibrage intelligent** est **actif**. Si le rééquilibrage intelligent n'est pas disponible ou si le statut est en **pause**, créez un nouveau cluster basé sur Express.
1. Dans la liste déroulante **Actions**, choisissez **Modifier le rééquilibrage intelligent**.
1. Sur la page **Modifier le rééquilibrage intelligent**, procédez comme suit :
1. Choisissez **Suspendu.**
1. Sélectionnez **Enregistrer les modifications**.
------
#### [ Pause and resume steady state rebalancing using AWS CLI ]
Pour définir l'état de rééquilibrage d'un cluster à **ACTIVE** l'aide de AWS CLI, utilisez la commande [update-rebalancing](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-rebalancing.html), comme indiqué dans l'exemple suivant. Dans cette commande, spécifiez le statut à l'aide du `rebalancing` paramètre.
```
aws msk update-rebalancing --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1 --current-version ABCDEF1GHIJK0L --rebalancing "{\"Rebalancing\":{\"Status\":\"ACTIVE\"}}"
```
------
#### [ Pause and resume steady state rebalancing using AWS SDK ]
Vous pouvez également définir l'état de rééquilibrage d'un cluster à l'aide de l'[UpdateRebalancingRequest](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-rebalancing.html#UpdateRebalancing)API pour modifier par programmation le nombre de courtiers. Les exemples suivants montrent comment définir l'état de rééquilibrage sur **ACTIVE** et**PAUSED**.
```
final UpdateRebalancingRequest updateRebalancingRequest = new UpdateRebalancingRequest()
.withClusterArn(arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1)
.withCurrentVersion(ABCDEF1GHIJK0L)
.withRebalancing(new Rebalancing().withStatus("ACTIVE"));
```
```
final UpdateRebalancingRequest updateRebalancingRequest = new UpdateRebalancingRequest()
.withClusterArn(arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1)
.withCurrentVersion(ABCDEF1GHIJK0L)
.withRebalancing(new Rebalancing().withStatus("PAUSED"));
```
------
# Application de correctifs sur des clusters provisionnés par MSK
Amazon MSK met régulièrement à jour le logiciel des courtiers de votre cluster. La maintenance inclut les mises à jour planifiées ou les réparations imprévues. La maintenance planifiée inclut les mises à jour du système d'exploitation, les mises à jour de sécurité et les autres mises à jour logicielles nécessaires pour maintenir l'intégrité, la sécurité et les performances de votre cluster. Nous effectuons des opérations de maintenance imprévues pour remédier à la dégradation soudaine de l'infrastructure. Nous assurons la maintenance des courtiers Standard et Express, mais les expériences sont différentes.
## Correctifs pour les courtiers standard
Les mises à jour apportées à vos courtiers standard n'ont aucun impact sur la rédaction et la lecture de vos applications si vous suivez les [meilleures pratiques](bestpractices.md).
Amazon MSK utilise des mises à jour logicielles continues afin de maintenir la haute disponibilité de vos clusters. Au cours de ce processus, les courtiers sont redémarrés un par un et Kafka transfère automatiquement le leadership à un autre courtier en ligne. Lorsque vous visualisez les opérations du cluster dans AWS Management Console ou via le `DescribeClusterOperation` et `ListClusterOperations` APIs, ces opérations de maintenance apparaissent avec un type d'opération de`SECURITY_PATCHING`. Les clients Kafka disposent de mécanismes intégrés pour détecter automatiquement le changement de direction des partitions et continuer à écrire et à lire des données dans un cluster MSK. Suivez [Bonnes pratiques pour les clients Apache Kafka](bestpractices-kafka-client.md) pour garantir le bon fonctionnement de votre cluster à tout moment, y compris pendant l'application des correctifs.
Lorsqu'un courtier se déconnecte, il est normal de constater des erreurs de déconnexion transitoires chez vos clients. Vous observerez également pendant une brève période (jusqu'à 2 minutes, généralement moins) des pics de latence de lecture et d'écriture de p99 (généralement des millisecondes élevées, jusqu'à environ 2 secondes). Ces pics sont attendus et sont causés par le fait que le client se reconnecte à un nouveau courtier leader ; cela n'a aucun impact sur vos produits ou votre consommation et se résorbera après la reconnexion. Pour plus d'informations, consultez [Broker hors ligne et basculement du client](https://docs.aws.amazon.com/msk/latest/developerguide/troubleshooting-offlinebroker-clientfailover.html).
Vous observerez également une augmentation de la métrique`UnderReplicatedPartitions`, ce qui est attendu car les partitions du broker arrêté ne répliquent plus les données. Cela n'a aucun impact sur les écritures et les lectures des applications, car les répliques de ces partitions hébergées sur d'autres courtiers répondent désormais aux demandes.
Après la mise à jour logicielle, lorsque le courtier revient en ligne, il doit « rattraper » les messages produits alors qu'il était hors ligne. Pendant le catch up, vous pouvez également observer une augmentation de l'utilisation du débit du volume et du processeur. Cela ne devrait pas avoir d'impact sur les écritures et les lectures dans le cluster si vos courtiers disposent de suffisamment de ressources en termes de processeur, de mémoire, de réseau et de volume.
## Correctifs pour les courtiers Express
Il n'existe aucun créneau de maintenance pour les courtiers Express. Amazon MSK met automatiquement à jour votre cluster de manière continue et dans le temps, ce qui signifie que vous pouvez vous attendre à des redémarrages occasionnels et ponctuels des courtiers au cours du mois. Cela garantit que vous n'avez pas besoin de planifier ou de prendre des mesures d'adaptation concernant des fenêtres de maintenance uniques à l'échelle du cluster. Comme toujours, le trafic restera ininterrompu pendant le redémarrage d'un courtier, car la direction passera à d'autres courtiers qui continueront à traiter les demandes. Lorsque vous visualisez les opérations du cluster dans AWS Management Console ou via le `DescribeClusterOperation` et `ListClusterOperations` APIs, ces opérations de maintenance apparaissent avec un type d'opération de`BROKER_UPDATE`.
Les courtiers Express sont configurés avec des paramètres et des garde-fous conformes aux meilleures pratiques qui rendent votre cluster résilient aux changements de charge susceptibles de survenir pendant la maintenance. Amazon MSK définit des quotas de débit pour vos courtiers Express afin d'atténuer l'impact de la surcharge de votre cluster, qui peut entraîner des problèmes lors du redémarrage des courtiers. Ces améliorations éliminent le besoin de notifications préalables, de planification et de fenêtres de maintenance lorsque vous utilisez des courtiers Express.
Les courtiers Express répliquent toujours vos données de trois manières afin que vos clients basculent automatiquement lors des redémarrages. Vous n'avez pas à vous inquiéter de l'indisponibilité des rubriques en raison d'un facteur de réplication défini sur 1 ou 2. De plus, le rattrapage d'un courtier Express redémarré est plus rapide que sur les courtiers Standard. La rapidité d'application des correctifs sur les courtiers Express signifie que les activités du plan de contrôle que vous pourriez avoir planifiées pour votre cluster ne seront que très peu perturbées.
Comme pour toutes les applications Apache Kafka, il existe toujours un contrat client-serveur partagé pour les clients qui se connectent aux courtiers Express. Il est toujours essentiel de configurer vos clients de manière à gérer le basculement du leadership entre les courtiers. Respectez les [Bonnes pratiques pour les clients Apache Kafka](bestpractices-kafka-client.md) pour garantir le bon fonctionnement de votre cluster à tout moment, y compris lors de l'application de correctifs. Après le redémarrage d'un courtier, il est normal que des [erreurs de déconnexion transitoires se produisent chez vos clients](troubleshooting-offlinebroker-clientfailover.md). Cela n'affectera pas vos produits et votre consommation, car les courtiers abonnés prendront le contrôle de la partition. Vos clients Apache Kafka basculeront automatiquement et commenceront à envoyer des demandes aux nouveaux courtiers leaders.
# Broker hors ligne et basculement du client
Kafka autorise un courtier hors ligne ; un seul courtier hors ligne au sein d'un cluster sain et équilibré respectant les meilleures pratiques n'aura aucun impact ni n'entraînera d'échec de production ou de consommation. Cela est dû au fait qu'un autre courtier reprendra la direction de la partition et que la bibliothèque client de Kafka basculera automatiquement et commencera à envoyer des demandes aux nouveaux courtiers leaders.
**Contrat client-serveur**
Cela se traduit par un contrat partagé entre la bibliothèque cliente et le comportement côté serveur ; le serveur doit réussir à attribuer un ou plusieurs nouveaux leaders et le client doit changer de courtier pour envoyer des demandes aux nouveaux dirigeants en temps opportun.
Kafka utilise des exceptions pour contrôler ce flux :
**Exemple de procédure**
1. Le courtier A entre dans un état hors ligne.
1. Le client Kafka reçoit une exception (généralement une déconnexion du réseau ou not\$1leader\$1for\$1partition).
1. Ces exceptions obligent le client Kafka à mettre à jour ses métadonnées afin de connaître les derniers leaders.
1. Le client de Kafka recommence à envoyer des demandes aux nouveaux responsables de partition sur d'autres courtiers.
Ce processus prend généralement moins de 2 secondes avec le client Java vendu et les configurations par défaut. Les erreurs côté client sont verbeuses et répétitives, mais elles ne sont pas préoccupantes, comme l'indique le niveau « WARN ».
**Exemple : Exception 1**
`10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Got error produce response with correlation id 864845 on topic-partition msk-test-topic-1-0, retrying (2147483646 attempts left). Error: NETWORK_EXCEPTION. Error Message: Disconnected from node 2`
**Exemple : Exception 2**
`10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Received invalid metadata error in produce request on partition msk-test-topic-1-41 due to org.apache.kafka.common.errors.NotLeaderOrFollowerException: For requests intended only for the leader, this error indicates that the broker is not the current leader. For requests intended for any replica, this error indicates that the broker is not a replica of the topic partition.. Going to request metadata update now"`
Les clients Kafka résolvent automatiquement ces erreurs généralement en 1 seconde et au plus 3 secondes. Cela se traduit par produce/consume une latence de p99 dans les métriques côté client (généralement des millisecondes élevées dans les années 100). Une durée plus longue indique généralement un problème de configuration client ou de charge du contrôleur côté serveur. Consultez la section consacrée au dépannage.
Un échec réussi peut être vérifié en vérifiant l'augmentation du trafic `BytesInPerSec` et des `LeaderCount` indicateurs sur les autres courtiers, ce qui prouve que le trafic et le leadership ont évolué comme prévu. Vous observerez également une augmentation de la `UnderReplicatedPartitions` métrique, ce qui est attendu lorsque les répliques sont hors ligne avec le courtier d'arrêt.
**Résolution des problèmes**
Le flux ci-dessus peut être perturbé en rompant le contrat client-serveur. Les causes de problème les plus courantes sont les suivantes :
+ Mauvaise configuration ou utilisation incorrecte des bibliothèques clientes de Kafka.
+ Comportements par défaut inattendus et bogues liés aux bibliothèques clientes tierces.
+ Le contrôleur est surchargé, ce qui ralentit l'assignation du chef de partition.
+ Un nouveau contrôleur est élu, ce qui ralentit l'attribution du chef de partition.
Afin de garantir un comportement correct face à un basculement du leadership, nous recommandons :
+ [Les meilleures pratiques](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html) côté serveur doivent être suivies pour garantir que le Controller Broker est dimensionné de manière appropriée afin d'éviter une affectation lente du leadership.
+ Les nouvelles tentatives doivent être activées dans les bibliothèques clientes pour garantir que le client gère le basculement.
+ Les bibliothèques clientes doivent avoir configuré retry.backoff.ms (100 par défaut) pour éviter les tempêtes. connection/request
+ Les bibliothèques clientes doivent définir des valeurs conformes au SLA des applications à request.timeout.ms et à delivery.timeout.ms. Des valeurs plus élevées se traduiront par un ralentissement du basculement pour certains types de défaillances.
+ Les bibliothèques clientes doivent s'assurer que bootstrap.servers contient au moins 3 courtiers aléatoires afin d'éviter tout impact sur la disponibilité lors de la découverte initiale.
+ Certaines bibliothèques clientes sont de niveau inférieur à d'autres et attendent du développeur de l'application qu'il implémente lui-même la logique des nouvelles tentatives et la gestion des exceptions. Reportez-vous à la documentation spécifique à la bibliothèque client pour des exemples d'utilisation, et assurez-vous que reconnect/retry la bonne logique est suivie.
+ Nous recommandons de surveiller la latence côté client pour les produits, le nombre de demandes réussies et le nombre d'erreurs pour les erreurs non réessayables.
+ Nous avons observé que les anciennes bibliothèques Golang et Ruby tierces restent verbeuses pendant toute la période hors ligne du broker, même si les demandes de production et de consommation ne sont pas affectées. Nous vous recommandons de toujours surveiller les indicateurs de votre activité, en plus des indicateurs de réussite et d'erreur relatifs aux demandes, afin de déterminer si vos journaux ont un impact réel par rapport au bruit.
+ Les clients ne doivent pas s'alarmer en cas d'exceptions transitoires pour network/not\$1leader, car elles sont normales, sans impact et attendues dans le cadre du protocole Kafka.
+ Les clients ne doivent pas déclencher d'alarme, UnderReplicatedPartitions car elles sont normales, sans impact et attendues lors d'un seul courtier hors ligne.
# Sécurité dans Amazon MSK
La sécurité du cloud AWS est la priorité absolue. En tant que AWS client, vous bénéficiez d'un centre de données et d'une architecture réseau conçus pour répondre aux exigences des entreprises les plus sensibles en matière de sécurité.
La sécurité est une responsabilité partagée entre vous AWS et vous. Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) décrit ceci comme la sécurité *du* cloud et la sécurité *dans* le cloud :
+ **Sécurité du cloud** : AWS est chargée de protéger l'infrastructure qui exécute les AWS services dans le AWS cloud. AWS vous fournit également des services que vous pouvez utiliser en toute sécurité. Des auditeurs tiers testent et vérifient régulièrement l'efficacité de notre sécurité dans le cadre des programmes de [AWS conformité Programmes](https://aws.amazon.com/compliance/programs/) de de conformité. Pour en savoir plus sur les programmes de conformité qui s'appliquent à Amazon Managed Streaming for Apache Kafka, consultez [Services Amazon Web Services concernés par le programme de conformité](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sécurité dans le cloud** — Votre responsabilité est déterminée par le AWS service que vous utilisez. Vous êtes également responsable d’autres facteurs, y compris la sensibilité de vos données, les exigences de votre entreprise, ainsi que la législation et la réglementation applicables.
Cette documentation vous aide à comprendre comment appliquer le modèle de responsabilité partagée lors de l'utilisation d'Amazon MSK. Les rubriques suivantes vous montrent comment configurer Amazon MSK pour répondre à vos objectifs de sécurité et de conformité. Vous apprenez également à utiliser d'autres services Amazon Web Services qui vous aident à contrôler et sécuriser vos ressources Amazon MSK.
**Topics**
+ [Protection des données dans Amazon Managed Streaming for Apache Kafka](data-protection.md)
+ [Authentification et autorisation pour Amazon MSK APIs](security-iam.md)
+ [Authentification et autorisation pour Apache Kafka APIs](kafka_apis_iam.md)
+ [Modification du groupe de sécurité d'un cluster Amazon MSK](change-security-group.md)
+ [Contrôlez l'accès aux ZooKeeper nœuds Apache de votre cluster Amazon MSK](zookeeper-security.md)
+ [Validation de conformité pour Amazon Managed Streaming for Apache Kafka](MSK-compliance.md)
+ [Résilience dans Amazon Managed Streaming for Apache Kafka](disaster-recovery-resiliency.md)
+ [Sécurité de l'infrastructure dans Amazon Managed Streaming for Apache Kafka](infrastructure-security.md)
# Protection des données dans Amazon Managed Streaming for Apache Kafka
Le modèle de [responsabilité AWS partagée Le modèle](https://aws.amazon.com/compliance/shared-responsibility-model/) s'applique à la protection des données dans Amazon Managed Streaming for Apache Kafka. Comme décrit dans ce modèle, AWS est chargé de protéger l'infrastructure mondiale qui gère tous les AWS Cloud. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Vous êtes également responsable des tâches de configuration et de gestion de la sécurité des Services AWS que vous utilisez. Pour plus d’informations sur la confidentialité des données, consultez [Questions fréquentes (FAQ) sur la confidentialité des données](https://aws.amazon.com/compliance/data-privacy-faq/). Pour en savoir plus sur la protection des données en Europe, consultez le billet de blog [Modèle de responsabilité partagée d’AWS et RGPD (Règlement général sur la protection des données)](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) sur le *Blog de sécuritéAWS *.
À des fins de protection des données, nous vous recommandons de protéger les Compte AWS informations d'identification et de configurer les utilisateurs individuels avec AWS IAM Identity Center ou Gestion des identités et des accès AWS (IAM). Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous :
+ Utilisez l’authentification multifactorielle (MFA) avec chaque compte.
+ SSL/TLS À utiliser pour communiquer avec AWS les ressources. Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Configurez l'API et la journalisation de l'activité des utilisateurs avec AWS CloudTrail. Pour plus d'informations sur l'utilisation des CloudTrail sentiers pour capturer AWS des activités, consultez la section [Utilisation des CloudTrail sentiers](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) dans le *guide de AWS CloudTrail l'utilisateur*.
+ Utilisez des solutions de AWS chiffrement, ainsi que tous les contrôles de sécurité par défaut qu'ils contiennent Services AWS.
+ Utilisez des services de sécurité gérés avancés tels qu’Amazon Macie, qui contribuent à la découverte et à la sécurisation des données sensibles stockées dans Amazon S3.
+ Si vous avez besoin de modules cryptographiques validés par la norme FIPS 140-3 pour accéder AWS via une interface de ligne de commande ou une API, utilisez un point de terminaison FIPS. Pour plus d’informations sur les points de terminaison FIPS disponibles, consultez [Norme FIPS (Federal Information Processing Standard) 140-3](https://aws.amazon.com/compliance/fips/).
Nous vous recommandons fortement de ne jamais placer d’informations confidentielles ou sensibles, telles que les adresses e-mail de vos clients, dans des balises ou des champs de texte libre tels que le champ **Nom**. Cela inclut lorsque vous travaillez avec Amazon MSK ou une autre entreprise à Services AWS l'aide de la console, de l'API ou AWS SDKs. AWS CLI Toutes les données que vous entrez dans des balises ou des champs de texte de forme libre utilisés pour les noms peuvent être utilisées à des fins de facturation ou dans les journaux de diagnostic. Si vous fournissez une adresse URL à un serveur externe, nous vous recommandons fortement de ne pas inclure d’informations d’identification dans l’adresse URL permettant de valider votre demande adressée à ce serveur.
**Topics**
+ [Chiffrement Amazon MSK](msk-encryption.md)
+ [Commencez avec le chiffrement Amazon MSK](msk-working-with-encryption.md)
+ [Utiliser Amazon MSK APIs avec des points de terminaison VPC d'interface](privatelink-vpc-endpoints.md)
# Chiffrement Amazon MSK
Amazon MSK fournit des options de chiffrement des données que vous pouvez utiliser pour répondre à des exigences strictes en matière de gestion des données. Les certificats utilisés par Amazon MSK pour le chiffrement doivent être renouvelés tous les 13 mois. Amazon MSK renouvelle automatiquement ces certificats pour tous les clusters. Les clusters Express Broker restent en `ACTIVE` état lorsqu'Amazon MSK lance l'opération de mise à jour des certificats. Pour les clusters de courtiers standard, Amazon MSK définit l'état du cluster au `MAINTENANCE` moment où il commence l'opération de mise à jour des certificats. MSK le rétablit à la fin `ACTIVE` de la mise à jour. Lorsqu'un cluster est en cours d'opération de mise à jour des certificats, vous pouvez continuer à produire et à consommer des données, mais vous ne pouvez effectuer aucune opération de mise à jour sur celui-ci.
## Chiffrement Amazon MSK au repos
Amazon MSK s'intègre à [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/) (KMS) pour permettre le chiffrement transparent côté serveur. Amazon MSK chiffre toujours vos données au repos. Lorsque vous créez un cluster MSK, vous pouvez spécifier la AWS KMS key que vous souhaitez qu'Amazon MSK utilise pour chiffrer vos données au repos. Si vous ne spécifiez pas de clé KMS, Amazon MSK crée une [Clé gérée par AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) pour vous et l'utilise en votre nom. Pour plus d'informations sur les clés KMS, consultez [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) dans le *Guide du développeur AWS Key Management Service *.
## Chiffrement Amazon MSK en transit
Amazon MSK utilise TLS 1.2. Par défaut, il chiffre les données en transit entre les agents de votre cluster MSK. Vous pouvez remplacer cette valeur par défaut au moment de la création du cluster.
Pour la communication entre clients et brokers, vous devez spécifier l'un des trois paramètres suivants :
+ Autoriser uniquement les données chiffrées TLS. Il s’agit du paramètre par défaut.
+ Autoriser à la fois le texte brut, ainsi que les données chiffrées TLS.
+ Autoriser uniquement les données en texte brut.
Les courtiers Amazon MSK utilisent des AWS Certificate Manager certificats publics. Par conséquent, tout magasin fiable qui fait confiance à Amazon Trust Services approuve également les certificats des agents Amazon MSK.
Bien que nous vous recommandions d'activer le chiffrement en transit, celui-ci peut entraîner des charges supplémentaires d'UC et quelques millisecondes de latence. La plupart des cas d'utilisation ne sont toutefois pas sensibles à ces différences, cependant l'ampleur de l'impact dépend de la configuration du cluster, des clients et du profil d'utilisation.
# Commencez avec le chiffrement Amazon MSK
Lors de la création d'un cluster MSK, vous pouvez spécifier les paramètres de chiffrement au format JSON. Voici un exemple.
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:123456789012:key/abcdabcd-1234-abcd-1234-abcd123e8e8e"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
Pour `DataVolumeKMSKeyId`, vous pouvez spécifier une [clé gérée par le client](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) ou la Clé gérée par AWS pour MSK dans votre compte (`alias/aws/kafka`). Si vous ne le spécifiez pas`EncryptionAtRest`, Amazon MSK chiffre toujours vos données au repos sous le. Clé gérée par AWS Pour déterminer la clé utilisée par votre cluster, envoyez une requête `GET` ou invoquez l'opération d'API `DescribeCluster`.
Pour `EncryptionInTransit`, la valeur par défaut de `InCluster` est true, mais vous pouvez la définir sur false si vous ne voulez pas qu'Amazon MSK chiffre vos données au fur et à mesure qu'elles passent entre les agents.
Pour spécifier le mode de chiffrement des données en transit entre les clients et les brokers, définissez `ClientBroker` sur l'une des trois valeurs suivantes : `TLS`, `TLS_PLAINTEXT` ou `PLAINTEXT`.
**Topics**
+ [Spécifiez les paramètres de chiffrement lors de la création d'un cluster Amazon MSK](msk-working-with-encryption-cluster-create.md)
+ [Testez le chiffrement Amazon MSK TLS](msk-working-with-encryption-test-tls.md)
# Spécifiez les paramètres de chiffrement lors de la création d'un cluster Amazon MSK
Ce processus décrit comment spécifier les paramètres de chiffrement lors de la création d'un cluster Amazon MSK.
**Spécifier les paramètres de chiffrement lors de la création d'un cluster**
1. Enregistrez le contenu de l'exemple précédent dans un fichier et donnez au fichier le nom souhaité. Par exemple, appelez-le `encryption-settings.json`.
1. Exécutez la commande `create-cluster` et utilisez l'option `encryption-info` pour pointer vers le fichier dans lequel vous avez enregistré votre JSON de configuration. Voici un exemple. *\$1YOUR MSK VERSION\$1*Remplacez-le par une version qui correspond à la version du client Apache Kafka. Pour de plus amples informations sur la recherche de la version de votre cluster MSK, consultez [Déterminer la version de votre cluster MSK](create-topic.md#find-msk-cluster-version). Sachez que l'utilisation d'une version du client Apache Kafka différente de la version de votre cluster MSK peut entraîner la corruption, la perte et l'arrêt des données d'Apache Kafka.
```
aws kafka create-cluster --cluster-name "ExampleClusterName" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --kafka-version "{YOUR MSK VERSION}" --number-of-broker-nodes 3
```
Voici un exemple de réponse réussie après l'exécution de cette commande.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:123456789012:cluster/SecondTLSTest/abcdabcd-1234-abcd-1234-abcd123e8e8e",
"ClusterName": "ExampleClusterName",
"State": "CREATING"
}
```
# Testez le chiffrement Amazon MSK TLS
Ce processus décrit comment tester le chiffrement TLS sur Amazon MSK.
**Pour tester le chiffrement TLS**
1. Créez une machine client en suivant les instructions de [Étape 3 : Créer un ordinateur client](create-client-machine.md).
1. Installez Apache Kafka sur l'ordinateur client.
1. Dans cet exemple, nous utilisons le magasin fiable JVM pour parler au cluster MSK. Pour ce faire, créez d'abord un dossier nommé `/tmp` sur l'ordinateur client. Ensuite, accédez au dossier `bin` de l'installation d'Apache Kafka et exécutez la commande suivante. (Votre chemin JVM peut être différent.)
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. Dans le dossier `bin` de l'installation d'Apache Kafka sur l'ordinateur client, créez un fichier texte nommé `client.properties` avec le contenu suivant.
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka.client.truststore.jks
```
1. Exécutez la commande suivante sur une machine sur laquelle le est AWS CLI installé, en le *clusterARN* remplaçant par l'ARN de votre cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
Un résultat réussi ressemble à ce qui suit. Enregistrez ce résultat car vous en avez besoin pour l'étape suivante.
```
{
"BootstrapBrokerStringTls": "a-1.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-3.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-2.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123"
}
```
1. Exécutez la commande suivante, en la *BootstrapBrokerStringTls* remplaçant par l'un des points de terminaison du broker que vous avez obtenus à l'étape précédente.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringTls --producer.config client.properties --topic TLSTestTopic
```
1. Ouvrez une nouvelle fenêtre de commande et connectez-vous au même ordinateur client. Exécutez ensuite la commande suivante pour créer un consommateur de console.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringTls --consumer.config client.properties --topic TLSTestTopic
```
1. Dans la fenêtre du producteur, tapez un message texte suivi d'un retour et recherchez le même message dans la fenêtre du consommateur. Amazon MSK a chiffré ce message en transit.
Pour de plus amples informations sur la configuration des clients Apache Kafka pour qu'ils fonctionnent avec des données chiffrées, veuillez consulter [Configuration des clients Kafka](https://kafka.apache.org/documentation/#security_configclients).
# Utiliser Amazon MSK APIs avec des points de terminaison VPC d'interface
Vous pouvez utiliser un point de terminaison VPC d'interface, alimenté par AWS PrivateLink, pour empêcher le trafic entre votre Amazon VPC et Amazon APIs MSK de quitter le réseau Amazon. Les points de terminaison VPC d'interface ne nécessitent pas de passerelle Internet, de périphérique NAT, de connexion VPN ou de connexion Direct AWS Connect. [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)est une AWS technologie qui permet une communication privée entre les AWS services à l'aide d'une interface réseau élastique avec private IPs dans votre Amazon VPC. Pour plus d'informations, consultez [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) and [Interface VPC Endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint) ().AWS PrivateLink
Vos applications peuvent se connecter à Amazon MSK Provisioned et MSK Connect APIs à l'aide de. AWS PrivateLink Pour commencer, créez un point de terminaison VPC d'interface pour votre API Amazon MSK afin de démarrer le trafic en provenance et à destination de vos ressources Amazon VPC via le point de terminaison VPC d'interface. Les points de terminaison VPC d'interface compatibles FIPS sont disponibles pour les régions des États-Unis. Pour plus d'informations, consultez la section [Créer un point de terminaison d'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint).
Grâce à cette fonctionnalité, vos clients Apache Kafka peuvent récupérer dynamiquement les chaînes de connexion pour se connecter aux ressources MSK Provisioned ou MSK Connect sans passer par Internet pour récupérer les chaînes de connexion.
Lors de la création d'un point de terminaison VPC d'interface, choisissez l'un des points de terminaison de nom de service suivants :
**Pour MSK Provisioned :**
+ Les points de terminaison de nom de service suivants ne sont plus pris en charge pour les nouvelles connexions :
+ com.amazonaws.region.kafka
+ com.amazonaws.region.kafka-fips (compatible FIPS)
+ Le service de point de terminaison Dualstack prenant en charge les deux IPv4 et le IPv6 trafic est le suivant :
+ aws.api.region.kafka-api
+ aws.api.region. kafka-api-fips (compatible FIPS)
Pour configurer les points de terminaison à double pile, vous devez suivre les directives relatives aux points de terminaison [à double pile et FIPS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html).
Où est le nom de votre région. Choisissez ce nom de service pour fonctionner avec MSK Provisioned APIs compatible. Pour plus d'informations, consultez la section [Operations in the https://docs.aws.amazon.com/msk/](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html) *1.0/apireference/*.
**Pour MSK Connect :**
+ com.amazonaws.region.kafkaconnect
Où est le nom de votre région. Choisissez ce nom de service pour fonctionner avec MSK Connect APIs compatible. Pour plus d'informations, consultez [Actions](https://docs.aws.amazon.com/MSKC/latest/mskc/API_Operations.html) dans le manuel *Amazon MSK Connect API Reference*.
*Pour plus d'informations, y compris step-by-step les instructions pour créer un point de terminaison VPC d'interface, consultez la section [Création d'un point de terminaison d'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint) dans le AWS PrivateLink Guide.*
## Contrôlez l'accès aux points de terminaison VPC pour Amazon MSK Provisioned ou MSK Connect APIs
Les politiques de point de terminaison VPC vous permettent de contrôler l'accès en attachant une politique à un point de terminaison VPC ou en utilisant des champs supplémentaires dans une politique attachée à un utilisateur, un groupe ou un rôle IAM afin de limiter l'accès uniquement via le point de terminaison VPC spécifié. Utilisez l'exemple de politique approprié pour définir les autorisations d'accès pour le service MSK Provisioned ou MSK Connect.
Si vous n’attachez pas de stratégie quand vous créez un point de terminaison, Amazon VPC attache une stratégie par défaut pour vous qui autorise un accès total au service. Une politique de point de terminaison n’annule pas et ne remplace pas les politiques IAM ou les politiques spécifiques aux services. Il s’agit d’une politique distincte qui contrôle l’accès depuis le point de terminaison jusqu’au service spécifié.
*Pour plus d'informations, consultez la section [Contrôle de l'accès aux services avec des points de terminaison VPC dans le guide](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html).AWS PrivateLink *
------
#### [ MSK Provisioned — VPC policy example ]
**Accès en lecture seule**
Cet exemple de politique peut être attaché à un point de terminaison VPC. (Pour de plus amples informations, veuillez consulter Contrôle de l'accès aux ressources VPC Amazon). Il limite les actions à la seule liste et à la description des opérations via le point de terminaison VPC auquel il est attaché.
```
{
"Statement": [
{
"Sid": "MSKReadOnly",
"Principal": "*",
"Action": [
"kafka:List*",
"kafka:Describe*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
**MSK Provisioned — Exemple de politique de point de terminaison VPC**
Restreindre l'accès à un cluster MSK spécifique
Cet exemple de politique peut être attaché à un point de terminaison VPC. Il restreint l'accès à un cluster Kafka spécifique via le point de terminaison VPC auquel il est attaché.
```
{
"Statement": [
{
"Sid": "AccessToSpecificCluster",
"Principal": "*",
"Action": "kafka:*",
"Effect": "Allow",
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster"
}
]
}
```
------
#### [ MSK Connect — VPC endpoint policy example ]
**Répertorier les connecteurs et créer un nouveau connecteur**
Voici un exemple de politique de point de terminaison pour MSK Connect. Cette politique permet au rôle spécifié de répertorier les connecteurs et de créer un nouveau connecteur.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "MSKConnectPermissions",
"Effect": "Allow",
"Action": [
"kafkaconnect:ListConnectors",
"kafkaconnect:CreateConnector"
],
"Resource": "*",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/MyMSKConnectExecutionRole"
]
}
}
]
}
```
**MSK Connect — Exemple de politique de point de terminaison VPC**
Autorise uniquement les demandes provenant d'une adresse IP spécifique dans le VPC spécifié
L’exemple suivant montre une politique qui autorise uniquement les demandes provenant d’une adresse IP spécifiée dans le VPC spécifié. Les demandes provenant d’autres adresses IP échoueront.
```
{
"Statement": [
{
"Action": "kafkaconnect:*",
"Effect": "Allow",
"Principal": "*",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:VpcSourceIp": "192.0.2.123"
},
"StringEquals": {
"aws:SourceVpc": "vpc-555555555555"
}
}
}
]
}
```
------
# Authentification et autorisation pour Amazon MSK APIs
Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Des administrateurs IAM contrôlent les personnes qui peuvent être *authentifiées* (connectées) et *autorisées* (disposant d'autorisations) à utiliser des ressources Amazon MSK. IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires.
**Topics**
+ [Fonctionnement d'Amazon MSK avec IAM](security_iam_service-with-iam.md)
+ [Exemples de politiques basées sur l'identité d'Amazon MSK](security_iam_id-based-policy-examples.md)
+ [Rôles liés à un service pour Amazon MSK](using-service-linked-roles.md)
+ [AWS politiques gérées pour Amazon MSK](security-iam-awsmanpol.md)
+ [Résoudre les problèmes liés à l'identité et à l'accès à Amazon MSK](security_iam_troubleshoot.md)
# Fonctionnement d'Amazon MSK avec IAM
Avant d'utiliser IAM pour gérer l'accès à Amazon MSK, vous devez comprendre quelles sont les fonctionnalités IAM pouvant être utilisées dans cette situation. Pour obtenir une vue d'ensemble de la manière dont Amazon MSK et les autres AWS services fonctionnent avec IAM, consultez la section [AWS Services That Work with IAM dans le guide de l'utilisateur *IAM*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).
**Topics**
+ [Politiques basées sur l'identité Amazon MSK](security_iam_service-with-iam-id-based-policies.md)
+ [Politiques basées sur des ressources Amazon MSK](security_iam_service-with-iam-resource-based-policies.md)
+ [Autorisation basée sur les balises Amazon MSK](security_iam_service-with-iam-tags.md)
+ [Rôles IAM Amazon MSK](security_iam_service-with-iam-roles.md)
# Politiques basées sur l'identité Amazon MSK
Avec les politiques IAM basées sur l’identité, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Amazon MSK prend en charge des actions, des ressources et des clés de condition spécifiques. Pour en savoir plus sur tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*.
## Actions pour les politiques basées sur l'identité d'Amazon MSK
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées.
Les actions de politique dans Amazon MSK utilisent le préfixe suivant avant l'action : `kafka:`. Par exemple, pour accorder à une personne l'autorisation de décrire un cluster MSK avec l'opération d'API Amazon MSK `DescribeCluster`, vous incluez l'action `kafka:DescribeCluster` dans sa politique. Les déclarations de politique doivent inclure un élément `Action` ou `NotAction`. Amazon MSK définit son propre ensemble d'actions qui décrivent les tâches que vous pouvez effectuer avec ce service.
Veuillez noter que les actions politiques pour le sujet MSK APIs utilisent le `kafka-cluster` préfixe situé avant l'action, reportez-vous au. [Sémantique des politiques d'autorisation, des actions et des ressources de l'IAM](kafka-actions.md)
Pour spécifier plusieurs actions dans une seule déclaration, séparez-les par des virgules comme suit :
```
"Action": ["kafka:action1", "kafka:action2"]
```
Vous pouvez aussi spécifier plusieurs actions à l’aide de caractères génériques (\$1). Par exemple, pour spécifier toutes les actions qui commencent par le mot `Describe`, incluez l’action suivante :
```
"Action": "kafka:Describe*"
```
Pour afficher la liste des actions Amazon MSK, consultez [Actions, ressources et clés de condition pour Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonmanagedstreamingforapachekafka.html) dans le *Guide de l'utilisateur IAM*.
## Ressources pour les politiques basées sur l'identité d'Amazon MSK
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources.
```
"Resource": "*"
```
La ressource d'instance Amazon MSK possède l'ARN suivant :
```
arn:${Partition}:kafka:${Region}:${Account}:cluster/${ClusterName}/${UUID}
```
Pour plus d'informations sur le format de ARNs, consultez [Amazon Resource Names (ARNs) et AWS Service Namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
Par exemple, pour spécifier l’instance `CustomerMessages` dans votre instruction, utilisez l’ARN suivant :
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/CustomerMessages/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2"
```
Pour spécifier toutes les instances qui appartiennent à un compte spécifique, utilisez le caractère générique (\$1) :
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*"
```
Certaines actions Amazon MSK, telles que celles destinées à la création de ressources, ne peuvent pas être exécutées sur une ressource spécifique. Dans ces cas-là, vous devez utiliser le caractère générique (\$1).
```
"Resource": "*"
```
Pour spécifier plusieurs ressources dans une seule instruction, séparez-les ARNs par des virgules.
```
"Resource": ["resource1", "resource2"]
```
Pour consulter la liste des types de ressources Amazon MSK et leurs caractéristiques ARNs, consultez la section [Resources Defined by Amazon Managed Streaming for Apache](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-resources-for-iam-policies) Kafka Kafka dans *le guide de l'utilisateur IAM*. Pour savoir les actions avec lesquelles vous pouvez spécifier l'ARN de chaque ressource, consultez [Actions définies par Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions).
## Clés de condition pour les politiques basées sur l'identité d'Amazon MSK
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Condition` indique à quel moment les instructions s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
Amazon MSK définit son propre ensemble de clés de condition et est également compatible avec l'utilisation de certaines clés de condition globales. Pour voir toutes les clés de condition AWS globales, consultez la section [Clés contextuelles de condition AWS globale](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
Pour afficher une liste des clés de condition Amazon MSK, consultez [Clés de condition pour Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-policy-keys) dans le *Guide de l'utilisateur IAM*. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez [Actions définies par Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions).
## Exemples de politiques basées sur l'identité Amazon MSK
Pour voir des exemples de politiques Amazon MSK basées sur l'identité, consultez [Exemples de politiques basées sur l'identité d'Amazon MSK](security_iam_id-based-policy-examples.md).
# Politiques basées sur des ressources Amazon MSK
Amazon MSK prend en charge une politique de cluster (également appelée politique basée sur des ressources) à utiliser avec les clusters Amazon MSK. Vous pouvez utiliser une politique de cluster pour définir quels principaux IAM disposent d'autorisations intercompte pour configurer une connectivité privée avec votre cluster Amazon MSK. Lorsqu'elle est utilisée avec l'authentification du client IAM, vous pouvez également utiliser la politique de cluster pour définir de manière granulaire les autorisations de plan de données Kafka pour les clients qui se connectent.
La taille maximale prise en charge pour une politique de cluster est de 20 Ko.
Pour voir un exemple de configuration d'une politique de cluster, reportez-vous à [Étape 2 : attacher une politique de cluster au cluster MSK](mvpc-cluster-owner-action-policy.md).
# Autorisation basée sur les balises Amazon MSK
Vous pouvez attacher des balises aux clusters Amazon MSK. Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `kafka:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`. Pour plus d'informations sur le balisage des ressources Amazon MSK, consultez. [Marquer un cluster Amazon MSK](msk-tagging.md)
Vous ne pouvez contrôler l'accès au cluster qu'à l'aide de balises. Pour étiqueter des sujets et des groupes de consommateurs, vous devez ajouter une déclaration distincte dans vos politiques sans balises.
Pour voir un exemple de politique basée sur l'identité visant à limiter l'accès à un cluster en fonction des balises de ce cluster, consultez. [Accès aux clusters Amazon MSK à l'aide de balises](security_iam_id-based-policy-examples-view-widget-tags.md)
Vous pouvez utiliser des conditions dans votre politique basée sur l'identité pour contrôler l'accès aux ressources Amazon MSK en fonction des balises. L'exemple suivant montre une politique qui permet à un utilisateur de décrire le cluster, d'obtenir ses courtiers bootstrap, de répertorier ses nœuds de courtiers, de le mettre à jour et de le supprimer. Toutefois, cette politique n'accorde l'autorisation que si la balise de cluster `Owner` a la valeur de celle de cet utilisateur`username`. La deuxième déclaration de la politique suivante autorise l'accès aux rubriques du cluster. La première déclaration de cette politique n'autorise aucun accès aux rubriques.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/*"
]
}
]
}
```
------
# Rôles IAM Amazon MSK
Un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) est une entité au sein de votre compte Amazon Web Services qui dispose d'autorisations spécifiques.
## Utilisation d'informations d'identification temporaires avec Amazon MSK
Vous pouvez utiliser des informations d'identification temporaires pour vous connecter à l'aide de la fédération, endosser un rôle IAM ou encore pour endosser un rôle intercompte. Vous obtenez des informations d'identification de sécurité temporaires en appelant des opérations d' AWS STS API telles que [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)ou [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html).
Amazon MSK prend en charge l'utilisation d'informations d'identification temporaires.
## Rôles liés à un service
Les [rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) permettent aux services Amazon Web Services d'accéder à des ressources dans d'autres services pour effectuer une action en votre nom. Les rôles liés à un service s'affichent dans votre compte IAM et sont la propriété du service. Un administrateur peut consulter, mais ne peut pas modifier les autorisations concernant les rôles liés à un service.
Amazon MSK prend en charge les rôles liés à un service. Pour plus d'informations sur la création ou la gestion de rôles liés à un service dans Amazon MSK, consultez [Rôles liés à un service pour Amazon MSK](using-service-linked-roles.md).
# Exemples de politiques basées sur l'identité d'Amazon MSK
Par défaut, les utilisateurs et les rôles IAM ne sont pas autorisés à effectuer des actions d'API Amazon MSK. Un administrateur doit créer des politiques IAM autorisant les utilisateurs et les rôles à exécuter des opérations d’API spécifiques sur les ressources spécifiées dont ils ont besoin. Il doit ensuite attacher ces politiques aux utilisateurs ou aux groupes IAM ayant besoin de ces autorisations.
Pour savoir comment créer une stratégie IAM basée sur l'identité à l'aide de ces exemples de documents de stratégie JSON, veuillez consulter [Création de stratégies dans l'onglet JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) dans le *Guide de l'utilisateur IAM*.
**Topics**
+ [Bonnes pratiques en matière de politiques](security_iam_service-with-iam-policy-best-practices.md)
+ [Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Accès à un cluster Amazon MSK](security_iam_id-based-policy-examples-access-one-cluster.md)
+ [Accès aux clusters Amazon MSK à l'aide de balises](security_iam_id-based-policy-examples-view-widget-tags.md)
# Bonnes pratiques en matière de politiques
Les politiques basées sur l'identité déterminent si une personne peut créer, consulter ou supprimer des ressources Amazon MSK dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.
# Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations
Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or AWS .
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Accès à un cluster Amazon MSK
Dans cet exemple, vous souhaitez accorder à un utilisateur IAM de votre compte Amazon Web Services l'accès à l'un de vos clusters, `purchaseQueriesCluster`. Cette stratégie permet à l'utilisateur de décrire le cluster, d'obtenir ses brokers d'amorçage, de répertorier ses nœuds de broker et de le mettre à jour.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"UpdateCluster",
"Effect":"Allow",
"Action":[
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*"
],
"Resource":"arn:aws:kafka:us-east-1:012345678012:cluster/purchaseQueriesCluster/abcdefab-1234-abcd-5678-cdef0123ab01-2"
}
]
}
```
------
# Accès aux clusters Amazon MSK à l'aide de balises
Vous pouvez utiliser des conditions dans votre politique basée sur l'identité pour contrôler l'accès aux ressources Amazon MSK en fonction des balises. Cet exemple montre comment créer une stratégie qui permet à l'utilisateur de décrire le cluster, d'obtenir ses brokers d'amorçage, de répertorier ses nœuds de broker, de le mettre à jour et de le supprimer. Toutefois, l'autorisation est accordée uniquement si la balise de cluster `Owner` a la valeur du nom d'utilisateur de cet utilisateur.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:012345678012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
}
]
}
```
------
Vous pouvez rattacher cette politique aux utilisateurs IAM de votre compte. Si un utilisateur nommé `richard-roe` tente de mettre à jour un cluster MSK, le cluster doit être balisé `Owner=richard-roe` ou `owner=richard-roe`. Dans le cas contraire, l’utilisateur se voit refuser l'accès. La clé de condition d'étiquette `Owner` correspond à la fois à `Owner` et à `owner`, car les noms de clé de condition ne sont pas sensibles à la casse. Pour plus d'informations, veuillez consulter la rubrique [Éléments de stratégie JSON IAM : Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l'utilisateur IAM*.
# Rôles liés à un service pour Amazon MSK
Amazon MSK utilise des rôles liés à un [service Gestion des identités et des accès AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un rôle lié à un service est un type unique de rôle IAM qui est lié directement à Amazon MSK. Les rôles liés à un service sont prédéfinis par Amazon MSK et incluent toutes les autorisations requises par le service pour appeler d'autres AWS services en votre nom.
Un rôle lié à un service simplifie la configuration d'Amazon MSK, car vous n'avez pas besoin d'ajouter manuellement les autorisations requises. Amazon MSK définit les autorisations de ses rôles liés à un service. Sauf indication contraire, seul Amazon MSK peut assumer ses rôles. Les autorisations définies comprennent la politique de confiance et la politique d’autorisation. De plus, cette politique d’autorisation ne peut pas être attachée à une autre entité IAM.
Pour plus d'informations sur les autres services qui prennent en charge les rôles liés à un service, consultez [Services Amazon Web Services qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services où **Oui** figure dans la colonne **Rôle lié à un service**. Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service.
**Topics**
+ [Autorisations de rôles liés à un service](slr-permissions.md)
+ [Créer un rôle lié à un service](create-slr.md)
+ [Modification d’un rôle lié à un service](edit-slr.md)
+ [Régions prises en charge pour les rôles liés à un service](slr-regions.md)
# Autorisations du rôle lié à un service pour Amazon MSK
Amazon MSK utilise le rôle lié à un service nommé **AWSServiceRoleForKafka**. Amazon MSK utilise ce rôle pour accéder à vos ressources et effectuer des opérations telles que :
+ `*NetworkInterface` - créer et gérer des interfaces réseau dans le compte client qui rendent les agents de cluster accessibles aux clients dans le VPC du client.
+ `*VpcEndpoints`— gérez les points de terminaison VPC dans le compte client afin de rendre les courtiers de clusters accessibles aux clients utilisant le VPC du client. AWS PrivateLink Amazon MSK utilise des autorisations pour `DescribeVpcEndpoints`, `ModifyVpcEndpoint` et `DeleteVpcEndpoints`.
+ `secretsmanager`— gérez les informations d'identification des clients avec AWS Secrets Manager.
+ `GetCertificateAuthorityCertificate` - récupérer le certificat pour votre autorité de certification privée.
+ `*Ipv6Addresses`— attribuer et annuler l'attribution d' IPv6 adresses aux interfaces réseau du compte client afin de permettre la IPv6 connectivité des clusters MSK.
+ `ModifyNetworkInterfaceAttribute`— modifiez les attributs de l'interface réseau dans le compte client pour configurer IPv6 les paramètres de connectivité au cluster MSK.
Ce rôle lié à un service est attaché à la politique gérée suivante : `KafkaServiceRolePolicy`. Pour connaître les mises à jour de cette politique, consultez [KafkaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/KafkaServiceRolePolicy.html).
Le rôle lié à un service AWSServiceRoleForKafka approuve les services suivants pour endosser le rôle :
+ `kafka.amazonaws.com`
La politique d'autorisations liée au rôle permet à Amazon MSK de réaliser les actions suivantes au niveau des ressources.
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Pour en savoir plus, consultez [Service-Linked Role Permissions (autorisations du rôle lié à un service)](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l’utilisateur IAM*.
# Création d'un rôle lié à un service pour Amazon MSK
Vous n'avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous créez un cluster Amazon MSK dans l' AWS Management Console AWS API AWS CLI, Amazon MSK crée le rôle lié au service pour vous.
Si vous supprimez ce rôle lié à un service et que vous avez ensuite besoin de le recréer, vous pouvez utiliser la même procédure pour recréer le rôle dans votre compte. Lorsque vous créez un cluster Amazon MSK, Amazon MSK crée à nouveau automatiquement le rôle lié au service.
# Modifier un rôle lié à un service pour Amazon MSK
Amazon MSK ne vous autorise pas à modifier le rôle lié à un service AWSServiceRoleForKafka. Après avoir créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence à ce rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour en savoir plus, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *Guide de l’utilisateur IAM*.
# Régions prises en charge pour les rôles liés à un service Amazon MSK
Amazon MSK prend en charge l'utilisation des rôles liés à un service dans toutes les régions où le service est disponible. Pour plus d’informations, consultez [AWS Régions et points de terminaison](https://docs.aws.amazon.com/general/latest/gr/rande.html).
# AWS politiques gérées pour Amazon MSK
Une politique AWS gérée est une politique autonome créée et administrée par AWS. AWS les politiques gérées sont conçues pour fournir des autorisations pour de nombreux cas d'utilisation courants afin que vous puissiez commencer à attribuer des autorisations aux utilisateurs, aux groupes et aux rôles.
N'oubliez pas que les politiques AWS gérées peuvent ne pas accorder d'autorisations de moindre privilège pour vos cas d'utilisation spécifiques, car elles sont accessibles à tous les AWS clients. Nous vous recommandons de réduire encore les autorisations en définissant des [politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) qui sont propres à vos cas d’utilisation.
Vous ne pouvez pas modifier les autorisations définies dans les politiques AWS gérées. Si les autorisations définies dans une politique AWS gérée sont AWS mises à jour, la mise à jour affecte toutes les identités principales (utilisateurs, groupes et rôles) auxquelles la politique est attachée. AWS est le plus susceptible de mettre à jour une politique AWS gérée lorsqu'une nouvelle Service AWS est lancée ou lorsque de nouvelles opérations d'API sont disponibles pour les services existants.
Pour plus d’informations, consultez [Politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *Guide de l’utilisateur IAM*.
# AWS politique gérée : Amazon MSKFull Access
Cette politique accorde des autorisations administratives qui permettent à un principal d'accéder pleinement à toutes les actions Amazon MSK. Les autorisations définies dans cette politique sont regroupées comme suit :
+ Les autorisations Amazon MSK autorisent toutes les actions Amazon MSK.
+ **`Amazon EC2`autorisations** : dans cette politique, elles sont requises pour valider les ressources transmises dans une demande d'API. Cela permet de s'assurer qu'Amazon MSK est en mesure d'utiliser correctement les ressources avec un cluster. Les autres autorisations Amazon EC2 de cette politique permettent à Amazon MSK de créer les AWS ressources nécessaires pour vous permettre de vous connecter à vos clusters.
+ **`AWS KMS`autorisations** — sont utilisées lors des appels d'API pour valider les ressources transmises dans une demande. Elles sont nécessaires pour qu'Amazon MSK puisse utiliser la clé transmise avec le cluster Amazon MSK.
+ **`CloudWatch Logs, Amazon S3, and Amazon Data Firehose`autorisations** : elles sont nécessaires pour qu'Amazon MSK puisse garantir que les destinations de livraison des journaux sont accessibles et qu'elles sont valides pour l'utilisation des journaux des courtiers.
+ **`IAM`autorisations** : elles sont nécessaires pour qu'Amazon MSK puisse créer un rôle lié à un service dans votre compte et pour vous permettre de transmettre un rôle d'exécution de service à Amazon MSK.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"kafka:*",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeSecurityGroups",
"ec2:DescribeRouteTables",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcAttribute",
"kms:DescribeKey",
"kms:CreateGrant",
"logs:CreateLogDelivery",
"logs:GetLogDelivery",
"logs:UpdateLogDelivery",
"logs:DeleteLogDelivery",
"logs:ListLogDeliveries",
"logs:PutResourcePolicy",
"logs:DescribeResourcePolicies",
"logs:DescribeLogGroups",
"S3:GetBucketPolicy",
"firehose:TagDeliveryStream"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc/*",
"arn:*:ec2:*:*:subnet/*",
"arn:*:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc-endpoint/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/AWSMSKManaged": "true"
},
"StringLike": {
"aws:RequestTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateVpcEndpoint"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteVpcEndpoints"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AWSMSKManaged": "true"
},
"StringLike": {
"ec2:ResourceTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/delivery.logs.amazonaws.com/AWSServiceRoleForLogDelivery*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "delivery.logs.amazonaws.com"
}
}
}
]
}
```
------
# AWS politique gérée : Amazon MSKRead OnlyAccess
Cette politique accorde des autorisations en lecture seule qui permettent aux utilisateurs de consulter des informations dans Amazon MSK. Les principaux auxquels cette politique est attachée ne peuvent effectuer aucune mise à jour ou supprimer des ressources existantes, ni créer de nouvelles ressources Amazon MSK. Par exemple, les principaux disposant de ces autorisations peuvent consulter la liste des clusters et des configurations associés à leur compte, mais ne peuvent pas modifier la configuration ou les paramètres des clusters. Les autorisations définies dans cette politique sont regroupées comme suit :
+ **`Amazon MSK`autorisations** : vous permettent de répertorier les ressources Amazon MSK, de les décrire et d'obtenir des informations à leur sujet.
+ **`Amazon EC2`autorisations** : elles sont utilisées pour décrire le VPC Amazon, les sous-réseaux, les groupes de sécurité et ENIs les entités associées à un cluster.
+ **`AWS KMS`permission** — est utilisée pour décrire la clé associée au cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"kafka:Describe*",
"kafka:List*",
"kafka:Get*",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"kms:DescribeKey"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
# AWS politique gérée : KafkaServiceRolePolicy
Vous ne pouvez pas vous associer KafkaServiceRolePolicy à vos entités IAM. Cette politique est attachée à un rôle lié à un service qui permet à Amazon MSK d'effectuer des actions telles que la gestion des points de terminaison de VPC (connecteurs) sur les clusters MSK, la gestion des interfaces réseau et la gestion des informations d'identification du cluster avec AWS Secrets Manager. Pour de plus amples informations, veuillez consulter [Rôles liés à un service pour Amazon MSK](using-service-linked-roles.md).
Le tableau suivant décrit les mises à jour apportées à la politique KafkaServiceRolePolicy gérée depuis qu'Amazon MSK a commencé à suivre les modifications.
| Modifier | Description | Date |
| --- | --- | --- |
| [IPv6 prise en charge de la connectivité ajoutée KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy) — Mise à jour d'une politique existante | Amazon MSK a ajouté des autorisations KafkaServiceRolePolicy pour activer la IPv6 connectivité pour les clusters MSK. Ces autorisations permettent à Amazon MSK d'attribuer ou d'annuler l'attribution d' IPv6 adresses aux interfaces réseau et de modifier les attributs des interfaces réseau dans le compte client. | 17 novembre 2025 |
| [KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy) : mise à jour d’une politique existante | Amazon MSK a ajouté des autorisations pour prendre en charge la connectivité privée à plusieurs VPC. | 8 mars 2023 |
| Amazon MSK a commencé à assurer le suivi des modifications | Amazon MSK a commencé à suivre les modifications apportées aux politiques KafkaServiceRolePolicy gérées. | 8 mars 2023 |
# AWS politique gérée : AWSMSKReplicator ExecutionRole
La `AWSMSKReplicatorExecutionRole` politique accorde des autorisations au réplicateur Amazon MSK pour répliquer les données entre les clusters MSK. Les autorisations définies dans cette politique sont regroupées comme suit :
+ **`cluster`**— Accorde à Amazon MSK Replicator l'autorisation de se connecter au cluster à l'aide de l'authentification IAM. Accorde également les autorisations nécessaires pour décrire et modifier le cluster.
+ **`topic`**— Accorde à Amazon MSK Replicator les autorisations nécessaires pour décrire, créer et modifier un sujet, ainsi que pour modifier la configuration dynamique du sujet.
+ **`consumer group`**— Accorde à Amazon MSK Replicator l'autorisation de décrire et de modifier les groupes de consommateurs, de lire et d'écrire la date d'un cluster MSK et de supprimer les sujets internes créés par le réplicateur.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ClusterPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:DescribeCluster",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:*:*:cluster/*"
]
},
{
"Sid": "TopicPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:AlterCluster"
],
"Resource": [
"arn:aws:kafka:*:*:topic/*/*"
]
},
{
"Sid": "GroupPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:*:*:group/*/*"
]
}
]
}
```
------
# Amazon MSK met à jour les politiques AWS gérées
Consultez les informations relatives aux mises à jour des politiques AWS gérées pour Amazon MSK depuis que ce service a commencé à suivre ces modifications.
| Modifier | Description | Date |
| --- | --- | --- |
| [WriteDataIdempotently autorisation ajoutée à AWSMSKReplicator ExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md) — Mise à jour d'une politique existante | Amazon MSK a ajouté WriteDataIdempotently l'autorisation à la AWSMSKReplicator ExecutionRole politique pour prendre en charge la réplication des données entre les clusters MSK. | 12 mars 2024 |
| [AWSMSKReplicatorExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md) : nouvelle politique | Amazon MSK a ajouté une AWSMSKReplicator ExecutionRole politique pour prendre en charge Amazon MSK Replicator. | 4 décembre 2023 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) — Mise à jour d'une politique existante | Amazon MSK a ajouté des autorisations pour prendre en charge le réplicateur Amazon MSK. | 28 septembre 2023 |
| [KafkaServiceRolePolicy](security-iam-awsmanpol-KafkaServiceRolePolicy.md) : mise à jour d’une politique existante | Amazon MSK a ajouté des autorisations pour prendre en charge la connectivité privée à plusieurs VPC. | 8 mars 2023 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) — Mise à jour d'une politique existante | Amazon MSK a ajouté de nouvelles autorisations Amazon EC2 pour permettre la connexion à un cluster. | 30 novembre 2021 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) — Mise à jour d'une politique existante | Amazon MSK a ajouté une nouvelle autorisation lui permettant de décrire les tables de routage Amazon EC2. | 19 novembre 2021 |
| Amazon MSK a commencé à assurer le suivi des modifications | Amazon MSK a commencé à suivre les modifications apportées à ses politiques AWS gérées. | 19 novembre 2021 |
# Résoudre les problèmes liés à l'identité et à l'accès à Amazon MSK
Utilisez les informations suivantes pour identifier et résoudre les problèmes courants que vous pouvez rencontrer lorsque vous utilisez Amazon MSK et IAM.
**Topics**
+ [Je ne suis pas autorisé à effectuer une action dans Amazon MSK](#security_iam_troubleshoot-no-permissions)
## Je ne suis pas autorisé à effectuer une action dans Amazon MSK
S'il vous AWS Management Console indique que vous n'êtes pas autorisé à effectuer une action, vous devez contacter votre administrateur pour obtenir de l'aide. Votre administrateur est la personne qui vous a fourni vos informations de connexion.
L'exemple d'erreur suivant se produit lorsque l'utilisateur IAM `mateojackson` tente d'utiliser la console pour supprimer un cluster, mais ne dispose pas des autorisations `kafka:DeleteCluster`.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: kafka:DeleteCluster on resource: purchaseQueriesCluster
```
Dans ce cas, Mateo demande à son administrateur de mettre à jour ses politiques pour lui permettre d’accéder à la ressource `purchaseQueriesCluster` à l’aide de l’action `kafka:DeleteCluster`.
# Authentification et autorisation pour Apache Kafka APIs
Vous pouvez utiliser IAM pour authentifier les clients et autoriser ou refuser des actions Apache Kafka. Vous pouvez également utiliser le protocole TLS ou SASL/SCRAM pour authentifier les clients, et Apache Kafka ACLs pour autoriser ou refuser des actions.
Pour plus d'informations sur le contrôle des personnes autorisées à effectuer des [opérations Amazon MSK](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html) sur votre cluster, consultez [Authentification et autorisation pour Amazon MSK APIs](security-iam.md).
**Topics**
+ [Contrôle d'accès IAM](iam-access-control.md)
+ [Authentification client TLS mutuelle pour Amazon MSK](msk-authentication.md)
+ [Authentification des identifiants de connexion avec AWS Secrets Manager](msk-password.md)
+ [Apache Kafka ACLs](msk-acls.md)
# Contrôle d'accès IAM
Le contrôle d'accès IAM pour Amazon MSK vous permet de gérer à la fois l'authentification et l'autorisation pour votre cluster MSK. Cela élimine la nécessité d'utiliser un mécanisme unique pour l'authentification et un autre pour l'autorisation. Par exemple, lorsqu'un client tente d'écrire sur votre cluster, Amazon MSK utilise IAM pour vérifier si ce client est une identité authentifiée et s'il est autorisé à produire sur votre cluster.
Le contrôle d'accès IAM fonctionne pour les clients Java et non-Java, y compris les clients Kafka écrits en Python JavaScript, Go et .NET. Le contrôle d'accès IAM pour les clients non-Java est disponible pour les clusters MSK dotés de la version 2.7.1 ou supérieure de Kafka.
Pour rendre le contrôle d'accès IAM possible, Amazon MSK apporte des modifications mineures au code source d'Apache Kafka. Ces modifications n'entraîneront pas de différence notable dans votre expérience avec Apache Kafka. Amazon MSK journalise les événements d'accès afin que vous puissiez les contrôler.
Vous pouvez appeler l'ACL Apache Kafka APIs pour un cluster MSK qui utilise le contrôle d'accès IAM. Cependant, Apache Kafka ACLs n'a aucun effet sur l'autorisation des identités IAM. Vous devez utiliser des politiques IAM pour contrôler l'accès aux identités IAM.
**Considérations importantes**
Lorsque vous utilisez le contrôle d'accès IAM avec votre cluster MSK, gardez à l'esprit les considérations importantes suivantes :
Le contrôle d'accès IAM ne s'applique pas aux ZooKeeper nœuds Apache. Pour plus d'informations sur la manière de contrôler l'accès à ces nœuds, consultez [Contrôlez l'accès aux ZooKeeper nœuds Apache de votre cluster Amazon MSK](zookeeper-security.md).
Le paramètre Apache Kafka `allow.everyone.if.no.acl.found` n'a aucun effet si votre cluster utilise le contrôle d'accès IAM.
Vous pouvez appeler l'ACL Apache Kafka APIs pour un cluster MSK qui utilise le contrôle d'accès IAM. Cependant, Apache Kafka ACLs n'a aucun effet sur l'autorisation des identités IAM. Vous devez utiliser des politiques IAM pour contrôler l'accès aux identités IAM.
# Fonctionnement du contrôle d'accès IAM pour Amazon MSK
Pour utiliser le contrôle d'accès IAM pour Amazon MSK, effectuez les étapes suivantes, décrites en détail dans ces rubriques :
+ [Créez un cluster Amazon MSK qui utilise le contrôle d'accès IAM](create-iam-access-control-cluster-in-console.md)
+ [Configurer les clients pour le contrôle d'accès IAM](configure-clients-for-iam-access-control.md)
+ [Création de politiques d'autorisation pour le rôle IAM](create-iam-access-control-policies.md)
+ [Obtenez les agents d'amorçage pour le contrôle d'accès IAM](get-bootstrap-brokers-for-iam.md)
# Créez un cluster Amazon MSK qui utilise le contrôle d'accès IAM
Cette section explique comment vous pouvez utiliser l' AWS Management Console API ou le AWS CLI pour créer un cluster Amazon MSK qui utilise le contrôle d'accès IAM. Pour plus d'informations sur l'activation du contrôle d'accès IAM pour un cluster existant, consultez [Mettre à jour les paramètres de sécurité d'un cluster Amazon MSK](msk-update-security.md).
**Utilisez le AWS Management Console pour créer un cluster qui utilise le contrôle d'accès IAM**
1. Ouvrez la console Amazon MSK à l'adresse [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Choisissez **Créer un cluster**.
1. Choisissez **Créer un cluster avec des paramètres personnalisés**.
1. Dans la section **Authentification**, choisissez **Contrôle d'accès IAM**.
1. Suivez le reste du flux de travail pour créer un cluster.
**Utilisez l'API ou le AWS CLI pour créer un cluster qui utilise le contrôle d'accès IAM**
+ Pour créer un cluster avec le contrôle d'accès IAM activé, utilisez l'[CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)API ou la commande [create-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/create-cluster.html) CLI et transmettez le JSON suivant pour `ClientAuthentication` le paramètre :. `"ClientAuthentication": { "Sasl": { "Iam": { "Enabled": true } }`
# Configurer les clients pour le contrôle d'accès IAM
Pour permettre aux clients de communiquer avec un cluster MSK qui utilise le contrôle d’accès IAM, vous pouvez utiliser l’un des mécanismes suivants :
+ Configuration d'un client non Java à l'aide d'un mécanisme SASL\$1OAUTHBEARER
+ Configuration du client Java à l'aide d' SASL\$1OAUTHBEARERun mécanisme ou d' AWS\$1MSK\$1IAM un mécanisme
## Utiliser le SASL\$1OAUTHBEARER mécanisme pour configurer IAM
1. Modifiez votre fichier de configuration client.properties à l'aide de l'exemple de client Python Kafka suivant. Les modifications de configuration sont similaires dans les autres langages.
```
from kafka import KafkaProducer
from kafka.errors import KafkaError
from kafka.sasl.oauth import AbstractTokenProvider
import socket
import time
from aws_msk_iam_sasl_signer import MSKAuthTokenProvider
class MSKTokenProvider():
def token(self):
token, _ = MSKAuthTokenProvider.generate_auth_token('')
return token
tp = MSKTokenProvider()
producer = KafkaProducer(
bootstrap_servers='',
security_protocol='SASL_SSL',
sasl_mechanism='OAUTHBEARER',
sasl_oauth_token_provider=tp,
client_id=socket.gethostname(),
)
topic = ""
while True:
try:
inp=input(">")
producer.send(topic, inp.encode())
producer.flush()
print("Produced!")
except Exception:
print("Failed to send message:", e)
producer.close()
```
1. Téléchargez la bibliothèque d'assistance pour la langue de configuration que vous avez choisie et suivez les instructions de la section *Démarrage* de la page d'accueil de cette bibliothèque de langues.
+ JavaScript: [https://github.com/aws/aws-msk-iam-sasl-signer-js](https://github.com/aws/aws-msk-iam-sasl-signer-js#getting-started) \$1getting -started
+ Python : [https://github.com/aws/aws-msk-iam-sasl-signer-python](https://github.com/aws/aws-msk-iam-sasl-signer-python#get-started) \$1get -started
+ Go : [https://github.com/aws/aws-msk-iam-sasl-signer-go](https://github.com/aws/aws-msk-iam-sasl-signer-go#getting-started) \$1getting -started
+ .NET : [https://github.com/aws/aws-msk-iam-sasl-signer-net](https://github.com/aws/aws-msk-iam-sasl-signer-net#getting-started) \$1getting -démarré
+ JAVA : le SASL\$1OAUTHBEARER support de Java est disponible via le fichier [https://github.com/aws/aws-msk-iam-auth/releases](https://github.com/aws/aws-msk-iam-auth/releases)jar
## Utiliser le AWS\$1MSK\$1IAM mécanisme personnalisé MSK pour configurer IAM
1. Ajoutez ce qui suit dans le fichier `client.properties`. **Remplacez-le par le chemin complet vers le fichier Trust Store sur le client.
**Note**
Si vous ne souhaitez pas utiliser un certificat spécifique, vous pouvez supprimer `ssl.truststore.location=` de votre fichier `client.properties`. Si vous ne spécifiez aucune valeur pour `ssl.truststore.location`, le processus Java utilise le certificat par défaut.
```
ssl.truststore.location=
security.protocol=SASL_SSL
sasl.mechanism=AWS_MSK_IAM
sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required;
sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler
```
Pour utiliser un profil nommé que vous avez créé pour les AWS informations d'identification, `awsProfileName="your profile name";` incluez-le dans votre fichier de configuration client. Pour plus d'informations sur les profils nommés, consultez la section [Profils nommés](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html) dans la AWS CLI documentation.
1. Téléchargez le dernier fichier [aws-msk-iam-auth](https://github.com/aws/aws-msk-iam-auth/releases)JAR stable et placez-le dans le chemin de classe. Si vous utilisez Maven, ajoutez la dépendance suivante, en ajustant le numéro de version selon les besoins :
```
software.amazon.msk
aws-msk-iam-auth
1.0.0
```
Le plug-in client Amazon MSK est open source sous la licence Apache 2.0.
# Création de politiques d'autorisation pour le rôle IAM
Attachez une politique d'autorisation au rôle IAM qui correspond au client. Dans une politique d'autorisation, vous spécifiez les actions à autoriser ou à refuser pour le rôle. Si votre client utilise une instance Amazon EC2, associez la politique d'autorisation au rôle IAM pour cette instance Amazon EC2. Vous pouvez également configurer votre client pour qu'il utilise un profil nommé, puis associer la politique d'autorisation au rôle de ce profil nommé. [Configurer les clients pour le contrôle d'accès IAM](configure-clients-for-iam-access-control.md) décrit comment configurer un client pour utiliser un profil nommé.
Pour plus d'informations sur la création d'une politique IAM, consultez [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html).
Voici un exemple de politique d'autorisation pour un cluster nommé MyTestCluster. Pour comprendre la sémantique des éléments `Action` et `Resource`, consultez [Sémantique des politiques d'autorisation, des actions et des ressources de l'IAM](kafka-actions.md).
**Important**
Les modifications que vous apportez à une politique IAM sont reflétées dans l'IAM APIs et immédiatement. AWS CLI Cependant, la modification de la politique peut prendre un certain temps avant d'être effective. Dans la plupart des cas, les modifications de politique prennent effet en moins d'une minute. Les conditions du réseau peuvent parfois augmenter le délai.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster"
],
"Resource": [
"arn:aws:kafka:us-east-1:111122223333:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/*"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:group/MyTestCluster/*"
]
}
]
}
```
------
Pour savoir comment créer une politique avec des éléments d'action correspondant aux cas d'utilisation courants d'Apache Kafka, tels que la production et la consommation de données, consultez [Cas d'utilisation courants de la politique d'autorisation des clients](iam-access-control-use-cases.md).
[Pour les versions 2.8.0 et supérieures de Kafka, l'**WriteDataIdempotently**autorisation est obsolète (KIP-679).](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default) Par défaut, `enable.idempotence = true` est défini. Par conséquent, pour les versions 2.8.0 et supérieures de Kafka, IAM n'offre pas les mêmes fonctionnalités que Kafka. ACLs Il n'est pas possible d'accéder `WriteDataIdempotently` à un sujet en fournissant uniquement `WriteData` l'accès à ce sujet. Cela n'affecte pas le cas lorsqu'il `WriteData` est fourni à **TOUS les** sujets. Dans ce cas, `WriteDataIdempotently` est autorisé. Cela est dû à des différences dans la mise en œuvre de la logique IAM et dans la manière dont les Kafka ACLs sont implémentés. De plus, écrire sur un sujet de manière idiote nécessite également un accès à. `transactional-ids`
Pour contourner ce problème, nous vous recommandons d'utiliser une politique similaire à la suivante.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/TestTopic",
"arn:aws:kafka:us-east-1:123456789012:transactional-id/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*"
]
}
]
}
```
------
Dans ce cas, `WriteData` autorise les écritures vers la `TestTopic`, pendant que `WriteDataIdempotently` autorise les écritures idempotentes sur le cluster. Cette politique ajoute également l'accès aux `transactional-id` ressources qui seront nécessaires.
Comme il `WriteDataIdempotently` s'agit d'une autorisation au niveau du cluster, vous ne pouvez pas l'utiliser au niveau du sujet. Si elle `WriteDataIdempotently` est limitée au niveau du sujet, cette politique ne fonctionnera pas.
# Obtenez les agents d'amorçage pour le contrôle d'accès IAM
Consultez [Obtenez les courtiers bootstrap pour un cluster Amazon MSK](msk-get-bootstrap-brokers.md).
# Sémantique des politiques d'autorisation, des actions et des ressources de l'IAM
**Note**
Pour les clusters exécutant Apache Kafka version 3.8 ou ultérieure, le contrôle d'accès IAM prend en charge l' WriteTxnMarkers API pour mettre fin aux transactions. Pour les clusters exécutant des versions de Kafka antérieures à 3.8, le contrôle d'accès IAM ne prend pas en charge les actions internes du cluster, notamment. WriteTxnMarkers Pour ces versions antérieures, pour mettre fin aux transactions, utilisez l'authentification SCRAM ou mTLS avec une authentification appropriée ACLs au lieu de l'authentification IAM.
Cette section explique la sémantique des éléments d'action et de ressource que vous pouvez utiliser dans une politique d'autorisation IAM. Pour un exemple de politique, consultez [Création de politiques d'autorisation pour le rôle IAM](create-iam-access-control-policies.md).
## Actions relatives à la politique d'autorisation
Le tableau suivant répertorie les actions que vous pouvez inclure dans une politique d'autorisation lorsque vous utilisez le contrôle d'accès IAM pour Amazon MSK. Lorsque vous incluez dans votre politique d'autorisation une action de la colonne *Action* du tableau, vous devez également inclure les actions correspondantes de la colonne *Actions requises*.
| Action | Description | Actions requises | Ressources requises | Applicable aux clusters sans serveur |
| --- | --- | --- | --- | --- |
| kafka-cluster:Connect | Octroie l'autorisation de se connecter et de s'authentifier à un cluster. | Aucune | cluster | Oui |
| kafka-cluster:DescribeCluster | Octroie l'autorisation de décrire divers aspects du cluster, équivalent à l'ACL DESCRIBE CLUSTER d'Apache Kafka. | `kafka-cluster:Connect` | cluster | Oui |
| kafka-cluster:AlterCluster | Octroi l'autorisation de modifier divers aspects du cluster, équivalent à l'ACL ALTER CLUSTER d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeCluster` | cluster | Non |
| kafka-cluster:DescribeClusterDynamicConfiguration | Octroie l'autorisation de décrire la configuration dynamique d'un cluster, équivalent à l'ACL DESCRIBE\$1CONFIGS CLUSTER d'Apache Kafka. | `kafka-cluster:Connect` | cluster | Non |
| kafka-cluster:AlterClusterDynamicConfiguration | Octroie l'autorisation de modifier la configuration dynamique d'un cluster, équivalente à l'ACL ALTER\$1CONFIGS CLUSTER d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` | cluster | Non |
| kafka-cluster:WriteDataIdempotently | Octroie l'autorisation d'écrire des données de manière idempotente dans un cluster, équivalent à l'ACL IDEMPOTENT\$1WRITE CLUSTER d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:WriteData` | cluster | Oui |
| kafka-cluster:CreateTopic | Accorde l'autorisation de créer des sujets sur un cluster, ce qui est équivalent à l' CLUSTER/TOPIC ACL CREATE d'Apache Kafka. | `kafka-cluster:Connect` | topic | Oui |
| kafka-cluster:DescribeTopic | Octroie l'autorisation de décrire des rubriques dans un cluster, équivalent à l'ACL DESCRIBE TOPIC d'Apache Kafka. | `kafka-cluster:Connect` | topic | Oui |
| kafka-cluster:AlterTopic | Octroie l'autorisation de modifier des rubriques dans un cluster, équivalent à l'ACL ALTER TOPIC d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topic | Oui |
| kafka-cluster:DeleteTopic | Octroie l'autorisation de supprimer des rubriques dans un cluster, équivalent à l'ACL DELETE TOPIC d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topic | Oui |
| kafka-cluster:DescribeTopicDynamicConfiguration | Octroie l'autorisation de décrire la configuration dynamique des rubriques dans un cluster, équivalent à l'ACL DESCRIBE\$1CONFIGS TOPIC d'Apache Kafka. | `kafka-cluster:Connect` | topic | Oui |
| kafka-cluster:AlterTopicDynamicConfiguration | Octroie l'autorisation de modifier la configuration dynamique des rubriques dans un cluster, équivalent à l'ACL ALTER\$1CONFIGS TOPIC d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` | topic | Oui |
| kafka-cluster:ReadData | Octroie l'autorisation de lire des données provenant de rubriques dans un cluster, équivalent à l'ACL READ TOPIC d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterGroup` | topic | Oui |
| kafka-cluster:WriteData | Autorise l'écriture des données dans les rubriques d'un cluster, équivalent à l'ACL WRITE TOPIC d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topic | Oui |
| kafka-cluster:DescribeGroup | Octroie l'autorisation de décrire des groupes dans un cluster, équivalent à l'ACL DESCRIBE GROUP d'Apache Kafka. | `kafka-cluster:Connect` | groupe | Oui |
| kafka-cluster:AlterGroup | Octroie l'autorisation de rejoindre des groupes dans un cluster, équivalent à l'ACL READ GROUP d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | groupe | Oui |
| kafka-cluster:DeleteGroup | Octroie l'autorisation de supprimer des groupes d'un cluster, équivalent à l'ACL DELETE GROUP d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | groupe | Oui |
| kafka-cluster:DescribeTransactionalId | Accorde l'autorisation de décrire les transactions IDs sur un cluster, ce qui est équivalent à l'ACL DESCRIBE TRANSACTIONAL\$1ID d'Apache Kafka. | `kafka-cluster:Connect` | transactional-id | Oui |
| kafka-cluster:AlterTransactionalId | Accorde l'autorisation de modifier les transactions IDs sur un cluster, ce qui est équivalent à l'ACL WRITE TRANSACTIONAL\$1ID d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:WriteData` | transactional-id | Oui |
Vous pouvez utiliser le caractère générique astérisque (\$1) autant de fois que vous le souhaitez dans une action après deux points. Voici quelques exemples.
+ `kafka-cluster:*Topic` représente `kafka-cluster:CreateTopic`, `kafka-cluster:DescribeTopic`, `kafka-cluster:AlterTopic` et `kafka-cluster:DeleteTopic`. Cela n'inclut pas `kafka-cluster:DescribeTopicDynamicConfiguration` ou `kafka-cluster:AlterTopicDynamicConfiguration`.
+ `kafka-cluster:*` représente toutes les autorisations.
## Ressources relatives aux politiques d'autorisation
Le tableau suivant montre les quatre types de ressources que vous pouvez utiliser dans une politique d'autorisation lorsque vous utilisez le contrôle d'accès IAM pour Amazon MSK. Vous pouvez obtenir le nom de ressource Amazon (ARN) du cluster à partir du AWS Management Console ou en utilisant l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)API ou la commande [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html) AWS CLI . Vous pouvez ensuite utiliser l'ARN du cluster pour créer un identifiant ARNs de sujet, de groupe et de transaction. Pour spécifier une ressource dans une politique d'autorisation, utilisez l'ARN de cette ressource.
| Ressource | Format ARN |
| --- | --- |
| Cluster | arn:aws:kafka : ::cluster//regionaccount-idcluster-namecluster-uuid |
| Rubrique | arn:aws:kafka : ::topic//regionaccount-idcluster-namecluster-uuidtopic-name |
| Groupe | arn:aws:kafka : :group///regionaccount-idcluster-namecluster-uuidgroup-name |
| ID transactionnel | arn:aws:kafka : :transactional-id//regionaccount-idcluster-namecluster-uuidtransactional-id |
Vous pouvez utiliser le caractère générique astérisque (\$1) autant de fois que vous le souhaitez dans la partie de l'ARN située après `:cluster/`, `:topic/`, `:group/` et `:transactional-id/`. Les exemples suivants illustrent la manière dont vous pouvez utiliser le caractère générique astérisque (\$1) pour faire référence à plusieurs ressources :
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/*`: tous les sujets d'un cluster nommé MyTestCluster, quel que soit l'UUID du cluster.
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*_test`: toutes les rubriques dont le nom se termine par « \$1test » dans le cluster dont le nom est MyTestCluster et dont l'UUID est abcd1234-0123-abcd-5678-1234abcd-1.
+ `arn:aws:kafka:us-east-1:0123456789012:transactional-id/MyTestCluster/*/5555abcd-1111-abcd-1234-abcd1234-1`: toutes les transactions dont l'ID transactionnel est 5555abcd-1111-abcd-1234-abcd1234-1, dans toutes les incarnations d'un cluster nommé dans votre compte. MyTestCluster Cela signifie que si vous créez un cluster nommé MyTestCluster, que vous le supprimez, puis que vous créez un autre cluster portant le même nom, vous pouvez utiliser cet ARN de ressource pour représenter le même identifiant de transaction sur les deux clusters. Cependant, le cluster supprimé n'est pas accessible.
# Cas d'utilisation courants de la politique d'autorisation des clients
La première colonne du tableau suivant présente certains cas d'utilisation courants. Pour autoriser un client à exécuter un cas d'utilisation donné, incluez les actions requises pour ce cas d'utilisation dans la politique d'autorisation du client et définissez `Effect` sur `Allow`.
Pour plus d'informations sur toutes les actions faisant partie du contrôle d'accès IAM pour Amazon MSK, consultez [Sémantique des politiques d'autorisation, des actions et des ressources de l'IAM](kafka-actions.md).
**Note**
Les actions sont refusées par défaut. Vous devez autoriser explicitement chaque action que vous souhaitez autoriser le client à effectuer.
****
| Cas d’utilisation | Actions requises |
| --- | --- |
| Admin | `kafka-cluster:*` |
| Création d’une rubrique | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` |
| Produire des données | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` |
| Consommer des données | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeGroup` `kafka-cluster:AlterGroup` `kafka-cluster:ReadData` |
| Produire des données de manière idempotente | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:WriteDataIdempotently` |
| Produire des données de manière transactionnelle | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:AlterTransactionalId` |
| Décrire la configuration d'un cluster | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` |
| Mettre à jour la configuration d'un cluster | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` `kafka-cluster:AlterClusterDynamicConfiguration` |
| Décrire la configuration d'une rubrique | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` |
| Mettre à jour la configuration d'une rubrique | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` `kafka-cluster:AlterTopicDynamicConfiguration` |
| Modifier une rubrique | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` |
# Authentification client TLS mutuelle pour Amazon MSK
Vous pouvez activer l'authentification client avec TLS pour les connexions entre vos applications et vos courtiers Amazon MSK. Pour utiliser l'authentification client, vous avez besoin d'une Autorité de certification privée AWS. Ils Autorité de certification privée AWS peuvent se trouver dans le même compte Compte AWS que celui de votre cluster ou dans un autre compte. Pour plus d'informations sur Autorité de certification privée AWS s, voir [Création et gestion d'un Autorité de certification privée AWS](https://docs.aws.amazon.com/acm-pca/latest/userguide/create-CA.html).
Amazon MSK ne prend pas en charge les listes de révocation de certificats ()CRLs. Pour contrôler l'accès aux rubriques de votre cluster ou bloquer les certificats compromis, utilisez Apache Kafka ACLs et les groupes AWS de sécurité. Pour plus d'informations sur l'utilisation d'Apache Kafka ACLs, consultez[Apache Kafka ACLs](msk-acls.md).
**Topics**
+ [Créez un cluster Amazon MSK qui prend en charge l'authentification des clients](msk-authentication-cluster.md)
+ [Configurer un client pour qu'il utilise l'authentification](msk-authentication-client.md)
+ [Produire et consommer des messages à l'aide de l'authentification](msk-authentication-messages.md)
# Créez un cluster Amazon MSK qui prend en charge l'authentification des clients
Cette procédure explique comment activer l'authentification du client à l'aide d'un Autorité de certification privée AWS.
**Note**
Nous vous recommandons vivement d'utiliser le protocole indépendant Autorité de certification privée AWS pour chaque cluster MSK lorsque vous utilisez le protocole TLS mutuel pour contrôler l'accès. Cela garantira que les certificats TLS signés par PCAs ne s'authentifient qu'auprès d'un seul cluster MSK.
1. Créez un fichier nommé `clientauthinfo.json` avec les contenus suivants. *Private-CA-ARN*Remplacez-le par l'ARN de votre PCA.
```
{
"Tls": {
"CertificateAuthorityArnList": ["Private-CA-ARN"]
}
}
```
1. Créez un fichier nommé `brokernodegroupinfo.json` comme décrit à la section [Créez un cluster Amazon MSK provisionné à l'aide du AWS CLI](create-cluster-cli.md).
1. L'authentification du client nécessite également l'activation du chiffrement lors du transit entre les clients et les brokers. Créez un fichier nommé `encryptioninfo.json` avec les contenus suivants. *KMS-Key-ARN*Remplacez-le par l'ARN de votre clé KMS. Vous pouvez définir `ClientBroker` sur `TLS` ou `TLS_PLAINTEXT`.
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "KMS-Key-ARN"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
iPour de plus amples informations sur le chiffrement, veuillez consulter [Chiffrement Amazon MSK](msk-encryption.md).
1. Sur une machine sur laquelle vous l'avez AWS CLI installé, exécutez la commande suivante pour créer un cluster sur lequel l'authentification et le chiffrement en transit sont activés. Enregistrez l'ARN de cluster fourni dans la réponse.
```
aws kafka create-cluster --cluster-name "AuthenticationTest" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --client-authentication file://clientauthinfo.json --kafka-version "{YOUR KAFKA VERSION}" --number-of-broker-nodes 3
```
# Configurer un client pour qu'il utilise l'authentification
Ce processus décrit comment configurer une instance Amazon EC2 à utiliser en tant que client pour utiliser l'authentification.
Ce processus décrit comment produire et consommer des messages à l'aide de l'authentification en créant une machine cliente, en créant un sujet et en configurant les paramètres de sécurité requis.
1. Créez une instance Amazon EC2 à utiliser en tant qu'ordinateur client. Pour plus de simplicité, créez cette instance dans le même VPC que celui utilisé pour le cluster. Consultez [Étape 3 : Créer un ordinateur client](create-client-machine.md) pour un exemple de création d'une machine client.
1. Créer une rubrique. Pour obtenir un exemple, consultez les instructions dans [Étape 4 : créer une rubrique dans le cluster Amazon MSK](create-topic.md).
1. Sur une machine sur laquelle vous l'avez AWS CLI installé, exécutez la commande suivante pour obtenir les courtiers bootstrap du cluster. *Cluster-ARN*Remplacez-le par l'ARN de votre cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn Cluster-ARN
```
Enregistrez la chaîne associée à `BootstrapBrokerStringTls` dans la réponse.
1. Sur votre ordinateur client, exécutez la commande suivante pour utiliser le magasin de confiance JVM pour créer votre magasin de confiance client. Si votre chemin JVM est différent, ajustez la commande en conséquence.
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts kafka.client.truststore.jks
```
1. Sur votre ordinateur client, exécutez la commande suivante pour créer une clé privée pour votre client. Remplacez *Distinguished-Name**Example-Alias*,*Your-Store-Pass*, et *Your-Key-Pass* par les chaînes de votre choix.
```
keytool -genkey -keystore kafka.client.keystore.jks -validity 300 -storepass Your-Store-Pass -keypass Your-Key-Pass -dname "CN=Distinguished-Name" -alias Example-Alias -storetype pkcs12 -keyalg rsa
```
1. Sur votre ordinateur client, exécutez la commande suivante pour créer une demande de certificat avec la clé privée que vous avez créée à l'étape précédente.
```
keytool -keystore kafka.client.keystore.jks -certreq -file client-cert-sign-request -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. Ouvrez le fichier `client-cert-sign-request` et assurez-vous qu'il commence par `-----BEGIN CERTIFICATE REQUEST-----` et se termine par `-----END CERTIFICATE REQUEST-----`. Si elle commence par `-----BEGIN NEW CERTIFICATE REQUEST-----`, supprimez le mot `NEW` (et l'espace unique qui le suit) du début et de la fin du fichier.
1. Sur une machine sur laquelle vous l'avez AWS CLI installé, exécutez la commande suivante pour signer votre demande de certificat. *Private-CA-ARN*Remplacez-le par l'ARN de votre PCA. Vous pouvez modifier la valeur de validité si vous le souhaitez. Ici, nous utilisons 300 comme exemple.
```
aws acm-pca issue-certificate --certificate-authority-arn Private-CA-ARN --csr fileb://client-cert-sign-request --signing-algorithm "SHA256WITHRSA" --validity Value=300,Type="DAYS"
```
Enregistrez l'ARN de certificat fourni dans la réponse.
**Note**
Pour récupérer votre certificat client, utilisez la commande `acm-pca get-certificate` et spécifiez l'ARN de votre certificat. Pour plus d'informations, consultez [get-certificate](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm-pca/get-certificate.html) dans la *Référence des commandes AWS CLI *.
1. Exécutez la commande suivante pour obtenir le certificat qui Autorité de certification privée AWS a été signé pour vous. *Certificate-ARN*Remplacez-le par l'ARN que vous avez obtenu à partir de la réponse à la commande précédente.
```
aws acm-pca get-certificate --certificate-authority-arn Private-CA-ARN --certificate-arn Certificate-ARN
```
1. À partir du résultat JSON de l'exécution de la commande précédente, copiez les chaînes associées à `Certificate` et `CertificateChain`. Collez ces deux chaînes dans un nouveau fichier nommé signed-certificate-from-acm. Collez la chaîne associée à `Certificate` en premier, suivie de la chaîne associée à `CertificateChain`. Remplacez les caractères `\n` par de nouvelles lignes. Voici la structure du fichier après avoir collé le certificat et la chaîne de certificats.
```
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
1. Exécutez la commande suivante sur l’ordinateur client pour ajouter ce certificat à votre magasin de clés afin que vous puissiez le présenter lorsque vous parlez aux agents MSK.
```
keytool -keystore kafka.client.keystore.jks -import -file signed-certificate-from-acm -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. Créez un fichier nommé `client.properties` avec les contenus suivants. Ajustez les emplacements du magasin de confiance et du magasin de clés aux chemins d'accès où vous avez enregistré `kafka.client.truststore.jks`. Remplacez les *\$1YOUR KAFKA VERSION\$1* espaces réservés par la version de votre client Kafka.
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.truststore.jks
ssl.keystore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.keystore.jks
ssl.keystore.password=Your-Store-Pass
ssl.key.password=Your-Key-Pass
```
# Produire et consommer des messages à l'aide de l'authentification
Ce processus décrit comment produire et consommer des messages à l'aide de l'authentification.
1. Exécutez la commande suivante pour créer une rubrique. Le fichier nommé `client.properties` est celui que vous avez créé lors de la procédure précédente.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBroker-String --replication-factor 3 --partitions 1 --topic ExampleTopic --command-config client.properties
```
1. Exécutez la commande suivante pour démarrer un producteur de console. Le fichier nommé `client.properties` est celui que vous avez créé lors de la procédure précédente.
```
/bin/kafka-console-producer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --producer.config client.properties
```
1. Dans une nouvelle fenêtre de commande sur votre ordinateur client, exécutez la commande suivante pour démarrer un consommateur de console.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --consumer.config client.properties
```
1. Tapez des messages dans la fenêtre du producteur et regardez-les apparaître dans la fenêtre du consommateur.
# Authentification des identifiants de connexion avec AWS Secrets Manager
Vous pouvez contrôler l'accès à vos clusters Amazon MSK à l'aide d'informations de connexion stockées et sécurisées à l'aide de AWS Secrets Manager. Le stockage des informations d'identification des utilisateurs dans Secrets Manager réduit les coûts liés à l'authentification du cluster, comme l'audit, la mise à jour et la rotation des informations d'identification. Secrets Manager vous permet également de partager les informations d'identification des utilisateurs entre les clusters.
Après avoir associé un secret à un cluster MSK, MSK synchronise régulièrement les données d'identification.
**Topics**
+ [Comment fonctionne l'authentification des informations de connexion](msk-password-howitworks.md)
+ [Configurer SASL/SCRAM l'authentification pour un cluster Amazon MSK](msk-password-tutorial.md)
+ [Utilisation des utilisateurs](msk-password-users.md)
+ [Limitations liées à l'utilisation des secrets SCRAM](msk-password-limitations.md)
# Comment fonctionne l'authentification des informations de connexion
L'authentification des informations de connexion pour Amazon MSK utilise l'authentification SASL/SCRAM (Simple Authentication and Security Layer/Salted Challenge Response Mechanism). Pour configurer l'authentification des informations d'identification de connexion pour un cluster, vous devez créer une ressource secrète dans [AWS Secrets Manager](https://docs.aws.amazon.com//secretsmanager/?id=docs_gateway) et associer les informations d'identification de connexion à ce secret.
L'authentification SASL/SCRAM est définie dans [RFC 5802.](https://tools.ietf.org/html/rfc5802) SCRAM utilise des algorithmes de hachage sécurisés et ne transmet pas d'informations d'identification de connexion en texte brut entre le client et le serveur.
**Note**
Lorsque vous configurez SASL/SCRAM l'authentification pour votre cluster, Amazon MSK active le chiffrement TLS pour tout le trafic entre les clients et les courtiers.
# Configurer SASL/SCRAM l'authentification pour un cluster Amazon MSK
Pour configurer un secret dans AWS Secrets Manager, suivez le didacticiel de [création et de récupération d'un secret figurant](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) dans le [guide de l'utilisateur de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html).
Tenez compte des exigences suivantes lors de la création d'un secret pour un cluster Amazon MSK :
+ Choisissez **Autre type de secrets (p. ex. clé d'API)** pour le type de secret.
+ Votre nom secret doit commencer par le préfixe **AmazonMSK\$1**.
+ Vous devez soit utiliser une AWS KMS clé personnalisée existante, soit créer une nouvelle AWS KMS clé personnalisée pour votre secret. Secrets Manager utilise la AWS KMS clé par défaut pour un secret.
**Important**
Un secret créé avec la AWS KMS clé par défaut ne peut pas être utilisé avec un cluster Amazon MSK.
+ Vos informations d'identification de connexion doivent être au format suivant pour saisir des paires clé-valeur à l'aide de l'option **Texte brut**.
```
{
"username": "alice",
"password": "alice-secret"
}
```
+ Enregistrez la valeur ARN (Amazon Resource Name) de votre secret.
+
**Important**
Vous ne pouvez pas associer un secret de Secrets Manager à un cluster qui dépasse les limites décrites dans [Dimensionnez correctement votre cluster : nombre de partitions par courtier standard](bestpractices.md#partitions-per-broker).
+ Si vous utilisez le AWS CLI pour créer le secret, spécifiez un ID de clé ou un ARN pour le `kms-key-id` paramètre. Ne spécifiez pas d'alias.
+ Pour associer le secret à votre cluster, utilisez soit la console Amazon MSK, soit l'[ BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret)opération.
**Important**
Lorsque vous associez un secret à un cluster, Amazon MSK associe une politique de ressource au secret qui permet à votre cluster d'accéder aux valeurs secrètes que vous avez définies et de les lire. Vous ne devez pas modifier cette politique de ressource. Cela peut empêcher votre cluster d'accéder à votre secret. Si vous apportez des modifications à la politique de ressources Secrets et/ou à la clé KMS utilisée pour le chiffrement secret, assurez-vous de réassocier les secrets à votre cluster MSK. Cela permettra à votre cluster de continuer à accéder à votre secret.
L'exemple d'entrée JSON suivant pour l'opération `BatchAssociateScramSecret` associe un secret à un cluster :
```
{
"clusterArn" : "arn:aws:kafka:us-west-2:0123456789019:cluster/SalesCluster/abcd1234-abcd-cafe-abab-9876543210ab-4",
"secretArnList": [
"arn:aws:secretsmanager:us-west-2:0123456789019:secret:AmazonMSK_MyClusterSecret"
]
}
```
# Connexion à votre cluster à l'aide des informations d'identification de connexion
Après avoir créé un secret et l'avoir associé à votre cluster, vous pouvez connecter votre client au cluster. La procédure suivante montre comment connecter un client à un cluster utilisant l' SASL/SCRAM authentification. Il montre également comment produire et consommer à partir d'un exemple de sujet.
**Topics**
+ [Connexion d'un client au cluster à l'aide de l' SASL/SCRAM authentification](#w2aab9c13c29c17c13c11b9b7)
+ [Dépannage des problèmes de connexion](#msk-password-tutorial-connect-troubleshooting)
## Connexion d'un client au cluster à l'aide de l' SASL/SCRAM authentification
1. Exécutez la commande suivante sur une machine déjà AWS CLI installée. *clusterARN*Remplacez-le par l'ARN de votre cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
À partir du résultat JSON de cette commande, enregistrez la valeur associée à la chaîne nommée`BootstrapBrokerStringSaslScram`. Vous utiliserez cette valeur dans les étapes suivantes.
1. Sur votre ordinateur client, créez un fichier de configuration JAAS contenant les informations d'identification d'utilisateur stockées dans votre secret. Par exemple, pour l'utilisateur **alice**, créez un fichier appelé `users_jaas.conf` avec le contenu suivant.
```
KafkaClient {
org.apache.kafka.common.security.scram.ScramLoginModule required
username="alice"
password="alice-secret";
};
```
1. Utilisez la commande suivante pour exporter votre fichier de configuration JAAS en tant que paramètre d'environnement `KAFKA_OPTS`.
```
export KAFKA_OPTS=-Djava.security.auth.login.config=/users_jaas.conf
```
1. Créez un fichier nommé `kafka.client.truststore.jks` dans un répertoire `/tmp`.
1. (Facultatif) Utilisez la commande suivante pour copier le fichier de stockage de clés JDK de votre `cacerts` dossier JVM dans le `kafka.client.truststore.jks` fichier que vous avez créé à l'étape précédente. *JDKFolder*Remplacez-le par le nom du dossier JDK de votre instance. Par exemple, votre dossier JDK peut être nommé `java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64`.
```
cp /usr/lib/jvm/JDKFolder/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. Dans le répertoire `bin` de votre installation d'Apache Kafka, créez un fichier de propriétés client appelé `client_sasl.properties` avec le contenu suivant. Ce fichier définit le mécanisme et le protocole SASL.
```
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
```
1. Pour créer un exemple de rubrique, exécutez la commande suivante. *BootstrapBrokerStringSaslScram*Remplacez-la par la chaîne bootstrap broker que vous avez obtenue à l'étape 1 de cette rubrique.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBrokerStringSaslScram --command-config /client_sasl.properties --replication-factor 3 --partitions 1 --topic ExampleTopicName
```
1. Pour produire un exemple de rubrique que vous avez créé, exécutez la commande suivante sur votre ordinateur client. *BootstrapBrokerStringSaslScram*Remplacez-la par la chaîne du broker bootstrap que vous avez récupérée à l'étape 1 de cette rubrique.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringSaslScram --topic ExampleTopicName --producer.config client_sasl.properties
```
1. Pour consommer à partir de la rubrique que vous avez créée, exécutez la commande suivante sur votre ordinateur client. *BootstrapBrokerStringSaslScram*Remplacez-la par la chaîne bootstrap broker que vous avez obtenue à l'étape 1 de cette rubrique.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --from-beginning --consumer.config client_sasl.properties
```
## Dépannage des problèmes de connexion
Lorsque vous exécutez les commandes du client Kafka, vous pouvez rencontrer des erreurs de mémoire Java Heap, en particulier lorsque vous travaillez avec des sujets ou des ensembles de données volumineux. Ces erreurs se produisent parce que les outils Kafka s'exécutent en tant qu'applications Java avec des paramètres de mémoire par défaut qui peuvent être insuffisants pour votre charge de travail.
Pour résoudre `Out of Memory Java Heap` les erreurs, vous pouvez augmenter la taille du segment de mémoire Java en modifiant la variable d'`KAFKA_OPTS`environnement pour inclure les paramètres de mémoire.
L'exemple suivant définit la taille maximale du tas à 1 Go ()`-Xmx1G`. Vous pouvez ajuster cette valeur en fonction de la mémoire système disponible et de vos exigences.
```
export KAFKA_OPTS="-Djava.security.auth.login.config=/users_jaas.conf -Xmx1G"
```
Si vous abordez des sujets volumineux, pensez à utiliser des paramètres basés sur le temps ou le décalage plutôt que de limiter l'utilisation `--from-beginning` de la mémoire :
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --max-messages 1000 --consumer.config client_sasl.properties
```
# Utilisation des utilisateurs
**Création d'utilisateurs :** vous créez des utilisateurs dans votre secret sous forme de paires valeur-clé. Lorsque vous utilisez l'option **Texte brut** dans la console Secrets Manager, vous devez spécifier les informations d'identification de connexion au format suivant.
```
{
"username": "alice",
"password": "alice-secret"
}
```
**Révocation de l'accès utilisateur :** pour révoquer les informations d'identification d'un utilisateur lui permettant d'accéder à un cluster, nous vous recommandons de supprimer ou d'appliquer une liste de contrôle d'accès (ACL) sur le cluster, puis de dissocier le secret. Ceci pour les raisons suivantes :
+ La suppression d'un utilisateur ne ferme pas les connexions existantes.
+ Les modifications de votre secret prennent jusqu'à 10 minutes pour se propager.
Pour en savoir plus sur l'utilisation d'une liste de contrôle d'accès (ACL) avec Amazon MSK, consultez [Apache Kafka ACLs](msk-acls.md).
Pour les clusters utilisant ZooKeeper le mode, nous vous recommandons de restreindre l'accès à vos ZooKeeper nœuds afin d'empêcher les utilisateurs de les modifier ACLs. Pour de plus amples informations, veuillez consulter [Contrôlez l'accès aux ZooKeeper nœuds Apache de votre cluster Amazon MSK](zookeeper-security.md).
# Limitations liées à l'utilisation des secrets SCRAM
Notez les limitations suivantes lorsque vous utilisez des secrets SCRAM :
+ Amazon MSK prend uniquement en charge l'authentification SCRAM-SHA-512.
+ Un cluster Amazon MSK peut avoir jusqu'à 1 000 utilisateurs.
+ Vous devez utiliser un AWS KMS key avec votre secret. Vous ne pouvez pas utiliser un secret qui utilise la clé de chiffrement par défaut de Secrets Manager avec Amazon MSK. Pour plus d'informations sur la création d'une clé KMS, consultez [Création de clés de chiffrements symétriques](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk).
+ Vous ne pouvez pas utiliser une clé KMS asymétrique avec Secrets Manager.
+ Vous pouvez associer jusqu'à 10 secrets à un cluster à la fois à l'aide de cette [ BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret)opération.
+ Le nom des secrets associés à un cluster Amazon MSK doit comporter le préfixe **AmazonMSK\$1**.
+ Les secrets associés à un cluster Amazon MSK doivent se trouver dans le même compte Amazon Web Services et dans la même AWS région que le cluster.
# Apache Kafka ACLs
Apache Kafka possède un autorisateur enfichable et est livré avec une implémentation d'autorisateur. out-of-box Amazon MSK active ce mécanisme d’autorisation dans le fichier `server.properties` sur les brokers.
Apache Kafka ACLs a le format « Le P principal est [autorisé/refusé] Opération O depuis l'hôte H sur toute ressource R correspondant au RP ». ResourcePattern Si RP ne correspond pas à une ressource R spécifique, alors R n'est pas associée et ACLs, par conséquent, personne d'autre que les super utilisateurs n'est autorisé à accéder à R. Pour modifier ce comportement d'Apache Kafka, vous définissez la propriété sur `allow.everyone.if.no.acl.found` true. Amazon MSK la définit par défaut en tant que vrai. Cela signifie qu'avec les clusters Amazon MSK, si vous ne définissez ACLs pas explicitement une ressource, tous les principaux peuvent accéder à cette ressource. Si vous l'activez ACLs sur une ressource, seuls les principaux autorisés peuvent y accéder. Si vous souhaitez restreindre l'accès à une rubrique et autoriser un client à l'aide de l'authentification mutuelle TLS, ajoutez-la à l' ACLs aide de la CLI d'autorisation Apache Kafka. Pour plus d'informations sur l'ajout, la suppression et la mise en liste ACLs, consultez l'[interface de ligne de commande d'autorisation Kafka](https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Authorization+Command+Line+Interface).
Amazon MSK configurant les courtiers en tant que super utilisateurs, ils peuvent accéder à toutes les rubriques. Cela permet aux courtiers de répliquer les messages depuis la partition principale, que la `allow.everyone.if.no.acl.found` propriété soit définie ou non pour la configuration du cluster.
**Pour ajouter ou supprimer l'accès en lecture et en écriture à une rubrique**
1. Ajoutez vos courtiers au tableau ACL pour leur permettre de lire tous les sujets ACLs en place. Pour donner l'accès à vos agents à la lecture d'une rubrique, exécutez la commande suivante sur un ordinateur client qui peut communiquer avec le cluster MSK.
Remplacez *Distinguished-Name* par le DNS de l'un des courtiers bootstrap de votre cluster, puis remplacez la chaîne située avant le premier point de ce nom distinctif par un astérisque ()`*`. Par exemple, si l'un des courtiers bootstrap de votre cluster possède le DNS`b-6.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com`, remplacez *Distinguished-Name* la commande suivante par`*.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com`. Pour de plus amples informations sur la façon d'obtenir les brokers d’amorçage, veuillez consulter [Obtenez les courtiers bootstrap pour un cluster Amazon MSK](msk-get-bootstrap-brokers.md).
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
1. Pour accorder à une application cliente un accès en lecture à une rubrique, exécutez la commande suivante sur votre ordinateur client. Si vous utilisez l'authentification TLS mutuelle, utilisez celle *Distinguished-Name* que vous avez utilisée lors de la création de la clé privée.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
Pour supprimer l'accès en lecture, vous pouvez exécuter la même commande, en remplaçant `--add` par `--remove`.
1. Pour accorder un accès en écriture à une rubrique, exécutez la commande suivante sur votre ordinateur client. Si vous utilisez l'authentification TLS mutuelle, utilisez celle *Distinguished-Name* que vous avez utilisée lors de la création de la clé privée.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Write --topic Topic-Name
```
Pour supprimer l'accès en écriture, vous pouvez exécuter la même commande, en remplaçant `--add` par `--remove`.
# Modification du groupe de sécurité d'un cluster Amazon MSK
Cette page explique comment modifier le groupe de sécurité d'un cluster MSK existant. Vous devrez peut-être modifier le groupe de sécurité d'un cluster afin de fournir l'accès à un certain ensemble d'utilisateurs ou de limiter l'accès au cluster. Pour plus d'informations sur les groupes de sécurité, consultez [Groupes de sécurité pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) dans le Guide de l'utilisateur Amazon VPC.
1. Utilisez l'[ListNodes](https://docs.amazonaws.cn/en_us/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes)API ou la commande [list-nodes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/list-nodes.html) du AWS CLI pour obtenir la liste des courtiers de votre cluster. Les résultats de cette opération incluent les IDs interfaces réseau élastiques (ENIs) associées aux courtiers.
1. Connectez-vous à la console Amazon EC2 AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. À l'aide de la liste déroulante située dans le coin supérieur droit de l'écran, sélectionnez la région dans laquelle le cluster est déployé.
1. Dans le volet de navigation, sous **Réseau et sécurité**, choisissez **Interfaces réseau**.
1. Sélectionnez la première ENI que vous avez obtenue lors de la première étape. Choisissez le menu **Actions** en haut de l'écran, puis choisissez **Modifier les groupes de sécurité**. Assignez le nouveau groupe de sécurité à cette ENI. Répétez cette étape pour chacun des éléments ENIs que vous avez obtenus lors de la première étape.
**Note**
Les modifications que vous apportez au groupe de sécurité d'un cluster à l'aide de la console Amazon EC2 ne sont pas reflétées dans la console MSK sous **Paramètres réseau**.
1. Configurez les règles du nouveau groupe de sécurité pour garantir que vos clients ont accès aux agents. Pour de plus amples informations sur la définition de règles de groupe de sécurité, consultez [Ajout, Suppression et Mise à jour de règles](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules) dans le Guide de l'utilisateur Amazon VPC.
**Important**
Si vous modifiez le groupe de sécurité associé aux agents d'un cluster, puis que vous ajoutez de nouveaux agents à ce cluster, Amazon MSK associe les nouveaux agents au groupe de sécurité d'origine associé au cluster lors de sa création. Toutefois, pour qu'un cluster fonctionne correctement, tous ses agents doivent être associés au même groupe de sécurité. Par conséquent, si vous ajoutez de nouveaux courtiers après avoir modifié le groupe de sécurité, vous devez suivre à nouveau la procédure précédente et mettre à jour les ENIs nouveaux courtiers.
# Contrôlez l'accès aux ZooKeeper nœuds Apache de votre cluster Amazon MSK
Pour des raisons de sécurité, vous pouvez limiter l'accès aux ZooKeeper nœuds Apache qui font partie de votre cluster Amazon MSK. Pour limiter l'accès aux nœuds, vous pouvez leur attribuer un groupe de sécurité distinct. Vous pouvez ensuite décider qui a accès à ce groupe de sécurité.
**Important**
Cette section ne s'applique pas aux clusters exécutés en KRaft mode. Consultez [KRaft mode](metadata-management.md#kraft-intro).
**Topics**
+ [Pour placer vos ZooKeeper nœuds Apache dans un groupe de sécurité distinct](zookeeper-security-group.md)
+ [Utilisation de la sécurité TLS avec Apache ZooKeeper](zookeeper-security-tls.md)
# Pour placer vos ZooKeeper nœuds Apache dans un groupe de sécurité distinct
Pour limiter l'accès aux ZooKeeper nœuds Apache, vous pouvez leur attribuer un groupe de sécurité distinct. Vous pouvez choisir qui a accès à ce nouveau groupe de sécurité en définissant des règles de groupe de sécurité.
1. Obtenez la chaîne de ZooKeeper connexion Apache pour votre cluster. Pour savoir comment procéder, consultez [ZooKeeper mode](metadata-management.md#msk-get-connection-string). La chaîne de connexion contient les noms DNS de vos ZooKeeper nœuds Apache.
1. Utilisez un outil comme `host` ou `ping` pour convertir les noms DNS que vous avez obtenus à l'étape précédente en adresses IP. Enregistrez ces adresses IP car vous en aurez besoin plus tard dans cette procédure.
1. Connectez-vous à la console Amazon EC2 AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. Dans le panneau de navigation, sous **Network & Security (Réseau et sécurité)**, choisissez **Network Interfaces (Interfaces réseau)**.
1. Dans le champ de recherche au-dessus de la table des interfaces réseau, tapez le nom de votre cluster, puis appuyer sur retour. Cela limite le nombre d'interfaces réseau qui apparaissent dans la table aux interfaces associées à votre cluster.
1. Activez la case à cocher au début de la ligne qui correspond à la première interface réseau de la liste.
1. Dans le volet de détails au bas de la page, recherchez l'** IPv4 adresse IP privée principale**. Si cette adresse IP correspond à l'une des adresses IP que vous avez obtenues lors de la première étape de cette procédure, cela signifie que cette interface réseau est attribuée à un ZooKeeper nœud Apache qui fait partie de votre cluster. Sinon, désactivez la case à cocher en regard de cette interface réseau et sélectionnez l'interface réseau suivante dans la liste. L'ordre dans lequel vous sélectionnez les interfaces réseau n'a pas d'importance. Dans les étapes suivantes, vous allez effectuer les mêmes opérations sur toutes les interfaces réseau assignées aux ZooKeeper nœuds Apache, une par une.
1. Lorsque vous sélectionnez une interface réseau correspondant à un ZooKeeper nœud Apache, choisissez le menu **Actions** en haut de la page, puis choisissez **Modifier les groupes de sécurité**. Attribuez un nouveau groupe de sécurité à cette interface réseau. Pour de plus amples informations sur la création des groupes de sécurité, consultez [Création d'un groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#CreatingSecurityGroups) dans la documentation Amazon VPC.
1. Répétez l'étape précédente pour attribuer le même nouveau groupe de sécurité à toutes les interfaces réseau associées aux ZooKeeper nœuds Apache de votre cluster.
1. Vous pouvez désormais choisir qui a accès à ce nouveau groupe de sécurité. Pour de plus amples informations sur la définition de règles de groupe de sécurité, consultez [Ajout, Suppression et Mise à jour de règles](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules) dans la documentation Amazon VPC.
# Utilisation de la sécurité TLS avec Apache ZooKeeper
Vous pouvez utiliser la sécurité TLS pour le chiffrement en transit entre vos clients et vos ZooKeeper nœuds Apache. Pour implémenter la sécurité TLS avec vos ZooKeeper nœuds Apache, procédez comme suit :
+ Les clusters doivent utiliser Apache Kafka version 2.5.1 ou ultérieure pour utiliser la sécurité TLS avec Apache. ZooKeeper
+ Activez la sécurité TLS lorsque vous créez ou configurez votre cluster. Les clusters créés avec Apache Kafka version 2.5.1 ou ultérieure avec TLS activé utilisent automatiquement la sécurité TLS avec les points de terminaison Apache. ZooKeeper Pour plus d'informations sur la configuration de la sécurité TLS, consultez [Commencez avec le chiffrement Amazon MSK](msk-working-with-encryption.md).
+ Récupérez les ZooKeeper points de terminaison TLS Apache à l'aide de l'opération [DescribeCluster ](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster).
+ Créez un fichier ZooKeeper de configuration Apache à utiliser avec les [https://kafka.apache.org/documentation/#security_authz_cli](https://kafka.apache.org/documentation/#security_authz_cli)outils `kafka-configs.sh` et ou avec le ZooKeeper shell. Avec chaque outil, vous utilisez le `--zk-tls-config-file` paramètre pour spécifier votre ZooKeeper configuration Apache.
L'exemple suivant montre un fichier de ZooKeeper configuration Apache typique :
```
zookeeper.ssl.client.enable=true
zookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
zookeeper.ssl.keystore.location=kafka.jks
zookeeper.ssl.keystore.password=test1234
zookeeper.ssl.truststore.location=truststore.jks
zookeeper.ssl.truststore.password=test1234
```
+ Pour les autres commandes (telles que`kafka-topics`), vous devez utiliser la variable d'`KAFKA_OPTS`environnement pour configurer les ZooKeeper paramètres Apache. L'exemple suivant montre comment configurer la variable d'`KAFKA_OPTS`environnement pour transmettre les ZooKeeper paramètres Apache à d'autres commandes :
```
export KAFKA_OPTS="
-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
-Dzookeeper.client.secure=true
-Dzookeeper.ssl.trustStore.location=/home/ec2-user/kafka.client.truststore.jks
-Dzookeeper.ssl.trustStore.password=changeit"
```
Après avoir configuré la variable d'environnement `KAFKA_OPTS`, vous pouvez utiliser les commandes de l'interface de ligne de commande normalement. L'exemple suivant crée un sujet Apache Kafka en utilisant la ZooKeeper configuration Apache à partir de la variable d'`KAFKA_OPTS`environnement :
```
/bin/kafka-topics.sh --create --zookeeper ZooKeeperTLSConnectString --replication-factor 3 --partitions 1 --topic AWSKafkaTutorialTopic
```
**Note**
Les noms des paramètres que vous utilisez dans votre fichier de ZooKeeper configuration Apache et ceux que vous utilisez dans votre variable d'`KAFKA_OPTS`environnement ne sont pas cohérents. Faites attention aux noms que vous utilisez et aux paramètres de votre fichier de configuration et de votre variable d'environnement `KAFKA_OPTS`.
Pour plus d'informations sur l'accès à vos ZooKeeper nœuds Apache avec TLS, voir [KIP-515 : Permettre au client ZK d'utiliser](https://cwiki.apache.org/confluence/display/KAFKA/KIP-515%3A+Enable+ZK+client+to+use+the+new+TLS+supported+authentication) la nouvelle authentification prise en charge par TLS.
# Validation de conformité pour Amazon Managed Streaming for Apache Kafka
Des auditeurs tiers évaluent la sécurité et la conformité d'Amazon Managed Streaming for Apache Kafka dans le cadre de programmes de conformité AWS . Ceux-ci comprennent PCI et HIPAA BAA.
Pour obtenir la liste des AWS services concernés par des programmes de conformité spécifiques, consultez [Amazon Services inclus dans le champ d'application par programme de conformité](https://aws.amazon.com/compliance/services-in-scope/) . Pour des informations générales, voir Programmes de [AWS conformité Programmes AWS](https://aws.amazon.com/compliance/programs/) de .
Vous pouvez télécharger des rapports d'audit tiers à l'aide de AWS Artifact. Pour plus d'informations, voir [Téléchargement de rapports dans AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
Lorsque vous utilisez Amazon MSK, votre responsabilité en matière de conformité dépend de la sensibilité de vos données, des objectifs de conformité de votre entreprise et des lois et réglementations applicables. AWS fournit les ressources suivantes pour faciliter la mise en conformité :
+ [Guides démarrage rapide de la sécurité et de la conformité](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance). Ces guides de déploiement traitent des considérations architecturales et fournissent des étapes pour déployer des environnements de base axés sur la sécurité et la conformité sur AWS.
+ Livre blanc [sur l'architecture pour la sécurité et la conformité HIPAA — Ce livre blanc](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html) décrit comment les entreprises peuvent créer des applications conformes à la loi HIPAA. AWS
+ AWS Ressources de [https://aws.amazon.com/compliance/resources/](https://aws.amazon.com/compliance/resources/) de conformité — Cette collection de classeurs et de guides peut s'appliquer à votre secteur d'activité et à votre région.
+ [Évaluation des ressources à l'aide des règles](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) du *guide du AWS Config développeur* : le AWS Config service évalue dans quelle mesure les configurations de vos ressources sont conformes aux pratiques internes, aux directives du secteur et aux réglementations.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Ce AWS service fournit une vue complète de l'état de votre sécurité interne, AWS ce qui vous permet de vérifier votre conformité aux normes et aux meilleures pratiques du secteur de la sécurité.
# Résilience dans Amazon Managed Streaming for Apache Kafka
L'infrastructure AWS mondiale est construite autour des AWS régions et des zones de disponibilité. AWS Les régions fournissent plusieurs zones de disponibilité physiquement séparées et isolées, connectées par un réseau à faible latence, à haut débit et hautement redondant. Avec les zones de disponibilité, vous pouvez concevoir et exploiter des applications et des bases de données qui basculent automatiquement d’une zone à l’autre sans interruption. Les zones de disponibilité sont davantage disponibles, tolérantes aux pannes et ont une plus grande capacité de mise à l’échelle que les infrastructures traditionnelles à un ou plusieurs centres de données.
Pour plus d'informations sur AWS les régions et les zones de disponibilité, consultez la section [Infrastructure AWS mondiale](https://aws.amazon.com/about-aws/global-infrastructure/).
# Sécurité de l'infrastructure dans Amazon Managed Streaming for Apache Kafka
En tant que service géré, Amazon Managed Streaming for Apache Kafka est protégé par les procédures de sécurité du réseau AWS mondial décrites dans le livre blanc [Amazon Web Services : Overview of Security Processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf).
Vous utilisez des appels d'API AWS publiés pour accéder à Amazon MSK via le réseau. Les clients doivent supporter le protocole TLS (Sécurité de la couche transport) 1.0 ou une version ultérieure. Nous recommandons TLS 1.2 ou version ultérieure. Les clients doivent aussi prendre en charge les suites de chiffrement PFS (Perfect Forward Secrecy) comme Ephemeral Diffie-Hellman (DHE) ou Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). La plupart des systèmes modernes tels que Java 7 et les versions ultérieures prennent en charge ces modes.
En outre, les demandes doivent être signées à l’aide d’un ID de clé d’accès et d’une clé d’accès secrète associée à un principal IAM. Vous pouvez également utiliser [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) pour générer des informations d’identification de sécurité temporaires et signer les demandes.
# Journalisation Amazon MSK
Vous pouvez envoyer les journaux des courtiers Apache Kafka vers un ou plusieurs des types de destination suivants : Amazon CloudWatch Logs, Amazon S3, Amazon Data Firehose. Vous pouvez également enregistrer les appels d'API Amazon MSK avec AWS CloudTrail.
**Note**
Les journaux des courtiers sont disponibles sur les courtiers MSK Standard et Express.
## Journaux d'agent
Les journaux d'agent vous permettent de dépanner vos applications Apache Kafka et d'analyser leurs communications avec votre cluster MSK. Vous pouvez configurer votre cluster MSK nouveau ou existant pour fournir des journaux de broker de niveau Info à un ou plusieurs des types de ressources de destination suivants : un groupe de CloudWatch journaux, un compartiment S3, un flux de diffusion Firehose. Grâce à Firehose, vous pouvez ensuite transmettre les données du journal de votre flux de diffusion au OpenSearch Service.
Vous devez créer une ressource de destination avant de configurer votre cluster pour qu'il y envoie les journaux d'agent. Amazon MSK ne crée pas ces ressources de destination pour vous si elles n'existent pas déjà. Pour plus d'informations sur ces trois types de ressources de destination et sur la façon de les créer, consultez la documentation suivante :
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)
+ [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)
### Autorisations requises
Pour configurer une destination pour les journaux d'agent Amazon MSK, l'identité IAM que vous utilisez pour les actions Amazon MSK doit disposer des autorisations décrites dans la politique [AWS politique gérée : Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md).
Pour diffuser des journaux d'agent vers un compartiment S3, vous avez également besoin de l'autorisation `s3:PutBucketPolicy`. Pour plus d'informations sur les politiques de compartiment S3, consultez [Comment ajouter une politique de compartiment S3 ?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/add-bucket-policy.html) dans le Guide de l'utilisateur Amazon S3. Pour plus d'informations sur les politiques IAM en général, consultez [Gestion des accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) dans le Guide de l'utilisateur IAM.
### Stratégie de clé KMS obligatoire à utiliser avec les compartiments SSE-KMS
Si vous avez activé le chiffrement côté serveur pour votre compartiment S3 à l'aide de clés AWS KMS gérées (SSE-KMS) avec une clé gérée par le client, ajoutez ce qui suit à la politique de clé pour votre clé KMS afin qu'Amazon MSK puisse écrire des fichiers de courtier dans le compartiment.
```
{
"Sid": "Allow Amazon MSK to use the key.",
"Effect": "Allow",
"Principal": {
"Service": [
"delivery.logs.amazonaws.com"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
}
```
### Configurez les journaux des courtiers à l'aide du AWS Management Console
Si vous créez un cluster, recherchez l'en-tête de **Broker log delivery (Transmission du journal d’agent)** dans la section **Monitoring (Surveillance)** . Vous pouvez spécifier les destinations vers lesquelles vous souhaitez qu'Amazon MSK diffuse vos journaux d'agent.
Pour un cluster existant, choisissez ce dernier dans votre liste de clusters, puis sélectionnez l'onglet **Propriétés**. Faites défiler jusqu'à la section **Diffusion de journaux**, puis choisissez son bouton **Modifier**. Vous pouvez spécifier les destinations vers lesquelles vous souhaitez qu'Amazon MSK diffuse vos journaux d'agent.
### Configurez les journaux des courtiers à l'aide du AWS CLI
Lorsque vous utilisez les commande `update-monitoring` ou `create-cluster`, vous pouvez éventuellement spécifier le paramètre `logging-info` et lui transmettre une structure JSON comme dans l'exemple suivant. Dans ce JSON, les trois types de destination sont facultatifs.
**Note**
Vous devez définir le `LogDeliveryEnabled` tag sur « `true` sur les streams Firehose » pour configurer la livraison des logs. Le rôle lié au service qui AWS crée pour les CloudWatch journaux utilise cette balise pour autoriser tous les flux de diffusion Firehose. Si vous supprimez cette balise, le rôle lié au service ne sera pas en mesure de fournir des journaux au stream Firehose. *Pour voir un exemple de politique IAM indiquant les autorisations incluses dans le rôle lié à un service, consultez la section [Rôles IAM utilisés pour les autorisations de ressources dans le guide de l'utilisateur](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-Firehose.html) Amazon. CloudWatch *
```
{
"BrokerLogs": {
"S3": {
"Bucket": "amzn-s3-demo-bucket",
"Prefix": "ExamplePrefix",
"Enabled": true
},
"Firehose": {
"DeliveryStream": "ExampleDeliveryStreamName",
"Enabled": true
},
"CloudWatchLogs": {
"Enabled": true,
"LogGroup": "ExampleLogGroupName"
}
}
}
```
### Configurer les journaux des courtiers à l'aide de l'API
Vous pouvez spécifier la `loggingInfo` structure facultative dans le JSON que vous transmettez aux [UpdateMonitoring](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-monitoring.html#UpdateMonitoring)opérations [CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)or.
**Note**
Par défaut, lorsque la journalisation des agents est activée, Amazon MSK journalise les journaux de niveau `INFO` vers les destinations spécifiées. Toutefois, pour les courtiers standard, les utilisateurs d'Apache Kafka 2.4.X et versions ultérieures peuvent définir dynamiquement le niveau de journal du courtier sur n'importe quel niveau de journal [log4j](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html). Pour plus d'informations sur la définition dynamique du niveau de journalisation de l'agent, consultez [KIP-412 : Extension de l'API Admin pour prendre en charge les niveaux de journalisation dynamiques des applications](https://cwiki.apache.org/confluence/display/KAFKA/KIP-412%3A+Extend+Admin+API+to+support+dynamic+application+log+levels). Si vous définissez dynamiquement le niveau de journalisation sur `DEBUG` ou`TRACE`, nous vous recommandons d'utiliser Amazon S3 ou Firehose comme destination du journal. Si vous utilisez CloudWatch les journaux comme destination des journaux et que vous activez `DEBUG` ou `TRACE` nivelez la journalisation de manière dynamique, Amazon MSK peut fournir en permanence un échantillon de journaux. Cela peut avoir un impact significatif sur les performances de l'agent et ne doit être utilisé que lorsque le niveau de journalisation `INFO` n'est pas suffisamment détaillé pour déterminer la cause première d'un problème.
# Enregistrez les appels d'API avec AWS CloudTrail
**Note**
AWS CloudTrail les journaux ne sont disponibles pour Amazon MSK que lorsque vous les utilisez[Contrôle d'accès IAM](iam-access-control.md).
Amazon MSK est intégré à AWS CloudTrail un service qui fournit un enregistrement des actions entreprises par un utilisateur, un rôle ou un AWS service dans Amazon MSK. CloudTrail capture les appels d'API sous forme d'événements. Ces captures incluent les appels de la console Amazon MSK et les appels de code vers les opérations d'API Amazon MSK. Il capture également les actions Apache Kafka telles que la création et la modification de rubriques et de groupes.
Si vous créez un suivi, vous pouvez activer la diffusion continue d' CloudTrail événements vers un compartiment Amazon S3, y compris des événements pour Amazon MSK. Si vous ne configurez pas de suivi, vous pouvez toujours consulter les événements les plus récents dans la CloudTrail console dans **Historique des événements**. À l'aide des informations collectées par CloudTrail, vous pouvez déterminer la demande envoyée à Amazon MSK ou l'action Apache Kafka, l'adresse IP à partir de laquelle la demande a été faite, l'auteur de la demande, la date à laquelle elle a été faite, ainsi que des informations supplémentaires.
Pour en savoir plus CloudTrail, notamment comment le configurer et l'activer, consultez le [guide de AWS CloudTrail l'utilisateur](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
## Informations Amazon MSK dans CloudTrail
CloudTrail est activé sur votre compte Amazon Web Services lorsque vous créez le compte. Lorsqu'une activité événementielle prise en charge se produit dans un cluster MSK, cette activité est enregistrée dans un CloudTrail événement avec d'autres événements de AWS service dans **l'historique** des événements. Vous pouvez afficher, rechercher et télécharger les événements récents dans votre compte Amazon Web Services. Pour plus d’informations, consultez [Affichage des événements avec l’historique des événements CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Pour un enregistrement continu des événements dans votre compte Amazon Web Services, y compris les événements pour Amazon MSK, créez un journal d'activité. Un *suivi* permet CloudTrail de fournir des fichiers journaux à un compartiment Amazon S3. Par défaut, lorsque vous créez un journal de suivi dans la console, il s’applique à toutes les régions . Le journal de suivi consigne les événements de toutes les régions dans la partition AWS , et il livre les fichiers journaux dans le compartiment Amazon S3 de votre choix. En outre, vous pouvez configurer d'autres services Amazon pour analyser plus en détail les données d'événements collectées dans les CloudTrail journaux et agir en conséquence. Pour plus d’informations, consultez les ressources suivantes :
+ [Vue d’ensemble de la création d’un journal d’activité](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail Services et intégrations pris en charge](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configuration des notifications Amazon SNS pour CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Réception de fichiers CloudTrail journaux de plusieurs régions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) et [réception de fichiers CloudTrail journaux de plusieurs comptes](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
Amazon MSK enregistre toutes les [opérations Amazon MSK sous forme d'](https://docs.aws.amazon.com/MSK/2.0/APIReference/operations.html)événements dans des fichiers CloudTrail journaux. En outre, il journalise les actions Apache Kafka suivantes.
+ cluster Kafka : DescribeClusterDynamicConfiguration
+ cluster Kafka : AlterClusterDynamicConfiguration
+ cluster Kafka : CreateTopic
+ cluster Kafka : DescribeTopicDynamicConfiguration
+ cluster Kafka : AlterTopic
+ cluster Kafka : AlterTopicDynamicConfiguration
+ cluster Kafka : DeleteTopic
Chaque événement ou entrée de journal contient des informations sur la personne ayant initié la demande. Les informations relatives à l’identité permettent de déterminer les éléments suivants :
+ Si la demande a été faite avec les informations d'identification de l'utilisateur root ou de l'utilisateur Gestion des identités et des accès AWS (IAM).
+ Si la demande a été effectuée avec les informations d’identification de sécurité temporaires d’un rôle ou d’un utilisateur fédéré.
+ Si la demande a été faite par un autre AWS service.
Pour plus d’informations, consultez la section [Élément userIdentity CloudTrail ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Exemple : entrées du fichier journal Amazon MSK
Un suivi est une configuration qui permet de transmettre des événements sous forme de fichiers journaux à un compartiment Amazon S3 que vous spécifiez. CloudTrail les fichiers journaux contiennent une ou plusieurs entrées de journal. Un événement représente une demande unique provenant de n'importe quelle source et inclut des informations sur l'action demandée, la date et l'heure de l'action, les paramètres de la demande, etc. CloudTrail les fichiers journaux ne constituent pas une trace ordonnée des appels d'API publics et des actions Apache Kafka. Ils n'apparaissent donc pas dans un ordre spécifique.
L'exemple suivant montre des entrées de CloudTrail journal illustrant les actions `DescribeCluster` et `DeleteCluster` Amazon MSK.
```
{
"Records": [
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEF0123456789ABCDE",
"arn": "arn:aws:iam::012345678901:user/Joe",
"accountId": "012345678901",
"accessKeyId": "AIDACKCEVSQ6C2EXAMPLE",
"userName": "Joe"
},
"eventTime": "2018-12-12T02:29:24Z",
"eventSource": "kafka.amazonaws.com",
"eventName": "DescribeCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "aws-cli/1.14.67 Python/3.6.0 Windows/10 botocore/1.9.20",
"requestParameters": {
"clusterArn": "arn%3Aaws%3Akafka%3Aus-east-1%3A012345678901%3Acluster%2Fexamplecluster%2F01234567-abcd-0123-abcd-abcd0123efa-2"
},
"responseElements": null,
"requestID": "bd83f636-fdb5-abcd-0123-157e2fbf2bde",
"eventID": "60052aba-0123-4511-bcde-3e18dbd42aa4",
"readOnly": true,
"eventType": "AwsApiCall",
"recipientAccountId": "012345678901"
},
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEF0123456789ABCDE",
"arn": "arn:aws:iam::012345678901:user/Joe",
"accountId": "012345678901",
"accessKeyId": "AIDACKCEVSQ6C2EXAMPLE",
"userName": "Joe"
},
"eventTime": "2018-12-12T02:29:40Z",
"eventSource": "kafka.amazonaws.com",
"eventName": "DeleteCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "aws-cli/1.14.67 Python/3.6.0 Windows/10 botocore/1.9.20",
"requestParameters": {
"clusterArn": "arn%3Aaws%3Akafka%3Aus-east-1%3A012345678901%3Acluster%2Fexamplecluster%2F01234567-abcd-0123-abcd-abcd0123efa-2"
},
"responseElements": {
"clusterArn": "arn:aws:kafka:us-east-1:012345678901:cluster/examplecluster/01234567-abcd-0123-abcd-abcd0123efa-2",
"state": "DELETING"
},
"requestID": "c6bfb3f7-abcd-0123-afa5-293519897703",
"eventID": "8a7f1fcf-0123-abcd-9bdb-1ebf0663a75c",
"readOnly": false,
"eventType": "AwsApiCall",
"recipientAccountId": "012345678901"
}
]
}
```
L'exemple suivant montre une entrée de CloudTrail journal illustrant l'`kafka-cluster:CreateTopic`action.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEFGH1IJKLMN2P34Q5",
"arn": "arn:aws:iam::111122223333:user/Admin",
"accountId": "111122223333",
"accessKeyId": "CDEFAB1C2UUUUU3AB4TT",
"userName": "Admin"
},
"eventTime": "2021-03-01T12:51:19Z",
"eventSource": "kafka-cluster.amazonaws.com",
"eventName": "CreateTopic",
"awsRegion": "us-east-1",
"sourceIPAddress": "198.51.100.0/24",
"userAgent": "aws-msk-iam-auth/unknown-version/aws-internal/3 aws-sdk-java/1.11.970 Linux/4.14.214-160.339.amzn2.x86_64 OpenJDK_64-Bit_Server_VM/25.272-b10 java/1.8.0_272 scala/2.12.8 vendor/Red_Hat,_Inc.",
"requestParameters": {
"kafkaAPI": "CreateTopics",
"resourceARN": "arn:aws:kafka:us-east-1:111122223333:topic/IamAuthCluster/3ebafd8e-dae9-440d-85db-4ef52679674d-1/Topic9"
},
"responseElements": null,
"requestID": "e7c5e49f-6aac-4c9a-a1d1-c2c46599f5e4",
"eventID": "be1f93fd-4f14-4634-ab02-b5a79cb833d2",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "111122223333"
}
```
# Gestion des métadonnées
Amazon MSK prend en charge les modes Apache ZooKeeper ou de gestion des KRaft métadonnées.
À partir de la version 3.7.x d'Apache Kafka sur Amazon MSK, vous pouvez créer des clusters qui utilisent le mode plutôt que KRaft le mode. ZooKeeper KRaftles clusters basés sur les contrôleurs de Kafka s'appuient sur des contrôleurs pour gérer les métadonnées.
**Topics**
+ [ZooKeeper mode](#msk-get-connection-string)
+ [KRaft mode](#kraft-intro)
## ZooKeeper mode
[Apache ZooKeeper](https://zookeeper.apache.org/) est « un service centralisé permettant de gérer les informations de configuration, de nommer, de fournir une synchronisation distribuée et de fournir des services de groupe. Tous ces types de services sont utilisés sous une forme ou une autre par des applications distribuées », notamment Apache Kafka.
Si votre cluster utilise le ZooKeeper mode, vous pouvez suivre les étapes ci-dessous pour obtenir la chaîne de ZooKeeper connexion Apache. Cependant, nous vous recommandons d'utiliser le `BootstrapServerString` pour vous connecter à votre cluster et effectuer des opérations d'administration, car l'`--zookeeper`indicateur est obsolète dans Kafka 2.5 et a été supprimé dans Kafka 3.0.
### Obtenir la chaîne de ZooKeeper connexion Apache à l'aide du AWS Management Console
1. Ouvrez la console Amazon MSK à l'adresse [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Le tableau présente tous les clusters de la région actuelle sous ce compte. Choisissez le nom d'un cluster pour afficher sa description.
1. Sur la page de **résumé du cluster**, choisissez **Voir les informations client**. Cela vous montre les courtiers bootstrap, ainsi que la chaîne de ZooKeeper connexion Apache.
### Obtenir la chaîne de ZooKeeper connexion Apache à l'aide du AWS CLI
1. Si vous ne connaissez pas le nom Amazon Resource Name (ARN) de votre cluster, vous pouvez le trouver en listant tous les clusters de votre compte. Pour de plus amples informations, veuillez consulter [Répertorier les clusters Amazon MSK](msk-list-clusters.md).
1. Pour obtenir la chaîne de ZooKeeper connexion Apache, ainsi que d'autres informations sur votre cluster, exécutez la commande suivante, en la *ClusterArn* remplaçant par l'ARN de votre cluster.
```
aws kafka describe-cluster --cluster-arn ClusterArn
```
La sortie de cette commande `describe-cluster` ressemble à l'exemple JSON suivant.
```
{
"ClusterInfo": {
"BrokerNodeGroupInfo": {
"BrokerAZDistribution": "DEFAULT",
"ClientSubnets": [
"subnet-0123456789abcdef0",
"subnet-2468013579abcdef1",
"subnet-1357902468abcdef2"
],
"InstanceType": "kafka.m5.large",
"StorageInfo": {
"EbsStorageInfo": {
"VolumeSize": 1000
}
}
},
"ClusterArn": "arn:aws:kafka:us-east-1:111122223333:cluster/testcluster/12345678-abcd-4567-2345-abcdef123456-2",
"ClusterName": "testcluster",
"CreationTime": "2018-12-02T17:38:36.75Z",
"CurrentBrokerSoftwareInfo": {
"KafkaVersion": "2.2.1"
},
"CurrentVersion": "K13V1IB3VIYZZH",
"EncryptionInfo": {
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:555555555555:key/12345678-abcd-2345-ef01-abcdef123456"
}
},
"EnhancedMonitoring": "DEFAULT",
"NumberOfBrokerNodes": 3,
"State": "ACTIVE",
"ZookeeperConnectString": "10.0.1.101:2018,10.0.2.101:2018,10.0.3.101:2018"
}
}
```
L'exemple JSON précédent montre la clé `ZookeeperConnectString` dans la sortie de la commande `describe-cluster`. Copiez la valeur correspondant à cette clé et enregistrez-la pour pouvoir la réutiliser lorsque vous devrez créer une rubrique sur votre cluster.
**Important**
Votre cluster Amazon MSK doit être en bon `ACTIVE` état pour que vous puissiez obtenir la chaîne de ZooKeeper connexion Apache. Lorsqu'un cluster a toujours l'état `CREATING`, la sortie de la commande `describe-cluster` n'inclut pas `ZookeeperConnectString`. Si c'est le cas, attendez quelques minutes, puis exécutez à nouveau `describe-cluster` après que votre cluster a atteint l'état `ACTIVE`.
### Obtenir la chaîne de ZooKeeper connexion Apache à l'aide de l'API
Pour obtenir la chaîne de ZooKeeper connexion Apache à l'aide de l'API, consultez [DescribeCluster](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster).
## KRaft mode
Amazon MSK a introduit la prise en charge de KRaft (Apache Kafka Raft) dans la version 3.7.x de Kafka. La communauté Apache Kafka a été développée KRaft pour remplacer [Apache ZooKeeper](#msk-get-connection-string) pour la gestion des métadonnées dans les clusters Apache Kafka. En KRaft mode, les métadonnées du cluster sont propagées au sein d'un groupe de contrôleurs Kafka, qui font partie du cluster Kafka, plutôt qu'entre les nœuds. ZooKeeper KRaftles manettes sont incluses sans frais supplémentaires pour vous et ne nécessitent aucune configuration ou gestion supplémentaire de votre part. Voir [KIP-500](https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum) pour plus d'informations sur. KRaft
Voici quelques points à noter concernant le KRaft mode sur MSK :
+ KRaft le mode n'est disponible que pour les nouveaux clusters. Vous ne pouvez pas changer de mode de métadonnées une fois le cluster créé.
+ Sur la console MSK, vous pouvez créer un cluster basé sur Kraft en choisissant Kafka version 3.7.x et en cochant la case dans la fenêtre de création du KRaft cluster.
+ Pour créer un cluster en KRaft mode à l'aide de l'API [https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)ou [https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2)des opérations MSK, vous devez utiliser `3.7.x.kraft` comme version. À utiliser `3.7.x` comme version pour créer un cluster en ZooKeeper mode.
+ Le nombre de partitions par broker est le même sur les clusters KRaft et ZooKeeper basés sur ceux-ci. KRaft Cela vous permet toutefois d'héberger davantage de partitions par cluster en provisionnant [davantage de courtiers dans un cluster](https://docs.aws.amazon.com/msk/latest/developerguide/limits.html).
+ Aucune modification d'API n'est requise pour utiliser le KRaft mode sur Amazon MSK. Toutefois, si vos clients utilisent toujours la chaîne de `--zookeeper` connexion aujourd'hui, vous devez mettre à jour vos clients afin qu'ils utilisent la chaîne de `--bootstrap-server` connexion pour se connecter à votre cluster. L'`--zookeeper`indicateur est obsolète dans la version 2.5 d'Apache Kafka et est supprimé à partir de la version 3.0 de Kafka. Nous vous recommandons donc d'utiliser les versions récentes du client Apache Kafka et la chaîne de `--bootstrap-server` connexion pour toutes les connexions à votre cluster.
+ ZooKeeper le mode continue d'être disponible pour toutes les versions publiées où zookeeper est également pris en charge par Apache Kafka. Consultez [Versions Apache Kafka prises en charge](supported-kafka-versions.md) pour plus de détails sur la fin du support pour les versions d'Apache Kafka et les futures mises à jour.
+ Vous devez vérifier que tous les outils que vous utilisez sont capables d'utiliser Kafka Admin APIs sans ZooKeeper connexion. Reportez-vous à [Régulateur LinkedIn de vitesse d'utilisation pour Apache Kafka avec Amazon MSK](cruise-control.md) la section pour connaître les étapes mises à jour pour connecter votre cluster au régulateur de vitesse. Le régulateur de vitesse contient également des instructions pour [utiliser le régulateur de vitesse sans ZooKeeper](https://github.com/linkedin/cruise-control/wiki/Run-without-ZooKeeper).
+ Vous n'avez pas besoin d'accéder directement aux KRaft contrôleurs de votre cluster pour effectuer des actions administratives. Toutefois, si vous utilisez la surveillance ouverte pour collecter des métriques, vous avez également besoin des points de terminaison DNS de vos contrôleurs afin de collecter des métriques non liées aux contrôleurs concernant votre cluster. Vous pouvez obtenir ces points de terminaison DNS à partir de la console MSK ou à l'aide de l'opération [ListNodes](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes)API. Consultez [Surveillez un cluster provisionné MSK avec Prometheus](open-monitoring.md) les étapes mises à jour pour configurer la surveillance ouverte pour les clusters KRaft basés.
+ Il n'y a aucune [CloudWatch métrique](https://docs.aws.amazon.com/msk/latest/developerguide/metrics-details.html) supplémentaire à surveiller pour les clusters de KRaft mode par rapport aux clusters de ZooKeeper mode. MSK gère les KRaft contrôleurs utilisés dans vos clusters.
+ Vous pouvez continuer à gérer ACLs l'utilisation de clusters en KRaft mode à l'aide de la chaîne de `--bootstrap-server` connexion. Vous ne devez pas utiliser la chaîne de `--zookeeper` connexion pour gérer ACLs. Consultez [Apache Kafka ACLs](msk-acls.md).
+ En KRaft mode, les métadonnées de votre cluster sont stockées sur des KRaft contrôleurs au sein de Kafka et non sur des ZooKeeper nœuds externes. Par conséquent, il n'est pas nécessaire de contrôler l'accès aux nœuds de contrôleur séparément [comme c'est le cas pour les ZooKeeper nœuds](https://docs.aws.amazon.com/msk/latest/developerguide/zookeeper-security.html).
# Opérations du sujet
Vous pouvez utiliser Amazon MSK APIs pour gérer les sujets de votre cluster MSK Provisioned sans avoir à configurer et à gérer les clients d'administration Kafka. Vous pouvez ainsi définir ou lire les APIs propriétés des rubriques telles que le facteur de réplication et le nombre de partitions, ainsi que les paramètres de configuration tels que les politiques de conservation et de nettoyage. Vous pouvez gérer les sujets Kafka par programmation à l'aide de vos interfaces habituelles, notamment AWS CLI et AWS SDKs. AWS CloudFormation Ils APIs sont également intégrés à la console Amazon MSK, regroupant ainsi toutes les opérations liées aux sujets en un seul endroit. Vous pouvez désormais créer ou mettre à jour des rubriques en quelques clics à l'aide de paramètres guidés par défaut, tout en bénéficiant d'une visibilité complète sur les configurations des rubriques, les informations au niveau des partitions et les métriques.
**Important**
Les réponses de l'API de cette rubrique reflètent des données mises à jour toutes les minutes environ. Pour connaître l'état le plus récent du sujet après avoir apporté des modifications, attendez environ une minute avant de lancer la requête.
## Conditions requises pour utiliser le sujet APIs
+ Votre cluster doit être un cluster provisionné par MSK. Ils ne APIs sont pas disponibles pour les clusters MSK Serverless.
+ Votre cluster doit exécuter Apache Kafka version 3.6.0 ou ultérieure. Pour plus d'informations sur les versions prises en charge, consultez[Versions Apache Kafka prises en charge](supported-kafka-versions.md).
+ Votre cluster doit être dans `ACTIVE` cet état. Pour de plus amples informations sur les états des clusters, consultez [Comprendre les états des clusters provisionnés par MSK](msk-cluster-states.md).
+ Vous devez disposer des autorisations IAM appropriées. Pour de plus amples informations, veuillez consulter [Autorisations IAM pour les opérations sur les sujets APIs](#topic-operations-permissions).
## Autorisations IAM pour les opérations sur les sujets APIs
Pour les appeler APIs, vous devez disposer des autorisations IAM appropriées. Le tableau suivant répertorie les autorisations requises pour chaque API.
**Autorisations requises pour les opérations sur les rubriques APIs**
| API | Autorisations nécessaires | Ressource |
| --- | --- | --- |
| ListTopics | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | ARN du cluster, ARN du sujet |
| DescribeTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | ARN du cluster, ARN du sujet |
| DescribeTopicPartitions | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | ARN du cluster, ARN du sujet |
| CreateTopic | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` | ARN du cluster, ARN du sujet |
| DeleteTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DeleteTopic` | ARN du cluster, ARN du sujet |
| UpdateTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` `kafka-cluster:AlterTopicDynamicConfiguration` | ARN du cluster, ARN du sujet |
**Note**
Pour`kafka-cluster:Connect`, spécifiez l'ARN du cluster dans votre politique IAM. Pour toutes les autres actions, spécifiez l'ARN du sujet dans votre politique IAM.
**Note**
En `ListTopics` effet, vous pouvez utiliser un caractère générique (\$1) pour faire correspondre tous les sujets d'un cluster. Par exemple : `arn:aws:kafka:us-east-1:123456789012:topic/my-cluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/*`.
Pour plus d'informations sur le contrôle d'accès IAM pour Amazon MSK, consultez. [Contrôle d'accès IAM](iam-access-control.md)
**Topics**
+ [Conditions requises pour utiliser le sujet APIs](#topic-operations-requirements)
+ [Autorisations IAM pour les opérations sur les sujets APIs](#topic-operations-permissions)
+ [Répertorier les sujets d'un cluster Amazon MSK](msk-list-topics.md)
+ [Obtenir des informations détaillées sur un sujet](msk-describe-topic.md)
+ [Afficher les informations de partition pour un sujet](msk-describe-topic-partitions.md)
+ [Création de sujets dans un cluster Amazon MSK](msk-create-topic.md)
+ [Mettre à jour une rubrique dans un cluster Amazon MSK](msk-update-topic.md)
+ [Supprimer une rubrique dans un cluster Amazon MSK](msk-delete-topic.md)
# Répertorier les sujets d'un cluster Amazon MSK
Vous pouvez répertorier toutes les rubriques de votre cluster MSK Provisioned pour afficher les métadonnées de base telles que le nombre de partitions et les facteurs de réplication. Cela est utile pour surveiller les sujets de votre cluster, effectuer des vérifications d'inventaire ou identifier les sujets devant faire l'objet d'une enquête plus approfondie.
**Note**
L'`ListTopics`API fournit des métadonnées thématiques de base. Pour obtenir des informations détaillées sur un sujet spécifique, notamment son statut actuel et sa configuration, utilisez l'`DescribeTopic`API. Pour de plus amples informations, veuillez consulter [Obtenir des informations détaillées sur un sujet](msk-describe-topic.md).
**Note**
Cette réponse de l'API reflète les données mises à jour toutes les minutes environ. Pour connaître l'état le plus récent du sujet après avoir apporté des modifications, attendez environ une minute avant de lancer la requête.
**Topics**
+ [Répertoriez les sujets en utilisant le AWS Management Console](list-topics-console.md)
+ [Répertoriez les sujets en utilisant le AWS CLI](list-topics-cli.md)
+ [Lister les sujets à l'aide de l'API](list-topics-api.md)
# Répertoriez les sujets en utilisant le AWS Management Console
1. Connectez-vous à la AWS Management Console console Amazon MSK et ouvrez-la [https://console.aws.amazon.com/msk/chez vous ? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dans la liste des clusters, choisissez le nom du cluster pour lequel vous souhaitez répertorier les sujets.
1. Sur la page des détails du cluster, choisissez l'onglet **Rubriques**.
1. Le tableau présente toutes les rubriques du cluster, notamment le nom de la rubrique, le nombre de partitions, le facteur de réplication et le nombre de out-of-sync répliques.
# Répertoriez les sujets en utilisant le AWS CLI
Exécutez la commande suivante, en la *ClusterArn* remplaçant par le Amazon Resource Name (ARN) de votre cluster. Si vous n'avez pas l'ARN pour votre cluster, vous pouvez le trouver en listant tous les clusters. Pour de plus amples informations, veuillez consulter [Répertorier les clusters Amazon MSK](msk-list-clusters.md).
```
aws kafka list-topics --cluster-arn ClusterArn
```
La sortie de cette commande ressemble à l'exemple JSON suivant.
```
{
"topics": [
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"partitionCount": 3,
"replicationFactor": 3,
"outOfSyncReplicaCount": 0
},
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/AnotherTopic",
"topicName": "AnotherTopic",
"partitionCount": 6,
"replicationFactor": 3,
"outOfSyncReplicaCount": 1
}
]
}
```
## Pagination des résultats
Si votre cluster comporte de nombreux sujets, vous pouvez utiliser la pagination pour récupérer les résultats par petits lots. Utilisez le `--max-results` paramètre pour spécifier le nombre maximum de sujets à renvoyer et utilisez-le `--next-token` pour récupérer la page de résultats suivante.
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10
```
Si d'autres résultats sont disponibles, la réponse inclut une `nextToken` valeur. Utilisez ce jeton pour récupérer la page de résultats suivante.
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10 --next-token NextToken
```
## Filtrer les sujets par nom
Vous pouvez filtrer la liste des sujets en spécifiant un préfixe à l'aide du `--topic-name-filter` paramètre. Cela renvoie uniquement les sujets dont le nom commence par le préfixe spécifié.
```
aws kafka list-topics --cluster-arn ClusterArn --topic-name-filter "prod-"
```
Cette commande renvoie uniquement les rubriques dont le nom commence par`prod-`, par exemple `prod-orders` ou`prod-inventory`.
# Lister les sujets à l'aide de l'API
Pour répertorier les sujets à l'aide de l'API, consultez [ListTopics](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#ListTopics).
# Obtenir des informations détaillées sur un sujet
Vous pouvez récupérer des informations détaillées sur un sujet spécifique de votre cluster MSK Provisioned, notamment son état actuel, le nombre de partitions, le facteur de réplication et la configuration. Cela est utile pour résoudre les problèmes, valider les paramètres des rubriques ou surveiller l'état des rubriques pendant les opérations.
**Note**
Cette réponse de l'API reflète les données mises à jour toutes les minutes environ. Pour connaître l'état le plus récent du sujet après avoir apporté des modifications, attendez environ une minute avant de lancer la requête.
**Topics**
+ [Décrivez un sujet à l'aide du AWS Management Console](describe-topic-console.md)
+ [Décrivez un sujet à l'aide du AWS CLI](describe-topic-cli.md)
+ [Décrire un sujet à l'aide de l'API](describe-topic-api.md)
# Décrivez un sujet à l'aide du AWS Management Console
1. Connectez-vous à la AWS Management Console console Amazon MSK et ouvrez-la [https://console.aws.amazon.com/msk/chez vous ? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dans la liste des clusters, choisissez le nom du cluster contenant le sujet que vous souhaitez décrire.
1. Sur la page des détails du cluster, choisissez l'onglet **Rubriques**.
1. Dans la liste des sujets, choisissez le nom du sujet que vous souhaitez consulter.
1. La page de détails du sujet contient des informations sur le sujet, notamment son statut, le nombre de partitions, le facteur de réplication et les paramètres de configuration.
# Décrivez un sujet à l'aide du AWS CLI
Exécutez la commande suivante, en la *ClusterArn* remplaçant par le Amazon Resource Name (ARN) de votre cluster et *TopicName* par le nom du sujet que vous souhaitez décrire.
```
aws kafka describe-topic --cluster-arn ClusterArn --topic-name TopicName
```
La sortie de cette commande ressemble à l'exemple JSON suivant.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"partitionCount": 3,
"replicationFactor": 3,
"configs": "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw",
"status": "ACTIVE"
}
```
## Comprendre le statut du sujet
Le `status` champ indique l'état actuel du sujet. Le tableau suivant décrit les valeurs d'état possibles.
**Valeurs d'état du sujet**
| Statut | Description |
| --- | --- |
| CRÉATION | Le sujet est en cours de création. |
| ACTIF | Le sujet est actif et prêt à être utilisé. |
| MISE À JOUR | La configuration de la rubrique est en cours de mise à jour. |
| SUPPRESSION | Le sujet est en cours de suppression. |
## Comprendre les configurations des rubriques
Le `configs` champ contient les propriétés de configuration Kafka du sujet, codées au format Base64. Pour afficher la configuration dans un format lisible, vous devez décoder la chaîne Base64.
L'exemple suivant montre comment décoder la configuration à l'aide de la `base64` commande sous Linux ou macOS.
```
echo "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw" | base64 --decode
```
La sortie décodée affiche les propriétés de configuration du sujet au format clé-valeur.
```
compression.type=producer
retention.ms=604800000
```
Pour plus d'informations sur les propriétés de configuration au niveau des rubriques, consultez. [Configuration Amazon MSK au niveau du sujet](msk-configuration-properties.md#msk-topic-confinguration)
# Décrire un sujet à l'aide de l'API
Pour décrire une rubrique utilisant l'API, voir [DescribeTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DescribeTopic).
# Afficher les informations de partition pour un sujet
Vous pouvez récupérer des informations détaillées sur les partitions d'une rubrique spécifique dans votre cluster MSK Provisioned. Ces informations incluent le numéro de partition, le courtier principal, les courtiers de répliques et les répliques synchronisées (ISR). Cela est utile pour surveiller la distribution des partitions, identifier les partitions sous-répliquées ou résoudre les problèmes de réplication.
**Note**
Cette réponse de l'API reflète les données mises à jour toutes les minutes environ. Pour connaître l'état le plus récent du sujet après avoir apporté des modifications, attendez environ une minute avant de lancer la requête.
**Topics**
+ [Affichez les informations de partition à l'aide du AWS Management Console](describe-topic-partitions-console.md)
+ [Affichez les informations de partition à l'aide du AWS CLI](describe-topic-partitions-cli.md)
+ [Afficher les informations de partition à l'aide de l'API](describe-topic-partitions-api.md)
# Affichez les informations de partition à l'aide du AWS Management Console
1. Connectez-vous à la AWS Management Console console Amazon MSK et ouvrez-la [https://console.aws.amazon.com/msk/chez vous ? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dans la liste des clusters, choisissez le nom du cluster qui contient le sujet.
1. Sur la page des détails du cluster, choisissez l'onglet **Rubriques**.
1. Dans la liste des rubriques, choisissez le nom de la rubrique pour laquelle vous souhaitez consulter les informations de partition.
1. Sur la page de détails du sujet, les informations de partition sont affichées, indiquant le numéro de partition, le courtier principal, les répliques et les répliques synchronisées pour chaque partition.
# Affichez les informations de partition à l'aide du AWS CLI
Exécutez la commande suivante, en la *ClusterArn* remplaçant par le Amazon Resource Name (ARN) de votre cluster et *TopicName* par le nom du sujet.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName
```
La sortie de cette commande ressemble à l'exemple JSON suivant.
```
{
"partitions": [
{
"partition": 0,
"leader": 1,
"replicas": [1, 2, 3],
"isr": [1, 2, 3]
},
{
"partition": 1,
"leader": 2,
"replicas": [2, 3, 1],
"isr": [2, 3, 1]
},
{
"partition": 2,
"leader": 3,
"replicas": [3, 1, 2],
"isr": [3, 1]
}
]
}
```
## Comprendre les informations de partition
La réponse inclut les informations suivantes pour chaque partition :
+ **partition** — Numéro de partition. Les partitions sont numérotées à partir de 0.
+ **leader** — L'ID de courtier du leader pour cette partition. Le leader gère toutes les demandes de lecture et d'écriture pour la partition.
+ **replicas** — Liste des courtiers IDs possédant des répliques de cette partition. Cela inclut à la fois la synchronisation et les out-of-sync répliques.
+ **isr** — Liste des courtiers IDs qui sont des répliques synchronisées. Ces répliques sont entièrement rattachées au leader et peuvent prendre le relais en tant que leader si nécessaire.
Dans l'exemple ci-dessus, la partition 2 possède une out-of-sync réplique. La `replicas` liste inclut le courtier 2, mais pas la `isr` liste. Cela indique que le courtier 2 n'est pas complètement rattrapé par le leader pour cette partition.
## Pagination des résultats
Si votre sujet comporte de nombreuses partitions, vous pouvez utiliser la pagination pour récupérer les résultats par petits lots. Utilisez le `--max-results` paramètre pour spécifier le nombre maximal de partitions à renvoyer, et `--next-token` utilisez-le pour récupérer la page de résultats suivante.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10
```
Si d'autres résultats sont disponibles, la réponse inclut une `nextToken` valeur. Utilisez ce jeton pour récupérer la page de résultats suivante.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10 --next-token NextToken
```
## Cas d’utilisation courants
L'affichage des informations de partition est utile dans plusieurs scénarios :
+ **Identification des partitions sous-répliquées** : comparez les `isr` listes `replicas` et pour identifier les partitions sur lesquelles certaines répliques ne sont pas synchronisées. Cela peut indiquer des problèmes de performance ou des problèmes de courtier.
+ **Surveillance de la distribution des partitions** — Vérifiez que les leaders des partitions sont répartis uniformément entre les courtiers afin de garantir une charge équilibrée.
+ **Résolution des problèmes de réplication** : identifiez les courtiers qui ont du mal à suivre le rythme de la réplication en examinant la liste ISR.
+ **Planification du rééquilibrage des partitions** : utilisez ces informations pour comprendre la disposition actuelle de la partition avant d'effectuer des opérations de rééquilibrage.
# Afficher les informations de partition à l'aide de l'API
Pour consulter les informations de partition à l'aide de l'API, consultez [DescribeTopicPartitions](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname-partitions.html#DescribeTopicPartitions).
# Création de sujets dans un cluster Amazon MSK
Vous pouvez créer des sujets dans votre cluster MSK Provisioned directement à l'aide de cette API sans configurer de Kafka personnalisé. AdminClient Lorsque vous créez un sujet, vous spécifiez le nom du sujet, le nombre de partitions, le facteur de réplication et, éventuellement, les configurations du sujet.
**Topics**
+ [Créez des sujets à l'aide du AWS Management Console](create-topic-console.md)
+ [Créez un sujet à l'aide du AWS CLI](create-topic-cli.md)
+ [Création d'un sujet à l'aide de l'API](create-topic-api.md)
# Créez des sujets à l'aide du AWS Management Console
1. Connectez-vous à la AWS Management Console console Amazon MSK et ouvrez-la [https://console.aws.amazon.com/msk/chez vous ? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dans la liste des clusters, choisissez le nom du cluster dans lequel vous souhaitez créer les sujets.
1. Sur la page des détails du cluster, choisissez l'onglet **Rubriques**.
1. Choisissez **Créer une rubrique**.
1. Entrez le nom du sujet, le nombre de partitions et le facteur de réplication. Ajoutez éventuellement des configurations. Vous pouvez créer plusieurs sujets à la fois.
1. Choisissez **Créer une rubrique**.
# Créez un sujet à l'aide du AWS CLI
Exécutez la commande suivante, en la *ClusterArn* remplaçant par le Amazon Resource Name (ARN) de votre cluster. Si vous n'avez pas l'ARN pour votre cluster, vous pouvez le trouver en listant tous les clusters. Pour de plus amples informations, veuillez consulter [Répertorier les clusters Amazon MSK](msk-list-clusters.md).
```
aws kafka create-topic --cluster-arn ClusterArn --topic-name MyTopic --partition-count 3 --replication-factor 3
```
La sortie de cette commande ressemble à l'exemple JSON suivant.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "CREATING"
}
```
# Création d'un sujet à l'aide de l'API
Pour créer une rubrique à l'aide de l'API, consultez [CreateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#CreateTopic).
# Mettre à jour une rubrique dans un cluster Amazon MSK
Mettez à jour le nombre de partitions ou les configurations au niveau du sujet pour un sujet existant. Cette opération modifie le sujet sans nécessiter de recréation.
**Note**
Vous pouvez mettre à jour le nombre de partitions ou les configurations des rubriques en un seul appel d'API, mais pas les deux simultanément. Pour mettre à jour les deux, effectuez des appels d'API distincts.
**Topics**
+ [Mettez à jour une rubrique à l'aide du AWS Management Console](update-topic-console.md)
+ [Mettez à jour une rubrique à l'aide du AWS CLI](update-topic-cli.md)
+ [Mettre à jour une rubrique à l'aide de l'API](update-topic-api.md)
# Mettez à jour une rubrique à l'aide du AWS Management Console
1. Connectez-vous à la AWS Management Console console Amazon MSK et ouvrez-la [https://console.aws.amazon.com/msk/chez vous ? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dans la liste des clusters, choisissez le nom du cluster contenant le sujet que vous souhaitez mettre à jour.
1. Sur la page des détails du cluster, choisissez l'onglet **Rubriques**.
1. Sélectionnez le sujet que vous souhaitez mettre à jour, puis choisissez **Modifier les paramètres de partition** ou **Modifier les configurations** dans **Actions**.
1. Mettez à jour le nombre de partitions ou les configurations selon les besoins.
1. Choisissez **Enregistrer**.
# Mettez à jour une rubrique à l'aide du AWS CLI
Exécutez la commande suivante, en la *ClusterArn* remplaçant par le Amazon Resource Name (ARN) de votre cluster et *TopicName* par le nom du sujet que vous souhaitez mettre à jour.
```
aws kafka update-topic --cluster-arn ClusterArn --topic-name TopicName --partition-count 6
```
La sortie de cette commande ressemble à l'exemple JSON suivant.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "UPDATING"
}
```
# Mettre à jour une rubrique à l'aide de l'API
Pour mettre à jour une rubrique à l'aide de l'API, consultez [UpdateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#UpdateTopic).
# Supprimer une rubrique dans un cluster Amazon MSK
La suppression d'une rubrique entraîne la suppression définitive de toutes ses données, métadonnées et informations de partition. Cette opération est irréversible.
**Topics**
+ [Supprimer un sujet à l'aide du AWS Management Console](delete-topic-console.md)
+ [Supprimer un sujet à l'aide du AWS CLI](delete-topic-cli.md)
+ [Supprimer un sujet à l'aide de l'API](delete-topic-api.md)
# Supprimer un sujet à l'aide du AWS Management Console
1. Connectez-vous à la AWS Management Console console Amazon MSK et ouvrez-la [https://console.aws.amazon.com/msk/chez vous ? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dans la liste des clusters, choisissez le nom du cluster contenant le sujet que vous souhaitez supprimer.
1. Sur la page des détails du cluster, choisissez l'onglet **Rubriques**.
1. Sélectionnez les sujets que vous souhaitez supprimer, puis choisissez **Supprimer** des **actions**.
1. Confirmez la suppression, puis choisissez **Supprimer**.
# Supprimer un sujet à l'aide du AWS CLI
Exécutez la commande suivante, en la *ClusterArn* remplaçant par le Amazon Resource Name (ARN) de votre cluster et *TopicName* par le nom du sujet que vous souhaitez supprimer.
```
aws kafka delete-topic --cluster-arn ClusterArn --topic-name TopicName
```
La sortie de cette commande ressemble à l'exemple JSON suivant.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "DELETING"
}
```
# Supprimer un sujet à l'aide de l'API
Pour supprimer une rubrique à l'aide de l'API, consultez [DeleteTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DeleteTopic).
# Ressources Amazon MSK
Le terme *ressources* a deux significations dans Amazon MSK, selon le contexte. Dans le contexte d' APIs une ressource, il existe une structure sur laquelle vous pouvez invoquer une opération. Pour obtenir la liste de ces ressources et des opérations que vous pouvez invoquer, consultez la section [Ressources](https://docs.aws.amazon.com/msk/1.0/apireference/resources.html) du manuel de référence de l'API Amazon MSK. Dans le contexte du [Contrôle d'accès IAM](iam-access-control.md), une ressource est une entité à laquelle vous pouvez autoriser ou refuser l'accès, comme défini dans la section [Ressources relatives aux politiques d'autorisation](kafka-actions.md#msk-iam-resources).
# Versions Apache Kafka
Lorsque vous créez un cluster Amazon MSK, vous spécifiez la version Apache Kafka que vous souhaitez avoir sur lui. Vous pouvez également mettre à jour la version Apache Kafka d'un cluster existant. Les rubriques de ce chapitre vous aident à comprendre les délais de prise en charge des versions de Kafka et à vous suggérer des bonnes pratiques.
**Topics**
+ [Versions Apache Kafka prises en charge](supported-kafka-versions.md)
+ [Prise en charge des versions d'Amazon MSK](version-support.md)
# Versions Apache Kafka prises en charge
Amazon Managed Streaming for Apache Kafka (Amazon MSK) prend en charge les versions Apache Kafka et Amazon MSK suivantes. La communauté Apache Kafka fournit environ 12 mois de support pour une version après sa date de sortie. Pour plus de détails, consultez la politique [EOL (fin de vie) d'Apache Kafka](https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan#TimeBasedReleasePlan-WhatIsOurEOLPolicy?).
Le tableau suivant répertorie les versions d'Apache Kafka prises en charge par Amazon MSK.
| Version d’Apache Kafka | Date de sortie de MSK | Date de fin du support |
| --- | --- | --- |
| [1.1.1](https://archive.apache.org/dist/kafka/1.1.1/RELEASE_NOTES.html) | -- | 05/06/2022 |
| [2.1.0](https://archive.apache.org/dist/kafka/2.1.0/RELEASE_NOTES.html) | -- | 05/06/2022 |
| [2.2.1](https://archive.apache.org/dist/kafka/2.2.1/RELEASE_NOTES.html) | 2019-07-31 | 2024-06-08 |
| [2.3.1](https://archive.apache.org/dist/kafka/2.3.1/RELEASE_NOTES.html) | 2019-12-19 | 2024-06-08 |
| [2.4.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 2020-04-02 | 2024-06-08 |
| [2.4.1.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 2020-09-09 | 2024-06-08 |
| [2.5.1](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html) | 2020-09-30 | 2024-06-08 |
| [2.6.0](https://archive.apache.org/dist/kafka/2.6.0/RELEASE_NOTES.html) | 21/10/2020 | 11/09/2024 |
| [2.6.1](https://archive.apache.org/dist/kafka/2.6.1/RELEASE_NOTES.html) | 19/01/2021 | 11/09/2024 |
| [2.6.2](https://archive.apache.org/dist/kafka/2.6.2/RELEASE_NOTES.html) | 29/04/2021 | 11/09/2024 |
| [2.6.3](https://archive.apache.org/dist/kafka/2.6.3/RELEASE_NOTES.html) | 2021-12-21 | 11/09/2024 |
| [2.7.0](https://archive.apache.org/dist/kafka/2.7.0/RELEASE_NOTES.html) | 29/12/2020 | 11/09/2024 |
| [2.7.1](https://archive.apache.org/dist/kafka/2.7.1/RELEASE_NOTES.html) | 25/05/2021 | 11/09/2024 |
| [2.7.2](https://archive.apache.org/dist/kafka/2.7.2/RELEASE_NOTES.html) | 2021-12-21 | 11/09/2024 |
| [2.8.0](https://archive.apache.org/dist/kafka/2.8.0/RELEASE_NOTES.html) | 19/05/2021 | 11/09/2024 |
| [2.8.1](https://archive.apache.org/dist/kafka/2.8.1/RELEASE_NOTES.html) | 28/10 | 11/09/2024 |
| [2.8.2 à plusieurs niveaux](https://archive.apache.org/dist/kafka/2.8.2/RELEASE_NOTES.html) | 28/10 | 14-01-2025 |
| [3.1.1](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html) | 22/06/2018 | 11/09/2024 |
| [3.2.0](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) | 22/06/2018 | 11/09/2024 |
| [3.3.1](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html) | 26/10 | 11/09/2024 |
| [3.3.2](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html) | 02 avril | 11/09/2024 |
| [3.4.0](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html) | 04/05/2023 | 04/08/2025 |
| [3.5.1](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html) | 26/09/2023 | 23/10/2025 |
| [3.6.0](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html) | 16/11/2023 | 01/06/2026/ |
| [3,7. x](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html) | 29/05/2024 | -- |
| [3,8. x](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html) | 20-02-2025 | -- |
| [3.9.x (recommandé](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html)) | 21/04/2025 | -- |
| [4,0. x](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html) | 16/05/2025 | -- |
| [4.1.x](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html) | 2025-10-15 | -- |
Pour plus d'informations sur la politique de support des versions d'Amazon MSK, consultez[Politique de support des versions d'Amazon MSK](version-support.md#version-support-policy).
## Amazon MSK version 4.1.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) prend désormais en charge la version 4.1 d'Apache Kafka, qui introduit les files d'attente en tant que fonctionnalité préliminaire, un nouveau protocole Streams Rebalance en accès anticipé et les répliques de leaders éligibles (ELR). Outre ces fonctionnalités, la version 4.1 d'Apache Kafka inclut diverses corrections de bogues et améliorations.
L'un des points forts de Kafka 4.1 est l'introduction des files d'attente en tant que fonctionnalité de prévisualisation. Vous pouvez utiliser plusieurs consommateurs pour traiter les messages provenant des mêmes partitions thématiques, ce qui améliore le parallélisme et le débit pour les charges de travail nécessitant la livraison de messages. point-to-point Le nouveau protocole Streams Rebalance s'appuie sur le protocole de rééquilibrage des consommateurs de Kafka 4.0, étendant les capacités de coordination des courtiers à Kafka Streams pour optimiser l'attribution des tâches et le rééquilibrage. En outre, l'ELR est désormais activé par défaut pour renforcer la disponibilité.
Pour plus de détails et une liste complète des améliorations et des corrections de bogues, consultez les [notes de publication d'Apache Kafka pour la version 4.1](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html).
Pour commencer à utiliser Apache Kafka 4.1 sur Amazon MSK, choisissez la version 4.1.x lors de la création d'un nouveau cluster via le AWS Management Console, ou. AWS CLI AWS SDKs Vous pouvez également mettre à niveau les clusters provisionnés par MSK existants grâce à une mise à jour continue sur place. Amazon MSK organise les redémarrages des courtiers pour maintenir la disponibilité et protéger vos données pendant la mise à niveau. Le support de Kafka version 4.1 est disponible partout Régions AWS où Amazon MSK est proposé.
## Amazon MSK version 4.0.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) prend désormais en charge la version 4.0 d'Apache Kafka. Cette version apporte les dernières avancées en matière de gestion et de performance des clusters à MSK Provisioned. Kafka 4.0 introduit un nouveau protocole de rééquilibrage destiné aux consommateurs, désormais largement disponible, qui permet de garantir des rééquilibres de groupe plus fluides et plus rapides. En outre, Kafka 4.0 nécessite des courtiers et des outils pour utiliser Java 17, ce qui améliore la sécurité et les performances, inclut diverses corrections de bogues et améliorations, et déconseille la gestion des métadonnées via Apache. ZooKeeper
Pour plus de détails et une liste complète des améliorations et des corrections de bogues, consultez les [notes de publication d'Apache Kafka pour la version 4.0](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html).
## Amazon MSK version 3.9.x (recommandée)
Amazon Managed Streaming for Apache Kafka (Amazon MSK) prend désormais en charge la version 3.9 d'Apache Kafka. Cette version améliore les fonctionnalités de stockage hiérarchisé en vous permettant de conserver les données hiérarchisées lorsque vous désactivez le stockage hiérarchisé au niveau de la rubrique. Vos applications grand public peuvent lire les données historiques à partir du décalage de démarrage à distance (Rx) tout en maintenant des décalages de journal continus sur le stockage local et distant.
La version 3.9 est la dernière version à prendre en charge les deux systèmes ZooKeeper ainsi que les systèmes de gestion des KRaft métadonnées. Amazon MSK fournira un support étendu pour la version 3.9 pendant au moins deux ans à compter de sa date de sortie.
Pour plus de détails et une liste complète des améliorations et des corrections de bogues, consultez les [notes de publication d'Apache Kafka pour la version 3.9.x](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html).
## Amazon MSK version 3.8.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) prend désormais en charge la version 3.8 d'Apache Kafka. Vous pouvez désormais créer de nouveaux clusters à l'aide de la version 3.8 avec KRAFT ou ZooKeeper en mode de gestion des métadonnées ou mettre à niveau vos clusters ZooKeeper basés existants pour utiliser la version 3.8. La version 3.8 d'Apache Kafka inclut plusieurs corrections de bogues et de nouvelles fonctionnalités qui améliorent les performances. Les principales nouvelles fonctionnalités incluent la prise en charge de la configuration du niveau de compression. Cela vous permet d'optimiser davantage vos performances lorsque vous utilisez des types de compression tels que lz4, zstd et gzip, en vous permettant de modifier le niveau de compression par défaut.
Pour plus de détails et une liste complète des améliorations et des corrections de bogues, consultez les [notes de publication d'Apache Kafka pour la version 3.8.x](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html).
## Apache Kafka version 3.7.x (avec stockage hiérarchisé prêt pour la production)
La version 3.7.x d'Apache Kafka sur MSK inclut le support de la version 3.7.0 d'Apache Kafka. Vous pouvez créer des clusters ou mettre à niveau des clusters existants pour utiliser la nouvelle version 3.7.x. Avec ce changement de dénomination des versions, vous n'avez plus à adopter les nouvelles versions de correctifs telles que 3.7.1 lorsqu'elles sont publiées par la communauté Apache Kafka. Amazon MSK mettra automatiquement à jour la version 3.7.x pour prendre en charge les futures versions de correctifs une fois qu'elles seront disponibles. Cela vous permet de bénéficier de la sécurité et des corrections de bogues disponibles via les versions corrigées sans déclencher de mise à niveau de version. Ces versions de correctifs publiées par Apache Kafka n'interrompent pas la compatibilité des versions et vous pouvez bénéficier des nouvelles versions de correctifs sans vous soucier des erreurs de lecture ou d'écriture pour vos applications clientes. Assurez-vous que les outils d'automatisation de votre infrastructure, tels que CloudFormation, sont mis à jour pour tenir compte de ce changement de dénomination de version.
Amazon MSK prend désormais en charge le KRaft mode (Apache Kafka Raft) dans la version 3.7.x d'Apache Kafka. Sur Amazon MSK, comme pour les ZooKeeper nœuds, les KRaft contrôleurs sont inclus sans frais supplémentaires pour vous et ne nécessitent aucune configuration ou gestion supplémentaire de votre part. Vous pouvez désormais créer des clusters en KRaft mode ou en ZooKeeper mode sur Apache Kafka version 3.7.x. En mode Kraft, vous pouvez ajouter jusqu'à 60 courtiers pour héberger davantage de partitions par cluster, sans demander d'augmentation de limite, par rapport au quota de 30 courtiers sur les clusters basés sur ZooKeeper. Pour en savoir plus KRaft sur MSK, voir[KRaft mode](metadata-management.md#kraft-intro).
La version 3.7.x d'Apache Kafka inclut également plusieurs corrections de bogues et de nouvelles fonctionnalités qui améliorent les performances. Les principales améliorations incluent l'optimisation de la découverte des leaders pour les clients et les options d'optimisation du vidage des segments de journal. Pour une liste complète des améliorations et des corrections de bogues, consultez les notes de publication d'Apache Kafka pour la version [3.7.0](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html).
## Apache Kafka version 3.6.0 (avec stockage hiérarchisé prêt pour la production)
Pour plus d'informations sur Apache Kafka version 3.6.0 (avec stockage hiérarchisé prêt pour production), consultez les [notes de mise à jour](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html) correspondantes sur le site de téléchargement d’Apache Kafka.
Amazon MSK continuera d'utiliser et de gérer ZooKeeper pour la gestion du quorum dans cette version à des fins de stabilité.
## Amazon MSK version 3.5.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) prend désormais en charge la version 3.5.1 d'Apache Kafka pour les clusters nouveaux et existants. Apache Kafka 3.5.1 inclut plusieurs corrections de bogues et de nouvelles fonctionnalités qui améliorent les performances. Les principales fonctionnalités incluent l'introduction d'une nouvelle attribution de partitions adaptée aux racks pour les consommateurs. Amazon MSK continuera d'utiliser et de gérer Zookeeper pour la gestion du quorum dans cette version. Pour une liste complète des améliorations et des corrections de bogues, consultez les notes de publication d'Apache Kafka pour la version 3.5.1.
Pour plus d'informations sur Apache Kafka, version 3.5.1, consultez ses [notes de mise à jour](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html) sur le site de téléchargement Apache Kafka.
## Amazon MSK version 3.4.0
Amazon Managed Streaming for Apache Kafka (Amazon MSK) prend désormais en charge la version 3.4.0 d'Apache Kafka pour les clusters nouveaux et existants. Apache Kafka 3.4.0 inclut plusieurs corrections de bogues et de nouvelles fonctionnalités qui améliorent les performances. Les principales fonctionnalités incluent un correctif pour améliorer la stabilité lors de l'extraction depuis la réplique la plus proche. Amazon MSK continuera d'utiliser et de gérer Zookeeper pour la gestion du quorum dans cette version. Pour une liste complète des améliorations et des corrections de bogues, consultez les notes de publication d'Apache Kafka pour la version 3.4.0.
Pour plus d'informations sur Apache Kafka, version 3.4.0, consultez ses [notes de mise à jour](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html) sur le site de téléchargement Apache Kafka.
## Amazon MSK version 3.3.2
Amazon Managed Streaming for Apache Kafka (Amazon MSK) prend désormais en charge la version 3.3.2 d'Apache Kafka pour les clusters nouveaux et existants. Apache Kafka 3.3.2 inclut plusieurs corrections de bogues et de nouvelles fonctionnalités qui améliorent les performances. Les principales fonctionnalités incluent un correctif pour améliorer la stabilité lors de l'extraction depuis la réplique la plus proche. Amazon MSK continuera d'utiliser et de gérer Zookeeper pour la gestion du quorum dans cette version. Pour une liste complète des améliorations et des corrections de bogues, consultez les notes de publication d'Apache Kafka pour la version 3.3.2.
Pour plus d'informations sur Apache Kafka, version 3.3.2, consultez ses [notes de mise à jour](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html) sur le site de téléchargement Apache Kafka.
## Amazon MSK version 3.3.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) prend désormais en charge la version 3.3.1 d'Apache Kafka pour les clusters nouveaux et existants. Apache Kafka 3.3.1 inclut plusieurs corrections de bogues et de nouvelles fonctionnalités qui améliorent les performances. Parmi les principales fonctionnalités, citons les améliorations apportées aux métriques et au partitionneur. Amazon MSK continuera d'utiliser et de gérer ZooKeeper pour la gestion du quorum dans cette version à des fins de stabilité. Pour une liste complète des améliorations et des corrections de bogues, consultez les notes de publication d'Apache Kafka pour la version 3.3.1.
Pour plus d'informations sur Apache Kafka, version 3.3.1, consultez ses [notes de mise à jour](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html) sur le site de téléchargement Apache Kafka.
## Amazon MSK version 3.1.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) prend désormais en charge les versions 3.1.1 et 3.2.0 d'Apache Kafka pour les clusters nouveaux et existants. Apache Kafka 3.1.1 et Apache Kafka 3.2.0 incluent plusieurs corrections de bogues et de nouvelles fonctionnalités qui améliorent les performances. Parmi les principales fonctionnalités, citons l'amélioration des métriques et l'utilisation du sujet IDs. MSK continuera d'utiliser et de gérer Zookeeper pour la gestion du quorum dans cette version à des fins de stabilité. Pour une liste complète des améliorations et des corrections de bogues, consultez les notes de publication d'Apache Kafka pour les versions 3.1.1 et 3.2.0.
Pour plus d'informations sur les versions 3.1.1 et 3.2.0 d'Apache Kafka, consultez ses [notes de mise à jour 3.2.0](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) et [3.1.1](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html) sur le site de téléchargement d'Apache Kafka.
## Stockage hiérarchisé Amazon MSK version 2.8.2.tiered
Cette version est une version uniquement Amazon MSK de la version 2.8.2 d'Apache Kafka et est compatible avec les clients Apache Kafka open source.
[La version 2.8.2.tiered contient des fonctionnalités de stockage hiérarchisé compatibles avec celles APIs introduites dans le KIP-405 pour Apache Kafka.](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage) Pour de plus amples informations sur la fonctionnalité de stockage hiérarchisé Amazon MSK, consultez [Stockage hiérarchisé pour les courtiers standard](msk-tiered-storage.md).
## Apache Kafka, version 2.5.1
La version 2.5.1 d'Apache Kafka inclut plusieurs corrections de bogues et de nouvelles fonctionnalités, notamment le chiffrement en transit pour Apache ZooKeeper et les clients d'administration. Amazon MSK fournit des ZooKeeper points de terminaison TLS, que vous pouvez interroger lors de l'opération. [DescribeCluster ](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)
Le résultat de l'[ DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)opération inclut le `ZookeeperConnectStringTls` nœud, qui répertorie les points de terminaison TLS Zookeeper.
L'exemple suivant montre le nœud `ZookeeperConnectStringTls` de la réponse à l'opération `DescribeCluster` :
```
"ZookeeperConnectStringTls": "z-3.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182,z-2.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182,z-1.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182"
```
Pour obtenir des informations sur l'utilisation du chiffrement TLS avec ZooKeeper, consultez [Utilisation de la sécurité TLS avec Apache ZooKeeper](zookeeper-security-tls.md).
Pour plus d'informations sur Apache Kafka, version 2.5.1, consultez ses [notes de mise à jour](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html) sur le site de téléchargement Apache Kafka.
## Version de correction de bogues Amazon MSK 2.4.1.1
Cette version est une version de correction de bogues uniquement pour Amazon MSK de la version 2.4.1 d'Apache Kafka. Cette version de correction de bogues contient un correctif pour [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752), un problème rare qui oblige les groupes de consommateurs à se rééquilibrer continuellement et à rester à l'état `PreparingRebalance`. Ce problème concerne les clusters exécutant les versions 2.3.1 et 2.4.1 d'Apache Kafka. Cette version contient un correctif produit par la communauté qui est disponible dans la version 2.5.0 d'Apache Kafka.
**Note**
Les clusters Amazon MSK exécutant la version 2.4.1.1 sont compatibles avec tous les clients Apache Kafka compatibles avec la version 2.4.1 d'Apache Kafka.
Nous vous recommandons d'utiliser la version de correction de bogues MSK 2.4.1.1 pour les nouveaux clusters Amazon MSK si vous préférez utiliser la version 2.4.1 d'Apache Kafka. Vous pouvez mettre à jour les clusters existants exécutant la version 2.4.1 d'Apache Kafka vers cette version afin d'intégrer ce correctif. Pour de plus amples informations sur la mise à niveau d'un cluster existant, consultez [Mettre à jour la version d'Apache Kafka](version-upgrades.md).
Pour contourner ce problème sans mettre à niveau le cluster vers la version 2.4.1.1, consultez la section [Groupe de consommateurs bloqué à l'état `PreparingRebalance`](troubleshooting.md#consumer-group-rebalance) du guide [Résoudre les problèmes liés à votre cluster Amazon MSK](troubleshooting.md).
## Apache Kafka version 2.4.1 (utilisez plutôt 2.4.1.1)
**Note**
Vous ne pouvez plus créer de cluster MSK avec la version 2.4.1 d'Apache Kafka. Vous pouvez plutôt utiliser [Version de correction de bogues Amazon MSK 2.4.1.1](#2.4.1.1) avec des clients compatibles avec la version 2.4.1 d'Apache Kafka. De même, si vous possédez déjà un cluster MSK avec la version 2.4.1 d'Apache Kafka, nous vous recommandons de le mettre à jour pour utiliser la version 2.4.1.1 d'Apache Kafka à la place.
KIP-392 est l'une des principales propositions d'amélioration de Kafka qui sont incluses dans la version 2.4.1 d'Apache Kafka. Cette amélioration permet aux consommateurs de récupérer le réplica le plus proche. Pour utiliser cette fonctionnalité, définissez `client.rack` dans les propriétés du consommateur pour l'ID de la zone de disponibilité du consommateur. Un exemple d'ID de zone de disponibilité est `use1-az1`. Amazon MSK définit `broker.rack` les zones IDs de disponibilité des courtiers. Vous devez également définir la propriété de configuration `replica.selector.class` sur `org.apache.kafka.common.replica.RackAwareReplicaSelector`, qui est une implémentation de la prise en compte du rack fournie par Apache Kafka.
Lorsque vous utilisez cette version d'Apache Kafka, les mesures du niveau de surveillance `PER_TOPIC_PER_BROKER` s'affichent seulement lorsque leurs valeurs sont devenues non nulles pour la première fois. Pour de plus amples informations à ce sujet, veuillez consulter [Surveillance de niveau `PER_TOPIC_PER_BROKER`](metrics-details.md#broker-topic-metrics).
Pour savoir comment trouver la zone de disponibilité IDs, voir [AZ IDs for Your Resource](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html) dans le guide de AWS Resource Access Manager l'utilisateur.
Pour plus d'informations sur la définition des propriétés de configuration, consultez [Configuration provisionnée d'Amazon MSK](msk-configuration.md).
Pour plus d'informations sur KIP-392, consultez [Autoriser les consommateurs à extraire du réplica le plus proche](https://cwiki.apache.org/confluence/display/KAFKA/KIP-392:+Allow+consumers+to+fetch+from+closest+replica) dans les pages Confluence.
Pour plus d'informations sur Apache Kafka, version 2.4.1, consultez ses [notes de mise à jour](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) sur le site de téléchargement Apache Kafka.
# Prise en charge des versions d'Amazon MSK
Cette rubrique décrit la procédure [Politique de support des versions d'Amazon MSK](#version-support-policy) et la procédure à suivre pour[Mettre à jour la version d'Apache Kafka](version-upgrades.md). Si vous mettez à jour votre version de Kafka, suivez les meilleures pratiques décrites dans[Bonnes pratiques pour les mises à niveau des versions](version-upgrades-best-practices.md).
**Topics**
+ [Politique de support des versions d'Amazon MSK](#version-support-policy)
+ [Mettre à jour la version d'Apache Kafka](version-upgrades.md)
+ [Bonnes pratiques pour les mises à niveau des versions](version-upgrades-best-practices.md)
## Politique de support des versions d'Amazon MSK
Cette section décrit la politique de support pour les versions de Kafka prises en charge par Amazon MSK.
+ Toutes les versions de Kafka sont prises en charge jusqu'à leur date de fin de support. Pour plus de détails sur les dates de fin de support, consultez[Versions Apache Kafka prises en charge](supported-kafka-versions.md). Mettez à niveau votre cluster MSK vers la version recommandée de Kafka ou une version supérieure avant la date de fin du support. Pour plus de détails sur la mise à niveau de votre version d'Apache Kafka, consultez[Mettre à jour la version d'Apache Kafka](version-upgrades.md). Un cluster utilisant une version de Kafka après sa date de fin de support est automatiquement mis à niveau vers la version recommandée de Kafka. Les mises à niveau automatiques peuvent avoir lieu à tout moment après la date de fin du support. Vous ne recevrez aucune notification avant la mise à niveau.
+ MSK supprimera progressivement le support pour les clusters nouvellement créés qui utilisent des versions de Kafka avec des dates de fin de support publiées.
# Mettre à jour la version d'Apache Kafka
Vous pouvez mettre à niveau un cluster MSK existant vers une version plus récente d'Apache Kafka. Avant de mettre à niveau la version Kafka de votre cluster, vérifiez que la version de votre logiciel côté client prend en charge les fonctionnalités de la nouvelle version de Kafka.
Pour plus d'informations sur la manière de rendre un cluster hautement disponible lors d'une mise à niveau, consultez[Créer des clusters hautement disponibles](bestpractices.md#ensure-high-availability).
**Mettez à jour la version d'Apache Kafka à l'aide du AWS Management Console**
1. Ouvrez la console Amazon MSK à l'adresse [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Dans la barre de navigation, choisissez la région dans laquelle vous avez créé le cluster MSK.
1. Choisissez le cluster MSK que vous souhaitez mettre à niveau.
1. Dans l'onglet **Propriétés**, choisissez **Mettre à niveau** dans la section **Version d'Apache Kafka**.
1. Dans la section **version d'Apache Kafka**, procédez comme suit :
1. Dans la liste déroulante *Choisir la version d'Apache Kafka*, choisissez la version cible vers laquelle vous souhaitez effectuer la mise à niveau. Par exemple, sélectionnez **3.9.x**.
1. (Facultatif) Choisissez **Afficher la compatibilité** des versions pour vérifier la compatibilité entre la version actuelle de votre cluster et les versions de mise à niveau disponibles. Sélectionnez ensuite **Choisir** pour continuer.
**Note**
Amazon MSK prend en charge les mises à niveau sur place vers la plupart des versions d'Apache Kafka. Toutefois, lors de la mise à niveau d'une version ZooKeeper basée sur Kafka vers une version KRaft basée sur Kafka, vous devez créer un nouveau cluster. Copiez ensuite vos données dans le nouveau cluster et transférez les clients vers le nouveau cluster.
1. (Facultatif) Cochez la case **Mettre à jour la configuration du cluster** pour appliquer les mises à jour de configuration compatibles avec la nouvelle version. Cela permet d'accéder aux fonctionnalités et aux améliorations de la nouvelle version.
Vous pouvez ignorer cette étape si vous devez conserver vos configurations personnalisées existantes.
**Note**
Les mises à niveau côté serveur ne mettent pas automatiquement à jour les applications clientes.
Pour maintenir la stabilité du cluster, les rétrogradations de version ne sont pas prises en charge.
1. Choisissez **Upgrade** pour démarrer le processus.
**Mettez à jour la version d'Apache Kafka à l'aide du AWS CLI**
1. Exécutez la commande suivante, en la *ClusterArn* remplaçant par le Amazon Resource Name (ARN) que vous avez obtenu lors de la création de votre cluster. Si vous n'avez pas l'ARN pour votre cluster, vous pouvez le trouver en listant tous les clusters. Pour de plus amples informations, veuillez consulter [Répertorier les clusters Amazon MSK](msk-list-clusters.md).
```
aws kafka get-compatible-kafka-versions --cluster-arn ClusterArn
```
Le résultat de cette commande inclut une liste des versions d'Apache Kafka vers lesquelles vous pouvez mettre à niveau le cluster. Elle ressemble à l'exemple suivant :
```
{
"CompatibleKafkaVersions": [
{
"SourceVersion": "2.2.1",
"TargetVersions": [
"2.3.1",
"2.4.1",
"2.4.1.1",
"2.5.1"
]
}
]
}
```
1. Exécutez la commande suivante, en la *ClusterArn* remplaçant par le Amazon Resource Name (ARN) que vous avez obtenu lors de la création de votre cluster. Si vous n'avez pas l'ARN pour votre cluster, vous pouvez le trouver en listant tous les clusters. Pour de plus amples informations, veuillez consulter [Répertorier les clusters Amazon MSK](msk-list-clusters.md).
Remplacez *Current-Cluster-Version* par la version actuelle du cluster. Car *TargetVersion* vous pouvez spécifier n'importe quelle version cible à partir de la sortie de la commande précédente.
**Important**
Les versions de cluster ne sont pas des entiers simples. Pour trouver la version actuelle du cluster, utilisez l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)opération ou la commande [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html) AWS CLI . Voici un exemple de version : `KTVPDKIKX0DER`.
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version TargetVersion
```
La sortie de la commande précédente ressemble au JSON suivant.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"ClusterOperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef"
}
```
1. Pour obtenir le résultat de l'`update-cluster-kafka-version`opération, exécutez la commande suivante en la *ClusterOperationArn* remplaçant par l'ARN que vous avez obtenu dans le résultat de la `update-cluster-kafka-version` commande.
```
aws kafka describe-cluster-operation --cluster-operation-arn ClusterOperationArn
```
La sortie de cette commande `describe-cluster-operation` ressemble à l'exemple JSON suivant.
```
{
"ClusterOperationInfo": {
"ClientRequestId": "62cd41d2-1206-4ebf-85a8-dbb2ba0fe259",
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"CreationTime": "2021-03-11T20:34:59.648000+00:00",
"OperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef",
"OperationState": "UPDATE_IN_PROGRESS",
"OperationSteps": [
{
"StepInfo": {
"StepStatus": "IN_PROGRESS"
},
"StepName": "INITIALIZE_UPDATE"
},
{
"StepInfo": {
"StepStatus": "PENDING"
},
"StepName": "UPDATE_APACHE_KAFKA_BINARIES"
},
{
"StepInfo": {
"StepStatus": "PENDING"
},
"StepName": "FINALIZE_UPDATE"
}
],
"OperationType": "UPDATE_CLUSTER_KAFKA_VERSION",
"SourceClusterInfo": {
"KafkaVersion": "2.4.1"
},
"TargetClusterInfo": {
"KafkaVersion": "2.6.1"
}
}
}
```
Si `OperationState` a la valeur `UPDATE_IN_PROGRESS`, attendez un moment, puis exécutez à nouveau la commande `describe-cluster-operation`. Lorsque l'opération est terminée, la valeur de `OperationState` devient `UPDATE_COMPLETE`. Étant donné que le temps nécessaire à Amazon MSK pour effectuer l'opération varie, vous devrez peut-être vérifier à plusieurs reprises jusqu'à ce que l'opération soit terminée.
**Mettre à jour la version d'Apache Kafka à l'aide de l'API**
1. Appelez l'[GetCompatibleKafkaVersions](https://docs.aws.amazon.com//msk/1.0/apireference/compatible-kafka-versions.html#GetCompatibleKafkaVersions)opération pour obtenir une liste des versions d'Apache Kafka vers lesquelles vous pouvez mettre à niveau le cluster.
1. Appelez l'[UpdateClusterKafkaVersion](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-version.html#UpdateClusterKafkaVersion)opération pour mettre à niveau le cluster vers l'une des versions compatibles d'Apache Kafka.
# Bonnes pratiques pour les mises à niveau des versions
Pour garantir la continuité du client pendant la mise à jour continue effectuée dans le cadre du processus de mise à niveau de la version de Kafka, passez en revue la configuration de vos clients et vos rubriques Apache Kafka comme suit :
+ Définissez le facteur de réplication (RF) du sujet sur une valeur minimale de `2` pour les clusters à deux AZ et une valeur minimale de `3` pour les clusters à trois AZ. Une valeur RF de `2` peut entraîner la création de partitions hors ligne lors de l'application de correctifs.
+ Définissez le nombre minimal de répliques synchronisées (MinISR) sur une valeur maximale inférieure de 1 à votre facteur de réplication (RF), qui est de. `miniISR = (RF) - 1` Cela garantit que le jeu de répliques de partitions peut tolérer qu'une réplique soit hors ligne ou sous-répliquée.
+ Configurez les clients pour qu'ils utilisent plusieurs chaînes de connexion de type broker. La présence de plusieurs courtiers dans la chaîne de connexion d'un client permet un basculement si un courtier spécifique prenant en charge le client I/O commence à recevoir un correctif. Pour plus d'informations sur la façon d'obtenir une chaîne de connexion avec plusieurs courtiers, consultez [Obtenir les courtiers bootstrap pour un cluster Amazon MSK](https://docs.aws.amazon.com//msk/latest/developerguide/msk-get-bootstrap-brokers.html).
+ Nous vous recommandons de mettre à niveau les clients de connexion vers la version recommandée ou une version supérieure pour bénéficier des fonctionnalités disponibles dans la nouvelle version. Les mises à niveau des clients ne sont pas soumises aux dates de fin de vie (EOL) de la version Kafka de votre cluster MSK et ne doivent pas nécessairement être terminées avant la date de fin de vie. Apache Kafka fournit une [politique de compatibilité client bidirectionnelle](https://kafka.apache.org/protocol#protocol_compatibility) qui permet aux anciens clients de travailler avec des clusters plus récents et vice versa.
+ Les clients Kafka utilisant les versions 3.x.x sont susceptibles de présenter les valeurs par défaut suivantes : et. `acks=all` `enable.idempotence=true` `acks=all`est différent de la valeur par défaut précédente de `acks=1` et offre une durabilité accrue en garantissant que toutes les répliques synchronisées accusent réception de la demande de production. De même, la valeur par défaut pour `enable.idempotence` était précédemment`false`. Le passage à `enable.idempotence=true` la valeur par défaut réduit le risque de doublons de messages. Ces modifications sont considérées comme des paramètres conformes aux meilleures pratiques et peuvent introduire une petite latence supplémentaire conforme aux paramètres de performance normaux.
+ Utilisez la version recommandée de Kafka lors de la création de nouveaux clusters MSK. L'utilisation de la version recommandée de Kafka vous permet de bénéficier des dernières fonctionnalités de Kafka et MSK.
# Résoudre les problèmes liés à votre cluster Amazon MSK
La documentation suivante peut vous aider à résoudre les problèmes que vous pouvez rencontrer avec votre cluster Amazon MSK. Vous pouvez également publier votre problème sur [AWS re:Post](https://repost.aws/). Pour résoudre les problèmes liés à Amazon MSK Replicator, consultez. [Résoudre les problèmes liés à MSK Replicator](msk-replicator-troubleshooting.md)
**Topics**
+ [Le remplacement du volume entraîne une saturation du disque en raison d'une surcharge de réplication](#replication-overload-disk-saturation)
+ [Groupe de consommateurs bloqué à l'état `PreparingRebalance`](#consumer-group-rebalance)
+ [Erreur lors de la transmission des journaux du courtier à Amazon CloudWatch Logs](#cw-broker-logs-error)
+ [Aucun groupe de sécurité par défaut](#troubleshooting-shared-vpc)
+ [Le cluster apparaît bloqué à l'état En cours de création.](#troubleshooting-cluster-stuck)
+ [L'état du cluster passe de En cours de création à En échec.](#troubleshooting-cluster-failed)
+ [L'état du cluster est Actif mais les producteurs ne peuvent pas envoyer de données ou les consommateurs ne peuvent pas en recevoir.](#troubleshooting-nodata)
+ [AWS CLI ne reconnaît pas Amazon MSK](#troubleshooting-nocli)
+ [Les partitions se déconnectent ou les réplicas sont désynchronisés](#troubleshooting-offlinepartition-outofsyncreplicas)
+ [L'espace disque est faible](#troubleshooting-lowdiskspace)
+ [Mémoire faible](#troubleshooting-lowmemory)
+ [Le producteur obtient NotLeaderForPartitionException](#troubleshooting-NotLeaderForPartitionException)
+ [Partitions sous-répliquées (URP) supérieures à zéro](#troubleshooting-urp)
+ [Le cluster contient des rubriques appelées \$1\$1amazon\$1msk\$1canary et \$1\$1amazon\$1msk\$1canary\$1state](#amazon_msk_canary)
+ [Échec de la réplication des partitions](#partition_replication_fails)
+ [Impossible d'accéder au cluster dont l'accès public est activé](#public-access-issues)
+ [Impossible d'accéder au cluster via le IPv6 bootstrap](#dualstack-issues)
+ [Impossible d'accéder au cluster depuis l'intérieur AWS : problèmes de réseau](#networking-trouble)
+ [Échec de l'authentification : trop de connexions](#troubleshoot-too-many-connects)
+ [Échec de l'authentification : session trop courte](#troubleshoot-session-too-short)
+ [MSK sans serveur : échec de la création du cluster](#troubleshoot-serverless-create-cluster-failure)
+ [Impossible de mettre à jour KafkaVersionsList dans la configuration MSK](#troubleshoot-kafkaversionslist-cfn-update-failure)
## Le remplacement du volume entraîne une saturation du disque en raison d'une surcharge de réplication
En cas de panne matérielle imprévue d'un volume, Amazon MSK peut remplacer le volume par une nouvelle instance. Kafka reremplit le nouveau volume en répliquant les partitions provenant d'autres courtiers du cluster. Une fois les partitions répliquées et rattrapées, elles peuvent devenir membres de Leadership and In-Sync Replica (ISR).
**Problème**
Dans un courtier qui se remet d'un remplacement de volume, certaines partitions de tailles différentes peuvent être remises en ligne avant d'autres. Cela peut être problématique car ces partitions peuvent servir du trafic provenant du même courtier qui continue de rattraper (répliquer) d'autres partitions. Ce trafic de réplication peut parfois saturer les limites de débit du volume sous-jacentes, qui sont de 250 MiB par seconde dans le cas par défaut. Lorsque cette saturation se produit, toutes les partitions déjà rattrapées seront affectées, ce qui se traduira par une latence au sein du cluster pour tous les courtiers partageant l'ISR avec les partitions rattrapées (et pas seulement les partitions principales en raison de prises distantes`acks=all`). Ce problème est plus fréquent dans le cas de grands clusters comportant un plus grand nombre de partitions dont la taille varie.
**Recommendation**
+ Pour améliorer la I/O posture de réplication, assurez-vous que les [paramètres de thread conformes aux meilleures pratiques](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html#optimize-broker-threads) sont en place.
+ Pour réduire le risque de saturation des volumes sous-jacents, activez le stockage provisionné avec un débit plus élevé. Une valeur de débit minimum de 500 MiB/s est recommandée pour les cas de réplication à haut débit, mais la valeur réelle requise varie en fonction du débit et du cas d'utilisation. [Provisionner le débit de stockage pour les courtiers standard dans un cluster Amazon MSK](msk-provision-throughput.md).
+ Pour minimiser la pression de réplication, abaissez `num.replica.fetchers` la valeur par défaut de`2`.
## Groupe de consommateurs bloqué à l'état `PreparingRebalance`
Si un ou plusieurs de vos groupes de consommateurs sont bloqués dans un état de rééquilibrage perpétuel, cela peut être dû au problème [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752) d'Apache Kafka, qui affecte les versions 2.3.1 et 2.4.1 d'Apache Kafka.
Pour résoudre ce problème, nous vous recommandons de mettre à niveau votre cluster vers la version [Version de correction de bogues Amazon MSK 2.4.1.1](supported-kafka-versions.md#2.4.1.1), qui contient un correctif pour ce problème. Pour plus d'informations sur la mise à jour d'un cluster existant vers la version de correction de bogues Amazon MSK 2.4.1.1, consultez [Mettre à jour la version d'Apache Kafka](version-upgrades.md).
Les solutions pour résoudre ce problème sans mettre à niveau le cluster vers la version de correction des bogues Amazon MSK 2.4.1.1 consistent soit à configurer les clients Kafka pour qu'ils utilisent [Protocole d'appartenance statique](#consumer-group-rebalance-static), soit à les placer sur le nœud d'agent de coordination [Identifier et redémarrer](#consumer-group-rebalance-reboot) du groupe de consommateurs bloqué.
### Mise en œuvre d'un protocole d'appartenance statique
Pour mettre en œuvre le protocole d'appartenance statique dans vos clients, procédez comme suit :
1. Définissez la propriété `group.instance.id` de la configuration de vos [consommateurs Kafka](https://kafka.apache.org/26/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html) sur une chaîne statique identifiant le consommateur dans le groupe.
1. Assurez-vous que les autres instances de la configuration sont mises à jour pour qu'elles utilisent la chaîne statique.
1. Déployez les modifications dans vos consommateurs Kafka.
L'utilisation du protocole d'appartenance statique est plus efficace si le délai d'expiration de la session dans la configuration client est défini sur une durée qui permet au consommateur de récupérer sans déclencher prématurément un rééquilibrage du groupe de consommateurs. Par exemple, si votre application consommateur peut tolérer 5 minutes d'indisponibilité, une valeur raisonnable pour le délai d'expiration de la session serait de 4 minutes au lieu de la valeur par défaut de 10 secondes.
**Note**
L'utilisation du protocole d'appartenance statique ne fait que réduire la probabilité de rencontrer ce problème. Vous pouvez toujours le rencontrer même lorsque vous utilisez le protocole d'appartenance statique.
### Redémarrage du nœud d'agent de coordination
Pour redémarrer le nœud d'agent de coordination, procédez comme suit :
1. Identifiez le coordinateur du groupe à l'aide de la commande `kafka-consumer-groups.sh`.
1. Redémarrez le coordinateur du groupe de consommateurs bloqué à l'aide de l'action [ RebootBroker](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-reboot-broker.html#RebootBroker)API.
## Erreur lors de la transmission des journaux du courtier à Amazon CloudWatch Logs
Lorsque vous essayez de configurer votre cluster pour envoyer les journaux des courtiers à Amazon CloudWatch Logs, il se peut que vous obteniez l'une des deux exceptions suivantes.
Si vous obtenez une exception `InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded`, réessayez mais utilisez les groupes de journaux qui commencent par `/aws/vendedlogs/`. Pour de plus amples informations, consultez [Activation de la journalisation à partir de certains services Amazon Web Services](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html).
En cas d'`InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded`exception, choisissez une politique Amazon CloudWatch Logs existante dans votre compte et ajoutez-y le code JSON suivant.
```
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}
```
Si vous essayez d'ajouter le JSON ci-dessus à une politique existante mais que vous recevez un message d'erreur indiquant que vous avez atteint la longueur maximale pour la politique que vous avez sélectionnée, essayez d'ajouter le JSON à une autre de vos politiques Amazon CloudWatch Logs. Après avoir ajouté le JSON à une politique existante, essayez à nouveau de configurer la livraison des journaux de courtage à Amazon Logs. CloudWatch
## Aucun groupe de sécurité par défaut
Si vous essayez de créer un cluster et que vous obtenez une erreur indiquant qu'il n'y a pas de groupe de sécurité par défaut, cela peut être dû au fait que vous utilisez un VPC partagé avec vous. Demandez à votre administrateur de vous accorder l'autorisation de décrire les groupes de sécurité sur ce VPC et réessayez. Pour obtenir un exemple de stratégie autorisant cette action, consultez [Amazon EC2 : Autorise la gestion des groupes de sécurité EC2 associés à un VPC spécifique, par programme et dans la console](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html).
## Le cluster apparaît bloqué à l'état En cours de création.
Parfois, la création de cluster peut prendre jusqu'à 30 minutes. Attendez 30 minutes et vérifiez à nouveau l'état du cluster.
## L'état du cluster passe de En cours de création à En échec.
Réessayez de créer le cluster.
## L'état du cluster est Actif mais les producteurs ne peuvent pas envoyer de données ou les consommateurs ne peuvent pas en recevoir.
+ Si la création du cluster réussit (l'état du cluster est `ACTIVE`), mais que vous ne pouvez pas envoyer ou recevoir de données, assurez-vous que vos applications producteur et grand public ont accès au cluster. Pour de plus amples informations, veuillez consulter [Étape 3 : Créer un ordinateur client](create-client-machine.md).
+ Si vos producteurs et consommateurs ont accès au cluster, mais rencontrent toujours des problèmes de production et de consommation de données, la cause peut être [KAFKA-7697](https://issues.apache.org/jira/browse/KAFKA-7697), qui affecte Apache Kafka version 2.1.0 et peut entraîner un blocage dans un ou plusieurs brokers. Envisagez de migrer vers Apache Kafka 2.2.1, qui n'est pas affecté par ce bogue. Pour de plus amples informations sur l'intégration, veuillez consulter [Migrer les charges de travail Kafka vers un cluster Amazon MSK](migration.md).
## AWS CLI ne reconnaît pas Amazon MSK
Si vous avez AWS CLI installé les commandes Amazon MSK, mais qu'elles ne les reconnaissent pas, passez AWS CLI à la dernière version. Pour obtenir des instructions détaillées sur la mise à niveau du AWS CLI, voir [Installation du AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html). Pour plus d'informations sur l'utilisation des commandes AWS CLI pour exécuter Amazon MSK, consultez[Caractéristiques et concepts clés d'Amazon MSK](operations.md).
## Les partitions se déconnectent ou les réplicas sont désynchronisés
Ceux-ci peuvent être des symptômes de faible espace disque. Consultez [L'espace disque est faible](#troubleshooting-lowdiskspace).
## L'espace disque est faible
Consultez les bonnes pratiques suivantes pour gérer l'espace disque : [Surveiller l'espace disque](bestpractices.md#bestpractices-monitor-disk-space) et [Ajuster les paramètres de rétention des données](bestpractices.md#bestpractices-retention-period).
## Mémoire faible
Si vous voyez que la métrique `MemoryUsed` est élevée ou que la métrique `MemoryFree` est faible, cela ne signifie pas qu'il y a un problème. Apache Kafka est conçu pour utiliser autant de mémoire que possible, et il le gère de manière optimale.
## Le producteur obtient NotLeaderForPartitionException
Il s'agit souvent d'une erreur transitoire. Définissez le paramètre de configuration `retries` du producteur sur une valeur supérieure à sa valeur actuelle.
## Partitions sous-répliquées (URP) supérieures à zéro
La métrique `UnderReplicatedPartitions` est importante à surveiller. Dans un cluster MSK sain, cette métrique a la valeur 0. Si elle est supérieure à zéro, cela peut être pour l'une des raisons suivantes.
+ Si `UnderReplicatedPartitions` est irrégulier, le problème peut être que le cluster n'est pas provisionné à la bonne taille pour gérer le trafic entrant et sortant. Consultez [Bonnes pratiques pour les courtiers standard](bestpractices.md).
+ S'il `UnderReplicatedPartitions` est constamment supérieur à 0, y compris pendant les périodes de faible trafic, le problème est peut-être que vous avez défini des restrictions ACLs qui n'accordent pas l'accès aux sujets aux courtiers. Pour répliquer les partitions, les brokers doivent être autorisés à lire et à décrire les rubriques. DESCRIBE est accordé par défaut avec l'autorisation READ. Pour plus d'informations sur le paramétrage ACLs, consultez la section [Autorisation et ACLs](https://kafka.apache.org/documentation/#security_authz) la documentation d'Apache Kafka.
## Le cluster contient des rubriques appelées \$1\$1amazon\$1msk\$1canary et \$1\$1amazon\$1msk\$1canary\$1state
Il se peut que votre cluster MSK possède une rubrique portant le nom `__amazon_msk_canary` et une autre portant le nom `__amazon_msk_canary_state`. Il s'agit de rubriques internes créées et utilisées par Amazon MSK pour les métriques d'intégrité et de diagnostic du cluster. Ces rubriques sont d'une taille négligeable et ne peuvent pas être supprimées.
## Échec de la réplication des partitions
Assurez-vous que vous n'avez pas ACLs activé CLUSTER\$1ACTIONS.
## Impossible d'accéder au cluster dont l'accès public est activé
Si l'accès public est activé sur votre cluster, mais que vous ne pouvez toujours pas y accéder depuis Internet, procédez comme suit :
1. Assurez-vous que les règles entrantes du groupe de sécurité du cluster autorisent votre adresse IP et le port du cluster. Pour obtenir la liste des numéros de port du cluster, consultez [Informations sur le port](port-info.md). Assurez-vous également que les règles sortantes du groupe de sécurité autorisent les communications sortantes. Pour plus d'informations sur les groupes de sécurité et leurs règles entrantes et sortantes, consultez [Groupes de sécurité pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) dans le Guide de l'utilisateur Amazon VPC.
1. Assurez-vous que votre adresse IP et le port du cluster sont autorisés dans les règles entrantes de l'ACL du réseau VPC du cluster. Contrairement aux groupes de sécurité, les réseaux ACLs sont apatrides. Cela signifie que vous devez configurer à la fois des règles entrantes et sortantes. Dans les règles sortantes, autorisez tout le trafic (plage de ports : 0 à 65535) vers votre adresse IP. Pour plus d'informations, consultez [Ajouter et supprimer des règles](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules) dans le Guide de l'utilisateur Amazon VPC.
1. Assurez-vous que vous utilisez la chaîne bootstrap-brokers à accès public pour accéder au cluster. Un cluster MSK dont l'accès public est activé possède deux chaînes bootstrap-brokers différentes, l'une pour l'accès public et l'autre pour l'accès depuis AWS. Pour de plus amples informations, veuillez consulter [Faites appel aux courtiers Bootstrap à l'aide du AWS Management Console](get-bootstrap-console.md).
## Impossible d'accéder au cluster via le IPv6 bootstrap
Si vous ne parvenez pas à vous connecter à un cluster à l'aide des chaînes IPv6 bootstrap fournies, procédez comme suit :
1. Assurez-vous que les adresses IPv4 et IPv6 sont attribuées à votre client. Votre application cliente doit s'exécuter dans un sous-réseau sur lequel l'adressage IPv4 et IPv6 est activé et correctement configuré. Vérifiez si votre VPC possède à la fois un bloc d'adresse CIDR IPv4 et un bloc d'adresse CIDR IPv6 associé, vérifiez que les adresses IPv4 et IPv6 de votre sous-réseau sont activées et vérifiez que les deux adresses sont attribuées à votre instance EC2 ou à votre environnement client. IPv4 IPv6 Pour plus d'informations, consultez la section [Adressage IP pour vos sous-réseaux VPCs et sous-réseaux](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) dans le guide de l'utilisateur Amazon VPC.
1. Assurez-vous que les IPv6 ports appropriés sont présents dans les règles entrantes et sortantes du groupe de sécurité. Ajoutez des règles entrantes pour autoriser le trafic sur les ports du cluster à partir de vos IPv6 adresses et configurez des règles sortantes pour autoriser IPv6 le trafic. Pour les numéros de port spécifiques, consultez les [informations sur les ports](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html) dans la documentation MSK. N'oubliez pas de mettre à jour à la fois IPv6 les règles IPv4 et les règles en cas d'exécution en mode double pile. Pour plus d'informations sur les groupes de sécurité et leurs règles entrantes et sortantes, consultez [Groupes de sécurité pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) dans le Guide de l'utilisateur Amazon VPC.
1. Assurez-vous que la configuration des propriétés JVM est correcte pour le IPv6 support. Dans votre application cliente, définissez `java.net.preferIPv6Addresses` sur `true` et `java.net.preferIPv4Stack` sur`false`. Ces paramètres peuvent être configurés en tant que propriétés du système ou en tant qu'arguments JVM. Redémarrez votre application après avoir effectué ces modifications pour qu'elles prennent effet.
## Impossible d'accéder au cluster depuis l'intérieur AWS : problèmes de réseau
Si vous disposez d'une application Apache Kafka qui ne parvient pas à communiquer avec un cluster MSK, commencez par effectuer le test de connectivité suivant.
1. Utilisez l'une des méthodes décrites dans [Obtenez les courtiers bootstrap pour un cluster Amazon MSK](msk-get-bootstrap-brokers.md) pour obtenir les adresses des brokers d’amorçage.
1. Dans la commande suivante, remplacez *bootstrap-broker* par l'une des adresses de courtier que vous avez obtenues à l'étape précédente. Remplacez *port-number* par 9094 si le cluster est configuré pour utiliser l'authentification TLS. Si le cluster n'utilise pas l'authentification TLS, remplacez-la *port-number* par 9092. Exécutez la commande à partir de l'ordinateur du client.
```
telnet bootstrap-broker port-number
```
Où le numéro de port est :
+ 9094 si le cluster est configuré pour utiliser l'authentification TLS.
+ 9092 Si le cluster n'utilise pas l'authentification TLS.
+ Un numéro de port différent est requis si l'accès public est activé.
Exécutez la commande à partir de l'ordinateur du client.
1. Répétez la commande précédente pour tous les brokers d’amorçage.
Si la machine cliente est en mesure d'accéder aux courtiers, cela signifie qu'il n'y a aucun problème de connectivité. Dans ce cas, exécutez la commande suivante pour vérifier si votre client Apache Kafka dispose de la configuration adéquate. Pour l'obtenir*bootstrap-brokers*, utilisez l'une des méthodes décrites dans[Obtenez les courtiers bootstrap pour un cluster Amazon MSK](msk-get-bootstrap-brokers.md). Remplacez *topic* par le nom de votre sujet.
```
/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic
```
Si la commande précédente réussit, cela signifie que votre client possède la bonne configuration. Si vous ne parvenez toujours pas à produire et à consommer à partir d'une application, déboguez le problème au niveau de cette dernière.
Si la machine cliente n'est pas en mesure d'accéder aux courtiers, consultez les sous-sections suivantes pour obtenir des instructions basées sur votre configuration client-machine.
### Client Amazon EC2 et cluster MSK dans le même VPC
Si l'ordinateur client se trouve dans le même VPC que le cluster MSK, assurez-vous que le groupe de sécurité du cluster dispose d'une règle entrante qui accepte le trafic provenant du groupe de sécurité de l'ordinateur client. Pour plus d'informations sur la configuration de ces règles, consultez [Règles des groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules). Pour obtenir un exemple de la façon d'accéder à un cluster à partir d'une instance Amazon EC2 située dans le même VPC que le cluster, consultez [Commencez à utiliser Amazon MSK](getting-started.md).
### Le client Amazon EC2 et le cluster MSK sont différents VPCs
Si la machine cliente et le cluster se trouvent dans deux emplacements différents VPCs, assurez-vous de ce qui suit :
+ Les deux VPCs sont regardés.
+ L'état de la connexion d'appairage soit actif.
+ Les tables de routage des deux VPCs sont correctement configurées.
Pour de plus amples informations sur l'appairage de VPC, veuillez consulter [Utilisation des connexions d'appairage de VPC](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html).
### Client sur site
Dans le cas d'un client sur site configuré pour se connecter au cluster MSK à l'aide de Site-to-Site VPN, assurez-vous de ce qui suit :
+ Le statut de la connexion VPN est `UP`. Pour de plus amples informations sur la façon de vérifier le statut de la connexion VPN, veuillez consulter [Comment vérifier le statut actuel d’un tunnel VPN ?](https://aws.amazon.com/premiumsupport/knowledge-center/check-vpn-tunnel-status/)
+ La table de routage du VPC du cluster contient la route d'un CIDR sur site dont la cible a le format `Virtual private gateway(vgw-xxxxxxxx)`.
+ Le groupe de sécurité du cluster MSK autorise le trafic sur les ports 2181, 9092 (si votre cluster accepte le trafic en texte brut) et 9094 (si votre cluster accepte le trafic chiffré TLS).
Pour plus d'informations sur la Site-to-Site VPN résolution des problèmes, consultez la section [Résolution des problèmes liés au VPN du Client](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/troubleshooting.html).
### Direct Connect
Si le client l'utilise Direct Connect, consultez la section [Résolution des problèmes Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html).
Si les instructions données dans la résolution de problèmes ne suffisent pas, vérifiez si un pare-feu ne bloque pas le trafic. Pour un débogage plus poussé, utilisez des outils comme `tcpdump` et `Wireshark` pour analyser le trafic et pour vous assurer qu'il atteint le cluster MSK.
## Échec de l'authentification : trop de connexions
L'erreur `Failed authentication ... Too many connects` indique qu'un agent se protège parce qu'un ou plusieurs clients IAM tentent de s'y connecter à un rythme effréné. Pour aider les agents à accepter un taux plus élevé de nouvelles connexions IAM, vous pouvez augmenter le paramètre de configuration [https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms](https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms).
Pour en savoir plus sur les limites de taux applicables aux nouvelles connexions par agent, consultez la page [Quota d'Amazon MSK](limits.md).
## Échec de l'authentification : session trop courte
L'`Failed authentication ... Session too short`erreur se produit lorsque votre client essaie de se connecter à un cluster à l'aide d'informations d'identification IAM sur le point d'expirer. Assurez-vous de vérifier comment vos informations d'identification IAM sont actualisées. Il est fort probable que les informations d'identification soient remplacées trop près de l'expiration de la session, ce qui entraîne des problèmes côté serveur et des échecs d'authentification.
## MSK sans serveur : échec de la création du cluster
Si vous essayez de créer un cluster MSK sans serveur et que le flux de travail échoue, vous n'êtes peut-être pas autorisé à créer un point de terminaison de VPC. Vérifiez que votre administrateur vous a autorisé à créer un point de terminaison de VPC en autorisant l'action `ec2:CreateVpcEndpoint`.
Pour obtenir la liste complète des autorisations requises pour effectuer toutes les actions Amazon MSK, consultez [AWS politique gérée : Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md).
## Impossible de mettre à jour KafkaVersionsList dans la configuration MSK
Lorsque vous mettez à jour la [KafkaVersionsList](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-kafkaversionslist)propriété dans la [AWS::MSK::Configuration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html)ressource, la mise à jour échoue avec l'erreur suivante.
```
Resource of type 'AWS::MSK::Configuration' with identifier '' already exists.
```
Lorsque vous mettez à jour la `KafkaVersionsList` propriété, AWS CloudFormation recrée une nouvelle configuration avec la propriété mise à jour avant de supprimer l'ancienne configuration. La mise à jour de la CloudFormation pile échoue car la nouvelle configuration utilise le même nom que la configuration existante. Une telle mise à jour nécessite le [remplacement d'une ressource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html#update-replacement). Pour réussir la mise à jour`KafkaVersionsList`, vous devez également mettre à jour la propriété [Name](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-name) au cours de la même opération.
En outre, si votre configuration est associée à des clusters créés à l'aide du AWS Management Console ou AWS CLI, ajoutez ce qui suit à votre ressource de configuration pour éviter l'[échec des tentatives de suppression](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted) de ressources.
```
UpdateReplacePolicy: Retain
```
Une fois la mise à jour réussie, accédez à la console Amazon MSK et supprimez l'ancienne configuration. Pour de plus amples informations sur les configurations MSK, veuillez consulter [Configuration provisionnée d'Amazon MSK](msk-configuration.md).