Kafka auto-géré ou managé : faut-il exploiter Kafka soi-même ou passer par un service Kafka managé ? La réponse dépend moins du prix des instances que de quatre postes souvent sous-estimés : les compétences et l'astreinte, les montées de version, le trafic réseau et les limites fonctionnelles des offres. Un service managé est généralement pertinent pour une équipe réduite déjà installée dans un cloud public. L'auto-gestion se justifie lorsque des exigences de souveraineté, un déploiement sur site ou un volume important s'appuient sur une équipe compétente et durable.
Entre les deux, les opérateurs Kubernetes ouvrent une troisième voie, qui automatise une partie de l'exploitation sans la faire disparaître. Dans tous les cas, la décision doit reposer sur un coût total chiffré, et non sur la comparaison d'une facture cloud avec le prix de quelques machines virtuelles.
Ce que coûte vraiment un cluster Kafka auto-géré
Les compétences et l'astreinte
Un cluster Kafka de production se dimensionne, se sécurise, se supervise et se répare. Il faut savoir diagnostiquer un déséquilibre de partitions, une réplication en retard ou un consommateur bloqué, souvent en dehors des heures ouvrées. Le poste principal est donc humain : au moins deux personnes formées pour assurer la continuité de l'astreinte, du temps de veille sur les versions et un budget de formation récurrent. Ce coût existe même lorsque le cluster fonctionne bien.
Les montées de version
Le passage à Kafka 4.x illustre ce coût. Le mode ZooKeeper a été retiré : un cluster sous ZooKeeper doit être migré vers KRaft avant toute montée en 4.0 ou au-delà 1. La version 3.9 a été annoncée comme la dernière version majeure à embarquer ZooKeeper et sert de version pont vers la 4.0 2. Les brokers exigent en outre Java 17 depuis la 4.0 1. La migration implique donc un inventaire, des tests sur un environnement représentatif et une bascule maîtrisée.
Le mouvement continue : Kafka 4.3 annonce déjà des dépréciations en vue de Kafka 5.0, dont des métriques MirrorMaker et un paramètre de configuration des brokers 7. Un parc auto-géré doit intégrer ce rythme dans sa feuille de route, faute de quoi la dette d'exploitation s'accumule.
Le stockage
Conserver longtemps des données dans Kafka coûte cher en disques répliqués. Le stockage hiérarchisé, déclaré prêt pour la production dans Kafka 3.9, permet de déporter les segments anciens vers un stockage objet 2. C'est un levier d'économie réel, mais il ajoute une dépendance à un stockage objet et des paramètres à maîtriser, que Kafka 4.3 continue d'enrichir 7.
Les coûts cachés d'un service Kafka managé
Des dimensions de facturation multiples
Le prix d'un service Kafka managé ne se résume pas à un coût horaire. Sur Amazon MSK, par exemple, le mode provisionné facture les heures de broker, le stockage et, pour les brokers Express, le volume de données écrit ; le mode Serverless facture l'heure de cluster, chaque partition, les volumes écrits et lus et le stockage 3. La connectivité privée ajoute un coût horaire et un coût par gigaoctet traité, et Kafka Connect managé est facturé à l'unité de calcul et à l'heure 3. Un modèle de coûts sérieux doit donc reproduire le profil réel de trafic, de partitions et de rétention.
Le réseau entre zones de disponibilité
Le trafic réseau est l'un des postes les plus souvent oubliés. Sur MSK, la réplication entre brokers n'est pas facturée 3, mais les consommateurs qui lisent depuis un leader situé dans une autre zone génèrent du trafic inter-zones. AWS documente la lecture depuis le réplica le plus proche (KIP-392), configurée côté broker et via le paramètre client.rack côté consommateur, et indique qu'elle peut réduire jusqu'aux deux tiers ce trafic facturé 4. Ce type de réglage, rarement activé par défaut, pèse lourd sur les flux à fort volume.
Les limites fonctionnelles et la dépendance
Tous les services ne sont pas des clusters Kafka. Azure Event Hubs expose un point d'accès compatible avec le protocole Kafka ; à la date de rédaction, Kafka Streams et les transactions y sont en préversion sur les niveaux Premium et Dedicated, et seule la compression gzip est prise en charge 6. Une incompatibilité découverte tardivement peut coûter plus cher qu'une année d'exploitation.
La dépendance fournisseur doit aussi être évaluée dans la durée. Le rachat de Confluent par IBM, finalisé le 17 mars 2026 8, rappelle que la feuille de route, le modèle commercial et l'interlocuteur d'une plateforme peuvent évoluer pendant la vie d'un contrat. Les clauses de réversibilité et la capacité technique à répliquer vers une autre plateforme font partie du coût.
Le prix affiché d'un cluster Kafka ne dit presque rien de son coût réel : ce sont les personnes, le réseau et les migrations qui font la différence.
Kubernetes et opérateurs : une troisième voie
Pour les organisations qui exploitent déjà Kubernetes, un opérateur permet de déclarer un cluster Kafka comme une ressource et d'automatiser son cycle de vie. Strimzi, projet en incubation à la CNCF depuis février 2024, prend en charge le déploiement et la mise à jour des clusters, la gestion des topics et celle des utilisateurs et de leurs droits 5.
Cette voie réduit le travail répétitif et rend l'infrastructure reproductible, sur site comme dans un cloud de confiance. Elle ne supprime pas les compétences Kafka nécessaires au diagnostic, et elle en ajoute d'autres : stockage persistant, réseau et sécurité Kubernetes. Elle convient aux équipes plateforme matures qui veulent garder la maîtrise sans tout opérer à la main.
Le choix n'est d'ailleurs pas forcément exclusif. De nombreux SI combinent un cluster auto-géré, sur site ou en cloud de confiance, pour les flux sensibles, et un service managé pour les usages analytiques ou les environnements hors production. Ce modèle hybride exige une réplication fiable entre plateformes, une gouvernance des schémas et des droits commune, et une supervision unifiée. Il multiplie les compétences nécessaires, mais permet d'appliquer à chaque flux le niveau de maîtrise qui lui correspond.
Grille de décision : Kafka auto-géré ou managé ?
Plutôt que de chercher une réponse universelle, il est utile d'évaluer chaque critère et de pondérer selon le contexte. Les questions suivantes couvrent l'essentiel.
- Souveraineté et réglementation : les données peuvent-elles être opérées par un fournisseur soumis à une juridiction extra-européenne ? Un cloud qualifié ou un déploiement sur site est-il exigé ?
- Compétences : disposez-vous d'au moins deux personnes capables d'exploiter et de diagnostiquer Kafka, et pouvez-vous les retenir ?
- Volumes et profil de trafic : débit, nombre de partitions, rétention et ratio lecture/écriture, qui déterminent la facture d'un service managé.
- Fonctionnalités requises : transactions, Kafka Streams, share groups, stockage hiérarchisé, connecteurs spécifiques.
- Localisation des producteurs et consommateurs : sur site, dans un ou plusieurs clouds, ce qui conditionne les coûts réseau.
- Réversibilité : capacité à migrer les données, les schémas et les configurations vers une autre plateforme dans un délai acceptable.
Comment chiffrer honnêtement les deux options
Un chiffrage crédible compare des périmètres équivalents sur trois ans, en incluant les coûts ponctuels et récurrents. La démarche suivante limite les angles morts.
- Mesurer sur l'existant ou estimer pour la cible le débit entrant et sortant, le nombre de partitions et la rétention par topic.
- Appliquer ces volumes à la grille tarifaire publique de chaque offre, dimension par dimension, y compris connectivité privée et connecteurs 3.
- Estimer le trafic inter-zones et l'effet d'une lecture depuis le réplica le plus proche 4.
- Valoriser les équivalents temps plein d'exploitation, d'astreinte et de veille pour l'option auto-gérée.
- Ajouter les projets de montée de version prévisibles, dont la migration vers KRaft si elle n'est pas faite 1.
- Chiffrer un scénario de sortie : coût et durée d'une migration vers une autre plateforme.
Ce travail relève directement de la démarche FinOps : il rend visibles des coûts dispersés entre budgets d'infrastructure, de personnel et de réseau, et permet un arbitrage fondé sur des hypothèses explicites plutôt que sur des impressions.
Conclusion
Il n'existe pas de bonne réponse universelle entre Kafka auto-géré et managé, mais il existe une mauvaise méthode : comparer des prix unitaires. Les coûts déterminants sont humains, réseau et liés aux évolutions de version, et la souveraineté peut à elle seule trancher le débat. DATASWING aide les DSI à construire ce chiffrage et à choisir un modèle d'exploitation cohérent avec leurs contraintes.
— Questions fréquentes
Ce qu'on nous demande souvent
Combien de personnes faut-il pour exploiter Kafka en interne ?+
Il n'existe pas de ratio universel, mais la continuité d'une astreinte impose en pratique au moins deux personnes formées à l'exploitation et au diagnostic de Kafka, complétées par des compétences sur l'infrastructure sous-jacente. Ce besoin existe dès le premier cluster de production, quel que soit le volume, et doit être intégré au coût total de l'option auto-gérée.
Faut-il migrer vers KRaft avant de passer à Kafka 4 ?+
Oui. Kafka 4.0 ne prend plus en charge ZooKeeper : un cluster sous ZooKeeper doit être migré vers KRaft avant de pouvoir être mis à jour en 4.x. La version 3.9 a été présentée comme la dernière à embarquer ZooKeeper et comme version pont. Les brokers 4.x exigent par ailleurs Java 17, ce qui peut imposer une mise à jour des environnements d'exécution.
Comment réduire les coûts réseau d'un cluster Kafka dans le cloud ?+
Le levier principal consiste à faire lire les consommateurs depuis le réplica situé dans leur propre zone de disponibilité, grâce au mécanisme de lecture depuis le réplica le plus proche (KIP-392) et au paramètre client.rack. AWS indique que ce réglage peut réduire jusqu'aux deux tiers le trafic inter-zones facturé des consommateurs MSK. La compression et le regroupement des messages complètent ce levier.
Strimzi est-il adapté à la production ?+
Strimzi est un opérateur Kubernetes pour Kafka, accepté en incubation à la CNCF en février 2024. Il automatise le déploiement, les mises à jour, la gestion des topics et des utilisateurs. Il convient à des équipes qui maîtrisent déjà Kubernetes en production, car il ajoute les sujets de stockage persistant et de réseau Kubernetes à l'exploitation de Kafka elle-même.
— Sources
Références citées
Les textes réglementaires et documentations évoluent : vérifiez la version en vigueur avant toute décision. Cet article n'est pas un avis juridique.
-
[1]
Upgrading to 4.0 (Apache Kafka documentation) ↗Apache Software Foundation · 2025
-
[2]
Apache Kafka 3.9.0 Release Announcement ↗Apache Software Foundation · 2024-11
-
[3]
Amazon MSK pricing ↗Amazon Web Services · 2026
-
[4]
Reduce network traffic costs of your Amazon MSK consumers with rack awareness ↗AWS Big Data Blog · 2022-08
-
[5]
Strimzi joins the CNCF Incubator ↗Cloud Native Computing Foundation · 2024-02
-
[6]
Azure Event Hubs for Apache Kafka overview ↗Microsoft Learn · 2026
-
[7]
Apache Kafka 4.3.0 Release Announcement ↗Apache Software Foundation · 2026-05
-
[8]
IBM Completes Acquisition of Confluent, Making Real-Time Data the Engine of Enterprise AI and Agents ↗IBM (PR Newswire) · 2026-03
