Résumé
- Hosting-27 Hosting-27 LTD n'est pas une entreprise visible uniquement dans les enregistrements de routage. La page d'accueil liveHosting27.comfait la publicité de services d'hébergement et de cloud bulgares, lapage de contactdonne une adresse à Sofia, un téléphone et des adresses e-mail de support, l'espace clientexpose un portail de connexion et de facturation, et lapage de tickets de supportdécrit un service de support travaillant tous les jours. Cette surface de vente publique est réelle, mais elle ne prouve pas en elle-même où se trouvent les serveurs ni comment les pannes sont réparées.
- L'identité réseau est concrète et compacte. La base de données RIPEobjet AS42347nomme Hosting-27, lie l'AS àORG-HA629-RIPE, liste Hosting-27 LTD comme organisation, donne le pays BG, le numéro d'enregistrement 204354361 et une adresse à Sofia, et enregistre les imports et exports avec AS57344 et AS31083. Leinetnum 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 de routage live 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 deuxième pair, AS31083 Telepoint, apparaît dans la politique de registre d'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é, leCloud VPS, leCloud VPS géré, lecloud privéetKubernetesmontrent une offre de capacité hébergée large. Les preuves publiques ne montrent pas de salle de centre de données nommée, de nombre de baies, de conception électrique, de stock matériel, de conditions de conservation des sauvegardes clients, de double transit actif, de service IPv6 ou de chemin de portabilité écrit.
La surface de service est visible, mais elle doit être lue depuis le rack vers l'extérieur
Hosting-27 Hosting-27 LTD ne doit pas être confondu avec un enregistrement de numéro Internet vide. Le site public Hosting27.com est live, daté par ses propres métadonnées d'en-tête et pages visibles, et construit comme une vitrine 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é, le Cloud VPS, le Cloud VPS géré, l'hébergement revendeur, les domaines, un espace client, les factures et les tickets de support. La navigation n'est pas un espace réservé d'une seule page abandonné; c'est une surface de vente d'hébergement avec des niveaux de produits, des boutons de commande, un espace de compte de style WHMCS et un portail de support.
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, un transit amont, de l'alimentation, du refroidissement, des mains distantes, l'état de facturation, le traitement des abus et une équipe de support avec 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 baies, loue de l'espace en baie, dépend d'un autre opérateur de centre de données bulgare, ou revend une capacité assemblée par un fournisseur lié.
Le menu de 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 plans avec 20 Go, 50 Go et 165 Go d'espace, cPanel, sites illimités, boîtes aux lettres illimitées, certificats SSL gratuits, CDN, aide à la migration, plusieurs versions de PHP et 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 être créés dessus, et que les migrations et sauvegardes font partie de la promesse de service.
Le menu cloud augmente les enjeux. Lapage Cloud VPSpropose des instances d'un à quatre CPU virtuels, 1 Go à 6 Go de RAM, 30 Go à 85 Go de stockage tout SSD, sauvegardes quotidiennes, 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 Cloud VPS gérépropose des serveurs gérés avec panneau de contrôle, support technique, sauvegardes quotidiennes, surveillance 24h/24 et migration gratuite. Lapage cloud privéva plus loin, décrivant une offre de centre de données virtuel basé sur OpenStack avec stockage défini par logiciel, une revendication de niveau de service à 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 à l'installation, la configuration et la maintenance d'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 preuve plus grand. Un vendeur de VPS à un nœud peut échouer silencieusement.
Un vendeur d'OpenStack, Ceph, cloud privé et Kubernetes doit répondre à plus de questions: combien de nœuds physiques sont disponibles, comment la réplication de 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 sert les clients, quel routeur porte la route, et qui peut réparer le système lorsque la couche physique échoue.
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. Le dossier public soutient l'existence d'une opération d'hébergement bulgare. Il ne soutient pas une conclusion solide sur la capacité cloud installée, la reprise multi-sites ou l'indépendance du fournisseur.
Le registre RIPE donne à Hosting-27 une bordure 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 pour AS42347nomme l'AS "Hosting-27", liste Hosting-27 LTD via ORG-HA629-RIPE, enregistre le statut ASSIGNED, donne la création le 24 août 2017 et la dernière modification le 7 avril 2021, et enregistre la politique 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 Todor Aleksandrov 133, et un contact abus à 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 de RIPE pour 217.174.144.0 - 217.174.144.255utilise netname Hosting-27, pays BG, organisation ORG-HA629-RIPE et statut ASSIGNED PA. L'objet route de 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 pairs RIPE RIS sur 326 au moment vérifié.
Ce /24 n'est pas seulement un enregistrement passif. Le domaine Hosting27.com lui-même résout dans le même bloc. La vueDNS-chain de RIPEstat pour hosting27.coma résolu hosting27.com en 217.174.144.181, a associé inversement cette adresse à shared-11.cpaneler.com, et a listé des serveurs de noms faisant autorité dont 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 registrar 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 routeur, les hôtes d'infrastructure, les serveurs de noms, les IP d'hébergement mutualisé, les attributions clients, les adresses de réserve et la capacité réservée. C'est suffisant pour une véritable entreprise d'hébergement, 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 recevoir plusieurs adresses publiques chacun. Ce n'est pas suffisant pour déduire une grande capacité installée.
Une offre de cloud privé, une offre Kubernetes, des comptes revendeurs, un VPS géré et un 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 prudente sont utilisés. Ils peuvent également être survendus si la planification est lâche. La route publique ne distingue pas ces cas.
Il existe également un deuxième objet route qui doit être traité avec précaution. La vueAS-routing-consistencyde RIPEstat liste 45.151.89.0/24 comme présent dans whois mais pas dans 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 qu'une 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. Elle ne doit pas être comptée comme capacité Hosting-27 disponible pour les clients à moins que des preuves BGP et commerciales actuelles ne la soutiennent.
La bordure réseau est donc réelle mais étroitement délimitée: un AS visible, un /24 IPv4 visible, un objet route valide, un site web live dans le bloc et aucun préfixe IPv6 visible pour AS42347 dans la vue de route RIPEstat.
Le bureau, le site web et le nom contractuel ne sont pas la même chose qu'une salle de données vérifiée
La piste d'adresse publique est utile, mais elle n'identifie pas un centre de données. Lapage de contactde Hosting27 donne Sofia, Todor Aleksandrov Boulevard 133, étage 2, plus un numéro de téléphone et des adresses e-mail de support et de vente. L'enregistrement d'organisation RIPE pour Hosting-27 LTD donne une adresse correspondante Todor Aleksandrov 133. L'enregistrement d'organisation RIPEde Geytit OOD utilise également Todor Aleksandrov 133 et apparaît comme l'organisation parrainante sur l'enregistrement AS42347. Ces enregistrements sont significatifs pour le contact et l'administration du registre. Ils ne prouvent pas que les serveurs clients se trouvent dans ce bâtiment, que Hosting-27 y possède des baies, ou que l'entreprise a un accès direct à l'alimentation et à l'infrastructure de cross-connect.
Les conditions juridiques publiques ajoutent une autre limite. Lapage des conditions généralesde Hosting27 intègre un PDF, et lesconditions PDFstipulent 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 conclusion de relation d'entreprise. Il le traite comme un problème de diligence de l'acheteur: la marque, l'organisation RIPE, le LIR parrainant, 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 en cas de panne, pas seulement lors de l'achat. Si une VM échoue à 2h00, le client doit savoir quelle entité contrôle la file d'attente de support, quelle entité possède ou loue le matériel, qui peut autoriser les mains distantes, qui peut remplacer un disque, qui contrôle la session routeur, qui facture le service et qui peut préserver les données en cas de litige de facturation.
Un décalage entre la marque, le détenteur de l'AS et le fournisseur contractuel n'est pas intrinsèquement mauvais; de nombreux groupes d'hébergement utilisent des véhicules juridiques distincts pour les ressources d'adresses, les contrats clients, les installations et les opérations. Mais les documents publics examinés ici n'expliquent pas cette structure. Les clients devraient demander directement.
Les conditions indiquent également que le service hébergé est une offre limitée, pas une garantie que chaque client reçoive un environnement entièrement indépendant. Le PDF indique que l'hébergement mutualisé implique que les clients partagent des 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 panneau de contrôle, support 24h/24, ressources garanties non partagées avec d'autres applications clientes, surveillance, réaction aux problèmes et sauvegardes régulières.
C'est un langage utile pour comprendre les classes de service prévues. Il laisse toujours flous le temps de restauration, l'emplacement des sauvegardes, la durée de conservation des instantanés, la réplication hors site, le format d'exportation client et les crédits d'interruption dans la vue publique.
Le cadrage "centre de données virtuel" de la page cloud privé est particulièrement important à qualifier. 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 virtuelles du plan de contrôle. Elles reposent toujours sur des nœuds physiques, des disques, des cartes réseau, des commutateurs de tête de baie, des alimentations et des liens de transit.
Sans installation nommée ou déclaration d'architecture, la revendication doit être traitée comme une offre de plan de contrôle cloud, pas comme une preuve d'un site physique séparé.
La dépendance amont visible est Telehouse, tandis que Telepoint est une possibilité politique
L'image de routage est simple au point d'observation actuel. La vueASN-neighboursde RIPEstat pour AS42347 a rapporté un voisin unique au dernier moment disponible: AS57344. Lavue d'ensemble AS de RIPEstat pour AS57344identifie AS57344 comme TELEHOUSE-AS Telehouse EAD. L'aut-num AS57344de RIPE 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'installation.
Cette largeur de Telehouse aide à expliquer comment le /24 de Hosting-27 peut être visible depuis des collecteurs mondiaux. Cela ne rend pas automatiquement Hosting-27 multi-hébergé. La dépendance immédiate observée pour AS42347 est toujours un voisin. Si la route AS42347 n'est portée que par Telehouse à la bordure active, alors un problème côté Telehouse, une session, un filtre de route, un incident d'installation, un problème de cross-connect, un gel commercial ou une fenêtre de maintenance peut affecter tous les clients utilisant le préfixe visible de Hosting-27.
Les collecteurs de route publics peuvent manquer des chemins de sauvegarde privés, des sessions temporairement inactives ou des arrangements qui ne deviennent actifs qu'en cas de panne. Mais la charge incombe au fournisseur de 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 d'AS42347 liste la politique d'import et d'export avec AS31083, et lavue d'ensemble AS31083de RIPEstat identifie AS31083 comme Telepoint Ltd. L'aut-num AS31083de RIPE montre Telepoint connecté à plusieurs amonts, et l'enregistrement Telepointde PeeringDB rapporte un profil de plus petite portée européenne. Mais la vue AS-routing-consistency de RIPEstat montre AS31083 comme présent dans la politique whois et non présent dans 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 le besoin 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 une faute. Cela signifie qu'il n'y a pas de liste publique d'installations Hosting-27, de liste d'échange, de page de 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 route et les identités des amonts observés ou enregistrés.
Le résultat de sécurité d'origine de route est positif. Lavalidation RPKI pour 217.174.144.0/24rapporte un ROA valide pour AS42347 originait le /24 exact avec une longueur maximale /24. Cela aide les réseaux qui appliquent la validation d'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 amont impayées, un compromis du panneau de contrôle ou un verrouillage de compte client. RPKI répond à qui peut annoncer le préfixe, pas si le service d'hébergement peut récupérer.
Pour les acheteurs, la question de diligence sur le transit est pratique: Telehouse est-il l'amont actif pour tous les services Hosting27, AS31083 est-il une entrée de politique de secours ou historique, l'un ou l'autre chemin peut-il transporter la charge de travail du client pendant la maintenance, et les routes sont-elles annoncées depuis des points de remise physiquement séparés ou depuis la même salle et chaîne de dépendance?
Les fonctionnalités cloud annoncées ne sont pas égales à 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, du courrier 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 de la main-d'œuvre 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, boîtes aux lettres et 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, de l'E/S de stockage, des limites d'inodes, des règles d'utilisation équitable, du contrôle du spam et de la gestion des abus.
Les plans revendeur annoncent un trafic et des comptes illimités, mais les limites de stockage sont de 40 Go, 75 Go et 130 Go; la contrainte réelle peut être l'E/S, la réputation du courrier sortant, la densité des comptes ou les performances de l'hôte partagé avant que le disque brut ne soit épuisé.
Les pages VPS sont plus concrètes car elles listent les valeurs de CPU virtuel, RAM et SSD. Un plan Cloud VPS avec 1 vCPU, 1 Go de RAM, 30 Go de SSD et un plan avec 4 vCPU, 6 Go de RAM, 85 Go de SSD peuvent être provisionnés à partir d'un cluster OpenStack modeste. Mais un tableau de plans ne montre pas combien d'instances peuvent être vendues sans contention, combien de nœuds existent, si le CPU est sur-abonné, comment la réplication de stockage est ajustée, si Ceph s'étend sur 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 indique que Ceph maintient les données répliquées à plusieurs endroits; un client a toujours besoin de savoir si ces endroits sont des disques séparés, des châssis séparés, des baies séparées ou des installations séparées.
Le langage de niveau de service à 99,99 % de la page cloud privé doit être traité comme une affirmation à vérifier, pas comme une preuve de l'état opérationnel atteint. Quatre 9 de disponibilité ne permettent qu'une petite quantité de temps d'arrêt sur une année, et cela nécessite à la fois une architecture et une discipline opérationnelle: alimentation redondante, chemins réseau redondants, stockage géré avec soin, récupération testée du plan de contrôle, gestion des changements, surveillance et une équipe de support capable d'agir rapidement.
Le site public ne publie pas le document SLA, le calendrier de crédit, 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 séparation de services de courrier, de compatibilité SSL héritée basée sur IP, d'isolation anti-abus ou de points de terminaison VPN devrait demander combien d'IPv4 sont réellement disponibles. Le comptage deRIPEstat routing-statusde 256 adresses IPv4 n'est pas la même chose que 256 IP client vendables. Certaines sont consommées par l'infrastructure, le DNS, l'hébergement mutualisé, la gestion, les réserves et les attributions 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, le petit pool d'adresses peut rendre la récupération plus difficile.
IPv6 est une autre lacune. Les pages produits publiques de Hosting27 examinées ici ne font pas une promesse forte d'IPv6, et RIPEstat ne montre aucun espace IPv6 annoncé visible pour AS42347 au moment vérifié. Un client ayant besoin d'hébergement compatible IPv6 ne devrait pas le déduire du mot cloud. Il devrait demander une adresse de test IPv6, une couverture SLA, la gestion du pare-feu, le DNS inverse, des 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 que l'IPv4.
La conclusion de capacité de l'article est donc conservative: Hosting27 vend un ensemble réel de produits d'hébergement et de cloud, et AS42347 donne à ces produits une véritable bordure réseau publique. Mais il n'y a aucune preuve publique qui traduit le menu de plans en nœuds installés, capacité de réserve disponible, conception multi-site ou 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 sont meilleures que le silence. Lapage de contactde Hosting27 liste des adresses de support, y compris des boîtes aux lettres support et devops, et une adresse de vente séparée. Lapage de tickets de supportindique que les clients qui ne peuvent pas résoudre un problème dans la documentation peuvent envoyer une demande au département approprié. Elle décrit le support comme travaillant tous les jours sans interruption et les demandes de vente comme traitées du lundi au vendredi de 09h00 à 18h00. Labase de connaissancesa des catégories pour cPanel, Virtualmin, serveurs VPS, WordPress, domaines et hébergement mutualisé. Lapage d'annoncescontient une annonce de site web plus ancienne 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 suffisent pas à 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 avec autorité sur le composant défaillant. Si la panne est un paramètre cPanel, le service d'assistance du fournisseur peut le réparer rapidement.
Si la panne 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 route et les permissions contractuelles.
Les conditions générales sont également utiles mais incomplètes pour la planification des incidents. Le PDF indique que les serveurs virtuels gérés incluent un support technique 24h/24, une surveillance et une réaction aux problèmes, des sauvegardes régulières et la possibilité d'héberger des applications clientes. Il indique que l'hébergement mutualisé inclut un support technique et précise que les utilisateurs mutualisés partagent des ressources.
Les pages publiques annoncent en outre des sauvegardes quotidiennes sur le Cloud VPS et le Cloud VPS géré, des sauvegardes d'un mois sur l'hébergement mutualisé et une migration gratuite pour certains plans. C'est précieux. Cela laisse toujours ouvertes les questions pratiques: 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 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 indique qu'il peut 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 une voie de sortie. Un client qui part plus tard peut avoir besoin d'une sauvegarde complète cPanel, d'un dump de base de données, de fichiers de zone DNS, de boîtes aux lettres, d'une image disque VM, d'un instantané de stockage par blocs, de données d'objet, de manifests Kubernetes, d'images conteneur, de secrets et de renumérotation IP.
Le site public ne décrit pas les formats d'exportation, les fenêtres de conservation, les frais de migration après annulation ou si les clients peuvent extraire des images d'OpenStack.
Le traitement des abus est important car les fournisseurs d'hébergement vivent et meurent par la réputation partagée. L'enregistrement d'organisation RIPE pour Hosting-27 pointe les abus versGLAC2-RIPE, un contact d'abus GateIT. C'est un chemin d'abus de registre, pas nécessairement le même qu'un bureau de support de détail. Un client exploitant du courrier, du commerce électronique ou des API publiques devrait demander qui gère le DNS inverse, qui s'occupe du nettoyage des listes noires, qui décide si un compte compromis provoque 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 public est donc suffisamment crédible pour compter, mais pas assez détaillée pour supprimer 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 demander des conditions écrites de sauvegarde et d'exportation plutôt que de se fier au langage abrégé des pages de plan.
La localisation 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 RIPE et l'adresse sont bulgares, le SN 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 d'envisager le service. Pour les clients avec des exigences réglementaires ou contractuelles de localisation des données, ces signes ne sont que le début.
Le contexte de l'UE et de la Bulgarie rend la distinction importante. L'aperçu de la Commission européenne sur lecadre juridique de la protection des données de l'UEexplique le régime de protection des données à l'échelle de l'UE. Sa page sur lesresponsables du 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 de la Commission sur lesclauses contractuelles typescouvre les outils de transfert de données pour les situations en dehors de l'Espace économique européen. LaCommission bulgare pour la protection des données personnellesest l'autorité de surveillance nationale. Cet article n'est pas un conseil juridique, mais ces références publiques montrent pourquoi l'emplacement 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 d'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 registraires 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 distants 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 des données?
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 bordure 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 la baie, l'amont, le stock matériel, le support, la facturation et la migration
Le premier chemin de défaillance est la baie. 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 la baie, 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 annonce des sauvegardes et des fonctionnalités cloud, mais il ne nomme pas l'installation physique, la baie, le fournisseur de mains distantes 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 pouvoir 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 d'origine de route est surveillée, et si les clients reçoivent un préavis avant la maintenance 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 disponible, la RAM, l'E/S disque et la réplication de stockage. Un client devrait demander si les ressources annoncées sont garanties, si le CPU est sur-abonné, si Ceph s'étend sur des hôtes séparés ou des baies séparées, combien de pannes peuvent être tolérées, et s'il y a suffisamment 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-baies plus grand.
Le quatrième chemin est l'escalade du support. Hosting27 expose les pages de support, de vente, de base de connaissances et de tickets. L'acheteur devrait encore tester la qualité de réponse, demander qui est d'astreinte, identifier le chemin d'urgence pour une VM en panne, et demander si le support peut contacter directement les opérateurs de réseau et d'installation. Une réponse commerciale n'est pas la même chose qu'une autorité d'incident.
Le cinquième chemin est la continuité de 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 annulation. 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 une sauvegarde cPanel, DNS, boîtes aux lettres et bases de données. Pour WordPress, il devrait inclure fichiers, base de données, redirections et timing DNS. Pour VPS, il devrait inclure export d'image disque, format d'instantané, renumérotation IP et mises à jour de pare-feu. Pour le cloud privé et Kubernetes, il devrait inclure volumes, réseaux, équilibreurs de charge, manifests, secrets et registres d'images.
Hosting27 commercialise une migration entrante gratuite, mais le matériel public ne publie pas de 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, proxy, scan et abus peuvent entraîner des listes de blocage, un filtrage amont ou des suspensions internes. Les clients avec des charges de travail de courrier 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 les 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: une baie inaccessible, 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 d'attente de tickets qui ne peut pas atteindre l'installation, et un client qui découvre trop tard que partir 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 live, le portail client est live, les pages produits sont spécifiques, la route est visible, le domaine 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 obsolète.
Les preuves publiques ne sont pas suffisamment solides pour une dépendance infrastructurelle de haute confiance sans diligence directe.
Un profil plus fort inclurait une page juridique à jour qui aligne la marque, l'organisation RIPE et le fournisseur contractuel; une déclaration d'installation nommant l'opérateur du centre de données ou expliquant l'arrangement d'hébergement; un SLA avec des conditions de mesure et de crédit; une page de statut ou des archives d'incidents; des objectifs explicites de conservation et de restauration des sauvegardes; une disponibilité IPv6 si offerte; un deuxième amont actif ou une explication écrite de la politique de route de 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 de clients probable devrait être échelonné par risque. Un petit site web bulgare, un serveur de staging, un site WordPress non critique ou un VPS expérimental peut é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 au seul tableau de plan. Il devrait obtenir des réponses écrites sur l'installation, les sauvegardes, la diversité de transit, la contractuelle juridique 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 en tant que vendeur bulgare de capacité hébergée avec AS42347 et une plateforme live Hosting27.com. 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 et bulgare de services d'hébergement et de cloud dont la promesse client dépend encore de baies invisibles, d'un transit visible via Telehouse, d'un stock IPv4 fini, de main-d'œuvre de support, de contrats fournisseurs et de fenêtres de réparation.

