Hetzner Online et l’AS24940 : le cloud à bas prix exige une discipline opérationnelle coûteuse

Résumé

Le RDAP du RIPE NCC enregistre l’AS24940 sous le nom actif HETZNER-AS et rattache l’organisation à Hetzner Online GmbH. Le 5 août 2026, RIPEstat indiquait que cet ASN était annoncé et observait 94 entrées de préfixes. C’est une identité réseau visible, pas un certificat de disponibilité.
Hetzner décrit des parcs de centres de données interconnectés, un filtrage DDoS, des sauvegardes, des instantanés et des engagements de disponibilité précisément définis. Ses propres conditions laissent aussi au client l’administration et la sécurité des serveurs root et cloud, l’organisation des copies et la vérification de la reprise métier.

Hetzner Online GmbH commercialise des serveurs cloud, des machines dédiées, du stockage et des services d’infrastructure. Pour beaucoup d’acheteurs, l’attrait initial est simple : obtenir des ressources informatiques pour une facture mensuelle contenue. Une fois en production, la facture visible ne couvre pourtant ni les mises à jour, ni les droits d’accès, ni la surveillance, ni les restaurations, ni l’organisation d’un incident.

L’AS24940 permet d’entrer dans cette chaîne par une donnée publique. Un numéro de système autonome, ou ASN, est un identifiant qu’un réseau utilise pour échanger des informations de routage avec d’autres réseaux. Il ressemble à un nom d’organisation sur la carte routière de l’internet. Il ne garantit pas qu’une commande, une connexion ou un traitement métier aboutira.

L’objectif de cette étude n’est donc pas de distribuer une note générale à Hetzner. Il consiste à distinguer les couches : ce que prouve le registre, ce que montre l’observation BGP, ce que l’opérateur publie sur ses interconnexions, ce que mesure un SLA, ce que contrôle le client et ce qui prouve enfin que le service utilisé par une personne fonctionne.

L’image de couverture est une scène photoréaliste générée pour BTW Media. Elle montre un technicien générique devant une baie sans marque. Elle n’illustre ni un salarié, ni un site, ni un équipement, ni un client, ni un incident réel de Hetzner, et ne constitue aucune affirmation de performance ou de soutien.

Le registre établit l’identité, pas la santé du service

L’objet suivi ici est l’entité COMPANY publiée « Hetzner Online GmbH » dans le répertoire BTW. Au moment du contrôle, elle ne possédait aucun lien ArticleEntity antérieur. D’autres lignes au nom proche existent pour des contextes différents ; elles ne sont pas utilisées comme substituts.

La réponse RDAP du RIPE NCC nomme l’AS24940 HETZNER-AS, le marque actif et cite Hetzner Online GmbH comme organisation enregistrée et dans le rôle de contact. RDAP signifie Registration Data Access Protocol. Le format rend les données de registre consultables de manière structurée. La capture indique une inscription le 3 juin 2002 et une dernière modification le 30 juin 2026.

Cette fiche sert de registre opérationnel. Elle maintient un numéro unique, une identité et des coordonnées utiles pour une question de routage ou un signalement d’abus. Elle réduit le risque qu’un interlocuteur doive deviner quelle société se cache derrière un nom commercial.

Elle ne montre pas tous les routeurs, fibres, sites, clients, produits ou contrats. Elle ne prouve ni la capacité actuelle, ni la latence, ni la couverture RPKI, ni la disponibilité d’une application. Un contact enregistré peut également être correct sans répondre dans le délai espéré.

Il faut donc associer chaque question à son bon niveau de preuve. Le RDAP répond à « qui est inscrit ? ». Une vue de routage répond à « qu’a-t-on vu circuler ? ». Les journaux applicatifs répondent à « le client a-t-il pu terminer son action ? ». Confondre ces questions produit des certitudes trompeuses.

Le contrôle solide est la réconciliation. Les informations de registre, l’inventaire interne, les autorisations de route, les observations BGP et les contacts d’exploitation doivent décrire une réalité compatible. Un écart déclenche une vérification ; il ne constitue pas à lui seul une accusation.

Les 94 préfixes observés ont une portée limitée

Le service RIPEstat a associé la ressource 24940 à HETZNER-AS Hetzner Online GmbH et l’a marquée annoncée le 5 août 2026. Autrement dit, ses collecteurs voyaient alors ce système autonome participer au routage mondial.

La réponse consacrée aux préfixes couvrait la période du 22 juillet au 5 août. Elle contenait 94 entrées, dont 89 en IPv4 et cinq en IPv6. Un préfixe représente un bloc d’adresses. La capture apporte donc une preuve datée de visibilité dans les deux familles d’adresses.

Le nombre 94 ne correspond ni à des clients, ni à des serveurs, ni à des circuits, ni à des sites. Les collecteurs observent depuis certains points et les routes changent avec le temps. La liste ne constitue pas un inventaire juridique complet et ne dit rien, à elle seule, de la qualité vécue par chaque utilisateur.

Elle reste utile à la surveillance. Un préfixe protégé qui apparaît sous un ASN inattendu, ou une route attendue qui disparaît de plusieurs vues, mérite une enquête. Il peut s’agir d’une migration légitime, d’un arrangement client, d’un retard de données ou d’une erreur. L’alerte demande une comparaison avec l’état attendu.

Une direction non technique n’a pas besoin de maîtriser tous les mécanismes BGP. Elle doit demander quels domaines et services dépendent de quelles adresses, quel ASN est attendu, qui examine un changement et à quel moment le fournisseur est sollicité.

PeeringDB est une carte maintenue par l’opérateur

Le profil PeeringDB capturé nomme Hetzner Online, relie le site hetzner.com, associe l’AS24940 et l’ensemble AS-HETZNER, décrit une politique générale ouverte et classe le réseau dans la catégorie Content. Il publie aussi des estimations de préfixes qui ne répondent pas à la même question que l’observation RIPEstat.

Les interfaces distinctes ont renvoyé 63 enregistrements de LAN d’échange correspondant à 49 identifiants d’échange, ainsi que 23 identifiants de site. Ce périmètre déclaré suggère une surface d’interconnexion étendue.

Il ne garantit pas la diversité physique, la capacité disponible ou le chemin emprunté par un client. Plusieurs ports peuvent appartenir au même échange. Deux sites peuvent partager un conduit métropolitain, une alimentation ou un fournisseur amont. Une ligne marquée opérationnelle n’est pas une mesure de trafic en temps réel.

PeeringDB est très utile comme carte de préparation et comme répertoire de coordination. Pour décider qu’une architecture est réellement résiliente, il faut le compléter par le contrat, la télémétrie actuelle, des tests de chemin et une confirmation du fournisseur.

Le cloud reste une infrastructure physique

La documentation de Hetzner présente huit centres de données à Nuremberg, 22 à Falkenstein et dix à Helsinki. Elle décrit des onduleurs, des groupes électrogènes, des chemins d’alimentation séparés et de la fibre noire redondante entre les parcs. Elle mentionne au moins 120 Gbit/s sur certains axes allemands.

Ces éléments proviennent de l’émetteur, et non d’un audit indépendant. Ils rappellent néanmoins qu’une machine virtuelle dépend d’un hôte physique, de commutateurs, d’énergie, de refroidissement, de fibres, d’opérateurs externes et de techniciens capables d’accéder au matériel.

Le mot « redondant » doit toujours être accompagné d’un objet et d’une frontière. Deux alimentations ne couvrent pas tous les incidents électriques. Deux fibres ne protègent d’une coupure que si leur parcours est séparé au bon endroit. Deux instances ne créent pas une reprise si la base de données, le DNS ou le compte de contrôle reste unique.

Un client ne doit pas exiger un plan privé complet du site. Il doit savoir quel domaine de panne son produit couvre, où se trouve la copie, quelle capacité reste après une perte, qui décide du basculement et quand le scénario a été testé.

Les deux chiffres de 99,9 % ne sont pas une promesse métier

Les conditions générales parlent d’efforts économiquement raisonnables pour obtenir une disponibilité réseau annuelle moyenne de 99,9 % dans les centres de données. L’accord Cloud Server vise 99,9 % par mois pour chaque machine virtuelle.

Ce dernier définit la disponibilité par le fonctionnement de l’hôte, le démarrage de l’instance par l’hyperviseur et une activité mesurable du processeur ou du réseau. Il prévoit des exclusions, notamment la maintenance, certains logiciels ou réglages du client, certaines attaques et les interruptions de réseau hors du contrôle raisonnable de Hetzner.

Une application peut être inutilisable alors que la machine répond à cette définition. Une base peut être incohérente, le DNS peut pointer ailleurs, une règle de pare-feu peut bloquer les visiteurs ou le paiement peut échouer. L’activité CPU ne prouve pas la réussite d’une transaction.

La période compte également. Une moyenne annuelle, une mesure mensuelle par serveur et l’objectif de reprise d’un commerce sont trois grandeurs différentes. Le client doit convertir le pourcentage en budget d’interruption et vérifier si ce budget convient aux heures les plus sensibles.

L’accord décrit un dédommagement en Cloud Credits pour certains écarts. Un crédit réduit une facture future ; il ne rembourse pas automatiquement les ventes perdues, les heures d’équipe, les consultants d’urgence ou le préjudice client. L’entreprise doit tarifer cette différence.

Les droits root transfèrent du pouvoir et du travail

Les conditions de Hetzner donnent au client les droits d’administration complets sur les produits root et cloud et lui attribuent la gestion et la sécurité. Cette liberté permet de choisir le logiciel et l’automatisation sans attendre une équipe de service géré.

Elle impose de corriger les systèmes, gérer les clés, configurer le pare-feu, renouveler les certificats, suivre la capacité et traiter les vulnérabilités. Le prix mensuel ne réalise aucune de ces tâches.

Dans une petite structure, un développeur peut créer une machine devenue critique puis quitter l’entreprise. Dans une grande structure, les projets, comptes et jetons API peuvent croître plus vite que le registre des actifs. Tant que le serveur répond, cette dette reste discrète.

Chaque service de production devrait avoir un propriétaire, un compte de facturation, une catégorie de données, une liste de dépendances, un destinataire d’alerte et un test de reprise. La protection contre la suppression et l’infrastructure sous forme de code aident, sans remplacer la propriété, la revue et la gestion des secrets.

La protection DDoS n’efface pas les autres pannes

Les mesures techniques de Hetzner décrivent une reconnaissance DDoS continue et un filtrage automatique du trafic malveillant. Une attaque DDoS utilise de nombreux systèmes pour tenter de saturer une cible. Un filtre placé chez le fournisseur peut réduire ce risque avant que le trafic n’atteigne le serveur.

Toutes les indisponibilités ne sont pourtant pas des DDoS. Une charge légitime peut saturer une base. Le pare-feu du client peut bloquer les bonnes requêtes. Un défaut logiciel peut créer une boucle. Le DNS, un certificat ou une API externe peut échouer.

Le client doit donc observer séparément l’hôte, l’application, l’accès depuis l’extérieur et l’action métier. Il doit aussi savoir qui contacte Hetzner, qui peut changer une règle, qui autorise une action urgente et comment la revenir en arrière.

Une sauvegarde n’est fiable qu’après restauration

La documentation présente les sauvegardes cloud, lorsqu’elles sont activées, comme des copies quotidiennes avec sept emplacements. Les instantanés sont créés par le client et restent jusqu’à leur suppression. La FAQ précise qu’une sauvegarde ne peut pas être protégée contre la suppression et disparaît avec le serveur, tandis qu’un instantané peut être protégé.

Une copie quotidienne laisse un risque de perte entre deux passages. Une base active peut nécessiter une procédure cohérente. Une image de disque sans clé, sans secret et sans configuration externe ne ramène pas l’activité.

Les règles de localisation comptent. En Europe, les sauvegardes se trouvent généralement dans un autre centre du même lieu et les instantanés suivent les règles de zone réseau. Certaines implantations américaines ou singapouriennes utilisent un seul centre et ont donc une frontière différente. « Autre hôte » n’équivaut pas toujours à « autre sinistre ».

Les conditions générales demandent au client de faire des copies régulières hors du serveur fourni, et la documentation recommande des sauvegardes indépendantes pour plusieurs produits. Le service du fournisseur peut former une couche ; une copie contrôlée séparément en forme une autre.

Une politique sérieuse répond à six questions : quelles données, quelle fréquence, quel emplacement, quel droit de suppression, quelle rétention, quelle dernière restauration complète réussie. Un travail de sauvegarde vert prouve une écriture. Un exercice de restauration prouve que des personnes savent rétablir le service.

Construire une carte de responsabilité

Si une machine cloud ne répond plus, Hetzner peut contrôler l’hôte, l’hyperviseur et le cœur réseau, tandis que le client contrôle le système, le logiciel et son pare-feu. La première étape n’est pas de chercher un coupable, mais d’identifier la couche en échec et le prochain détenteur d’autorité.

Un incident d’hôte oblige le client à choisir entre attente, basculement ou mode dégradé. Un disque plein peut laisser la machine active tout en arrêtant l’application. Un DNS obsolète peut envoyer les utilisateurs vers l’ancien système alors que les deux serveurs fonctionnent.

Une sauvegarde sans clé s’arrête à la frontière des accès. Un compte compromis peut permettre une suppression au moyen d’une interface légitime. Une perturbation amont peut laisser l’AS24940 visible depuis certains observateurs tout en bloquant un groupe d’utilisateurs.

Pour chaque service critique, une fiche courte devrait nommer les couches du fournisseur, les couches du client, les interfaces partagées, les preuves, le décideur et le test métier de reprise. Cette carte réduit les transferts stériles pendant l’incident.

Le vrai coût d’un serveur peu cher

Le tarif de l’infrastructure est visible. Les coûts d’intégration, de supervision et d’échec sont répartis entre les équipes. L’identité, le courriel, les paiements, le stockage, le DNS et les API ajoutent chacun des identifiants, des limites et des interlocuteurs.

La supervision comprend les correctifs, la revue des accès, les certificats, la capacité, les sauvegardes et l’astreinte. L’échec produit des transactions perdues, du personnel inactif, une coordination d’urgence et une communication client. La sortie exige de déplacer les données, les secrets et les politiques réseau.

Un calcul honnête additionne la facture cloud, les personnes et les outils, la fréquence probable des pannes, leur impact, les copies indépendantes, les exercices et la capacité alternative. Hetzner peut rester très compétitif dans ce calcul. Le but est d’éviter de confondre un prix bas avec un système d’exploitation complet.

Questions utiles avant et après la mise en production

Avant le lancement, il faut nommer le propriétaire du compte et du service, comprendre quel objet le SLA mesure, identifier les domaines de panne partagés, vérifier les copies, limiter les droits, organiser la surveillance et cartographier le DNS, les certificats, l’identité, la base et les API externes.

Il faut demander qui récupère le compte si l’administrateur habituel manque, si une suppression peut effacer simultanément serveur et sauvegardes, quel test prouve l’action d’un utilisateur et combien de temps prendrait une reconstruction ailleurs.

Après le lancement, il faut suivre les ressources sans propriétaire, les jetons anciens, l’âge des sauvegardes, les restaurations en retard, les erreurs métier, les changements de route inattendus, le DNS et les certificats. « Machine active », « application répond » et « activité vérifiée » doivent rester trois états distincts.

Conclusion pratique

Les sources publiques établissent une identité réseau claire entre Hetzner Online GmbH et l’AS24940. Le RIPE NCC conserve le registre ; RIPEstat a observé l’annonce et 94 entrées de préfixes le 5 août 2026 ; PeeringDB publie une carte d’interconnexion et de sites maintenue par l’opérateur.

Les documents de Hetzner décrivent les connexions entre sites, le filtrage DDoS, les sauvegardes, les instantanés et des engagements précis. Ils montrent aussi les limites : le client administre et sécurise ses systèmes, organise ses copies et doit vérifier le retour de l’activité.

La règle pour un décideur non spécialiste est directe. Le registre est une identité, la route une observation datée, PeeringDB une carte déclarative, le SLA un contrat pour un objet précis et la sauvegarde une copie non prouvée jusqu’à la restauration. Une machine en marche n’est qu’une étape vers un service métier en marche.

Sources

Attribution de l’image

Image éditoriale photoréaliste générée pour BTW Media : un technicien réseau générique vérifie une baie sans marque dans une allée de centre de données ordinaire. L’image source a été créée avec l’outil de génération intégré puis convertie en JPEG 1600 × 900 sans modifier la scène. Elle ne représente aucune installation, personne, interface, marque ou architecture réelle et n’illustre ni Hetzner Online GmbH, ni ses équipements, ni ses performances, ni un incident, ni un soutien.