Summary

  • EHOST SOFTWARE COMPANY LIMITED is supported by consistent legal, contact and network identifiers: the operating site names Công ty TNHH Phần Mềm EHOST and tax code 0312916711, while public routing records identify AS135920 as EHOST-VN and show five originated IPv4/24prefixes.
  • The routing footprint is real but narrow. The reviewed BGP sources show 1,280 originated IPv4 addresses, no originated IPv6 space and one observed upstream adjacency through AS135905. That proves neither poor service nor physical single-homing, but it makes route diversity, failover and product-specific IPv6 questions material.
  • Ehost’s public sales surfaces do not provide one stable product specification. The same 250,000-dong Cloud 1G label is described differently on the marketing page and billing portal, and public versus checkout colocation offers also diverge. A signed order form must therefore define the authoritative CPU, memory, storage, IOPS, bandwidth, location, backup and support terms.
  • Backup, security and support claims need the same treatment. Ehost advertises daily or weekly backups, physical firewalls, AntiDDoS, 24/7 support and a five-minute response on some products, but it does not publicly disclose a complete recovery design, severity matrix, service-credit schedule, incident archive, abuse workflow or independent assurance scope.
  • The provider may fit customers that value Vietnamese billing, direct human support, migration help and a menu spanning shared hosting, cloud, dedicated servers, colocation, backup and DDoS protection. Buyers with strict continuity, compliance or portability requirements should run a proof of service and negotiate an executable exit before moving production.

A 250,000-dong server with two answers

Start with the smallest Ehost cloud package. On the publicCloud Server page, “EHOST 1G” costs 250,000 Vietnamese dong a month and is described as two CPU cores, 2 GB of RAM, 30 GB of SSD storage and a 100 Mbps network connection. The page says all cloud plans receive at least 2,000 storage IOPS. On Ehost’s liveSSD Cloud Server ordering page, “Cloud 1G” also starts at 250,000 dong a month, but the displayed specification is one CPU core, 2 GB of RAM, 20 GB of SSD storage, 200 Mbps networking and 10,000 IOPS.

Neither page is obscure. One is the customer-facing explanation of the service; the other is the system through which a buyer is invited to order it. Yet they describe materially different computing units. The discrepancy is not confined to the smallest plan. The public Cloud 2G offer lists two cores, 4 GB of RAM and 40 GB of storage; the checkout version lists two cores, 2 GB of RAM and 40 GB. Higher packages differ in memory and disk as well. A separate billing category,SSD Cloud Server C6, presents another generation of similarly named plans, including a 350,000-dong Cloud 1G with two cores, 2 GB of RAM, 30 GB of storage, 200 Mbps and 50,000 IOPS.

This does not prove that customers are provisioned incorrectly. A catalogue can contain a legacy category, a newer hardware pool, a stale landing page or a configuration that is clarified during sales. It does prove that the public record cannot answer the most elementary procurement question: which specification becomes the obligation when payment is made?

For an infrastructure supplier, that is not a minor publishing error. CPU allocation affects application throughput. Memory can determine whether a database remains resident or swaps. Disk size affects migration feasibility. IOPS can change the behaviour of transactional workloads by an order of magnitude. A network rate can be a port ceiling, a committed rate, a shared profile or a burst limit. Each variation can alter performance and total cost.

The first control in an Ehost purchase should therefore be documentary. The quote, order form or contract should identify the exact product family and generation; vCPU count and scheduling model; guaranteed memory; usable storage; storage medium; minimum and burst IOPS; domestic and international bandwidth; transfer limits; public IP allocation; location; operating-system image; management scope; backup inclusion; restoration fee; taxes; and renewal term. The buyer should preserve that document alongside the invoice and initial provisioning evidence.

The central thesis of this review follows from those two Cloud 1G cards. Ehost’s infrastructure is not adequately described by the brand name, the monthly price or the word “cloud”. Its real product begins where the parties reconcile the sales page, the billing portal and the service that is actually delivered.

The exact company behind the screens

The 实体 boundary is unusually important because “Ehost” appears as a brand, a domain, a support portal, an AntiDDoS service and a registered network. The company examined here isEHOST SOFTWARE COMPANY LIMITED, in VietnameseCông ty TNHH Phần Mềm Ehost, with tax code0312916711. Ehost’scontact pagegives the legal name, registration number, a Ho Chi Minh City address at 147/25 An Dương Vương in Bình Tân, telephone number 0938-227-199 and an@ehost.vncontact address. The footer says the business registration was issued on September 9, 2014.

Athird-party Vietnamese tax-record aggregatorindependently associates the same tax code with EHOST SOFTWARE COMPANY LIMITED, the same street address, an operating date of September 9, 2014 and representative Nguyễn Thanh Tâm. That record is useful corroboration, not a substitute for a fresh extract from Vietnam’s official enterprise registry. Its status and industry classifications should be treated as the aggregator’s dated rendering of public records.

The network identity supplies a separate continuity check.BGP.toolsreproduces APNIC-originated registration data for AS135920:EHOST-VN, described as Ehost software company limited, country Vietnam, maintained through VNNIC. The record was modified in January 2026.IPinfo’s AS135920 pagealso classifies the network as hosting and associates it with the same company name.

These links support an honest conclusion: the legal company, the activeehost.vnsales surface, thesecure.ehost.vnbilling and support surface, and AS135920 belong to one coherent operating footprint. They do not prove that every service advertised on every related domain is owned, operated or guaranteed by the company. IPinfo, for example, listsehost.com.vnas the ASN’s domain, while the current operating site reviewed here isehost.vn; the former did not yield a usable page during this research. That is a domain-continuity question for the company, not grounds to split or merge 实体.

The same caution applies to AntiDDoS. Ehost links directly toAntiddos.vn, and its cloud page says customers can integrate with that service. The AntiDDoS site presents itself as a multi-node Vietnamese mitigation network founded in 2015. Public pages reviewed here do not set out a separate corporate identity or contract chain sufficient to determine whether Antiddos.vn is a division, product, affiliate or commercial partner of EHOST SOFTWARE COMPANY LIMITED. A buyer should make the contracting party explicit rather than infer it from cross-linking.

Exact identity matters at failure time. The 实体 taking payment should be the 实体 obliged to provide service, safeguard data, notify incidents, return equipment or exports, and pay any refund or service credit. If a data-centre operator, software licensor, mitigation service or network carrier performs part of the service, the customer needs to know whether Ehost remains accountable for that dependency or merely resells it.

What AS135920 proves — and what it does not

AS135920 is the strongest independent evidence that Ehost operates more than a brochure and a reseller storefront. In the frozen public BGP view, the autonomous system originates five IPv4/24prefixes:45.123.96.0/24,45.123.97.0/24,103.63.212.0/24,103.63.213.0/24and103.63.215.0/24. That is 1,280 IPv4 addresses. BothBGP.toolsandIPinfoshow the prefixes as covered by valid Route Origin Authorisations. APNIC Labs’Vietnam route-origin validation tablereports 100 per cent valid coverage for the measured EHOST-VN address population.

That is meaningful operational evidence. Ehost has number resources visible in the global routing system. Multiple addresses respond to independent probes, and IPinfo reports hundreds of domains across addresses in the ASN. The footprint is consistent with hosting activity rather than a legal shell that merely markets someone else’s platform.

RPKI validity is also a real control. It lets route validators cryptographically check that AS135920 is authorised to originate the covered prefixes. VNNIC’s2024 internet-resource reporttreats RPKI and IPv6 as important parts of Vietnam’s internet-resource development. Ehost’s valid origin authorisations reduce one class of route-origin error or hijack risk.

The evidence stops there. RPKI does not show that Ehost filters invalid routes received from others, protects customer applications, maintains redundant routers or can survive a carrier failure. It says nothing about traffic volume, server capacity, power, cooling, DDoS scrubbing capacity, backup quality or customer count. A five-prefix origin can support a well-run specialised host or a fragile one; the route table does not decide between them.

The visible connectivity is more cautionary. BGP.tools lists one upstream, AS135905, described as Vietnam P&T. The independentCIDR Report viewalso sees one upstream adjacency and no downstream address space. IPinfo likewise lists one upstream and one peer, both AS135905. Relationship labels vary by data source, but the consistent observation is one externally visible adjacent network carrying AS135920’s routes in the reviewed views.

This should not be translated into a claim that every Ehost rack has one physical cable or that every product is single-homed. Ehost advertises colocation at several data-centre brands, and it may use provider-assigned addresses, private interconnects, Layer 2 services, remote DDoS mitigation or routes not visible as separate AS adjacencies. Public BGP collectors can also miss private or selective relationships.

It does create a procurement test. If a service is sold as multi-carrier or multi-data-centre, Ehost should show how customer traffic survives loss of AS135905, the relevant border router, the serving site and the path to the mitigation platform. The evidence might include an architecture diagram, current BGP sessions, route policy, looking-glass results, failover records and a controlled test. “Several data centres” is a facility statement; “diverse internet reachability” is a routing statement. One does not automatically deliver the other.

IPv6 is the other visible gap. The reviewed routing sources showzero originated IPv6 prefixesfor AS135920. That does not prove Ehost offers no IPv6 anywhere: a customer could receive IPv6 from a facility or upstream ASN. It does mean a buyer cannot infer native dual-stack service from Ehost’s own autonomous system. Product-specific questions should cover IPv6 allocation size, routing, reverse DNS, firewalling, DDoS handling, monitoring and parity with IPv4 support. In 2026, “we can add it later” is a lifecycle commitment, not a technical answer.

A catalogue of different responsibility models

Ehost is not selling one infrastructure model. Its public menu spans shared hosting, email hosting, virtual machines, dedicated servers, game servers, colocation, backup, 实体-style storage, caching, CDN brokerage, control-panel licences, certificates and DDoS protection. Each moves a different part of the operating stack between provider and customer.

Inpersonal shared hosting, Ehost says the platform supplies cPanel, SSL, SSD storage, a basic AntiDDoS layer and weekly backups. The customer primarily manages website code, content, accounts and application updates while depending on Ehost for the shared server, control panel, network and isolation. Thebusiness-hosting pageadds a dedicated public IP, Redis caching and claims of resource separation. That is a higher-control shared service, not equivalent to a virtual server.

Cloud shifts more responsibility to the customer. Ehost’s public page says it uses OpenStack, provides a virtual machine, lets customers add CPU, memory and disk, and can stop the server for two to five minutes during an upgrade. Unless a separate managed-service term applies, the buyer should assume that operating-system hardening, application patching, database operation, identity management and workload monitoring remain customer duties. The public pages do not clearly label the standard cloud plans as managed or unmanaged.

Dedicated servers shift hardware exclusivity to the buyer but not necessarily hardware ownership. Ehost’s2026 dedicated-server pagelists monthly configurations from 5.5 million to 12 million dong, with Intel Xeon processors, 128 or 256 GB of RAM, SSD or NVMe storage, one IP address and 100 or 200 Mbps bandwidth. The buyer avoids noisy-neighbour compute contention, but remains dependent on Ehost for the machine, rack, power, carrier path, remote hands and replacement process.

Colocation is different again. The customer owns or controls the physical server and rents rack space, power and connectivity. Ehost says customers can enter the data centre around the clock after preregistration and can use remote KVM. In this model, Ehost may have less control over the server and more responsibility for access coordination, power, cross-connects, routing and hands-on assistance. A failure matrix must separate customer hardware, facility infrastructure, Ehost network and upstream carrier.

TheECDN pagesays Ehost cooperates with Vietnamese and international CDN providers rather than describing one wholly owned delivery network. That can be commercially useful: Ehost can act as a local integrator and billing contact. It also means cache locations, logs, purge behaviour, data handling, incident responsibility and exit depend on the unnamed underlying provider and the order-specific design.

TheeStorage pagedescribes “vStorage” as an Ehost-developed 实体-storage technology for media, documents, logs and static content, and says data is permanently stored and always backed up. The page does not publish an API specification, consistency model, durability target, erasure-coding or replication scheme, deletion behaviour, region map, egress price or service level. “Object storage” identifies a service class, not enough architecture for a durable-data decision.

Ehost’s breadth is therefore both an advantage and a diligence burden. A customer can buy several adjacent services from one local provider and reduce vendor coordination. But the responsibility boundary changes each time the customer moves from shared hosting to cloud, cloud to dedicated hardware, or an Ehost-origin network to a third-party CDN or data-centre path.

OpenStack is a component list, not an availability result

Ehost says its virtual machines run on OpenStack. That is technically specific enough to be useful, but not specific enough to establish resilience. The officialOpenStack logical-architecture guidedescribes a cloud as a set of independent services joined through APIs and a common identity service. Behind the interfaces sit databases, message queues and service processes for compute, networking, images and storage. OpenStack is an operating framework whose outcome depends on how those parts are deployed and maintained.

For a buyer, the first question is which OpenStack release and service set Ehost operates. The answer affects support status, upgrades, drivers, security fixes and API behaviour. The public product page does not identify the release, the compute hypervisor, the storage backend, the network design, availability zones, live-migration policy or customer-accessible API.

The second question is fault containment. OpenStack’s ownhigh-availability design guidancedistinguishes the data plane that keeps instances, networks and storage running from the control plane that performs management operations. It emphasises redundant services, load balancers, databases, message queues, switches, routes and power. Simply installing OpenStack does not eliminate single points of failure; operators have to design them out.

Ehost says its cloud uses high availability and can recover a server onto another system. That is a company claim about an outcome. To assess it, a buyer should ask what happens in several separate failures:

  • If one compute host fails, does the virtual machine restart automatically, and how long does detection and restart take?
  • If shared storage fails, are volumes replicated across independent fault domains or merely protected by RAID inside one system?
  • If a controller or message queue fails, do existing machines continue while management operations pause?
  • If a top-of-rack or core switch fails, is there a physically diverse path?
  • If a site fails, can a customer be restored in another site from an independent copy?
  • If the OpenStack upgrade itself fails, what is the rollback and customer-notification process?

These questions matter because the public 99.5 per cent uptime claim is relatively permissive. If applied continuously, 99.5 per cent availability allows about 3 hours and 36 minutes of downtime in a 30-day month, or roughly 43 hours and 48 minutes in a 365-day year. That calculation is not a statement about Ehost’s actual performance. It shows why the measurement period, exclusions, maintenance treatment, monitoring source and remedy matter as much as the percentage.

There is also an upgrade signal in the product text. Ehost says changing CPU, memory, disk or network can require a two-to-five-minute shutdown. That suggests at least some resizing is an interruption rather than a transparent live operation. A customer planning vertical scaling during peak periods should test it and ask whether storage expansion, instance flavour changes and host maintenance follow the same path.

The useful conclusion is neither “OpenStack is unreliable” nor “OpenStack guarantees cloud”. It is that Ehost has named a plausible technical foundation, while leaving the deployment choices that determine customer risk largely outside the public record.

The customer journey crosses three control planes

An Ehost customer moves through three distinct control planes: commercial, infrastructure and application. Problems often occur where responsibility passes between them.

The commercial journey begins onEhost’s main site, where product pages present packages and monthly prices. Ehost says that after registration it sends a confirmation and cost notice, and that service is created after payment. The customer then reachessecure.ehost.vn, a billing and support system with product categories, VND and US-dollar display options, an account, order forms, tickets, announcements, downloads and a server-status link.

The specification conflict makes the handoff important. Before payment, the buyer should capture the selected order configuration and obtain written confirmation that it supersedes inconsistent web copy. After provisioning, the customer should record what actually arrived: virtual CPU count, memory, disk, public IP, route, interface speed, operating system, control-panel licence and backup status. A short acceptance script can compare the delivered machine with the order.

The infrastructure journey then begins. For a cloud server, Ehost provisions compute, storage and networking; the customer installs or receives an operating system, creates administrator credentials, points DNS and deploys an application. For shared hosting, Ehost exposes a control panel and the customer moves site files, databases, certificates and mail settings. For colocation, the customer must arrange facility access, rack installation, power, IP addressing and remote administration.

Migration is not one task. Ehost’s main site advertises free advice and data-transfer assistance for customers using its services. A production migration still needs a source inventory, data copy, DNS strategy, certificate handling, mail-flow test, application freeze window, integrity check and rollback. If IP addresses change, allowlists, payment providers, third-party APIs and security rules may need updates. If email moves, sender reputation and DNS records such as SPF, DKIM and DMARC become part of acceptance.

The application control plane remains largely the customer’s. A virtual machine can be healthy while the application is down because of a failed deployment, full disk, expired certificate or database lock. Ehost’s knowledgebase includes articles on full disks and certificate errors, which is useful support content, but it also illustrates the shared boundary: the provider can explain a symptom without owning every workload decision.

Operations should therefore assign named responsibilities. Ehost may own physical hardware, virtualisation, edge networking and platform backups. The customer may own operating systems, applications, accounts and data classification. A third party may own the control-panel licence, CDN, certificate authority, domain registration or DDoS scrubbing. During an incident, the ticket must reach the party that can actually act.

The final commercial step is renewal or exit. Public pages expose monthly prices, but some products require multi-month minimums. The billing portal shows three-month periods for some hosting offers, while DirectAdmin licences are shown with six-month minimums. Buyers should not confuse a monthly unit price with a month-to-month termination right.

Price is transparent only after the specification is stable

Ehost publishes more prices than many infrastructure vendors. That is useful. A small business can see that shared hosting starts at 50,000 dong a month, business hosting at 300,000, cloud at 250,000, backup at 95,000, dedicated servers at 5.5 million and public-page colocation at 1.8 million. Add-ons have visible prices: extra cloud CPU, memory, disk and IPv4; extra hosting storage, domain or IP; rack space, power and network upgrades.

The figures reveal Ehost’s economic design. Shared hosting spreads a server and support operation across many customers. Cloud packages meter a bundle of compute, memory, storage and network capacity. Dedicated servers charge for exclusive hardware. Colocation charges for scarce rack, power and connectivity. Backup charges primarily by stored capacity. Licences and certificates add third-party software or trust services.

Yet published price is not the same as dependable price. Thebusiness-hosting order categorycontains a striking anomaly: “Business-02” is displayed at 1.35 billion dong for three months, while nearby packages are in the hundreds of thousands. The same page advertises legacy PHP and MariaDB versions. It would be unreasonable to treat the billion-dong figure as Ehost’s intended tariff without confirmation; it is better understood as evidence that the storefront can contain data-entry or lifecycle inconsistencies.

Colocation shows a broader reconciliation problem. The publiccolocation pagelists 1U packages at VNPT Data, Viettel IDC and CMC for 3.2 million, 2.8 million and 1.8 million dong a month, generally with 200 Mbps domestic networking and 30 Mbps shared international bandwidth. Thebilling portal’s colocation categorylists ODS, Viettel IDC and VNPT Tân Thuận at 1.3 million or 1.4 million dong, with 100 Mbps ports and four or ten Mbps international bandwidth. The locations, capacity and prices are not equivalent.

There may be a legitimate explanation: different rack generations, promotions, power allowances, commitment periods, legacy offers or routes to market. The pages do not provide it. A buyer comparing only the headline monthly number could therefore purchase a different service class from the one assumed.

The total cost should include at least:

  • initial migration, operating-system setup and application validation;
  • VAT and any other applicable charges;
  • minimum commitment and renewal terms;
  • public IPv4, bandwidth, international traffic and DDoS options;
  • control-panel, Windows, database or other software licences;
  • backup capacity, retention and restoration charges;
  • managed support or remote-hands work;
  • hardware replacement or upgrade downtime;
  • domain, certificate and email dependencies;
  • data export, transfer and transition assistance at exit.

“Unlimited bandwidth” also needs a definition. Several Ehost pages use the term while separately publishing port rates or international bandwidth. Unlimited can reasonably mean no usage-based transfer charge, not infinite throughput or a dedicated uncontended circuit. The contract should distinguish port speed, committed information rate, burst behaviour, fair-use policy and domestic versus international paths.

Ehost may still be price-competitive after every term is clarified. The public record is not sufficient to calculate margin, oversubscription or like-for-like cost against rivals. It is sufficient to show that price comparison must begin after product reconciliation, not before.

Backup is a promise with two retention periods

Backup is where Ehost’s public material is most useful and most contradictory. The cloud page first says the entire cloud is backed up daily and copies are retained for at least seven days. In the plan notes, it says “Full Backup Daily” retains the most recent fourteen days and charges 500,000 dong per restoration. Both statements appear on the same page.

Shared hosting follows another policy. The personal and business pages say data is triplicated in real time and backed up weekly, with backups retained for two months. A separateCloud Backup servicesells storage from 10 GB to 100 GB and says it can back up a whole disk so an operating system and applications can be moved to replacement hardware. It advertises 24/7/365 technical support and monthly payment.

These may be distinct layers: platform replication, included service backup and customer-purchased backup. They should be distinct. Real-time triplication can protect against a disk failure while instantly reproducing a customer’s deletion or ransomware-encrypted data. A platform snapshot can help Ehost recover infrastructure while being unsuitable for granular customer restoration. A paid backup service can have separate retention and isolation. The current pages do not give a single map of those layers.

OpenStack’s ownbackup and recovery guidancemakes the missing questions clear: backup frequency should follow acceptable data loss; retention and off-site storage matter; and recovery testing is as important as the existence of copies. Ehost’s public claims do not disclose the backup location, immutability, encryption, administrative separation, deletion policy, restore-time target or test results.

A buyer should turn “backup included” into a schedule:

  1. Scope:boot volume, attached volumes, databases, object storage, control-panel configuration, mailboxes and customer-managed keys.
  2. Recovery point:the maximum data that can be lost in each service.
  3. Recovery time:when Ehost starts work and when a usable workload must return.
  4. Retention:exact number of recoverable copies and how age is calculated.
  5. Isolation:whether copies survive compromise of the production account, cluster or site.
  6. Restore method:whole-machine, file-level, database-level and alternate-location recovery.
  7. Fees:included restores, emergency charges and data-egress costs.
  8. Evidence:scheduled customer restore tests with recorded results.

The conflict between seven and fourteen days should be resolved in the contract, but the deeper issue is responsibility. If a customer’s application generates critical data, an Ehost backup should not be the only copy controlled through the same account and provider. The customer needs an independent export or replication path whose credentials and failure domain differ from production.

Five-minute response is not five-minute recovery

Ehost’s support surface is visible. The main site provides phone and email contacts; the support portal offers tickets, a knowledgebase, announcements, downloads and server status. Theservice-warranty pagesays support works 24/7 and that customers will be notified by email, telephone or direct contact when maintenance requires time. The dedicated-server and game-server pages claim a response within five minutes through ticket, email, hotline or live chat.

These are useful commitments, but they describe access and response more than resolution. A five-minute acknowledgement can confirm that an incident exists while hardware replacement, route failover or data restoration takes hours. A serious service schedule needs separate clocks for acknowledgement, technical engagement, workaround, restoration and root-cause report.

Severity also matters. A single website being slow, an entire virtualisation cluster being unavailable, suspected data exposure and a routine configuration question should not share one queue. The public pages do not disclose severity definitions, escalation roles, language coverage, staffing model, after-hours authority or service-credit remedies.

The support portal provides one intriguing but limited observation. At the time of access, both itsknowledgebaseanddownload areadisplayed a generic notice that Ehost was aware of an issue that could affect service. The linked server-status detail was not publicly retrievable at the time of review, so the affected service, start time, severity, customer impact and resolution could not be established. This is not evidence of a material outage. It is evidence that a status mechanism exists but did not yield a usable public incident record.

No comprehensive public status history, post-incident archive or independently measured uptime series was located. Absence of a public archive does not mean Ehost has no incidents or no internal records. It means a buyer must request them. Useful diligence would include the prior twelve months of availability by product and site, severity-one incident counts, median response and restoration times, maintenance history, sample root-cause reports and backup-restore results.

Maintenance notice should also be made measurable. How much notice is given for planned work? Which emergency actions are exempt? Is maintenance excluded from uptime calculations? Can a customer reschedule? Does Ehost migrate virtual machines or shut them down? What happens to an unmanaged operating system that does not recover cleanly?

The strongest local provider can be valuable precisely because a buyer can reach a human who knows the infrastructure. That advantage becomes contractual only when the person has authority, the queue is monitored, the escalation is tested and the restoration obligation is clear.

Security is several products, not one shield

Ehost’s security language spans physical firewalls, shared-hosting isolation, basic AntiDDoS, paid DDoS mitigation, SSL certificates, backups and support. These controls address different threats and should not be collapsed into a general claim that a workload is “secure”.

The cloud page says each cluster has a physical firewall and that virtual machines can be integrated with Antiddos.vn. The business-hosting page says basic AntiDDoS can automatically activate firewall protection against smaller botnets. TheAntiDDoS sitedescribes multiple proxy and firewall nodes across Vietnamese data-centre brands, filtering malicious requests and providing HTTP/2 and web-application-firewall features. Ehost’sAntiDDoS ordering categorypublishes plan labels and some request-volume parameters.

These are company claims about service design, not independent validation of mitigation capacity. Procurement should ask whether protection is always on or activated after detection; whether it covers Layer 3/4 floods, Layer 7 requests or both; where traffic is diverted; what clean bandwidth is committed; whether source IPs are preserved; how TLS keys are handled; what happens to non-web protocols; whether attacks trigger extra charges; and whether the origin remains reachable directly.

The network-resource evidence adds another boundary. RPKI-valid prefixes help prevent unauthorised route origins. They do not filter malicious application requests, stop credential theft, patch a customer operating system or protect a database from an overprivileged account. Conversely, a web proxy can absorb HTTP attacks while leaving mail, VPN, game or database services exposed.

Account security is also underdocumented. The public record reviewed here does not establish whether multi-factor authentication is mandatory or available for every customer and administrator surface. Buyers should test MFA, role separation, API credentials, support identity verification, privileged-access logging and offboarding rather than infer implementation from general security language.

The abuse path is similarly unclear. APNIC-derived records identify VNNIC’s incident-response maintainer rather than a clearly advertised Ehost abuse desk, and the main site exposes sales and support contacts rather than a dedicated abuse policy. That does not prove Ehost lacks an internal process. It means an external reporter or customer cannot easily verify the route for malware, spam, phishing, copyright or network abuse. A hosting provider should be able to show intake, authentication, evidence preservation, customer notification, suspension standards and appeal.

Vietnam’s official legal database lists theLaw on Personal Data Protection 91/2025/QH15as effective from January 1, 2026. The application of that law depends on the facts and should be assessed by qualified counsel. For Ehost buyers, the practical requirement is straightforward: the contract must identify processing roles, support access, data location, subprocessors, incident cooperation, retention, deletion and export for the actual service.

No public, product-specific security assurance package was located for Ehost: no scoped ISO certificate, SOC report, penetration-test summary, vulnerability-disclosure policy, subprocessor list or software bill of materials. This is an evidence gap, not proof that those controls do not exist. It becomes consequential when a buyer’s risk model requires more than first-party claims.

The lifecycle warning hidden in the storefront

The public catalogue contains signs that product information has aged unevenly. The shared-hosting pages describe support for PHP versions from 5.4 to 7.1 and MariaDB 10.1. The billing portal separately lists MultiPHP 5.5, 5.6 and 7.0 for some packages and PHP 7.0 with MariaDB 10.1 for a high-performance offer.

Those versions are not current. PHP’s officialunsupported-branches tablerecords end of life for PHP 5.4 in September 2015, PHP 7.0 in January 2019 and PHP 7.1 in December 2019. The MariaDB Foundation’srelease-maintenance tableplaces MariaDB 10.1’s maintenance end in October 2020.

The responsible interpretation is not that Ehost definitely runs exposed end-of-life software in production. The pages may be stale while the platform has been upgraded. That distinction has to be tested. Stale specifications are themselves a control problem because customers use them to judge application compatibility and security.

An Ehost buyer should request a current runtime matrix for every shared-hosting pool: operating system, web server, control panel, PHP branches, database version, TLS configuration, patch cadence and planned deprecation dates. It should confirm whether customers can select unsupported versions for legacy applications and, if so, what isolation and risk terms apply.

Control panels add third-party lifecycle dependency. Ehost sellsDirectAdmin licencesand says some “internal” licences are available only for servers hosted at Ehost, with multi-month minimum payment. A customer that combines Ehost compute, an Ehost-supplied licence, DNS, certificates and backups may receive convenient one-stop support. It also creates a bundle that must be disentangled during migration.

The cloud page’s reference to Intel Broadwell processors provides another dated clue, while the dedicated-server page advertises newer Xeon Gold and Platinum configurations and the C6 billing category claims much higher IOPS. This looks like multiple infrastructure generations rather than one uniform fleet. That is normal for a long-running host, but placement policy matters. The buyer should know whether a plan maps to a defined CPU generation and storage class or whichever pool has capacity.

Lifecycle governance should cover more than versions. It should specify notice for host migrations, control-panel changes, operating-system image retirement, hardware end of life, IP renumbering, certificate-brand changes and discontinued packages. The support portal even contains a category labelled “EOL”, though its contents were not available in the frozen evidence. A published lifecycle policy would let customers plan instead of discovering retirement through a renewal or incident.

Competition tests Ehost on evidence, not scale

Ehost competes across several markets at once. In shared hosting, it faces local hosts and website platforms. In virtual machines, it faces Vietnamese telco clouds, specialised VPS providers and global hyperscalers. In dedicated servers and colocation, it faces data-centre operators, systems integrators and direct facility contracts. For backup, CDN and DDoS, customers can buy a specialist service independently.

The most credible Ehost advantage is not global scale. It is the possibility of a local operating relationship: VND-denominated packages, direct telephone and ticket contact, migration help, Vietnamese facilities, simple bundles and one supplier across hosting, server, rack and protection services. A small company without a large infrastructure team may value a provider willing to inspect a system and recommend a practical configuration.

The challenge is that larger domestic alternatives publish a different level of assurance.VNPT Cloudadvertises an SLA of 99.99 per cent, IPv6 support, a broader managed-service catalogue and named security certifications. Those are VNPT’s own claims, not independent proof that every workload will perform better. They illustrate the procurement comparison Ehost must meet: what service level, dual-stack capability, compliance evidence, architecture and managed scope does the buyer receive for the price?

Global hyperscalers offer APIs, regions and managed services that Ehost’s public catalogue does not match. They can also introduce foreign-currency exposure, complex pricing, distant support and architecture that a small customer struggles to operate. A self-managed server in colocation offers maximum hardware control but transfers patching, spare parts and recovery to the customer. A managed software platform can eliminate server administration but increase application-level lock-in.

The right competition test is therefore workload-specific:

  • For a brochure site, shared hosting may be cheaper and simpler than any cloud.
  • For a Vietnamese application needing predictable local support, Ehost cloud or dedicated hardware may be attractive if the service specification is verified.
  • For a regulated workload, assurance scope, incident process and data terms may outweigh headline price.
  • For a globally distributed application, IPv6, international paths, automated scaling and multi-region design may dominate local support.
  • For a latency-sensitive game, CPU clock, DDoS response, domestic peering and attack-time packet loss matter more than generic “cloud” branding.

The single old independent customer discussion found in the reviewed public record, aVietnamese hosting forum thread, contains a favourable anecdote about Ehost service and support. It is years old, informal and not representative. Ehost’s own site also publishes positive testimonials without enough detail to verify identity, product or date. Neither should substitute for current references from customers running a comparable workload.

Ehost does not need to prove that it is the largest provider. It needs to prove that its local service model gives a particular customer more control per dong than the realistic alternatives.

Switching costs appear one dependency at a time

Infrastructure is often described as portable because a virtual machine can be copied. In practice, switching cost accumulates outside the machine image.

The first layer isaddressing. A workload using Ehost-assigned IPv4 may need to renumber when it leaves. DNS can hide part of the change, but allowlists, VPN peers, payment systems, mail reputation and third-party APIs may contain the old address. Ehost’s own portable address space is visible, but the public terms do not say whether a customer can bring or transfer IP resources.

The second layer isstorage and backup. A disk image may omit snapshots, 实体 metadata, backup history or provider-side encryption details. The eStorage page does not publish an export API or egress schedule. A restore that works only inside Ehost is continuity protection, not portability.

The third layer iscontrol software. cPanel or DirectAdmin configurations, mail accounts, reseller hierarchies, certificates and scheduled jobs have to be reconstructed or converted. An internal licence tied to Ehost hosting may end when the server moves, requiring a new licence and perhaps a control-panel migration.

The fourth layer isnetwork protection. If a domain points through an Ehost-linked DDoS proxy or CDN, exit requires DNS change, certificate and origin reconfiguration, log export and careful removal of the old path. Attack-time migration is especially difficult because the origin may be exposed during transition.

The fifth layer isoperational knowledge. Ehost support may know why a server uses a particular route, kernel, firewall exception or storage layout. If that knowledge lives in tickets rather than customer documentation, a successful support relationship creates dependence.

Colocation has physical exit costs. The customer needs authorised access, a maintenance window, packaging, transport, data destruction for retired media and a new route. If Ehost supplies IP space or remote hands, those services end at the same time the machine moves.

The public evidence does not provide a complete termination, export or deletion policy. Ehost’s homepage says there is a refund policy when a service is not used, and the personal-hosting FAQ says unused value can be credited when upgrading. The warranty page addresses support and maintenance notice. None of those pages establishes refund eligibility, termination notice, data-access duration, export format, deletion evidence or transition assistance across all services.

An exit schedule should be agreed before go-live. It should give the customer current exports and snapshots; sufficient read access; DNS and domain transfer procedures; mailbox migration support; log and ticket history where relevant; a timetable for removing provider access; deletion confirmation; hardware-release steps for colocation; and predictable charges. The customer should rehearse at least one restore or migration to another environment while the relationship is healthy.

A procurement test that matches Ehost’s actual surface

Ehost should be evaluated with evidence that corresponds to its specific claims and gaps, not a generic cloud questionnaire.

1. Reconcile the commercial record

Ask Ehost to identify the authoritative product catalogue and explain the differences between the public Cloud Server page, SSD Cloud Server store and C6 store. Require a signed configuration schedule. Do the same for public and billing-portal colocation packages. Confirm taxes, commitment, renewal, refund, restoration and upgrade charges.

2. Prove the delivered machine

During a trial, record CPU model and steal time, available memory, usable disk, sustained and burst IOPS, latency under load, interface rate and domestic and international throughput. Run tests at several times rather than treating one benchmark as a guarantee. Compare the result with the order form.

3. Map the OpenStack fault domains

Request the OpenStack release, hypervisor, storage backend, availability-zone design, control-plane redundancy and maintenance process. Ask for a controlled compute-host failure or documented recent test. Establish whether instance restart, volume recovery and cross-site restoration are separate capabilities.

4. Test the route, not the data-centre list

Confirm which ASN and prefixes the product uses, whether addresses are Ehost or facility space, and whether IPv6 is available. Ask how AS135920 survives loss of AS135905 and how routes change when AntiDDoS is activated. Test from major Vietnamese access networks and from international locations. Record packet loss and path changes during a maintenance or simulated failover.

5. Turn backup into a recovery exercise

Resolve the seven-versus-fourteen-day cloud-retention conflict. Select a file, database and full-machine recovery. Delete or corrupt test data, then measure the recovery point, operator response, restoration time, resulting consistency and fee. Verify whether a separate-site or offline copy exists.

6. Define support by severity

Open tickets through each promised channel. Confirm that 24/7 means a qualified responder, not only intake. Contract separate acknowledgement and restoration targets, escalation contacts, maintenance notice and root-cause delivery. Obtain historical performance for the product and site being purchased.

7. Inspect security and abuse controls

Test MFA, role separation, account recovery and support identity checks. Review patch ownership, tenant isolation, logging, vulnerability management, DDoS architecture and privileged access. Obtain the actual privacy and service policies that the support portal lists but that were not publicly retrievable in this research. Confirm a dedicated abuse route and evidence-handling process.

8. Verify lifecycle and portability

Ask for current supported software versions and deprecation dates. Export a VM, database, mailbox set, control-panel account and backup. Confirm which licences terminate on exit. If colocation is involved, rehearse authorised physical access and equipment release.

This test does not demand hyperscaler documentation from a small operator. It asks Ehost to support the promises it already makes: defined resources, high availability, backups, fast support, several facilities, security and local operational care.

The unanswered questions are part of the product

The reviewed public record establishes more than is often visible for a local host. There is an exact company, live pricing, active support and billing systems, a broad service catalogue, an autonomous system, five routed IPv4 prefixes, RPKI coverage and responsive addresses in Ho Chi Minh City. It also reveals a provider that continues to publish new 2026 content and newer dedicated-server or C6 offers.

It does not establish audited revenue, market share, customer count, staff scale, facility ownership, traffic volume, server count, route capacity or actual uptime. IPinfo’s hosted-domain estimate cannot be converted into customers because one customer can operate many domains and one domain can use only part of Ehost’s service. A public prefix count cannot be converted into compute capacity.

It does not establish that the “Tier 3” facilities named in Ehost marketing are certified for the exact racks and services sold, or that Ehost owns the facilities. It does not establish physical or carrier diversity from a multi-site list. It does not establish that every RPKI-covered address receives DDoS protection.

It does not establish a complete SLA. The public 99.5 per cent figure lacks a visible measurement and remedy framework, while “absolute uptime” wording on dedicated servers is not a credible substitute for bounded terms. No complete refund schedule was accessible.

It does not establish current runtime versions. The old PHP and MariaDB references may be stale copy or live compatibility; only a current platform inventory can distinguish them. It does not establish an OpenStack version or topology.

It does not establish backup isolation, recovery performance or one authoritative retention period. It does not establish an incident history, even though the support portal exposes a status mechanism and displayed a generic issue notice. It does not establish independent security certification, test scope or abuse handling.

These are not reasons to declare the company unsuitable. They are dimensions of the service that remain private, contract-specific or unresolved. For a low-risk website, a customer may reasonably accept less documentary depth and rely on a tested migration plus independent backups. For a revenue-critical, regulated or attack-prone system, the same gaps become procurement blockers until Ehost supplies evidence.

What to watch next

Five signals would materially improve confidence in Ehost’s control surface.

First,catalogue convergence. The public product pages and billing portal should describe the same packages, or clearly mark generations and dates. Removing implausible prices and unsupported runtime references would make the storefront a reliable part of the service.

Second,network development. Continued RPKI validity is positive. Public IPv6 origination and a demonstrably diverse upstream or peering design would reduce unanswered questions around reachability and lifecycle. If Ehost intentionally keeps one public upstream, it should explain the resilience mechanism behind that choice.

Third,operational transparency. A usable status page with incident timestamps, affected products, updates and resolution would turn the existing status link into evidence. Periodic availability and restore metrics would make the uptime and backup claims testable.

Fourth,policy closure. Ehost’s site links privacy, service-use, shipping and warranty pages, and its support portal lists an EHOST services-policy download. Publishing current, accessible terms for refunds, acceptable use, abuse, data processing, support, SLA, backup, termination and deletion would reduce negotiation cost for both sides.

Fifth,lifecycle discipline. A current software matrix, OpenStack release policy and notice schedule for hardware pools, control panels and end-of-life products would show that Ehost manages the long tail created by a broad catalogue.

Ehost’s public network is not imaginary. Five routed prefixes and an active hosting footprint are more persuasive than a wall of unverified infrastructure logos. But a route announcement is only the outer edge of the service. The customer depends on the order database, provisioning system, hypervisor, storage, facility, carrier, backup, support queue and contract that sit behind it.

That is why the two 250,000-dong Cloud 1G descriptions matter. They expose the exact place where a hosting relationship can become either controllable or ambiguous. If Ehost and the buyer can reconcile the specification, prove the route and recovery path, assign failure-time responsibility and preserve an exit, the company’s local breadth can be an advantage. If those questions remain inside inconsistent web pages, the cheapest server has not yet acquired a dependable price.