Der Vertrag vor der Cloud: Ehosts sichtbares Netzwerk und seine konkurrierenden Spezifikationen

Zusammenfassung

• EHOST SOFTWARE COMPANY LIMITED wird durch konsistente rechtliche, Kontakt- und Netzwerkkennungen gestützt: die Betriebsseitennamen Công ty TNHH Phần Mềm EHOST und Steuernummer 0312916711, während öffentliche Routing-Einträge AS135920 als EHOST-VN identifizieren und fünf originierte IPv4/24-Präfixe zeigen.
• Der Routing-Fußabdruck ist real, aber schmal. Die überprüften BGP-Quellen zeigen 1.280 originierte IPv4-Adressen, kein originierte IPv6-Space und eine beobachtete Upstream-Nachbarschaft über AS135905. Das beweist weder schlechten Service noch physisches Single-Homing, macht aber Fragen zur Routendiversität, Failover und produktspezifischen IPv6 relevant.
• Ehosts öffentliche Verkaufsoberflächen bieten keine einheitliche Produktspezifikation. Das gleiche 250.000-Dong-Cloud-1G-Label wird auf der Marketingseite und im Abrechnungsportal unterschiedlich beschrieben, und öffentliche versus Checkout-Colocation-Angebote weichen ebenfalls ab. Ein unterschriebenes Bestellformular muss daher die maßgeblichen CPU-, Arbeitsspeicher-, Speicher-, IOPS-, Bandbreiten-, Standort-, Backup- und Support-Bedingungen definieren.
• Backup-, Sicherheits- und Support-Behauptungen benötigen die gleiche Behandlung. Ehost bewirbt tägliche oder wöchentliche Backups, physische Firewalls, AntiDDoS, 24/7-Support und eine Fünf-Minuten-Antwort bei einigen Produkten, legt aber keinen vollständigen Wiederherstellungsplan, keine Schweregradmatrix, keinen Service-Guthabenplan, kein Vorfallarchiv, keinen Missbrauchsworkflow und keinen unabhängigen Prüfumfang offen.
• Der Anbieter könnte Kunden passen, die vietnamesische Abrechnung, direkten menschlichen Support, Migrationshilfe und ein Menü schätzen, das Shared Hosting, Cloud, dedizierte Server, Colocation, Backup und DDoS-Schutz umfasst. Käufer mit strengen Kontinuitäts-, Compliance- oder Portabilitätsanforderungen sollten einen Proof of Service durchführen und einen durchführbaren Ausstieg aushandeln, bevor sie die Produktion verlagern.

Ein 250.000-Dong-Server mit zwei Antworten

Beginnen wir mit dem kleinsten Ehost-Cloud-Paket. Auf der öffentlichenCloud Server-Seitekostet „EHOST 1G“ 250.000 vietnamesische Dong pro Monat und wird mit zwei CPU-Kernen, 2 GB RAM, 30 GB SSD-Speicher und einer 100-Mbps-Netzwerkverbindung beschrieben. Die Seite gibt an, dass alle Cloud-Tarife mindestens 2.000 Speicher-IOPS erhalten. Auf Ehosts Live-SSD-Cloud-Server-Bestellseitebeginnt „Cloud 1G“ ebenfalls bei 250.000 Dong pro Monat, aber die angezeigte Spezifikation ist ein CPU-Kern, 2 GB RAM, 20 GB SSD-Speicher, 200 Mbps Netzwerk und 10.000 IOPS.

Keine der Seiten ist obskur. Die eine ist die kundenorientierte Erklärung des Dienstes; die andere ist das System, über das ein Käufer eingeladen wird, ihn zu bestellen. Dennoch beschreiben sie wesentlich unterschiedliche Recheneinheiten. Die Diskrepanz beschränkt sich nicht auf den kleinsten Tarif. Das öffentliche Cloud 2G-Angebot listet zwei Kerne, 4 GB RAM und 40 GB Speicher; die Checkout-Version listet zwei Kerne, 2 GB RAM und 40 GB. Höhere Pakete unterscheiden sich ebenfalls in Arbeitsspeicher und Festplatte. Eine separate Abrechnungskategorie,SSD Cloud Server C6, präsentiert eine weitere Generation ähnlich benannter Tarife, darunter einen 350.000-Dong-Cloud-1G mit zwei Kernen, 2 GB RAM, 30 GB Speicher, 200 Mbps und 50.000 IOPS.

Das beweist nicht, dass Kunden falsch bereitgestellt werden. Ein Katalog kann eine veraltete Kategorie, einen neueren Hardware-Pool, eine veraltete Landingpage oder eine Konfiguration enthalten, die während des Verkaufs geklärt wird. Es beweist, dass die öffentliche Aufzeichnung die elementarste Beschaffungsfrage nicht beantworten kann: Welche Spezifikation wird zur Verpflichtung, wenn die Zahlung erfolgt?

Für einen Infrastrukturanbieter ist das kein geringfügiger Veröffentlichungsfehler. Die CPU-Zuteilung beeinflusst den Anwendungsdurchsatz. Der Arbeitsspeicher kann bestimmen, ob eine Datenbank resident bleibt oder auslagert. Die Festplattengröße beeinflusst die Migrationsdurchführ barkeit. IOPS können das Verhalten transaktionaler Workloads um eine Größenordnung verändern. Eine Netzwerkrate kann eine Portobergrenze, eine garantierte Rate, ein gemeinsames Profil oder eine Burst-Grenze sein. Jede Variation kann Leistung und Gesamtkosten verändern.

Die erste Kontrolle bei einem Ehost-Kauf sollte daher dokumentarisch sein. Das Angebot, das Bestellformular oder der Vertrag sollte die genaue Produktfamilie und -generation identifizieren; die Anzahl der vCPUs und das Scheduling-Modell; den garantierten Arbeitsspeicher; den nutzbaren Speicher; das Speichermedium; minimale und Burst-IOPS; die nationale und internationale Bandbreite; Übertragungslimits; die Zuweisung öffentlicher IPs; den Standort; das Betriebssystem-Image; den Verwaltungsumfang; den Backup-Einschluss; die Wiederherstellungsgebühr; Steuern; und die Verlängerungsbedingungen.

Der Käufer sollte dieses Dokument zusammen mit der Rechnung und den ersten Bereitstellungsnachweisen aufbewahren.

Die zentrale These dieser Überprüfung folgt aus diesen beiden Cloud 1G-Karten. Ehosts Infrastruktur wird nicht angemessen durch den Markennamen, den monatlichen Preis oder das Wort „Cloud“ beschrieben. Sein eigentliches Produkt beginnt dort, wo die Parteien die Verkaufsseite, das Abrechnungsportal und den tatsächlich gelieferten Dienst in Einklang bringen.

Das genaue Unternehmen hinter den Bildschirmen

Die Unternehmensgrenze ist ungewöhnlich wichtig, da „Ehost“ als Marke, Domain, Support-Portal, AntiDDoS-Dienst und registriertes Netzwerk auftritt. Das hier untersuchte Unternehmen istEHOST SOFTWARE COMPANY LIMITED, auf VietnamesischCông ty TNHH Phần Mềm Ehost, mit der Steuernummer0312916711. EhostsKontaktseitegibt den rechtlichen Namen, die Registernummer, eine Adresse in Ho-Chi-Minh-Stadt unter 147/25 An Dương Vương in Bình Tân, die Telefonnummer 0938-227-199 und eine@ehost.vn-Kontaktadresse an. Die Fußzeile gibt an, dass die Gewerbeanmeldung am 9. September 2014 ausgestellt wurde.

Einexterner vietnamesischer Steuerdaten-Aggregatorordnet der gleichen Steuernummer EHOST SOFTWARE COMPANY LIMITED, dieselbe Straßenadresse, ein Betriebsdatum vom 9. September 2014 und den Vertreter Nguyễn Thanh Tâm zu. Diese Aufzeichnung ist eine nützliche Bestätigung, kein Ersatz für einen aktuellen Auszug aus dem offiziellen Unternehmensregister Vietnams. Sein Status und seine Branchenklassifikationen sollten als datierte Wiedergabe öffentlicher Aufzeichnungen durch den Aggregator behandelt werden.

Die Netzwerkidentität liefert eine separate Kontinuitätsprüfung.BGP.toolsreproduziert APNIC-originierte Registrierungsdaten für AS135920:EHOST-VN, beschrieben als Ehost software company limited, Land Vietnam, verwaltet durch VNNIC. Der Datensatz wurde im Januar 2026 geändert.IPinfos AS135920-Seiteklassifiziert das Netzwerk ebenfalls als Hosting und ordnet es demselben Firmennamen zu.

Diese Verknüpfungen stützen eine ehrliche Schlussfolgerung: Die juristische Person, die aktiveehost.vn-Verkaufsoberfläche, diesecure.ehost.vn-Abrechnungs- und Supportoberfläche und AS135920 gehören zu einem einheitlichen Betriebsfußabdruck. Sie beweisen nicht, dass jeder auf jeder zugehörigen Domain beworbene Dienst dem Unternehmen gehört, betrieben oder garantiert wird. IPinfo listet beispielsweiseehost.com.vnals Domain der ASN, während die hier überprüfte aktuelle Betriebsseiteehost.vnist; erstere ergab während dieser Recherche keine nutzbare Seite. Das ist eine Frage der Domain-Kontinuität für das Unternehmen, kein Grund, Entitäten zu teilen oder zu verschmelzen.

Die gleiche Vorsicht gilt für AntiDDoS. Ehost verlinkt direkt aufAntiddos.vn, und seine Cloud-Seite sagt, dass Kunden in diesen Dienst integrieren können. Die AntiDDoS-Seite präsentiert sich als ein multi-node-vietnamesisches Mitigationsnetzwerk, gegründet 2015. Die hier geprüften öffentlichen Seiten legen keine separate Unternehmensidentität oder Vertragskette dar, die ausreicht, um zu bestimmen, ob Antiddos.vn eine Abteilung, ein Produkt, ein Partner oder ein kommerzieller Partner von EHOST SOFTWARE COMPANY LIMITED ist. Ein Käufer sollte die Vertragspartei ausdrücklich festlegen, anstatt sie aus Querverlinkungen abzuleiten.

Die genaue Identität ist im Fehlerfall wichtig. Die zahlungsempfangende Entität sollte die Entität sein, die zur Bereitstellung des Dienstes, zum Schutz der Daten, zur Meldung von Vorfällen, zur Rückgabe von Geräten oder Exporten und zur Zahlung von Rückerstattungen oder Serviceguthaben verpflichtet ist. Wenn ein Rechenzent rumsbetreiber, Software-Lizenzgeber, Mitigationsdienst oder Netzwerkbetreiber einen Teil des Dienstes erbringt, muss der Kunde wissen, ob Ehost für diese Abhängigkeit verantwortlich bleibt oder sie nur weiterverkauft.

Was AS135920 beweist — und was nicht

AS135920 ist der stärkste unabhängige Beweis dafür, dass Ehost mehr als eine Broschüre und eine Reseller-Storefront betreibt. In der eingefrorenen öffentlichen BGP-Ansicht originatiert das autonome System fünf IPv4/24-Präfixe:45.123.96.0/24,45.123.97.0/24,103.63.212.0/24,103.63.213.0/24und103.63.215.0/24. Das sind 1.280 IPv4-Adressen. SowohlBGP.toolsals auchIPinfozeigen die Präfixe als von gültigen Route Origin Authorisations abgedeckt. APNIC Labs’Tabelle zur Routen-Ursprungsvalidierung für Vietnammeldet 100 % gültige Abdeckung für die gemessene EHOST-VN-Adresspopulation.

Das ist ein aussagekräftiger operativer Nachweis. Ehost verfügt über Nummernressourcen, die im globalen Routing-System sichtbar sind. Mehrere Adressen antworten auf unabhängige Sonden, und IPinfo meldet Hunderte von Domains über Adressen in der ASN. Der Fußabdruck ist konsistent mit Hosting-Aktivitäten und nicht mit einer juristischen Hülle, die nur die Plattform eines anderen vermarktet.

RPKI-Gültigkeit ist auch eine echte Kontrolle. Sie ermöglicht es Routenvalidatoren, kryptografisch zu prüfen, ob AS135920 berechtigt ist, die abgedeckten Präfixe zu originieren. VNNICsInternetressourcenbericht 2024behandelt RPKI und IPv6 als wichtige Teile der Internetressourcenentwicklung Vietnams. Ehosts gültige Ursprungsautorisierungen verringern eine Klasse von Routenursprungsfehlern oder Hijack-Risiken.

Die Beweise enden dort. RPKI zeigt nicht, dass Ehost ungültige Routen von anderen filtert, Kundenanwendungen schützt, redundante Router unterhält oder einen Carrier-Ausfall überleben kann. Es sagt nichts über Verkehrsvolumen, Serverkapazität, Strom, Kühlung, DDoS-Scrubbing-Kapazität, Backup-Qualität oder Kundenzahl aus. Ein Fünf-Präfix-Ursprung kann ein gut geführtes spezialisiertes Hosting oder ein fragiles unterstützen; die Routingtabelle entscheidet nicht zwischen ihnen.

Die sichtbare Konnektivität ist eher warnend. BGP.tools listet einen Upstream, AS135905, beschrieben als Vietnam P&T. Die unabhängigeCIDR Report-Ansichtsieht ebenfalls eine Upstream-Nachbarschaft und keinen Downstream-Adressraum. IPinfo listet ebenfalls einen Upstream und einen Peer, beide AS135905. Beziehungsbezeichnungen variieren je nach Datenquelle, aber die konsistente Beobachtung ist ein extern sichtbares angrenzendes Netzwerk, das AS135920s Routen in den überprüften Ansichten trägt.

Dies sollte nicht in die Behauptung übersetzt werden, dass jedes Ehost-Rack ein physisches Kabel hat oder dass jedes Produkt Single-Homed ist. Ehost bewirbt Colocation an mehreren Rechenzentrumsmarken und verwendet möglicherweise vom Anbieter zugewiesene Adressen, private Interconnects, Layer-2-Dienste, entfernte DDoS-Mitigation oder Routen, die nicht als separate AS-Nachbarschaften sichtbar sind. Öffentliche BGP-Collectoren können auch private oder selektive Beziehungen übersehen.

Es schafft jedoch einen Beschaffungstest. Wenn ein Dienst als Multi-Carrier- oder Multi-Rechenzentrum verkauft wird, sollte Ehost zeigen, wie der Kundenverkehr den Verlust von AS135905, des relevanten Border-Routers, des bedienenden Standorts und des Pfades zur Mitigationsplattform übersteht. Die Beweise könnten ein Architekturdiagramm, aktuelle BGP-Sitzungen, Routenrichtlinien, Looking-Glass-Ergebnisse, Failover-Aufzeichnungen und einen kontrollierten Test umfassen. „Mehrere Rechenzentren“ ist eine Standortaussage; „diverse Internet-Erreichbarkeit“ ist eine Routing-Aussage. Eine liefert nicht automatisch die andere.

IPv6 ist die andere sichtbare Lücke. Die überprüften Routing-Quellen zeigennull originierte IPv6-Präfixefür AS135920. Das beweist nicht, dass Ehost nirgendwo IPv6 anbietet: Ein Kunde könnte IPv6 von einer Einrichtung oder einer vorgelagerten ASN erhalten. Es bedeutet, dass ein Käufer nicht auf natives Dual-Stack-Service aus Ehosts eigenem autonomen System schließen kann. Produktspezifische Fragen sollten die IPv6-Zuordnungsgröße, das Routing, Reverse DNS, Firewalling, DDoS-Handling, Überwachung und Parität mit IPv4-Support abdecken. Im Jahr 2026 ist „wir können es später hinzufügen“ eine Lebenszyklusverpflichtung, keine technische Antwort.

Ein Katalog verschiedener Verantwortungsmodelle

Ehost verkauft nicht ein einziges Infrastrukturmodell. Sein öffentliches Menü umfasst Shared Hosting, E-Mail-Hosting, virtuelle Maschinen, dedizierte Server, Gameserver, Colocation, Backup, objektähnlichen Speicher, Caching, CDN-Vermittlung, Control-Panel-Lizenzen, Zertifikate und DDoS-Schutz. Jedes verschiebt einen anderen Teil des Betriebsstapels zwischen Anbieter und Kunde.

Impersönlichen Shared Hostingstellt die Plattform laut Ehost cPanel, SSL, SSD-Speicher, eine grundlegende AntiDDoS-Schicht und wöchentliche Backups bereit. Der Kunde verwaltet hauptsächlich Website-Code, Inhalte, Konten und Anwendungsupdates, während er für den gemeinsam genutzten Server, das Control Panel, das Netzwerk und die Isolierung von Ehost abhängig ist. DieBusiness-Hosting-Seitefügt eine dedizierte öffentliche IP, Redis-Caching und Behauptungen der Ressourcentrennung hinzu. Das ist ein Dienst mit höherer Kontrolle, der nicht mit einem virtuellen Server gleichzusetzen ist.

Cloud verschiebt mehr Verantwortung auf den Kunden. Ehosts öffentliche Seite sagt, dass es OpenStack verwendet, eine virtuelle Maschine bereitstellt, dem Kunden erlaubt, CPU, Arbeitsspeicher und Festplatte hinzuzufügen, und den Server während eines Upgrades für zwei bis fünf Minuten stoppen kann. Sofern kein separater Managed-Service-Vertrag gilt, sollte der Käufer davon ausgehen, dass Härtung des Betriebssystems, Anwendungs-Patching, Datenbankbetrieb, Identitätsmanagement und Workload-Überwachung weiterhin in der Verantwortung des Kunden liegen.

Die öffentlichen Seiten kennzeichnen die Standard-Cloud-Tarife nicht eindeutig als verwaltet oder unverwaltet.

Dedizierte Server verlagern die Hardware-Exklusivität auf den Käufer, aber nicht unbedingt das Eigentum an der Hardware. EhostsDedicated-Server-Seite von 2026listet monatliche Konfigurationen von 5,5 Millionen bis 12 Millionen Dong, mit Intel Xeon-Prozessoren, 128 oder 256 GB RAM, SSD- oder NVMe-Speicher, einer IP-Adresse und 100 oder 200 Mbps Bandbreite. Der Käufer vermeidet Compute-Konflikte durch laute Nachbarn, bleibt aber für die Maschine, das Rack, den Strom, den Carrier-Pfad, die Remote-Hands und den Austauschprozess von Ehost abhängig.

Colocation ist wieder anders. Der Kunde besitzt oder kontrolliert den physischen Server und mietet Rack-Platz, Strom und Konnektivität. Ehost sagt, dass Kunden nach Voranmeldung rund um die Uhr das Rechenzentrum betreten und Remote-KVM nutzen können. In diesem Modell hat Ehost möglicherweise weniger Kontrolle über den Server und mehr Verantwortung für die Zugangskoordination, Strom, Cross-Connects, Routing und praktische Unterstützung. Eine Fehlermatrix muss Kundenhardware, Einrichtungsinfrastruktur, Ehost-Netzwerk und vorgelagerten Carrier trennen.

DieECDN-Seitesagt, dass Ehost mit vietnamesischen und internationalen CDN-Anbietern zusammenarbeitet, anstatt ein vollständig eigenes Zustellnetzwerk zu beschreiben. Das kann kommerziell nützlich sein: Ehost kann als lokaler Integrator und Abrechnungskontakt fungieren. Es bedeutet auch, dass Cache-Standorte, Protokolle, Löschverhalten, Datenhandhabung, Vorfallverantwortung und Ausstieg vom ungenannten zugrunde liegenden Anbieter und der auftragsspezifischen Gestaltung abhängen.

DieeStorage-Seitebeschreibt „vStorage“ als eine von Ehost entwickelte Objektspeicher-Technologie für Medien, Dokumente, Protokolle und statische Inhalte und sagt, dass Daten dauerhaft gespeichert und immer gesichert werden. Die Seite veröffentlicht keine API-Spezif ikation, kein Konsistenzmodell, kein Haltbarkeitsziel, kein Erasure-Coding- oder Replikationsschema, kein Löschverhalten, keine Regionskarte, keinen Ausgangspreis und kein Service-Level. „Objektspeicher“ identifiziert eine Dienstklasse, nicht genug Architektur für eine Entscheidung über dauerhafte Daten.

Ehosts Breite ist daher sowohl ein Vorteil als auch eine Sorgfaltspflicht. Ein Kunde kann mehrere benachbarte Dienste von einem lokalen Anbieter kaufen und die Anbieterkoordination reduzieren. Aber die Verantwortungsgrenze ändert sich jedes Mal, wenn der Kunde von Shared Hosting zu Cloud, von Cloud zu dedizierter Hardware oder von einem Ehost-eigenen Netzwerk zu einem Drittanbieter-CDN oder Rechenzentrumspfad wechselt.

OpenStack ist eine Komponentenliste, kein Verfügbarkeitsergebnis

Ehost sagt, dass seine virtuellen Maschinen auf OpenStack laufen. Das ist technisch spezifisch genug, um nützlich zu sein, aber nicht spezifisch genug, um Resilienz zu etablieren. Der offizielleOpenStack Logical Architecture Guidebeschreibt eine Cloud als eine Reihe unabhängiger Dienste, die über APIs und einen gemeinsamen Identitätsdienst verbunden sind. Hinter den Schnittstellen stehen Datenbanken, Message Queues und Dienstprozesse für Compute, Netzwerk, Images und Speicher. OpenStack ist ein Betriebsrahmen, dessen Ergebnis davon abhängt, wie diese Teile bereitgestellt und gewartet werden.

Für einen Käufer ist die erste Frage, welche OpenStack-Version und Dienstgruppe Ehost betreibt. Die Antwort betrifft Support-Status, Upgrades, Treiber, Sicherheitsfixes und API-Verhalten. Die öffentliche Produktseite identifiziert weder die Version, den Compute-Hypervisor, das Speicher-Backend, das Netzwerk-Design, die Verfügbarkeitszonen, die Live-Migrationsrichtlinie noch die kundenzugängliche API.

Die zweite Frage ist die Fehlereindämmung. OpenStacks eigeneHigh-Availability-Design-Anleitungunterscheidet die Datenebene, die Instanzen, Netzwerke und Speicher am Laufen hält, von der Kontrollebene, die Verwaltungsoperationen durchführt. Sie betont redundante Dienste, Lastenausgleicher, Datenbanken, Message Queues, Switches, Routen und Strom. Die einfache Installation von OpenStack eliminiert keine Single Points of Failure; Betreiber müssen sie wegdimensionalieren.

Ehost sagt, dass seine Cloud Hochverfügbarkeit verwendet und einen Server auf ein anderes System wiederherstellen kann. Das ist eine Unternehmensbehauptung über ein Ergebnis. Um sie zu beurteilen, sollte ein Käufer fragen, was bei mehreren separaten Fehlern passiert:

• Wenn ein Compute-Host ausfällt, startet die virtuelle Maschine automatisch neu, und wie lange dauern Erkennung und Neustart?
• Wenn gemeinsam genutzter Speicher ausfällt, werden Volumes über unabhängige Fehlerdomänen repliziert oder nur durch RAID in einem System geschützt?
• Wenn ein Controller oder eine Message Queue ausfällt, laufen bestehende Maschinen weiter, während Verwaltungsoperationen pausieren?
• Wenn ein Top-of-Rack- oder Core-Switch ausfällt, gibt es einen physisch diversen Pfad?
• Wenn ein Standort ausfällt, kann ein Kunde an einem anderen Standort aus einer unabhängigen Kopie wiederhergestellt werden?
• Wenn das OpenStack-Upgrade selbst fehlschlägt, was ist der Rollback- und Kundenbenachrichtigungsprozess?

Diese Fragen sind wichtig, weil die öffentliche Behauptung von 99,5 % Betriebszeit relativ nachsichtig ist. Kontinuierlich angewendet erlaubt 99,5 % Verfügbarkeit etwa 3 Stunden und 36 Minuten Ausfallzeit in einem 30-Tage-Monat oder etwa 43 Stunden und 48 Minuten in einem 365-Tage-Jahr. Diese Berechnung ist keine Aussage über Ehosts tatsächliche Leistung. Sie zeigt, warum der Messzeitraum, Ausschlüsse, Wartungsbehandlung, Überwachungsquelle und Abhilfe genauso wichtig sind wie der Prozentsatz.

Es gibt auch ein Upgrade-Signal im Produkttext. Ehost sagt, dass das Ändern von CPU, Arbeitsspeicher, Festplatte oder Netzwerk eine zwei- bis fünfminütige Abschaltung erfordern kann. Das deutet darauf hin, dass zumindest einige Größenänderungen eine Unterbrechung und kein transparenter Live-Vorgang sind. Ein Kunde, der vertikale Skalierung während Spitzenzeiten plant, sollte dies testen und fragen, ob Speichererweiterung, Instanz-Flavor- Änderungen und Host-Wartung dem gleichen Pfad folgen.

Die nützliche Schlussfolgerung ist weder „OpenStack ist unzuverlässig“ noch „OpenStack garantiert Cloud“. Es ist, dass Ehost ein plausibles technisches Fundament genannt hat, während die Bereitstellungsentscheidungen, die das Kundenrisiko bestimmen, weitgehend außerhalb der öffentlichen Aufzeichnung bleiben.

Die Customer Journey durchläuft drei Kontrollebenen

Ein Ehost-Kunde bewegt sich durch drei verschiedene Kontrollebenen: kommerziell, Infrastruktur und Anwendung. Probleme treten oft dort auf, wo die Verantwortung zwischen ihnen übergeht.

Die kommerzielle Reise beginnt aufEhosts Hauptseite, wo Produktseiten Pakete und monatliche Preise präsentieren. Ehost sagt, dass es nach der Registrierung eine Bestätigung und Kostenmitteilung sendet und der Dienst nach Zahlung erstellt wird. Der Kunde erreicht dannsecure.ehost.vn, ein Abrechnungs- und Support-System mit Produktkategorien, Anzeigeoptionen in VND und US-Dollar, einem Konto, Bestellformularen, Tickets, Ankündigungen, Downloads und einem Server-Status-Link.

Der Spezifikationskonflikt macht die Übergabe wichtig. Vor der Zahlung sollte der Käufer die ausgewählte Bestellkonfiguration erfassen und eine schriftliche Bestätigung erhalten, dass sie widersprüchliche Webkopien ersetzt. Nach der Bereitstellung sollte der Kunde aufzeichnen, was tatsächlich angekommen ist: virtuelle CPU-Anzahl, Arbeitsspeicher, Festplatte, öffentliche IP, Route, Schnittstellengeschwindigkeit, Betriebssystem, Control-Panel-Lizenz und Backup-Status. Ein kurzes Akzeptanzskript kann die gelieferte Maschine mit der Bestellung vergleichen.

Die Infrastrukturreise beginnt dann. Für einen Cloud-Server stellt Ehost Compute, Speicher und Netzwerk bereit; der Kunde installiert oder erhält ein Betriebssystem, erstellt Administrator-Anmeldeinformationen, weist DNS zu und stellt eine Anwendung bereit. Für Shared Hosting stellt Ehost ein Control Panel zur Verfügung, und der Kunde verschiebt Site-Dateien, Datenbanken, Zertifikate und Mail-Einstellungen. Für Colocation muss der Kunde den Einrichtungszugang, die Rack-Installation, die Stromversorgung, die IP-Adressierung und die Fernverwaltung arrangieren.

Migration ist nicht eine Aufgabe. Ehosts Hauptseite bewirbt kostenlose Beratung und Datenübertragungsunterstützung für Kunden, die seine Dienste nutzen. Eine Produktionsmigration erfordert dennoch ein Quellinventar, eine Datenkopie, eine DNS-Strategie, eine Zertifikatsverwaltung, einen Mail-Flow-Test, ein Anwendungs-Freeze-Fenster, eine Integritätsprüfung und einen Rollback. Wenn sich IP-Adressen ändern, müssen möglicherweise Whitelists, Zahlungsanbieter, Drittanbieter-APIs und Sicherheitsregeln aktualisiert werden. Wenn E-Mail umzieht, werden Sender-Reputation und DNS-Einträge wie SPF, DKIM und DMARC Teil der Akzeptanz.

Die Anwendungs-Kontrollebene bleibt weitgehend in der Hand des Kunden. Eine virtuelle Maschine kann gesund sein, während die Anwendung aufgrund einer fehlgeschlagenen Bereitstellung, einer vollen Festplatte, eines abgelaufenen Zertifikats oder einer Datenbanksperre ausgefallen ist. Ehosts Wissensdatenbank enthält Artikel über volle Festplatten und Zertifikatsfehler, was nützlicher Support-Inhalt ist, aber auch die gemeinsame Grenze verdeutlicht: Der Anbieter kann ein Symptom erklären, ohne jede Workload-Entscheidung zu besitzen.

Der Betrieb sollte daher benannte Verantwortlichkeiten zuweisen. Ehost kann physische Hardware, Virtualisierung, Edge-Netzwerk und Plattform-Backups besitzen. Der Kunde kann Betriebssysteme, Anwendungen, Konten und Datenklassifikation besitzen. Ein Dritter kann die Control-Panel-Lizenz, das CDN, die Zertifizierungsstelle, die Domain-Registrierung oder das DDoS-Scrubbing besitzen. Während eines Vorfalls muss das Ticket die Partei erreichen, die tatsächlich handeln kann.

Der letzte kommerzielle Schritt ist die Verlängerung oder der Ausstieg. Öffentliche Seiten zeigen monatliche Preise, aber einige Produkte erfordern Mindestlaufzeiten von mehreren Monaten. Das Abrechnungsportal zeigt für einige Hosting-Angebote Zeiträume von drei Monaten, während DirectAdmin-Lizenzen mit einer Mindestlaufzeit von sechs Monaten angezeigt werden. Käufer sollten einen monatlichen Stückpreis nicht mit einem monatlichen Kündigungsrecht verwechseln.

Der Preis ist erst transparent, wenn die Spezifikation stabil ist

Ehost veröffentlicht mehr Preise als viele Infrastrukturanbieter. Das ist nützlich. Ein kleines Unternehmen kann sehen, dass Shared Hosting bei 50.000 Dong pro Monat beginnt, Business Hosting bei 300.000, Cloud bei 250.000, Backup bei 95.000, dedizierte Server bei 5,5 Millionen und Colocation auf der öffentlichen Seite bei 1,8 Millionen. Add-ons haben sichtbare Preise: zusätzliche Cloud-CPU, Arbeitsspeicher, Festplatte und IPv4; zusätzlicher Hosting-Speicher, Domain oder IP; Rack-Platz, Strom- und Netzwerk-Upgrades.

Die Zahlen offenbaren Ehosts wirtschaftliches Design. Shared Hosting verteilt einen Server und Support-Betrieb auf viele Kunden. Cloud-Pakete messen ein Bündel aus Compute, Arbeitsspeicher, Speicher und Netzwerkkapazität. Dedizierte Server berechnen exklusive Hardware. Colocation berechnet knappen Rack-Platz, Strom und Konnektivität. Backup wird hauptsächlich nach gespeicherter Kapazität berechnet. Lizenzen und Zertifikate fügen Software oder Vertrauensdienste von Drittanbietern hinzu.

Dennoch ist der veröffentlichte Preis nicht dasselbe wie ein verlässlicher Preis. DieBusiness-Hosting-Bestellkategorieenthält eine auffällige Anomalie: „Business-02“ wird mit 1,35 Milliarden Dong für drei Monate angezeigt, während nahegelegene Pakete in den Hunderttausenden liegen. Dieselbe Seite bewirbt veraltete PHP- und MariaDB-Versionen. Es wäre unvernünftig, den Milliarden-Dong-Betrag ohne Bestätigung als Ehosts beabsichtigten Tarif zu behandeln; es ist besser als Beweis dafür zu verstehen, dass die Storefront Inkonsistenzen in der Dateneingabe oder im Lebenszyklus enthalten kann.

Colocation zeigt ein breiteres Abstimmungsproblem. Die öffentlicheColocation-Seitelistet 1U-Pakete bei VNPT Data, Viettel IDC und CMC für 3,2 Millionen, 2,8 Millionen und 1,8 Millionen Dong pro Monat, in der Regel mit 200 Mbps nationalem Netzwerk und 30 Mbps geteilter internationaler Bandbreite. DieColocation-Kategorie des Abrechnungsportalslistet ODS, Viettel IDC und VNPT Tân Thuận zu 1,3 Millionen oder 1,4 Millionen Dong, mit 100 Mbps Ports und vier oder zehn Mbps internationaler Bandbreite. Die Standorte, Kapazitäten und Preise sind nicht gleichwertig.

Es mag eine legitime Erklärung geben: verschiedene Rack-Generationen, Aktionen, Stromzuteilungen, Verpflichtungszeiträume, Legacy-Angebote oder Wege zum Markt. Die Seiten liefern sie nicht. Ein Käufer, der nur die monatliche Kopfzahl vergleicht, könnte daher eine andere Dienstklasse kaufen als die angenommene.

Die Gesamtkosten sollten mindestens Folgendes umfassen:

• anfängliche Migration, Betriebssystem-Setup und Anwendungsvalidierung;
• Mehrwertsteuer und alle anderen anfallenden Gebühren;
• Mindestlaufzeit und Verlängerungsbedingungen;
• öffentliche IPv4, Bandbreite, internationaler Verkehr und DDoS-Optionen;
• Control-Panel-, Windows-, Datenbank- oder andere Softwarelizenzen;
• Backup-Kapazität, Aufbewahrung und Wiederherstellungsgebühren;
• Managed Support oder Remote-Hands-Arbeit;
• Hardware-Austausch oder Upgrade-Ausfallzeiten;
• Domain-, Zertifikats- und E-Mail-Abhängigkeiten;
• Datenexport, - übertragung und Übergangsunterstützung beim Ausstieg.

„Unbegrenzte Bandbreite“ benötigt ebenfalls eine Definition. Mehrere Ehost-Seiten verwenden den Begriff, während sie separat Port-Raten oder internationale Bandbreite veröffentlichen. Unbegrenzt kann vernünftigerweise bedeuten, dass keine nutzungsabhängigen Übertragungsgebühren anfallen, nicht unendlicher Durchsatz oder eine dedizierte, nicht umkämpfte Leitung. Der Vertrag sollte zwischen Portgeschwindigkeit, garantierter Informationsrate, Burst-Verhalten, Fair-Use-Richtlinie und nationalen versus internationalen Pfaden unterscheiden.

Ehost kann nach Klärung aller Bedingungen immer noch preislich wettbewerbsfähig sein. Die öffentliche Aufzeichnung reicht nicht aus, um Marge, Überbuchung oder Kostenvergleiche mit Wettbewerbern zu berechnen. Sie reicht aus, um zu zeigen, dass der Preisvergleich nach der Produktabstimmung beginnen muss, nicht davor.

Backup ist ein Versprechen mit zwei Aufbewahrungsfristen

Backup ist der Bereich, in dem Ehosts öffentliches Material am nützlichsten und widersprüchlichsten ist. Die Cloud-Seite sagt zunächst, dass die gesamte Cloud täglich gesichert wird und Kopien mindestens sieben Tage aufbewahrt werden. In den Plannotizen heißt es, dass „Full Backup Daily“ die letzten vierzehn Tage aufbewahrt und 500.000 Dong pro Wiederherstellung verlangt. Beide Aussagen erscheinen auf derselben Seite.

Shared Hosting folgt einer anderen Richtlinie. Die persönlichen und geschäftlichen Seiten sagen, dass Daten in Echtzeit dreifach gespeichert und wöchentlich gesichert werden, wobei Backups zwei Monate lang aufbewahrt werden. Ein separaterCloud Backup-Dienstverkauft Speicher von 10 GB bis 100 GB und sagt, dass er eine ganze Festplatte sichern kann, sodass ein Betriebssystem und Anwendungen auf Ersatzhardware verschoben werden können. Er bewirbt 24/7/365 technischen Support und monatliche Zahlung.

Dies können verschiedene Schichten sein: Plattformreplikation, im Dienst enthaltener Backup und kundengekaufter Backup. Sie sollten unterschiedlich sein. Echtzeit-Dreifachspeicherung kann vor einem Festplattenausfall schützen, während sie gleichzeitig die Löschung oder Ransomware-verschlüsselten Daten eines Kunden sofort reproduziert. Ein Plattform-Snapshot kann Ehost helfen, die Infrastruktur wiederherzustellen, während er für eine granulare Kundenwiederherstellung ungeeignet ist. Ein kostenpflichtiger Backup-Dienst kann separate Aufbewahrung und Isolierung haben. Die aktuellen Seiten geben keine einzige Karte dieser Schichten.

OpenStacks eigeneBackup- und Wiederherstellungsanleitungmacht die fehlenden Fragen klar: Die Backup-Häufigkeit sollte dem akzeptablen Datenverlust folgen; Aufbewahrung und Off-Site-Speicher sind wichtig; und Wiederherstellungstests sind genauso wichtig wie die Existenz von Kopien. Ehosts öffentliche Behauptungen offenbaren nicht den Backup-Standort, die Unveränderlichkeit, die Verschlüsselung, die administrative Trennung, die Löschrichtlinie, das Wiederherstellungszeit-Ziel oder die Testergebnisse.

Ein Käufer sollte „Backup inklusive“ in einen Zeitplan umwandeln:

1. Umfang:Boot-Volume, angehängte Volumes, Datenbanken, Objektspeicher, Control-Panel-Konfiguration, Postfächer und kundenverwaltete Schlüssel.
2. Wiederherstellungspunkt:die maximalen Daten, die bei jedem Dienst verloren gehen können.
3. Wiederherstellungszeit:wann Ehost mit der Arbeit beginnt und wann eine nutzbare Workload zurück sein muss.
4. Aufbewahrung:genaue Anzahl wiederherstellbarer Kopien und wie das Alter berechnet wird.
5. Isolierung:ob Kopien eine Kompromittierung des Produktionskontos, Clusters oder Standorts überleben.
6. Wiederherstellungsmethode:Ganzmaschinen-, Datei-, Datenbank- und Alternativort-Wiederherstellung.
7. Gebühren:inkludierte Wiederherstellungen, Notfallgebühren und Datenausgangskosten.
8. Nachweise:geplante Kundenwiederherstellungstests mit aufgezeichneten Ergebnissen.

Der Konflikt zwischen sieben und vierzehn Tagen sollte im Vertrag gelöst werden, aber das tiefere Problem ist die Verantwortung. Wenn die Anwendung eines Kunden kritische Daten generiert, sollte ein Ehost-Backup nicht die einzige Kopie sein, die über dasselbe Konto und denselben Anbieter gesteuert wird. Der Kunde benötigt einen unabhängigen Export- oder Replikationspfad, dessen Anmeldeinformationen und Fehlerdomäne sich von der Produktion unterscheiden.

Fünf-Minuten-Antwort ist nicht fünf Minuten Wiederherstellung

Ehosts Support-Oberfläche ist sichtbar. Die Hauptseite bietet Telefon- und E-Mail-Kontakte; das Support-Portal bietet Tickets, eine Wissensdatenbank, Ankündigungen, Downloads und Server-Status. DieService-Garantieseitesagt, dass der Support 24/7 arbeitet und Kunden per E-Mail, Telefon oder direkt kontaktiert werden, wenn Wartung Zeit in Anspruch nimmt. Die Dedicated-Server- und Gameserver-Seiten behaupten eine Antwort innerhalb von fünf Minuten per Ticket, E-Mail, Hotline oder Live-Chat.

Dies sind nützliche Verpflichtungen, aber sie beschreiben Zugang und Antwort mehr als Lösung. Eine Fünf-Minuten-Bestätigung kann bestätigen, dass ein Vorfall existiert, während der Hardware-Austausch, das Route-Failover oder die Datenwiederherstellung Stunden dauert. Ein ernsthafter Service-Zeitplan benötigt separate Uhren für Bestätigung, technische Einschaltung, Workaround, Wiederherstellung und Ursachenbericht.

Der Schweregrad ist ebenfalls wichtig. Eine einzelne langsame Website, ein nicht verfügbarer gesamter Virtualisierungscluster, ein vermuteter Datenverlust und eine Routine-Konfigurationsfrage sollten sich nicht eine Warteschlange teilen. Die öffentlichen Seiten legen keine Schweregraddefinitionen, Eskalationsrollen, Sprachabdeckung, Personalmodell, Bereitschaftsbefugnisse oder Service-Guthaben-Abhilfen offen.

Das Support-Portal bietet eine interessante, aber begrenzte Beobachtung. Zum Zeitpunkt des Zugriffs zeigten sowohl seineWissensdatenbankals auch seinDownload-Bereicheinen generischen Hinweis, dass Ehost ein Problem bekannt sei, das den Dienst beeinträchtigen könnte. Das verlinkte Server-Status-Detail war zum Zeitpunkt der Überprüfung nicht öffentlich abrufbar, sodass der betroffene Dienst, die Startzeit, der Schweregrad, die Kundenauswirkung und die Lösung nicht festgestellt werden konnten. Dies ist kein Nachweis eines materiellen Ausfalls. Es ist ein Nachweis dafür, dass ein Statusmechanismus existiert, aber keinen nutzbaren öffentlichen Vorfallsdatensatz lieferte.

Es wurde kein umfassender öffentlicher Statusverlauf, kein Vorfallarchiv und keine unabhängig gemessene Betriebszeitreihe gefunden. Das Fehlen eines öffentlichen Archivs bedeutet nicht, dass Ehost keine Vorfälle oder keine internen Aufzeichnungen hat. Es bedeutet, dass ein Käufer sie anfordern muss. Eine nützliche Sorgfalt würde die letzten zwölf Monate Verfügbarkeit nach Produkt und Standort, die Anzahl der Vorfälle der Schweregrade eins, die mediane Antwort- und Wiederherstellungszeit, den Wartungsverlauf, Beispiel-Ursachenberichte und Backup-Wiederherstellungsergebnisse umfassen.

Die Wartungsbenachrichtigung sollte ebenfalls messbar gemacht werden. Wie viel Vorankündigung wird für geplante Arbeiten gegeben? Welche Notfallmaßnahmen sind ausgenommen? Ist die Wartung von der Betriebszeitberechnung ausgeschlossen? Kann ein Kunde verschieben? Migriert Ehost virtuelle Maschinen oder fährt sie herunter? Was passiert mit einem nicht verwalteten Betriebssystem, das sich nicht sauber erholt?

Der stärkste lokale Anbieter kann gerade deshalb wertvoll sein, weil ein Käufer einen Menschen erreichen kann, der die Infrastruktur kennt. Dieser Vorteil wird vertraglich erst dann wirksam, wenn die Person Autorität hat, die Warteschlange überwacht wird, die Eskalation getestet ist und die Wiederherstellungsverpflichtung klar ist.

Sicherheit ist mehrere Produkte, nicht ein Schild

Ehosts Sicherheitssprache umfasst physische Firewalls, Shared-Hosting-Isolierung, grundlegendes AntiDDoS, bezahlte DDoS-Mitigation, SSL-Zertifikate, Backups und Support. Diese Kontrollen adressieren unterschiedliche Bedrohungen und sollten nicht zu einer allgemeinen Behauptung zusammengefasst werden, dass eine Workload „sicher“ ist.

Die Cloud-Seite sagt, dass jeder Cluster eine physische Firewall hat und dass virtuelle Maschinen in Antiddos.vn integriert werden können. Die Business-Hosting-Seite sagt, dass grundlegendes AntiDDoS automatisch Firewall-Schutz gegen kleinere Botnets aktivieren kann. DieAntiDDoS-Seitebeschreibt mehrere Proxy- und Firewall-Knoten über vietnamesische Rechenzentrumsmarken hinweg, die bösartige Anfragen filtern und HTTP/2- und Web-Application-Firewall-Funktionen bereitstellen. EhostsAntiDDoS-Bestellkategorieveröffentlicht Planbezeichnungen und einige Anfragevolumenparameter.

Dies sind Unternehmensbehauptungen über das Servicedesign, keine unabhängige Validierung der Mitigationskapazität. Die Beschaffung sollte fragen, ob der Schutz immer eingeschaltet oder nach Erkennung aktiviert wird; ob er Layer-3/4-Floods, Layer-7-Anfragen oder beides abdeckt; wohin der Verkehr umgeleitet wird; welche saubere Bandbreite garantiert wird; ob Quell-IPs erhalten bleiben; wie TLS-Schlüssel behandelt werden; was mit Nicht-Web-Protokollen passiert; ob Angriffe zusätzliche Gebühren auslösen; und ob der Ursprung direkt erreichbar bleibt.

Die Netzwerkressourcen-Nachweise fügen eine weitere Grenze hinzu. RPKI-gültige Präfixe helfen, unbefugte Routenursprünge zu verhindern. Sie filtern keine bösartigen Anwendungsanfragen, stoppen keinen Diebstahl von Anmeldeinformationen, patchen kein Kundenbetriebssystem und schützen keine Datenbank vor einem überprivilegierten Konto. Umgekehrt kann ein Web-Proxy HTTP-Angriffe absorbieren, während Mail-, VPN-, Spiel- oder Datenbankdienste ungeschützt bleiben.

Die Kontosicherheit ist ebenfalls unterdokumentiert. Die hier überprüfte öffentliche Aufzeichnung stellt nicht fest, ob die Multi-Faktor-Authentifizierung für jede Kunden- und Administrationsoberfläche obligatorisch oder verfügbar ist. Käufer sollten MFA, Rollentrennung, API-Anmeldeinformationen, Support-Identitätsüberprüfung, privilegierte Zugriffsprotokollierung und Offboarding testen, anstatt die Implementierung aus allgemeinen Sicherheitsformulierungen abzuleiten.

Der Missbrauchspfad ist ähnlich unklar. APNIC-abgeleitete Aufzeichnungen identifizieren VNNICs Incident-Response-Maintainer anstelle einer klar beworbenen Ehost-Missbrauchsstelle, und die Hauptseite zeigt Verkaufs- und Support-Kontakte anstelle einer dedizierten Missbrauchsrichtlinie. Das beweist nicht, dass Ehost keinen internen Prozess hat. Es bedeutet, dass ein externer Melder oder Kunde den Weg für Malware, Spam, Phishing, Urheberrechts- oder Netzwerkmissbrauch nicht einfach überprüfen kann.

Ein Hosting-Anbieter sollte in der Lage sein, Aufnahme, Authentifizierung, Beweiserhaltung, Kundenbenachrichtigung, Sperrstandards und Berufung zu zeigen.

Vietnams offizielle Rechtsdatenbank listet dasGesetz zum Schutz personenbezogener Daten 91/2025/QH15als wirksam ab dem 1. Januar 2026. Die Anwendung dieses Gesetzes hängt von den Tatsachen ab und sollte von qualifizierten Rechtsberatern beurteilt werden. Für Ehost-Käufer ist die praktische Anforderung einfach: Der Vertrag muss Verarbeitungsrollen, Support-Zugriff, Datenstandort, Unterauftragsverarbeiter, Vorfallkooperation, Aufbewahrung, Löschung und Export für den tatsächlichen Dienst identifizieren.

Es wurde kein öffentliches, produktspezifisches Sicherheits-Assurance-Paket für Ehost gefunden: kein ISO-Zertifikat, kein SOC-Bericht, keine Penetrationstest-Zusammenfassung, keine Richtlinie zur Offenlegung von Schwachstellen, keine Unterauftragsverarbeiterliste und keine Software-Stückliste. Dies ist eine Evidenzlücke, kein Beweis dafür, dass diese Kontrollen nicht existieren. Sie wird folgenreich, wenn das Risikomodell eines Käufers mehr als Behauptungen erster Partei erfordert.

Der Lebenszyklus-Warnhinweis im Storefront

Der öffentliche Katalog enthält Anzeichen dafür, dass Produktinformationen ungleichmäßig gealtert sind. Die Shared-Hosting-Seiten beschreiben Unterstützung für PHP-Versionen von 5.4 bis 7.1 und MariaDB 10.1. Das Abrechnungsportal listet separat MultiPHP 5.5, 5.6 und 7.0 für einige Pakete und PHP 7.0 mit MariaDB 10.1 für ein Hochleistungsangebot.

Diese Versionen sind nicht aktuell. Die offizielleTabelle der nicht unterstützten Zweige von PHPverzeichnet das Ende der Lebensdauer für PHP 5.4 im September 2015, PHP 7.0 im Januar 2019 und PHP 7.1 im Dezember 2019. DieRelease-Wartungstabelle der MariaDB Foundationsetzt das Wartungsende von MariaDB 10.1 auf Oktober 2020.

Die verantwortungsvolle Interpretation ist nicht, dass Ehost definitiv exponierte Software am Ende ihrer Lebensdauer in der Produktion betreibt. Die Seiten können veraltet sein, während die Plattform aktualisiert wurde. Diese Unterscheidung muss getestet werden. Veraltete Spezifikationen sind selbst ein Kontrollproblem, da Kunden sie verwenden, um die Anwendungskompatibilität und Sicherheit zu beurteilen.

Ein Ehost-Käufer sollte eine aktuelle Laufzeitmatrix für jeden Shared-Hosting-Pool anfordern: Betriebssystem, Webserver, Control Panel, PHP-Zweige, Datenbankversion, TLS-Konfiguration, Patch-Rhythmus und geplante Abkündigungsdaten. Er sollte bestätigen, ob Kunden nicht unterstützte Versionen für Legacy-Anwendungen auswählen können und, falls ja, welche Isolierungs- und Risikobedingungen gelten.

Control Panels fügen eine Lebenszyklusabhängigkeit von Drittanbietern hinzu. Ehost verkauftDirectAdmin-Lizenzenund sagt, dass einige „interne“ Lizenzen nur für Server verfügbar sind, die bei Ehost gehostet werden, mit einer Mindestlaufzeit von mehreren Monaten. Ein Kunde, der Ehost Compute, eine von Ehost bereitgestellte Lizenz, DNS, Zertifikate und Backups kombiniert, er möglicherweise praktischen One-Stop-Support. Es schafft auch ein Bündel, das während der Migration entwirrt werden muss.

Der Verweis auf Intel-Broadwell-Prozessoren auf der Cloud-Seite liefert einen weiteren datierten Hinweis, während die Dedicated-Server-Seite neuere Xeon Gold- und Platinum-Konfigurationen bewirbt und die C6-Abrechnungskategorie viel höhere IOPS behauptet. Dies sieht nach mehreren Infrastrukturgenerationen aus, nicht nach einer einheitlichen Flotte. Das ist für einen langlebigen Host normal, aber die Platzierungspolitik ist wichtig. Der Käufer sollte wissen, ob ein Tarif auf eine definierte CPU-Generation und Speicherklasse abbildet oder auf den Pool mit verfügbarer Kapazität.

Die Lebenszyklus-Governance sollte mehr als Versionen abdecken. Sie sollte die Ankündigung für Host-Migrationen, Control-Panel-Änderungen, die Ausmusterung von Betriebssystem-Images, das Ende der Hardware-Lebensdauer, die IP-Nummerierung, Änderungen der Zertifikatsmarke und eingestellte Pakete spezifizieren. Das Support-Portal enthält sogar eine Kategorie mit der Bezeichnung „EOL“, obwohl ihr Inhalt in den eingefrorenen Beweisen nicht verfügbar war. Eine veröffentliche Lebenszyklus-Richtlinie würde es Kunden ermöglichen, zu planen, anstatt die Ausmusterung durch eine Verlängerung oder einen Vorfall zu entdecken.

Der Wettbewerb testet Ehost anhand von Beweisen, nicht der Größe

Ehost konkurriert gleichzeitig in mehreren Märkten. Im Shared Hosting steht es lokalen Hosts und Website-Plattformen gegenüber. Bei virtuellen Maschinen steht es vietnamesischen Telco-Clouds, spezialisierten VPS-Anbietern und globalen Hyperscalern gegenüber. Bei dedizierten Servern und Colocation steht es Rechenzentrumsbetreibern, Systemintegratoren und direkten Einrichtungsverträgen gegenüber. Für Backup, CDN und DDoS können Kunden einen spezialisierten Dienst unabhängig kaufen.

Der glaubwürdigste Vorteil von Ehost ist nicht die globale Größe. Es ist die Möglichkeit einer lokalen Betriebsbeziehung: in VND denominierten Pakete, direkter Telefon- und Ticketkontakt, Migrationshilfe, vietnamesische Einrichtungen, einfache Bündel und ein Lieferant für Hosting, Server, Rack und Schutzdienste. Ein kleines Unternehmen ohne großes Infrastrukturteam könnte einen Anbieter schätzen, der bereit ist, ein System zu inspizieren und eine praktische Konfiguration zu empfehlen.

Die Herausforderung besteht darin, dass größere inländische Alternativen ein anderes Maß an Sicherheit veröffentlichen.VNPT Cloudbewirbt eine SLA von 99,99%, IPv6-Unterstützung, einen breiteren Managed-Service-Katalog und genannte Sicherheitszertifizierungen. Dies sind VNPTs eigene Behauptungen, kein unabhängiger Beweis dafür, dass jede Workload besser abschneidet. Sie veranschaulichen den Beschaffungsvergleich, den Ehost erfüllen muss: welches Service-Level, welche Dual-Stack-Fähigkeit, welche Compliance-Nachweise, welche Architektur und welcher verwaltete Umfang erhält der Käufer für den Preis?

Globale Hyperscaler bieten APIs, Regionen und Managed Services, die Ehosts öffentlicher Katalog nicht bietet. Sie können auch Fremdwährungsrisiko, komplexe Preisgestaltung, entfernten Support und eine Architektur einführen, die ein kleiner Kunde nur schwer betreiben kann. Ein selbstverwalteter Server in Colocation bietet maximale Hardware-Kontrolle, überträgt aber Patchen, Ersatzteile und Wiederherstellung auf den Kunden. Eine verwaltete Softwareplattform kann die Serververwaltung eliminieren, aber die Anwendungsbindung erhöhen.

Der richtige Wettbewerbstest ist daher workload-spezifisch:

• Für eine Werbeseite kann Shared Hosting günstiger und einfacher sein als jede Cloud.
• Für eine vietnamesische Anwendung, die vorhersagbaren lokalen Support benötigt, kann Ehosts Cloud oder dedizierte Hardware attraktiv sein, wenn die Dienstspezifikation verifiziert ist.
• Für eine regulierte Workload können der Assurance-Umfang, der Vorfallsprozess und die Datenbedingungen den Listenpreis überwiegen.
• Für eine global verteilte Anwendung können IPv6, internationale Pfade, automatische Skalierung und Multi-Region-Design den lokalen Support dominieren.
• Für einen latenzempfindlichen Spieleserver sind CPU-Takt, DDoS-Antwort, nationales Peering und Paketverlust während Angriffen wichtiger als generisches „Cloud“-Branding.

Die einzige alte unabhängige Kundendiskussion, die in der überprüften öffentlichen Aufzeichnung gefunden wurde, einvietnamesisches Hosting-Forum-Thread, enthält eine positive Anekdote über Ehost-Service und Support. Sie ist Jahre alt, informell und nicht repräsentativ. Ehosts eigene Seite veröffentlicht auch positive Testimonials ohne genügend Details, um Identität, Produkt oder Datum zu überprüfen. Keines sollte aktuelle Referenzen von Kunden ersetzen, die eine vergleichbare Workload betreiben.

Ehost muss nicht beweisen, dass es der größte Anbieter ist. Es muss beweisen, dass sein lokales Servicemodell einem bestimmten Kunden mehr Kontrolle pro Dong gibt als die realistischen Alternativen.

Wechselkosten entstehen eine Abhängigkeit nach der anderen

Infrastruktur wird oft als portabel beschrieben, weil eine virtuelle Maschine kopiert werden kann. In der Praxis entstehen Wechselkosten außerhalb des Maschinen-Images.

Die erste Schicht istAdressierung. Eine Workload, die eine von Ehost zugewiesene IPv4 verwendet, muss möglicherweise umnummeriert werden, wenn sie geht. DNS kann einen Teil der Änderung verbergen, aber Whitelists, VPN-Peers, Zahlungssysteme, Mail-Reputation und Drittanbieter-APIs können die alte Adresse enthalten. Ehosts eigener portabler Adressraum ist sichtbar, aber die öffentlichen Bedingungen sagen nicht, ob ein Kunde IP-Ressourcen mitbringen oder übertragen kann.

Die zweite Schicht istSpeicher und Backup. Ein Festplatten-Image kann Snapshots, Objekt-Metadaten, Backup-Verlauf oder anbieterseitige Verschlüsselungsdetails auslassen. Die eStorage-Seite veröffentlicht keine Export-API oder Ausgangsplan. Eine Wiederherstellung, die nur innerhalb von Ehost funktioniert, ist Kontinuitätsschutz, nicht Portabilität.

Die dritte Schicht istSteuersoftware. cPanel- oder DirectAdmin-Konfigurationen, Mail-Konten, Reseller-Hierarchien, Zertifikate und geplante Jobs müssen rekonstruiert oder konvertiert werden. Eine interne Lizenz, die an Ehost-Hosting gebunden ist, kann enden, wenn der Server umzieht, was eine neue Lizenz und möglicherweise eine Control-Panel-Migration erfordert.

Die vierte Schicht istNetzwerkschutz. Wenn eine Domain über einen mit Ehost verbundenen DDoS-Proxy oder ein CDN zeigt, erfordert der Ausstieg DNS-Änderungen, Zertifikats- und Ursprungskonfiguration, Log-Export und sorgfältige Entfernung des alten Pfades. Eine Migration während eines Angriffs ist besonders schwierig, da der Ursprung während des Übergangs exponiert sein kann.

Die fünfte Schicht istbetriebliches Wissen. Der Ehost-Support weiß möglicherweise, warum ein Server eine bestimmte Route, einen Kernel, eine Firewall-Ausnahme oder ein Speicher-Layout verwendet. Wenn dieses Wissen in Tickets und nicht in Kundendokumentation lebt, schafft eine erfolgreiche Support-Beziehung Abhängigkeit.

Colocation hat physische Ausstiegskosten. Der Kunde benötigt autorisierten Zugang, ein Wartungsfenster, Verpackung, Transport, Datenvernichtung für ausgemusterte Medien und eine neue Route. Wenn Ehost IP-Raum oder Remote-Hands bereitstellt, enden diese Dienste gleichzeitig mit dem Umzug der Maschine.

Die öffentlichen Beweise liefern keine vollständige Kündigungs-, Export- oder Löschrichtlinie. Ehosts Homepage sagt, dass es eine Rückerstattungsrichtlinie gibt, wenn ein Dienst nicht genutzt wird, und das Personal-Hosting-FAQ sagt, dass ungenutzter Wert beim Upgrade gutgeschrieben werden kann. Die Garantieseite behandelt Support- und Wartungsmitteilungen. Keine dieser Seiten etabliert Rückerstattungsberechtigung, Kündigungsfrist, Datenzugriffsdauer, Exportformat, Löschungsnachweise oder Übergangshilfe für alle Dienste.

Ein Ausstiegsplan sollte vor dem Go-Live vereinbart werden. Er sollte dem Kunden aktuelle Exporte und Snapshots; ausreichenden Lesezugang; DNS- und Domain-Transferverfahren; Mailbox-Migrationsunterstützung; Log- und Ticket-Verlauf, wo relevant; einen Zeitplan für die Entfernung des Anbieterzugangs; Löschbestätigung; Hardware-Freigabeschritte für Colocation; und vorhersehbare Gebühren geben. Der Kunde sollte mindestens eine Wiederherstellung oder Migration in eine andere Umgebung proben, solange die Beziehung gesund ist.

Ein Beschaffungstest, der Ehosts tatsächlicher Oberfläche entspricht

Ehost sollte mit Beweisen bewertet werden, die seinen spezifischen Behauptungen und Lücken entsprechen, nicht einem generischen Cloud-Fragebogen.

1. Den kommerziellen Datensatz abgleichen

Bitten Sie Ehost, den maßgeblichen Produktkatalog zu identifizieren und die Unterschiede zwischen der öffentlichen Cloud Server-Seite, dem SSD Cloud Server-Store und dem C6-Store zu erklären. Fordern Sie einen unterschriebenen Konfigurationsplan an. Machen Sie dasselbe für öffentliche und Abrechnungsportal-Colocation-Pakete. Bestätigen Sie Steuern, Verpflichtung, Verlängerung, Rückerstattung, Wiederherstellungs- und Upgrade-Gebühren.

2. Die gelieferte Maschine nachweisen

Zeichnen Sie während eines Tests CPU-Modell und Steal-Zeit, verfügbaren Arbeitsspeicher, nutzbare Festplatte, anhaltende und Burst-IOPS, Latenz unter Last, Schnittstellengeschwindigkeit sowie nationale und internationale Durchsätze auf. Führen Sie Tests zu mehreren Zeiten durch, anstatt einen Benchmark als Garantie zu behandeln. Vergleichen Sie das Ergebnis mit dem Bestellformular.

3. Die OpenStack-Fehlerdomänen kartieren

Fordern Sie die OpenStack-Version, den Hypervisor, das Speicher-Backend, das Verfügbarkeitszonen-Design, die Kontrollebenen-Redundanz und den Wartungsprozess an. Bitten Sie um einen kontrollierten Compute-Host-Ausfall oder einen dokumentierten aktuellen Test. Stellen Sie fest, ob Instanz-Neustart, Volume-Wiederherstellung und standortübergreifende Wiederherstellung separate Fähigkeiten sind.

4. Die Route testen, nicht die Rechenzentrumsliste

Bestätigen Sie, welche ASN und Präfixe das Produkt verwendet, ob Adressen Ehost- oder Einrichtungsraum sind und ob IPv6 verfügbar ist. Fragen Sie, wie AS135920 den Verlust von AS135905 übersteht und wie sich Routen ändern, wenn AntiDDoS aktiviert wird. Testen Sie von großen vietnamesischen Zugangsnetzen und von internationalen Standorten. Zeichnen Sie Paketverlust und Pfadänderungen während einer Wartung oder eines simulierten Failovers auf.

5. Backup in eine Wiederherstellungsübung umwandeln

Lösen Sie den Cloud-Aufbewahrungskonflikt zwischen sieben und vierzehn Tagen. Wählen Sie eine Datei-, Datenbank- und Ganzmaschinen-Wiederherstellung aus. Löschen oder beschädigen Sie Testdaten, messen Sie dann den Wiederherstellungspunkt, die Betreiberreaktion, die Wiederherstellungszeit, die resultierende Konsistenz und die Gebühr. Überprüfen Sie, ob eine externe oder Offline-Kopie existiert.

6. Support nach Schweregrad definieren

Eröffnen Sie Tickets über jeden versprochenen Kanal. Bestätigen Sie, dass 24/7 einen qualifizierten Antwortgeber bedeutet, nicht nur Annahme. Vertraglich separate Bestätigungs- und Wiederherstellungsziele, Eskalationskontakte, Wartungsmitteilung und Ursachenlieferung. Holen Sie historische Leistungsdaten für das Produkt und den Standort ein, die gekauft werden.

7. Sicherheits- und Missbrauchskontrollen inspizieren

Testen Sie MFA, Rollentrennung, Konto-Wiederherstellung und Support-Identitätsprüfungen. Überprüfen Sie Patch-Eigentümerschaft, Mandantenisolierung, Protokollierung, Schwachstellenmanagement, DDoS-Architektur und privilegierten Zugriff. Holen Sie die tatsächlichen Datenschutz- und Service-Richtlinien ein, die das Support-Portal auflistet, die aber bei dieser Recherche nicht öffentlich abrufbar waren. Bestätigen Sie einen dedizierten Missbrauchsweg und einen Beweishandhabungsprozess.

8. Lebenszyklus und Portabilität verifizieren

Fragen Sie nach aktuell unterstützten Softwareversionen und Abkündigungsdaten. Exportieren Sie eine VM, eine Datenbank, einen Postfachsatz, ein Control-Panel-Konto und Backups. Bestätigen Sie, welche Lizenzen beim Ausstieg enden. Wenn Colocation beteiligt ist, proben Sie den autorisierten physischen Zugang und die Gerätefreigabe.

Dieser Test verlangt keine Hyperscaler-Dokumentation von einem kleinen Betreiber. Er bittet Ehost, die Versprechen zu untermauern, die es bereits macht: definierte Ressourcen, Hochverfügbarkeit, Backups, schnellen Support, mehrere Einrichtungen, Sicherheit und lokale Betriebsfürsorge.

Die unbeantworteten Fragen sind Teil des Produkts

Die überprüfte öffentliche Aufzeichnung stellt mehr fest, als für einen lokalen Host oft sichtbar ist. Es gibt ein genaues Unternehmen, Live-Preise, aktive Support- und Abrechnungssysteme, einen breiten Servicekatalog, ein autonomes System, fünf geroutete IPv4-Präfixe, RPKI-Abdeckung und antwortende Adressen in Ho-Chi-Minh-Stadt. Sie zeigt auch einen Anbieter, der weiterhin neue 2026-Inhalte und neuere Dedicated-Server- oder C6-Angebote veröffentlicht.

Sie stellt keine geprüften Einnahmen, keinen Marktanteil, keine Kundenzahl, kein Personal, keinen Einrichtungsbesitz, kein Verkehrsvolumen, keine Serveranzahl, keine Routenkapazität und keine tatsächliche Betriebszeit fest. IPinfos Schätzung gehosteter Domains kann nicht in Kunden umgewandelt werden, da ein Kunde viele Domains betreiben kann und eine Domain nur einen Teil von Ehosts Dienst nutzen kann. Eine öffentliche Präfixanzahl kann nicht in Rechenkapazität umgewandelt werden.

Sie stellt nicht fest, dass die in Ehost-Marketing genannten „Tier 3“-Einrichtungen für die genauen Racks und Dienste zertifiziert sind, die verkauft werden, oder dass Ehost die Einrichtungen besitzt. Sie stellt keine physische oder Carrier-Diversität aus einer Multi-Site-Liste fest. Sie stellt nicht fest, dass jede RPKI-gedeckte Adresse DDoS-Schutz erhält.

Sie stellt keine vollständige SLA fest. Die öffentliche 99,5%-Zahl enthält keinen sichtbaren Mess- und Abhilferahmen, während „absolute Betriebszeit“-Formulierungen auf dedizierten Servern kein glaubwürdiger Ersatz für begrenzte Bedingungen sind. Es war kein vollständiger Rückerstattungsplan zugänglich.

Sie stellt keine aktuellen Laufzeitversionen fest. Die alten PHP- und MariaDB-Verweise können veraltete Kopie oder Live-Kompatibilität sein; nur ein aktuelles Plattform-Inventar kann sie unterscheiden. Sie stellt keine OpenStack-Version oder Topologie fest.

Sie stellt keine Backup-Isolierung, Wiederherstellungsleistung oder eine maßgebliche Aufbewahrungsfrist fest. Sie stellt keine Vorfallhistorie fest, obwohl das Support-Portal einen Statusmechanismus offenlegt und einen generischen Problemhinweis anzeigte. Sie stellt keine unabhängige Sicherheitszertifizierung, keinen Testumfang und keine Missbrauchsbehandlung fest.

Dies sind keine Gründe, das Unternehmen als ungeeignet zu erklären. Sie sind Dimensionen des Dienstes, die privat, vertragsspezifisch oder ungelöst bleiben. Für eine Low-Risk-Website kann ein Kunde vernünftigerweise weniger dokumentarische Tiefe akzeptieren und sich auf einen getesteten Migrations- und unabhängige Backups verlassen. Für ein umsatz-, regulierungs- oder angriffsanfälliges System werden dieselben Lücken zu Beschaffungsblockern, bis Ehost Beweise liefert.

Was als nächstes zu beobachten ist

Fünf Signale würden das Vertrauen in Ehosts Kontrolloberfläche wesentlich verbessern.

Erstens,Katalogkonvergenz. Die öffentlichen Produktseiten und das Abrechnungsportal sollten dieselben Pakete beschreiben oder Generationen und Daten klar kennzeichnen. Die Entfernung unrealistischer Preise und nicht unterstützter Laufzeitverweise würde die Storefront zu einem zuverlässigen Teil des Dienstes machen.

Zweitens,Netzwerkentwicklung. Fortgesetzte RPKI-Gültigkeit ist positiv. Eine öffentliche IPv6-Originierung und ein nachweislich diverser Upstream- oder Peering-Design würden unbeantwortete Fragen zur Erreichbarkeit und zum Lebenszyklus reduzieren. Wenn Ehost absichtlich einen öffentlichen Upstream beibehält, sollte es den Resilienzmechanismus hinter dieser Wahl erklären.

Drittens,betriebliche Transparenz. Eine nutzbare Statusseite mit Vorfallzeitstempeln, betroffenen Produkten, Updates und Lösung würde den bestehenden Status-Link in Beweise verwandeln. Zeitnahe Verfügbarkeits- und Wiederherstellungsmetriken würden die Betriebszeit- und Backup-Behauptungen testbar machen.

Viertens,Richtlinienabschluss. Ehosts Seite verlinkt Datenschutz-, Nutzungs-, Versand- und Garantieseiten, und sein Support-Portal listet einen Download der EHOST-Dienstrichtlinien auf. Die Veröffentlichung aktueller, zugänglicher Bedingungen für Rückerstattungen, akzeptable Nutzung, Missbrauch, Datenverarbeitung, Support, SLA, Backup, Kündigung und Löschung würde die Verhandlungskosten für beide Seiten senken.

Fünftens,Lebenszyklus-Disziplin. Eine aktuelle Software-Matrix, eine OpenStack-Release-Richtlinie und ein Ankündigungsplan für Hardware-Pools, Control Panels und Produkte am Ende der Lebensdauer würden zeigen, dass Ehost den langen Schwanz verwaltet, der durch einen breiten Katalog entsteht.

Ehosts öffentliches Netzwerk ist nicht imaginär. Fünf geroutete Präfixe und ein aktiver Hosting-Fußabdruck sind überzeugender als eine Wand unbewiesener Infrastrukturlogos. Aber eine Routenankündigung ist nur die äußere Kante des Dienstes. Der Kunde ist abhängig von der Bestelldatenbank, dem Bereitstellungssystem, dem Hypervisor, dem Speicher, der Einrichtung, dem Carrier, dem Backup, der Support-Warteschlange und dem Vertrag, die dahinter stehen.

Deshalb sind die beiden 250.000-Dong-Cloud-1G-Beschreibungen wichtig. Sie legen die genaue Stelle offen, an der eine Hosting-Beziehung entweder kontrollierbar oder mehrdeutig werden kann. Wenn Ehost und der Käufer die Spezifikation abgleichen, die Route und den Wiederherstellungspfad nachweisen, die Verantwortung im Fehlerfall zuweisen und einen Ausstieg bewahren können, kann die lokale Breite des Unternehmens ein Vorteil sein. Wenn diese Fragen in inkonsistenten Webseiten verbleiben, hat der günstigste Server noch keinen verlässlichen Preis erhalten.