Hosting-27 Hosting-27 LTD vend une capacité hébergée qui dépend encore des racks, du transit et des fenêtres de réparation

Résumé

• Hosting-27 Hosting-27 LTD n'est pas une entreprise visible uniquement dans les enregistrements de routage. Lapage d'accueil Hosting27.comen ligne propose des services d'hébergement et de cloud bulgares, lapage de contactfournit une adresse à Sofia, un numéro de téléphone et des adresses e-mail d'assistance, l'espace clientexpose un portail de connexion et de facturation, et lapage de tickets d'assistancedécrit un service d'assistance fonctionnant tous les jours. Cette surface de vente publique est réelle, mais elle ne prouve pas à elle seule où se trouvent les serveurs ni comment les pannes sont réparées.
• L'identité réseau est concrète et compacte. L'objet AS42347de la base de données RIPE nomme Hosting-27, lie l'AS à l'organisation ORG-HA629-RIPE, liste Hosting-27 LTD comme organisation, indique le pays BG, le numéro d'enregistrement 204354361 et une adresse à Sofia, et enregistre les imports et exports avec AS57344 et AS31083. L'objet inetnum RIPE 217.174.144.0 - 217.174.144.255et l'objet route 217.174.144.0/24lient le bloc IPv4 visible à Hosting-27 et AS42347.
• La vue des routes en direct est plus étroite que le menu marketing. Lavue d'ensemble ASde RIPEstat a montré AS42347 annoncé le 12 juillet 2026, et sa vuerouting-statusa montré un préfixe IPv4 visible, 256 adresses IPv4, aucun IPv6 visible et un voisin observé. La vueASN-neighboursde RIPEstat a identifié ce voisin comme AS57344, et lavue d'ensemble AS57344de RIPEstat identifie AS57344 comme Telehouse EAD. Un second pair, AS31083 Telepoint, apparaît dans la politique de registre AS42347 mais pas dans la vue de cohérence BGP actuelle.
• Le niveau opérationnel est un moyen qualifié, pas fort. Les pages produits pour l'hébergement mutualisé,Cloud VPS,managed Cloud VPS,private cloudetKubernetesmontrent une large offre de capacité hébergée. Les preuves publiques ne montrent pas de salle de centre de données nommée, de nombre de baies, de conception de l'alimentation, de stock de matériel, de conditions de conservation des sauvegardes pour les clients, de transit double actif, de service IPv6 ou de chemin de portabilité écrit.

La surface de service est visible, mais elle doit être lue à partir du rack vers l'extérieur

Hosting-27 Hosting-27 LTD ne doit pas être confondu avec un simple enregistrement de numéros Internet. Le site public Hosting27.com est en ligne, daté par ses propres métadonnées d'en-tête et ses pages visibles, et conçu comme une devanture commerciale d'hébergement opérationnelle. Lapage d'accueilprésente la marque comme un fournisseur de services d'hébergement et de cloud. Elle oriente les acheteurs vers l'hébergement WordPress, les clusters Kubernetes, le cloud privé, Cloud VPS, managed Cloud VPS, l'hébergement revendeur, les domaines, un espace client, des factures et des tickets d'assistance. La navigation n'est pas une page d'accueil unique abandonnée; c'est une surface de vente au détail d'hébergement avec des niveaux de produits, des boutons de commande, un espace compte de type WHMCS et un portail d'assistance.

Cela rend l'enquête plus exigeante, pas moins. Lorsqu'une entreprise vend de l'hébergement web ou des serveurs cloud, la dépendance du client n'est pas la page web. La dépendance est la pile cachée sous la facture: un nœud hôte, un backend de stockage, des commutateurs, des routeurs, un stock d'IPv4, du transit amont, de l'alimentation, du refroidissement, des interventions à distance, l'état de la facturation, la gestion des abus et une équipe d'assistance ayant l'autorité d'agir.

Le matériel public de Hosting27 décrit plusieurs produits destinés aux clients, mais il n'identifie pas l'installation ou les installations derrière eux. Il ne dit pas si Hosting-27 exploite ses propres racks, loue des espaces de baie, dépend d'un autre opérateur de centre de données bulgare ou revend de la capacité assemblée par un fournisseur lié.

Le menu des produits est important car il indique aux clients quel type de système physique devrait exister. Lapage d'hébergement mutualisépropose trois tailles de plan avec 20 Go, 50 Go et 165 Go d'espace, cPanel, sites illimités, boîtes mail illimitées, certificats SSL gratuits, CDN, aide à la migration, plusieurs versions de PHP et des sauvegardes d'un mois. Lapage d'hébergement WordPresspropose des niveaux similaires de 20 Go, 50 Go et 165 Go, ajoute la gestion WordPress et promet une aide pour déplacer les sites WordPress. Lapage d'hébergement revendeurpropose des plans de 40 Go, 75 Go et 130 Go avec accès WHM, trafic illimité et comptes illimités. Ce ne sont pas des slogans cloud abstraits. Ce sont des affirmations selon lesquelles des hôtes physiques ou virtuels partagés existent, que des comptes peuvent y être créés et que les migrations et les sauvegardes font partie de la promesse de service.

Le menu cloud élève les enjeux. Lapage Cloud VPSpropose des instances de un à quatre CPU virtuels, 1 Go à 6 Go de RAM, 30 Go à 85 Go de stockage tout SSD, des sauvegardes quotidiennes, un panneau de gestion, OpenStack, KVM et Ceph. Elle vend également des adresses IP supplémentaires, des sauvegardes système supplémentaires et des blocs d'administration système de trente minutes. Lapage managed Cloud VPSpropose des serveurs gérés avec un panneau de contrôle, un support technique, des sauvegardes quotidiennes, une surveillance 24 heures sur 24 et une migration gratuite. Lapage private cloudva plus loin, décrivant une offre de centre de données virtuel basée sur OpenStack avec du stockage défini par logiciel, une revendication de niveau de service de 99,99 %, un réseau doublement sécurisé et des services API tels que Cinder, Nova, Heat, Glance, Magnum, Neutron et Keystone. Lapage Kubernetesdécrit une aide pour installer, configurer et maintenir un environnement Kubernetes hautement disponible et indique que le service couvre l'infrastructure, le réseau et les équilibreurs de charge comme l'une de ses couches.

Ces pages donnent à Hosting27 une surface de vente publique plus forte que de nombreux petits réseaux d'hébergement. Elles créent également un écart de preuves plus grand. Un vendeur de VPS à nœud unique peut échouer discrètement.

Un vendeur d'OpenStack, Ceph, cloud privé et Kubernetes doit répondre à davantage: combien de nœuds physiques sont disponibles, comment la réplication du stockage est isolée, si les composants du plan de contrôle ont des domaines de défaillance indépendants, où se trouvent les sauvegardes, quel pool d'adresses dessert les clients, quel routeur porte la route et qui peut réparer le système lorsque la couche physique tombe en panne.

Le point de départ le plus sûr n'est donc ni le rejet ni la confiance aveugle. Hosting-27 a un site web visible et un AS visible. Les archives publiques soutiennent l'existence d'une opération d'hébergement bulgare. Elles ne soutiennent pas une conclusion solide sur la capacité cloud installée, la récupération multi-site ou l'indépendance du fournisseur.

L'enregistrement RIPE donne à Hosting-27 une périphérie réseau petite mais réelle

La preuve d'infrastructure la plus claire se trouve dans la base de données RIPE et RIPEstat. L'enregistrement aut-num RIPE pour AS42347nomme l'AS "Hosting-27", liste Hosting-27 LTD via ORG-HA629-RIPE, enregistre le statut ASSIGNED, indique une création le 24 août 2017 et une dernière modification le 7 avril 2021, et enregistre les politiques d'import et d'export pour AS57344 et AS31083. L'enregistrement d'organisationlié nomme Hosting-27 LTD, pays BG, numéro d'enregistrement 204354361, type d'organisation OTHER, une adresse à Sofia au 133 boulevard Todor Aleksandrov, et un contact abuse à GLAC2-RIPE. Il a été créé en août 2017 et modifié pour la dernière fois en mai 2026.

L'attribution IPv4 est tout aussi explicite. L'inetnum RIPE pour 217.174.144.0 - 217.174.144.255utilise le nom de réseau Hosting-27, pays BG, organisation ORG-HA629-RIPE et statut ASSIGNED PA. L'objet route RIPE pour 217.174.144.0/24décrit Hosting27 et autorise l'origine AS42347. La vueannounced-prefixesde RIPEstat a montré 217.174.144.0/24 visible dans la fenêtre de deux semaines se terminant le 12 juillet 2026. Sa vuerouting-statusa montré un préfixe IPv4, 256 adresses IPv4 et une visibilité IPv4 complète sur 326 des 326 pairs RIPE RIS au moment de la vérification.

Ce /24 n'est pas qu'un enregistrement passif. Le domaine Hosting27.com lui-même se résout dans le même bloc. La vueDNS-chainde RIPEstat pour hosting27.com a résolu hosting27.com en 217.174.144.181, a associé en inverse cette adresse à shared-11.cpaneler.com, et a listé les serveurs de noms faisant autorité incluant ns1-pns.hosting27.com et ns2-pns.hosting27.com. L'enregistrement RDAP de domaine pour hosting27.commontre le domaine enregistré le 12 juillet 2013, expirant le 12 juillet 2027, avec PublicDomainRegistry.com comme bureau d'enregistrement et des serveurs de noms sous hosting27.com. Le site web visible, le DNS et le préfixe routé s'alignent donc autour de la même empreinte réseau publique.

Le pool d'adresses est petit. Un /24 contient 256 adresses IPv4 avant de compter les interfaces de routeur, les hôtes d'infrastructure, les serveurs de noms, les IP d'hébergement mutualisé, les attributions aux clients, les adresses de réserve et la capacité réservée. Cela suffit pour une entreprise d'hébergement réelle, surtout si de nombreux clients d'hébergement mutualisé sont derrière des hôtes virtuels basés sur le nom et si les petits plans VPS peuvent partager des hôtes sans que chacun reçoive plusieurs adresses publiques. Cela ne suffit pas pour déduire une grande capacité installée.

Une offre de cloud privé, une offre Kubernetes, des comptes revendeurs, du VPS géré et de l'hébergement mutualisé peuvent tous être vendus à partir d'un pool d'adresses publiques compact si l'adressage interne, le NAT, l'hébergement virtuel et une attribution soigneuse sont utilisés. Ils peuvent également être survendus si la planification est laxiste. La route publique ne distingue pas ces cas.

Il y a aussi un deuxième objet route qui doit être traité avec prudence. La vueAS-routing-consistencyde RIPEstat liste 45.151.89.0/24 comme présent dans le whois mais pas dans le BGP pour AS42347 au moment de la requête. Unerecherche RIPE pour 45.151.89.0/24montre un objet route pour AS42347, mais l'inetnum appartient à Geytit OOD, pas à Hosting-27 LTD, et la route ne faisait pas partie de l'ensemble annoncé visible actuel. Cela signifie qu'il est possible que la politique de route ait été préparée pour un autre pool, ou que la route était inactive, réservée, historique ou non visible au moment de la requête. Cela ne doit pas être compté comme une capacité Hosting-27 disponible pour les clients à moins que des preuves BGP et commerciales actuelles ne le soutiennent.

La périphérie réseau est donc réelle mais étroitement limitée: un AS visible, un /24 IPv4 visible, un objet route valide, un site web en direct à l'intérieur du bloc et aucun préfixe IPv6 visible pour AS42347 dans la vue de route RIPEstat.

Le bureau, le site web et le nom de l'entité contractante ne sont pas les mêmes qu'une salle de données vérifiée

La piste des adresses publiques est utile, mais elle n'identifie pas un centre de données. Lapage de contactde Hosting27 donne Sofia, boulevard Todor Aleksandrov 133, étage 2, plus un numéro de téléphone et des adresses e-mail d'assistance et de vente. L'enregistrement d'organisation RIPE pour Hosting-27 LTD donne une adresse correspondante au 133 Todor Aleksandrov. L'enregistrement d'organisation RIPE deGeytit OODutilise également le 133 Todor Aleksandrov et apparaît comme l'organisation sponsor de l'enregistrement AS42347. Ces enregistrements sont significatifs pour le contact et l'administration du registre. Ils ne prouvent pas que les serveurs des clients se trouvent dans ce bâtiment, que Hosting-27 possède des racks là-bas, ou que l'entreprise a un accès direct aux infrastructures d'alimentation et d'interconnexion.

Les conditions légales publiques ajoutent une autre limite. Lapage des conditions généralesde Hosting27 intègre un PDF, et lesconditions PDFindiquent que les conditions de service régissent l'hébergement mutualisé, les certificats SSL, l'enregistrement de domaine, les serveurs virtuels et les serveurs virtuels gérés via le site Hosting27.com. Le PDF nomme Cloud Systems OOD comme fournisseur dans les conditions bulgares et donne un numéro d'enregistrement d'entreprise différent. Cet article ne traite pas cela comme une constatation de relation d'entreprise. Il le traite comme un problème de diligence de l'acheteur: la marque, l'organisation RIPE, le LIR sponsor, les conditions web et l'émetteur de facture doivent s'aligner avant qu'un client ne considère le service comme un contrat d'infrastructure fiable.

Cette limite est importante pendant la panne, pas seulement pendant l'approvisionnement. Si une VM tombe en panne à 02h00, le client doit savoir quelle entité contrôle la file d'attente d'assistance, quelle entité possède ou loue le matériel, qui peut autoriser des interventions à distance, qui peut remplacer un disque, qui contrôle la session du routeur, qui facture le service et qui peut préserver les données en cas de litige de facturation.

Une discordance entre la marque, le détenteur de l'AS et le fournisseur du contrat n'est pas intrinsèquement mauvaise; de nombreux groupes d'hébergement utilisent des véhicules juridiques distincts pour les ressources d'adresse, les contrats clients, les installations et les opérations. Mais les documents publics examinés ici n'expliquent pas cette structure. Les clients doivent demander directement.

Les conditions indiquent également clairement que le service hébergé est une offre limitée, pas une garantie que chaque client reçoit un environnement totalement indépendant. Le PDF dit que l'hébergement mutualisé implique le partage par les clients de ressources serveur communes telles que la vitesse, la RAM et la connectivité réseau avec d'autres utilisateurs.

Sa section sur les serveurs virtuels gérés décrit l'administration d'un serveur virtuellement séparé avec un panneau de contrôle, un support 24 heures sur 24, des ressources garanties non partagées avec d'autres applications clientes, une surveillance, une réaction aux problèmes et des sauvegardes régulières. C'est un langage utile pour comprendre les classes de service prévues. Cela laisse tout de même flous le temps de restauration, l'emplacement des sauvegardes, la rétention des instantanés, la réplication hors site, le format d'exportation client et les crédits d'indisponibilité dans la vue publique.

Le cadrage de « centre de données virtuel » de la page private cloud est particulièrement important à nuancer. Un client lisant cette phrase peut imaginer une zone de centre de données dédiée. La page elle-même décrit une abstraction OpenStack: réseaux créés par le client, routeurs, équilibreurs de charge et services de stockage. Ce sont des fonctionnalités de plan de contrôle virtuel. Elles reposent toujours sur des nœuds physiques, des disques, des cartes réseau, des commutateurs de haut de rack, des alimentations et des liaisons de transit.

Sans une installation nommée ou une déclaration d'architecture, l'affirmation doit être traitée comme une offre de plan de contrôle cloud, pas comme la preuve d'un site physique séparé.

La dépendance visible en amont est Telehouse, tandis que Telepoint est une possibilité politique

La situation des routes est simple au point d'observation actuel. La vueASN-neighboursde RIPEstat pour AS42347 a signalé un voisin unique au dernier moment disponible: AS57344. Lavue d'ensemble AS pour AS57344de RIPEstat identifie AS57344 comme TELEHOUSE-AS Telehouse EAD. L'aut-num AS57344RIPE montre Telehouse avec une large politique amont et d'échange, incluant Arelion, Cogent, GTT, Level 3, Liberty Global, NTT, Orange, PCCW, RETN, Seabone, Tata, Telxius et plusieurs fabrics d'échange. L'enregistrement AS57344de PeeringDB décrit Telehouse comme ayant une portée mondiale, un support IPv6, de nombreuses présences d'échange et des entrées d'installations.

Cette étendue de Telehouse aide à expliquer comment le /24 de Hosting-27 peut être visible depuis les collecteurs globaux. Cela ne rend pas automatiquement Hosting-27 multi-hébergé. La dépendance immédiate observée pour AS42347 est toujours d'un seul voisin. Si la route AS42347 n'est portée que via Telehouse à la périphérie active, alors un problème côté Telehouse, un problème de session, un filtre de route, un incident d'installation, un problème d'interconnexion, un blocage commercial ou une fenêtre de maintenance peut affecter tous les clients utilisant le préfixe Hosting-27 visible.

Les collecteurs de routes publics peuvent manquer des chemins de sauvegarde privés, des sessions temporairement inactives ou des accords qui ne deviennent actifs qu'en cas de défaillance. Mais il incombe au fournisseur de démontrer une telle redondance, car la vue BGP publique actuelle ne le fait pas.

AS31083 est le deuxième nom à traiter avec précision. L'aut-num RIPE AS42347 liste des politiques d'import et d'export avec AS31083, et lavue d'ensemble AS31083de RIPEstat identifie AS31083 comme Telepoint Ltd. L'aut-num AS31083RIPE montre Telepoint connecté à plusieurs amonts, et l'enregistrement Telepointde PeeringDB signale un profil de portée européenne plus petit. Mais la vue AS-routing-consistency de RIPEstat montre AS31083 comme présent dans la politique whois et non présent dans le BGP pour AS42347 au moment de la requête. Cela signifie que la politique de registre seule ne doit pas être décrite comme une diversité active.

L'absence de PeeringDB pour Hosting-27 renforce la nécessité de prudence. Unerequête PeeringDB pour AS42347n'a retourné aucun objet réseau public. De nombreux petits réseaux fonctionnent sans profil PeeringDB, donc l'absence n'est pas un défaut. Cela signifie qu'il n'y a pas de liste d'installations Hosting-27 publique, de liste d'échanges, de page looking-glass, d'estimation de trafic, de politique de peering ou de profil NOC dans ce répertoire. La seule piste d'interconnexion publique est la politique RIPE, les collecteurs de routes et les identités des amonts observés ou enregistrés.

Le résultat de sécurité de l'origine de route est positif. Lavalidation RPKI pour 217.174.144.0/24de RIPEstat signale un ROA valide pour AS42347 originaire du /24 exact avec une longueur max /24. Cela aide les réseaux qui appliquent la validation de l'origine de route à accepter la route comme autorisée. Cela ne protège pas contre une panne d'hôte, une panne de stockage, une mauvaise configuration de routeur, des factures d'amont impayées, une compromission du panneau de contrôle ou un verrouillage de compte client. RPKI répond à la question de qui peut originer le préfixe, pas à celle de savoir si le service d'hébergement peut récupérer.

Pour les acheteurs, la question de diligence du transit est pratique: Telehouse est-il l'amont actif pour tous les services Hosting27, AS31083 est-il une entrée de secours ou de politique historique, l'un ou l'autre chemin peut-il porter la charge de travail du client pendant la maintenance, et les routes sont-elles annoncées à partir de liaisons physiquement séparées ou de la même salle et chaîne de dépendance?

Les fonctionnalités cloud annoncées ne correspondent pas à une capacité installée, utilisable ou récupérable

L'économie de l'hébergement récompense le partage efficace. L'hébergement mutualisé vend du disque, de la messagerie et de la gestion de site en regroupant de nombreux comptes clients sur un ou plusieurs serveurs. L'hébergement VPS vend des tranches de CPU virtuel, de RAM et de stockage à partir d'hôtes plus grands. Le VPS géré ajoute du travail de support, de la surveillance et de l'administration. Le cloud privé ajoute une couche d'orchestration et une promesse plus forte de contrôle client. Kubernetes ajoute une autre couche d'orchestration au-dessus.

Chaque couche peut être réelle tout en dépendant d'un petit nombre de nœuds physiques.

Les pages de Hosting27 font des affirmations larges qui sont plausibles pour un petit fournisseur bulgare mais impossibles à dimensionner de l'extérieur. Les plans d'hébergement mutualisé annoncent des sites, des boîtes mail et un trafic illimités, mais ce sont des règles de plan, pas une capacité infinie. Le service dépend toujours du CPU, de la RAM, des E/S de stockage, des limites d'inode, des règles d'utilisation équitable, du contrôle du spam et de la gestion des abus.

Les plans revendeurs annoncent un trafic et des comptes illimités, mais les plafonds de stockage sont de 40 Go, 75 Go et 130 Go; la contrainte réelle peut être les E/S, la réputation de messagerie sortante, la densité de comptes ou les performances de l'hôte mutualisé avant que le disque brut ne soit épuisé.

Les pages VPS sont plus concrètes car elles listent les valeurs de CPU virtuel, de RAM et de SSD. Un plan Cloud VPS à un vCPU, 1 Go de RAM, 30 Go SSD et un plan à quatre vCPU, 6 Go de RAM, 85 Go SSD peuvent être provisionnés à partir d'un cluster OpenStack modeste. Mais un tableau de plan ne montre pas combien d'instances peuvent être vendues sans contention, combien de nœuds existent, si le CPU est sursouscrit, comment la réplication du stockage est réglée, si Ceph couvre des domaines d'alimentation indépendants, ou si les sauvegardes sont stockées sur le même système physique qu'elles sont censées protéger.

La page dit que Ceph conserve les données répliquées à plusieurs endroits; un client a encore besoin de savoir si ces endroits sont des disques séparés, des châssis séparés, des racks séparés ou des installations séparées.

Le langage de niveau de service de 99,99 % de la page private cloud doit être traité comme une affirmation à vérifier, pas comme une preuve de l'état opérationnel atteint. Quatre neuf de disponibilité ne permettent qu'une petite quantité de temps d'arrêt sur une année, et exigent à la fois une architecture et une discipline opérationnelle: alimentation redondante, chemins réseau redondants, stockage soigneusement géré, récupération du plan de contrôle testée, gestion des changements, surveillance et une équipe de support capable d'agir rapidement.

Le site public ne publie pas le document SLA, le barème des crédits, la méthode de mesure, les exclusions, le traitement de la maintenance planifiée ou l'historique des incidents qui permettraient à un acheteur d'évaluer cette promesse.

Le stock d'adresses limite certains cas d'utilisation. Un client qui a besoin de nombreuses adresses IPv4 publiques, de la séparation du service de messagerie, de la compatibilité héritée SSL basée sur IP, de l'isolation anti-abus ou de points de terminaison VPN devrait demander combien d'IPv4 sont réellement disponibles. Le comptage de 256 adresses IPv4 de lavue routing-statusde RIPEstat n'est pas la même chose que 256 IP clientes vendables. Certaines sont consommées par l'infrastructure, le DNS, l'hébergement mutualisé, la gestion, les réserves et les allocations aux clients. Des IP supplémentaires sont vendues sur la page Cloud VPS, ce qui rend le pool opérationnellement important. Si des problèmes d'abus ou de liste noire affectent une partie du /24, la petite taille du pool d'adresses peut rendre la récupération plus difficile.

IPv6 est une autre lacune. Les pages de produits publiques de Hosting27 examinées ici ne font pas de promesse IPv6 forte, et RIPEstat ne montre pas d'espace annoncé IPv6 visible pour AS42347 au moment de la vérification. Un client nécessitant un hébergement compatible IPv6 ne devrait pas le déduire du mot cloud. Il devrait demander une adresse de test IPv6, la couverture SLA, la gestion du pare-feu, le DNS inverse, les preuves de routage et si le support IPv6 est disponible sur l'hébergement mutualisé, le VPS, le cloud privé et Kubernetes de la même manière qu'IPv4.

La conclusion de capacité de l'article est donc prudente: Hosting27 vend un ensemble réel de produits d'hébergement et de cloud, et AS42347 donne à ces produits une périphérie réseau publique réelle. Mais il n'y a aucune preuve publique qui traduise le menu de plans en nœuds installés, en capacité de réserve disponible, en conception multi-site ou en images récupérables par le client.

Les affirmations de support et de sauvegarde sont utiles, mais l'autorité de réparation est la question centrale

Les preuves de support valent mieux que le silence. Lapage de contactde Hosting27 liste les adresses de support, y compris les boîtes mail support et devops, et une adresse de vente séparée. Lapage de tickets d'assistanceindique que les clients qui ne peuvent pas résoudre un problème dans la documentation peuvent envoyer une demande au service approprié. Elle décrit le support comme fonctionnant tous les jours sans interruption et les demandes commerciales comme traitées du lundi au vendredi de 09h00 à 18h00. Labase de connaissancesa des catégories pour cPanel, Virtualmin, les serveurs VPS, WordPress, les domaines et l'hébergement mutualisé. Lapage d'annoncescontient une ancienne annonce de site web de 2018, ce qui montre au moins que le portail client fait partie de la surface de service depuis des années.

Ce sont des signes opérationnels utiles. Ils ne sont pas suffisants pour répondre au risque de fenêtre de réparation. La distinction la plus importante est entre un canal de support qui reçoit des tickets et une équipe d'exploitation ayant autorité sur le composant défaillant. Si le défaut est un paramètre cPanel, le helpdesk du fournisseur peut le corriger rapidement.

Si le défaut est un disque mort, un commutateur défaillant, un problème d'alimentation, un problème de quorum de cluster de stockage, un filtre de route amont ou un compte de facturation verrouillé, la réparation dépend de qui contrôle le matériel, l'accès à l'installation, les sessions de routeur et les autorisations contractuelles.

Les conditions générales sont également utiles mais incomplètes pour la planification des incidents. Le PDF dit que les serveurs virtuels gérés incluent un support technique 24 heures sur 24, une surveillance et une réaction aux problèmes, des sauvegardes régulières et la capacité d'héberger les applications des clients. Il dit que l'hébergement mutualisé inclut un support technique et précise que les utilisateurs mutualisés partagent les ressources.

Les pages publiques annoncent en outre des sauvegardes quotidiennes sur Cloud VPS et managed Cloud VPS, des sauvegardes d'un mois sur l'hébergement mutualisé et une migration gratuite pour certains plans. C'est précieux. Cela laisse tout de même les questions pratiques ouvertes: les sauvegardes sont-elles sur le même cluster ou hors site, combien de générations existent, un client peut-il restaurer en libre-service, une image de VM peut-elle être exportée, que se passe-t-il après la suspension du compte, et quel est le temps de restauration cible?

La promesse de migration est également plus étroite qu'il n'y paraît. Hosting27 dit pouvoir déplacer un compte d'hébergement ou un site WordPress gratuitement. Cela aide lors de l'intégration. Cela ne crée pas nécessairement un chemin de sortie. Un client qui part plus tard peut avoir besoin d'une sauvegarde cPanel complète, d'un dump de base de données, de fichiers de zone DNS, de boîtes mail, d'une image disque de VM, d'un instantané de stockage en bloc, de données d'objet, de manifests Kubernetes, d'images de conteneur, de secrets et de la renumérotation IP.

Le site public ne décrit pas les formats d'exportation, les fenêtres de rétention, les frais de migration après résiliation ou si les clients peuvent extraire des images d'OpenStack.

La gestion des abus est importante car les fournisseurs d'hébergement vivent et meurent par la réputation partagée. L'enregistrement d'organisation RIPE pour Hosting-27 renvoie l'abus àGLAC2-RIPE, un contact d'abus GateIT. C'est un chemin d'abus de registre, pas nécessairement le même qu'un bureau d'assistance commercial. Un client gérant du courrier, du commerce électronique ou des API publiques devrait demander qui gère le DNS inverse, qui gère la remédiation des listes noires, qui décide si un compte compromis entraîne une suspension plus large, et si les problèmes de réputation IP peuvent être isolés à l'intérieur du /24.

La posture de support publique est donc suffisamment crédible pour compter, mais pas assez détaillée pour éliminer le risque opérationnel. Les acheteurs devraient tester le bureau de tickets avant de déplacer des charges de travail importantes, demander un chemin de contact d'incident, et exiger des conditions écrites de sauvegarde et d'exportation plutôt que de se fier aux abréviations des pages de plan.

La localité des données n'est pas réglée par une adresse bulgare ou une IP bulgare

La surface bulgare de Hosting27 est pertinente. Le site web est en langue bulgare, la page de contact donne des détails sur Sofia, l'organisation et l'adresse RIPE sont bulgares, l'ASN est dans la région RIPE, et le bloc IPv4 visible est enregistré avec le pays BG. Pour les clients avec des utilisateurs bulgares, une facture bulgare, un support en langue locale et une latence vers Sofia ou les réseaux régionaux peuvent être des raisons de considérer le service. Pour les clients ayant des exigences réglementaires ou contractuelles de localité des données, ces signes ne sont que le début.

Le contexte européen et bulgare rend la distinction importante. La vue d'ensemble de la Commission européenne sur lecadre juridique de protection des données de l'UEexplique le régime de protection des données à l'échelle de l'UE. Sa page sur lesresponsables de traitement et sous-traitantsexplique la distinction entre la partie qui décide comment les données personnelles sont traitées et une partie qui les traite pour le compte d'une autre. La page desclauses contractuelles typesde la Commission couvre les outils de transfert de données pour les situations hors de l'Espace économique européen. LaCommission pour la protection des données personnellesde Bulgarie est l'autorité nationale de contrôle. Cet article n'est pas un avis juridique, mais ces références publiques montrent pourquoi la localisation de l'infrastructure, l'accès au support et la géographie des sauvegardes ne sont pas des détails cosmétiques.

Une adresse IP bulgare ne prouve pas que toutes les données restent en Bulgarie. Les sauvegardes de l'hébergement mutualisé pourraient être stockées dans une autre installation. La surveillance pourrait être effectuée depuis ailleurs. Un ticket de support pourrait inclure des données personnelles. Un panneau de contrôle pourrait dépendre de logiciels tiers ou d'une authentification externe. Une fonctionnalité CDN pourrait intentionnellement placer du contenu statique dans d'autres pays.

Un service d'enregistrement de domaine interagit nécessairement avec des registres et des bureaux d'enregistrement en dehors du nœud d'hébergement. Un client de cloud privé peut créer des réseaux et des volumes dans une console d'apparence bulgare tandis que certains composants de gestion ou de sauvegarde se trouvent ailleurs.

Les bonnes questions de diligence sont donc concrètes. Où se trouve le nœud de calcul principal? Où sont stockés les instantanés et les sauvegardes? Le personnel de support et les administrateurs à distance sont-ils dans l'UE? Le fournisseur propose-t-il un accord de traitement des données? Quelle entité juridique est le sous-traitant pour les services d'hébergement? Le contrat nomme-t-il la même partie qui facture le client? Si les données quittent la Bulgarie ou l'EEE, quel mécanisme de transfert s'applique? Que se passe-t-il si le client demande la suppression ou l'exportation?

Quels journaux sont conservés, et pendant combien de temps?

Ces questions ne sont pas une suspicion particulière envers Hosting-27. Elles sont normales pour tout petit fournisseur de cloud ou d'hébergement qui commercialise la localité. Les preuves publiques ici soutiennent une zone de service bulgare et une périphérie routée bulgare. Elles ne prouvent pas une architecture complète de résidence des données en Bulgarie.

Les chemins de défaillance à tester sont le rack, l'amont, le stock de matériel, le support, la facturation et la migration

Le premier chemin de défaillance est le rack. Si un serveur d'hébergement mutualisé ou un hôte VPS tombe en panne, qui touche la machine? Un client devrait demander où se trouve le rack, qui possède le matériel hôte, comment l'alimentation est protégée, s'il y a des nœuds de rechange, si le stockage est local ou distribué, et si un nœud défaillant peut être évacué sans changer l'IP du client. Le site web public revendique des sauvegardes et des fonctionnalités cloud, mais il ne nomme pas l'installation physique, la baie, le fournisseur d'interventions à distance ou le plan de matériel de rechange.

Le deuxième chemin est le transit amont. RIPEstat voit actuellement AS42347 via AS57344. Le fournisseur devrait être en mesure de dire si la route a un deuxième amont actif, si Telepoint est actif, de secours ou historique, si la route de secours est testée, si la validation de l'origine de route est surveillée, et si les clients reçoivent un préavis avant la maintenance du réseau. Un résultat RPKI valide est bon. Ce n'est pas la même chose qu'un deuxième chemin.

Le troisième chemin est le stock de matériel et de stockage. Les offres VPS et cloud privé dépendent du ratio entre les plans vendus et le calcul, la RAM, les E/S disque et la réplication du stockage disponibles. Un client devrait demander si les ressources annoncées sont garanties, si le CPU est sursouscrit, si Ceph couvre des hôtes séparés ou des racks séparés, combien de défaillances peuvent être tolérées, et s'il y a assez de capacité de réserve pour restaurer un hôte pendant une période chargée.

La page publique nomme OpenStack, KVM et Ceph, mais ces noms peuvent décrire n'importe quoi, d'un petit cluster à un environnement multi-rack plus grand.

Le quatrième chemin est l'escalade du support. Hosting27 expose des pages de support, de vente, de base de connaissances et de tickets. L'acheteur devrait tout de même tester la qualité de la réponse, demander qui est d'astreinte, identifier le chemin d'urgence pour une VM en panne, et demander si le support peut joindre directement les opérateurs réseau et d'installation. Une réponse commerciale n'est pas la même chose que l'autorité d'incident.

Le cinquième chemin est la continuité de la facturation et juridique. Les conditions PDF du site web nomment Cloud Systems OOD comme fournisseur, tandis que RIPE nomme Hosting-27 LTD comme organisation réseau. Les clients devraient demander quelle partie signe le contrat, quelle partie facture, quelle partie contrôle la suspension du service, et quelle partie est responsable de l'exportation et de la suppression après résiliation. Si le compte est suspendu pour facturation ou abus, le client devrait savoir combien de temps les données restent récupérables.

Le sixième chemin est la migration. Pour l'hébergement mutualisé, le chemin de sortie devrait inclure la sauvegarde cPanel, le DNS, les boîtes mail et les bases de données. Pour WordPress, il devrait inclure les fichiers, la base de données, les redirections et le timing DNS. Pour le VPS, il devrait inclure l'exportation d'image disque, le format d'instantané, la renumérotation IP et les mises à jour du pare-feu. Pour le cloud privé et Kubernetes, il devrait inclure les volumes, les réseaux, les équilibreurs de charge, les manifests, les secrets et les registres d'images.

Hosting27 commercialise la migration entrante gratuite, mais le matériel public ne publie pas une promesse complète de portabilité sortante.

Le septième chemin est la réputation d'adresse. Un /24 compact peut être efficace, mais il donne moins de place pour isoler les clients compromis. Les problèmes de courrier, de proxy, de scan et d'abus peuvent conduire à des listes noires, au filtrage amont ou à des suspensions internes. Les clients avec des charges de travail de messagerie ou transactionnelles devraient demander le contrôle du DNS inverse, la procédure de réponse aux abus, la politique de nettoyage des listes noires et si des adresses IP supplémentaires proviennent du même pool 217.174.144.0/24.

Ce ne sont pas des préoccupations théoriques. Ce sont les modes de défaillance ordinaires cachés sous l'hébergement à bas coût: un rack qui ne peut pas être atteint, une session amont qui disparaît, un cluster de stockage qui perd le quorum, une sauvegarde qui existe mais ne peut pas être restaurée rapidement, une file de tickets qui ne peut pas atteindre l'installation, et un client qui découvre trop tard que déménager signifie reconstruire autour de nouvelles adresses IP.

Ce qui rendrait les preuves solides

Hosting-27 Hosting-27 LTD a suffisamment de preuves publiques pour un profil opérationnel réel: le site web est en ligne, le portail client est en ligne, les pages produits sont spécifiques, la route est visible, le domaine se résout à l'intérieur du bloc IPv4 visible de l'entreprise, l'organisation RIPE est à jour, et l'autorisation d'origine de route est valide. C'est matériellement plus fort qu'une entreprise dont la seule trace est un enregistrement AS périmé.

Les preuves publiques ne sont pas assez solides pour une confiance élevée dans l'infrastructure sans diligence directe.

Un profil plus solide inclurait une page légale actuelle qui aligne la marque, l'organisation RIPE et le fournisseur contractant; une déclaration d'installation nommant l'opérateur du centre de données ou expliquant l'accord d'hébergement; un SLA avec des conditions de mesure et de crédit; une page de statut ou un historique d'incidents; des objectifs explicites de rétention et de restauration des sauvegardes; la disponibilité IPv6 si offerte; un deuxième amont actif ou une explication écrite de la politique de route Telepoint; des formats d'exportation pour les données VPS et cloud privé; et une procédure claire

d'abus et de réputation IP.

L'ensemble probable de clients devrait être hiérarchisé par risque. Un petit site web bulgare, un serveur de staging, un site WordPress non critique ou un VPS expérimental peuvent évaluer Hosting27 par des tests de service ordinaires: commander un petit plan, tester le support, vérifier la latence, restaurer une sauvegarde et vérifier l'annulation. Un système critique pour l'entreprise ne devrait pas se fier uniquement au tableau des plans. Il devrait obtenir des réponses écrites sur l'installation, les sauvegardes, la diversité du transit, les contrats légaux et la portabilité des données avant de déplacer la production.

La lecture finale est équilibrée. Hosting-27 Hosting-27 LTD est visible comme un vendeur de capacité hébergée bulgare avec AS42347 et une plateforme Hosting27.com en ligne. Son histoire opérationnelle publique n'est pas vide. Mais les faits d'infrastructure décisifs restent derrière la couche de vente.

Jusqu'à ce que ces faits soient divulgués ou vérifiés dans un contrat client, Hosting27 doit être compris comme un fournisseur compact d'hébergement et de services cloud bulgares dont la promesse client dépend encore de racks invisibles, d'un transit visible par Telehouse, d'un stock IPv4 fini, de main-d'œuvre de support, de contrats de fournisseur et de fenêtres de réparation.