Passer d’AWS à Hetzner, réduire les coûts de 90 % et maintenir l’ISO 27001 avec Ansible

• Les enjeux de souveraineté des données et de conformité au RGPD liés aux services cloud américains ont rendu nécessaire une migration vers un cloud européen
• En renonçant à la commodité et aux services intégrés d’AWS, le passage à un hébergement européen comme Hetzner a permis d’obtenir immédiatement une baisse des coûts et une meilleure clarté sur les données
• Pour améliorer l’efficacité de l’exploitation de l’infrastructure, une automatisation basée sur Ansible et un système de supervision autogéré ont été mis en place
• Cette reconstruction en interne a permis d’adopter une conception de sécurité plus rigoureuse et une architecture facilitant des audits transparents
• Une réduction des coûts de 90 % et une diminution du risque lié à la surveillance américaine ont aussi apporté des avantages stratégiques côté business

---

Processus de transition d’AWS vers un cloud européen (Hetzner) et stratégie de maintien de l’ISO 27001

Le dilemme d’un CTO européen : les enjeux de conformité hors d’AWS

• L’une des préoccupations les plus courantes chez les responsables techniques vient des limites des fournisseurs de cloud américains
• Bien que les services certifiés ISO 27001 d’AWS donnaient satisfaction, le CLOUD Act et la FISA exposent inévitablement les données des clients européens à la juridiction américaine
• Quelle que soit la localisation réelle des serveurs, il devient difficile de tenir les engagements RGPD
• La facture cloud annuelle de 24 000 $ s’est révélée excessive par rapport aux besoins réels
• Il est apparu clairement qu’il était stratégiquement risqué de faire dépendre l’avenir de l’entreprise d’un unique fournisseur basé aux États-Unis

Présentation du cas concret de Datapult

• Datapult est une entreprise danoise de logiciels de gestion des effectifs ; ses activités de planification des employés, d’ajustement des heures supplémentaires et de gestion des données de présence exigent un niveau de fiabilité proche de celui de la finance
• L’entreprise s’était conformée aux exigences légales dans le cadre d’un workflow basé sur AWS, mais une migration vers de l’on-premise ou des services alternatifs indépendants nécessite un examen juridique supplémentaire

Les craintes liées au départ d’AWS et les pertes réelles

• Renoncer à la commodité intégrée d’AWS constitue une barrière psychologique importante
• Cela implique de perdre la simplicité et l’automatisation de Lambda, du RDS en un clic et de divers outils de conformité intégrés
• On passe de services managés à une situation avec davantage de contrôle direct, mais aussi plus de responsabilités

Les effets attendus d’un cloud européen et les bénéfices concrets

• La migration vers des fournisseurs européens (Hetzner, OVHcloud) apporte des gains immédiats en matière de souveraineté des données, de RGPD et d’ISO 27001
  • Preuve d’une véritable résidence des données, avec une communication client plus transparente et une meilleure préparation aux audits
  • Réduction des coûts inattendue (90 %) et meilleure visibilité budgétaire
  • En abandonnant le confort d’AWS, l’entreprise a mis en place des procédures d’automatisation techniquement plus solides (configuration Ansible) et renforcé sa sécurité
• Par rapport à la situation initiale, elle gagne en autonomie, capacité d’innovation et infrastructure vérifiable

Stratégie de transition concrète et principaux enseignements

• Automatisation de la conformité avec Ansible
  • Mise en place d’une gestion d’infrastructure auto-documentée, où chaque configuration serveur est directement rattachée aux contrôles de l’Annexe A de l’ISO 27001
• Construction d’un système de supervision en remplacement d’AWS
  • La combinaison Prometheus, Grafana et Loki permet d’atteindre un niveau de supervision enterprise proche d’AWS CloudWatch et d’assurer une réponse rapide aux incidents
• Mise en œuvre du security-by-design pour renforcer l’architecture de sécurité
  • En l’absence d’outils de sécurité managés, l’automatisation Ansible a permis de renforcer l’ISMS (système de management de la sécurité de l’information) et de faciliter la conformité pour les développeurs

Des effets stratégiques au-delà de la technique

• Réduction du risque de conformité lié aux lois américaines sur la surveillance
• Utilisation d’une infrastructure d’hébergement européenne comme argument commercial différenciant, renforçant la confiance et la valeur de la marque
• Les économies réalisées sur le cloud (90 %) peuvent être réinvesties dans le cœur de l’activité

Guide d’application de la stratégie de transition

• À partir de cette expérience de migration d’une infrastructure AWS vers un cloud européen souverain tout en maintenant l’ISO 27001, il est possible de proposer des lignes directrices reproductibles
• Pour les CTO et fondateurs qui envisagent de passer d’AWS à un cloud européen, un accompagnement sur mesure peut être proposé sur l’analyse des coûts, les risques de conformité et le calendrier de mise en œuvre
  • En une heure, il est possible de clarifier l’écart de coût, les principaux risques juridiques et les premières étapes de la migration

[GN⁺]

Commentaires Hacker News

• Nous avons réduit les coûts en réimplémentant nous-mêmes les fonctionnalités clés d’AWS, mais beaucoup de gens sous-estiment le vrai coût d’un hébergement en mode DIY, surtout des aspects comme le support 24/7. Si on essaie de recréer cela en interne, cela peut au contraire coûter assez cher. Une facture AWS annuelle de 24 000 $ correspond à 1 à 2 mois d’un excellent freelance DevOps, ou à environ 0,3 ETP d’un développeur peu rémunéré ; avec ce budget, il est difficile d’espérer une astreinte 24/7. Bien sûr, ce choix peut être rationnel, mais je trouve dommage de ne pas exposer honnêtement tout ce que cela implique réellement, notamment le temps de développement et les coûts d’exploitation. J’envisage moi aussi une décision similaire, non pas tant pour réduire les coûts que pour répondre à des exigences métier, notamment de clients allemands. Mais cela va forcément complexifier les choses et nécessiter d’agrandir l’équipe. En tant que CTO, mon temps est limité, et m’impliquer directement dans ce type de travail est probablement la pire utilisation possible de mon temps. Je pense qu’il vaut mieux me concentrer davantage sur l’évolution de l’entreprise et du produit. Personnellement, je trouve que Terraform est excessif à cette petite échelle, et qu’Ansible correspond mieux à un cas YAGNI (You Ain’t Gonna Need It).

  • Beaucoup de gens s’imaginent à tort que les grands fournisseurs cloud comme AWS, Azure ou GCP assurent réellement un support applicatif 24/7, alors qu’en réalité ce n’est pas le cas. L’infrastructure fonctionne simplement « globalement » bien, mais pour l’exploiter correctement, il faut toujours des experts capables de surveiller eux-mêmes les explosions de coûts ou les problèmes d’intégration. L’idée que la facture cloud représente le TCO (coût total de possession) est un mythe complètement faux.

  • Reproduire 100 % des fonctionnalités d’AWS peut coûter cher, mais si on n’a besoin que de 80 %, la situation change. Il ne faut pas non plus négliger l’effort nécessaire pour configurer AWS et entretenir en permanence les compétences techniques associées. Par exemple, au lieu du tableau de bord AWS, on peut utiliser de meilleurs outils comme Grafana. Au final, tout dépend de l’ampleur et de la diversité des besoins. Le marteau le plus cher n’est pas toujours la bonne réponse.

  • Si on se limite aux économies, cela représente 21 600 $ par an, soit 90 % de 24 000 $. Mais avec un tel budget, on ne peut pas recruter un ingénieur SRE/DevOps en Europe. Je pense même qu’à long terme, le coût total de possession augmentera, car il faudra gérer toute l’infrastructure soi-même avec le temps. Cela dit, je soutiens quand même l’initiative.

  • Si l’on prend en compte le risque qu’un jour le gouvernement américain exige d’Amazon la suspension forcée d’un compte, utiliser AWS peut devenir risqué. C’est d’autant plus vrai dans le contexte récent de discours sur une guerre entre les États-Unis et l’Europe, notamment autour du Groenland.

  • Je trouve que ce calcul simpliste autour des 24 000 $ par an est bien trop naïf. J’ai l’impression qu’il manque une vraie estimation des coûts humains : combien de personnes faut-il pour mettre en place ces services sur AWS, et combien en faut-il pour faire passer un coût initial de 48 000 à 100 000 dollars à 24 000 dollars ?

• Je pense qu’avec le trio Prometheus, Grafana et Loki, on peut recréer soi-même le niveau de monitoring qu’on avait sur AWS, voire le dépasser. Je suis toujours surpris que, malgré l’excellence de ces outils, les services de monitoring d’AWS soient si chers, si lents et aussi décevants en UX. En pratique, le coût du monitoring a été la partie la plus rapide et la plus désagréable de mon expérience AWS.

  • Ça me fait rire de voir qu’une fonctionnalité aussi simple que les logs en temps réel avec Live Tail soit un service payant. Le fait même que quelque chose d’aussi indispensable au quotidien que la consultation des logs ne soit pas gratuit montre à quel point CloudWatch (CW) est pénible.

• Les principaux inconvénients de Hetzner sont, à mon sens, la pollution de réputation des IP à cause d’utilisateurs malveillants, ainsi que les pannes matérielles et les besoins de mise à niveau. Je me demande si cela ne les inquiétait pas. Et je me demande aussi comment ils gèrent les explosions de consommation mémoire de Loki, ou s’il existe de meilleures alternatives.

  • Pour le problème de réputation IP, l’accès des utilisateurs passe en proxy via Cloudflare, et l’accès externe est bloqué en configurant ufw et en n’autorisant que les sources approuvées, notamment les IP de Cloudflare. En cas de panne matérielle ou de besoin d’upgrade, leur configuration Terraform permet de remplacer rapidement les machines et d’augmenter la capacité. Ils surveillent le matériel avec Prometheus et node exporter afin de recevoir des alertes préventives, et n’ont eu aucune panne en neuf mois. L’application contient très peu de données, et la base est testée fréquemment en restauration. Pour les problèmes mémoire de Loki, ils les ont résolus en combinant plusieurs approches : politiques de rétention, séparation des index, réglage de la concurrence des requêtes et des limites mémoire, adoption de labels façon promtail et de logs structurés, et remplacement des anciens historiques par des sauvegardes sur object storage ou par grep.

  • D’après notre expérience, les problèmes rencontrés avec Loki viennent surtout du fait que les paramètres de déploiement par défaut, notamment via Helm, ne sont pas assez optimisés. En appliquant les conseils de performance mentionnés dans le blog — réinitialisation des index, ajout d’instances en lecture seule et autres recommandations — nous avons constaté une nette amélioration. J’ai aussi l’impression qu’il faut un peu bricoler au départ, car l’objectif implicite est de pousser les utilisateurs vers leur propre service cloud plutôt que vers l’open source.

  • Comme alternative à Loki, je recommande Victoria. C’est beaucoup plus rapide et sa réputation est excellente, mais nous avons choisi Loki en tenant compte de la diversité des mainteneurs du projet. Les méthodes évoquées plus haut compensent ses inconvénients.

  • Partage du lien https://en.wikipedia.org/wiki/Sybil_attack. Les fournisseurs cloud coûteux ont l’avantage de construire une réputation IP un peu comme un mécanisme de type PoW (preuve de travail).

• ISO 27001 est une norme internationale de gestion de la sécurité, très populaire en Europe. Elle est peu utilisée aux États-Unis, et beaucoup d’entreprises européennes ont du mal à accepter cette différence. La référence de base en matière de standards de sécurité aux États-Unis est SOC 2, moins stricte qu’ISO 27001 et bien plus familière pour le marché américain.

  • ISO 27001 n’est pas, à l’origine, une exigence particulièrement rigide ou sévère ; en général, elle demande simplement les bases qu’il faut déjà faire quand on utilise un logiciel. En revanche, ce qui est compliqué, c’est d’en apporter la preuve documentaire, alors que SOC 2 impose une charge de documentation nettement plus légère.

  • Ayant connu à la fois SOC 2 et ISO 27001, je trouve dommage que les audits SOC 2 dépendent souvent davantage des compétences et de l’intuition de l’auditeur que des contrôles réellement en place. ISO 27001 me paraît bien plus clair et équitable comme audit.

  • Quelqu’un demande de citer ne serait-ce qu’un seul grand fournisseur cloud américain qui ne soit pas certifié ISO 27001.

• J’ai moi aussi obtenu 90 % d’économies avec une configuration similaire sur Azure. J’ai l’impression que les grands groupes imposent délibérément une expérience de service abstraite et complexe, au point de rendre une exploitation simple de plus en plus difficile.

  • Quelqu’un demande plus de détails sur ce cas de réduction des coûts sur Azure.

• L’une des raisons pour lesquelles on paie AWS, c’est que cela réduit la charge opérationnelle. En pratique, depuis que j’utilise des bases de données managées sur AWS, je ne ressens plus le stress que j’avais autrefois lors des mises à niveau de clusters MySQL. Bien sûr, cela ne suffit pas à lui seul à justifier le coût élevé, mais je pense que cela a une vraie valeur.

  • Je suis d’accord avec cette remarque. Pour obtenir une vraie conformité ISO 27001, il faut aussi internaliser le processus de mise à niveau afin de contrôler efficacement le développement et le déploiement. Par exemple, AWS RDS n’effectue pas automatiquement les mises à niveau majeures ou mineures de Postgres et MySQL ; seuls les patchs sont automatiques, le reste doit être géré manuellement. Le sujet n’est pas de savoir si le cloud ou les serveurs européens sont « meilleurs », mais plutôt comment exploiter soi-même un environnement complexe et certifié. Si, pour des raisons client ou réglementaires, on doit garder la maîtrise de son infrastructure, alors gérer soi-même les mises à niveau et obtenir l’ISO 27001 a du sens ; sinon, dépendre du cloud comme AWS RDS reste tout à fait acceptable.

• Les chiffres ne me semblent pas cohérents. Réduire de 90 % une facture annuelle de 24 000 $, cela ramène à 200 $ par mois, soit à peine le prix d’un seul serveur chez Hetzner. Dans ce cas, on pourrait presque se contenter d’un serveur unique sans système distribué. Je serais curieux de connaître le nombre réel de requêtes par seconde ou d’utilisateurs.

  • Pour respecter ISO 27001, on ne peut pas fonctionner avec un serveur unique ; il faut aussi un serveur séparé dédié aux logs et au monitoring. Quelle que soit la charge, une certaine complexité est inévitable. Les employés ne se connectent pas tous les jours, et avec une application de planification, beaucoup ne la consultent qu’une à deux fois par semaine. Les DAU se situent entre 10 000 et 20 000, le pic de connexions simultanées entre 1 500 et 2 000 personnes, et la moyenne entre 50 et 150 connexions simultanées. Si les coûts cloud sont élevés, c’est à cause des fonctionnalités temps réel et de la lourde charge de traitement de données liée aux règles métier complexes. Par exemple, les affectations de postes tiennent compte de règles de prime différentes, et l’optimisation des plannings demande aussi beaucoup de calcul.

  • Quelqu’un corrige en précisant qu’il s’agit de 200 $, pas de 2 400 $.

• Je me demande comment ils gèrent le chiffrement disque. Sur AWS c’est automatique, mais je n’ai pas souvent vu de bonne implémentation chez les hébergeurs classiques. Et si la clé de chiffrement est stockée sur la partition de boot, cela ne sert à rien.

  • ISO27001 n’impose pas nécessairement le chiffrement disque ; il faut surtout définir une méthode appropriée de protection des données sensibles. En particulier dans un environnement matériel partagé, le chiffrement disque est le moyen le plus courant. Hetzner exploite des datacenters certifiés ISO27001 et dispose d’un processus d’effacement des données lors de la mise au rebut des disques, ce qui permet de répondre aux exigences de la certification.

• J’adore vraiment Hetzner, au point d’y faire tourner aussi mon moteur de recherche. À mon avis, les serveurs physiques, c’est le top.

• En plus d’OVH et de Hetzner, j’aimerais recommander UpCloud parmi les clouds européens. L’un de ses avantages semble être que tous les cœurs CPU sont de vrais cœurs, et non des vCPU basés sur des threads. Dommage qu’il y ait peu de références officielles à ce sujet. Comparer OVH, Hetzner et les hyperscalers n’est pas simple, car dans le cas de Hetzner, la plupart des composants sont plutôt orientés grand public. Présentation d’UpCloud

  • Je me demande pourquoi les clouds low cost n’ont jamais de véritable IAM au niveau IaaS — permissions, politiques, logs — et se limitent presque toujours à une simple connexion console, sans vrais rôles, identités machine ni journaux d’audit natifs. Pourtant OpenStack fournit déjà ce genre de fonctions, mais on a l’impression que les clouds low cost ont tout refait de zéro. Même chez UpCloud, par exemple, leur guide Crossplane semble encourager le partage de credentials API au niveau d’un utilisateur console, ce qui paraît risqué. Avec Terraform, cela devient difficile à gérer, donc on finit par devoir utiliser quelque chose comme upcli. OpenStack Service Users OpenStack Federation Guide UpCloud Crossplane Gestion des sous-comptes UpCloud Configuration des permissions UpCloud