Summary

  • APNIC registered AS153006 to Thuong Tin Cloud Company Limited in Vietnam on 9 October 2024 (2024-10-09) under the name THUONGTINCLOUD-VN. That is a real and useful administrative resource, but it is not evidence that the company has activated an independently reachable network.
  • RIPEstat's 11 July 2026 observations showed no current prefixes for AS153006, no first-seen or last-seen route, zero IPv4 and IPv6 visibility, and zero neighbours. CAIDA also marked the ASN seen=false, with a prefix cone of zero and network degree zero.
  • A separate company-labelled IPv4 block, 160.187.226.0/23, was globally visible through AS150862 rather than AS153006. This is evidence that some Thuong Tin Cloud-labelled address space can be reached, but it does not establish who owns the routers, racks or contracts carrying it.
  • The practical resilience question is therefore not whether the ASN exists. It is whether Thuong Tin Cloud can show active capacity, a documented upstream and facility boundary, recoverable customer workloads, and a tested path from provider-dependent delivery to the network represented by its own number.

The record is a prerequisite, not the network

The cleanest way to understand Thuong Tin Cloud Company Limited is to separate administrative capability from operational fact. The APNIC RDAP record for AS153006 is active. It identifies the number as THUONGTINCLOUD-VN, gives Vietnam as the country, names Thuong Tin Cloud Company Limited, and records registration and last change at 06:18:24 UTC on 9 October 2024. It also identifies administrative and technical contacts and a Vietnam National Internet Network Information Center maintenance boundary. Those are meaningful facts. They show that an accountable registry entry exists and that a number has been reserved for use under a stated organisation name.

An autonomous system number does not, by itself, carry a packet. It is a label used in interdomain routing, where a network announces address prefixes and exchanges reachability information under a routing policy. The distinction is embedded in the operation of BGP itself: RFC 4271 describes how systems exchange network-layer reachability information and the autonomous-system paths associated with it. A registry can allocate the label before a router is installed, before a transit contract starts, before address space is originated, or before any route is accepted by the wider internet.

That makes AS153006 a prerequisite for one kind of independent network operation, not proof that the operation has begun. The number gives Thuong Tin Cloud a possible future control point. It could be used to originate the company's own address space, establish sessions with one or more upstreams, enforce a routing policy, and make provider changes without renumbering every customer. None of those outcomes follows automatically from allocation. Each requires equipment, contracts, configuration, security controls and people able to operate them.

This distinction matters because cloud and hosting businesses are unusually easy to overestimate from administrative evidence. A company can hold an ASN while selling no active service. It can sell active services from provider-assigned addresses without using its own ASN. It can own servers but lease every rack, power circuit and route. It can also market a cloud while depending on a single upstream, a single facility and a support arrangement that customers never see. The registry answers who a number is associated with. It does not answer where workloads run, how customers reach them, or what survives a failure.

AS153006 has no observed route history in the 11 July 2026 snapshot

The direct routing evidence for AS153006 is negative. RIPEstat's announced-prefixes result returned an empty prefix list. Its routing-status result, queried for 11 July 2026, returned empty first-seen and last-seen entities. It reported zero announced IPv4 prefixes and addresses, zero announced IPv6 prefixes and /48 equivalents, and no visibility at any of the 327 IPv4 or 322 IPv6 RIS peers counted in that response.

The adjacency view agrees. RIPEstat's ASN-neighbours result contained no neighbours. Its routing-consistency result contained no prefixes, imports or exports. The separate CAIDA AS Rank response identified the same ASN and organisation label but marked it seen=false; its prefix cone and address cone were zero, and its customer, peer, provider and total degree measures were all zero.

These are independent ways of describing the same absence. No public route collector in the cited snapshot saw AS153006 originating reachability. No observed AS path supplied a neighbour. No route history populated the first-seen or last-seen fields. No inferred relationship appeared in CAIDA's view. A routing dashboard can create a page for any known ASN, and Cloudflare Radar's AS153006 routing view correctly carries the registered identity, but the existence of the page must not be confused with a populated routing table.

The result is stronger than saying that traffic appears light. Light traffic would presuppose a route and a measurement capable of associating traffic with it. Here the direct evidence stops earlier: the ASN has no observed announced space in the snapshot. That is why claims about customers, bandwidth, latency, international paths, peering or outage performance cannot be derived from AS153006. There is no visible route on which to base them.

Zero visibility is precise, but its scope is limited

Negative routing evidence needs the same discipline as positive evidence. Zero RIPE RIS visibility means that the sampled collectors did not see a public BGP route associated with AS153006 at the query time. It does not prove that Thuong Tin Cloud owns no servers, employs no support staff, holds no upstream contract, or serves no customers. Private networks, management links, provider-assigned addresses and Layer 2 arrangements can all exist without appearing as routes originated by a company's own ASN.

The absence also does not prove permanent inactivity. A new network can prepare equipment and addressing for months before announcing. A route can appear after the observation date, disappear during maintenance, or be visible only for a period not represented in a current-prefix result. That is why the empty first-seen and last-seen fields are important. They mean the cited dataset did not supply a public history for this ASN, not that no packet has ever traversed equipment controlled by the company.

Public route collectors have bounded views. RIPE NCC explains the collector system in its Routing Information Service documentation, while the RIPEstat API presents measurements derived from that infrastructure. A route seen by most collectors is strong evidence of public reachability. A route seen by none is strong evidence of non-visibility to those collectors. Neither observation is a physical inventory. It cannot reveal a dark fibre, an unadvertised interconnect, a powered-off router, or a server using somebody else's address space.

The proper conclusion is therefore narrow but consequential: AS153006 should not be counted as active public routing capacity. It should not be presented as a second network path, an independent upstream position, or proof of multi-homing. Procurement and resilience decisions must use the delivery arrangement that is actually visible today, then treat activation of AS153006 as a possible future change that requires fresh evidence.

A company-labelled /23 is reachable through a different ASN

The story does not end with the empty ASN. APNIC's RDAP record for 160.187.226.0/23 identifies an active block of 512 IPv4 addresses under the name THUONGTINCLOUD-VN. It names Thuong Tin Cloud Company Limited, gives Vietnam as the country, and records registration on 9 October 2024, within minutes of the AS153006 registration. This is a substantial additional fact because address space, unlike a bare ASN, can be assigned to interfaces and services.

Yet the route boundary is different from the registry label. RIPEstat's network-information response for the /23 identifies AS150862 as the observed origin. Its routing-status response records first visibility on 14 October 2024, last visibility in the 11 July 2026 snapshot, and reachability at 325 of 327 IPv4 RIS peers. The route therefore appeared five days after the registry entries and was broadly visible at the later observation, but it was not being originated by AS153006.

This sequence is more informative than either record in isolation. The company acquired a labelled address block and an autonomous system number on the same day. The address block then became publicly reachable through AS150862. The company's own ASN remained unobserved. That pattern is consistent with a provider-originated hosting arrangement in which an upstream or infrastructure supplier originates customer-labelled space. It is not proof of the contract, ownership structure or physical topology behind the arrangement.

Origin is a routing fact, not a corporate relationship. It shows which ASN told the public internet that it could deliver traffic to the prefix. It does not show whether AS150862 owns the servers, leases the rack, supplies transit only, manages the routers, or acts under another arrangement. The operator name attached to AS150862 and the company name attached to the prefix should not be turned into a durable relationship claim without contracts, facility records or statements from the parties.

There is also a positive routing-security signal. RIPEstat's RPKI validation response marked the observed origin valid and showed a route origin authorisation covering the /23 with AS150862 as origin. That reduces one class of origin ambiguity. It does not make the path diverse, prove that customer workloads occupy the addresses, or show that AS153006 is ready to take over the announcement.

The routed block proves reachability, not independent operation

The /23 changes the operating-status assessment from "no reachable evidence at all" to something more exact: company-labelled IPv4 space is reachable, but through another network's origin. That is enough to support the possibility of active hosted systems. It is not enough to claim that Thuong Tin Cloud runs an independent autonomous system or controls the full delivery stack.

Several public aggregators provide useful cross-checks. BGP.tools' AS150862 view lists 160.187.226.0/23 among prefixes originated by that network, while BGP.tools' AS153006 view offers the contrasting lookup for the company's own number. The Hurricane Electric BGP Toolkit, IPinfo and BGPView are additional observation surfaces. These services differ in update timing and presentation, so the collector-backed RIPEstat records carry more weight for the dated finding. Their value is in checking whether a later activation has appeared, not in manufacturing detail where the primary observations are empty.

For a customer, the distinction translates into control and failure domains. If the provider-originated route is the only public path, a routing policy error, unpaid bill, contract dispute, upstream maintenance event or failed edge device at that boundary can remove reachability even when the customer's virtual machines remain powered. If Thuong Tin Cloud does not control the route announcement directly, restoring service may require another organisation to act. Response time then depends on escalation rights and commercial priority, not only technical skill inside Thuong Tin Cloud.

The routed block also creates a migration question. A company-labelled portable allocation can be valuable because, in principle, the same addresses may be announced through a different authorised origin. In practice, moving them requires policy changes, accepted route objects or authorisations, a new transit handoff, configured routers, and a controlled cutover. AS153006 could become part of that future path. Until a route appears, it remains an option on paper rather than a demonstrated recovery mechanism.

The public domain exposes another supplier boundary

The company domain adds a different kind of operating signal. The administrative and technical contacts in the APNIC record use addresses at thuongtincloud.pro, linking the domain to the registry identity. The root website resolved during review to 103.178.234.11 and returned an account-suspended hosting page rather than a current service catalogue. The page directed the account holder to contact a hosting provider. This is direct evidence about the state of one public web account, not a verdict on the company as a whole.

The address behind that page is not part of 160.187.226.0/23. APNIC's RDAP record for 103.178.234.11 places it inside 103.178.234.0/23, registered as VPSTTT-VN, and RIPEstat's network-information response identifies AS140810 as the observed origin. The website, the company-labelled /23, and the unused AS153006 therefore sit on three distinguishable public network records.

That fragmentation is not automatically improper. Small hosting companies commonly buy web hosting separately from the infrastructure used for customers. A marketing domain can sit on shared hosting while customer workloads use a dedicated block. A prefix can be originated by a specialist transit or infrastructure provider while the service company handles sales and support. What the fragmentation does is prevent the website from proving ownership of the network behind the /23, and prevent the /23 from proving that the website's current state reflects every customer service.

The suspended page is still operationally relevant. A public website is often where prospective customers find support details, service status, terms, invoices and migration instructions. If that endpoint is suspended, a customer needs another authenticated escalation channel. The page also illustrates a contract failure that can become visible without any failed server: a hosting account can be disabled because of billing, policy, administration or provider action. The specific cause is not disclosed and should not be guessed.

The resilience lesson is that access to support and account control must not depend on the same commercial path that may be interrupted.

The name does not locate the infrastructure

Thuong Tin is a place name associated with Hanoi, but the APNIC records for both AS153006 and 160.187.226.0/23 give Hoa Hoi Village, Xuan Canh Commune, Song Cau Town, Phu Yen as the description address. The domain's observed hosting address belongs to yet another registered block. None of these facts identifies the building in which customer servers operate.

A registry address is an accountability field. It may be an office, contact address or administrative location. A domain's IP geolocation is not a server-room audit. Even the country code VN is not a rack coordinate. It cannot establish which province holds the data, whether equipment is in one or several facilities, or whether storage replicas cross a national boundary. Location claims require facility names, addresses, provider attestations, contractual placement terms or other evidence tied to the workload.

The absence of a proven facility matters because physical risk is local. Flood, fire, utility interruption, cooling failure and fibre construction affect buildings and routes, not registry labels. A customer told only that a service is "in Vietnam" cannot determine whether primary and backup systems share one power feed, one metro corridor or one operator. A customer told that a company has its own ASN still cannot determine whether the edge router is in the same room as every server.

No public evidence reviewed here establishes that Thuong Tin Cloud owns a data centre. The more defensible operating model is supplier-bounded: the company may control customer relationships or workloads while relying on leased racks, provider routing, third-party power and separate web hosting. That model can deliver a valid service, but its resilience depends on contract design and verified recovery arrangements across organisational boundaries.

A cloud label is a chain of physical dependencies

The NIST definition of cloud computing describes service characteristics such as on-demand access, resource pooling and measured service. It does not make cloud capacity immaterial. Every virtual machine must eventually occupy a physical processor, memory bank, storage device and network port. Every control panel depends on software, identity systems and management connectivity. Every promise of availability depends on spare resources and people able to repair or replace failed components.

For Thuong Tin Cloud, the public record does not disclose server count, processor generation, storage architecture, oversubscription, rack location, power allocation, carrier contracts or staffing. The company-labelled /23 provides at most 512 IPv4 addresses before reservations and operational use. Address count is not server count. A single host can use many addresses, many hosts can share one address through translation, and allocated addresses can remain unused. It is therefore wrong to convert the /23 into a capacity estimate.

The same warning applies to the ASN. It is not a bandwidth measure. A network with one ASN can have one low-capacity transit link or many diverse high-capacity links. A network without its own active ASN can still buy substantial capacity from a provider. The relevant evidence is a set of specific constraints: committed and burst bandwidth, port speed, upstream diversity, route policy, rack power, cooling limits, usable storage, backup throughput, restore time and support coverage.

These constraints interact. Adding servers without rack power does not create usable capacity. Adding a transit port without an announced prefix does not create reachability. Copying backups without enough restore bandwidth does not create recovery. Advertising a second site without replicated identity, DNS and monitoring does not create continuity. Cloud economics encourage high utilisation, while resilience requires headroom. The gap between those incentives is where customer risk accumulates.

Installed capacity is not usable capacity

Infrastructure providers often describe capacity with inventory numbers: cores, gigabytes, terabytes, ports or racks. Those figures are inputs. Usable capacity is what can be allocated while preserving performance and recovery commitments under a defined failure.

Suppose a provider has two hosts, each large enough for the current workload. That can support a host-failure claim only if workloads can restart on the surviving host, storage remains accessible, network configuration follows, licences permit the move and the second host has reserved headroom. If both hosts share one storage controller or one top-of-rack switch, the apparent duplication does not cover those failures. If both sit behind the same provider-originated route, neither can be reached during a route withdrawal.

Storage capacity has the same trap. Raw disk totals must be reduced for replication, parity, snapshots, free-space requirements and rebuild overhead. A storage cluster close to full can take longer to rebuild and may suffer severe performance loss after a device failure. Backup capacity is separate again: a snapshot in the same administrative domain can be deleted by the same mistake or compromised credential that damages production.

The routed /23 proves only that traffic can be delivered to the address block through AS150862. It does not show how many addresses answer, what services they host, whether there is spare compute, or whether customer data can be restored. A serious capacity statement from Thuong Tin Cloud would identify the service tier, active and reserved resources, the failure assumed, remaining capacity after that failure, and the date of the measurement. Without those elements, capacity language remains a sales description rather than resilience evidence.

The most credible failure path crosses commercial boundaries

The public facts point to a composite failure path rather than a single technical component. A customer workload may depend on a server or virtualisation cluster, a storage system, rack power, facility cooling, a local switch, the origin arrangement through AS150862, and the support team or provider contract that controls each layer. The public website depends on a different block and origin. A failure at any of those boundaries can disrupt service or the ability to get help.

Rack failure can be mechanical, electrical or administrative. A power distribution unit can fail. A breaker can trip. A colocation account can be restricted. A technician can disconnect the wrong cable. Recovery depends on remote-hands access, labelled cabling, spare parts and authority to act. If Thuong Tin Cloud does not own the facility, the response clock includes the facility operator's queue and contract terms.

Upstream failure is similarly broad. A fibre cut or router fault can remove traffic. So can a bad route filter, expired authorisation, rejected prefix, session configuration error or commercial suspension. The valid route-origin authorisation for the /23 is useful, but it authorises AS150862, not AS153006. Changing origin requires deliberate preparation. A customer should not assume that the new ASN can replace the existing origin in minutes merely because both registry entities exist.

Hardware-stock failure affects the length of an outage. A failed drive may be replaced from local stock or wait for shipping. A failed server board may require an exact model or a workload move to compatible hardware. In a smaller operation, one senior technician may hold the practical knowledge needed to rebuild the system. Support resilience therefore includes staffing, documentation and vendor access, not just a telephone number.

Billing failure deserves equal attention because the suspended domain demonstrates the form such an interruption can take, even though it does not disclose the cause. A provider can disable a service while all equipment remains healthy. A resilient customer arrangement needs advance notice, a dispute path, an emergency payment route, export rights and published contact points outside the affected account. These controls are commercial, but their absence can create a technical outage.

AS153006 is not yet a redundancy path

Two numbers on a registry page do not create two paths. Redundancy exists when a defined service survives a defined failure with acceptable capacity and recovery time. AS153006 cannot presently be counted as a backup to AS150862 because the cited observations show no prefix announcements, no neighbours and no route history for AS153006.

Making it a genuine alternative would require several visible and non-visible steps. Thuong Tin Cloud would need a router or routing service capable of using the ASN, one or more contracted upstreams, configured BGP sessions, accepted prefix filters, route-origin authorisation for the intended origin, route objects where required, monitoring, and tested failover. It would also need a physical handoff that does not share every critical component with the current path.

The RADB query for AS153006 and PeeringDB search are useful places to look for future policy and interconnection declarations, but neither operator-maintained database substitutes for an observed route. PeeringDB absence is not proof of no private transit, and an Internet Routing Registry entity can be stale or aspirational. Public BGP visibility remains the decisive test for internet reachability through the ASN.

Even an eventual announcement would not prove diversity. Two upstream names can share one fibre entrance. Two circuits can terminate on one router. Two routes can depend on one power domain. The required evidence is path-specific: distinct handoffs, distinct edge equipment, distinct power where claimed, and a failover test showing that the service remains reachable with enough capacity after one path is removed.

Route security must move with any future origin

The current /23 route has a valid RPKI origin state for AS150862 in the cited response. RFC 6811 explains BGP prefix-origin validation, while RFC 7454 sets out broader operational and security practices for BGP. These controls matter because an activation of AS153006 would change the authorised and observed origin relationship.

If Thuong Tin Cloud intends to originate 160.187.226.0/23 from AS153006, the route origin authorisation must permit that origin before the cutover. Upstream filters and route objects must also accept it. Otherwise a technically correct BGP announcement may be marked invalid or rejected. A rushed migration can therefore turn an intended resilience improvement into an outage.

Origin validation covers only the origin. It does not certify the whole AS path, prevent every leak, protect routers from compromise, or ensure enough capacity. Operational security also needs prefix filters, maximum-prefix limits, session protection, configuration review, out-of-band access and monitoring that can distinguish a withdrawal from a traffic shift.

The empty RIPEstat imports and exports for AS153006 should not be read as a security failure. They reflect an absence of returned routing-policy data. The correct question is what controls will be in place before activation and how the operator will prove that they work. A dated change plan, valid authorisations, staged announcements, collector visibility and rollback criteria would answer that question far better than the bare existence of the ASN.

Power, cooling and facility control remain undisclosed

Routing evidence can show that an address is reachable, but it cannot show whether the server stays powered. No reviewed public material identifies a Thuong Tin Cloud facility, rack count, utility feed, generator, battery design, cooling arrangement, fire system or maintenance regime. Those omissions prevent any evidence-based availability claim at the facility layer.

Power redundancy must be traced to the load. Two utility feeds do not help a server with one power supply connected to one strip. A generator does not help if fuel, switchgear or cooling fails. A battery runtime figure is not an outage duration guarantee; it is a bridge under assumptions about load and successful generator start. The useful test records which components remained powered, how long they ran and what happened to cooling and network equipment.

Facility location also affects support and logistics. The APNIC description points to Phu Yen, but it does not prove that customer equipment sits there. If racks are elsewhere, travel time, spare-part stock and remote-hands contracts may differ. If all capacity is in one building, a site event can affect every customer regardless of server-level redundancy.

A credible disclosure would distinguish owned equipment from leased facility services. It would name the operator boundary for power, cooling, physical security and remote hands. It would explain whether a second site is active, what data is replicated there, and whether the second site's network path is truly independent. Without that evidence, the service should be evaluated as having an unknown physical footprint and unproven site redundancy.

Support labour determines whether recovery is real

Infrastructure does not repair itself. A useful support commitment names the hours of staffed coverage, severity definitions, acknowledgement target, escalation authority and the party responsible for each layer. Public contact names in an RDAP record provide accountability for number resources; they are not a service desk or a promise of round-the-clock response.

The domain's suspended page makes channel independence especially important. Customers should have an authenticated support method that does not rely on the marketing site, its hosting account or the same identity provider as the customer control panel. Emergency contacts should be tested. Status communication should live on infrastructure that can remain available when the primary service fails.

Knowledge concentration is another risk. A small provider may be technically capable but dependent on one person who knows the routing configuration, storage layout or provider contacts. Runbooks, access escrow, configuration backups and cross-training reduce that dependency. They also matter during a commercial dispute or staff departure, when the equipment may be healthy but authority and credentials are fragmented.

The recovery test should include people and suppliers. Remove one host, one route, one support contact or one account and observe what happens. Record who detected the failure, who could authorise changes, how customers were notified, how long service restoration took, and whether the restored service had enough capacity. This is more informative than a generic claim of 24/7 support.

Data locality needs workload-level proof

The country fields in the APNIC records make Vietnam a reasonable service-area context. They do not prove that every customer workload or backup remains in Vietnam. The public website uses one network, the company-labelled /23 uses another origin, and the physical facility is not identified. Each of those boundaries can affect where data is stored, processed, backed up or accessed.

Vietnam's official publication of Decree 53/2022/ND-CP and the official legal text provide the legal context for certain data-storage and cybersecurity obligations. Applicability depends on the service, data, organisation and current law, so a registry country code cannot settle compliance. Customers need contractual and technical evidence tailored to their own obligations.

Useful locality evidence includes named facility locations, data-flow diagrams, backup destinations, support-access locations, subprocessors and deletion procedures. It should distinguish primary data from logs, snapshots, replicas and support records. A service may keep its main virtual disk in Vietnam while sending monitoring data or backups elsewhere.

The provider-originated route does not itself move stored data across a border; BGP paths and data residency are different questions. But the supplier boundary means customers should ask who can access the infrastructure and which contracts govern it. Data sovereignty is partly about location and partly about control, jurisdiction and the practical ability to retrieve or delete data when a supplier relationship ends.

Backups matter only when restoration is demonstrated

A backup claim is easy to make and difficult to evaluate without a restore record. The important properties are isolation, retention, integrity, access control, capacity and restoration time. A copy on the same storage system may protect against accidental file deletion but not controller failure, site loss or compromised administrator credentials.

NIST's contingency-planning guidance treats recovery as a planned capability involving business impact, preventive controls, strategies, testing and maintenance. Applied to a hosting provider, that means identifying the service to recover, the maximum tolerable interruption, the data-loss limit, the dependencies required for restoration and the evidence from a recent test.

For Thuong Tin Cloud, a meaningful restore exercise would start outside the production failure domain. It would rebuild a workload, attach verified data, restore identity and network configuration, update DNS or routes where needed, and confirm application integrity. If the current public delivery depends on AS150862, the exercise must either preserve that route or demonstrate a prepared alternative. AS153006 cannot be listed as the alternative until it has been configured and observed.

Restore throughput often becomes the hidden constraint. A provider can store many terabytes of backup but lack enough network or disk bandwidth to recover all customers within promised times. Priority rules then determine who waits. Customers need tier-specific recovery objectives and clarity about whether resources are reserved or shared during a large incident.

Portability is the final recovery control

When every provider-side recovery path fails, the customer needs a way out. Portability means more than downloading data. It includes supported export formats, access to configuration, keys, images, database dumps, DNS records and enough time and bandwidth to move. It also requires a destination that can accept the workload.

The company-labelled /23 may help network portability if Thuong Tin Cloud has the rights and technical preparation to change its origin. Customer portability is different. Most customers will not move the provider's addresses with them. They need applications designed to tolerate address changes, external DNS control, independent backups and documented rebuild procedures.

Contract terms should state export fees, bandwidth limits, notice periods, data-retention windows and what happens during a billing dispute. A suspended account should not erase the only route to customer data. Emergency read-only access or escrowed exports can reduce that risk, but only if tested and legally workable.

The strongest evidence of portability is a completed migration. A provider can show that a representative workload was exported, restored elsewhere and validated within a measured period. Until such evidence exists, customers should treat migration time and data egress as material unknowns rather than assume that a cloud interface guarantees mobility.

Who is affected when this chain fails

The public evidence does not identify Thuong Tin Cloud's customers, so no customer names or market share should be inferred. The affected population can still be described by dependency type. Any tenant using addresses in 160.187.226.0/23 depends on the current origin path. Any user relying on the public domain for contact depends on its separate hosting account. Any workload placed in an undisclosed facility depends on that facility's power, cooling, access and support arrangements.

A route withdrawal would affect services addressed from the /23 even if servers stayed healthy. A rack or storage failure could affect only a subset of workloads while the route remained visible. A control-panel or identity failure could prevent customers from managing systems that still answer. A billing or provider-contract failure could remove the website, routing, rack access or more than one of them, depending on which services share the supplier.

Indirect users matter too. A hosted application may support a local business, API, game, e-commerce site or internal system. Those users may never know Thuong Tin Cloud's name, but they experience the outage. The customer's recovery plan therefore has to account for its own downstream obligations rather than rely solely on the provider's headline availability.

The absence of direct route evidence for AS153006 raises the importance of transparent incident communication. Customers need to know whether an event affects the origin route, facility, compute, storage, control plane or support channel. Different failures have different workarounds. A status message that says only "network issue" does not tell a customer whether to wait, fail over DNS, restore elsewhere or protect data.

What would change the assessment

The assessment can improve quickly because the missing evidence is concrete. The first public change would be an observed announcement from AS153006. RIPEstat should then show a populated prefix list, first-seen time, visibility and neighbours. Independent views such as Cloudflare Radar, BGP.tools and Hurricane Electric should converge on the new origin. A valid route-origin authorisation should cover the announcement.

That would prove public use of the ASN, but not resilience. The next evidence should identify upstreams and physical handoffs, state whether paths are diverse, and show a failover test. A route that disappears when one router or one circuit fails is active but not redundant. A route that remains visible with too little capacity is technically available but commercially inadequate.

Facility evidence would name the site or sites, operator boundaries, rack-power design, cooling assumptions, remote-hands terms and recovery inventory. Service evidence would identify actual products, capacity constraints and support commitments. The present suspended root page should be replaced by an authenticated and maintained customer contact path, or customers should be given an alternative that is demonstrably independent.

Recovery evidence would include recent host, storage, route and site exercises with measured results. Locality evidence would tie workloads and backups to documented locations and subprocessors. Portability evidence would show a successful export and restore. Each item closes a different uncertainty; none can substitute for all the others.

A procurement test built around the real boundary

A buyer evaluating Thuong Tin Cloud should begin with the visible route rather than the registered ambition. Which products, if any, use 160.187.226.0/23? Who operates the edge that originates it through AS150862? What contractual right does Thuong Tin Cloud have to maintain, change or withdraw that announcement? Which organisation receives the first escalation when the route disappears?

The buyer should then ask what AS153006 is intended to do. Is activation planned? Which prefixes will it originate? Which upstreams and facilities will support it? Are route-origin authorisations and filters prepared? Has a staged announcement been tested, and what is the rollback plan? Answers should be dated and supported by configuration or measurement, not inferred from the ASN's registration date.

Physical questions follow. Where are the servers and backups? Who owns them? What happens after loss of rack power, storage, one upstream, one administrator or one facility? How much spare capacity remains after each failure? Which replacement parts are on site, and what are the remote-hands response terms?

Commercial questions are equally technical in their consequences. Can an upstream, facility or hosting provider suspend service for non-payment or policy reasons? How much notice is required? Does Thuong Tin Cloud have an emergency escalation and alternate payment route? Can customers retrieve data during a dispute? Is the status channel hosted outside the primary failure domain?

Finally, the buyer should run a small recovery exercise before concentrating critical workloads. Export a representative system, restore it elsewhere, test DNS changes, measure transfer time and verify application integrity. The result will reveal more about practical resilience than the presence of an ASN, a /23 or a cloud label.

Monitoring should look for transitions, not page existence

AS153006 is straightforward to monitor because the expected transition is observable. The RIPEstat AS page and data endpoints can reveal the first prefix, first-seen time, visibility and neighbours. APNIC's AS-number guidance explains the resource's role, while the IANA AS-number registry provides the delegation context. These pages establish identity and method; the transition occurs only when routing data appears.

The company-labelled /23 should be monitored separately. A change from AS150862 to AS153006, a multi-origin state, loss of visibility or invalid RPKI status would each demand explanation. The domain should also be checked independently because its hosting path is separate. Conflating the three surfaces would hide exactly the supplier boundaries that matter.

Monitoring should be dated. Routing is dynamic, and a finding from 11 July 2026 may change. The useful record is a sequence: registration, first route, origin changes, visibility, neighbour changes and incidents. That sequence can show whether the company is moving toward independent operation or continuing with provider-originated delivery.

The empty result should not be treated as an outage alert for AS153006 because no prior route is present in the cited history. It is a baseline. The broadly visible /23 is the operational route that can be monitored for withdrawal. Keeping those baselines separate prevents a dormant number from being mistaken for failed capacity.

The narrow conclusion is the useful one

Thuong Tin Cloud Company Limited has more than a name in a business directory. It has an active Vietnamese AS registration, an active company-labelled IPv4 block, accountable registry contacts and a publicly reachable route for that block. But the route is originated by AS150862, while AS153006 has no observed prefixes, first or last route, visibility or neighbours in the 11 July 2026 evidence. CAIDA's independent view also says the ASN is unseen and has no prefix cone.

That combination supports a specific thesis. The new AS record creates the administrative possibility of independent routing. It does not prove reachable infrastructure under that number. The reachable /23 demonstrates a delivery path through another ASN, not ownership of the routers, racks or facilities behind it. The suspended public domain adds evidence of a separate hosting dependency, not evidence that every customer service is offline.

For customers, the correct response is neither to dismiss the company nor to grant the registry more meaning than it carries. Evaluate the service that can actually be reached, identify the supplier boundaries carrying it, and demand proof for physical capacity, route control, support, recovery, locality and portability. Treat AS153006 as future capability until a public announcement and tested operating plan turn it into infrastructure.