FerroStash Container
Container compatible Logstash natif Rust pour Amazon EKS
Quand est-ce amorti ?
Exemple : 5 000 $/mois de dépenses d’observabilité managée
Avec 5 000 $/mois de dépenses d’observabilité managée, une réduction conservatrice de 40% représente environ 2 000 $/mois de frais d’usage bruts évités — avant frais logiciels S4, EC2 et différences de charge de travail.
Estimez vos économies
Saisissez vos dépenses ou votre usage mensuel pertinent — aucun transfert de facture requis.
Build container de FerroStash. Déployez le pipeline de logs et d’événements compatible Logstash, natif Rust, sous forme d’un binaire statique unique sur Amazon EKS via le chart Helm inclus. Implémente le sous-ensemble courant en production des plugins fournis avec Logstash 9.x (98 sur 111, ~88%), parse nativement le DSL `pipeline.conf`, sans JVM, démarrage en millisecondes. Mesuré au pod-hour.
Là où un pipeline Logstash typique réserve environ un gigabyte de heap JVM et met des dizaines de secondes à démarrer, FerroStash Container exécute un seul binaire Rust comme pod EKS. C’est le même binaire de la ligne v1.0 que le build AMI et il couvre ~88% des plugins fournis avec Logstash 9.x — les inputs incluent beats, file, tcp, udp, http, syslog, kafka, redis, s3, sqs, jdbc, elasticsearch et cloudwatch ; les filters incluent grok, dissect, kv, json, mutate, date, geoip, dns, csv, xml, useragent, cidr, fingerprint, translate, aggregate, throttle et un script natif de style Painless ; les outputs incluent elasticsearch / opensearch, kafka, s3, http, tcp, udp, file, redis, sqs, sns, cloudwatch, email et datadog ; les codecs incluent json, json_lines, multiline, cef, netflow, avro, msgpack et protobuf — pilotés par un `pipeline.conf` templatisé rendu dans un `ConfigMap`. Le chart Helm expose Elastic Beats sur tcp/5044 et l’API de monitoring sur tcp/9600. Le container vérifie l’entitlement via `RegisterUsage` au démarrage, exclut le filter optionnel `ruby` et est pris en charge en topologie single-node. Portée honnête : il est compatible avec la configuration et les pipelines Logstash, pas un drop-in 100% identique octet pour octet.
Points forts
Chart Helm pour Amazon EKS inclus : `pipeline.conf` rendu via un `ConfigMap`, Elastic Beats sur tcp/5044 + API de monitoring sur tcp/9600.
Environ 88% des plugins fournis avec Logstash 9.x (98 sur 111) dans un seul binaire Rust — pas de JVM, démarrage en ms, quelques dizaines de MB de RAM.
Mesure au pod-hour avec entitlement Marketplace fail-closed : `RegisterUsage` vérifié au démarrage. Filter `ruby` exclu ; la topologie prise en charge est single-node.
Pourquoi c'est moins cher
Hypothèse : 10 Pods sur un cluster EKS existant avec sidecars Logstash traitant 5 TB/mois de logs.
- vCPU / RAM supplémentaires (≈ m5.large × 5)
- $350 / mois
- Total mensuel
- $350 / mois
- vCPU / RAM supplémentaires (négligeable, ≈ t3.small × 1)
- $15 / mois
- Frais logiciels FerroStash (10 × horaires)
- $45 / mois
- Total mensuel
- $60 / mois
Dimensionner FerroStash Container selon les sidecars
| Sidecars | Frais logiciels FerroStash | Coût des nodes supplémentaires (Logstash) | Total mensuel vs sidecars Logstash |
|---|---|---|---|
| ~5 Pods | $22 / mois | $175 / mois | $30 / mois (−83 %) |
| ~10 Pods | $45 / mois | $350 / mois | $60 / mois (−83 %) |
| ~100 Pods | $450 / mois | $3,500 / mois | $600 / mois (−83 %) |
Exemple à titre indicatif. Logstash sur JVM nécessite ~1 GB de heap par Pod, donc 10 sidecars exigent la marge de ressources d'environ 5 nodes m5.large. FerroStash Container utilise quelques dizaines de MB de RAM avec un démarrage en ms et se colocalise quasi gratuitement avec les Pods existants. Les frais du control plane EKS sont omis, en supposant un cluster existant.
Modèle de tarification
Frais logiciels horaires par pod facturés par AWS + les nodes EC2 dans votre propre cluster EKS. Pas de clés de licence ; entitlement vérifié via Marketplace `RegisterUsage`.
Autres produits S4
S4 — Squished S3
Gateway transparent de compression S3 par GPU
S4 Logs
Archiver CloudWatch Logs vers S3 zstd
S4 Metrics
Gouverner la cardinalité des métriques CloudWatch