SecOps Toolkit

Calculateur de coûts de stockage des logs : SIEM ou stockage cloud

Décider où stocker les logs de sécurité est l’un des postes les plus difficiles à budgéter dans un SOC. Ce calculateur compare, en USD par mois et par an, le coût de conservation de vos logs dans un stockage objet (AWS S3, Glacier, Cloudflare R2, Backblaze B2 et Wasabi) à une référence pour Splunk Cloud et AWS CloudWatch Logs.

Le calcul inclut la rétention à chaud et à froid, la compression, les recherches mensuelles, les frais d’egress et de restauration, et vous pouvez ajuster tous les prix selon vos propres devis.

Pourquoi le coût des logs croît plus vite que l’infrastructure

Dans la plupart des organisations, le volume des logs de sécurité et applicatifs double tous les quelques mois : plus de microservices, plus de postes, plus d’événements d’authentification et plus de trafic réseau. Les SIEM traditionnels facturent au volume ingéré : chaque gigaoctet qui entre a un prix, qu’il soit ensuite consulté ou non. Stocker les mêmes données dans un stockage objet coûte une fraction de ce prix, mais introduit d’autres coûts souvent négligés : frais de restauration et frais de transfert sortant (egress).

Modèle de calcul et formules

Le calculateur utilise un modèle en régime stationnaire : il suppose que la rétention est déjà complète et que chaque mois compte 30 jours. Les niveaux chaud et froid sont dimensionnés sur les données compressées :

  • Ingestion brute mensuelle : I = Go_jour × 30
  • Volume compressé quotidien : Vc = Go_jour / r, où r est le taux de compression.
  • Stockage chaud et froid : C = Vc × jours_chaud et F = Vc × jours_froid
  • Coût de stockage : C × prix_chaud + F × prix_froid, avec des prix en USD par Go-mois.
  • Données lues par mois : L = recherches × Go_par_recherche / r. Si une fraction p des recherches interroge l’archive froide, L_froid = L × p et L_chaud = L − L_froid.
  • Egress : max(0, L − g × (C + F)) × prix_egress, où g est l’egress gratuit exprimé en multiple des données stockées (3 chez Backblaze B2 et 0 chez les autres).
  • Restauration Glacier : L_froid × prix_restauration
  • Splunk Cloud (référence) : I × prix_par_Go_ingéré plus l’archive à froid.
  • CloudWatch Logs : I × prix_ingestion + C × prix_stockage + (L_chaud × r) × prix_Insights

Exemple chiffré avec les valeurs par défaut

Avec 200 Go par jour non compressés, 30 jours à chaud, 335 jours à froid et un taux de compression de 8:1, l’ingestion brute atteint 6 000 Go par mois, le volume compressé quotidien est de 25 Go, et environ 750 Go sont stockés à chaud et 8 375 Go à froid. Avec les prix catalogue approximatifs fournis par défaut, S3 Standard avec Glacier avoisine 115 USD par mois, Backblaze B2 environ 55 USD, Wasabi environ 64 USD, Cloudflare R2 environ 137 USD et S3 uniquement en Standard environ 277 USD. Les estimations de référence pour CloudWatch Logs et Splunk Cloud, facturés à l’ingestion, se situent respectivement autour de 3 100 et 24 000 USD par mois. Les chiffres exacts dépendent des prix que vous modifiez.

Ce qu’il faut savoir sur chaque fournisseur

  • AWS S3 Standard : stockage objet à haute disponibilité, sans frais de restauration mais avec un egress vers Internet.
  • S3 Glacier Flexible Retrieval : très économique par Go, avec des frais de restauration, une latence de restauration et 90 jours de stockage minimum. Idéal pour l’archive froide.
  • Cloudflare R2 : compatible avec l’API S3 et sans frais d’egress, ce qui favorise les lectures fréquentes.
  • Backblaze B2 : prix de stockage bas et egress gratuit jusqu’à trois fois les données stockées.
  • Wasabi : tarif de stockage forfaitaire sans egress dans le cadre d’une politique d’usage raisonnable, avec une durée minimale de stockage.
  • Splunk Cloud et CloudWatch Logs : incluent l’indexation et la recherche, mais sont facturés surtout au volume ingéré, d’où leur rôle de référence coûteuse dans le tableau.

Architecture de référence : stockage hiérarchisé

Une architecture courante pour réduire les coûts sépare la recherche interactive de la conservation réglementaire. Les collecteurs envoient les événements à un pipeline qui les route selon leur criticité : les événements à forte valeur (authentification, EDR, pare-feu) vont au SIEM pendant 30 à 90 jours, tandis que la totalité du volume est archivée compressée (gzip ou Parquet) dans un stockage objet, partitionnée par date et par source. Pour une investigation historique, un moteur de requête sur objets ne lit que les partitions nécessaires. Le SIEM indexe ainsi moins de données et l’archive satisfait la rétention exigée ; PCI DSS demande par exemple de conserver l’historique des logs d’audit au moins 12 mois, dont trois mois immédiatement disponibles.

Dans l’espace francophone, d’autres éléments entrent en jeu : les logs contenant des adresses IP sont des données personnelles soumises au principe de limitation de la conservation de l’article 5, paragraphe 1, point e) du RGPD, et la CNIL recommande généralement une durée de conservation de l’ordre de six mois à un an pour les traces de journalisation. L’ANSSI publie par ailleurs des recommandations de sécurité pour la mise en œuvre d’un système de journalisation. De nombreuses organisations choisissent aussi des régions situées dans l’Union européenne, comme Paris ou Francfort, pour répondre à leurs exigences de localisation des données.

Cas d’usage concrets

  • Budgétiser une migration de SIEM : comparer le coût annuel d’un stockage entièrement à chaud avec un modèle hiérarchisé.
  • Respecter les obligations de conservation : dimensionner une archive de 12 mois ou plus sans payer l’indexation de données rarement consultées.
  • MSSP et équipes FinOps : estimer le coût par client et repérer le point où l’egress dépasse l’économie de stockage.
  • Choisir le fournisseur d’archivage : mesurer le poids de l’egress lorsque les recherches s’exécutent hors du réseau du fournisseur.

Limites du modèle

L’outil n’inclut ni les frais de requêtes (PUT, GET, LIST), ni les coûts de calcul du moteur de requête, ni les remises d’engagement, ni les taxes. Les prix sont des valeurs catalogue approximatives qui changent souvent, et le taux de compression réel dépend du format et de la répétitivité de vos logs. Servez-vous des résultats pour comparer des ordres de grandeur et remplacez-les par des devis réels avant toute décision d’achat.

Questions fréquentes

Quel est le taux de compression typique des logs ?
Les logs textuels sont très répétitifs et se compressent bien avec gzip ou zstd, avec des taux courants de 5:1 à 10:1 et parfois nettement supérieurs pour les logs très structurés. Les formats en colonnes comme Parquet peuvent améliorer encore ce résultat. En revanche, les logs contenant des charges binaires, des identifiants aléatoires ou des données déjà chiffrées se compressent moins bien. Si vous ne connaissez pas votre taux réel, compressez un échantillon représentatif d’une journée et mesurez la différence de taille avant de vous fier à la valeur par défaut.
Que sont les frais d’egress et pourquoi comptent-ils pour l’archivage des logs ?
L’egress désigne les frais facturés par un fournisseur pour les données qui sortent de son réseau vers Internet ou vers un autre cloud. Si votre SIEM ou votre moteur de requête s’exécute hors du fournisseur de stockage, chaque recherche dans l’archive génère de l’egress. Chez des fournisseurs comme AWS, ces frais peuvent dépasser le coût du stockage en cas de consultation intensive, alors que Cloudflare R2 n’en facture pas et que Backblaze B2 offre une franchise. Si vos recherches s’exécutent dans le même cloud et la même région, vous pouvez désactiver l’interrupteur d’egress.
Les prix du calculateur sont-ils officiels ?
Non. Ce sont des prix catalogue publics approximatifs, utiles pour comparer des ordres de grandeur, et ils ont pu changer. Les coûts réels dépendent de la région, du volume, des remises d’engagement et du contrat avec chaque fournisseur. C’est pourquoi le calculateur permet de modifier tous les prix unitaires dans le panneau prévu à cet effet. Avant de décider, remplacez-les par vos devis ou par les calculateurs officiels de chaque fournisseur, et considérez les lignes Splunk Cloud et CloudWatch comme des estimations de référence.
Combien de temps conserver les logs à chaud et à froid ?
Cela dépend de votre cas d’usage et de la réglementation applicable. Pour la détection et la réponse aux incidents, de nombreuses équipes conservent entre 30 et 90 jours de données immédiatement interrogeables. Pour l’audit et la conformité, l’archive à froid peut être étendue à 12 mois ou plus ; PCI DSS exige par exemple au moins 12 mois d’historique de logs d’audit, dont trois mois immédiatement disponibles. Pour les logs contenant des données personnelles, le principe de limitation de la conservation du RGPD s’applique en plus. Validez les durées exactes avec votre responsable conformité et votre délégué à la protection des données.
Mes données de volume de logs sont-elles envoyées à un serveur ?
Non. Le calcul s’exécute entièrement dans votre navigateur en JavaScript. Les valeurs saisies, comme les Go quotidiens, les jours de rétention ou les prix que vous modifiez, ne sont ni transmises ni stockées sur un serveur de SecOps Toolkit. Vous pouvez donc utiliser les chiffres réels de votre organisation sans les exposer.