THANH CLOUD COMPANY LIMITED vend une capacité hébergée qui dépend encore des racks, du transit et des fenêtres de réparation

Résumé

• Le meilleur élément de preuve opérationnelle est l'AS153005, enregistré par l'APNIC commePTCLOUD-VNpour Phu Thanh Cloud Company Limited. Cet AS annonçait visiblement un bloc IPv4,160.187.156.0/23, le 12 juillet 2026. Cela établit une surface de routage active, pas une plateforme cloud vérifiée ni une correspondance entre toutes les versions du nom de la société.
• Le réseau visible est petit et concentré. Il dispose de 512 adresses IPv4, aucune annonce IPv6 observée, un seul transit amont observé via Proxel Innovations, aucun profil PeeringDB public et aucun emplacement de centre de données ou point d'échange Internet divulgué. Une autorisation de route valide améliore l'hygiène du routage mais ne crée pas de redondance physique.
• Le domaine de l'entreprise reste délégué et peut recevoir des e-mails, mais son apex ne publiait aucune adresse web à la date du rapport. Les documents publics n'identifient pas de catalogue VPS actuel, d'hyperviseur, de conception de stockage, de nombre de baies, de propriétaire d'installation, de topologie électrique, de stock de matériel de rechange, d'engagement de service ou d'objectif de reprise.
• Les clients doivent donc considérer la disponibilité du service, la localisation des données au Vietnam et la reprise multi-site comme non vérifiées jusqu'à ce que l'entreprise contractante fournisse des preuves au niveau des installations, des schémas de routage et de transport, des résultats de restauration testés, des conditions d'escalade du support et un chemin d'exportation pratique.
• Les preuves soutiennent une évaluation opérationnelle faible: il existe une piste juridique et réseau réelle et un préfixe récemment actif, mais trop peu de preuves publiques pour traduire cette piste en capacité de calcul installée, en capacité client utilisable ou en service récupérable.

Le mot manquant dans le nom est le premier problème d'infrastructure

L'entité en titre est THANH CLOUD COMPANY LIMITED. Le réseau qui lui est rattaché est l'AS153005. Pourtant, l'enregistrement APNIC pour l'AS153005 n'utilise pas ce nom abrégé. Il identifiePTCLOUD-VNcomme PHU THANH CLOUD COMPANY LIMITED, donne une adresse au quatrième étage sur Vuong Thua Vu à Hanoi et nomme des contacts administratifs et techniques utilisant le domaineptcloud.vn. L'enregistrement APNIC pour son bloc IPv4 répète le nom et l'adresse Phu Thanh.

Les services d'information sur les entreprises vietnamiennes vont dans le même sens. La page de la société Infocom identifie Cong Ty TNHH Phu Thanh Cloud, code fiscal 0110062087, comme une société à responsabilité limitée unipersonnelle créée en juillet 2022. Elle indique PT Cloud comme nom abrégé et le traitement de données, l'hébergement et les activités connexes comme ligne d'activité principale enregistrée. VNBIS rapporte le nom légal anglais Phu Thanh Cloud Company Limited et la même adresse à Hanoi.

Il s'agit de présentations secondaires des données de l'entreprise plutôt que d'un substitut à un certificat à jour, mais leur concordance avec l'APNIC est significative.

Ces éléments font de Phu Thanh Cloud l'identité juridique la plus plausible derrière l'AS153005. Cela ne permet pas au lecteur d'effacer la différence entre ce nom et THANH CLOUD COMPANY LIMITED. Un mot manquant peut provenir d'une troncature, d'un alias, d'une traduction, d'un nettoyage de données ou d'une entreprise véritablement différente. Les documents publics examinés ici ne contiennent aucun dépôt d'entreprise indiquant que le nom abrégé est un alias juridique formel. Ils ne montrent pas non plus de transfert, de structure mère-filiale ou de licence de nom commercial qui expliquerait la variation.

Pour un client d'hébergement, ce n'est pas un détail administratif. L'entité juridique figurant sur le bon de commande détermine qui doit un remboursement, qui contrôle les données du client, qui peut autoriser les ingénieurs à entrer dans une installation et qui reste responsable si un contrat de transport ou de colocation prend fin. Le détenteur de ressources dans l'APNIC détermine qui est responsable de l'enregistrement de la route. La marque sur un site web ou une facture peut être une couche supplémentaire. Si ces noms diffèrent, le contrat doit les relier explicitement.

La conclusion juste est étroite. L'AS153005 est une preuve faisant autorité concernant un réseau enregistré au nom de Phu Thanh Cloud Company Limited. C'est le seul point d'ancrage technique solide actuellement associé à l'entité en titre. L'association est suffisamment crédible pour être examinée, mais pas assez forte pour considérer que toute affirmation concernant un nom est automatiquement prouvée pour l'autre. Tout achat sérieux devrait commencer par le certificat d'entreprise vietnamien en cours, l'identité fiscale, le bénéficiaire du compte bancaire, le contrat de service et une explication signée des noms PT Cloud et THANH CLOUD.

Ce qui peut être prouvé comme existant

Le dossier public soutient quatre propositions concrètes.

Premièrement, une société vietnamienne appelée Phu Thanh Cloud Company Limited possède une empreinte juridique cohérente. Les pages d'information sur l'entreprise s'accordent sur sa création en 2022, son adresse à Hanoi, son représentant et son activité principale. Une activité enregistrée est une permission ou une classification générale; ce n'est pas la preuve que chaque produit d'hébergement possible est actuellement vendu. Néanmoins, c'est plus pertinent qu'un simple nom car le traitement de données et l'hébergement sont centraux plutôt qu'accessoires dans l'activité enregistrée.

Deuxièmement, l'APNIC a attribué l'AS153005 et160.187.156.0/23à la société en octobre 2024. Le bloc est un espace d'adressage portable, pas seulement quelques adresses empruntées de manière invisible à un autre fournisseur. Les enregistrements d'ASN et de préfixe utilisent la même description d'organisation, la même adresse et les mêmes contacts. Cet alignement rend l'identité réseau nettement plus solide qu'une page de médias sociaux non vérifiée ou une étiquette cloud générique.

Troisièmement, le réseau était actif à la date de l'article. L'aperçu de l'ASN par RIPEstat a rapporté l'AS153005 comme annoncé le 12 juillet 2026. Son historique des préfixes annoncés a vu160.187.156.0/23du 28 juin au 12 juillet. La vue actuelle de BGP.tools montrait également le préfixe dans la table globale. Cela importe car des instantanés tiers plus anciens décrivaient encore l'ASN comme inactif. La différence s'explique le mieux par le moment: la route est apparue après la collecte de ces instantanés.

Quatrièmement, la route était couverte par une autorisation d'origine de route valide. Le résultat de validation RIPEstat indique que l'AS153005 est autorisé à émettre le/23, les annonces plus spécifiques étant autorisées jusqu'au/24. C'est une bonne hygiène de routage. Cela réduit le risque que les réseaux appliquant la validation d'origine de route rejettent l'annonce légitime et facilite le filtrage de certaines formes d'utilisation abusive accidentelle ou malveillante de l'origine.

Ces propositions établissent une organisation, des ressources numériques et une route active. Elles n'identifient pas de salle de données, ne prouvent pas qu'un cluster d'hyperviseurs fonctionne, ne montrent pas que les clients occupent les adresses et ne démontrent pas que la route est restée disponible pendant une période de service significative. La route publique était visible depuis environ deux semaines à la fin de la fenêtre d'observation. Une nouvelle annonce peut être un lancement de production, une migration, un test de connectivité, un arrangement de location d'adresses ou une étape intermédiaire.

Sans preuves de service et d'installation, son objectif reste ouvert.

Un bloc routé n'est pas un cloud

Le/23de l'AS153005 contient 512 adresses IPv4. C'est une ressource réseau utile, mais c'est une mauvaise unité pour mesurer la capacité cloud. Un serveur physique peut héberger de nombreuses machines virtuelles avec des adresses publiques. De nombreuses machines virtuelles peuvent se trouver derrière une adresse partagée. Des adresses peuvent être réservées, filtrées, attribuées à des équipements réseau, réservées pour de futurs clients ou routées sans aucune charge de travail client derrière elles. Inversement, un cloud privé important peut n'exposer qu'une petite plage publique.

La définition standard est utile ici. Le NIST SP 800-145 décrit le cloud computing par le libre-service à la demande, l'accès réseau étendu, la mutualisation des ressources, l'élasticité rapide et la mesure du service. Il distingue également les modèles de service d'infrastructure, de plateforme et de logiciel. Aucune de ces caractéristiques ne peut être déduite d'un ASN. Une route soutient l'accès réseau étendu; elle ne dit rien en elle-même sur le provisionnement automatisé, le comptage, l'isolation des locataires ou les pools de ressources élastiques.

Les documents publics ne permettent pas d'établir si PT Cloud propose des serveurs privés virtuels, du bare metal, de l'hébergement mutualisé, des applications gérées, du transit d'adresses, des bureaux distants, une capacité de proxy ou un autre service. Ils ne montrent pas de page de commande, de spécification de produit, d'engagement de service actuel ou de portail client. Le domaineptcloud.vnest délégué aux serveurs de noms Cloudflare et possède des échangeurs de courrier Google, ce qui montre que le domaine reste configuré pour les communications. Mais la réponse d'enregistrement A public et la réponse AAAA n'ont retourné aucune adresse pour l'apex à la date du rapport. Aucune adressewwwn'était visible non plus.

Cela ne prouve pas que l'entreprise a cessé ses activités. Une entreprise peut vendre par contacts directs, utiliser une autre marque, maintenir un site web temporairement hors ligne ou exécuter sa console de service sur un nom d'hôte non divulgué. La route active pointe dans la direction opposée à une simple théorie de fermeture. La conclusion correcte est qu'un lecteur ne peut pas inspecter indépendamment un catalogue public actuel ou des conditions clients sur le domaine d'entreprise évident.

La distinction importe car chaque service a une carte de dépendances différente. Une offre VPS dépend de nœuds de calcul, de stockage, de réseau virtuel, de gestion d'adresses et d'un système de contrôle. Le bare metal ajoute un inventaire physique et un remplacement manuel. L'hébergement mutualisé ajoute des dépendances web, courrier, base de données et panneau de contrôle. Le service géré ajoute des ingénieurs et des licences logicielles. Le transit ou le service d'adresses peut reposer davantage sur des contrats de routage que sur le calcul. Avant de juger la capacité ou la défaillance, le produit doit être nommé.

L'adresse de Hanoi est un bureau, pas un centre de données démontré

L'adresse au quatrième étage dans le district de Thanh Xuan est cohérente dans les registres de l'entreprise et du réseau. C'est une preuve d'un emplacement administratif. Rien dans ces registres ne dit qu'elle contient une salle de données de production, une alimentation soutenue par générateur, un refroidissement de précision, une extinction d'incendie, un accès de chargement sécurisé ou des entrées pour opérateurs télécoms. Traiter une adresse de bureau comme l'emplacement du serveur transformerait un champ de contact en une affirmation physique qu'il ne fait pas.

Cela laisse trois grandes possibilités. L'entreprise peut louer de l'espace en baie dans un centre de données vietnamien, revendre l'infrastructure exploitée par un autre fournisseur, ou placer l'équipement hors du Vietnam tout en conservant une société et un ASN vietnamiens. Elle peut aussi utiliser plusieurs de ces arrangements. Les preuves publiques ne permettent pas de choisir parmi eux.

Le Vietnam a un marché des centres de données concentré. Un rapport du Ministère de l'Information et de la Communication indiquait que Viettel, VNPT, FPT et CMC représentaient environ 97 % du marché intérieur en 2024. Cette concentration fait de l'infrastructure louée une voie pratique pour les petits fournisseurs: ils peuvent acheter des baies, de l'énergie et de la connectivité plutôt que de financer un bâtiment complet. Cela ne montre pas que Phu Thanh utilise l'une de ces quatre sociétés, et aucune ne doit être considérée comme son fournisseur sans contrat, bon de commande d'interconnexion ou confirmation d'installation.

La question de l'installation doit être répondue au niveau du bâtiment. Une divulgation utile identifierait la ville et l'opérateur, si l'entreprise possède ou loue la baie, l'allocation constante de puissance par armoire, les chemins d'alimentation A et B, les dispositions de générateur et de carburant, la conception du refroidissement, la zone d'incendie, les règles d'accès physique et les entrées des opérateurs télécoms. S'il y a un second site, il devrait identifier quels services y sont réellement exécutés et s'il partage l'alimentation, la fibre métropolitaine ou les systèmes de gestion avec le premier.

Les normes d'installation devraient également être précises. L'explication des niveaux de l'Uptime Institute distingue la capacité de base, les composants redondants, la maintenabilité simultanée et la tolérance aux pannes. Un vendeur disant que ses serveurs se trouvent dans un bâtiment « Tier III » n'est pas la même chose que montrer une certification actuelle pour le site exact, et même une installation certifiée ne rend pas automatiquement la baie, le réseau ou le logiciel du locataire maintenables simultanément.

Des serveurs à cordon unique, un seul commutateur haut de baie ou un seul contrôleur de stockage peuvent réintroduire un point de défaillance à l'intérieur d'un bâtiment résilient.

Aucune certification de site publique, photographie de baie, contrat d'installation ou relation nommée avec un centre de données n'a été trouvée pour l'entreprise. L'emplacement physique de la capacité client reste donc non vérifié.

Capacité installée et capacité utilisable sont des chiffres différents

Même si un inventaire de baies apparaissait demain, le chiffre pertinent pour le client ne serait pas le nombre de serveurs. Le matériel installé ne devient une capacité cloud utilisable qu'après déduction des réserves pour pannes, maintenance, réplication, sursouscription et croissance.

Prenons un petit cluster avec plusieurs nœuds de calcul. Une partie du CPU et de la mémoire doit rester disponible pour que les machines virtuelles puissent redémarrer lorsqu'un nœud est retiré. Le stockage peut conserver deux ou trois copies des données. Les instantanés consomment de l'espace et de la capacité d'entrée-sortie. Les liaisons réseau ont besoin de marge pour les attaques, les sauvegardes et la migration. Un fournisseur qui alloue chaque cœur visible ou chaque téraoctet nominal ne dispose d'aucune marge pour absorber une défaillance.

Le même nombre de serveurs peut donc supporter un service robuste ou un service fragile selon la politique de réserve.

Rien de public n'indique le nombre ou la génération des serveurs de PT Cloud, l'inventaire des processeurs et de la mémoire, le support de stockage, le facteur de réplication, l'hyperviseur, le ratio de sursouscription, l'engagement de bande passante, la rétention des sauvegardes ou la capacité de réserve. Il n'y a aucune preuve de la partie du/23qui est attribuée. Un client ne peut pas calculer la capacité de calcul installée, vendable ou récupérable à partir de 512 adresses.

L'âge du matériel change également l'équation. Un catalogue peut annoncer un CPU virtuel sans dire si les processeurs sous-jacents sont uniformes. Des générations mixtes compliquent la migration à chaud et la planification de capacité. Les performances de stockage peuvent chuter à mesure que les baies se remplissent. L'usure de la flash, les disques défaillants et le trafic de reconstruction peuvent réduire l'entrée-sortie utilisable bien avant que les téraoctets nominaux ne soient épuisés. Le micrologiciel et les licences logicielles peuvent limiter la machine de rechange qui est réellement déployable.

Les preuves nécessaires sont opérationnelles plutôt que promotionnelles: un inventaire daté par site, les plages d'utilisation actuelles, la réserve de défaillance, la réplication du stockage, la séparation des sauvegardes, les engagements réseau et la quantité de capacité restante après la perte du plus grand nœud ou de la plus grande baie. Ces chiffres peuvent être partagés confidentiellement avec les clients. Leur absence du web ouvert est compréhensible pour une petite entreprise privée; leur absence d'un approvisionnement sérieux ne le serait pas.

La route visible a une chaîne amont observée unique

L'observation actuelle de la route donne la vue la plus claire de la dépendance externe. BGP.tools montrait l'AS153005 connecté à l'AS401561, Proxel Innovations LLC, pour l'IPv4. Il ne montrait pas de second amont ou de chemin IPv6. L'enregistrement de l'AS401561 à son tour montrait Hurricane Electric AS6939 comme son amont. Une autre vue d'annuaire réseau plaçait également l'AS153005 parmi les clients de Proxel.

Cela ne signifie pas que les paquets voyagent physiquement de Hanoi au Missouri et retour. Le pays d'enregistrement d'un ASN n'est pas une carte des câbles, et une relation commerciale peut être délivrée via un peering distant, des tunnels, des installations tierces ou un autre fournisseur de transport. Cela ne prouve pas non plus que Proxel soit le seul contrat: des liaisons privées, des sessions de secours et des routes invisibles à l'ensemble d'observation peuvent exister.

Ce que cela montre, c'est que la table globale exposait une sortie logique unique pour le préfixe le 12 juillet. Si cette session BGP est retirée, si Proxel cesse de porter la route, ou si une erreur de configuration retire l'AS153005 du chemin accepté, le/23peut devenir injoignable même si tous les serveurs restent sous tension. Si le propre chemin de l'AS401561 vers Hurricane Electric échoue et qu'aucune alternative n'est disponible, le même résultat peut se produire un niveau plus haut.

L'autorisation valide de la route aide à la validation d'origine mais pas à la diversité des chemins. RPKI dit que l'AS153005 peut émettre le préfixe. Il ne promet pas que la session est active, qu'un second opérateur existe, que les câbles empruntent des entrées différentes ou que le trafic est protégé contre la congestion et les attaques par déni de service distribué. La sécurité de l'annonce et la disponibilité du service sont des propriétés distinctes.

Il n'y a pas non plus d'entrée réseau PeeringDB publique pour l'AS153005. Cela signifie qu'aucun niveau de trafic, politique de peering, port d'échange, liste d'installations ou contact opérationnel divulgué volontairement ne peut être vérifié là-bas. De nombreux petits réseaux n'utilisent pas PeeringDB, donc le résultat vide est un manque de divulgation plutôt qu'une preuve d'isolement. Dans un marché avec un échange national et de nombreux réseaux domestiques, cependant, l'absence rend impossible de confirmer un peering local ou un second chemin à partir de cette source.

L'Internet plus large du Vietnam est en expansion active. Les aperçus des ressources Internet de VNNIC comptent des centaines de systèmes autonomes et suivent le déploiement IPv6 du pays, tandis que la stratégie d'infrastructure numérique du gouvernement appelle à de nouvelles routes de câbles internationaux et des centres de données plus écologiques. Le progrès national ne diversifie pas automatiquement un petit ASN. Les propres sessions opérateur, chemins physiques et plan IPv6 de PT Cloud doivent encore être montrés.

Défaillance de baie: la plus petite panne physique peut avoir l'effet le plus large

Une baie est un domaine de défaillance partagé. Des serveurs qui semblent indépendants dans un panneau de contrôle peuvent utiliser la même unité de distribution d'énergie, le même commutateur haut de baie, le même cordon de brassage fibre, le même commutateur de gestion et le même allée de refroidissement. Si le fournisseur place le calcul, le stockage et la sauvegarde dans une seule armoire, un seul déclenchement de disjoncteur ou une panne de commutateur peut supprimer les trois.

La première question de résilience n'est donc pas combien de machines virtuelles la plateforme peut créer. C'est de savoir si une charge de travail client, ses réplicas de stockage et les systèmes nécessaires à sa récupération franchissent une véritable frontière d'alimentation et de réseau. Deux copies de stockage dans le même châssis protègent contre une panne de disque mais pas contre une panne de châssis. Deux hôtes sur la même multiprise protègent contre une carte mère mais pas la multiprise. Un serveur de sauvegarde dans la baie voisine peut encore partager la même salle électrique et la même installation.

Les preuves publiques ne fournissent aucune disposition des baies. Elles ne donnent pas non plus de politique de maintenance. Les travaux planifiés peuvent exposer une conception qui semble redondante dans des conditions normales: un chemin d'alimentation est déjà hors service pour maintenance lorsque l'autre tombe en panne, ou un commutateur est en cours de mise à niveau lorsqu'un changement de routage tourne mal. La maintenabilité simultanée doit inclure l'équipement du locataire et la procédure d'exploitation, pas seulement le bâtiment du propriétaire.

Les clients affectés par une panne de baie varieraient selon le produit. Une machine virtuelle avec stockage répliqué pourrait redémarrer ailleurs après une pause. Un seul serveur bare metal reste en panne jusqu'à réparation. L'hébergement mutualisé peut mettre hors ligne des centaines de sites en même temps. Un panneau de contrôle peut être indisponible pendant que les charges de travail existantes continuent, laissant les clients incapables de les redémarrer ou de les modifier. Le fournisseur devrait énoncer ces modes séparément plutôt que de les réduire à un seul pourcentage de disponibilité.

Panne d'alimentation et de refroidissement: le bail transfère le contrôle, pas les conséquences

Si PT Cloud loue de l'espace, il achète de l'électricité et du refroidissement à un exploitant d'installation. Cela peut être efficace, mais cela divise la responsabilité. Le propriétaire contrôle les alimentations électriques, l'appareillage de commutation, les générateurs, le carburant, les refroidisseurs et la sécurité physique. Le locataire contrôle la charge de son armoire, son câblage et ses serveurs. Un client contracte avec le fournisseur cloud et peut ne jamais avoir de réclamation directe contre le bâtiment.

Cette frontière devient importante lors d'une longue panne. L'autonomie du générateur dépend de la charge, du stock de carburant et du réapprovisionnement. Le refroidissement peut devenir le système limitant même lorsque l'alimentation reste disponible. Une baie qui dépasse sa densité contractuelle peut créer une chaleur localisée ou déclencher une protection. Une installation peut remplir son obligation tandis que l'unité de distribution d'énergie unique du locataire tombe en panne.

Aucune preuve publique n'identifie l'engagement de niveau d'installation de PT Cloud ni si une compensation du propriétaire est répercutée sur les clients. Il n'y a pas de période de préavis de maintenance publiée, de procédure d'incident électrique ou de densité maximale de baie. Un acheteur ne devrait pas supposer que l'engagement d'un bâtiment et un engagement cloud sont identiques.

L'incitation économique peut fonctionner dans les deux sens. La location permet à un petit fournisseur d'obtenir une installation professionnelle sans posséder de générateurs et de refroidisseurs. Elle crée également des obligations mensuelles fixes. Si une facture de colocation est contestée ou qu'un contrat prend fin, le problème technique devient l'accès: qui peut entrer, qui possède les serveurs, à quelle vitesse l'équipement peut-il être retiré, et où peut-il aller? Une défaillance de contrat fournisseur peut donc ressembler à une panne matérielle pour les clients même quand aucun équipement n'est cassé.

Défaillance de route: des serveurs sous tension peuvent encore disparaître

La conception de routage visible est le risque de concentration le plus immédiat car un seul amont est observable. Une erreur de configuration à l'une ou l'autre extrémité de la relation AS153005-AS401561 pourrait retirer le/23. Des changements de filtrage pourraient le rejeter. Une coupure de fibre pourrait isoler la session délivrée. La congestion ou le trafic d'attaque pourrait laisser la route présente mais le service inutilisable.

Différentes atténuations traitent différentes défaillances. Une seconde session BGP sur la même interconnexion protège contre un routeur, pas contre un chemin de câbles. Un second opérateur délivré par le même chemin métropolitain protège davantage contre une erreur de configuration opérateur que contre une coupure de génie civil. Un tunnel distant peut restaurer la joignabilité mais peut ajouter de la latence et dépendre du réseau d'accès local qu'il est censé remplacer. La diversité réelle nécessite des preuves logiques et physiques.

L'absence d'annonce IPv6 est une autre contrainte. Elle ne rend pas le service IPv4 non opérationnel, et de nombreux clients peuvent fonctionner entièrement en IPv4. Elle signifie que le réseau public n'a pas de seconde famille de protocoles visible par laquelle les clients IPv6 natifs pourraient atteindre les charges de travail. L'ajout d'IPv6 améliorerait la portée du protocole mais ne compterait pas comme une diversité d'opérateur s'il suit le même routeur, la même fibre et le même amont.

Les clients devraient demander les deux ASN amont, les tailles de port, les installations, les types de remise, les propriétaires de dernier kilomètre et si les routes utilisent des entrées séparées. Ils devraient également demander ce qu'il advient des adresses des clients pendant le basculement. Un fournisseur peut avoir un transit de secours mais être incapable d'annoncer le préfixe depuis celui-ci car les filtres, les lettres d'autorisation ou les objets de route n'étaient pas préparés. Une conception de reprise existe seulement lorsque la route a été testée.

Défaillance du stock de matériel: une promesse de remplacement nécessite un inventaire

Le bare metal et les petits clusters ont une file d'attente physique derrière eux. Un disque, une alimentation, un ventilateur, un module de mémoire ou une carte mère défaillant doit être diagnostiqué, accessible et remplacé. Le temps de récupération dépend du stock de pièces de rechange, du micrologiciel compatible, de l'intervention à distance et des autorisations de déplacement, pas seulement d'une alerte.

Les activités enregistrées de l'entreprise incluent le commerce d'équipements informatiques et de télécommunications et la réparation d'ordinateurs en plus de l'hébergement. Cette combinaison est compatible avec une entreprise capable de s'approvisionner et de maintenir du matériel. Ce n'est pas une preuve de stock sur une étagère dans l'installation. Un revendeur peut légalement commercialiser du matériel tout en attendant des jours pour un distributeur.

Pour les services virtuels, une capacité de réserve peut remplacer une pièce du même modèle si les charges de travail se déplacent vers un autre nœud sain. Cela nécessite que le stockage et le réseau restent disponibles et une réserve suffisante pour absorber la charge. Pour les serveurs dédiés, le client peut avoir besoin d'un remplacement exact ou équivalent. Si la machine défaillante contient des disques locaux, la réparation peut devenir un problème de récupération de données plutôt qu'un simple échange.

Un engagement de support devrait donc définir l'horloge. Le temps de remplacement commence-t-il lorsque la surveillance détecte une panne, lorsqu'un client ouvre un ticket, lorsqu'un ingénieur confirme le diagnostic ou lorsqu'une pièce de rechange arrive? Le service d'intervention à distance est-il disponible 24h/24 et 7j/7? Qui approuve les travaux destructifs? Les disques chiffrés et les supports défaillants sont-ils conservés ou détruits? Aucune de ces conditions n'est publiquement visible pour PT Cloud.

Défaillance du support: une petite équipe peut être le point unique caché

L'enregistrement APNIC fournit des contacts administratifs et techniques nommés. C'est une responsabilité utile pour les ressources numériques, mais deux noms n'établissent pas une organisation de support 24h/24. Les pages d'information sur l'entreprise ne divulguent pas l'effectif, les quarts ou un centre d'exploitation. Le site web non fonctionnel ne laisse aucune page de statut publique, portail de tickets, matrice d'escalade ou historique d'incidents à évaluer.

Les petits fournisseurs peuvent offrir un excellent service parce que les clients atteignent directement des ingénieurs expérimentés. Ils peuvent aussi concentrer la connaissance sur une ou deux personnes. Un incident pendant une maladie, un voyage ou un jour férié peut durer plus longtemps que la panne technique. La garde des mots de passe, les clés de signature, l'accès au bureau d'enregistrement, l'autorisation d'installation et l'approbation de facturation peuvent tous dépendre des mêmes individus.

La capacité de support a sa propre distinction entre installé et utilisable. Cinq ingénieurs sur une page d'entreprise ne signifient pas cinq personnes disponibles pendant un incident. Les projets planifiés, les pannes clients concurrentes et les déplacements vers l'installation réduisent la couverture effective. Les mesures pertinentes sont les services surveillés par quart, le temps d'accusé de réception, le temps d'engagement d'un ingénieur qualifié, l'escalade vers les opérateurs et l'autorité pour effectuer des changements d'urgence.

Les clients ont également besoin d'un chemin hors bande. Si le domaine, le réseau et le système de tickets du fournisseur partagent l'infrastructure défaillante, les canaux de support ordinaires peuvent disparaître ensemble. La route de courrier Google configurée suggère que la messagerie d'entreprise est externe à l'AS153005, ce qui est un modeste signal de séparation positif. Cela ne montre pas que le système de tickets, le service téléphonique, la page de statut ou les identifiants d'installation sont indépendants de manière similaire.

Défaillance de facturation et de contrat: le service peut s'arrêter sans incident technique

La capacité cloud est une chaîne d'obligations récurrentes. Le fournisseur peut devoir à l'installation pour l'espace en baie et l'énergie, à un opérateur pour le transit, à un éditeur de logiciel pour les licences de virtualisation ou de panneau de contrôle, à un bureau d'enregistrement pour les domaines et aux fournisseurs pour le matériel. Les clients doivent au fournisseur. Une défaillance à n'importe quel maillon commercial peut devenir un événement de service.

L'ambiguïté d'identité augmente les enjeux. Si une facture porte THANH CLOUD tandis que l'ASN et le bénéficiaire bancaire portent Phu Thanh Cloud, un client doit savoir quelle partie possède le matériel et laquelle peut remédier à un défaut. Si un revendeur se situe entre le client et l'installation, le revendeur peut ne pas contrôler l'accès physique. Si les adresses sont portables mais que les routeurs sont détenus dans une baie contestée, la portabilité sur papier peut ne pas les restaurer rapidement.

Aucun événement indésirable n'est établi ici. Le point est structurel: un SLA couvrant la perte d'énergie et de paquets peut ne rien dire sur la résiliation du fournisseur, l'insolvabilité, l'expiration de licence ou les factures contestées. Un accord résilient devrait prévoir un préavis, des périodes de grâce, l'accès aux données pendant un litige, les droits d'exportation du client et la coopération pour une transition ordonnée. Il devrait distinguer la suspension pour abus de la suspension pour facturation et préserver un moyen de récupérer les données lorsque cela est légal.

L'activation récente de la route de l'entreprise peut être lue positivement comme un investissement dans une identité réseau indépendante. Cela peut aussi augmenter les coûts fixes et la responsabilité opérationnelle. Les preuves ne révèlent pas l'équilibre. Les clients devraient juger la durabilité du contrat à partir de preuves commerciales auditées ou confidentielles, pas de l'existence d'un ASN.

Défaillance de migration: la sauvegarde n'est pas la même chose que l'évasion

Un fournisseur peut restaurer sa propre plateforme tout en laissant un client incapable de la quitter. La portabilité dépend des formats d'image, des extractions de données, de la configuration réseau, des clés, de la bande passante et du temps. Une exportation de disque virtuel sans règles de pare-feu, DNS, données d'objet ou clés de chiffrement peut être incomplète. Une grande exportation sur un lien congestionné peut prendre plus de temps que la période de préavis.

ISO/IEC 19941 traite l'interopérabilité et la portabilité cloud comme des préoccupations transversales distinctes. Le travail sur les cas d'utilisation du cloud du NIST pose la question pratique directement: un client peut-il changer de fournisseur à faible coût et avec peu de perturbations? Cette question est particulièrement importante lorsque le vendeur a un préfixe visible unique et aucune conception multi-site publiée.

Aucune condition publique de PT Cloud ne spécifie les formats d'exportation, les frais de sortie, l'accès aux instantanés après résiliation, la portabilité des adresses pour les clients, le moment de la suppression ou l'assistance à la transition. Il n'y a pas de temps maximum publié pour produire une exportation. Les clients devraient supposer qu'aucun de ces droits n'existe jusqu'à ce qu'ils apparaissent dans le contrat.

Un test de sortie crédible déplacerait une charge de travail représentative vers un autre fournisseur pendant que le service d'origine est sain. Il mesurerait le volume de données, le taux de transfert, le travail de conversion, le changement DNS, la réémission de certificat, la reconstruction du pare-feu et le retour arrière. Le client devrait conserver son propre code d'application, sa configuration et une sauvegarde indépendante dans la mesure du possible. Les instantanés du fournisseur sont utiles pour un retour rapide mais peuvent échouer avec le même compte, système de stockage ou contrat.

Ce n'est pas un argument contre les petits clouds. C'est un argument pour réduire la différence entre une migration normale et une migration d'urgence. Moins un client en sait sur l'emplacement physique et les dépendances des fournisseurs, plus une sortie testée devient précieuse.

La reprise multi-site n'est pas visible

Aucun matériel public examiné ne prétend ou ne démontre que le service fonctionne depuis deux centres de données. Le/23actif ne code pas l'emplacement. Un seul préfixe peut être annoncé depuis un site, plusieurs sites ou un routeur distant. L'enregistrement américain de l'ASN amont ne localise pas les serveurs de PT Cloud. Les bases de données de géolocalisation IP répètent souvent le pays d'enregistrement ou infèrent l'emplacement à partir de mesures éparses; elles ne sont pas la preuve qu'un disque client se trouve à Hanoi.

Multi-site a également plusieurs significations. Un fournisseur peut conserver des sauvegardes dans un second bâtiment sans y exécuter de calcul. Il peut exécuter du calcul de réserve sans données actuelles. Il peut étendre un cluster de stockage sur deux salles qui partagent un chemin de fibre métropolitaine. Il peut exploiter des charges de travail actives dans deux villes tout en laissant les systèmes de compte et d'identité dans un seul site. Chaque conception récupère d'un ensemble différent de défaillances.

Le client a besoin d'objectifs de temps de reprise et de point de reprise pour chaque service. Le guide de planification de contingence du NIST distingue l'équipement alternatif, le traitement alternatif et la reprise sur un site alternatif. Le guide de test de reprise de Google Cloud souligne utilement l'intégrité des données, le temps de reprise, le point de reprise et la restauration de l'ensemble de la pile applicative. Ces principes s'appliquent quelle que soit la taille du fournisseur.

Un journal de sauvegarde n'est pas suffisant. Les preuves devraient montrer la dernière restauration réussie, ce qui a été restauré, dans quel environnement isolé, combien de temps cela a pris et quel intervalle de données a été perdu. Si le basculement nécessite de nouveaux serveurs, le matériel doit exister. S'il nécessite une route depuis un second site, le filtrage et l'autorisation doivent être prêts. S'il nécessite un ingénieur particulier, cette personne ne doit pas être le seul détenteur des identifiants.

Tant que PT Cloud n'identifie pas un second site d'exploitation et ne fournit pas de résultats de test, les clients devraient planifier comme si le service avait une seule région physique et une seule sortie réseau visible.

La localisation des données ne peut être déduite d'un ASN vietnamien

L'entreprise est vietnamienne, son ASN est enregistré au Vietnam et les annuaires réseau tiers étiquettent le préfixe comme vietnamien. Aucun de ces faits ne prouve où les données des clients sont stockées. Le pays d'enregistrement décrit le détenteur des ressources. BGP décrit la joignabilité. Un serveur peut émettre un préfixe enregistré au Vietnam depuis un autre pays, et un panneau de contrôle vietnamien peut provisionner du stockage ailleurs.

Le contexte juridique rend la précision plus importante. Le Décret 53/2022 fixe des exigences de stockage vietnamien pour certaines données et circonstances en vertu de la Loi sur la cybersécurité. Le Décret 13/2023 réglemente le traitement des données personnelles et s'applique aux organisations vietnamiennes ainsi qu'aux parties étrangères concernées. La Loi sur les données de 2024, en vigueur à partir de juillet 2025, ajoute des règles pour le stockage des données et un traitement spécial pour les données nationales, essentielles et importantes.

Ces lois ne transforment pas chaque serveur commercialisé au Vietnam en stockage local vérifié. L'applicabilité dépend du client, des données et du service. La conformité implique également la finalité du traitement, l'accès, le transfert, la conservation et la sécurité, pas seulement le pays du disque. Les clients devraient obtenir des conseils juridiques pour leurs propres obligations.

Le contrat du fournisseur devrait indiquer les pays de production et de sauvegarde, les installations nommées ou au moins les villes, les sous-traitants, l'accès transfrontalier du support, l'emplacement des journaux et les conditions de déplacement des données. Il devrait expliquer si les instantanés et les copies de reprise après sinistre restent au Vietnam. Il devrait dire quelle partie agit en tant que responsable du traitement ou sous-traitant selon l'arrangement concerné et comment la suppression est attestée.

L'empreinte publique de PT Cloud ne fournit aucun de ces détails. La souveraineté et la localisation des données restent donc un sujet important précisément parce que la réponse n'est pas résolue. Une affirmation comme « IP Vietnam » ou « cloud Vietnam » ne la réglerait pas. Des divulgations d'installation et de traitement le feraient.

L'économie favorise la location, mais le contrat doit révéler la dépendance

Une société créée en 2022 avec un petit bloc d'adresses est peu susceptible de reproduire l'économie complète d'un exploitant national de centres de données. C'est une inférence, pas une conclusion sur l'architecture exacte de PT Cloud. Pour un petit hébergeur, louer de l'espace en baie et acheter du transit peut être rationnel: le capital est dirigé vers les serveurs, les logiciels et le support tandis que l'installation répartit les générateurs, le refroidissement et la sécurité sur de nombreux locataires.

Le modèle crée une facture à plusieurs niveaux. Les clients paient l'hébergeur; l'hébergeur paie pour le matériel, les unités de baie, les kilowatts, les interconnexions, le transit, les logiciels et la main-d'œuvre. La capacité n'est rentable que lorsque l'utilisation est suffisamment élevée pour couvrir ces coûts fixes, mais la résilience nécessite une marge inutilisée, des pièces de rechange et des systèmes dupliqués. La tentation de vendre trop près des limites physiques est inhérente à l'économie de l'hébergement.

Le/23récemment actif peut améliorer le contrôle des adresses et du routage. L'espace portable peut faciliter le changement de fournisseur de transit par rapport aux adresses attribuées par le fournisseur, en supposant que de nouvelles sessions et des filtres soient préparés. Il peut également soutenir une allocation client plus propre et une gestion des abus. Mais la ressource d'adresses ne réduit pas le coût d'une seconde baie, d'une seconde ville ou d'un quart de nuit doté en personnel.

La question commerciale clé est ce que le prix bas, s'il existe, omet. La sauvegarde est-elle incluse ou simplement disponible? L'engagement de service exclut-il les incidents en amont? Le support est-il pratique ou à distance? Le remplacement du matériel est-il stocké? Les exportations sont-elles facturées à la bande passante? Le client peut-il choisir un emplacement de données? Sans catalogue et conditions actuels, aucune de ces questions ne peut être répondue publiquement.

Les clients n'ont pas besoin que le fournisseur possède chaque dépendance. Ils ont besoin que le fournisseur nomme la dépendance, s'engage contractuellement de manière responsable et explique la limite de reprise. Externaliser l'énergie à un exploitant de centre de données peut renforcer la résilience. Cacher l'exploitant empêche le client d'évaluer la concentration.

Qui est affecté lorsque le système tombe en panne

Il n'y a pas de liste de clients publics vérifiée, il serait donc erroné de nommer des organisations comme dépendantes de PT Cloud. La population affectée peut être décrite par type de service.

Si l'entreprise vend du VPS ou de l'hébergement mutualisé, les petites entreprises, les boutiques en ligne, les équipes logicielles et les agences peuvent perdre des sites, des applications, du courrier ou des bases de données. Un retrait de route rend toutes les charges de travail sur le/23injoignables en même temps. Une panne de stockage peut corrompre un ensemble plus petit mais créer une récupération plus longue. Une panne de système de contrôle peut laisser les applications en cours d'exécution en ligne tandis que les clients ne peuvent pas les redémarrer, les redimensionner ou les restaurer.

S'il vend du bare metal, chaque client peut dépendre d'un châssis et de la file d'attente de pièces de rechange locale. S'il revend une autre plateforme, le client final dépend des deux sociétés et peut ne pas savoir quel bureau de support peut agir. S'il fournit des adresses ou du transit, les réseaux en aval peuvent hériter du seul chemin amont visible. S'il fournit des services gérés, la récupération du client dépend des connaissances du personnel et des identifiants en plus de l'infrastructure.

Le chronomètre d'incident varie également. Le contenu web mis en cache peut masquer une panne d'origine. Les machines virtuelles existantes peuvent survivre à une panne de panneau de facturation. Une corruption de base de données peut continuer à servir des données erronées tandis que chaque moniteur reste vert. Un retrait de route de masse est immédiat. Un pool de pièces de rechange épuisé ne devient visible que lorsque la machine suivante tombe en panne.

C'est pourquoi un seul chiffre de disponibilité est inadéquat. Les clients ont besoin d'engagements séparés pour la joignabilité réseau, le calcul, la durabilité du stockage, la restauration des sauvegardes, les fonctions de contrôle et la réponse du support. Ils ont également besoin de savoir quelles exclusions leur renvoient le risque du propriétaire et de l'opérateur.

Preuves qui changeraient l'évaluation

L'évaluation actuelle peut s'améliorer rapidement car les preuves manquantes sont spécifiques.

L'identité serait résolue par un certificat d'entreprise à jour et un contrat montrant la relation entre THANH CLOUD COMPANY LIMITED, Phu Thanh Cloud Company Limited et PT Cloud. Le contrat, la facture et le bénéficiaire bancaire devraient identifier la même partie responsable ou expliquer chaque rôle.

Le service serait défini par un catalogue actuel: VPS, bare metal, hébergement, service géré, transit ou autre produit. Il devrait indiquer les garanties de ressources, l'architecture de virtualisation et de stockage, l'isolation des clients, la méthode de provisionnement, le comptage et les systèmes d'exploitation pris en charge. Un site web public aiderait, mais les spécifications contractuelles importent davantage.

Le domaine physique serait établi par des installations nommées, la propriété ou la location de baie, la ville, l'allocation de puissance et les certifications au niveau du site. Un client sous confidentialité peut examiner les factures de colocation, les schémas de baie, les listes d'accès et les commandes d'interconnexion sans exposer de détails de sécurité sensibles.

La résilience réseau serait établie par deux amonts actuels, leurs ASN, les tailles de port et une livraison physiquement diversifiée. Des preuves de looking glass ou de surveillance de route devraient montrer le préfixe par les deux chemins. L'allocation et l'annonce IPv6 amélioreraient la couverture protocolaire. La propriété et la capacité d'atténuation des attaques devraient être énoncées séparément du transit ordinaire.

La reprise serait établie par des résultats de restauration et de basculement datés. Les preuves devraient inclure le point de reprise, le temps de reprise, les contrôles d'intégrité des données, les changements de route, la disponibilité du système de contrôle et les personnes impliquées. Un second site devrait être décrit par l'état de la charge de travail, pas simplement par le mot « sauvegarde ».

La résilience matérielle serait établie par un inventaire des nœuds actifs, la capacité réservée, la réplication, les pièces de rechange et les objectifs de remplacement. La résilience du support serait établie par la couverture des quarts, les temps d'accusé de réception et d'escalade, les communications hors bande et au moins deux détenteurs d'identifiants pour les systèmes critiques.

La portabilité serait établie par les formats d'exportation, les taux de transfert, les frais, les périodes de préavis, la preuve de suppression et une migration d'essai terminée. La localisation des données serait établie par les emplacements de production et de sauvegarde, les sous-traitants et les arrangements d'accès.

Ce sont des faits ordinaires pour l'exploitation d'un service d'hébergement. Aucun ne nécessite de divulguer les noms des clients, les coordonnées exactes des baies, les mots de passe ou une topologie exploitable. Ils transforment une promesse cloud en un service qui peut être évalué.

Une route active mérite de l'attention, pas une prime de résilience

L'AS153005 a changé la donne fin juin 2026. Le réseau n'est plus simplement un ASN alloué mais invisible dans la télémétrie actuelle. Il émet un/23valablement autorisé et a un chemin visible vers l'Internet mondial. Avec les informations correspondantes de l'APNIC et de l'entreprise, c'est une preuve crédible d'activité réseau récente.

Le changement est trop récent et trop étroit pour soutenir une conclusion opérationnelle forte. La route a un amont observé unique, pas d'IPv6 observé, aucune divulgation publique d'échange ou d'installation et aucun catalogue de services visible au domaine de l'entreprise. Les preuves publiques ne peuvent pas connecter les adresses aux machines des clients, identifier la baie ou montrer une restauration réussie. Elles ne peuvent pas prouver que le nom en titre et le nom légal APNIC sont contractuellement identiques.

La classification sensée est donc faible, pas négative. Il y a quelque chose de réel à vérifier: une entreprise, un ASN, un bloc portable, un routage actuel et une configuration de domaine de messagerie maintenue. Une évaluation négative ignorerait ces preuves. Une évaluation moyenne ou forte transformerait le routage en capacité cloud et supposerait les couches physiques manquantes.

Pour les clients, la tâche immédiate est simple. Vérifier la contrepartie juridique, le produit, l'installation, deux chemins de route, la réserve de défaillance disponible, l'escalade du support, la reprise testée et le processus d'exportation avant de placer une charge de travail importante. Jusqu'à ce que ces faits soient fournis, le service doit être traité comme une dépendance à région unique et à amont visible unique avec des caractéristiques de reprise inconnues.

Le langage cloud donne l'impression que la capacité est détachée du lieu. L'AS153005 montre le contraire. Derrière le compte, il doit encore y avoir une baie, un contrat d'énergie, une route, du matériel que quelqu'un peut remplacer et des personnes autorisées à agir. Pour THANH CLOUD COMPANY LIMITED, ces dépendances ne sont pas réfutées. Elles ne sont simplement pas encore assez visibles pour être tarifées en tant que résilience.