Hoang Dieu Cloud Computing Company Limited sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Hoang Dieu Cloud Computing Company Limited is most concrete in official internet-number records. VNNIC's public IP-member list records "Công ty TNHH Điện toán Đám mây Hoàng Diệu" as DTDMVNCLOUD-VN with a 26 November 2024 member date, while APNIC's AS153416 record names DTDMVNCLOUD-VN, country VN, registered on 13 November 2024.
• The cloud-company allocation is real: APNIC's 160.191.244.0/23 record describes Hoang Dieu Cloud Computing Company Limited at 162 Thuong Duc Street in Hai Phong, and APNIC's 2001:df4:9c40::/48 record assigns a matching IPv6 /48 to the same named holder. Those records prove numbering resources, not an owned data-centre hall.
• The live route view is narrow. RIPEstat's routing-status view on 12 July 2026 showed AS153416 announced, two visible IPv4 /23s, 1,024 IPv4 addresses, no visible IPv6 route, 325 of 326 IPv4 RIS peers seeing the AS, and one observed neighbour. RIPEstat's neighbour view identified that neighbour as AS140810, which APNIC identifies as Megacore Technology Company Limited.
• The operating grade is deliberately downgraded. A company-tax listing at Masothue shows the same Vietnamese company name, tax code 0202261639, data-processing and leasing as the primary business line, an active date of 29 October 2024, and a temporary-business-suspension status in a page updated on 11 July 2026. The APNIC contact domain serverhoangdieu.pro is registered, but the public record does not show a usable customer storefront, service terms, facility list, status page, multi-site restore path or data-portability commitment.

The company is visible first as an IP member, not as a polished cloud platform

Hoang Dieu Cloud Computing Company Limited should be read from the network layer outward. The company name is not merely an SEO phrase or an unverified scrape. VNNIC's IP-member list includes "Công ty TNHH Điện toán Đám mây Hoàng Diệu" at row 218, gives the member handle DTDMVNCLOUD-VN, and records 26 November 2024 as the member date. APNIC's AS153416 record uses the same DTDMVNCLOUD-VN name and places the autonomous-system registration on 13 November 2024. APNIC's IPv4 and IPv6 records then tie the cloud-company name to one portable IPv4 /23 and one IPv6 /48.

That is enough to say Hoang Dieu Cloud Computing Company Limited has a real public numbering footprint. It is not enough to say it operates a mature public cloud service. The difference matters because a customer buying hosted capacity is not buying an ASN record. The customer is buying an application-visible result: a virtual server that boots, a reachable IP address, power and cooling behind the host, packet delivery through upstream networks, a human escalation path, usable billing records, backups that can be restored, and a migration path when a provider relationship changes.

The company-tax trail makes the picture more specific and more cautious at the same time. The Masothue listing for tax code 0202261639 gives the Vietnamese name CÔNG TY TNHH ĐIỆN TOÁN ĐÁM MÂY HOÀNG DIỆU, a Hai Phong address, representative BÙI NGỌC LIỆU, a 29 October 2024 operating date, and a primary line translated as data processing, leasing and related activities. It also lists computer wholesale, telecom-equipment wholesale, computer programming, system administration consulting and computer repair. Those business lines fit a company that might sell VPS, hosting, bare-metal access, infrastructure leasing or managed-service capacity. But the same page, updated on 11 July 2026, displays a temporary-business-suspension status. That status does not automatically erase the network route, because the ASN was visible on 12 July 2026. It does mean customers should not treat a routed /23 as proof that the legal and commercial account layer is healthy.

The public service surface is thin. APNIC's technical contact record for the cloud-company resources points to [email protected]; the serverhoangdieu.pro RDAP record shows a domain registered on 2 November 2024, expiring on 2 November 2026, at NameCheap with registrar nameservers. A similarly timed hoangdieuvps.pro RDAP record appears around the related Hoang Dieu physical-server resources. Those names help explain the contact trail, but they are not a customer contract. The public record reviewed for this article did not reveal a current retail site, plan table, terms of service, refund policy, outage page, support-ticket portal, facility disclosure, backup policy or data-export guide under the cloud-company name.

That absence is not the same as evidence of fraud or non-operation. Many small infrastructure sellers operate through direct sales, social channels, reseller panels, private billing systems or provider-to-provider arrangements. But the absence sets the article's posture. Hoang Dieu Cloud Computing Company Limited can be analysed as a network-resource holder and possible hosted-capacity seller. It cannot yet be analysed as a fully documented cloud platform with public claims about regions, availability zones, server classes, restore objectives or support levels.

The location evidence points to Hai Phong, but not to a verified data hall

APNIC's 160.191.244.0/23 record describes Hoang Dieu Cloud Computing Company Limited at "162 Thuong Duc Street, Nguyen Hue Residential Group, Minh Duc Ward, Do Son District, Hai Phong City, Vietnam." The 2001:df4:9c40::/48 record repeats the same company description and address. Masothue gives the same street and residential group, with a tax-address variant that refers to Phường Nam Đồ Sơn and a business address that refers to Phường Minh Đức, Quận Đồ Sơn. That administrative difference is not the central issue. The central issue is that both versions are company-address evidence, not facility evidence.

A registered address can be a head office, residential address, tax address, sales office or administrative contact. It is rarely enough to identify the rack that hosts customer workloads. If Hoang Dieu Cloud Computing Company Limited sells cloud, VPS, bare-metal or managed-service capacity, the machines behind that capacity still need a physical home. They need space in a data centre or equipment room, stable power, cooling, access control, fire suppression, transit or transport, switching, routing, remote hands, hardware stock and a process for replacing failed components.

None of the public records names the data-centre operator, campus, rack count, cabinet power density, cross-connect count, UPS design, generator arrangement or remote-hands service level.

The two Hoang Dieu-named resource sets make the boundary question sharper. APNIC's 160.191.242.0/23 record describes Hoang Dieu Physical Server Company Limited, while the cloud-company /23 is 160.191.244.0/23. APNIC also records 2001:df4:9bc0::/48 for the physical-server company and 2001:df4:9c40::/48 for the cloud company. RIPEstat and secondary route directories show both IPv4 /23s currently originated by AS153416. This article does not treat that second holder as a customer, parent, subsidiary or separate operating event. It treats the observation as an operator-boundary caveat: the same visible ASN edge is carrying more than the cloud-company block, so a buyer should ask which legal party, facility contract and support team sits behind the exact service being ordered.

There is also a capacity-reading trap. A /23 provides 512 IPv4 addresses before reservations, routing design, infrastructure addresses and customer allocations. Two /23s provide 1,024 addresses. That is useful and scarce capacity in the hosting market, but it is not equivalent to 1,024 usable customer servers. Some addresses may sit idle, be reserved for routers and management interfaces, be used by NAT, be assigned to shared-hosting names, sit behind protection systems, or be held for future service.

An IPv6 /48 is much larger on paper, but RIPEstat's AS-level route view did not show any visible IPv6 prefix for AS153416 at the checked time. A customer needing IPv6 should therefore ask for a working allocation and a test route, not merely accept the registry allocation as proof.

The best way to read the physical location is conservative: the company is Vietnamese, the resource registration points to Hai Phong, and the route is visible from public collectors. The actual machines may sit in a Vietnamese facility, on leased racks, with Megacore or another upstream-linked operator, or in a provider environment not named in the public record. Without a facility name or contract evidence, data locality remains a claim to verify service by service.

Current routing proves a live edge, but also a single visible upstream dependency

On the network side, AS153416 is live. RIPEstat's AS overview reported the holder as "DTDMVNCLOUD-VN - Hoang Dieu Cloud Computing Company Limited" and marked the AS announced on 12 July 2026. RIPEstat's announced-prefixes view listed two IPv4 prefixes, 160.191.244.0/23 and 160.191.242.0/23, visible during the 28 June to 12 July 2026 window. RIPEstat's routing-status view showed one first-seen route on 6 December 2024, two IPv4 prefixes, 1,024 IPv4 addresses, no IPv6 announced space, and 325 of 326 IPv4 RIS peers seeing the AS.

The route-origin security signal is positive. RIPEstat's RPKI validation result for the cloud-company /23 returned valid, with AS153416 authorized for 160.191.244.0/23 at max length /23. The 160.191.242.0/23 RPKI result was also valid. Valid RPKI does not keep a server online during a disk failure, power event or unpaid bill, but it is still material. It lowers the risk that networks enforcing route-origin validation will reject the route as unauthorized.

The dependency question sits one hop upstream. RIPEstat's ASN-neighbours view saw one unique neighbour for AS153416 on 11 July 2026: AS140810. RIPEstat's AS overview for AS140810 identifies that neighbour as "MEGACORE-AS-VN - Megacore Technology Company Limited," and APNIC's AS140810 record identifies Megacore as a Vietnam network registered in 2021. RIPEstat's BGPlay samples repeatedly show paths ending through AS140810 before AS153416. RIPEstat's AS-routing-consistency view also shows imports and exports with peer 140810 in BGP.

That does not prove AS140810 is the only commercial provider. Collector views can miss private backup links, temporarily idle sessions, blackhole communities, IX-only paths or provider relationships not visible at the query time. But the public route view is the evidence a risk analyst can see. One visible upstream neighbour means the customer should ask whether the Hoang Dieu cloud service has a second physically diverse route, whether that route is active or only planned, whether the backup path can carry customer load, and whether Megacore controls the racks, transport, handoff or route policy for the service.

The absence of a public interconnection profile reinforces the same point. A PeeringDB API query returned no public network entity for AS153416 at the checked time. PeeringDB absence is not a fault. Many small networks never publish a profile. But it means there is no public exchange list, facility list, peering policy, looking-glass link or NOC contact there to corroborate a multi-site design. Secondary route directories such as IPregistry and IPIP describe the same core shape: AS153416, the cloud-company name, two IPv4 /23s, two IPv6 /48s in registry-derived views, and the visible connection pattern. They are useful corroboration, not substitutes for a signed SLA or a facility diagram.

This is the clearest technical conclusion: Hoang Dieu Cloud Computing Company Limited has a live public route edge. It does not have a public route posture that proves transit diversity, IPv6 service availability, anycast, distributed regions, self-operated facilities, independent power domains or a tested restore path.

Hosted capacity is an economic promise before it is a technical entity

The planned service class is customer-facing cloud, hosting, VPS, bare-metal or managed-service capacity. The public evidence does not reveal Hoang Dieu's product catalogue, but the business lines and route resources point to the same risk pattern as a small hosting provider. A seller can market CPU cores, RAM, disk space, IPv4 addresses, bandwidth, DDoS filtering, remote console access and monthly billing. A customer can receive a VM or physical server quickly. The question is whether the advertised resource survives the ordinary failure paths that cheap hosting tends to hide.

The first path is the host node. A VPS is only usable while the server under it has power, cooling, storage, memory, network cards, a hypervisor and a management plane. A bare-metal customer depends on the same inputs, plus remote hands and spare parts. If a disk dies, the service is restored only if someone has a replacement disk, authorization to open the machine, a current backup or disk image, and a path to move the customer to another node. No public source names Hoang Dieu's hardware inventory, hypervisor stack, storage layout, backup cadence or remote-hands arrangement.

The second path is the rack and facility. The company address is in Do Son, Hai Phong, but the rack could be in a carrier room, a third-party data centre, a Megacore-linked facility, or another Vietnamese hosting environment. The difference is not cosmetic. Facility ownership or leasing determines who can replace power strips, approve new cross-connects, schedule maintenance, move a server, fix an access-card problem, or recover a host during a building incident. If the facility contract belongs to another party, Hoang Dieu's customer support can be responsive while still waiting for someone else to act.

The third path is transit. RIPEstat's public view makes AS140810 the visible neighbour. If a Megacore circuit, route policy, filtering rule or billing dispute interrupts AS153416's reachability, customers may see a network outage even if their servers remain powered. If AS153416 has a hidden backup path, customers need to know whether it is tested. If it does not, the single visible upstream is a common-mode risk. It means one upstream boundary can affect both Hoang Dieu IPv4 /23s currently seen from AS153416.

The fourth path is address reputation and abuse handling. Hosting networks with small IPv4 pools can be sensitive to spam, scanning, proxy abuse, copyright complaints, bot traffic and policy filtering. APNIC lists VNNIC's abuse contact through IRT-VNNIC-AP, while the cloud-company technical contact in APNIC is NTT52-AP, using the serverhoangdieu.pro address. A customer needs to know who answers abuse notices, who can request delisting, who controls reverse DNS, and whether an abuse suspension affects only one VM, one IP, one prefix or the whole customer account.

The fifth path is billing and legal continuity. Masothue's temporary-suspension status is a weak but material commercial signal. It may reflect a formal pause, an administrative update, a data mismatch or a tax status that is not synchronized with network operations. It should not be overstated. Yet a customer buying capacity needs to know whether invoices are being issued by the same legal party, whether contracts are enforceable, whether paid service periods are honored, and whether account access survives a business-status change.

A routed AS can stay visible while a customer loses the ability to renew, receive tax documents or migrate data cleanly.

Hosting economics are built around exactly these boundaries. Low-cost capacity is possible because providers pool hardware, oversubscribe bandwidth, standardize plans, limit credits, pass through upstream terms and avoid expensive redundancy that customers did not pay for. There is nothing inherently wrong with that arrangement. The risk is that buyers often read "cloud" as if it automatically means multi-site redundancy, elastic capacity and graceful failover.

For a thin-footprint network such as Hoang Dieu Cloud Computing Company Limited, the safer assumption is the opposite: each resilience feature must be requested and evidenced.

Data sovereignty is a contract question, not a country code on an IP block

Vietnamese cloud and hosting capacity can be attractive to customers that want domestic routing, local-language support, Vietnamese invoicing, lower latency to Vietnamese users, or a data-location argument under Vietnamese rules. The broader policy context matters. The U.S. International Trade Administration's note on Vietnam cybersecurity data localization requirements explains that Decree 53/2022/ND-CP implements parts of Vietnam's Cybersecurity Law and took effect on 1 October 2022. LuatVietnam's English page for Decree 13/2023/ND-CP records Vietnam's personal-data-protection decree taking effect on 1 July 2023.

This article is not legal advice, and Hoang Dieu's public record does not say which regulated workloads it accepts. The practical point is narrower: if a customer needs Vietnamese data locality, the customer cannot infer that from "VN" in APNIC alone. A registry country code, VNNIC membership and a Hai Phong company address are relevant signs. They do not say where the host node sits, where backups sit, where the billing database is stored, where support tickets are processed, whether a remote administrator is outside Vietnam, whether logs are replicated abroad, or whether a third-party provider can move the workload.

The IPv6 evidence shows why the distinction matters. The cloud company has APNIC-assigned IPv6 space, 2001:df4:9c40::/48, but RIPEstat's route status for AS153416 reported no visible IPv6 announced space on 12 July 2026. A customer that needs IPv6-enabled Vietnamese hosting should ask for a test address, traceroute evidence, reverse-DNS control, firewall policy and support commitment. A registry allocation is only the right to use numbering resources; service availability depends on route announcement, router configuration, upstream support and customer provisioning.

The same applies to backups and migration. If Hoang Dieu sells a virtual server with a Vietnamese IP address, the workload can still depend on a provider control panel, an image repository, an offsite backup, a payment gateway or a support mailbox outside the rack. If the customer needs to prove locality, the relevant evidence is a service order, a facility address, a data-processing appendix, a backup-location statement, and an export path. A public route alone cannot answer those questions.

Data locality also intersects with failure recovery. A customer may choose a Vietnamese host to keep data close to users and regulators, then discover during an outage that the only practical restore path is to a foreign cloud account, a different Vietnamese provider, or a new block of addresses that breaks allowlists. The public Hoang Dieu record does not disclose restore targets. It does not show snapshots, offsite replicas, entity-storage regions, backup retention or customer-controlled image export. For a regulated or business-critical workload, those omissions are not minor. They are the main diligence task.

What unofficial signals can and cannot prove

Secondary route pages add useful hints, but they should stay in their lane. IPregistry's AS153416 page describes Hoang Dieu Cloud Computing Company Limited as the AS153416 organisation, lists the two IPv4 prefixes and two IPv6 prefixes, and states that AS153416 connects through at least one upstream provider with no direct peering agreements shown. IPIP's AS153416 page shows the same AS name, cloud-company description, 1,024 IPv4 addresses, and registry-derived whois text. These pages help a reader see the resource layout quickly.

They cannot prove customer count, revenue, hardware ownership, availability, abuse rate, support quality, or whether an actual VPS product is for sale today. They also cannot settle the relationship between the cloud-company and physical-server resource sets beyond what routing and registry records show. A secondary route directory may count registry resources as "announced" or display IPv6 ranges even when a specific collector view does not show IPv6 from the ASN at a given time. That is why this article relies on APNIC and RIPEstat for the core resource and visibility claims, and uses secondary route pages as corroboration only.

The non-resolving customer-surface signal should also be bounded. The serverhoangdieu.pro and hoangdieuvps.pro domains are registered, and the APNIC contact email uses serverhoangdieu.pro. A visible web shop was not available through those names during the local checks supporting this article. That suggests the company may not be operating a conventional self-serve storefront under those domains. It does not prove that email is dead, that direct sales are inactive, or that no customers exist.

The decisive evidence would be current DNS records, a reachable service portal, signed customer terms, invoice samples, support responses, route tests and actual service orders.

Masothue's temporary-suspension status belongs in the same careful category. It is a significant public listing because it is tied to the tax code, business name, address, representative, business lines and update date. But it is still a third-party company-tax page. It should be used to flag commercial due diligence, not to claim that AS153416 has stopped operating. The route was visible after the listing's update timestamp. The open question is how legal status, invoicing and customer support align with that continuing route visibility.

The difference between "signal" and "proof" is practical. A buyer should not reject or accept Hoang Dieu Cloud Computing Company Limited solely because a route collector sees an ASN or because a tax listing shows a status warning. The buyer should ask for a current quotation, company registration evidence, tax invoice details, service terms, facility location, upstream design, backup statement, support escalation and test IP. If those materials exist and align, the public gaps become manageable. If they do not, the public gaps are the risk.

Failure paths to test before relying on the service

The rack failure path is first. Ask where the server will sit, who owns the cabinet, who owns the hardware, what power redundancy exists, what remote-hands provider can replace disks or memory, and whether there is a spare node with enough capacity to receive the workload. Ask whether a VM can be restored to a different host without changing IP address. Ask whether bare-metal customers receive out-of-band management and whether the provider can reinstall the machine without waiting for third-party approval.

The upstream failure path is second. AS153416's public view shows one visible neighbour, AS140810. Ask whether there is a second upstream, whether it is physically diverse, whether both /23s are announced through both paths, whether RPKI ROAs cover the exact prefixes, whether route changes are tested, and whether customers are notified before planned maintenance. The current RPKI status for both visible /23s is valid, which is good. It does not answer the physical diversity question.

The hardware-stock path is third. A small address footprint can support a real service, but it often means tight inventory. Customers should ask whether advertised CPU, RAM, SSD and port claims are tied to in-stock machines, leased capacity, a provider marketplace or a future procurement. A server offer that depends on a single old chassis has a different repair profile from a cluster with spare drives and warm standby capacity. The public Hoang Dieu record does not disclose which case applies.

The support path is fourth. APNIC lists NTT52-AP as the administrative and technical contact for the cloud-company resource, with Nguyen Thi Trang, a Vietnamese phone number and [email protected]. It lists IRT-VNNIC-AP as the abuse contact. Those records are useful for registry contactability. They do not show a customer-facing support desk, hours, response targets, escalation tiers, incident communication, refund rules or maintenance notice history. A buyer should test support before moving production traffic.

The billing path is fifth. The risk is not only non-payment. It is account mismatch: a customer pays one party, receives service on AS153416, and needs tax or support documents from another party. The Masothue status warning makes that worth verifying. Customers should ask which legal entity signs the order, whether the tax code is active for invoicing, what happens during a business-status change, whether service can be suspended without data export, and how long backups are retained after non-payment or cancellation.

The migration path is sixth. IPv4 addresses in 160.191.244.0/23 are not portable to the customer unless a written arrangement says otherwise. If a customer builds firewall allowlists, mail reputation, API partner access or VPN tunnels around those addresses, moving away may require renumbering. If the customer uses a VM image, they should ask whether the image can be exported, in which format, at what cost and within what retention window. If the customer uses a physical server, they should ask whether disk images are available or whether migration depends on copying files over the network before cancellation.

The provider-contract path is seventh. If AS153416 depends on AS140810 for visible reachability, then Megacore's maintenance, filtering, commercial terms and route policy can affect Hoang Dieu customers. The customer does not need to see every upstream contract, but the customer should know who is responsible when a route disappears, a prefix is filtered, a DDoS event triggers mitigation, or an upstream asks for abuse cleanup. The support answer "we are waiting for provider response" is not a resilience plan; it is a handoff.

Who is affected when the route, rack or account layer fails

The public record does not identify Hoang Dieu Cloud Computing Company Limited's customers, so the affected-user analysis has to stay generic. Still, the failure surface is easy to map. Anyone using an address in 160.191.244.0/23 for a website, API endpoint, VPN concentrator, proxy node, game server, development environment, file store, DNS service, monitoring endpoint or customer panel depends on the same basic chain: host power, local switching, AS153416 routing, AS140810 reachability, abuse filtering and the commercial account that keeps the service assigned.

If any one of those layers fails, the visible symptom may be the same to the user: the IP address stops responding.

For a small website or test server, that may be tolerable. The owner can move DNS, restore from a local copy, or accept downtime while support replies. For a production endpoint, the effect is broader. Firewalls, API partners, payment systems and enterprise VPN rules often trust a fixed IP address. If a customer must renumber away from Hoang Dieu's block during an outage, the work is not just copying data. It includes DNS TTL timing, SSL certificate checks, reverse-DNS changes, partner allowlist changes, application configuration, log retention and sometimes reputation rebuilding.

The smaller the customer team, the more a simple route or billing incident becomes an operational interruption.

Mail and abuse-sensitive workloads are especially exposed. A /23 can carry many unrelated users if it is sold as VPS or proxy capacity. One compromised server can draw spam complaints, blocklist entries or filtering attention that affects neighbouring customers. The public APNIC trail gives an abuse path through VNNIC, but it does not show the provider's private abuse handling, customer notification policy, reverse-DNS rules or delisting procedure.

A customer that needs outbound mail, clean API calls or stable search-crawler access should ask whether the assigned address has recent reputation history and whether the provider separates high-risk uses from ordinary hosting.

Resellers face another layer of risk. If a reseller buys a block of small VPS instances or dedicated servers from Hoang Dieu and sells them under another brand, the end customer may never see AS153416 or the Hai Phong company name. During a failure, the reseller's support desk depends on Hoang Dieu's support desk, which may depend on Megacore or a facility operator. Every handoff adds time and ambiguity. The reseller should therefore know whether it has direct escalation, service credits, notification rights, and permission to export customer images or transfer IP-dependent services if the upstream arrangement changes.

Vietnam-locality buyers have a different exposure. They may be choosing a Vietnamese provider to keep latency low or to keep data handling aligned with Vietnamese rules. If the service fails and the emergency restore lands on a foreign cloud or a foreign backup host, the customer may solve uptime while creating a locality problem. If the provider cannot state where backups are stored or where support administrators sit, the customer cannot rely on the Vietnamese route alone as proof of locality. The route can be Vietnamese while the recovery path is not documented.

The route-level blast radius is also asymmetric. RIPEstat saw both IPv4 /23s originated by AS153416 and one visible upstream neighbour. If a single host node fails, the effect can be one customer or one small cluster. If the upstream handoff fails, route policy breaks, or an upstream-level filter catches the ASN, the effect can cover every service reachable only through that visible path. If billing or legal status prevents renewals or customer support, the effect may unfold slowly: first no new orders, then unpaid upstream invoices, then suspension or withdrawal.

Customers usually discover which layer failed only after the fact unless the provider publishes maintenance and incident communications.

The practical control is to ask for a rehearsal. A serious customer should not only ask "Do you have backups?" It should ask the provider to restore a test VM, move a test service to another host, confirm the IP remains assigned, show a support escalation path, and state how long data remains accessible after cancellation or suspension. A serious customer should not only ask "Do you have redundant transit?" It should ask whether both routes are active, which routes carry the exact prefix, and whether a maintenance window has ever failed over successfully.

Without that rehearsal, the service may be fine for ordinary days and fragile on the only day that matters.

The evidence threshold for a stronger grade is clear

Hoang Dieu Cloud Computing Company Limited does not need a large marketing site to be a useful infrastructure seller. Many regional providers are small, direct and technically competent. What it does need, if it wants customers to rely on it for business workloads, is evidence that connects the visible route to a repeatable operating setup.

The first evidence item would be a current customer-facing service surface: a reachable website or portal, plan descriptions, legal terms, refund and cancellation terms, support channels, abuse rules, privacy terms and a clear statement of which legal entity is contracting. The second would be facility and route disclosure at an appropriate level: not a sensitive diagram, but enough to tell customers whether the service is in one site or multiple sites, whether Megacore is the only active transit path, whether maintenance is announced, and whether there is a tested backup route.

The third would be backup and restore disclosure. A credible hosted-capacity offer should say whether backups are included, where they are stored, how often they run, how long they are retained, how customers request restore, what a restore costs, and whether a customer can export a VM or disk image. The fourth would be support evidence: ticket categories, response targets, escalation path, outage notice history and an abuse-contact path that reaches the actual operator. The fifth would be current legal and billing evidence resolving the temporary-suspension signal in the company-tax listing.

Until those materials are public or provided to a buyer, the safest reading is restrained. The network edge is real. The cloud-company resource allocation is real. The route is visible. RPKI is valid. VNNIC membership is visible. But the customer promise remains under-evidenced. Hoang Dieu Cloud Computing Company Limited's risk is not that the public record is empty; it is that the hard public record stops at the edge of the rack, contract and recovery path.

For users with low-criticality workloads, short experiments or disposable test servers, that may be acceptable after a direct sales check. For customers hosting client data, regulated records, production websites, VPN concentrators, API endpoints, mail systems or workloads that cannot tolerate sudden renumbering, the evidence threshold is higher. They should not buy "Vietnam cloud" from the country code alone.

They should buy a named service, in a named facility or provider arrangement, with a named support path, a tested route, an exportable backup and a written answer to what happens when the rack, upstream, hardware stock, billing state or provider contract fails.