- Deux ans après avoir partagé son expérience de migration d’AWS vers le bare metal avec 230 000 $ d’économies annuelles, voici un rapport qui rassemble des réponses de suivi aux nombreuses questions de la communauté. L’équipe y présente des données d’exploitation réelles sur deux ans et indique avoir atteint plus de 1,2 M$ d’économies annuelles
- Grâce à l’exploitation en conditions réelles, les économies ont dépassé 1,2 million de dollars par an, réinvestis dans des serveurs dédiés à la synthèse d’incidents par IA et à la correction automatique de code, ce qui a amélioré la qualité du service
- En s’appuyant sur une pile MicroK8s + Ceph, l’équipe a maintenu une disponibilité de 99,993 % et supprimé les points uniques de défaillance grâce à une architecture sur deux datacenters
- Les principaux sujets comme les coûts d’exploitation réels, la gestion des incidents, la durée de vie du matériel, les certifications de sécurité et les alternatives au cloud sont expliqués avec des chiffres concrets
- Au final, la stabilité comme l’efficacité économique se sont améliorées, et le rapport conclut que pour les systèmes à charge permanente d’une certaine taille, le bare metal est plus rationnel
Résumé des résultats d’exploitation sur 2 ans
- La pile MicroK8s + Ceph a été exploitée en production pendant 24 mois avec une disponibilité de 99,993 %
- Pour éliminer le problème du rack unique, un deuxième rack a été ajouté à Francfort, avec une double liaison DWDM vers le rack principal de Paris
- Grâce au NVMe local et à la suppression des interférences de bruit, la latence côté client a été réduite de 19 %
- Les économies réalisées ont été réinvesties dans l’achat de serveurs IA bare metal, afin d’étendre les fonctions de résumé d’alertes par LLM et de correction automatique de code de OneUptime
Économies réalisées et comparaison des coûts
- L’économie initialement estimée à 230 000 $ par an dépasse désormais 1,2 M$
- Cela représente une réduction d’environ 76 % par rapport à AWS
- À l’échelle des salaires mondiaux, cela correspond à la rémunération annuelle de 2 à 5 ingénieurs
- Même avec des Savings Plans / Reserved Instances, le bare metal reste plus avantageux
- Les Savings Plans ne s’appliquent pas aux coûts de S3, egress et Direct Connect
- Les frais du control plane EKS à 1 260 $/mois et de la NAT Gateway à 600 $/mois ne peuvent pas non plus être réduits
- Pour une charge steady 24/7, l’efficacité des Reserved Instances est restée limitée
Migration et coûts d’exploitation
- La migration initiale a été réalisée avec environ une semaine de travail d’ingénierie
- Il s’agissait pour l’essentiel de tâches déjà nécessaires, comme la remise en ordre de l’IaC et le renforcement des politiques de sauvegarde
- Les coûts d’exploitation actuels sont les suivants :
- Gestion directe : environ 24 heures par trimestre (patchs et mises à jour de firmware inclus)
- Remote Hands : seulement 2 interventions en 24 mois (principalement pour des problèmes de disque), avec un temps moyen de réponse de 27 minutes
- Automatisation : démarrage PXE (Tinkerbell), gestion des images Talos, automatisation de la configuration avec Flux/Terraform
- L’équipe d’exploitation a même constaté une augmentation de la vitesse de release par rapport à l’époque AWS, ainsi que la disparition du poids des réunions d’optimisation des coûts
Prévention des incidents et garantie de disponibilité
- L’ajout d’un deuxième rack à Francfort et une connexion DWDM à double chemin ont supprimé tout point unique de défaillance
- Mise en place d’un mirroring Ceph fondé sur la réplication asynchrone et d’un double control plane
- Une voie d’administration via 4G/satellite permet aussi l’accès distant en cas de panne réseau
- Migration en cours de MicroK8s vers Talos
- Un cluster de secours AWS Failover est toujours maintenu, avec des exercices trimestriels de reprise après sinistre
- Grâce à un ingress en Anycast + BGP, le délai de bascule DNS a aussi été ramené à moins d’une minute
- La disponibilité a été maintenue à 99,993 % sur 2 ans, sans subir les récents incidents de région AWS
Matériel et gestion du CapEx
- Les serveurs sont exploités sur une base d’amortissement sur 5 ans (2×EPYC 9654, 1 To de RAM, configuration NVMe)
- En cas de saturation des performances, ils sont réaffectés au cluster d’analyse puis remplacés par de nouveaux serveurs
- Grâce aux économies réalisées, un refresh de 40 % tous les 2 ans est devenu possible, tout en conservant un gain annuel face à AWS
- Extension de garantie Supermicro + stock de 3 serveurs de secours
- La durée de vie réelle est de 7 à 8 ans, mais le calcul reste volontairement conservateur avec 5 ans
Logique de remplacement des services managés
- La philosophie produit de OneUptime repose sur la possibilité d’auto-hébergement, d’où la nécessité de conserver la même stack
- Maintien d’une cohérence open stack avec Kubernetes, Postgres, Redis, ClickHouse, etc.
- Évolution de Terraform + EKS + RDS vers MicroK8s + Argo Rollouts + Ceph
- Utilisation d’open source standard, sans fork maison
- Le cloud est toujours utilisé en parallèle : AWS Glacier (sauvegardes), CloudFront (cache edge), instances temporaires pour les tests de charge
- Le cloud est adapté à l’élasticité, tandis que le bare metal convient mieux à la charge de base
Réseau et sécurité
- Deux liens 5 Gbps (95th percentile) ont été provisionnés, pour un coût 8 fois inférieur à l’egress AWS
- La protection DDoS est assurée par un déploiement complet de Cloudflare
- Un réseau d’administration indépendant en 4G/satellite permet l’accès distant en cas d’incident
Conformité et réponse aux audits
- Maintien des certifications SOC 2 Type II et ISO 27001
- Exploitation des éléments du centre de colocation, comme la certification Tier III, les journaux d’accès et la vidéosurveillance
- Les logs de configuration Terraform/Talos servent de preuve d’historique des changements
- Les auditeurs ont jugé cela plus fiable que des captures d’écran de la console AWS
Comparaison des alternatives au cloud
- Comparaison entre Hetzner, OVH, Leaseweb, Equinix Metal et AWS Outposts
- Les hyperscalers conservent des coûts d’egress élevés
- Les hébergeurs européens peinent à répondre aux exigences de SLA et de grands clusters Ceph
- Equinix Metal présente une prime de 25 à 30 % par rapport au CapEx
- L’exploitation de son propre matériel garde l’avantage en densité électrique et en liberté d’upgrade
- Au final, grâce à une configuration de rack à 15 kW et à la possibilité de réutiliser les composants, la colocation l’emporte à la fois sur le coût et les performances
Mesure de la charge opérationnelle (TOIL)
- Hebdomadaire : patchs kernel/firmware et vérifications Ceph (1 heure)
- Mensuel : upgrade canari du control plane Kubernetes (2 heures)
- Trimestriel : exercices DR, planification de capacité, revue des contrats opérateurs (12 heures)
- Total : environ 14 heures par mois, soit un niveau proche de la période AWS, mais avec un basculement du focus de la traque des coûts vers l’automatisation opérationnelle
Cas où le cloud reste pertinent
- Lorsque la charge présente des pics ou une forte saisonnalité
- En cas de forte dépendance à des services managés comme Aurora Serverless, Kinesis, Step Functions
- Lorsqu’il n’y a pas les ressources pour exploiter directement Kubernetes, Ceph, la supervision et la réponse aux incidents
- En d’autres termes, le cloud garde un avantage pour les activités en phase initiale ou à charge très variable
Suite du programme
- Publication prévue d’un module Terraform et d’un runbook pour prévoir les budgets de colocation
- Un article technique approfondi sur l’exploitation avec Talos est également en préparation
- L’équipe prévoit de continuer à répondre aux retours sur HN et Reddit, et à partager des cas concrets fondés sur des chiffres réels
3 commentaires
Deux ans après être passés d'AWS au bare metal : réponses aux questions sur la sortie d'AWS
Je travaille dans une entreprise qui utilise AWS avec enthousiasme alors qu’elle n’utilise absolument aucun service fourni uniquement par AWS.
Une histoire à la fois triste et absurde quand on voit que cette décision est fortement influencée par l’ambition très personnelle de certains dirigeants de développer leur carrière...
Réactions sur Hacker News
AWS est beaucoup trop cher. Il y a en réalité assez peu de raisons de faire tourner tout son système entièrement sur AWS. Avant, tout le monde savait gérer des serveurs bare metal soi-même, mais on dirait que cela s’est perdu. Notre équipe a maintenu une disponibilité de 99,993 % pendant plus de 730 jours et a même évité la récente panne de région AWS. Nous utilisons bien Cloudflare pour la protection DDoS, mais je comprends que la gestion du DNS ou de l’ingress puisse devenir un travail à plein temps. Malgré cela, on peut très bien faire tourner soi-même quelques microservices et une base de données. AWS facture trop cher pour la plupart des entreprises
À ses débuts, le cloud avait commencé comme un service simple et économiquement intéressant, mais aujourd’hui il s’est transformé en un enchevêtrement complexe de plus de 200 services. Si on ne surveille pas cela, la facture explose
La véritable fonction d’AWS est : (1) permettre l’extension des organisations et de leurs structures de pouvoir, (2) autoriser un traitement comptable en OpEx plutôt qu’en CapEx, (3) masquer des structures de recrutement incompétentes. Avant, on pouvait exploiter un datacenter avec 5 à 10 personnes ; aujourd’hui, on se retrouve avec des organisations DevOps de 3 000 personnes
Le cœur de cette réussite, c’est une charge stable 24/7. En réalité, la plupart des entreprises ont un profil assez similaire
Le vrai sujet, c’est l’élasticité face à la charge de fond. Le cloud n’est vraiment avantageux que lorsque le trafic explose brutalement, comme dans la collecte de données. Dans la plupart des cas, le bare metal est préférable
Dans les années 2010, le matériel et les réseaux étaient lents, mais aujourd’hui, les performances et l’efficacité des CPU ont progressé de plusieurs centaines de fois. Là où il fallait 64 serveurs autrefois, un seul suffit désormais. On ira probablement jusqu’à un ratio de 100:1. Dans ce contexte, les avantages du cloud diminuent progressivement
En tant qu’employé d’Amazon, je trouve que gérer Kubernetes soi-même est beaucoup trop risqué. Des composants comme etcd sont instables, et il a même fallu les patcher nous-mêmes. Le self-hosting décrit dans l’article sous-estime les risques
Beaucoup de startups n’auraient même pas pu exister si les coûts AWS avaient été aussi élevés. Par exemple, quelque chose comme le téléchargement gratuit de GeoIP (lien) aurait été impossible. Le cloud est lent, avec une latence disque élevée et une forte contention CPU. En dessous de 10 000 dollars par mois, cela reste acceptable, mais au-delà, le bare metal devient nettement plus efficace
Dans l’entreprise où je travaillais, le trafic était faible, mais ils voulaient quand même migrer vers AWS. La raison était simple : ils voulaient ajouter AWS sur leur CV. Ce n’était pas seulement vrai pour les développeurs, mais aussi pour la direction. « Responsable de migration AWS » sonnait bien sur un parcours professionnel. L’entreprise a fini par être revendue et les bureaux sont désormais vides. Peut-être que demain, « sortir d’AWS » deviendra à son tour un argument de carrière
En définitive, l’important est de savoir ce que l’on cherche à faire