Le contrat avant le cloud: le réseau visible d'Ehost et ses spécifications concurrentes

Résumé

• EHOST SOFTWARE COMPANY LIMITED est appuyée par des identifiants légaux, de contact et réseau cohérents: les noms de site opérationnels Công ty TNHH Phần Mềm EHOST et le code fiscal 0312916711, tandis que les enregistrements de routage publics identifient AS135920 comme EHOST-VN et montrent cinq préfixes IPv4/24annoncés.
• L’empreinte de routage est réelle mais modeste. Les sources BGP examinées montrent 1 280 adresses IPv4 annoncées, aucun espace IPv6 annoncé et une seule adjacence upstream observée via AS135905. Cela ne prouve ni un service médiocre ni un mono-hébergement physique, mais rend matérielles les questions de diversité de routage, de basculement et de disponibilité IPv6 spécifique au produit.
• Les surfaces commerciales publiques d’Ehost ne fournissent pas de spécification produit stable. La même étiquette Cloud 1G à 250 000 dongs est décrite différemment sur la page marketing et le portail de facturation, et les offres de colocation publiques et de paiement divergent également. Un bon de commande signé doit donc définir les termes faisant autorité concernant le CPU, la mémoire, le stockage, les IOPS, la bande passante, la localisation, la sauvegarde et le support.
• Les affirmations sur la sauvegarde, la sécurité et le support nécessitent le même traitement. Ehost annonce des sauvegardes quotidiennes ou hebdomadaires, des pare-feu physiques, AntiDDoS, un support 24/7 et une réponse en cinq minutes sur certains produits, mais il ne divulgue pas publiquement un plan de reprise complet, une matrice de gravité, un calendrier de crédit de service, un historique des incidents, un processus de gestion des abus ou un périmètre d’assurance indépendant.
• Le fournisseur peut convenir aux clients qui apprécient la facturation vietnamienne, le support humain direct, l’aide à la migration et un menu couvrant l’hébergement partagé, le cloud, les serveurs dédiés, la colocation, la sauvegarde et la protection DDoS. Les acheteurs ayant des exigences strictes de continuité, de conformité ou de portabilité doivent effectuer une preuve de service et négocier une sortie exécutable avant de passer en production.

Un serveur à 250 000 dongs avec deux réponses

Commençons par le plus petit package cloud d’Ehost. Sur la page publiqueCloud Server, « EHOST 1G » coûte 250 000 dongs vietnamiens par mois et est décrit comme deux cœurs CPU, 2 Go de RAM, 30 Go de stockage SSD et une connexion réseau à 100 Mbps. La page indique que tous les plans cloud reçoivent au moins 2 000 IOPS de stockage. Sur la page de commandeSSD Cloud Serveren direct d’Ehost, « Cloud 1G » commence également à 250 000 dongs par mois, mais la spécification affichée est d’un cœur CPU, 2 Go de RAM, 20 Go de stockage SSD, un réseau à 200 Mbps et 10 000 IOPS.

Aucune des deux pages n’est obscure. L’une est l’explication du service destinée aux clients; l’autre est le système par lequel un acheteur est invité à commander. Pourtant, elles décrivent des unités de calcul matériellement différentes. L’écart ne se limite pas au plus petit plan. L’offre publique Cloud 2G liste deux cœurs, 4 Go de RAM et 40 Go de stockage; la version de paiement liste deux cœurs, 2 Go de RAM et 40 Go. Les packages supérieurs diffèrent également en mémoire et en disque. Une catégorie de facturation distincte,SSD Cloud Server C6, présente une autre génération de plans nommés de manière similaire, dont un Cloud 1G à 350 000 dongs avec deux cœurs, 2 Go de RAM, 30 Go de stockage, 200 Mbps et 50 000 IOPS.

Cela ne prouve pas que les clients sont mal provisionnés. Un catalogue peut contenir une catégorie héritée, un pool matériel plus récent, une page d’accueil obsolète ou une configuration clarifiée lors de la vente. Cela prouve que le dossier public ne peut pas répondre à la question d’achat la plus élémentaire: quelle spécification devient l’obligation lorsque le paiement est effectué?

Pour un fournisseur d’infrastructure, ce n’est pas une erreur de publication mineure. L’allocation CPU affecte le débit de l’application. La mémoire peut déterminer si une base de données reste résidente ou swappe. La taille du disque affecte la faisabilité de la migration. Les IOPS peuvent modifier le comportement des charges transactionnelles d’un ordre de grandeur. Un débit réseau peut être un plafond de port, un débit garanti, un profil partagé ou une limite de burst. Chaque variation peut altérer les performances et le coût total.

Le premier contrôle dans un achat Ehost doit donc être documentaire. Le devis, le bon de commande ou le contrat doit identifier la famille de produits et la génération exactes; le nombre de vCPU et le modèle de planification; la mémoire garantie; le stockage utilisable; le support de stockage; les IOPS minimales et en burst; la bande passante nationale et internationale; les limites de transfert; l’allocation d’IP publique; la localisation; l’image du système d’exploitation; le périmètre de gestion; l’inclusion de sauvegarde; les frais de restauration; les taxes; et la durée de renouvellement.

L’acheteur doit conserver ce document avec la facture et la preuve de provisionnement initial.

La thèse centrale de cette revue découle de ces deux fiches Cloud 1G. L’infrastructure d’Ehost n’est pas correctement décrite par le nom de marque, le prix mensuel ou le mot « cloud ». Son véritable produit commence lorsque les parties réconcilient la page de vente, le portail de facturation et le service réellement livré.

L’entreprise exacte derrière les écrans

La limite de l’entité est particulièrement importante car « Ehost » apparaît comme une marque, un domaine, un portail de support, un service AntiDDoS et un réseau enregistré. L’entreprise examinée ici estEHOST SOFTWARE COMPANY LIMITED, en vietnamienCông ty TNHH Phần Mềm Ehost, avec le code fiscal0312916711. Lapage de contactd’Ehost donne le nom légal, le numéro d’enregistrement, une adresse à Ho Chi Minh Ville au 147/25 An Dương Vương à Bình Tân, le numéro de téléphone 0938-227-199 et une adresse de contact@ehost.vn. Le pied de page indique que l’enregistrement commercial a été délivré le 9 septembre 2014.

Unagrégateur tiers de registres fiscaux vietnamiensassocie indépendamment le même code fiscal à EHOST SOFTWARE COMPANY LIMITED, la même adresse, une date d’opération au 9 septembre 2014 et le représentant Nguyễn Thanh Tâm. Cet enregistrement est une corroboration utile, non un substitut à un extrait frais du registre officiel des entreprises du Vietnam. Son statut et ses classifications sectorielles doivent être traités comme le rendu daté par l’agrégateur de documents publics.

L’identité réseau fournit une vérification de continuité distincte.BGP.toolsreproduit les données d’enregistrement d’origine APNIC pour AS135920:EHOST-VN, décrit comme Ehost software company limited, pays Vietnam, maintenu via VNNIC. L’enregistrement a été modifié en janvier 2026. Lapage IPinfo d’AS135920classifie également le réseau comme hébergement et l’associe au même nom d’entreprise.

Ces liens soutiennent une conclusion honnête: la société légale, la surface de vente activeehost.vn, la surface de facturation et de supportsecure.ehost.vn, et AS135920 appartiennent à une empreinte opérationnelle cohérente. Ils ne prouvent pas que chaque service annoncé sur chaque domaine associé est possédé, opéré ou garanti par l’entreprise. IPinfo, par exemple, listeehost.com.vncomme domaine de l’ASN, tandis que le site opérationnel actuel examiné ici estehost.vn; le premier n’a pas donné de page utilisable lors de cette recherche. C’est une question de continuité de domaine pour l’entreprise, pas une raison pour diviser ou fusionner des entités.

La même prudence s’applique à AntiDDoS. Ehost renvoie directement àAntiddos.vn, et sa page cloud indique que les clients peuvent s’intégrer à ce service. Le site AntiDDoS se présente comme un réseau de mitigation vietnamien multi-nœuds fondé en 2015. Les pages publiques examinées ici n’exposent pas d’identité corporative distincte ou de chaîne contractuelle suffisante pour déterminer si Antiddos.vn est une division, un produit, une filiale ou un partenaire commercial d’EHOST SOFTWARE COMPANY LIMITED. Un acheteur devrait rendre explicite la partie contractante plutôt que de l’inférer à partir de liens croisés.

Une identité exacte importe en cas de défaillance. L’entité qui prend le paiement doit être celle obligée de fournir le service, de protéger les données, de notifier les incidents, de retourner l’équipement ou d’exporter, et de payer tout remboursement ou crédit de service. Si un opérateur de centre de données, un concédant de logiciel, un service de mitigation ou un transporteur réseau exécute une partie du service, le client doit savoir si Ehost reste responsable de cette dépendance ou se contente de la revendre.

Ce qu’AS135920 prouve — et ce qu’il ne prouve pas

AS135920 est la preuve indépendante la plus solide qu’Ehost exploite plus qu’une brochure et une vitrine de revendeur. Dans la vue figée du BGP public, le système autonome annonce cinq préfixes IPv4/24:45.123.96.0/24,45.123.97.0/24,103.63.212.0/24,103.63.213.0/24et103.63.215.0/24. Cela représente 1 280 adresses IPv4.BGP.toolsetIPinfomontrent tous deux que les préfixes sont couverts par des autorisations d’origine de route valides. La table de validation d’origine de route du Vietnam d’APNIC Labs rapporte une couverture valide à 100 % pour la population d’adresses EHOST-VN mesurée.

C’est une preuve opérationnelle significative. Ehost dispose de ressources numériques visibles dans le système de routage mondial. Plusieurs adresses répondent à des sondes indépendantes, et IPinfo signale des centaines de domaines sur les adresses de l’ASN. L’empreinte est cohérente avec une activité d’hébergement plutôt qu’avec une coquille juridique qui ne ferait que commercialiser la plateforme d’un autre.

La validité RPKI est également un contrôle réel. Elle permet aux validateurs de route de vérifier cryptographiquement qu’AS135920 est autorisé à annoncer les préfixes couverts. Le rapport 2024 sur les ressources Internet de VNNIC traite RPKI et IPv6 comme des éléments importants du développement des ressources Internet du Vietnam. Les autorisations d’origine valides d’Ehost réduisent une classe de risque d’erreur d’origine de route ou de détournement.

La preuve s’arrête là. RPKI ne montre pas qu’Ehost filtre les routes invalides reçues d’autres, protège les applications des clients, maintient des routeurs redondants ou peut survivre à une défaillance de transporteur. Cela ne dit rien sur le volume de trafic, la capacité des serveurs, l’alimentation, le refroidissement, la capacité de filtrage DDoS, la qualité des sauvegardes ou le nombre de clients. Une annonce de cinq préfixes peut supporter un hébergeur spécialisé bien géré ou un fragile; la table de routage ne décide pas entre eux.

La connectivité visible est plus prudente. BGP.tools liste un upstream, AS135905, décrit comme Vietnam P&T. Le rapport CIDR indépendant voit également une seule adjacence upstream et aucun espace d’adressage downstream. IPinfo liste également un upstream et un peer, tous deux AS135905. Les étiquettes de relation varient selon la source de données, mais l’observation constante est un seul réseau adjacent visible portant les routes d’AS135920 dans les vues examinées.

Cela ne doit pas être traduit par l’affirmation que chaque rack Ehost a un seul câble physique ou que chaque produit est mono-hébergé. Ehost annonce de la colocation dans plusieurs marques de centres de données, et peut utiliser des adresses assignées par le fournisseur, des interconnexions privées, des services de couche 2, une mitigation DDoS distante ou des routes non visibles comme des adjacences AS séparées. Les collecteurs BGP publics peuvent également manquer des relations privées ou sélectives.

Cela crée néanmoins un test d’achat. Si un service est vendu comme multi-opérateur ou multi-centre de données, Ehost doit montrer comment le trafic client survit à la perte d’AS135905, du routeur frontière concerné, du site de desserte et du chemin vers la plateforme de mitigation. Les preuves pourraient inclure un diagramme d’architecture, les sessions BGP actuelles, la politique de routage, les résultats d’un looking-glass, les enregistrements de basculement et un test contrôlé. « Plusieurs centres de données » est une déclaration d’installation; « diversité de joignabilité Internet » est une déclaration de routage.

L’une ne délivre pas automatiquement l’autre.

IPv6 est l’autre écart visible. Les sources de routage examinées montrentzéro préfixe IPv6 annoncépour AS135920. Cela ne prouve pas qu’Ehost n’offre nulle part IPv6: un client pourrait recevoir IPv6 d’une installation ou d’un ASN upstream. Cela signifie qu’un acheteur ne peut pas déduire un service dual-stack natif du propre système autonome d’Ehost. Les questions spécifiques au produit devraient couvrir la taille de l’allocation IPv6, le routage, le DNS inverse, le pare-feu, la gestion DDoS, la surveillance et la parité avec le support IPv4. En 2026, « nous pouvons l’ajouter plus tard » est un engagement de cycle de vie, pas une réponse technique.

Un catalogue de différents modèles de responsabilité

Ehost ne vend pas un seul modèle d’infrastructure. Son menu public couvre l’hébergement partagé, l’hébergement email, les machines virtuelles, les serveurs dédiés, les serveurs de jeux, la colocation, la sauvegarde, le stockage de type objet, le cache, le courtage CDN, les licences de panneau de contrôle, les certificats et la protection DDoS. Chacun déplace une partie différente de la pile d’exploitation entre le fournisseur et le client.

Enhébergement partagé personnel, Ehost indique que la plateforme fournit cPanel, SSL, stockage SSD, une couche AntiDDoS de base et des sauvegardes hebdomadaires. Le client gère principalement le code du site, le contenu, les comptes et les mises à jour d’application, tout en dépendant d’Ehost pour le serveur partagé, le panneau de contrôle, le réseau et l’isolation. Lapage d’hébergement professionnelajoute une IP publique dédiée, un cache Redis et revendique une séparation des ressources. C’est un service partagé avec plus de contrôle, pas équivalent à un serveur virtuel.

Le cloud transfère davantage de responsabilité au client. La page publique d’Ehost indique qu’il utilise OpenStack, fournit une machine virtuelle, permet au client d’ajouter du CPU, de la mémoire et du disque, et peut arrêter le serveur pendant deux à cinq minutes lors d’une mise à niveau. Sauf si un contrat de service géré distinct s’applique, l’acheteur doit supposer que le durcissement du système d’exploitation, l’application des correctifs, l’exploitation de la base de données, la gestion des identités et la surveillance de la charge de travail restent des devoirs du client.

Les pages publiques n’étiquettent pas clairement les plans cloud standard comme gérés ou non gérés.

Les serveurs dédiés transfèrent l’exclusivité matérielle à l’acheteur mais pas nécessairement la propriété matérielle. Lapage des serveurs dédiés 2026d’Ehost liste des configurations mensuelles de 5,5 à 12 millions de dongs, avec des processeurs Intel Xeon, 128 ou 256 Go de RAM, du stockage SSD ou NVMe, une adresse IP et une bande passante de 100 à 200 Mbps. L’acheteur évite la contention de calcul du voisin bruyant, mais reste dépendant d’Ehost pour la machine, le rack, l’alimentation, le chemin de transporteur, les mains distantes et le processus de remplacement.

La colocation est encore différente. Le client possède ou contrôle le serveur physique et loue l’espace rack, l’alimentation et la connectivité. Ehost indique que les clients peuvent entrer dans le centre de données 24h/24 après préenregistrement et peuvent utiliser un KVM distant. Dans ce modèle, Ehost peut avoir moins de contrôle sur le serveur et plus de responsabilité pour la coordination d’accès, l’alimentation, les cross-connects, le routage et l’assistance sur site. Une matrice de défaillance doit séparer le matériel du client, l’infrastructure de l’installation, le réseau Ehost et le transporteur upstream.

Lapage ECDNindique qu’Ehost coopère avec des fournisseurs CDN vietnamiens et internationaux plutôt que de décrire un réseau de livraison entièrement détenu. Cela peut être utile commercialement: Ehost peut agir comme intégrateur local et contact de facturation. Cela signifie aussi que les emplacements de cache, les journaux, le comportement de purge, le traitement des données, la responsabilité en cas d’incident et la sortie dépendent du fournisseur sous-jacent non nommé et de la conception spécifique à la commande.

Lapage eStoragedécrit « vStorage » comme une technologie de stockage objet développée par Ehost pour les médias, les documents, les journaux et le contenu statique, et indique que les données sont stockées en permanence et toujours sauvegardées. La page ne publie pas de spécification d’API, de modèle de cohérence, d’objectif de durabilité, de schéma d’effacement ou de réplication, de comportement de suppression, de carte de région, de prix de sortie ou de niveau de service. « Stockage objet » identifie une classe de service, pas une architecture suffisante pour une décision de données durables.

La largeur d’Ehost est donc à la fois un avantage et un fardeau de diligence. Un client peut acheter plusieurs services adjacents auprès d’un seul fournisseur local et réduire la coordination des fournisseurs. Mais la limite de responsabilité change chaque fois que le client passe de l’hébergement partagé au cloud, du cloud au matériel dédié, ou d’un réseau d’origine Ehost à un CDN tiers ou un chemin de centre de données.

OpenStack est une liste de composants, pas un résultat de disponibilité

Ehost indique que ses machines virtuelles fonctionnent sur OpenStack. C’est techniquement assez spécifique pour être utile, mais pas assez pour établir la résilience. Le guide officiel d’architecture logique d’OpenStack décrit un cloud comme un ensemble de services indépendants reliés par des API et un service d’identité commun. Derrière les interfaces se trouvent des bases de données, des files d’attente de messages et des processus de service pour le calcul, le réseau, les images et le stockage. OpenStack est un cadre opérationnel dont le résultat dépend de la manière dont ces parties sont déployées et maintenues.

Pour un acheteur, la première question est quelle version d’OpenStack et quel ensemble de services Ehost exploite. La réponse affecte le statut du support, les mises à niveau, les pilotes, les correctifs de sécurité et le comportement de l’API. La page produit publique n’identifie pas la version, l’hyperviseur de calcul, le backend de stockage, la conception du réseau, les zones de disponibilité, la politique de migration en direct ou l’API accessible au client.

La deuxième question est le confinement des pannes. Le propre guide de conception haute disponibilité d’OpenStack distingue le plan de données qui maintient les instances, les réseaux et le stockage en fonctionnement du plan de contrôle qui effectue les opérations de gestion. Il met l’accent sur les services redondants, les équilibreurs de charge, les bases de données, les files d’attente de messages, les commutateurs, les routeurs et l’alimentation. L’installation d’OpenStack n’élimine pas les points uniques de défaillance; les opérateurs doivent les concevoir.

Ehost indique que son cloud utilise la haute disponibilité et peut récupérer un serveur sur un autre système. C’est une affirmation d’entreprise sur un résultat. Pour l’évaluer, un acheteur devrait demander ce qui se passe en cas de plusieurs défaillances séparées:

• Si un hôte de calcul tombe en panne, la machine virtuelle redémarre-t-elle automatiquement, et combien de temps prennent la détection et le redémarrage?
• Si le stockage partagé tombe en panne, les volumes sont-ils répliqués sur des domaines de panne indépendants ou simplement protégés par RAID à l’intérieur d’un seul système?
• Si un contrôleur ou une file d’attente de messages tombe en panne, les machines existantes continuent-elles de fonctionner pendant que les opérations de gestion sont en pause?
• Si un commutateur de tête de rack ou cœur tombe en panne, existe-t-il un chemin physiquement diversifié?
• Si un site tombe en panne, un client peut-il être restauré dans un autre site à partir d’une copie indépendante?
• Si la mise à niveau OpenStack elle-même échoue, quel est le processus de retour arrière et de notification au client?

Ces questions sont importantes car l’affirmation publique de disponibilité de 99,5 % est relativement permissive. Si elle est appliquée en continu, une disponibilité de 99,5 % permet environ 3 heures et 36 minutes d’interruption dans un mois de 30 jours, soit environ 43 heures et 48 minutes par an. Ce calcul n’est pas une affirmation sur les performances réelles d’Ehost. Il montre pourquoi la période de mesure, les exclusions, le traitement de la maintenance, la source de surveillance et le recours comptent autant que le pourcentage.

Il y a également un signal de mise à niveau dans le texte du produit. Ehost indique que la modification du CPU, de la mémoire, du disque ou du réseau peut nécessiter un arrêt de deux à cinq minutes. Cela suggère qu’au moins certains redimensionnements sont une interruption plutôt qu’une opération transparente en direct. Un client qui planifie une mise à l’échelle verticale pendant les périodes de pointe devrait la tester et demander si l’extension du stockage, les changements de type d’instance et la maintenance de l’hôte suivent le même chemin.

La conclusion utile n’est ni « OpenStack n’est pas fiable » ni « OpenStack garantit le cloud ». C’est qu’Ehost a nommé une base technique plausible, tout en laissant les choix de déploiement qui déterminent le risque client largement hors du dossier public.

Le parcours client traverse trois plans de contrôle

Un client Ehost se déplace à travers trois plans de contrôle distincts: commercial, infrastructure et application. Les problèmes surviennent souvent là où la responsabilité passe entre eux.

Le parcours commercial commence surle site principal d’Ehost, où les pages produit présentent des packages et des prix mensuels. Ehost indique qu’après l’inscription, il envoie une confirmation et un avis de coût, et que le service est créé après paiement. Le client atteint ensuitesecure.ehost.vn, un système de facturation et de support avec des catégories de produits, des options d’affichage en VND et USD, un compte, des formulaires de commande, des tickets, des annonces, des téléchargements et un lien d’état du serveur.

Le conflit de spécification rend la transition importante. Avant le paiement, l’acheteur doit capturer la configuration de commande sélectionnée et obtenir une confirmation écrite qu’elle prévaut sur la copie web incohérente. Après le provisionnement, le client doit enregistrer ce qui est réellement arrivé: nombre de CPU virtuels, mémoire, disque, IP publique, route, vitesse d’interface, système d’exploitation, licence du panneau de contrôle et état de la sauvegarde. Un script d’acceptation court peut comparer la machine livrée à la commande.

Le parcours d’infrastructure commence alors. Pour un serveur cloud, Ehost provisionne le calcul, le stockage et le réseau; le client installe ou reçoit un système d’exploitation, crée des identifiants d’administrateur, pointe le DNS et déploie une application. Pour l’hébergement partagé, Ehost expose un panneau de contrôle et le client déplace les fichiers du site, les bases de données, les certificats et les paramètres de messagerie. Pour la colocation, le client doit organiser l’accès à l’installation, l’installation du rack, l’alimentation, l’adressage IP et l’administration à distance.

La migration n’est pas une seule tâche. Le site principal d’Ehost annonce des conseils gratuits et une assistance au transfert de données pour les clients utilisant ses services. Une migration de production nécessite encore un inventaire source, une copie des données, une stratégie DNS, une gestion des certificats, un test de flux de messagerie, une fenêtre de gel d’application, une vérification d’intégrité et un retour arrière. Si les adresses IP changent, les listes autorisées, les fournisseurs de paiement, les API tierces et les règles de sécurité peuvent nécessiter des mises à jour.

Si le courrier électronique change, la réputation de l’expéditeur et les enregistrements DNS tels que SPF, DKIM et DMARC deviennent partie intégrante de l’acceptation.

Le plan de contrôle des applications reste largement du ressort du client. Une machine virtuelle peut être saine alors que l’application est en panne en raison d’un déploiement défaillant, d’un disque plein, d’un certificat expiré ou d’un verrou de base de données. La base de connaissances d’Ehost comprend des articles sur les disques pleins et les erreurs de certificat, ce qui est un contenu de support utile, mais cela illustre également la frontière partagée: le fournisseur peut expliquer un symptôme sans détenir toutes les décisions de charge de travail.

Les opérations devraient donc attribuer des responsabilités nommées. Ehost peut posséder le matériel physique, la virtualisation, le réseau périphérique et les sauvegardes de plateforme. Le client peut posséder les systèmes d’exploitation, les applications, les comptes et la classification des données. Un tiers peut posséder la licence du panneau de contrôle, le CDN, l’autorité de certification, l’enregistrement du domaine ou le filtrage DDoS. Lors d’un incident, le ticket doit atteindre la partie qui peut effectivement agir.

La dernière étape commerciale est le renouvellement ou la sortie. Les pages publiques affichent des prix mensuels, mais certains produits nécessitent des minimums de plusieurs mois. Le portail de facturation montre des périodes de trois mois pour certaines offres d’hébergement, tandis que les licences DirectAdmin sont affichées avec des minimums de six mois. Les acheteurs ne doivent pas confondre un prix unitaire mensuel avec un droit de résiliation mois par mois.

Le prix n’est transparent qu’après stabilisation de la spécification

Ehost publie plus de prix que de nombreux fournisseurs d’infrastructure. C’est utile. Une petite entreprise peut voir que l’hébergement partagé commence à 50 000 dongs par mois, l’hébergement professionnel à 300 000, le cloud à 250 000, la sauvegarde à 95 000, les serveurs dédiés à 5,5 millions et la colocation sur page publique à 1,8 million. Les options additionnelles ont des prix visibles: CPU cloud supplémentaire, mémoire, disque et IPv4; stockage d’hébergement supplémentaire, domaine ou IP; espace rack, alimentation et mises à niveau réseau.

Les chiffres révèlent la conception économique d’Ehost. L’hébergement partagé répartit un serveur et une opération de support entre de nombreux clients. Les packages cloud mesurent un ensemble de capacité de calcul, mémoire, stockage et réseau. Les serveurs dédiés facturent le matériel exclusif. La colocation facture le rack rare, l’alimentation et la connectivité. La sauvegarde facture principalement par capacité stockée. Les licences et certificats ajoutent des logiciels tiers ou des services de confiance.

Pourtant, le prix publié n’est pas le même que le prix fiable. Lacatégorie de commande d’hébergement professionnelcontient une anomalie frappante: « Business-02 » est affiché à 1,35 milliard de dongs pour trois mois, alors que les packages voisins sont dans les centaines de milliers. La même page annonce des versions PHP et MariaDB héritées. Il serait déraisonnable de traiter le chiffre d’un milliard comme le tarif prévu par Ehost sans confirmation; il est mieux compris comme une preuve que la vitrine peut contenir des incohérences de saisie ou de cycle de vie.

La colocation montre un problème de réconciliation plus large. Lapage publique de colocationliste des packages 1U chez VNPT Data, Viettel IDC et CMC pour 3,2 millions, 2,8 millions et 1,8 million de dongs par mois, généralement avec 200 Mbps de réseau domestique et 30 Mbps de bande passante internationale partagée. Lacatégorie de colocation du portail de facturationliste ODS, Viettel IDC et VNPT Tân Thuận à 1,3 million ou 1,4 million de dongs, avec des ports à 100 Mbps et quatre ou dix Mbps de bande passante internationale. Les emplacements, les capacités et les prix ne sont pas équivalents.

Il peut y avoir une explication légitime: différentes générations de racks, promotions, allocations d’alimentation, durées d’engagement, offres héritées ou voies d’accès au marché. Les pages ne la fournissent pas. Un acheteur comparant uniquement le prix mensuel principal pourrait donc acheter une classe de service différente de celle supposée.

Le coût total devrait inclure au moins:

• la migration initiale, la configuration du système d’exploitation et la validation de l’application;
• la TVA et tous autres frais applicables;
• les conditions d’engagement minimal et de renouvellement;
• les options IPv4 publique, bande passante, trafic international et DDoS;
• les licences de panneau de contrôle, Windows, base de données ou autres logiciels;
• la capacité de sauvegarde, la rétention et les frais de restauration;
• le support géré ou le travail à distance;
• le temps d’arrêt pour remplacement ou mise à niveau matérielle;
• le domaine, le certificat et les dépendances email;
• l’exportation, le transfert et l’assistance à la transition à la sortie.

« Bande passante illimitée » nécessite également une définition. Plusieurs pages d’Ehost utilisent ce terme tout en publiant séparément des débits de port ou une bande passante internationale. Illimité peut raisonnablement signifier pas de frais de transfert basés sur l’utilisation, pas un débit infini ou un circuit dédié sans contention. Le contrat doit distinguer la vitesse du port, le débit d’information garanti (CIR), le comportement de rafale, la politique d’utilisation raisonnable et les chemins domestiques et internationaux.

Ehost peut encore être compétitif en prix après chaque terme clarifié. Le dossier public n’est pas suffisant pour calculer la marge, la sursouscription ou le coût à service comparable face aux concurrents. Il suffit de montrer que la comparaison des prix doit commencer après la réconciliation du produit, pas avant.

La sauvegarde est une promesse avec deux périodes de rétention

La sauvegarde est l’endroit où le matériel public d’Ehost est le plus utile et le plus contradictoire. La page cloud dit d’abord que l’ensemble du cloud est sauvegardé quotidiennement et que les copies sont conservées au moins sept jours. Dans les notes du plan, elle dit que « Sauvegarde complète quotidienne » conserve les quatorze jours les plus récents et facture 500 000 dongs par restauration. Les deux affirmations apparaissent sur la même page.

L’hébergement partagé suit une autre politique. Les pages personnelles et professionnelles indiquent que les données sont tripliquées en temps réel et sauvegardées chaque semaine, avec des sauvegardes conservées pendant deux mois. Un serviceCloud Backupséparé vend du stockage de 10 à 100 Go et dit qu’il peut sauvegarder un disque entier afin qu’un système d’exploitation et des applications puissent être déplacés vers un matériel de remplacement. Il annonce un support technique 24/7/365 et un paiement mensuel.

Il peut s’agir de couches distinctes: réplication de plateforme, sauvegarde de service incluse et sauvegarde achetée par le client. Elles devraient être distinctes. La triplication en temps réel peut protéger contre une défaillance de disque tout en reproduisant instantanément la suppression ou les données chiffrées par ransomware d’un client. Un instantané de plateforme peut aider Ehost à récupérer l’infrastructure tout en étant inapproprié pour une restauration granulaire client. Un service de sauvegarde payant peut avoir une rétention et un isolement distincts. Les pages actuelles ne donnent pas une carte unique de ces couches.

Le propre guide de sauvegarde et de récupération d’OpenStack rend claires les questions manquantes: la fréquence des sauvegardes doit suivre la perte de données acceptable; la rétention et le stockage hors site importent; et le test de récupération est aussi important que l’existence de copies. Les affirmations publiques d’Ehost ne divulguent pas l’emplacement des sauvegardes, l’immuabilité, le chiffrement, la séparation administrative, la politique de suppression, l’objectif de temps de restauration ou les résultats des tests.

Un acheteur devrait transformer « sauvegarde incluse » en un calendrier:

1. Périmètre:volume de démarrage, volumes attachés, bases de données, stockage objet, configuration du panneau de contrôle, boîtes aux lettres et clés gérées par le client.
2. Point de récupération:la quantité maximale de données pouvant être perdue dans chaque service.
3. Temps de récupération:quand Ehost commence à travailler et quand une charge de travail utilisable doit revenir.
4. Rétention:nombre exact de copies récupérables et comment l’âge est calculé.
5. Isolement:si les copies survivent à un compromis du compte de production, du cluster ou du site.
6. Méthode de restauration:machine entière, niveau fichier, niveau base de données et restauration vers un emplacement alternatif.
7. Frais:restaurations incluses, frais d’urgence et coûts de sortie de données.
8. Preuve:tests de restauration client programmés avec résultats enregistrés.

Le conflit entre sept et quatorze jours doit être résolu dans le contrat, mais la question plus profonde est la responsabilité. Si l’application d’un client génère des données critiques, une sauvegarde Ehost ne devrait pas être la seule copie contrôlée par le même compte et fournisseur. Le client a besoin d’une voie d’exportation ou de réplication indépendante dont les identifiants et le domaine de défaillance diffèrent de la production.

Une réponse en cinq minutes n’est pas une récupération en cinq minutes

La surface de support d’Ehost est visible. Le site principal fournit des contacts téléphoniques et email; le portail de support propose des tickets, une base de connaissances, des annonces, des téléchargements et l’état du serveur. Lapage de garantie de serviceindique que le support fonctionne 24h/24 et que les clients seront notifiés par email, téléphone ou contact direct lorsque la maintenance nécessite du temps. Les pages de serveur dédié et de serveur de jeux revendiquent une réponse dans les cinq minutes par ticket, email, hotline ou chat en direct.

Ce sont des engagements utiles, mais ils décrivent plus l’accès et la réponse que la résolution. Un accusé de réception en cinq minutes peut confirmer l’existence d’un incident tandis que le remplacement matériel, le basculement de route ou la restauration de données prend des heures. Un calendrier de service sérieux nécessite des horloges séparées pour l’accusé de réception, l’engagement technique, la solution de contournement, la restauration et le rapport de cause profonde.

La gravité compte également. Un seul site web lent, un cluster de virtualisation entier indisponible, une suspicion d’exposition de données et une question de configuration de routine ne devraient pas partager une seule file d’attente. Les pages publiques ne divulguent pas les définitions de gravité, les rôles d’escalade, la couverture linguistique, le modèle de personnel, l’autorité après les heures ou les recours de crédit de service.

Le portail de support fournit une observation intrigante mais limitée. Au moment de l’accès, sabase de connaissanceset sazone de téléchargementaffichaient un avis générique indiquant qu’Ehost était conscient d’un problème pouvant affecter le service. Le détail de l’état du serveur lié n’était pas publiquement récupérable au moment de l’examen, de sorte que le service affecté, l’heure de début, la gravité, l’impact client et la résolution n’ont pas pu être établis. Ce n’est pas une preuve d’une panne matérielle. C’est une preuve qu’un mécanisme d’état existe mais n’a pas produit d’enregistrement d’incident public utilisable.

Aucun historique complet d’état public, archive post-incident ou série de disponibilité mesurée indépendamment n’a été localisé. L’absence d’archive publique ne signifie pas qu’Ehost n’a pas d’incidents ou d’enregistrements internes. Cela signifie qu’un acheteur doit les demander. Une diligence utile inclurait les douze mois précédents de disponibilité par produit et site, les comptes d’incidents de gravité un, les temps de réponse et de restauration médians, l’historique de maintenance, des exemples de rapports de cause profonde et des résultats de restauration de sauvegarde.

L’avis de maintenance devrait également être rendu mesurable. Combien de préavis est donné pour les travaux planifiés? Quelles actions d’urgence sont exemptées? La maintenance est-elle exclue des calculs de disponibilité? Le client peut-il reprogrammer? Ehost migre-t-il les machines virtuelles ou les arrête-t-il? Qu’advient-il d’un système d’exploitation non géré qui ne redémarre pas proprement?

Le fournisseur local le plus solide peut être précieux précisément parce qu’un acheteur peut joindre un humain qui connaît l’infrastructure. Cet avantage devient contractuel uniquement lorsque la personne a l’autorité, la file d’attente est surveillée, l’escalade est testée et l’obligation de restauration est claire.

La sécurité est plusieurs produits, pas un bouclier unique

Le langage de sécurité d’Ehost couvre les pare-feu physiques, l’isolation de l’hébergement partagé, l’AntiDDoS de base, la mitigation DDoS payante, les certificats SSL, les sauvegardes et le support. Ces contrôles traitent de menaces différentes et ne devraient pas être fondus en une affirmation générale qu’une charge de travail est « sécurisée ».

La page cloud indique que chaque cluster dispose d’un pare-feu physique et que les machines virtuelles peuvent être intégrées à Antiddos.vn. La page d’hébergement professionnel indique que l’AntiDDoS de base peut automatiquement activer la protection du pare-feu contre les botnets plus petits. Le siteAntiDDoSdécrit plusieurs nœuds proxy et pare-feu répartis dans des centres de données vietnamiens, filtrant les requêtes malveillantes et fournissant des fonctionnalités HTTP/2 et de pare-feu applicatif Web. Lacatégorie de commande AntiDDoSd’Ehost publie des étiquettes de plan et certains paramètres de volume de requêtes.

Ce sont des affirmations d’entreprise sur la conception du service, pas une validation indépendante de la capacité de mitigation. L’approvisionnement doit demander si la protection est toujours active ou activée après détection; si elle couvre les inondations de couche 3/4, les requêtes de couche 7 ou les deux; où le trafic est redirigé; quelle bande passante de nettoyage est engagée; si les IP sources sont conservées; comment les clés TLS sont traitées; ce qui arrive aux protocoles non-Web; si les attaques déclenchent des frais supplémentaires; et si l’origine reste joignable directement.

La preuve de ressources réseau ajoute une autre limite. Les préfixes valides RPKI aident à empêcher les origines de route non autorisées. Ils ne filtrent pas les requêtes d’application malveillantes, n’arrêtent pas le vol d’identifiants, ne corrigent pas un système d’exploitation client ou ne protègent pas une base de données d’un compte trop privilégié. Inversement, un proxy Web peut absorber les attaques HTTP tout en laissant les services de messagerie, VPN, jeu ou base de données exposés.

La sécurité des comptes est également sous-documentée. Le dossier public examiné ici n’établit pas si l’authentification multifacteur est obligatoire ou disponible pour chaque surface client et administrateur. Les acheteurs devraient tester l’AMF, la séparation des rôles, les identifiants API, la vérification d’identité du support, la journalisation des accès privilégiés et le départ plutôt que d’inférer la mise en œuvre à partir d’un langage de sécurité général.

La voie de signalement des abus est également peu claire. Les enregistrements dérivés d’APNIC identifient le responsable de la réponse aux incidents de VNNIC plutôt qu’un bureau de signalement des abus Ehost clairement annoncé, et le site principal expose des contacts commerciaux et de support plutôt qu’une politique d’abus dédiée. Cela ne prouve pas qu’Ehost manque de processus interne. Cela signifie qu’un rapporteur externe ou un client ne peut pas facilement vérifier la voie de signalement des logiciels malveillants, du spam, du phishing, des droits d’auteur ou des abus réseau.

Un fournisseur d’hébergement devrait pouvoir montrer la réception, l’authentification, la conservation des preuves, la notification au client, les normes de suspension et l’appel.

La base de données juridique officielle du Vietnam liste laLoi sur la protection des données personnelles 91/2025/QH15comme effective à partir du 1er janvier 2026. L’application de cette loi dépend des faits et doit être évaluée par un conseil qualifié. Pour les acheteurs d’Ehost, l’exigence pratique est simple: le contrat doit identifier les rôles de traitement, le support d’accès, la localisation des données, les sous-traitants, la coopération en cas d’incident, la rétention, la suppression et l’exportation pour le service réel.

Aucun package d’assurance sécurité public spécifique au produit n’a été localisé pour Ehost: pas de certificat ISO audité, de rapport SOC, de résumé de test de pénétration, de politique de divulgation des vulnérabilités, de liste de sous-traitants ou de nomenclature logicielle. C’est un manque de preuve, pas une preuve que ces contrôles n’existent pas. Cela devient conséquent lorsque le modèle de risque d’un acheteur exige plus que des affirmations de première partie.

L’avertissement de cycle de vie caché dans la vitrine

Le catalogue public contient des signes que les informations produits ont vieilli de manière inégale. Les pages d’hébergement partagé décrivent le support des versions PHP de 5.4 à 7.1 et MariaDB 10.1. Le portail de facturation liste séparément MultiPHP 5.5, 5.6 et 7.0 pour certains packages et PHP 7.0 avec MariaDB 10.1 pour une offre haute performance.

Ces versions ne sont pas actuelles. Le tableau des branches non supportées de PHP enregistre la fin de vie de PHP 5.4 en septembre 2015, PHP 7.0 en janvier 2019 et PHP 7.1 en décembre 2019. Le tableau de maintenance des versions de la MariaDB Foundation place la fin de maintenance de MariaDB 10.1 en octobre 2020.

L’interprétation responsable n’est pas qu’Ehost exécute définitivement des logiciels en fin de vie exposés en production. Les pages peuvent être obsolètes tandis que la plateforme a été mise à niveau. Cette distinction doit être testée. Les spécifications obsolètes sont elles-mêmes un problème de contrôle car les clients les utilisent pour juger de la compatibilité et de la sécurité de l’application.

Un acheteur Ehost devrait demander une matrice d’exécution actuelle pour chaque pool d’hébergement partagé: système d’exploitation, serveur web, panneau de contrôle, branches PHP, version de base de données, configuration TLS, cadence de correctifs et dates de dépréciation planifiées. Il devrait confirmer si les clients peuvent sélectionner des versions non supportées pour des applications héritées et, si oui, quelles conditions d’isolement et de risque s’appliquent.

Les panneaux de contrôle ajoutent une dépendance de cycle de vie à un tiers. Ehost vend deslicences DirectAdminet indique que certaines licences « internes » sont disponibles uniquement pour les serveurs hébergés chez Ehost, avec un paiement minimum de plusieurs mois. Un client qui combine le calcul Ehost, une licence fournie par Ehost, le DNS, les certificats et les sauvegardes peut bénéficier d’un support tout-en-un pratique. Cela crée également un ensemble qui doit être démêlé lors de la migration.

La référence de la page cloud aux processeurs Intel Broadwell fournit un autre indice daté, tandis que la page des serveurs dédiés annonce des configurations Xeon Gold et Platinum plus récentes et la catégorie de facturation C6 revendique des IOPS beaucoup plus élevées. Cela ressemble à de multiples générations d’infrastructure plutôt qu’à une flotte uniforme. C’est normal pour un hébergeur de longue date, mais la politique de placement est importante. L’acheteur devrait savoir si un plan correspond à une génération de CPU et une classe de stockage définies ou au pool ayant de la capacité.

La gouvernance du cycle de vie devrait couvrir plus que les versions. Elle devrait spécifier le préavis pour les migrations d’hôtes, les changements de panneau de contrôle, le retrait d’image de système d’exploitation, la fin de vie matérielle, la renumérotation IP, les changements de marque de certificat et les packages abandonnés. Le portail de support contient même une catégorie intitulée « EOL », bien que son contenu n’était pas disponible dans les preuves figées. Une politique de cycle de vie publiée permettrait aux clients de planifier au lieu de découvrir le retrait via un renouvellement ou un incident.

La concurrence teste Ehost sur les preuves, pas sur l’échelle

Ehost concurrence sur plusieurs marchés à la fois. En hébergement partagé, il fait face à des hébergeurs locaux et à des plateformes de sites web. En machines virtuelles, il fait face aux clouds des opérateurs télécoms vietnamiens, aux fournisseurs VPS spécialisés et aux hyperscalers mondiaux. En serveurs dédiés et colocation, il fait face aux opérateurs de centres de données, aux intégrateurs système et aux contrats directs d’installation. Pour la sauvegarde, le CDN et le DDoS, les clients peuvent acheter un service spécialisé indépendamment.

L’avantage le plus crédible d’Ehost n’est pas l’échelle mondiale. C’est la possibilité d’une relation opérationnelle locale: packages en VND, contact téléphonique et ticket direct, aide à la migration, installations vietnamiennes, ensembles simples et un seul fournisseur pour l’hébergement, le serveur, le rack et les services de protection. Une petite entreprise sans grande équipe d’infrastructure peut apprécier un fournisseur prêt à inspecter un système et à recommander une configuration pratique.

Le défi est que les alternatives nationales plus grandes publient un niveau d’assurance différent.VNPT Cloudannonce un SLA de 99,99 %, un support IPv6, un catalogue de services gérés plus large et des certifications de sécurité nommées. Ce sont les propres affirmations de VNPT, pas une preuve indépendante que chaque charge de travail fonctionnera mieux. Elles illustrent la comparaison d’approvisionnement qu’Ehost doit soutenir: quel niveau de service, capacité dual-stack, preuves de conformité, architecture et périmètre géré l’acheteur reçoit-il pour le prix?

Les hyperscalers mondiaux offrent des API, des régions et des services gérés que le catalogue public d’Ehost n’égale pas. Ils peuvent également introduire une exposition aux devises étrangères, une tarification complexe, un support distant et une architecture qu’un petit client a du mal à exploiter. Un serveur auto-géré en colocation offre un contrôle matériel maximal mais transfère les correctifs, les pièces détachées et la récupération au client. Une plateforme logicielle gérée peut éliminer l’administration du serveur mais augmenter le verrouillage au niveau de l’application.

Le bon test de concurrence est donc spécifique à la charge de travail:

• Pour un site vitrine, l’hébergement partagé peut être moins cher et plus simple qu’un cloud.
• Pour une application vietnamienne ayant besoin d’un support local prévisible, le cloud ou le matériel dédié Ehost peut être attrayant si la spécification du service est vérifiée.
• Pour une charge de travail réglementée, le périmètre d’assurance, le processus d’incident et les conditions de données peuvent l’emporter sur le prix d’appel.
• Pour une application distribuée mondialement, l’IPv6, les chemins internationaux, la mise à l’échelle automatique et la conception multi-région peuvent dominer le support local.
• Pour un jeu sensible à la latence, l’horloge CPU, la réponse DDoS, le peering domestique et la perte de paquets en cas d’attaque comptent plus qu’un branding « cloud » générique.

La seule discussion client indépendante ancienne trouvée dans le dossier public examiné, unfil de forum d’hébergement vietnamien, contient une anecdote favorable sur le service et le support d’Ehost. Elle date de plusieurs années, est informelle et non représentative. Le propre site d’Ehost publie également des témoignages positifs sans suffisamment de détails pour vérifier l’identité, le produit ou la date. Aucun ne devrait remplacer des références actuelles de clients exécutant une charge de travail comparable.

Ehost n’a pas besoin de prouver qu’il est le plus grand fournisseur. Il doit prouver que son modèle de service local donne à un client particulier plus de contrôle par dong que les alternatives réalistes.

Les coûts de changement s’accumulent une dépendance à la fois

L’infrastructure est souvent décrite comme portable car une machine virtuelle peut être copiée. En pratique, le coût du changement s’accumule en dehors de l’image machine.

La première couche estl’adressage. Une charge de travail utilisant une IPv4 assignée par Ehost peut devoir être renumérotée lorsqu’elle quitte. Le DNS peut cacher une partie du changement, mais les listes autorisées, les pairs VPN, les systèmes de paiement, la réputation de messagerie et les API tierces peuvent contenir l’ancienne adresse. Le propre espace d’adressage portable d’Ehost est visible, mais les conditions publiques ne disent pas si un client peut apporter ou transférer des ressources IP.

La deuxième couche estle stockage et la sauvegarde. Une image disque peut omettre les instantanés, les métadonnées d’objet, l’historique de sauvegarde ou les détails de chiffrement côté fournisseur. La page eStorage ne publie pas d’API d’exportation ou de calendrier de sortie. Une restauration qui ne fonctionne qu’à l’intérieur d’Ehost est une protection de continuité, pas une portabilité.

La troisième couche estle logiciel de contrôle. Les configurations cPanel ou DirectAdmin, les comptes de messagerie, les hiérarchies de revendeurs, les certificats et les tâches planifiées doivent être reconstruits ou convertis. Une licence interne liée à l’hébergement Ehost peut prendre fin lorsque le serveur déménage, nécessitant une nouvelle licence et peut-être une migration de panneau de contrôle.

La quatrième couche estla protection réseau. Si un domaine pointe via un proxy DDoS ou un CDN lié à Ehost, la sortie nécessite un changement DNS, une reconfiguration du certificat et de l’origine, l’exportation des journaux et un retrait soigneux de l’ancien chemin. La migration en cas d’attaque est particulièrement difficile car l’origine peut être exposée pendant la transition.

La cinquième couche estla connaissance opérationnelle. Le support Ehost peut savoir pourquoi un serveur utilise une route particulière, un noyau, une exception de pare-feu ou une disposition de stockage. Si cette connaissance réside dans des tickets plutôt que dans la documentation client, une relation de support réussie crée une dépendance.

La colocation a des coûts de sortie physiques. Le client a besoin d’un accès autorisé, d’une fenêtre de maintenance, d’emballage, de transport, de destruction des données pour les supports retirés et d’une nouvelle route. Si Ehost fournit l’espace IP ou les mains distantes, ces services prennent fin en même temps que la machine déménage.

Les preuves publiques ne fournissent pas de politique complète de résiliation, d’exportation ou de suppression. La page d’accueil d’Ehost indique qu’il existe une politique de remboursement lorsqu’un service n’est pas utilisé, et la FAQ d’hébergement personnel indique que la valeur non utilisée peut être créditée lors de la mise à niveau. La page de garantie traite du support et de la maintenance. Aucune de ces pages n’établit l’éligibilité au remboursement, le préavis de résiliation, la durée d’accès aux données, le format d’exportation, la preuve de suppression ou l’assistance à la transition pour tous les services.

Un calendrier de sortie devrait être convenu avant la mise en service. Il devrait donner au client des exportations et instantanés actuels; un accès en lecture suffisant; des procédures de transfert DNS et de domaine; un support de migration de boîte aux lettres; l’historique des tickets et des journaux le cas échéant; un calendrier pour la suppression de l’accès du fournisseur; une confirmation de suppression; des étapes de libération du matériel pour la colocation; et des frais prévisibles. Le client devrait répéter au moins une restauration ou une migration vers un autre environnement pendant que la relation est saine.

Un test d’achat correspondant à la surface réelle d’Ehost

Ehost devrait être évalué avec des preuves correspondant à ses affirmations et lacunes spécifiques, pas à un questionnaire cloud générique.

1. Réconcilier le dossier commercial

Demander à Ehost d’identifier le catalogue produit faisant autorité et d’expliquer les différences entre la page publique Cloud Server, le store SSD Cloud Server et le store C6. Exiger un calendrier de configuration signé. Faire de même pour les packages de colocation publique et du portail de facturation. Confirmer les taxes, l’engagement, le renouvellement, le remboursement, la restauration et les frais de mise à niveau.

2. Prouver la machine livrée

Pendant un essai, enregistrer le modèle CPU et le temps volé, la mémoire disponible, le disque utilisable, les IOPS soutenues et en rafale, la latence sous charge, le débit d’interface et le débit domestique et international. Effectuer des tests à plusieurs moments plutôt que de traiter un seul benchmark comme garantie. Comparer le résultat avec le bon de commande.

3. Cartographier les domaines de panne OpenStack

Demander la version OpenStack, l’hyperviseur, le backend de stockage, la conception des zones de disponibilité, la redondance du plan de contrôle et le processus de maintenance. Demander une défaillance contrôlée d’hôte de calcul ou un test récent documenté. Établir si le redémarrage d’instance, la récupération de volume et la restauration intersite sont des capacités distinctes.

4. Tester la route, pas la liste de centres de données

Confirmer quel ASN et quels préfixes le produit utilise, si les adresses sont de l’espace Ehost ou de l’installation, et si IPv6 est disponible. Demander comment AS135920 survit à la perte d’AS135905 et comment les routes changent lorsqu’AntiDDoS est activé. Tester depuis les principaux réseaux d’accès vietnamiens et depuis des localisations internationales. Enregistrer la perte de paquets et les changements de chemin pendant une maintenance ou un basculement simulé.

5. Transformer la sauvegarde en exercice de récupération

Résoudre le conflit de rétention cloud sept ou quatorze jours. Sélectionner une récupération de fichier, de base de données et de machine complète. Supprimer ou corrompre des données de test, puis mesurer le point de récupération, la réponse de l’opérateur, le temps de restauration, la cohérence résultante et les frais. Vérifier s’il existe une copie sur un site séparé ou hors ligne.

6. Définir le support par sévérité

Ouvrir des tickets via chaque canal promis. Confirmer que 24/7 signifie un répondant qualifié, pas seulement une réception. Contracter des objectifs distincts d’accusé de réception et de restauration, des contacts d’escalade, un préavis de maintenance et une remise de cause profonde. Obtenir les performances historiques pour le produit et le site acheté.

7. Inspecter les contrôles de sécurité et d’abus

Tester l’AMF, la séparation des rôles, la récupération de compte et les vérifications d’identité du support. Examiner la propriété des correctifs, l’isolation des locataires, la journalisation, la gestion des vulnérabilités, l’architecture DDoS et l’accès privilégié. Obtenir les politiques de confidentialité et de service réelles que le portail de support liste mais qui n’étaient pas publiquement récupérables dans cette recherche. Confirmer une voie de signalement des abus dédiée et un processus de traitement des preuves.

8. Vérifier le cycle de vie et la portabilité

Demander les versions logicielles supportées actuelles et les dates de dépréciation. Exporter une VM, une base de données, un ensemble de boîtes aux lettres, un compte de panneau de contrôle et une sauvegarde. Confirmer quelles licences prennent fin à la sortie. Si la colocation est impliquée, répéter l’accès physique autorisé et la libération de l’équipement.

Ce test n’exige pas une documentation d’hyperscaler d’un petit opérateur. Il demande à Ehost de soutenir les promesses qu’il fait déjà: ressources définies, haute disponibilité, sauvegardes, support rapide, plusieurs installations, sécurité et soin opérationnel local.

Les questions sans réponse font partie du produit

Le dossier public examiné établit plus que ce qui est souvent visible pour un hébergeur local. Il y a une entreprise exacte, des prix en direct, des systèmes de facturation et de support actifs, un large catalogue de services, un système autonome, cinq préfixes IPv4 routés, une couverture RPKI et des adresses répondant à Ho Chi Minh Ville. Il révèle également un fournisseur qui continue de publier du nouveau contenu 2026 et des offres plus récentes de serveurs dédiés ou C6.

Il n’établit pas de revenus audités, de part de marché, de nombre de clients, d’échelle de personnel, de propriété d’installations, de volume de trafic, de nombre de serveurs, de capacité de routage ou de disponibilité réelle. L’estimation de domaines hébergés d’IPinfo ne peut pas être convertie en clients car un client peut exploiter de nombreux domaines et un domaine peut n’utiliser qu’une partie du service d’Ehost. Un nombre de préfixes publics ne peut pas être converti en capacité de calcul.

Il n’établit pas que les installations « Tier 3 » nommées dans le marketing d’Ehost sont certifiées pour les racks et services exacts vendus, ou qu’Ehost possède les installations. Il n’établit pas de diversité physique ou de transporteur à partir d’une liste multisite. Il n’établit pas que chaque adresse couverte par RPKI reçoit une protection DDoS.

Il n’établit pas de SLA complet. Le chiffre public de 99,5 % manque d’un cadre de mesure et de recours visible, tandis que le libellé « disponibilité absolue » sur les serveurs dédiés n’est pas un substitut crédible à des termes limités. Aucun calendrier de remboursement complet n’était accessible.

Il n’établit pas de versions d’exécution actuelles. Les anciennes références PHP et MariaDB peuvent être une copie obsolète ou une compatibilité en direct; seul un inventaire de plateforme actuel peut les distinguer. Il n’établit pas de version ou topologie OpenStack.

Il n’établit pas d’isolation des sauvegardes, de performances de récupération ou de période de rétention faisant autorité. Il n’établit pas d’historique des incidents, même si le portail de support expose un mécanisme d’état et affichait un avis de problème générique. Il n’établit pas de certification de sécurité indépendante, de périmètre de test ou de gestion des abus.

Ce ne sont pas des raisons de déclarer l’entreprise inadaptée. Ce sont des dimensions du service qui restent privées, spécifiques au contrat ou non résolues. Pour un site web à faible risque, un client peut raisonnablement accepter moins de profondeur documentaire et se fier à une migration testée plus des sauvegardes indépendantes. Pour un système critique en revenus, réglementé ou sujet aux attaques, les mêmes lacunes deviennent des obstacles à l’achat jusqu’à ce qu’Ehost fournisse des preuves.

Ce qu’il faut surveiller ensuite

Cinq signaux amélioreraient matériellement la confiance dans la surface de contrôle d’Ehost.

Premièrement,la convergence du catalogue. Les pages produits publiques et le portail de facturation devraient décrire les mêmes packages, ou clairement marquer les générations et les dates. Supprimer les prix invraisemblables et les références d’exécution non supportées rendrait la vitrine fiable en tant que partie du service.

Deuxièmement,le développement réseau. La validité continue du RPKI est positive. L’annonce publique d’IPv6 et une conception upstream ou de peering démontrablement diversifiée réduiraient les questions sans réponse sur la joignabilité et le cycle de vie. Si Ehost choisit délibérément de garder un seul upstream public, il devrait expliquer le mécanisme de résilience derrière ce choix.

Troisièmement,la transparence opérationnelle. Une page d’état utilisable avec des horodatages d’incidents, des produits affectés, des mises à jour et une résolution transformerait le lien d’état existant en preuve. Des mesures périodiques de disponibilité et de restauration rendraient les affirmations de disponibilité et de sauvegarde testables.

Quatrièmement,la clôture des politiques. Le site d’Ehost renvoie vers des pages de confidentialité, de conditions d’utilisation, d’expédition et de garantie, et son portail de support liste un téléchargement de politique de services EHOST. Publier des conditions actuelles et accessibles pour les remboursements, l’utilisation acceptable, les abus, le traitement des données, le support, le SLA, la sauvegarde, la résiliation et la suppression réduirait les coûts de négociation pour les deux parties.

Cinquièmement,la discipline de cycle de vie. Une matrice logicielle actuelle, une politique de version OpenStack et un calendrier de préavis pour les pools matériels, les panneaux de contrôle et les produits en fin de vie montreraient qu’Ehost gère la longue traîne créée par un catalogue large.

Le réseau public d’Ehost n’est pas imaginaire. Cinq préfixes routés et une empreinte d’hébergement active sont plus convaincants qu’un mur de logos d’infrastructure non vérifiés. Mais une annonce de route n’est que la bordure extérieure du service. Le client dépend de la base de données de commandes, du système de provisionnement, de l’hyperviseur, du stockage, de l’installation, du transporteur, des files d’attente de support et du contrat qui se trouvent derrière.

C’est pourquoi les deux descriptions Cloud 1G à 250 000 dongs comptent. Elles exposent l’endroit exact où une relation d’hébergement peut devenir soit contrôlable, soit ambiguë. Si Ehost et l’acheteur peuvent réconcilier la spécification, prouver le chemin de routage et de récupération, attribuer la responsabilité en cas de défaillance et préserver une sortie, la largeur locale de l’entreprise peut être un avantage. Si ces questions restent dans des pages web incohérentes, le serveur le moins cher n’a pas encore acquis un prix fiable.