Résumé
- Le site public de Cloud9 le présente comme un fournisseur géorgien d'hébergement, de cloud et de centre de données avec des services incluantcolocation et baies,VPS,VDS,serveurs dédiés,hébergement partagé,messagerie Zimbra, noms de domaine, SSL et services de portail client.
- Les preuves réseau sont significatives.RIPEstat montre AS57814comme annoncé pour le titulaire Cloud9 Cloud 9 Ltd. le 12 juillet 2026, tandis queAS49297est lié au même titulaire mais non annoncé. Les comptages RIPE RIS pour AS57814 montrent28 préfixes IPv4 d'origine, 13 préfixes IPv4 en transit, trois préfixes IPv6 d'origine et deux préfixes IPv6 en transit.
- Le centre de gravité physique est Tbilissi. La pagecentre de donnéesde Cloud9 indique que la plupart de ses services sont fournis depuis son propre centre de données à Tbilissi, etPeeringDB listeune installation Cloud9 Dinamo Arena au 2, avenue A. Tsereteli, Tbilissi, avec une présence d'échange et des contacts de support publics.
- Le risque pour l'acheteur n'est pas que Cloud9 soit invisible. C'est que les preuves publiques ne prouvent toujours pas la capacité de basculement spécifique au client, la disponibilité de matériel de rechange, les performances de restauration des sauvegardes, l'escalade du support ou les droits de sortie. Les clients doivent vérifier ces conditions avant de traiter la capacité hébergée par Cloud9 comme un substitut à leur propre conception de continuité.
L'entreprise est suffisamment visible pour être analysée
Cloud9 Cloud 9 Ltd. mérite une lecture plus concrète que de nombreuses petites entrées d'hébergement car plusieurs archives publiques indépendantes concordent. Le site de l'entreprise utilise la marque Cloud9 pour une activité d'hébergement et de centre de données en Géorgie. Lapage d'accueildécrit Cloud9 comme un fournisseur d'hébergement web professionnel et un opérateur de centre de données expérimenté en Géorgie. Le pied de page indique une adresse opérationnelle au 2, avenue Akaki Tsereteli, stade Dinamo, porte 5, Tbilissi, Géorgie 0112, avec un numéro de téléphone et une adresse e-mail de support. Lesconditions de serviceidentifient « Cloud 9 LLC », ID d'entreprise 405063755, avec une adresse légale à Tbilissi et des adresses e-mail de contact pour les questions contractuelles et de support. Le nom n'est pas parfaitement uniforme sur les surfaces publiques, mais l'adresse, le domaine et les preuves de registre pointent vers le même opérateur d'hébergement géorgien.
Les enregistrements RIR font de cette identité plus qu'une simple affirmation de site web.RIPE RDAP pour AS57814liste l'organisation titulaire comme Cloud 9 Ltd., indique l'adresse au 2, avenue Tsereteli, 0112, Tbilissi, Géorgie, et fournit des contacts publics administratifs, techniques et d'abus.RIPE RDAP pour ORG-CL434-RIPEdonne l'organisation comme Cloud 9 Ltd., la même adresse à Tbilissi, un numéro de téléphone et une adresse e-mail de contact.RIPE RDAP pour AS49297lie un autre système autonome à la même organisation et au même ensemble de contacts.
Cela importe parce que les services visibles de l'entreprise sont des services d'infrastructure. Cloud9 vend de la capacité orientée client: hébergement partagé, serveurs virtuels, serveurs dédiés, colocation, messagerie, noms de domaine, certificats et services de centre de données. Un client qui achète ces services n'achète pas simplement une marque; il dépend de l'espace en baie, de l'alimentation, du routage, du travail de support et des conditions contractuelles. Les preuves publiques sont suffisamment solides pour placer Cloud9 dans cette catégorie.
Elles ne sont pas suffisamment solides pour répondre à toutes les questions de continuité client sans documents contractuels et de conception.
Le cadrage le plus important est donc pratique. Cloud9 est visible en tant que fournisseur d'hébergement et de réseau géorgien opérationnel. Il concentre également une grande partie de l'histoire client autour d'une installation nommée à Tbilissi. Cette combinaison est utile pour le service régional et la localité des données. Cela signifie également qu'un client devrait demander où chaque service fonctionne réellement, comment il échoue, comment il récupère et ce qui se passe si le client doit partir rapidement.
L'enregistrement réseau comporte deux numéros AS, mais un seul est visiblement actif
Le tableau de routage public a un centre propre et une mise en garde importante.L'aperçu AS de RIPEstat pour AS57814montre le titulaire comme Cloud9 Cloud 9 Ltd. et marque l'AS comme annoncé au moment de la requête du 12 juillet 2026.L'aperçu AS de RIPEstat pour AS49297montre la même chaîne de titulaire mais marque cet AS comme non annoncé au même moment.Les données de préfixes annoncés de RIPEstat pour AS57814listent un large ensemble de routes visibles, y compris 185.229.110.0/24, 45.138.44.0/22 et 195.69.140.0/22 entre autres, tandis quele même point de terminaison pour AS49297ne renvoie aucun préfixe annoncé.
Cette distinction doit être préservée. Il serait faux de dire que chaque AS lié à Cloud9 transporte activement du trafic. Il serait également faux de dire que l'entreprise n'a pas de réseau visible. AS57814 est clairement vivant dans la vue de route publique.Les comptages de préfixes RIPE RISmontrent 28 préfixes IPv4 d'origine, 13 préfixes IPv4 en transit, trois préfixes IPv6 d'origine et deux préfixes IPv6 en transit pour AS57814 au moment de la requête du 12 juillet 2026. Ces comptages ne prouvent pas combien de clients sont actifs, à quel point la plateforme est pleine ou quelle capacité de réserve existe, mais ils montrent une surface réseau matériellement plus grande qu'une seule route dormante.
Les exemples de routes montrent également la visibilité actuelle des préfixes.L'aperçu de préfixe RIPEstat pour 185.229.110.0/24indique que le préfixe est annoncé par AS57814 et le relie à 185.229.108.0/22.L'échantillon d'état BGP de RIPEstat pour 185.229.110.0/24a renvoyé des centaines d'observations de routes, avec des chemins atteignant AS57814 via des AS amont ou pairs tels que AS20771 et AS35805 dans l'échantillon.BGP.tools pour AS57814décrit Cloud 9 Ltd. comme un réseau de longue date qui s'interconnecte avec d'autres réseaux et a des opérateurs amont, etBGP.tools pour 185.229.110.0/24montre que ce préfixe est originaire d'AS57814.
L'inférence opérationnelle est équilibrée. Cloud9 n'est pas un revendeur sans emplacement sans réseau. L'entreprise a un AS en direct, une visibilité IPv4 et IPv6, des objets de route et des données de peering publiques. Mais la visibilité des routes n'est pas la même chose qu'une garantie client. Un client doit encore savoir quelles de ses charges de travail se trouvent sur les préfixes propres de Cloud9, lesquelles se trouvent sur des plateformes de fournisseurs, quelles routes transportent les services de sauvegarde, et si un événement de basculement a suffisamment de marge après la charge normale des clients.
Le centre de données est le cœur de l'offre
La pagecentre de donnéesde Cloud9 est inhabituellement directe sur la dépendance physique. Elle indique que la plupart des services fournis par Cloud9 sont livrés depuis son propre centre de données basé à Tbilissi. La page décrit un centre de données neutre vis-à-vis des opérateurs, une surveillance 24/7/365 par des ingénieurs, des contrôles de sécurité, une redondance électrique, une détection et extinction d'incendie, un contrôle climatique et une interconnexion. Elle indique que l'installation est alimentée par trois sous-stations électriques indépendantes et un générateur diesel de secours de 630 kVA; elle indique également que la zone de colocation dispose d'une alimentation électrique redondante N+N avec UPS. Pour la connectivité, Cloud9 indique être connecté aux principaux opérateurs de télécommunications et petits FAI via de la fibre noire réservée avec plusieurs itinéraires alternatifs et 250 Gbps de capacité d'interconnexion totale.
PeeringDB étaye la revendication de l'installation de Tbilissi d'une manière différente.L'enregistrement d'installation PeeringDB pour Cloud9 Dinamo Arenaliste l'installation au 2, avenue A. Tsereteli, Tbilissi, Géorgie 0112, avec Cloud9 LTD comme organisation, une note indiquant que l'entreprise fournit des services de centre de données, d'hébergement, de cloud et de FAI en Géorgie, nombre de réseaux 7, nombre d'échanges 1 et nombre d'opérateurs 1.La relation réseau-installation de PeeringDB pour net_id 20057lie également AS57814 à Cloud9 Dinamo Arena. Ces preuves publiques de PeeringDB ne certifient pas la conception technique, mais elles donnent un ancrage d'installation indépendant qui correspond au modèle d'adresse sur les pages propres de Cloud9.
Le problème clé est la capacité installée par rapport à la capacité utilisable. Une page de centre de données peut nommer des sous-stations, des UPS et un générateur, mais un client doit savoir comment ces actifs se comportent en maintenance et en cas de panne. Combien de baies sont réellement construites et alimentées? Quelle est l'allocation de puissance par baie? Quelle capacité de réserve UPS et générateur reste-t-il après la charge actuelle? Quelle quantité de carburant est contractée pendant une longue panne de service public?
Les chemins d'alimentation sont-ils vraiment indépendants jusqu'à la baie client, ou sont-ils partagés avant un point de défaillance? Comment le démarrage du générateur est-il testé en charge? Les pages publiques ne répondent pas à ces questions au niveau de détail client.
La même distinction s'applique à la connectivité. Une déclaration de 250 Gbps d'interconnexion totale est significative, surtout sur un marché régional, mais ce n'est pas la même chose que la bande passante disponible pour le client pendant une panne. Un client doit savoir si son service utilise un transit partagé, un chemin IXP, une interconnexion privée, une route de FAI local ou un chemin de réseau fédérateur Cloud9; si le chemin de secours sort du même bâtiment; et si des garanties de bande passante survivent à une coupure de fibre ou à une maintenance d'opérateur.
Les pages publiques de Cloud9 donnent suffisamment de confiance pour considérer le centre de données comme réel. Elles ne suppriment pas la nécessité de tester ce qu'un client peut réellement consommer en situation de stress.
L'hébergement est un service de baie avant d'être un service cloud
Le menu de détail de Cloud9 est large. L'entreprise vendhébergement partagé Linux,hébergement partagé Windows,VPS,VDS,serveurs dédiés,messagerie Zimbra,noms de domaine, certificats et colocation. Lesconditions de servicedécrivent les services d'hébergement, l'enregistrement de noms de domaine, la location de serveurs virtuels, la location de serveurs physiques, les services de messagerie, les services de centre de données, la sécurité et la défense DDoS, la planification d'infrastructure de serveurs, les services DevOps et les services cloud. Ce ne sont pas toutes la même dépendance.
L'hébergement partagé dépend des serveurs web, des panneaux de contrôle, du DNS, du stockage et de la politique de support. Le VPS dépend de l'hôte physique, de l'hyperviseur, du stockage, des instantanés et des contrôles de voisin bruyant. Le VDS est annoncé comme un produit de serveur virtuel plus fort, mais il dépend toujours de l'allocation de serveur physique et de la conception du basculement. La location de serveur dédié dépend du matériel appartenant à Cloud9, du stock de remplacement, de l'accès console à distance et de la disponibilité du personnel.
La colocation dépend de l'équipement propre du client, des services de baie de Cloud9 et de la capacité du client à réparer ou autoriser des interventions à distance. La messagerie dépend du fonctionnement du serveur de messagerie, du filtrage anti-spam, du DNS, du stockage, des sauvegardes et des outils de migration.
Les pages produits publiques rendent l'offre de détail lisible, mais elles ne peuvent pas prouver la disponibilité des ressources par elles-mêmes. Un plan VPS peut lister le CPU, la mémoire et le stockage, mais les performances réelles dépendent de la contention, de la disposition du stockage et de la capacité de défaillance. Un serveur dédié peut être disponible à l'achat, mais une carte mère, un disque ou une alimentation défaillante dépendent de l'inventaire de pièces de rechange et de la réactivité du personnel.
Un compte d'hébergement partagé peut être peu coûteux, mais le temps de restauration dépend de la fréquence des sauvegardes, de l'intégrité des sauvegardes et de l'isolation du système de sauvegarde par rapport au serveur défaillant. Un service de nom de domaine ou de messagerie peut être géré via un portail client, mais la récupération du client peut dépendre de la possibilité de déplacer rapidement les exports DNS et de boîtes aux lettres.
C'est pourquoi la capacité hébergée nécessite toujours un audit physique par le client. La question n'est pas simplement de savoir si le service existe. C'est de savoir si le service reste utilisable après la défaillance d'un hôte, d'un commutateur, d'un système de stockage, d'une unité de refroidissement, d'un chemin d'alimentation, d'une interconnexion ou d'un quart de support. Les informations publiques de Cloud9 soutiennent un fournisseur de services réel avec une installation et un réseau. Elles ne publient pas assez de détails pour déduire la survie spécifique au client sous chacun de ces modes de défaillance.
La colocation trace une frontière de propriété claire
Lapage de colocationest l'une des sources publiques les plus précieuses car elle expose la frontière entre la capacité détenue par Cloud9 et l'équipement appartenant au client. Cloud9 vend des options de colocation 1U, 2U et tour, des demi-baies, des baies complètes et des cages personnalisées. Les offres 1U et 2U incluent une double alimentation A/B, une liaison 1 Gb/s et une liaison de gestion; l'offre pour serveur tour liste une alimentation simple, une liaison 1 Gb/s et une liaison de gestion. La page indique que la connectivité 1 Gb/s est illimitée vers les FAI géorgiens et inclut 30 Mb/s de connectivité mondiale par client. Elle indique également que la liaison de gestion est destinée à l'accès IPMI, iLO, iDRAC ou BMC avec une IP interne et un accès VPN sécurisé.
Ces détails sont commercialement utiles et révèlent également les limites. La colocation n'est pas la même chose que l'hébergement dédié géré. La FAQ de Cloud9 indique qu'en colocation, l'équipement est sous la responsabilité du client, tandis que Cloud9 offrira une assistance pour accélérer la correction. Elle indique que Cloud9 dispose d'ingénieurs disponibles 24/7/365 pour les interventions à distance, et que Cloud9 a effectué des migrations à grande échelle, chaque migration dépendant de la charge de travail.
Elle indique également que l'espace et les adresses IP peuvent être prêts en moins de 24 heures après le devis et le paiement initial, tandis que les baies complètes et les cages peuvent prendre plus de temps en raison des pièces et de la main-d'œuvre.
Pour les clients, cette frontière est décisive lors des pannes. Si un serveur colocalisé a une défaillance de disque, d'alimentation ou un problème de micrologiciel, Cloud9 ne peut fournir des interventions à distance que dans le cadre du contrat du client et du stock de pièces de rechange ou du plan de remplacement disponibles. Si le client n'a pas de disques de rechange, de justificatifs de console à distance, de support de démarrage documenté et de cible de migration, la baie peut rester alimentée tandis que l'application reste hors ligne.
Il en va de même pour les changements réseau: une liaison de gestion n'aide que si le client a des droits d'accès, des détails VPN, des justificatifs connus et un chemin de console testé.
La tarification et le langage de bande passante méritent également attention. Une liaison locale 1 Gb/s et 30 Mb/s de connectivité mondiale peuvent suffire pour de nombreuses utilisations d'hébergement géorgiennes, mais ce n'est pas la même chose que la bande passante cloud mondiale. Un client servant des utilisateurs internationaux, des sauvegardes hors site ou des exportations de données volumineuses doit savoir comment le trafic en rafale, la facturation, la congestion et la migration d'urgence se comportent au-delà de l'utilisation mensuelle normale. La page de colocation donne à Cloud9 le crédit de rendre la frontière publique.
Elle donne également aux acheteurs les conditions qu'ils devraient vérifier avant d'y placer du matériel critique.
Le peering et la diversité des routes semblent meilleurs que l'hypothèse la plus faible
L'hypothèse de risque initiale de la mission mettait en garde contre une empreinte publique mince. Les preuves réelles de routage et de peering sont plus solides que cela.L'enregistrement de réseau PeeringDB pour AS57814liste Cloud9 comme un profil de services réseau avec AS57814, site webhttps://www.cloud9.ge/, support IPv6, portée régionale, trafic sortant lourd, trafic auto-déclaré de 200-300 Gbps, une politique de peering général ouverte, une installation et un nombre d'échanges de un. Il liste l'ensemble AS IRR comme AS-SET-CLOUD9. Le profil est auto-maintenu et ne doit pas être considéré comme une capacité auditée, mais c'est un profil d'infrastructure publique, pas une page blanche.
L'entrée netixlan de PeeringDBliste Cloud9 sur IXP.ge avec un port de 10 000 Mb/s, une adresse IPv4 185.1.224.232, un statut de pair de serveur de routes vrai et un statut opérationnel vrai.L'enregistrement IXP.ge de PeeringDBdécrit l'échange comme étant à Tbilissi et Kutaisi, avec Cloud9 Dinamo Arena parmi les entrées d'installation. La pagecentre de donnéesde Cloud9 indique que l'entreprise est également un opérateur de point d'échange Internet et fournit des connexions croisées aux opérateurs. Prises ensemble, ces sources soutiennent un rôle d'interconnexion local significatif.
RIPEstat montre également une cohérence de politique de routage sur un ensemble plus large de préfixes et de pairs.La cohérence de routage AS pour AS57814liste de nombreux préfixes comme présents à la fois dans BGP et dans les données de routage whois, y compris 45.138.44.0/22, 185.229.108.0/24, 185.229.109.0/24, 185.229.110.0/24, 188.93.88.0/24 et 195.69.140.0/22. Elle montre également plusieurs pairs d'import et d'export dans BGP et whois, y compris AS49628, AS20771, AS35805, AS16010 et AS34797, ainsi que d'autres pairs visibles en BGP non présents dans les données whois vérifiées.Les données de longueur de chemin AS de RIPEstatmontrent AS57814 visible depuis de nombreux emplacements de collecte.
Ce n'est pas le profil d'un hébergeur mono-préfixe avec un seul amont observable. Néanmoins, la diversité au niveau du routage doit être traduite en résilience de service. Une route peut avoir plusieurs chemins tandis qu'un service client dépend toujours d'un commutateur de haut de baie, d'une baie de stockage, d'un chemin de distribution électrique ou d'une décision de support.
Un client devrait demander quels fournisseurs sont utilisés pour son service, si les routes sont activement surveillées, si Cloud9 peut déplacer le trafic pendant un événement de maintenance, et si l'accessibilité internationale reste acceptable lorsqu'un pair ou fournisseur de transit est altéré.
L'hygiène de routage est partielle mais visible
La sécurité du routage est un domaine où Cloud9 a des preuves visibles, bien qu'elle doive être évaluée préfixe par préfixe.La validation RPKI de RIPEstat pour AS57814 et 185.229.110.0/24renvoie un statut valide, incluant des ROA validants pour l'origine 57814 couvrant 185.229.110.0/24 et 185.229.108.0/22. Cela importe parce qu'une autorisation d'origine de route valide aide les réseaux à rejeter les annonces provenant d'une mauvaise origine pour ce préfixe. Cela ne résout pas les temps d'arrêt des applications, mais réduit une classe d'erreur de routage ou de détournement.
Le point de terminaisoncohérence de routage ASdonne un autre signe positif en montrant de nombreux préfixes Cloud9 à la fois dans BGP et dans les données de routage whois. L'ensemble AS du profil PeeringDB donne également aux réseaux un objet public à utiliser dans la politique de routage. Ce sont de bons signaux pour un fournisseur régional car de nombreux incidents opérationnels commencent par un filtre de route, un objet périmé, un ROA manquant ou une inadéquation entre ce qu'un fournisseur annonce et ce qu'un amont est prêt à transporter.
La mise en garde est que les preuves ne sont pas une certification universelle. Le lien de validation RPKI ci-dessus valide un préfixe représentatif, pas chaque route. La sortie de cohérence de routage AS montre certaines routes whois non actuellement dans BGP et certains pairs dans BGP mais pas dans la politique whois vérifiée. C'est normal pour de nombreux réseaux, mais cela signifie que les affirmations orientées client doivent être mesurées par rapport au préfixe ou service exact.
Un client utilisant une adresse d'un bloc particulier devrait demander si ce bloc a un ROA valide, un objet de route maintenu, des filtres amont documentés et un contact de surveillance qui peut répondre aux fuites de routes ou à la perte d'accessibilité.
L'hygiène de routage devrait également être liée aux droits de migration. Si le service d'un client utilise des adresses IP fournies par Cloud9, le client doit savoir si ces adresses peuvent se déplacer avec la charge de travail ou si le DNS, les certificats, les listes d'autorisation et la réputation de messagerie doivent être reconstruits ailleurs. Les preuves réseau de Cloud9 sont suffisamment solides pour que les services clients puissent être profondément intégrés à son espace d'adressage. Cela rend une documentation propre plus importante, pas moins.
Les revendications d'alimentation et de refroidissement nécessitent une preuve spécifique au client
Les revendications publiques de centre de données de Cloud9 sont suffisamment détaillées pour être utilisées, mais pas assez pour remplacer les preuves d'ingénierie dans un contrat. La pagecentre de donnéesindique que l'installation est alimentée par trois sous-stations électriques indépendantes et un générateur diesel de 630 kVA. Elle indique que la zone de colocation dispose d'une alimentation électrique redondante N+N et d'un système UPS. Elle décrit une détection précoce de température, de fumée et d'incendie, un système d'extinction d'incendie 3M Novec 1230, un refroidissement DX, un contrôle de température et d'humidité, pas de fenêtres ou de murs donnant sur l'extérieur dans les salles de serveurs et seulement de la plomberie d'extinction d'incendie à proximité. Elle indique également que tous les systèmes clés sont surveillés 24/7/365 par des ingénieurs.
Ce sont les bonnes catégories: alimentation, incendie, refroidissement, sécurité physique et surveillance. La question restante est de savoir si le client reçoit un service redondant après une maintenance ordinaire et des événements de défaillance crédibles. Si un client achète une colocation 1U avec double alimentation A/B, les deux alimentations sont-elles véritablement acheminées vers des chemins d'alimentation amont séparés, ou un composant amont peut-il encore affecter les deux? Si un client achète une colocation tour avec une alimentation simple, le client a-t-il évalué le risque d'une seule alimentation?
Si un client loue un serveur dédié, le contrat inclut-il des délais de remplacement de composants et un chemin de remplacement matériel? Si un serveur virtuel fonctionne sur du matériel Cloud9, quel niveau de défaillance de l'hôte ou du stockage la plateforme peut-elle absorber sans temps d'arrêt?
Le refroidissement a des contraintes cachées similaires. Le refroidissement DX peut être approprié pour l'installation, mais le client doit connaître les limites de densité au niveau de la baie, la conception d'allée chaude/froide, le placement des capteurs et le chemin d'escalade lorsqu'une baie chauffe. Une installation peut avoir une conception de refroidissement redondante tandis qu'une baie client spécifique est toujours contrainte par le flux d'air ou la densité de puissance. L'extinction d'incendie compte également différemment pour la colocation physique et les services virtuels.
Un événement d'extinction d'incendie peut protéger l'équipement de dommages plus graves, mais il peut quand même entraîner des contrôles d'accès d'urgence, des fenêtres d'inspection et des retards de récupération.
Le site public indique que l'installation est de Tier 3 dans le sens où elle peut planifier une maintenance sans interrompre le service. La FAQ de colocation explique le Tier 3 comme le système de classification de l'Uptime Institute et indique que le centre de données de Cloud9 est de Tier 3. Les clients devraient demander si Cloud9 détient une certification tierce actuelle ou utilise le terme pour décrire l'intention de conception. La distinction n'est pas pédante.
Une conception alignée sur les concepts Tier III est utile, mais une installation certifiée, un enregistrement de maintenance audité et une lettre de redondance spécifique au client portent un poids probatoire différent.
Le portail simplifie le service, mais la facturation et l'accès deviennent des dépendances
Lesconditions de servicede Cloud9 sont importantes car elles montrent comment les clients touchent réellement l'infrastructure. Les conditions indiquent qu'un utilisateur s'inscrit sur cloud9.ge et reçoit un compte personnel sur le portail Cloud9 à my.cloud9.ge, où l'utilisateur peut acheter de nouveaux produits, gérer les produits existants, annuler les produits non désirés, contrôler les paiements et ouvrir des tickets de support à tout moment. Les conditions indiquent également que l'utilisateur est responsable du maintien de la confidentialité du compte et des actions entreprises avec le compte.
Cette conception de portail est utile. Elle permet aux clients de gérer l'infrastructure sans attendre une conversation commerciale. Elle fait également de l'accès au compte une dépendance de continuité. Si le compte e-mail autorisé du client est perdu, si les justificatifs sont compromis, si un membre du personnel part, ou si les contacts de facturation ne sont pas mis à jour, la capacité du client à ouvrir des tickets, annuler des services, contrôler les paiements ou apporter des modifications d'urgence peut être altérée.
Les conditions placent la responsabilité sur l'utilisateur de maintenir à jour les personnes de contact, les données d'enregistrement, l'e-mail et les détails téléphoniques. C'est un langage juridique ordinaire, mais cela devient opérationnel lors d'une panne.
La facturation est une autre dépendance du chemin de réparation. Si un problème de facture ou de période de règlement désactive un service, le client peut subir une panne technique dont la cause racine est administrative. Le client devrait savoir comment Cloud9 notifie les contacts du compte, quel préavis s'applique avant suspension ou résiliation, si une restauration d'urgence est disponible après paiement, et quelle personne peut autoriser un changement pendant une crise. Les conditions publiques peuvent décrire le contrat général.
Les clients critiques ont encore besoin d'une gouvernance de compte: propriété partagée du portail, contacts documentés, règles de départ et escalade de support testée.
La conservation et la suppression des données comptent également. Les conditions et le langage de confidentialité de Cloud9 indiquent que les données personnelles et les données de prestation de services peuvent être stockées à des fins légales et de service définies, et que les données peuvent être supprimées ou détruites après la période de conservation pertinente. Les clients devraient faire la distinction entre les données de compte, les journaux, les sauvegardes, les données de boîte aux lettres, les fichiers hébergés et les images de machine virtuelle.
La capacité d'un client à quitter Cloud9 dépend du format d'exportation, du moment de la suppression, de la disponibilité des sauvegardes et de la possibilité pour le client de récupérer les données après annulation.
La leçon pratique est simple: le portail fait partie de l'infrastructure. Les clients devraient le sécuriser comme un accès de production, attribuer plus d'un responsable autorisé, maintenir les données de facturation à jour et vérifier la procédure de support d'urgence avant le premier incident.
La souveraineté des données est un atout seulement si le placement de service est explicite
La revendication de localité la plus forte de Cloud9 est la présence géorgienne. Le site de l'entreprise, les conditions, les enregistrements RIPE et PeeringDB pointent tous vers Tbilissi.RIPE RDAP pour ORG-CL434-RIPEliste Cloud 9 Ltd. à Tbilissi.L'enregistrement d'installation de PeeringDBliste Cloud9 Dinamo Arena à Tbilissi.La géolocalisation RIPEstat pour 185.229.110.0/24place ce préfixe représentatif à Tbilissi au moment du résultat de juillet 2026. La page centre de données de Cloud9 indique que la plupart des services sont fournis depuis le propre centre de données de Cloud9 à Tbilissi.
Pour les clients qui ont besoin d'hébergement géorgien, de support local ou d'un accès à faible latence aux réseaux géorgiens, c'est précieux. De nombreuses entreprises ne veulent pas que chaque charge de travail soit envoyée vers une région hyperscale dans une autre juridiction, surtout lorsque le support client, les demandes réglementaires, la langue et les chemins Internet locaux comptent. Les offres de colocation et de serveurs virtuels de Cloud9 peuvent donc être lues comme un jeu de capacité locale: le client achète de la proximité, une entreprise locale, un accès opérateur local et une installation locale.
Le mot « plupart » compte encore. Les pages publiques de Cloud9 ne prouvent pas que chaque service, copie de sauvegarde, enregistrement de messagerie, fonction de portail, service DNS, service de sécurité ou ensemble de données de support est stocké uniquement en Géorgie. Lapolitique de confidentialitédiscute du traitement des données personnelles et de la prestation de services, mais le texte public ne mappe pas chaque produit à un emplacement de stockage. Lesconditions de servicelistent un large portefeuille de services, y compris les noms de domaine, les certificats, la messagerie, la sécurité, la défense DDoS et les services cloud, dont certains peuvent impliquer des systèmes tiers. C'est normal pour les entreprises d'hébergement, mais cela signifie que la localité des données doit être spécifiée par service.
Un client avec des exigences de souveraineté devrait donc demander à Cloud9 une déclaration de placement de service. Où se trouve la charge de travail principale? Où sont les sauvegardes? Où sont les journaux? Où sont les tickets de support? Quels registres externes, autorités de certification, systèmes de sécurité de messagerie ou processeurs de paiement touchent les données client? Toutes les données peuvent-elles être exportées et supprimées selon un calendrier défini? Si le client a besoin d'un traitement uniquement géorgien, quels produits Cloud9 sont éligibles et lesquels ne le sont pas?
Les preuves publiques de Cloud9 soutiennent Tbilissi comme un fort centre de gravité. Elles ne règlent pas automatiquement toutes les questions de souveraineté des données.
Le DNS et les services de domaine font de Cloud9 une partie du plan de contrôle des clients
Cloud9 vendl'enregistrement de noms de domaine, l'hébergement adjacent au DNS et les services de messagerie, donc son rôle peut aller au-delà du calcul. Le panneau de serveurs de noms du site liste les serveurs de noms cPanel pour Linux, Windows et l'hébergement VPS: ns1.cpanel.ge et ns2.cpanel.ge pour l'hébergement Linux, ns5.cpanel.ge et ns6.cpanel.ge pour l'hébergement Windows, et ns3.cpanel.ge et ns4.cpanel.ge pour l'hébergement VPS. Les observations DNS publiques montrent cloud9.ge utilisant ns1.cpanel.ge et ns2.cpanel.ge comme serveurs de noms faisant autorité, cloud9.ge résolvant vers 188.93.90.171, et son enregistrement MX pointant vers tbs01-mail02.cpanel.ge. Ces noms relient l'offre web de détail, d'hébergement et de messagerie à l'espace de noms de service propre du fournisseur.
C'est important parce que le DNS est un plan de contrôle, pas une décoration. Si un client héberge un site web, un domaine de messagerie ou une application sur Cloud9 et utilise les serveurs de noms gérés par Cloud9, un incident DNS peut affecter la migration, le basculement et la récupération même lorsque le serveur sous-jacent est sain. Inversement, si le client garde le DNS chez un fournisseur indépendant et utilise Cloud9 uniquement pour le calcul ou la colocation, le client peut être en mesure de rediriger le trafic plus rapidement pendant un problème de service Cloud9.
Le bon choix dépend de la tolérance au risque et du niveau de compétence du client.
L'enregistrement de noms de domaine ajoute une autre couche. Un client qui achète des noms de domaine via Cloud9 devrait savoir comment fonctionne l'accès au registre, si le client peut obtenir des codes de transfert rapidement, qui reçoit les avis de renouvellement, si des verrous de domaine sont en place, et ce qui se passe si un problème de facturation coïncide avec le renouvellement. Un domaine peut survivre à n'importe quel fournisseur d'hébergement, mais seulement si le client garde le contrôle des justificatifs, des détails du titulaire et des droits de transfert.
La messagerie augmente encore les enjeux. La messagerie Zimbra peut être pratique pour les entreprises qui veulent un produit de boîte aux lettres hébergée local, mais la récupération de la messagerie dépend du DNS, des sauvegardes de boîtes aux lettres, des formats d'exportation, de la réputation anti-spam, des mots de passe utilisateur et des délais de support. Les clients devraient demander comment les boîtes aux lettres peuvent être exportées, comment les enregistrements DNS sont restaurés, combien de temps les messages supprimés restent récupérables et quel engagement de support s'applique pendant une panne de messagerie.
Les services de domaine et de messagerie de Cloud9 sont des parties légitimes de son offre. Ils font également de Cloud9 un fournisseur de plan de contrôle pour les clients qui pourraient autrement penser qu'ils n'achètent que des serveurs.
Les principaux chemins de défaillance sont ordinaires, pas exotiques
Les chemins de défaillance les plus crédibles de Cloud9 ne sont pas des événements de science-fiction. Ce sont des problèmes d'infrastructure familiers: un problème d'alimentation de baie, un incident de refroidissement, une défaillance matérielle, une fuite de route, une panne d'opérateur amont, un événement DDoS, une suspension de facturation, un problème d'accès au portail, une sauvegarde échouée, un remplacement lent de pièce de rechange, une migration échouée ou une file de support qui grandit plus vite que le personnel ne peut la traiter.
Parce que Cloud9 offre à la fois des services hébergés et de la colocation, l'impact client dépend de ce que le client a acheté.
Pour un client d'hébergement partagé, la défaillance peut être un site web hors ligne, une base de données indisponible, une erreur DNS, un problème de connexion au panneau de contrôle ou un retard de restauration de sauvegarde. Pour un client VPS ou VDS, la défaillance peut être la contention de l'hôte, une défaillance de stockage, la maintenance de l'hyperviseur, une console de gestion inaccessible ou une perte de réseau. Pour un client de serveur dédié, la défaillance peut être un composant physique qui nécessite un inventaire et un remplacement manuel.
Pour un client de colocation, la défaillance peut être du matériel appartenant au client auquel Cloud9 peut aider à accéder mais qu'il ne possède pas. Pour un client de domaine, la défaillance peut être la perte de contrôle sur le nom plutôt que sur le serveur. Pour un client de messagerie, la défaillance peut être l'accès à la boîte aux lettres, le routage DNS, la mise en file d'attente du courrier ou la réputation de spam.
La vue de route suggère que Cloud9 a plus de diversité réseau qu'un petit fournisseur mono-hébergé, mais cela n'élimine pas la concentration de services. Si de nombreux services clients sont à l'intérieur d'une seule installation, un événement au niveau de l'installation peut encore compter même avec plusieurs opérateurs. Si les sauvegardes sont stockées sur le même site, la récupération peut être retardée par le même incident qui met la production hors ligne. Si les tickets de support et l'accès à la facturation dépendent du portail, un problème de compte ou de portail peut compliquer la réparation technique.
Si un client possède du matériel colocalisé mais n'a pas de pièces de rechange locales, l'installation peut fonctionner normalement tandis que la charge de travail du client reste arrêtée.
C'est pourquoi les preuves publiques de Cloud9 devraient être lues comme un point de départ pour la diligence raisonnable, pas comme un substitut. Les clients devraient demander ce qui échoue ensemble. Les serveurs hébergés, le DNS, le portail et les cibles de sauvegarde partagent-ils le même bâtiment? Le service a-t-il un deuxième site? Les instantanés sont-ils stockés en dehors du système de stockage principal? Les changements de route sont-ils testés? Un client peut-il déplacer un domaine, une boîte aux lettres ou une image de serveur pendant un différend ou une urgence?
Chaque réponse réduit l'écart entre « hébergé dans un centre de données » et « récupérable lorsque le centre de données, le réseau ou le chemin de compte est sous stress ».
La migration est le coût caché de la capacité bon marché
La page de colocation de Cloud9 indique que l'entreprise a effectué des migrations à grande échelle et aidera les clients à planifier et exécuter un emménagement dans son centre de données. C'est un signe positif car la compétence de migration compte dans l'hébergement régional. Mais chaque migration a deux côtés: entrer chez le fournisseur et quitter le fournisseur. Les clients négocient souvent soigneusement le premier côté et ignorent le second jusqu'à ce qu'une panne, un changement de prix, une demande de conformité ou une vente d'entreprise force la question.
Le problème de sortie est différent pour chaque service Cloud9. Les clients d'hébergement partagé ont besoin de fichiers de site web, de bases de données, de zones DNS, de comptes de messagerie et de journaux. Les clients VPS ont besoin d'images de VM, d'instantanés ou de constructions de serveur reproductibles. Les clients VDS et serveur dédié ont besoin d'accès au système d'exploitation, de chemins de copie de données, de règles de pare-feu, d'images, de licences et de plans de renumérotation IP.
Les clients de colocation ont besoin d'accès physique, de fenêtres d'expédition, de coordination des interventions à distance, de cartes de câblage et de listes d'équipement. Les clients de domaine ont besoin de codes de transfert et d'enregistrements de titulaire déverrouillés. Les clients de messagerie ont besoin d'exportations de boîtes aux lettres, de changements DNS et de reconfiguration utilisateur. Un client qui utilise plusieurs services à la fois a besoin de toute la carte.
La bande passante peut devenir le facteur limitant. La page de colocation de Cloud9 indique que la connectivité client standard inclut 1 Gb/s illimité vers les FAI géorgiens et 30 Mb/s de connectivité mondiale par client. Cela peut être parfaitement adéquat pour les charges de travail locales normales, mais une exportation en masse vers un autre pays peut se comporter très différemment.
Si un client doit déplacer des téraoctets de machines virtuelles, de sauvegardes ou de boîtes aux lettres, le client devrait savoir si des mises à niveau temporaires de bande passante sont disponibles, combien elles coûtent et si le trafic de migration est en concurrence avec le trafic de production.
L'adressage IP est un autre coût caché. Si les services d'un client sont construits autour d'adresses IP fournies par Cloud9, la migration nécessite des changements DNS, des réémissions de certificats, des mises à jour de liste d'autorisation de pare-feu, une reconstruction de la réputation de messagerie et une communication client. Si le client a des adresses indépendantes du fournisseur ou garde un DNS à durée de vie courte et indépendant, la migration peut être plus facile. La présence réseau de Cloud9 est utile, mais un client ne devrait pas supposer que l'espace d'adressage utilisé aujourd'hui peut voyager avec le service demain.
La posture d'acheteur la plus sûre est de traiter le premier plan de migration et le plan de sortie comme un seul document. Si Cloud9 est le bon fournisseur, il devrait toujours être possible de définir comment le client récupère les données, les domaines, les boîtes aux lettres, les images de serveur et l'équipement sous son propre contrôle.
Ce que les clients devraient vérifier avant de placer des charges de travail critiques
Les preuves publiques soutiennent Cloud9 comme un véritable fournisseur d'infrastructure géorgien. Les questions client sont donc plus avancées que « existe-t-il? » Le premier ensemble concerne l'installation et la capacité. Quelle installation exacte héberge le service? Est-ce Cloud9 Dinamo Arena, une autre salle Cloud9 ou une plateforme tierce? Combien de baies, de chemins d'alimentation, de chemins de refroidissement et de chemins réseau sont impliqués pour le service client spécifique? Quelle est la densité de puissance, l'allocation de bande passante et la capacité de basculement du client?
Y a-t-il un deuxième site, et est-il actif, tiède ou de secours uniquement?
Le deuxième ensemble concerne l'opération réseau. Quels préfixes le service client utilisera-t-il? Sont-ils couverts par des ROA RPKI valides et des objets de route actuels? Quels amonts et pairs transportent le trafic du client? Le client obtient-il une garantie de diversité de route? Que se passe-t-il si IXP.ge, un amont, une route de fibre ou une interconnexion de bâtiment échoue? Comment les fuites de route, les événements DDoS et les problèmes d'accessibilité internationale sont-ils gérés? Quelle visibilité le client peut-il voir pendant un incident?
Le troisième ensemble concerne la récupération de données. À quelle fréquence les sauvegardes sont-elles effectuées? Où sont-elles stockées? Sont-elles immuables ou isolées des justificatifs de production? À quelle fréquence les restaurations sont-elles testées? À quelle vitesse un serveur virtuel complet, une boîte aux lettres ou une base de données peut-il être restauré? Un client peut-il restaurer sans que le portail principal de Cloud9 soit disponible? Les exportations de sauvegarde sont-elles incluses dans le prix, et les exportations d'urgence sont-elles limitées en débit par la bande passante?
Le quatrième ensemble concerne le support et le contrôle. Qui répond en dehors des heures de bureau? Quels problèmes sont couverts par les interventions à distance, et lesquels sont facturables? Quel est le chemin d'escalade du support pour la colocation, le remplacement de serveur dédié, les changements de route, les transferts de domaine et les pannes de messagerie? Combien de contacts autorisés le client peut-il maintenir? Que se passe-t-il si le contact de facturation part? Le client peut-il désigner des contacts d'urgence séparés des contacts de facturation?
Le cinquième ensemble concerne la sortie. Le client peut-il recevoir une liste d'actifs actuelle, un fichier de zone DNS, une exportation de boîte aux lettres, une image de VM, une copie de sauvegarde, un code de transfert de domaine et un enregistrement d'accès sur demande? Quel préavis est requis? Que se passe-t-il pendant un différend? Combien de temps les services supprimés ou annulés sont-ils récupérables? Quelles données sont détruites et quand? Ces questions ne sont pas hostiles. Elles sont les conditions minimales qui transforment un service hébergé en une dépendance responsable.
Conclusion
Cloud9 Cloud 9 Ltd. devrait être lu comme un fournisseur géorgien d'hébergement et de centre de données opérationnel avec des preuves d'infrastructure publique crédibles. Ses propres pages vendent les services pertinents. Les enregistrements RIPE lient Cloud 9 Ltd. à AS57814 et AS49297, et RIPEstat montre AS57814 comme annoncé tandis que AS49297 n'est pas visible dans BGP. AS57814 a une surface de route significative à travers IPv4 et IPv6, avec une visibilité d'origine et de transit. PeeringDB place Cloud9 à Cloud9 Dinamo Arena à Tbilissi et montre une présence IXP.ge.
La page centre de données de Cloud9 donne des revendications d'installation concrètes sur l'alimentation, le refroidissement, l'extinction d'incendie, la surveillance et l'interconnexion opérateur.
C'est suffisant pour aller au-delà de l'interprétation la plus faible. Cloud9 n'est pas simplement un nom dans un répertoire. C'est un fournisseur d'infrastructure local avec une offre centrée sur l'installation, une présence de routage publique et des produits de détail qui peuvent compter pour les entreprises géorgiennes, les développeurs, les organismes publics et les fournisseurs de services régionaux. La proposition de valeur est claire: achetez de la capacité hébergée ou colocalisée proche des réseaux géorgiens, avec un support local et un opérateur de centre de données qui se présente comme neutre vis-à-vis des opérateurs.
Le risque restant est le même risque qui suit chaque fournisseur régional de cloud et d'hébergement. L'étiquette cloud n'efface pas les baies, le transit, l'alimentation, le matériel, le DNS, la facturation, l'accès au compte ou la migration. Les pages publiques ne prouvent pas la capacité de réserve pendant une défaillance de composant, la vitesse de restauration après un incident de sauvegarde, les droits d'exportation client, l'escalade en dehors des heures de bureau ou le basculement propre d'une installation à une autre. Les clients peuvent bien utiliser Cloud9 s'ils documentent ces conditions.
Ils ne devraient pas l'utiliser comme une boîte noire.
Pour les charges de travail critiques, la capacité de Cloud9 devrait être traitée comme réelle mais dépendante du contrat. L'entreprise a suffisamment de preuves d'infrastructure publique pour être prise au sérieux. La sécurité du client dépend de la transformation de ces preuves en réponses spécifiques: où la charge de travail s'exécute, ce qui échoue avec elle, comment les routes survivent, comment les sauvegardes restaurent, qui répare le matériel, qui répond en dehors des heures de bureau, ce qui se passe quand une facture ou un contact de compte tourne mal, et comment le client sort sans perdre de données ou de contrôle.