Thanh Trang Cloud Computing and Technology Company Limited sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Thanh Trang Cloud Computing and Technology Company Limited was registered in Ho Chi Minh City in February 2024 and joined VNNIC's Internet address membership system in May 2024. APNIC records associate it with AS151934, the portable IPv4 block 157.66.252.0/23 and the portable IPv6 block 2401:9be0::/48.
• The IPv4 /23, containing 512 addresses, has been publicly originated by AS150820, registered to LienVPS Technology Company Limited, throughout its visible routing history. A valid route-origin authorisation covers that origin. Thanh Trang's own AS151934 currently announces no prefixes.
• At the 12 July 2026 observation point, all 333 collector paths in RIPEstat's BGP state for the IPv4 block reached AS150820 through AS18403 at the adjacent autonomous-system hop. That is evidence of a concentrated visible path, but it does not prove a direct contract, a single physical circuit or the absence of private or dormant alternatives.
• Thanh Trang's allocated IPv6 /48 had a valid authorisation for AS150820 but no globally visible announcement. Allocation and authorisation are therefore ahead of observable delivery. The company's public operational identity remains substantially IPv4-dependent.
• No cited public material identifies a data-centre building, rack operator, power topology, server inventory, storage design, support hours, service terms, backup arrangement, recovery site or customer migration process. The operating-evidence grade is Weak even though the corporate and number-resource records are concrete.

A cloud company with a visible block but an invisible rack

Thanh Trang presents a compact case study in the gap between an Internet identity and a delivered computing service. The legal and network records are real. They are also narrower than the company's English name.

Two Vietnamese company-information services identify the same legal core. VNBIS lists business ID 0318310564, registration on 22 February 2024, an active status, the Vietnamese name Công ty TNHH Công nghệ và Điện toán đám mây Thanh Trạng, and an address at 108 Tran Dinh Xu in District 1, Ho Chi Minh City. MyTour's company record names To Thanh Trang as legal representative and lists the principal activity as other information-technology and computer-related services. It also lists data processing and related rental among a wider set of registered activities.

The network records add a more concrete operating clue. VNNIC's Internet address member list names the company under THANHTRANG-VN and dates the allocation to 8 May 2024. The APNIC record for AS151934 carries the same company name and address. The IPv4 registration assigns 157.66.252.0 through 157.66.253.255 to Thanh Trang with ALLOCATED PORTABLE status. The IPv6 registration does the same for 2401:9be0::/48.

Those records establish a legal entity and its association with scarce, operationally useful number resources. They do not establish what the company sells today, how much it sells, where the equipment sits or which organisation can touch it. A registered activity is permission or scope, not proof of a live product. A portable address allocation associates a resource with its holder, not with a particular server. An ASN is a routing identity, not a data-centre certificate.

The distinction is especially important here because the public trace separates the holder from the visible route origin. A customer could plausibly receive service on a Thanh Trang-registered address while packets are originated, carried and physically hosted by several different parties. Conversely, the live block could serve purposes other than a retail virtual-machine catalogue. The evidence supports an infrastructure footprint. It does not support a complete service description.

That is why the right opening question is not whether Thanh Trang is "really" a cloud company. The public record cannot settle that broad label. The useful question is narrower: what dependencies can a buyer identify before placing data and applications on capacity associated with the company? The answer begins with routing, then moves down into the facility, hardware, people, contracts and exit paths that routing records cannot show.

The IPv4 space has always depended on another visible origin

Thanh Trang received its IPv4 block and ASN at roughly the same time, but the two resources have not appeared together in the global routing table.

The RIPEstat routing history for 157.66.252.0/23 shows AS150820 as the visible origin throughout the block's observed history from May 2024 to the 12 July 2026 endpoint. AS150820 is registered to LienVPS Technology Company Limited. The APNIC prefix record contains a matching route object for AS150820, last modified on 13 May 2024. By contrast, the RIPEstat overview for AS151934 marked Thanh Trang's ASN as not announced, and the announced-prefixes response returned an empty list.

This is not a sign that the IPv4 allocation itself belongs to LienVPS. Registration and route origination answer different questions. APNIC identifies Thanh Trang on the address range. BGP identifies AS150820 as the network telling the wider Internet that it can deliver traffic to that range. A resource holder may authorise another ASN to originate its prefix for many ordinary reasons: managed routing, transit, colocation connectivity, denial-of-service filtering, leased infrastructure or a larger wholesale service.

The origin is authorised rather than merely visible. The RIPEstat RPKI validation result reports a valid Route Origin Authorisation for AS150820, with a maximum prefix length of /23. Testing AS151934 against the same prefix returns invalid_asn under the current authorisation. That is a useful security control: networks performing origin validation can distinguish the authorised origin from an unauthorised one.

Authorisation does not disclose the commercial arrangement. It does not say whether Thanh Trang rents virtual machines from LienVPS, owns servers connected through LienVPS routers, buys a managed network service, or uses another arrangement altogether. It does not identify the facility, invoice, support boundary or duration of the agreement. It proves that AS150820 is allowed to originate the route, not that AS150820 assumes every customer obligation associated with it.

The fact that Thanh Trang's own ASN has not appeared as the origin in the available history makes this more than a temporary failover observation. The visible delivery design has been third-party-originated from the beginning. A buyer should therefore treat the origin-provider dependency as a foundational part of the service rather than an incidental backup path.

That dependency can work perfectly well. Small providers often obtain economies of scale by buying routing, facilities or hardware from larger specialists. The risk comes from opacity. If the retail promise and the underlying agreement differ on repair times, suspension rights, address use or termination, the customer's recovery clock follows the underlying dependency whether or not it appears on the retail invoice.

One observed path sits behind a globally visible route

A route can be visible around the world while still entering its origin through a concentrated edge.

At 13:59 UTC on 12 July 2026, the RIPEstat BGP state response for the /23 contained 333 collector paths. Every path ended at AS150820. Every path also placed AS18403 immediately before AS150820 after repeated AS-path prepending was normalised to the adjacent autonomous-system hop. AS18403 is associated in public routing records with FPT Telecom.

This is strong evidence about the route observed by RIPE RIS collectors at that moment. It is not evidence of a direct contract between Thanh Trang and FPT, and it does not identify a fibre circuit. BGP paths expose routing decisions between autonomous systems. They can conceal resellers, route servers, private interconnections, backup sessions and the physical geography of each hop. Repeated appearances of the same ASN in a path can also be deliberate prepending rather than multiple independent networks.

Still, the observation matters. There was no visible second adjacent autonomous-system path for this prefix in that snapshot. If a customer is told that the service has diverse upstream connectivity, the public route creates a precise follow-up question: where is the alternate path, and under what failure condition would it become visible?

The answer might be perfectly satisfactory. A backup could remain idle until failure. Two physical circuits could both terminate in AS18403. A private connection could carry selected traffic without appearing in collector best paths. Conversely, two BGP sessions can share one duct, one building entrance, one router or one commercial account. Autonomous-system diversity and physical diversity are related but not interchangeable.

RFC 4271 defines BGP as an exchange of network reachability and path attributes. It does not carry rack coordinates, fibre routes or service-level commitments. RFC 7454 describes operational practices around filtering and BGP security, while RFC 9234 adds roles intended to help prevent route leaks. None of those standards demonstrates which controls are deployed for Thanh Trang's block.

A useful redundancy statement would identify the primary and alternate handoffs, their physical entry paths, the routing policy that activates each one, the last failover test and the capacity available after failover. It would also distinguish a route-origin outage from an upstream outage. If AS150820's edge fails, a second transit behind the same origin may help. If AS150820 itself cannot originate the prefix, the recovery plan may require another authorised origin and a changed ROA. Those are different repair procedures with different clocks.

Until such evidence is available, the accurate conclusion is modest: the IPv4 prefix is broadly reachable, its origin is authorised, and its observed adjacent AS path is concentrated. That is enough to identify a dependency. It is not enough to declare the service either fragile or redundant.

IPv6 is allocated and authorised, but not delivered publicly

The IPv6 record is the cleanest example of why installed potential must not be confused with usable capacity.

APNIC allocates 2401:9be0::/48 to Thanh Trang with portable status. A /48 is large enough for a conventional customer or site allocation plan containing many /64 subnets. The APNIC record also contains a route object naming AS150820, and the RIPEstat RPKI validator reports a valid authorisation for that origin.

Yet the RIPEstat prefix overview marked the /48 as not announced on 12 July 2026. The detailed routing-history response contained no broadly visible route for the specific prefix. The paperwork needed for a valid origin exists; the route itself does not appear in the observed global table.

That distinction has direct customer consequences. A provider may own IPv6 resources without assigning IPv6 addresses to virtual machines. It may configure IPv6 internally without advertising it. It may advertise only to a limited set of networks below the visibility threshold. Or it may have prepared the registry and authorisation records for a deployment that has not happened. The public evidence cannot choose among those explanations.

What it can show is that a buyer should not infer dual-stack service from the existence of the /48. Dual-stack means more than placing an IPv6 address on an interface. It requires routing, filtering, monitoring, name resolution where relevant, security policy, support procedures and application testing across both protocol families. A service can be healthy over IPv4 and unavailable over IPv6, or the reverse. Security controls can also diverge if one protocol path receives less operational attention.

Vietnam's digital infrastructure strategy calls for broad IPv6 deployment, stronger domestic and international connectivity and more data infrastructure. Those national goals increase the strategic value of having an allocation. They do not make an unannounced prefix reachable.

For Thanh Trang, the evidence needed to upgrade the assessment is straightforward: a globally visible route, customer documentation showing address assignment, a reachable test endpoint, equivalent filtering controls, and a recorded response to IPv6 path loss. Without those, the IPv6 block should be described as allocated and authorised but not publicly operational.

The practical effect is continued dependence on the IPv4 /23 for the company's visible address presence. IPv4 scarcity can support a hosting business, but it can also create constraints around address reuse, reputation, migration and customer isolation. IPv6 would expand addressing flexibility. Its present absence from the public routing table means that flexibility cannot be counted as delivered capacity.

The Ho Chi Minh City address does not locate customer machines

Thanh Trang's legal and APNIC records both point to 108 Tran Dinh Xu in Ho Chi Minh City. That agreement strengthens identity matching. It does not turn the address into a data centre.

A registered office can hold staff, correspondence or management functions while customer systems run elsewhere. An APNIC contact address identifies the party responsible for number-resource records. Neither record says that utility feeds, cooling plant, racks or storage sit at the same location. The current BGP path does not close the gap because routing geography and physical hosting geography are different layers.

This uncertainty matters to any customer buying locality. "Hosted in Vietnam" can refer to the legal entity, the address registration, the public IP's country label, the primary disk, a backup copy, system logs or the engineers who can access the machine. Those are not equivalent. A customer trying to satisfy a contractual or regulatory location requirement needs to identify each relevant data copy and each access path.

Commercial IP-geolocation sites may label addresses in the Thanh Trang block as Hanoi or another Vietnamese location. Those databases infer location from registration, network measurements, commercial feeds and other signals. They are useful for broad traffic decisions but are not equipment inventories. A city label attached to 157.66.253.0/24 cannot prove which building contains a particular customer's disk.

A credible facility disclosure need not expose a rack number. It could identify the city, facility operator, service type and assurance level; state whether hardware is owned, leased or resold; identify who controls physical access; and name the separate site used for backup or recovery. If the provider relies on a wholesale platform, it could state that boundary plainly without disclosing commercially sensitive pricing.

Vietnam's broader infrastructure market offers many possible locations and suppliers. The Ministry of Information and Communications reported in 2024 that four large domestic providers accounted for most of the country's data-centre market and that the market was expanding. Its data-centre market summary is useful national context, not evidence that Thanh Trang uses any named operator.

The operating question is therefore not whether Vietnam has capable data centres. It does. The question is which facility and contractual layer support these particular addresses, and what happens when that layer fails. Until the company answers, the physical location of customer-facing capacity remains unverified.

A /23 counts addresses, not servers or customers

The 512 addresses in 157.66.252.0/23 are the most visible measure attached to Thanh Trang. They are also an easy number to misuse.

An IPv4 /23 spans 512 addresses. Conventional subnetting reserves some addresses in many arrangements, but providers can divide and use the range in numerous ways. One server can hold several addresses. Many virtual machines can share one public address through translation. Addresses can be reserved for routers, hypervisors, management, customers, mitigation, future use or quarantine. Some can be reachable without hosting a customer application.

The address count therefore says nothing reliable about server count, virtual-machine count, CPU cores, memory, storage, bandwidth or customer demand. It cannot show how much capacity is sold or how much remains after a host failure. The fact that independent network databases observe many addresses responding to probes is a sign of use, not a capacity audit. A responding address may be a shared front end, a firewall, a proxy or an intentionally uniform host response.

Hosting capacity has at least five useful layers. Installed capacity is the hardware nominally present. Allocated capacity is what software assigns to customers. Delivered capacity is what customers can use under ordinary contention. Survivable capacity is what remains after a host, switch, storage node, circuit or power feed fails. Recoverable capacity is what can be restored from backups or replacement equipment within an agreed time.

The public evidence provides no Thanh Trang figure for any of those layers. It does not identify a virtualisation platform, processor class, memory commitment, storage medium, oversubscription policy, network port or spare ratio. It also does not establish whether the company owns machines at all. The retail service could be built from owned hosts, leased bare metal, resold virtual machines or a mixture.

This is where hosting economics and resilience meet. A provider can improve prices by running hosts at high utilisation, buying wholesale capacity and keeping a small spare pool. Those choices are not inherently poor. They become risky when the service promise assumes more headroom, independence or repair authority than the underlying arrangement provides.

A buyer should ask for capacity in failure-state terms. How many customer workloads can restart after the largest host fails? Is memory committed or contended? Does storage remain writable during a node failure? How long does it take to source a compatible power supply or drive? Can an important workload move while the platform is already busy? Answers to those questions describe useful capacity. The /23 does not.

The rack, power and hardware chain sets the hard recovery limit

Every virtual machine depends on physical equipment even when the customer never learns its serial number.

The dependency chain begins with utility power and continues through switchgear, uninterruptible power systems, generators, cooling, fire controls, rack power distribution, server power supplies, network switches, storage devices and cables. A well-designed facility can still lose one rack to a failed power unit or one group of hosts to a top-of-rack switch. A maintenance error can defeat nominal redundancy if two paths share a hidden component.

No cited Thanh Trang material identifies a facility, power topology, rack arrangement or hardware inventory. It does not state whether customer instances use local disks, shared storage or replicated storage. It does not disclose compatible spares or the engineer who can install them. That absence prevents any responsible claim about fault tolerance.

Uptime Institute's Tier explanation is useful because it separates topology from operational sustainability. A facility design label does not by itself prove that maintenance, staffing and change control will keep a particular service available. There is no public evidence here of a Tier-certified Thanh Trang site in any case.

Ownership changes the repair clock. If Thanh Trang owns servers in colocation, it may control parts replacement while depending on the facility for power and access. If it leases bare metal, the lessor may control replacement. If it resells another host's virtual machines, it may have no physical access at all. Restoration then includes detection, retail support triage, supplier escalation, facility access, diagnosis, spare availability and repair.

NIST SP 800-125A Rev. 1 describes how a hypervisor mediates shared physical processor, memory, network and storage resources. NIST SP 800-125B addresses virtual-network segmentation, traffic control, redundancy and monitoring. These documents provide a framework for questions; they do not certify Thanh Trang's implementation.

The minimum useful disclosure would identify the service class and the failing unit. For a virtual machine, that means host-failure behaviour and storage recovery. For bare metal, it means replacement stock and rebuild time. For managed hosting, it also means operating-system and application responsibility. Each promise should name who can perform the repair and whether support access survives the same outage.

Without that information, a customer must assume that the longest dependency in the chain governs restoration. A one-hour retail response target is not a one-hour repair if the hardware supplier responds in four hours and the facility grants access later still.

Support and billing can fail while the servers remain healthy

Infrastructure failure is not limited to broken equipment. Control can be lost through people, accounts and contracts.

The APNIC records name an administrative and technical contact associated with Thanh Trang, but a registry contact is not a published 24-hour support desk. The company's domain appears in APNIC remarks and contact details, yet no cited public service page sets out support hours, ticket channels, severity levels, response targets or emergency escalation. The corporate sources do not disclose staffing.

That matters because diagnosis crosses organisational boundaries. A customer reports an unreachable machine. The retail provider must determine whether the fault lies in the guest, host, storage, rack switch, origin router, upstream path, facility or account. It must then reach the party with authority to act. If the service is assembled from several suppliers, the customer can receive technically correct but operationally useless answers from each boundary: the route is present, the host is powered, the facility is normal, or the account is under review.

Billing is another control plane. Automated fraud checks, disputed payments, expired cards, currency issues or an upstream invoice can suspend a service without any physical fault. If the provider's agreement allows immediate termination, customer recovery depends on backups and export rights rather than repair. If Thanh Trang's right to use the underlying capacity ends, the customer needs to know whether there is a cure period and who retains access to data.

Abuse handling can create similar pressure. Public abuse databases contain reports for individual addresses in the /23, but such reports are unverified observations about traffic, not findings against Thanh Trang or every user of the block. Shared and reassigned hosting addresses often accumulate reputation from previous tenants. What matters operationally is whether the provider can isolate one customer, preserve evidence, notify the affected account and avoid disabling unrelated systems.

A mature service agreement would distinguish network abuse, payment risk, legal demands and technical failure. It would state suspension thresholds, notice where lawful, data-retention periods, appeal routes and emergency contacts. It would also explain what happens when the retail provider and infrastructure supplier disagree about the cause.

No public evidence establishes those Thanh Trang terms. Customers should therefore keep their own account records, secondary contact route and independent monitoring. A status page hosted on the same network as the failed service is not enough. Neither is a single email domain if its name service or mail path shares the outage.

Backups are useful only when they sit outside the failure they answer

A provider snapshot can look like a backup while remaining exposed to the same host, storage, account and administrator.

The public record does not identify any Thanh Trang backup product, retention period, storage location, encryption control or restore test. It does not show whether snapshots are included, optional or absent. Customers must not infer protection from the word "cloud" or from the existence of a control panel.

NIST SP 800-34 Rev. 1 connects contingency planning with alternate storage, alternate processing, telecommunications and tested recovery. The CISA ransomware guide recommends offline or otherwise protected backups and regular restoration testing. These principles apply beyond ransomware: a copy must survive the failure it is meant to answer.

For Thanh Trang-associated capacity, the failure domains are not yet publicly mapped. A snapshot on the same storage cluster may help with an accidental file deletion but not a storage-controller failure. A replica in the same rack may help with a disk failure but not loss of rack power. A copy in the same customer account may survive hardware failure but not account compromise or suspension. A second service from the same wholesale platform may still share the original facility and support boundary.

Customers need two numbers: recovery point objective, the maximum tolerable data loss measured in time, and recovery time objective, the target time to restore service. Major cloud guidance such as the Google Cloud disaster-recovery planning guide and AWS reliability guidance explains the trade-off between faster recovery and greater cost or complexity. Those guides do not imply a relationship with Thanh Trang; they give buyers a common vocabulary.

A defensible backup plan would say where each copy is, who administers it, how credentials are separated, how often restoration is tested and what bandwidth is available during a large recovery. It would include configuration, keys and dependency data, not only virtual disks. It would also account for the case in which the provider's normal portal and billing account are inaccessible.

Until Thanh Trang publishes or contracts for such controls, customers should maintain an independently administered copy with a different failure and account boundary. The burden is higher for databases and stateful applications, where copying files without application consistency can produce a backup that exists but cannot be trusted.

Migration depends on formats, bandwidth, addresses and cooperation

Cloud portability is often described as a software concern. During a provider failure, it becomes a physical and contractual exercise.

A customer leaving Thanh Trang-associated capacity may need to export disk images, database dumps, entity data, configuration, secrets, firewall rules, domain records and logs. The provider must keep the source service available long enough to copy them. The destination must accept the format. The network must have enough egress capacity. Staff must be able to authenticate and support the transfer.

Public address portability does not automatically extend to the customer. The /23 is registered to Thanh Trang, not to each tenant. Even if the block can move between origin networks, a customer normally cannot take an assigned address to an unrelated provider unless a separate agreement and routing design allow it. Migration may therefore require new addresses, DNS changes, certificate updates, firewall changes, partner allowlists and reputation rebuilding.

The current RPKI arrangement makes one part of an origin change visible. AS150820 is authorised today. If a different ASN were to originate the /23, the resource holder or authorised administrator would need to create or adjust the ROA before networks enforcing origin validation accepted the route as valid. That can be a controlled migration when planned. During a dispute or sudden supplier failure, it becomes a governance dependency.

Data volume sets another hard limit. Moving one terabyte over a sustained 100 Mbps link takes roughly a day before overhead and interruptions. Large storage estates can take much longer. Exporting during an outage may compete with production traffic or storage rebuilds. A provider promising easy cancellation should therefore state egress limits, fees, export formats and the time data remains available after termination.

No cited Thanh Trang terms answer those questions. There is no public migration guide, image-export specification, data-deletion period or egress tariff in the material reviewed. That does not prove hostile lock-in. It means portability is unverified.

The best test is practical: restore a representative workload elsewhere before an emergency. Use a new address, re-create network policy, validate the database, rotate credentials and measure the elapsed time. A written exit plan that has never moved data is a hypothesis. A completed test exposes the missing dependencies while the original service still works.

Data locality requires a map of copies and access, not an IP country label

Vietnamese customers now operate under a more developed data-law environment than the one in place when Thanh Trang was registered.

Vietnam's Law on Data No. 60/2024/QH15 took effect in July 2025 and establishes broad rules for data activities. The Law on Personal Data Protection No. 91/2025/QH15 took effect on 1 January 2026 and defines obligations for parties controlling and processing personal data. The exact duties depend on the customer, data and processing arrangement, so buyers need legal advice rather than a generic hosting conclusion.

Infrastructure evidence can still identify the questions that advice must answer. Where is primary data stored? Where are snapshots and logs stored? Can a wholesale supplier or remote engineer access them? What subprocessor handles support or mitigation? What happens to copies after termination? Which party provides incident evidence and deletion confirmation?

The APNIC country field and Vietnamese registration support an association with Vietnam. The visible AS path also travels through Vietnamese-registered networks near the origin. Neither fact proves that every data copy stays in Vietnam. Traffic can cross borders, backups can sit elsewhere and support access can originate elsewhere. Conversely, a foreign route hop would not by itself prove foreign storage.

Locality is therefore a property of named systems and procedures. A customer should obtain a schedule identifying the facility region for primary and recovery data, the role of each processor, the permitted support locations and the conditions for cross-border transfer. It should also know whether monitoring and security logs follow the same rule as application data.

The unannounced IPv6 allocation illustrates why formal availability and real operation must be separated in compliance discussions. A registered resource is not a deployed service. In the same way, a contractual promise of Vietnamese hosting needs operating evidence that traces actual copies, not merely a company address or country code.

Thanh Trang's public footprint does not provide that map. Data sovereignty and locality remain relevant controlled topics because the service is associated with Vietnamese resources and potential hosting activity, but the company-specific compliance position is unverified.

What evidence would change the assessment

The Weak grade is not a claim that Thanh Trang has no operating service. It reflects the distance between what can be observed and what a customer would need to rely on.

Several pieces are already strong. The company identity is corroborated by multiple business-data services. VNNIC and APNIC align on the name, netname, ASN and address resources. The IPv4 prefix is broadly visible, originated by AS150820 and covered by a valid ROA. The current BGP snapshot consistently identifies AS18403 at the adjacent hop. The IPv6 allocation and authorisation are also concrete even though the route is absent.

The missing evidence is operational. The assessment would improve with a current service catalogue and terms; a facility and equipment-boundary statement; host and storage architecture; primary and alternate transit design; repair and support escalation; backup retention and restore results; billing and suspension rules; migration formats and egress limits; and a data-location schedule. A dated failover test would be more valuable than an undated claim of redundancy.

Three questions deserve especially direct answers.

First, what is Thanh Trang's role relative to AS150820? The answer should distinguish address-resource control, route origination, hardware ownership, customer support and billing. It need not disclose private prices. It should say which party has authority during an outage and what changes if the underlying agreement ends.

Second, where is the service physically recoverable? A primary city and facility type, a genuinely separate recovery location, and the available capacity after a failure would establish far more than a server count. If there is only one site, the company should state the backup and replacement procedure without calling it multi-site resilience.

Third, what is the status of IPv6? A route and test endpoint would show deployment. If the /48 is reserved for future use, saying so would prevent customers from mistaking preparation for delivery.

Unofficial market signals can help direct those questions but cannot answer them. Address-response scans suggest active use of much of the IPv4 space. Abuse-report pages suggest that some addresses have generated Internet traffic. Commercial geolocation labels suggest Vietnamese locations. None identifies a customer, rack, owner or service agreement. The evidence that would settle those issues is a contract, facility disclosure, route and failover record, support policy and tested export.

The customer carries the uncertainty unless the supplier names the boundary

Thanh Trang's network footprint is neither empty nor self-explanatory. It is a live IPv4 block with a valid authorised origin, attached to a young Vietnamese company that also holds an inactive ASN and an unannounced IPv6 allocation. Those facts are more useful than a generic cloud slogan because they reveal the first dependency boundary.

They also show why a cloud purchase cannot be assessed at the brand layer alone. The customer depends on the company taking the order, the party originating the prefix, the upstream carrying the route, the facility supplying power and access, the owner of the host and storage, the people holding spares, and the contract that allows data to leave. A failure at any one layer can make healthy capacity unusable.

For low-consequence workloads, that uncertainty may be acceptable at the right price. A customer can reduce exposure with independent backups, external monitoring, short renewal periods and a tested move. For systems that carry personal data, revenue, public services or hard recovery deadlines, unverified facility and support boundaries should be treated as a material procurement issue.

The operating-evidence grade remains Weak. Thanh Trang's corporate identity, IPv4 and IPv6 allocations, ASN and authorised third-party IPv4 origin are verifiable. Its rack location, facility operator, hardware inventory, usable capacity, path diversity, support depth, recovery design and portability terms are not. The proper response is not to invent those details or to assume the worst. It is to price the uncertainty, demand the missing evidence and keep a recovery route outside the same dependency chain.