Cloud9 Cloud 9 Ltd.: capacité hébergée dépendant des baies, transit et réparations

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 qui incluentla colocation et les baies,les VPS,les VDS,les serveurs dédiés,l'hébergement partagé,l'email Zimbra, les domaines, le SSL et les 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 comptes 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. Lapage du centre de donnéesde Cloud9 indique que la plupart de ses services sont fournis depuis son propre centre de données à Tbilissi, etPeeringDB répertorieune installation Cloud9 Dinamo Arena au 2 A. Tsereteli Ave, Tbilissi, avec une présence sur un exchange 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é du 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 considérer 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é géorgienne d'hébergement et de centre de données. Lapage d'accueildécrit Cloud9 comme un fournisseur professionnel d'hébergement web et un opérateur expérimenté de centre de données en Géorgie. Le pied de page mentionne une adresse d'exploitation au 2 Akaki Tsereteli Ave., Dinamo Stadium, Gate 5, Tbilissi, Géorgie 0112, avec un numéro de téléphone et un email de support. Lesconditions de serviceidentifient "Cloud 9 LLC", ID d'entreprise 405063755, avec une adresse légale à Tbilissi et des emails de contact pour les questions contractuelles et de support. La dénomination 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 géorgien d'hébergement.

Les enregistrements RIR rendent cette identité plus qu'une simple affirmation sur le site web.Le RDAP RIPE pour AS57814liste l'organisation enregistrée comme Cloud 9 Ltd., montre l'adresse comme 2 Tsereteli ave, 0112, Tbilissi, Géorgie, et donne des contacts publics administratifs, techniques et d'abus.Le RDAP RIPE pour ORG-CL434-RIPEdonne l'organisation comme Cloud 9 Ltd., la même adresse à Tbilissi, un numéro de téléphone et un email de contact.Le RDAP RIPE pour AS49297lie un autre système autonome à la même organisation et au même ensemble de contacts.

C'est important car 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, email, domaines, certificats et services de centre de données. Un client qui achète ces services n'achète pas seulement une marque; il dépend de l'espace en baie, de l'alimentation, du routage, de la main-d'œuvre 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é des clients sans documents contractuels et de conception.

Le plus important est donc d'être pratique. Cloud9 est visible en tant que fournisseur géorgien opérationnel d'hébergement et de réseau. Il concentre également une grande partie de l'histoire client autour d'une installation nommée à Tbilissi. Cette combinaison est utile pour les services régionaux et la localité des données. Cela signifie aussi qu'un client doit demander où chaque service s'exécute réellement, comment il tombe en panne, comment il se rétablit, et ce qui se passe si le client doit partir rapidement.

Le registre réseau comprend deux numéros AS, mais un seul est visiblement actif

Le tableau de routage public a un centre clair 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é à la date d'interrogation 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é à la même date d'interrogation.Les données de préfixes annoncés de RIPEstat pour AS57814listent un large ensemble de routes visibles, dont 185.229.110.0/24, 45.138.44.0/22 et 195.69.140.0/22 entre autres, tandis quele même endpoint pour AS49297ne retourne aucun préfixe annoncé.

Cette distinction devrait ê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 actif dans la vue de routage publique.Les comptes 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 à la date d'interrogation du 12 juillet 2026. Ces comptes ne prouvent pas combien de clients sont actifs, à quel point la plateforme est pleine, ou combien de capacité de rechange 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 retourné des centaines d'observations de routes, avec des chemins atteignant AS57814 via des AS en 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 établit des peering avec d'autres réseaux et a des transporteurs en 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 réseau. L'entreprise a un AS actif, 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 a toujours besoin de savoir quelles charges de travail reposent sur les propres préfixes de Cloud9, lesquelles reposent sur des plateformes de fournisseurs, quelles routes transportent les services de sauvegarde, et si un événement de basculement dispose d'une marge suffisante après la charge normale des clients.

Le centre de données est au cœur de l'offre

Lapage du centre 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 à Tbilissi. La page décrit un centre de données neutre vis-à-vis des opérateurs, une surveillance 24h/24 et 7j/7 par des ingénieurs, des contrôles de sécurité, une redondance d'alimentation, une détection et suppression 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 redondante N+N avec onduleur. Pour la connectivité, Cloud9 déclare être connecté aux principaux opérateurs de télécommunications et petits opérateurs FAI via des fibres noires réservées avec plusieurs itinéraires alternatifs et une capacité d'interconnexion totale de 250 Gbps.

PeeringDB soutient la revendication de l'installation de Tbilissi d'une manière différente.L'enregistrement d'installation de PeeringDB pour Cloud9 Dinamo Arenaliste l'installation au 2 A. Tsereteli Ave, 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, un nombre net de 7, un nombre d'exchange de 1 et un nombre d'opérateurs de 1.La relation réseau-installation de PeeringDB pour net_id 20057lie également AS57814 à Cloud9 Dinamo Arena. Cette preuve publique PeeringDB ne certifie pas la conception technique, mais elle donne un ancrage d'installation indépendant qui correspond au modèle d'adresse sur les propres pages de Cloud9.

La question clé est la capacité installée par rapport à la capacité utilisable. Une page de centre de données peut nommer des sous-stations, un onduleur et un générateur, mais un client a besoin de savoir comment ces actifs se comportent en maintenance et en panne. Combien de baies sont réellement construites et alimentées? Quelle est l'allocation de puissance par baie? Quelle capacité d'onduleur et de générateur reste après la charge actuelle? Combien de carburant est contracté lors d'une longue panne de réseau électrique?

Les chemins d'alimentation sont-ils vraiment indépendants jusqu'à la baie du 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 en profondeur client.

La même distinction s'applique à la connectivité. Une déclaration d'interconnexion totale de 250 Gbps est significative, surtout dans un marché régional, mais elle n'est pas la même chose que la bande passante disponible pour le client pendant une panne. Un client a besoin de savoir si son service utilise un transit partagé, un chemin d'IXP, une interconnexion privée, une route FAI locale, ou un chemin de backbone 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 le besoin de tester ce qu'un client peut réellement consommer en période de stress.

L'hébergement est un service de baie avant d'être un service cloud

Le menu de vente au détail de Cloud9 est large. L'entreprise vendde l'hébergement partagé Linux,de l'hébergement partagé Windows,des VPS,des VDS,des serveurs dédiés,l'email Zimbra,des domaines, des certificats et de la colocation. Lesconditions de servicedécrivent les services d'hébergement, l'enregistrement de domaine, la location de serveurs virtuels, la location de serveurs physiques, les services email, les services de centre de données, la sécurité et la défense DDoS, la planification d'infrastructure de serveur, les services DevOps et les services cloud. Ce ne sont pas tous 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 snapshots et des contrôles de voisin bruyant. Le VDS est annoncé comme un produit de serveur virtuel plus puissant, mais il dépend toujours de l'allocation du 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 à la console à distance et de la disponibilité du personnel.

La colocation dépend de l'équipement du client, des services de baie de Cloud9 et de la capacité du client à réparer ou autoriser des interventions à distance. L'email 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 compréhensible, mais elles ne peuvent pas prouver la disponibilité des ressources par elles-mêmes. Un plan VPS peut lister CPU, mémoire et stockage, mais la performance réelle dépend de la contention, de la disposition du stockage et de la capacité de panne. Un serveur dédié peut être disponible à l'achat, mais une carte mère, un disque ou une alimentation défaillants dépendent du stock de pièces de rechange et de la réactivité du personnel.

Un compte d'hébergement partagé peut être bon marché, mais le temps de restauration dépend de la fréquence des sauvegardes, de l'intégrité des sauvegardes et du fait que le système de sauvegarde soit isolé du serveur défaillant. Un domaine ou un service email peut être géré via un portail client, mais la récupération du client peut dépendre de la rapidité avec laquelle le DNS et les exportations de boîtes aux lettres peuvent être déplacés.

C'est pourquoi la capacité hébergée a encore besoin d'un audit physique par le client. La question n'est pas simplement de savoir si le service existe. Elle 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 véritable fournisseur de services avec une installation et un réseau. Elles ne publient pas assez de détails pour déduire la survie spécifique au client dans chacun de ces modes de défaillance.

La colocation dessine 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é appartenant à 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 alimentation double A/B, un lien 1 Gb/s et un lien de gestion; l'offre de serveur tour liste une alimentation simple, un lien 1 Gb/s et un lien de gestion. La page indique que la connectivité 1 Gb/s n'est pas mesurée vers les FAI géorgiens et inclut 30 Mb/s de connectivité mondiale par client. Elle indique également que le lien de gestion est pour l'accès IPMI, iLO, iDRAC ou BMC avec IP interne et 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 la responsabilité du client, tandis que Cloud9 offrira une assistance pour accélérer la correction. Elle indique que Cloud9 a des ingénieurs disponibles 24h/24 et 7j/7 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 devis et 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 en colocation a une défaillance de disque, d'alimentation ou de firmware, Cloud9 ne peut fournir des interventions à distance que dans le cadre du contrat du client et des pièces de rechange ou du plan de remplacement disponibles. Si le client n'a pas de disques de rechange, d'identifiants de console à distance, de supports de démarrage documentés 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: un lien de gestion n'est utile que si le client a les droits d'accès, les détails VPN, les identifiants connus et un chemin de console testé.

Le langage de tarification et de bande passante mérite également de l'attention. Un lien local de 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 du crédit à Cloud9 pour avoir rendu la frontière publique.

Elle donne également aux acheteurs les conditions qu'ils doivent vérifier avant de placer du matériel critique là-bas.

Le peering et la diversité des routes sont meilleurs que l'hypothèse la plus faible

L'hypothèse de risque initiale de l'affectation mettait en garde contre une empreinte publique mince. Les preuves réelles de routage et de peering sont plus solides que cela.L'enregistrement 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 important, 200-300 Gbps de trafic auto-déclaré, une politique de peering générale ouverte, une installation et un nombre d'exchange de 1. Il liste l'ensemble IRR comme AS-SET-CLOUD9. Le profil est auto-maintenu et ne doit pas être traité comme une capacité auditée, mais c'est un profil d'infrastructure publique, pas une page vierge.

L'entrée netixlan de PeeringDBliste Cloud9 sur IXP.ge avec un port 10 000 Mb/s, adresse IPv4 185.1.224.232, état pair de routeur serveur vrai et état 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 proprepage du centre de donnéesde Cloud9 indique que l'entreprise est également un opérateur de point d'échange Internet et fournit des interconnexions aux opérateurs. Prises ensemble, ces sources soutiennent un rôle d'interconnexion locale significatif.

RIPEstat montre également une cohérence de politique de route 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, dont 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. Il montre également plusieurs pairs d'import et d'export dans BGP et whois, dont AS49628, AS20771, AS35805, AS16010 et AS34797, ainsi que d'autres pairs visibles 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ôte à un seul 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 alors qu'un service client dépend toujours d'un commutateur de haut de baie, d'un tableau de stockage, d'un chemin de distribution d'alimentation ou d'une décision de support.

Un client doit demander quels fournisseurs sont utilisés pour son service, si les routes sont activement surveillées, si Cloud9 peut déplacer le trafic lors d'un événement de maintenance, et si la joignabilité internationale reste acceptable lorsqu'un pair ou un fournisseur de transit est dégradé.

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'elles doivent être évaluées préfixe par préfixe.La validation RPKI RIPEstat pour AS57814 et 185.229.110.0/24retourne un statut valide, incluant des ROAs de validation pour l'origine 57814 couvrant 185.229.110.0/24 et 185.229.108.0/22. Cela importe car une autorisation d'origine de route valide aide les réseaux à rejeter les annonces de la mauvaise origine pour ce préfixe. Cela ne résout pas les temps d'arrêt des applications, mais cela réduit une classe d'erreur de routage ou de détournement.

Lepoint de terminaison de cohé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 obsolète, 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 la preuve n'est pas une certification universelle. Le lien de validation RPKI ci-dessus valide un préfixe représentatif, pas toutes les routes. La sortie de cohérence de routage AS montre des routes whois qui ne sont pas actuellement dans BGP et des pairs dans BGP qui ne sont pas dans la politique whois vérifiée. C'est normal pour de nombreux réseaux, mais cela signifie que les affirmations destinées aux clients 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 de joignabilité.

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 être déplacées avec la charge de travail ou si le DNS, les certificats, les listes d'autorisation et la réputation du courrier 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 affirmations sur l'alimentation et le refroidissement nécessitent des preuves spécifiques au client

Les affirmations publiques du centre de données de Cloud9 sont suffisamment détaillées pour être utilisées, mais pas suffisamment détaillées pour remplacer les preuves d'ingénierie dans un contrat. Lapage du centre de donnéesindique 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 que la zone de colocation dispose d'une alimentation redondante N+N et d'un système onduleur. Elle décrit une détection précoce de température, fumée et 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 ni de murs donnant sur l'extérieur dans les salles de serveurs, et seulement la plomberie d'extinction d'incendie à proximité. Elle indique également que tous les systèmes clés sont surveillés 24h/24 et 7j/7 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 panne crédibles. Si un client achète une colocation 1U avec une alimentation double A/B, les deux alimentations sont-elles réellement 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 en tour avec une seule alimentation, 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 a besoin de connaître les limites de densité au niveau de la baie, la conception des allées chaudes et froides, le placement des capteurs et le chemin d'escalade lorsqu'une baie devient chaude. Une installation peut avoir une conception de refroidissement redondante tandis qu'une baie client spécifique est encore contrainte par le flux d'air ou la densité de puissance. L'extinction d'incendie est également différente pour la colocation physique et les services virtuels.

Un événement d'extinction d'incendie peut protéger l'équipement contre des dommages plus graves, mais il peut toujours 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 niveau Tier 3 dans le sens où elle peut planifier la maintenance sans interrompre le service. La FAQ sur la 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 niveau 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 ont un poids probant 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 indésirables, 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 effectuées 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 l'adresse email autorisée du client est perdue, si les identifiants 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 entravée.

Les conditions mettent la responsabilité sur l'utilisateur de maintenir les contacts, les données d'enregistrement, l'email et les détails téléphoniques à jour. C'est un langage juridique ordinaire, mais il devient opérationnel lors d'une panne.

La facturation est une autre dépendance de chemin de réparation. Si un problème de facturation ou de période de règlement désactive un service, le client peut subir une panne technique dont la cause première est administrative. Le client doit savoir comment Cloud9 notifie les contacts du compte, combien de préavis s'applique avant une suspension ou une résiliation, si une restauration d'urgence est disponible après paiement, et quelle personne peut autoriser un changement en cas de 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 la politique 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 doivent distinguer 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 machines virtuelles.

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 l'annulation.

La leçon pratique est simple: le portail fait partie de l'infrastructure. Les clients doivent le sécuriser comme un accès de production, désigner plus d'un mainteneur 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 du service est explicite

L'affirmation 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.Le RDAP RIPE 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 à la date du résultat de juillet 2026. La page du centre de données de Cloud9 indique que la plupart des services sont fournis depuis son propre centre de données à Tbilissi.

Pour les clients qui ont besoin d'un hébergement géorgien, d'un support local ou d'un accès à faible latence aux réseaux géorgiens, c'est précieux. De nombreuses entreprises ne souhaitent 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 considérées comme un jeu de capacité locale: le client achète la proximité, une entreprise locale, un accès opérateur local et une installation locale.

Le mot "la plupart" compte encore. Les pages publiques de Cloud9 ne prouvent pas que chaque service, copie de sauvegarde, enregistrement email, 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étraite du traitement des données personnelles et de la prestation de services, mais le texte public ne cartographie pas chaque produit à un emplacement de stockage. Lesconditions de servicelistent un large portefeuille de services, y compris les domaines, certificats, email, sécurité, défense DDoS et 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 ayant des exigences de souveraineté devrait donc demander à Cloud9 une déclaration de placement de service. Où est 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é email ou processeurs de paiement touchent les données du 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 admissibles 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 chaque question de souveraineté des données.

Les services DNS et de domaine font de Cloud9 une partie du plan de contrôle des clients

Cloud9 vendl'enregistrement de domaine, l'hébergement adjacent au DNS et les services email, donc son rôle peut s'étendre au-delà du calcul. Le panneau de serveurs de noms du site liste les serveurs de noms cPanel pour l'hébergement Linux, Windows et 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 que cloud9.ge utilise 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 lient le web de détail, l'hébergement et l'offre email à l'espace de noms de service du fournisseur lui-même.

C'est important car le DNS est un plan de contrôle, pas une décoration. Si un client héberge un site web, un domaine email ou une application sur Cloud9 et utilise des 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. À l'inverse, si le client conserve 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 lors d'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 domaine ajoute une autre couche. Un client qui achète des domaines via Cloud9 devrait savoir comment fonctionne l'accès au registre, si le client peut obtenir rapidement les codes de transfert, 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 un renouvellement. Un domaine peut survivre à n'importe quel fournisseur d'hébergement, mais seulement si le client garde le contrôle des identifiants, des détails du titulaire et des droits de transfert.

L'email augmente encore les enjeux. L'email Zimbra peut être pratique pour les entreprises qui souhaitent un produit de boîte aux lettres hébergée local, mais la récupération du courrier dépend du DNS, des sauvegardes de boîte aux lettres, des formats d'exportation, de la réputation anti-spam, des mots de passe utilisateur et du timing du 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 le courrier supprimé reste récupérable et quel engagement de support s'applique lors d'une panne de courrier.

Les services de domaine et d'email de Cloud9 sont des parties légitimes de son offre. Ils font également de Cloud9 un fournisseur de plan de contrôle pour des clients qui pourraient autrement penser qu'ils achètent seulement 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 panne 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èces de rechange, une migration échouée ou une file d'attente de support qui croît plus vite que le personnel ne peut la traiter.

Parce que Cloud9 propose à la fois des services hébergés et de la colocation, l'impact sur le client dépend de ce que le client a acheté.

Pour un client d'hébergement partagé, la panne 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 panne peut être une contention d'hôte, une panne de stockage, une maintenance d'hyperviseur, une console de gestion injoignable ou une perte réseau. Pour un client de serveur dédié, la panne peut être un composant physique qui nécessite un inventaire et un remplacement en mains propres.

Pour un client de colocation, la panne peut être du matériel appartenant au client auquel Cloud9 peut aider à accéder mais ne possède pas. Pour un client de domaine, la panne peut être une perte de contrôle sur le nom plutôt que sur le serveur. Pour un client email, la panne peut être un accès à la boîte aux lettres, un routage DNS, une mise en file d'attente du courrier ou une réputation de spam.

La vue des routes suggère que Cloud9 a plus de diversité réseau qu'un petit fournisseur mono-hébergé, mais cela n'élimine pas la concentration des services. Si de nombreux services clients sont dans 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 en colocation mais n'a pas de pièces de rechange locales, l'installation peut fonctionner normalement tandis que la charge de travail du client reste en panne.

C'est pourquoi les preuves publiques de Cloud9 doivent être considérées comme un point de départ pour la diligence raisonnable, pas comme un substitut. Les clients devraient demander ce qui tombe en panne 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 snapshots 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 en cas de litige ou d'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 déménagement vers son centre de données. C'est un signe positif car la compétence en matière de migration compte dans l'hébergement régional. Mais chaque migration a deux faces: entrer chez le fournisseur et le quitter. 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 email et de journaux. Les clients VPS ont besoin d'images de VM, de snapshots ou de builds 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 à 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 email 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 la carte complète.

La bande passante peut devenir le facteur limitant. La page de colocation de Cloud9 indique que la connectivité client standard inclut 1 Gb/s non mesuré vers les FAI géorgiens et 30 Mb/s de connectivité mondiale par client. Cela peut être parfaitement adéquat pour des 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 doit savoir si des mises à niveau temporaires de bande passante sont disponibles, combien elles coûtent et si le trafic de migration entre 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 listes d'autorisation de pare-feu, une reconstruction de réputation de courrier et une communication client. Si le client a des adresses indépendantes du fournisseur ou maintient un DNS à courte durée de vie 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 encore être possible de définir comment le client récupère ses données, domaines, boîtes aux lettres, images de serveur et é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 en tant que véritable fournisseur d'infrastructure géorgien. Les questions des clients sont donc plus avancées que "existe-t-il?" La première série 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, d'alimentations, 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, chaud ou réservé aux sauvegardes?

La deuxième série concerne l'exploitation réseau. Quels préfixes le service du client utilisera-t-il? Sont-ils couverts par des ROAs RPKI valides et des objets de route à jour? 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 un point de remise de bâtiment tombe en panne? Comment les fuites de routes, les événements DDoS et les problèmes de joignabilité internationale sont-ils traités? Quelle visibilité le client peut-il avoir lors d'un incident?

La troisième série concerne la récupération des données. À quelle fréquence les sauvegardes sont-elles effectuées? Où sont-elles stockées? Sont-elles immuables ou isolées des identifiants de production? À quelle fréquence les restaurations sont-elles testées? Combien de temps faut-il pour restaurer un serveur virtuel complet, une boîte aux lettres ou une base de données? 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 par la bande passante?

La quatrième série concerne le support et le contrôle. Qui répond en dehors des heures d'ouverture? 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 courrier? 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?

La cinquième série 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? Combien de préavis est requis? Que se passe-t-il en cas de litige? Pendant 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. Ce sont les conditions minimales qui transforment un service hébergé en une dépendance responsable.

En résumé

Cloud9 Cloud 9 Ltd. doit être considéré comme un fournisseur géorgien opérationnel d'hébergement et de centre de données 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 qu'AS49297 n'est pas visible dans BGP. AS57814 a une surface de route significative en IPv4 et IPv6, avec une visibilité d'origine et de transit. PeeringDB place Cloud9 à Cloud9 Dinamo Arena à Tbilissi et montre une présence sur IXP.ge.

La page du centre de données de Cloud9 donne des affirmations 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 seulement 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 en colocation 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 rechange lors d'une panne de composant, la vitesse de restauration après un incident de sauvegarde, les droits d'exportation du client, l'escalade après les heures ou le basculement propre d'une installation à une autre. Les clients peuvent utiliser Cloud9 correctement 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 doit ê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 tombe en panne avec elle, comment les routes survivent, comment les sauvegardes se restaurent, qui répare le matériel, qui répond après les heures, ce qui se passe lorsqu'une facture ou un contact de compte tourne mal, et comment le client sort sans perdre de données ou de contrôle.