The contract before the cloud: Ehost's visible network and its competing specifications

Summary

• EHOST SOFTWARE COMPANY LIMITED is supported by consistent legal, contact and network identifiers: the operational website 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 announced IPv4/24prefixes.
• The routing footprint is real but modest. The BGP sources examined show 1,280 announced IPv4 addresses, no announced IPv6 space, and a single upstream adjacency observed via AS135905. This proves neither poor service nor physical single-homing, but makes questions of routing diversity, failover, and product-specific IPv6 availability material.
• Ehost's public commercial surfaces do not provide a stable product specification. The same Cloud 1G label at 250,000 dong is described differently on the marketing page and the billing portal, and public and payment colocation offers also diverge. A signed purchase order must therefore define the authoritative terms regarding CPU, memory, storage, IOPS, bandwidth, location, backup and support.
• Claims about backup, security and support require the same treatment. Ehost announces 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 plan, a severity matrix, a service credit schedule, an incident history, an abuse management process or an independent insurance coverage.
• The provider may suit customers who value Vietnamese billing, direct human support, migration assistance and a menu covering shared hosting, cloud, dedicated servers, colocation, backup and DDoS protection. Buyers with strict continuity, compliance or portability requirements must perform a proof of service and negotiate an executable exit before going into production.

A 250,000 dong server with two answers

Let's start with Ehost's smallest cloud package. On the publicCloud Serverpage, "EHOST 1G" costs 250,000 Vietnamese dong per 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 states that all cloud plans receive at least 2,000 storage IOPS. On Ehost's live order pageSSD Cloud Server, "Cloud 1G" also starts at 250,000 dong per month, but the displayed specification is one CPU core, 2 GB of RAM, 20 GB of SSD storage, a 200 Mbps network and 10,000 IOPS.

Neither page is obscure. One is the service explanation intended for customers; the other is the system through which a buyer is invited to order. Yet they describe materially different compute units. The discrepancy is not limited to the smallest plan. The public Cloud 2G offering lists two cores, 4 GB of RAM and 40 GB of storage; the billing version lists two cores, 2 GB of RAM and 40 GB. The higher packages also differ in memory and disk. A separate billing category,SSD Cloud Server C6, presents another generation of similarly named plans, including a Cloud 1G at 350,000 dong with two cores, 2 GB of RAM, 30 GB of storage, 200 Mbps and 50,000 IOPS.

This does not prove that customers are poorly provisioned. A catalogue may contain a legacy tier, a newer hardware pool, an outdated homepage, or a configuration clarified at point of sale. It does prove that the public record cannot answer the most basic purchasing question: which specification becomes the obligation when payment is made?

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

The first check in an Ehost purchase must therefore be documentary. The quote, purchase order or contract must identify the exact product family and generation; the number of vCPUs and scheduling model; the guaranteed memory; the usable storage; the storage medium; the minimum and burst IOPS; national and international bandwidth; transfer limits; public IP allocation; location; operating system image; management scope; backup inclusion; restoration fees; taxes; and renewal term. The buyer must keep this document with the invoice and proof of initial provisioning.

The central thesis of this review stems from these two Cloud 1G sheets. Ehost's infrastructure is not correctly described by the brand name, monthly price or the word "cloud". Its real product begins when the parties reconcile the sales page, the billing portal and the service actually delivered.

The exact company behind the screens

Entity boundaries matter especially because "Ehost" appears as a brand, a domain, a support portal, an AntiDDoS service and a registered network. The company reviewed 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, an address in Ho Chi Minh City at 147/25 An Dương Vương in Bình Tân, phone number 0938-227-199 and a contact email@ehost.vn. The footer indicates the business registration was issued on September 9, 2014.

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

The network identity provides a separate continuity check.BGP.toolsreproduces APNIC's original registration data for AS135920:EHOST-VN, described as Ehost software company limited, country Vietnam, maintained via VNNIC. The record was modified in January 2026. TheIPinfo page for AS135920also classifies the network as hosting and associates it with the same company name.

These links support an honest conclusion: the legal entity, the active sales surfaceehost.vn, the billing and support surfacesecure.ehost.vn, and AS135920 belong to a consistent operational footprint. They do not prove that every service advertised on every associated domain is owned, operated, or guaranteed by the company. IPinfo, for example, listsehost.com.vnas the ASN's domain, while the actual operational site reviewed here isehost.vn; the former did not yield a usable page during this research. This is a domain continuity matter for the company, not a reason to split or merge entities.

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

Exact identity matters in failure. The entity that takes payment must be the one obliged to provide the service, protect data, notify incidents, return equipment or export, and pay any refund or service credit. If a datacenter operator, software licensor, mitigation service, or network carrier executes part of the service, the customer needs to know whether Ehost remains responsible 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 view of public BGP, the autonomous system announces 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. This represents 1,280 IPv4 addresses.BGP.toolsandIPinfoboth show the prefixes are covered by valid route origin authorisations. APNIC Labs' Vietnam route origin validation table reports 100% valid coverage for the measured EHOST-VN address population.

This is significant operational evidence. Ehost has digital resources visible in the global routing system. Multiple addresses respond to independent probes, and IPinfo reports hundreds of domains on the ASN's addresses. 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 check. It allows route validators to cryptographically verify that AS135920 is authorised to announce the covered prefixes. VNNIC's 2024 Internet resource report treats RPKI and IPv6 as important items in 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 filtering capacity, backup quality, or number of customers. An announcement of five prefixes can support a well-run specialist hoster or a fragile one; the routing table does not decide between them.

Visible connectivity is more modest. BGP.tools lists one upstream, AS135905, described as Vietnam P&T. The independent CIDR report also sees a single upstream adjacency and no downstream address space. IPinfo also lists one upstream and one peer, both AS135905. Relationship labels vary by data source, but the consistent observation is a single visible adjacent network carrying AS135920's routes in the views examined.

This must not be read as the claim that every Ehost rack has a single physical cable or that every product is single-homed. Ehost advertises colocation in multiple datacenter brands, and may use provider-assigned addresses, private interconnects, layer-2 services, remote DDoS mitigation, or routes not visible as separate AS adjacencies. Public BGP collectors may also miss private or selective relationships.

It nonetheless creates a procurement test. If a service is sold as multi-carrier or multi-datacenter, Ehost must show how customer traffic survives loss of AS135905, the border router involved, the serving site, and the path to the mitigation platform. Evidence could include an architecture diagram, current BGP sessions, routing policy, looking-glass results, failover records, and a controlled test. "Multiple datacenters" is a facility statement; "Internet reachability diversity" is a routing statement. One does not automatically deliver the other.

IPv6 is the other visible gap. The routing sources examined showzero announced IPv6 prefixfor AS135920. This does not prove that Ehost offers IPv6 nowhere: a customer might receive IPv6 from a facility or upstream ASN. It means 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, firewall, DDoS management, 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 does not sell a single infrastructure model. Its public menu covers shared hosting, email hosting, virtual machines, dedicated servers, game servers, colocation, backup, entity-like storage, cache, CDN brokering, control panel licences, certificates, and DDoS protection. Each moves a different part of the operational stack between provider and customer.

Inpersonal shared hosting, Ehost states the platform provides cPanel, SSL, SSD storage, a basic AntiDDoS layer, and weekly backups. The customer primarily manages site code, content, accounts, and application updates, while depending on Ehost for the shared server, control panel, network, and isolation. Thebusiness hosting pageadds dedicated public IP, Redis cache, and claims resource separation. This is shared service with more control, not equivalent to a virtual server.

Cloud shifts more responsibility to the customer. Ehost's public page states it uses OpenStack, provides a virtual machine, allows the customer to add CPU, memory and disk, and may stop the server for two to five minutes during an upgrade. Unless a separate managed service contract applies, the buyer should assume OS hardening, patching, database operations, identity management, and workload monitoring remain customer duties. The public pages do not clearly label standard cloud plans as managed or unmanaged.

Dedicated servers transfer hardware exclusivity to the buyer but not necessarily hardware ownership. Ehost's2026 dedicated server pagelists monthly configurations from 5.5 to 12 million dong, with Intel Xeon CPUs, 128 or 256 GB RAM, SSD or NVMe storage, an IP address, and 100 to 200 Mbps bandwidth. The buyer avoids neighbour noise 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 states customers may enter the datacenter 24/7 after pre-registration and can use a remote KVM. In this model, Ehost may have less control over the server and more responsibility for access coordination, power, cross-connects, routing, and on-site assistance. A failure matrix must separate customer hardware, facility infrastructure, Ehost network, and upstream carrier.

TheECDN pagestates that Ehost cooperates with Vietnamese and international CDN providers rather than describing a fully owned delivery network. This may be commercially useful: Ehost can act as 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 object storage technology developed by Ehost for media, documents, logs, and static content, and states data is stored permanently and always backed up. The page does not publish API specification, consistency model, durability objective, erasure or replication scheme, deletion behaviour, region map, egress pricing, or service level. "Object storage" identifies a service class, not an architecture sufficient for a durable data decision.

Ehost's breadth is therefore both an advantage and a due diligence burden. A customer can buy multiple adjacent services from a single local provider and reduce vendor coordination. But the responsibility boundary changes every time the customer moves from shared hosting to cloud, cloud to dedicated hardware, or from Ehost-originated network to a third-party CDN or datacentre path.

OpenStack is a component list, not an availability outcome

Ehost states its virtual machines run on OpenStack. This is technically specific enough to be useful, but not enough to establish resilience. OpenStack's official logical architecture guide describes a cloud as a set of independent services linked by APIs and a common identity service. Behind the interfaces are databases, message queues, and service processes for compute, network, image, and storage. OpenStack is an operational framework whose outcome depends on how these parts are deployed and maintained.

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

The second question is failure containment. OpenStack's own high-availability design guide distinguishes 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, routers, and power. Installing OpenStack does not eliminate single points of failure; operators must design them out.

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

• If a 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 failure domains or only protected by RAID inside a single system?
• If a controller or message queue fails, do existing machines continue running 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 at 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% availability claim is relatively permissive. Applied continuously, 99.5% availability allows roughly 3 hours 36 minutes of downtime in a 30-day month, or about 43 hours 48 minutes per year. This calculation is not a claim about Ehost's actual performance. It shows why 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 states that changing CPU, memory, disk or network may require a two-to-five-minute shutdown. This 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 type 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 traverses three control planes

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

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

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

The infrastructure journey then begins. For a cloud server, Ehost provisions compute, storage and network; 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 email settings. For colocation, the customer must arrange facility access, rack installation, power, IP addressing, and remote administration.

Migration is not a single task. Ehost's main site announces free guidance and data transfer assistance for customers using its services. A production migration still requires source inventory, data copy, DNS strategy, certificate management, email flow test, application freeze window, integrity check, and rollback. If IP addresses change, allow lists, payment providers, third-party APIs, and security rules may need updates. If email changes, 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 may be healthy while the application is down due to a failed deployment, full disk, expired certificate, or database lock. Ehost's knowledge base 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 holding all workload decisions.

Operations should therefore assign named responsibilities. Ehost may own the physical hardware, virtualisation, edge network, 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 filtering. During an incident, the ticket must reach the party that can actually act.

The final commercial step is renewal or exit. Public pages display monthly prices, but some products require multi-month minimums. The billing portal shows three-month terms for certain hosting offers, while DirectAdmin licences are displayed with six-month minimums. Buyers should not confuse a monthly unit price with month-by-month termination rights.

Price is only transparent after specification stabilisation

Ehost publishes more prices than many infrastructure providers. This is useful. A small business can see that shared hosting starts at 50,000 dong per month, business hosting at 300,000, cloud at 250,000, backup at 95,000, dedicated servers at 5.5 million, and colocation on the public page 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 numbers reveal Ehost's economic design. Shared hosting spreads a server and support operation across many customers. Cloud packages measure 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 reliable price. Thebusiness hosting order categorycontains a striking anomaly: "Business-02" is displayed at 1.35 billion dong for three months, while neighbouring packages are in the hundreds of thousands. The same page lists legacy PHP and MariaDB versions. It would be unreasonable to treat the billion figure as Ehost's intended rate without confirmation; it is better understood as evidence that the storefront can contain data-entry or lifecycle inconsistencies.

Colocation shows a broader reconciliation issue. Thepublic colocation pagelists 1U packages at VNPT Data, Viettel IDC, and CMC for 3.2 million, 2.8 million, and 1.8 million dong per month, typically with 200 Mbps domestic network and 30 Mbps international bandwidth shared. Thebilling portal 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. Locations, capacities, and prices are not equivalent.

There may be a legitimate explanation: different rack generations, promotions, power allocations, commitment terms, legacy offerings, or market access routes. The pages do not provide one. A buyer comparing only the headline monthly price may therefore buy a different class of service from what was assumed.

Total cost should include at least:

• initial migration, OS setup, and application validation;
• VAT and all other applicable taxes;
• minimum commitment and renewal conditions;
• public IPv4, bandwidth, international traffic, and DDoS options;
• control panel, Windows, database, or other software licences;
• backup capacity, retention, and restoration fees;
• managed support or remote hands;
• downtime for hardware replacement or upgrade;
• domain, certificate, and email dependencies;
• export, transfer, and transition assistance at exit.

"Unlimited bandwidth" also requires definition. Several Ehost pages use this term while separately publishing port speeds or international bandwidth. Unlimited may reasonably mean no usage-based transfer fees, not infinite throughput or a dedicated circuit without contention. The contract must distinguish port speed, committed information rate (CIR), 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 cost at comparable service against competitors. It suffices to show that price comparison must start 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 "Daily full backup" 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 state data is triplicated in real time and backed up weekly, with backups retained for two months. A separateCloud Backupservice sells 10 to 100 GB of storage and says it can back up an entire disk so an OS and applications can be moved to replacement hardware. It advertises 24/7/365 technical support and monthly billing.

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

OpenStack's own backup and recovery guide makes the missing questions clear: backup frequency must follow acceptable data loss; retention and off-site storage matter; and recovery testing is as important as copy existence. Ehost's public statements do not disclose backup location, immutability, encryption, administrative separation, deletion policy, recovery time objective, 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 amount of data that could be lost per 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 measured.
5. Isolation:whether copies survive compromise of the production account, cluster, or site.
6. Restoration method:full machine, file-level, database-level, and restore to alternate location.
7. Fees:included restores, emergency fees, and data egress costs.
8. Proof:scheduled customer restore tests with recorded results.

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

A five-minute response is not a five-minute recovery

Ehost's support surface is visible. The main site provides phone and email contacts; the support portal offers tickets, knowledge base, announcements, downloads, and server status. Theservice warranty pagestates support operates 24/7 and customers will be notified by email, phone or direct contact when maintenance requires time. The dedicated server and game server pages claim a five-minute response via ticket, email, hotline, or live chat.

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

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

The support portal provides an intriguing but limited observation. At time of access, 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 time of review, so the affected service, start time, severity, customer impact, and resolution could not be established. This is not proof of a material outage. It is proof that a status mechanism exists but did not produce a usable public incident record.

No complete public status history, post-incident archive, or independently measured availability series was located. Absence of a public archive does not mean Ehost has no incidents or internal records. It means a buyer must request them. Useful diligence would include the previous twelve months of availability per product and site, severity-one incident reports, 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? What emergency actions are exempt? Is maintenance excluded from availability calculations? Can the customer reschedule? Does Ehost migrate virtual machines or shut them down? What happens to an unmanaged OS that does not reboot 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, escalation is tested, and the restoration obligation is clear.

Security is several products, not a single shield

Ehost's security language covers physical firewalls, shared hosting isolation, basic AntiDDoS, paid DDoS mitigation, SSL certificates, backups, and support. These controls address different threats and should not be blended into a general claim that a workload is "secure".

The cloud page states each cluster has a physical firewall and virtual machines can be integrated with Antiddos.vn. The business hosting page states basic AntiDDoS can automatically enable firewall protection against smaller botnets. TheAntiDDoS sitedescribes several proxy and firewall nodes distributed across Vietnamese datacenters, filtering malicious requests and providing HTTP/2 and web application firewall features. Ehost'sAntiDDoS order categorypublishes plan labels and some request volume parameters.

These are business claims about service design, not independent validation of mitigation capability. Procurement must 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 redirected; what scrubbing bandwidth is committed; whether source IPs are preserved; how TLS keys are handled; what happens to non-web protocols; whether attacks trigger additional fees; and whether the origin remains directly reachable.

Network resource evidence adds another limit. RPKI-valid prefixes help prevent unauthorised route origins. They do not filter malicious application requests, stop credential theft, patch a customer OS, or protect a database from an over-privileged account. Conversely, a web proxy may absorb HTTP attacks while leaving mail, VPN, game, or database services exposed.

Account security is also under-documented. The public record examined 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 reporting path is also unclear. APNIC-derived records identify VNNIC's incident response contact rather than a clearly advertised Ehost abuse desk, and the main site exposes business and support contacts rather than a dedicated abuse policy. This does not prove Ehost lacks internal process. It means an external reporter or customer cannot easily verify the report path for malware, spam, phishing, copyright, or network abuse. A hosting provider should be able to show receipt, verification, evidence preservation, customer notification, suspension standards, and appeal.

Vietnam's official legal database lists thePersonal Data Protection Law 91/2025/QH15as effective from January 1, 2026. Application of this law depends on facts and must be assessed by qualified counsel. For Ehost buyers, the practical requirement is simple: the contract must identify processing roles, access support, data location, sub-processors, incident cooperation, retention, deletion, and export for the actual service.

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

The lifecycle warning in the storefront

The public catalogue contains signs that product information has aged unevenly. The shared hosting pages describe support for PHP versions 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.

These versions are not current. PHP's unsupported branches table records 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's version maintenance table places MariaDB 10.1 maintenance end in October 2020.

The responsible interpretation is not that Ehost definitely runs end-of-life software exposed in production. The pages may be outdated while the platform has been upgraded. This distinction must be tested. Outdated 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 each shared hosting pool: OS, web server, control panel, PHP branches, database version, TLS configuration, patch cadence, and planned deprecation dates. They should confirm whether customers can select unsupported versions for legacy applications and, if so, what isolation and risk conditions apply.

Control panels add a third-party lifecycle dependency. Ehost sellsDirectAdmin licencesand states that some "internal" licences are available only for servers hosted at Ehost, with multi-month minimum payment. A customer who combines Ehost compute, an Ehost-supplied licence, DNS, certificates, and backups may benefit from convenient all-in-one support. It also creates a bundle that must be untangled at 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 a uniform fleet. That is normal for a long-running hoster, but placement policy matters. The buyer should know whether a plan maps to a defined CPU generation and storage class or to whichever pool has capacity.

Lifecycle governance should cover more than versions. It should specify notice for host migrations, control panel changes, OS image retirement, hardware end-of-life, IP renumbering, certificate brand changes, and discontinued packages. The support portal even contains a category called "EOL", though its content was 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 in several markets at once. In shared hosting, it faces local hosters and website platforms. In virtual machines, it faces Vietnamese telecom clouds, specialist VPS providers, and global hyperscalers. In dedicated servers and colocation, it faces datacentre operators, system integrators, and direct facility contracts. For backup, CDN, and DDoS, customers can buy specialised service independently.

Ehost's most credible advantage is not global scale. It is the possibility of a local operational relationship: packages in VND, phone and ticket contact, migration assistance, Vietnamese facilities, simple bundles, and a single provider for hosting, server, rack, and protection services. A small business 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 a 99.99% SLA, IPv6 support, a broader managed services catalogue, and named security certifications. These are VNPT's own claims, not independent proof that every workload will perform better. They illustrate the procurement comparison Ehost must support: 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 may also introduce foreign currency exposure, complex pricing, remote support, and an architecture that a small customer struggles to operate. A self-managed server in colocation offers maximum hardware control but shifts patching, spare parts, and recovery to the customer. A managed software platform may eliminate server administration but increase application-level lock-in.

The correct competition test is therefore workload-specific:

• For a brochure site, shared hosting may be cheaper and simpler than 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 conditions may outweigh headline price.
• For a globally distributed application, IPv6, international paths, autoscaling, and multi-region design may dominate local support.
• For a latency-sensitive game, CPU clock, DDoS response, domestic peering, and packet loss under attack matter more than generic "cloud" branding.

The only independent customer discussion older than this year found in the examined public record, aVietnamese hosting forum thread, contains a favourable anecdote about Ehost's service and support. It is several years old, informal, and non-representative. Ehost's own site also publishes positive testimonials without enough detail to verify identity, product, or date. Neither should replace current references from customers running a comparable workload.

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

Switching costs accumulate 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 an Ehost-assigned IPv4 may need to be renumbered when it leaves. DNS can hide some of the change, but allow lists, VPN peers, payment systems, email 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, entity metadata, backup history, or provider-side encryption details. The eStorage page does not publish an export API or egress schedule. A restore that only works inside Ehost is a continuity protection, not portability.

The third layer iscontrol software. cPanel or DirectAdmin configurations, email accounts, reseller hierarchies, certificates, and scheduled tasks must be rebuilt or converted. An internal licence tied to Ehost hosting may terminate when the server moves, requiring a new licence and possibly a control panel migration.

The fourth layer isnetwork protection. If a domain points through a DDoS proxy or CDN tied to Ehost, exit requires a DNS change, certificate and origin reconfiguration, log export, and careful withdrawal of the old path. Migration under attack is particularly challenging 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 resides in tickets rather than customer documentation, a successful support relationship creates dependency.

Colocation has physical exit costs. The customer needs authorised access, a maintenance window, packing, transport, data destruction for retired media, and a new route. If Ehost provides IP space or remote hands, those services end with the machine move.

Public evidence does not provide a complete termination, export, or deletion policy. Ehost's home page states there is a refund policy when a service is not used, and the personal hosting FAQ states unused value may be credited upon upgrade. The warranty page deals with support and maintenance. None of these pages establish refund eligibility, termination notice, data access duration, export format, deletion proof, or transition assistance for all services.

An exit schedule should be agreed before service commencement. It should give the customer current exports and snapshots; sufficient read access; DNS and domain transfer procedures; mailbox migration support; ticket and log history as applicable; a timeline for provider access removal; deletion confirmation; hardware release steps for colocation; and predictable fees. The customer should rehearse at least one restore or migration to another environment while the relationship is healthy.

A procurement test matched to Ehost's actual surface

Ehost should be evaluated with evidence matching 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 differences between the public Cloud Server page, the SSD Cloud Server store, and the C6 store. Demand a signed configuration schedule. Do the same for public and billing portal colocation packages. Confirm taxes, commitment, renewal, refund, restoration, and upgrade fees.

2. Prove the delivered machine

During a trial, record CPU model and stolen time, available memory, usable disk, sustained and burst IOPS, latency under load, interface throughput, and domestic and international speed. Perform tests at multiple times rather than treating a single benchmark as warranty. Compare the result with the purchase order.

3. Map OpenStack failure domains

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

4. Test the route, not the datacentre list

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

5. Turn backup into a recovery exercise

Resolve the cloud retention seven or fourteen day conflict. Select a file, database, and full machine recovery. Delete or corrupt test data, then measure recovery point, operator response, restoration time, resulting consistency, and fees. Verify whether an off-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 reception. Contract distinct acknowledgement and restoration targets, escalation contacts, maintenance notice, and root-cause delivery. Obtain historical performance for the product and site purchased.

7. Inspect security and abuse controls

Test MFA, role separation, account recovery, and support identity checks. Examine 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 which were not publicly retrievable in this research. Confirm a dedicated abuse reporting path and evidence handling process.

8. Verify lifecycle and portability

Ask for current supported software versions and deprecation dates. Export a VM, a database, a mailbox set, a control panel account, and a 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 substantiate the promises it already makes: defined resources, high availability, backups, fast support, multiple facilities, security, and local operational care.

The unanswered questions are part of the product

The public record examined establishes more than is often visible for a local hoster. There is an exact company, live prices, active billing and support systems, a broad service catalogue, an autonomous system, five routed IPv4 prefixes, RPKI coverage, and responding 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, routing capacity, or factual availability. IPinfo's hosted domains estimate cannot be converted to customers because one customer may operate many domains and one domain may use only part of Ehost's service. A public prefix count cannot be converted to compute capacity.

It does not establish that the "Tier 3" facilities named in Ehost's 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% figure lacks a visible measurement framework and remedy, while the "absolute availability" wording on dedicated servers is not a credible substitute for limited 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 OpenStack version or topology.

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

These are not reasons to declare the company unsuitable. They are dimensions of 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 purchase obstacles until Ehost provides evidence.

What to watch next

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

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

Second,network development. Continued RPKI validity is positive. Public IPv6 announcement and a demonstrably diverse upstream or peering design would reduce the unanswered questions about reachability and lifecycle. If Ehost deliberately chooses to keep a single 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 restoration metrics would make the availability and backup claims testable.

Fourth,policy closure. Ehost's site links to privacy, terms, shipping, and warranty pages, and its support portal lists an EHOST services policy download. Publishing current, accessible conditions for refunds, acceptable use, abuse, data handling, support, SLA, backup, termination, and deletion would reduce negotiation costs for both parties.

Fifth,lifecycle discipline. A current software matrix, an OpenStack version policy, and a 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 convincing 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, support queues, and contract that lie behind it.

That is why the two Cloud 1G descriptions at 250,000 dong matter. They expose the exact point where a hosting relationship can become either controllable or ambiguous. If Ehost and the buyer can reconcile the specification, prove the routing and recovery path, allocate failure responsibility, and preserve an exit, the company's local breadth can be an advantage. If these questions remain in inconsistent web pages, the cheapest server has not yet acquired a reliable price.