Summary
- APNIC's public registration identifies AS152991 as
NGANDOANCLOUD-VN, names Ngan Doan Cloud Company Limited, places the resource in Vietnam and dates registration to 5 September 2024. This establishes a number-resource identity, not a live route or a cloud platform. - RIPEstat's 11 July 2026 observation showed zero current prefixes, zero announced IPv4 and IPv6 space, empty first-seen and last-seen fields, visibility from 0 of 327 IPv4 peers and 0 of 322 IPv6 peers, and zero observed neighbours. CAIDA independently marked the ASN unseen with a prefix cone of zero and network degree of zero.
- The public evidence does not locate a rack, disclose an address block, identify an upstream, demonstrate a customer endpoint, quantify installed compute or storage, or establish whether services are supplied through another operator. The absence of an AS152991 route is therefore a limit on verification, not proof that no other activity exists.
- For a buyer, the decisive tests sit below and beyond the ASN: facility and power boundaries, ownership or lease of hardware, current transit paths, usable spare capacity, backup restoration, support escalation, billing continuity, and the ability to export workloads before a provider or contract fails.
- Ngan Doan Cloud can turn the registered capability into an observable operating claim by publishing a current service boundary and allowing customers to test assigned endpoints, route origins, failover, restoration and data portability. Until such evidence appears, AS152991 is best treated as a reserved network identity with no live public prefixes to test.
The ASN is specific; the operating claim is not yet visible
The strongest public fact about Ngan Doan Cloud Company Limited is precise. The APNIC RDAP record for AS152991 identifies the autonomous system as NGANDOANCLOUD-VN, associates it with Vietnam, names the company in the registration description and records both registration and last change on 5 September 2024. The public administrative and technical contact entities use the same network label. RIPEstat's AS overview renders the holder as NGANDOANCLOUD-VN - Ngan Doan Cloud Company Limited and places the number within a block assigned by APNIC.
Those facts are enough to connect a legal name, a country code and a public routing identifier. They are not enough to connect that identifier to a working cloud service. An autonomous system number gives a network a distinct identity for exchanging routing information. It does not include an IP prefix, a router, a transit circuit, a data-centre contract, a server, a storage array, a support desk or a customer. The number can exist before any of those components are assembled, and it can remain registered while services are delivered through a different provider's network.
That distinction matters because NGANDOANCLOUD-VN looks like a compact description of a finished operation. It contains a product category and a country code. A reader can easily slide from “this company has an ASN” to “this company operates a Vietnamese cloud network.” The public evidence supports the first statement. It does not yet support the second.
The date sharpens the question. By the observation cut-off, the registration was almost two years old. An ASN can reasonably be assigned before deployment, and APNIC's current resource policy allows assignment where an applicant needs to interconnect with another autonomous system, including where it expects to meet the criteria within a reasonably short time. Registration therefore records an approved use case or anticipated routing need. It is not an attestation that implementation followed on a particular date.
For Ngan Doan Cloud, the useful starting point is consequently not an assumption of activity or inactivity. It is a gap between administrative identity and observable routing. The rest of the assessment asks what that gap prevents a customer, supplier or counterparty from knowing.
At the cut-off, every public routing measure was zero
RIPEstat gives the most direct current-state test. Its announced-prefixes result for AS152991 returned an empty prefix list. Its routing-status result recorded zero IPv4 prefixes, zero IPv4 addresses, zero IPv6 prefixes and zero IPv6 /48 equivalents at 08:00 UTC on 11 July 2026. The first-seen and last-seen entities were empty.
Visibility was also zero rather than merely low. None of the 327 IPv4 full-table RIS peers represented in that result saw AS152991, and none of the 322 IPv6 peers saw it. The status result counted zero observed neighbours. The separate ASN-neighbours result returned no neighbour entries. There is thus no observed provider, peer or customer AS to use as a starting point for examining reachability or diversity.
The registry and policy views do not supply a hidden substitute. RIPEstat's Whois result reproduced the APNIC aut-num record and the Hanoi correspondence address, but its captured Internet Routing Registry section was empty. The aligned routing-consistency result contained no prefixes, imports or exports. There was no registered policy in that response that could be compared with a live route.
CAIDA offers a separate topology measurement. Its AS Rank result for AS152991 named NGANDOANCLOUD-VN, associated the record with Vietnam and set seen to false. It reported a cone containing zero prefixes and zero addresses, with provider, peer, customer and total degree all zero. The cone's one-AS count represents the ASN itself; it is not evidence of a downstream network.
These measurements agree on the narrow conclusion: AS152991 did not have a publicly observed routing surface at the cut-off. The agreement is meaningful because a current-state collector view and an independently processed topology dataset are not the same product. Neither one exposes a live prefix, an AS path or a neighbour that contradicts the other.
Zero routes are not the same as zero business
The negative finding must remain bounded. Public BGP collectors observe routes that reach their peers. They do not inventory companies, contracts, physical machines or private networks. A company can operate applications on provider-assigned addresses, resell virtual servers on another supplier's platform, lease bare metal behind another origin ASN, use a content-delivery service, keep internal systems on private addresses, or provide consulting and support without ever originating a public prefix under its own number.
AS152991's absence therefore does not prove that Ngan Doan Cloud has no servers, no customers, no revenue or no current activity. It does not prove that the company abandoned a deployment. It does not prove an outage, because an outage is the loss of a previously established operating state and the supplied route data has no first-seen or last-seen event to lose. It also does not prove that a very local or short-lived announcement could never have escaped the sampled views.
RIPE NCC's routing-status documentation makes the measurement boundary explicit: the endpoint summarizes BGP state as observed by RIS route collectors, aligns historical requests to collection times and normally excludes very low-visibility announcements below its peer threshold. Zero visibility across the displayed full-table peers is strong evidence against a globally propagated route at that time. It is not universal surveillance of every session.
The same restraint applies in the opposite direction. Registry presence cannot be promoted into proof of service. A valid aut-num entity does not show that customer traffic moves, that hardware is powered, that invoices are honoured or that an engineer can restore a failed disk. The company label cannot fill those gaps. “Cloud” in a registered network name is an identity clue, not a measured service catalogue.
This leaves a deliberately asymmetric conclusion. The sources are strong enough to say that AS152991 had no observed public prefixes on 11 July 2026. They are not strong enough to say what, if anything, Ngan Doan Cloud delivered through other networks. That uncertainty is not a defect in the assessment. It is the central fact a buyer must resolve.
Registration records intent and custody, not installed capacity
An ASN sits in a governance system designed to coordinate routing identifiers. The IANA AS Numbers registry allocates ranges to regional registries, and APNIC or a national internet registry handles assignments in the Asia-Pacific region. Ngan Doan Cloud's number falls within that chain. The registration creates a durable public reference and contact path for the resource.
APNIC defines an autonomous system as a connected group of prefixes under a clearly defined routing policy. Its AS-number guidance explains the role of the number in identifying a network's routing policy. The protocol itself, defined in RFC 4271, exchanges reachability information between autonomous systems. Both descriptions point toward operational use, but neither says that an assigned number is automatically announcing a route.
The timing allowance is important. Resource assignment can precede circuits, address resources, router configuration and upstream acceptance. A network may need the ASN before it can complete a provider order or create filters. Deployment can then be delayed by procurement, facility access, licensing, engineering, commercial priorities or a change in architecture. The number may also be retained for a future migration while current services continue under a supplier's ASN.
Installed cloud capacity is a different category of evidence. It would require facts about hosts, processors, memory, storage, switching, power and placement. Even a single visible prefix would only prove that an origin was propagated; it would not reveal how many machines sat behind the addresses. With zero prefixes, AS152991 provides no reachable sample at all. There is no address to probe for latency, no path to inspect for transit, no origin to compare with a route object and no route history from which to infer continuity.
The registration is consequently best read as capability at the control-plane identity layer. It says Ngan Doan Cloud can be named independently in BGP if it has prefixes and counterparties prepared to exchange and propagate them. Whether it has exercised that capability is the unanswered question.
The public record does not locate a machine room
The Whois material associates the company with a street address in Thanh Xuan District, Hanoi. That is an administrative location in a number-resource record. It is not evidence that customer equipment, a network edge or a data centre occupies that address. Registered offices, correspondence addresses and technical contacts routinely differ from the physical sites where services run.
No public route can supply a geographic clue either. Country codes in internet-number records describe registration context, not precise equipment geolocation. Even when a prefix is active, an IP address can be announced remotely, tunnelled, carried over a backbone, served through anycast or mapped imprecisely by commercial databases. In this case there is no AS152991 prefix from which even those limited inferences could begin.
A cloud location claim would need a different evidence package. At minimum, a customer should know the city or facility class in which primary compute and storage reside, whether Ngan Doan Cloud owns the hardware or rents it, which party controls physical access, and whether backups occupy the same building. A supplier can protect exact rack coordinates while still identifying the operator boundary and broad jurisdiction. Facility attestations, contract extracts, invoices, access procedures or customer test endpoints can support the claim without exposing sensitive security details.
This is especially important in Vietnam's fast-growing digital-infrastructure market. The government's digital infrastructure strategy calls for new data centres, international cables, digital hubs and greener facilities. Those national targets establish demand and policy direction. They do not establish that a particular small company owns a data centre, leases a rack or has secured a watt of usable power.
Ngan Doan Cloud may use a Vietnamese facility, a foreign facility, a reseller platform or no customer-facing infrastructure at all. The ASN's VN registration cannot choose among those possibilities. Physical locality must be demonstrated at the workload and storage layer.
A cloud product is a chain of assets and promises
The word cloud can make the service appear detached from hardware, but a customer ultimately rents a coordinated set of scarce assets. The NIST definition of cloud computing describes on-demand access to a shared pool of configurable resources such as networks, servers, storage, applications and services. The apparent elasticity depends on actual hosts, disks, switches, power and operational staff.
For a small provider, the chain may begin with a wholesale virtualisation platform rather than owned servers. That is a legitimate architecture, but it changes the risk boundary. The retail provider controls packaging, billing and support while the wholesaler controls the hypervisor, physical host, storage and often the network. An outage or account dispute at the wholesaler can affect retail customers even if the retail provider's own systems are healthy.
The alternative is leased rack space with company-owned equipment. That gives the provider more control over server choice and virtualisation, but adds responsibilities for hardware stock, remote hands, firmware, cabling, power allocation and transit. Owning a data-centre building would move still more dependencies inside the company, including cooling, generators, fire protection, carrier entrances and security. Public evidence does not identify which rung Ngan Doan Cloud occupies.
AS152991 alone cannot resolve the question because network identity can be separated from every one of those commercial models. A reseller can hold an ASN it does not use. A hardware owner can operate under an upstream's addresses. A software business can register a number for a project that never launches. A cloud service can remain reachable through a provider origin while its own ASN is dark.
The operating model matters more than the label because it identifies who can repair a failure. If a customer instance disappears, can Ngan Doan Cloud access the host, replace the disk and restore the image, or must it open a supplier ticket? If a prefix is filtered, can its engineer change BGP, or does an upstream own the route? If the account is suspended, which contract controls reinstatement? With no visible route or service disclosure, those are open questions rather than criticisms.
Installed capacity is not usable capacity
Even proof of physical hardware would not settle the cloud-capacity question. Installed capacity counts what is present. Usable capacity subtracts resources consumed by resilience, maintenance, platform overhead and customer commitments. A rack can look full while having little safe headroom, and a new server can be unusable if power, storage or network ports are constrained.
Compute capacity is limited by the mix of processors, memory and workload contention. Storage capacity is limited by replication, parity, snapshots, performance and rebuild margin. Network capacity is limited by switch ports, uplink speed, upstream commitments and congestion. Power capacity is limited by the lower of contractual allocation, distribution equipment, cooling and generator support. Staff capacity is limited by the people who can respond at the time of failure.
A provider that advertises ten hosts cannot safely sell all ten as steady-state production capacity if one host must be available to absorb another's workloads. Two storage copies in the same chassis do not survive a chassis failure. Two power supplies connected to one distribution unit do not create independent power. Two transit sessions delivered over one cross-connect do not create physical route diversity.
No public material reviewed here gives Ngan Doan Cloud an installed figure, much less a usable one. That means neither abundance nor scarcity can be inferred. The zero-prefix ASN adds one specific limitation: there is no public customer plane under AS152991 on which utilisation, latency, packet loss or failover could be measured.
The evidence that would settle capacity is practical. A provider can disclose a current inventory by class, oversubscription policy, reserved failover margin and recent utilisation range. A customer can ask for the number of workloads that can survive the loss of the largest host, storage node, switch and power feed. The answer should identify the constraint that binds first. Marketing totals without those deductions are design numbers, not recoverable service capacity.
The route boundary is completely untested
If Ngan Doan Cloud intends to use AS152991, the first visible operating change would normally be a prefix carrying that number as origin or appearing in an AS path. That would make several tests possible. Observers could identify upstreams, measure propagation, inspect route stability, compare policy records and evaluate whether IPv4 and IPv6 follow the same design.
At present, none of those tests can run. There is no route to show whether the company is single-homed or multihomed. There is no neighbour to distinguish transit from peering. There is no prefix to check for a route-origin authorisation. There is no path to reveal whether nominally separate upstreams share a common provider. There is no withdrawal history from which to estimate restoration behaviour.
The absence of a PeeringDB network result in the captured lookup adds no strong conclusion. PeeringDB is a voluntary interconnection directory. Many small networks have no profile, and a profile would itself be self-reported rather than proof of a working session. The missing entry means only that this public directory did not add a disclosed facility, exchange or interconnection layer to the evidence.
Likewise, an empty routing-policy view is not a route failure. APNIC's aut-num guide explains how import and export attributes can document intended routing policy. Such statements can help operators build filters, but they are administrative declarations. Ngan Doan Cloud's captured record did not expose them, and even if it did, live BGP observation would still be required.
The shortest route test is therefore also the most revealing: ask for a current customer endpoint and determine which ASN originates it. If the origin is AS152991, the public record should begin to show a path. If the origin is another network, the provider should explain that operator boundary, address ownership and migration consequences. Either answer is more useful than treating the registered number as proof.
Route security cannot be scored without a route
Modern routing assessments often ask whether prefixes are covered by Route Origin Authorisations and whether networks filter invalid announcements. Those are sensible controls, but they presuppose address space and an intended origin. AS152991 has no observed prefix set in the cited data, so there is no current origin claim to validate.
RFC 6811 describes BGP prefix-origin validation, while RFC 8210 defines the protocol by which routers can receive validated cache data. These mechanisms help a network decide whether an origin is consistent with cryptographically signed resource authority. They do not prove that a circuit exists or that a service is healthy.
For Ngan Doan Cloud, a future route would create three separate checks. First, is the address block registered to the company or legitimately supplied by a provider? Second, is the observed origin authorised through the resource certification system or accepted through documented provider controls? Third, do upstreams propagate the route with stable reachability? Passing one does not guarantee the others.
The APNIC route-object guide adds another distinction. An Internet Routing Registry route object states that a prefix is intended to be originated by an ASN and can inform filtering. Creating the entity does not cause BGP to announce the prefix. Conversely, some routes appear without complete registry entities. Policy records, cryptographic authorisations and observed paths are complementary evidence.
Since the current views contain none of those AS152991 route elements, the responsible score is “not testable,” not “secure” and not “insecure.” A future customer should require the relevant prefixes, authorisations and filtering policy before relying on the ASN as a security claim.
Power and facility resilience remain outside the number record
Routing is only one failure domain. A perfectly propagated prefix does not help if the machines behind it lose electricity or cooling. Cloud resilience begins at the power feed, continues through distribution and cooling, and depends on a facility operator capable of maintaining those systems under fault.
The public record provides no power location, contracted capacity, redundancy topology, generator duration, fuel arrangement or maintenance history for Ngan Doan Cloud. It does not say whether any equipment has dual power supplies, whether those supplies land on independent distribution paths, or whether a second site exists. It does not identify the party that grants physical access during an incident.
These unknowns are common for privately held infrastructure suppliers and need not be published in exhaustive detail. They do need to be made available to serious customers under suitable confidentiality. A facility letter, power diagram, recent load test, maintenance report and responsibility matrix can demonstrate that the service rests on more than a brand and a network registration.
Multi-site claims deserve special care. Two rooms in one building can share utility service, generators, cooling, fire systems and carrier entrances. Two facilities can still share one metropolitan fibre route or one management account. A remote backup can be useless if credentials, encryption keys or billing are controlled by the same failed system. True redundancy is measured by the independence of failure domains and by tested recovery, not by a site count.
Ngan Doan Cloud's AS record says nothing about these layers. That is not what AS records are designed to say. The error would be to let the number imply a level of infrastructure assurance it cannot provide.
Hardware stock and support labour set the repair clock
Small cloud operations can deliver good service, but their recovery time is often governed by mundane constraints. A failed power supply may require a compatible spare. A storage rebuild may need a replacement disk with the right capacity and endurance. A dead switch may require a configuration backup and someone authorised to enter the facility. A hypervisor fault may require expertise held by one person.
The distinction between remote management and physical control is decisive. If Ngan Doan Cloud rents virtual capacity from a wholesaler, its support team may diagnose a fault without being able to repair the host. If it owns hardware in colocation, it may control the equipment but depend on facility remote hands outside staffed hours. If it runs a private room, it may control access while carrying the full burden of spares and environmental systems.
No public source identifies the model, the support hours or the escalation chain. A buyer should therefore test the human path, not merely ask whether support exists. Who receives an alert? Who can reboot or replace a host? Who can change a route? Who can restore a tenant from backup? Who has authority to approve emergency spend? How does the process work when the primary contact is unavailable?
The answers should be attached to measured times. An advertised response time is not a restoration time. A ticket can be acknowledged within minutes while a spare part takes a day to arrive. A remote-hands service can begin quickly but wait for customer approval or accurate instructions. A good service commitment separates acknowledgement, diagnosis, mitigation, restoration and final repair.
AS152991 offers no evidence on any of these questions. Its zero-prefix status only means the company's independent public network cannot currently be used as an external test surface. Customers must obtain support and repair evidence directly from the service arrangement they are considering.
Billing and contracts are infrastructure dependencies too
Cloud systems can fail without any component breaking. A missed upstream payment can suspend transit. A disputed colocation invoice can restrict site access. A domain or certificate can expire. A wholesale cloud account can be locked. A provider contract can terminate with too little time to migrate customer data. These are administrative events with physical consequences.
The risk is greater when the retail provider and underlying operator are different parties. Customers may contract with Ngan Doan Cloud while their workloads sit on a supplier controlled through a separate account. If that supplier relationship fails, customer rights depend on terms they may never have seen. The retail provider's ASN does not create ownership of the underlying machines or addresses.
Address portability is especially important. If customers receive provider-assigned IP addresses, they may need to renumber during a move. DNS changes can be quick, but cached records, allowlists, mail reputation, certificates and partner firewalls can make migration slow. If the address space belongs to Ngan Doan Cloud but is originated by another operator, customers need to know who controls route changes when the contract ends.
The registered AS could eventually reduce some dependence by giving the company its own routing identity, but only if it has portable addresses, active counterparties and operational control. A dormant ASN does not provide continuity by itself. It cannot preserve reachability when no prefix is attached.
A robust customer contract should therefore name the actual service operator, data location, upstream dependencies, suspension conditions, backup obligations, notification periods and exit assistance. These terms are part of the infrastructure design because they determine whether working equipment remains available to the customer.
Backup claims have to end in a restored workload
A backup is not resilience until it can be restored within the customer's tolerance for data loss and downtime. Cloud providers commonly describe snapshots, replicas and retention periods, but each mechanism protects against a different set of failures. A snapshot on the same storage system may help with accidental deletion while failing with the array. A replica in the same facility may survive a disk but not a power event. An off-site copy may survive the site while being too slow to restore.
The NIST contingency-planning guide frames recovery as planning, testing and maintaining alternative capabilities rather than merely creating copies. For a Ngan Doan Cloud customer, the important measures would include recovery point objective, recovery time objective, restore bandwidth, key availability, application dependencies and the most recent successful exercise.
There is no public backup or restore claim to test here. That absence should prevent both reassurance and accusation. The provider may have good private controls; it may have none; or it may not currently provide customer services. The evidence needed is operational: a dated restore result for a representative workload, including the time to obtain data, rebuild networking, recover credentials and confirm application integrity.
The operator boundary appears again. If a wholesaler creates the snapshot, can Ngan Doan Cloud export it without the wholesaler's platform? If storage is encrypted, who controls the key and how is it recovered during an account lock? If backups share the same billing account, can a payment failure remove both production and recovery copies? These questions turn a generic backup promise into a failure test.
The absence of an AS152991 route means network failover and data restoration cannot be tested from public endpoints under that origin. Customers should require a controlled exercise on the actual service they plan to use, not infer recoverability from the network name.
Portability is the final recovery layer
When every preventive control fails, a customer needs to leave. Portability is therefore part of cloud resilience, not merely a procurement convenience. A service is less fragile when workloads, data, configurations and credentials can be reconstructed elsewhere without permission from a failed supplier.
The practical exit package includes machine images or reproducible build instructions, database exports in documented formats, entity and file copies, DNS control, certificates, encryption keys, network rules, logs and a record of external dependencies. It also includes enough time and bandwidth to move the data. A nominal export feature is little help if a large dataset would take weeks over a throttled link.
Network identity can complicate the exit. Customers using addresses tied to the provider must renumber. Customers relying on the provider's ASN for allowlists or partner connectivity need a transition plan. If AS152991 remains unannounced, it cannot serve as evidence that Ngan Doan Cloud can carry customer addresses independently during a migration.
A buyer should test portability before production. Export a representative virtual machine, database and storage set. Rebuild them in an alternate environment. Measure transfer time and identify proprietary features that do not translate. Confirm who pays egress and who has authority to release data during a dispute. Record the minimum notice needed to complete the move.
This test also clarifies the provider's actual value. If Ngan Doan Cloud supplies skilled local support, integration or managed operations on top of third-party infrastructure, those services can remain valuable even when the underlying platform is portable. Transparent dependency does not weaken a provider. Hidden dependency does.
Vietnamese locality requires a workload-level answer
The VN country field and Hanoi correspondence address provide evidence about the resource holder. They do not establish that customer data stays in Vietnam. Data sovereignty and locality depend on where primary data, replicas, backups, logs and support access actually reside, as well as on the legal entities that control them.
Vietnam's 2023 Law on Telecommunications brought data-centre and cloud-computing services explicitly within its scope. The law defines cloud computing as flexible use of shared computing resources and requires providers to register or notify services, comply with security and data-protection obligations, preserve contractual user information and declare service quality. It also requires a commercially commissioned data centre to declare conformity with relevant standards and technical regulations.
The implementing Decree 163/2024/ND-CP adds service-notification and user-information provisions and states that data of state agencies using cloud or data-centre services must be stored within Vietnam. These rules create important context for due diligence. They do not prove that Ngan Doan Cloud has made a notification, operates a conforming facility or serves a state agency; no such company-specific evidence is present here.
Locality must therefore be stated per service. A provider should identify the jurisdiction of primary compute, persistent storage, replicas and backups; disclose whether support personnel abroad can access data; and explain what happens during disaster recovery. “Vietnamese ASN” answers none of those questions when the ASN has no prefixes and when network registration is not a storage-location record.
The country's National Data Strategy anticipates connected national and regional data centres and government cloud capacity. That is a market and policy signal. It cannot be converted into capacity for this company. Ngan Doan Cloud's locality claim, if one is offered, must stand on its own placement and contract evidence.
Unofficial network pages are monitors, not operating certificates
Public routing aggregators can help detect a future change. The pages for AS152991 at BGP.tools, Hurricane Electric's BGP Toolkit, Cloudflare Radar, IPinfo and BGPView provide convenient places to cross-check names, prefixes and paths when their data are available.
Their value must be kept in proportion. Each service collects, processes, caches or presents routing data differently. An empty page can reflect no routes, a stale index, an interface choice or limited coverage. A populated page can reflect a brief announcement or registered metadata rather than stable production traffic. None of these sites audits servers, facilities, contracts or customer use.
What they suggest at present is that no obvious contrary public footprint challenges the stronger RIPE and CAIDA finding. What they cannot prove is that Ngan Doan Cloud lacks provider-hosted services or private activity. What would settle the routing question is a sustained, time-stamped route seen by multiple collectors, tied to a prefix whose authority and intended origin can be checked.
Peering and market directories have similar limits. A voluntary profile can reveal claimed facilities, exchanges and traffic policy, but self-description is not a measured session. Absence can mean that a small network simply has not created a profile. These sources should generate questions and monitoring points, not verdicts.
The strongest assessment therefore rests on the converging primary measurements and treats the aggregators as watchpoints. If AS152991 begins announcing, the change should be verified across independent collectors and over enough time to distinguish a test from a production state.
What genuine redundancy would look like
Redundancy is not one feature. It is a chain in which each critical dependency has an alternate path that does not fail for the same reason. For Ngan Doan Cloud, public evidence supports no redundancy claim today, so the right approach is to define the proof that would be required.
At the route layer, the provider would identify active prefixes and upstreams, then show that paths are concurrently visible. It would explain whether circuits use separate carrier entrances, routers and power domains. A live failover exercise would demonstrate that traffic continues when one session or circuit is disabled. RFC 7454 provides broad operational guidance on BGP filtering and session protection, but compliance must be shown through the network's own controls.
At the facility layer, redundant power should terminate on genuinely independent distribution paths, with generator and cooling support sized for the protected load. At the compute layer, spare capacity should absorb the largest expected host failure without violating performance commitments. At the storage layer, copies should span the failure domains the service promises to survive.
At the operational layer, more than one authorised person should be able to diagnose, approve and execute recovery. Contact methods and monitoring should survive failure of the primary platform. At the commercial layer, backup access and export rights should remain available during a dispute or supplier termination. At the geographic layer, a second site should not share the same flood, utility, carrier or control-account exposure.
The proof is a dated exercise with results, not a diagram alone. A test should state the fault introduced, the workloads affected, the time to detect, the time to restore, the data lost and the manual steps required. Without that evidence, “redundant” describes design intent. With no AS152991 route, even the first network test remains pending.
Who would be affected when the chain fails
The affected population cannot be counted from public evidence because no customers, endpoints or services are identified. Still, the failure paths can be mapped by customer type. A virtual-private-server customer could lose compute and public reachability. A managed-service customer could lose both the application and the administrator who understands it. A reseller could pass the failure to many downstream clients. A business using backup storage could discover the problem only when it needs a restore.
Network failure under an upstream ASN would affect services according to that supplier's path, even though AS152991 remained absent. A rack or power failure would affect workloads colocated in the same domain. A storage fault could produce corruption or data loss without total network unreachability. A support failure could extend a short technical incident into a long outage. A billing or contract failure could remove access while all hardware remained functional.
Locality-sensitive users face an additional risk: disaster recovery might move data across a border or make it accessible to another operator. State agencies and regulated customers may have placement requirements that make an otherwise workable failover unacceptable. Buyers must know the recovery location before the primary site fails.
The smallest customer may be most exposed because it lacks bargaining power, independent monitoring and migration staff. Larger customers can demand audits, test restores and hold duplicate environments, but they too can be trapped by proprietary services or large data volumes. The absence of a public route makes external monitoring harder for everyone because there is no AS152991 address set to watch.
The mitigation is direct evidence and an exit plan. Customers should monitor their actual endpoint, not the company ASN alone; keep independent backups where contractually permitted; retain credentials and deployment information; and rehearse migration. Those controls remain useful whether Ngan Doan Cloud owns the hardware or relies on another provider.
A practical verification sequence
The investigation should begin with the service, not the company name. Ask Ngan Doan Cloud for a current product description, contracting entity, service URL or test address, and the location class of compute, storage and backups. Determine whether the offer is company-owned infrastructure, leased colocation, wholesale cloud, resale or managed service. Each model can be valid, but each assigns repair authority differently.
Next, resolve the network boundary. Identify the ASN that originates the test address, the owner or lawful supplier of the address block, the upstreams, and the party that controls routing changes. If AS152991 is expected to become active, request the deployment state and intended prefix without treating a target date as accomplished fact. Once a route appears, verify it through RIPEstat's public dashboard and multiple independent observations.
Then test capacity and resilience. Obtain current utilisation and reserved failover margin. Confirm power and carrier failure domains. Review the most recent host, storage, network and site recovery exercises. Test a backup restore and a representative export. Contact support outside ideal business hours and follow the escalation path far enough to establish who can act.
Finally, review the commercial controls: upstream and facility dependencies, payment and suspension terms, data-return rights, deletion commitments, incident notification, service credits and migration assistance. Confirm which obligations survive termination. A technically sound platform can still become inaccessible through a contract boundary.
This sequence produces evidence that is proportionate to risk. A low-value development server may justify a simple endpoint test and verified export. A production database, regulated workload or reseller platform requires facility, security, continuity and contractual detail. The zero-prefix finding does not dictate the purchase decision; it tells the buyer not to treat AS152991 as evidence for those layers.
What to watch for next
The registration can change from dormant identity to observable network quickly. The first signal would be an announced prefix or an AS path containing AS152991. That should be followed by first-seen data, non-zero collector visibility and one or more observed neighbours. Persistence over days and weeks would carry more weight than a brief test.
Routing records would then allow further questions. Does the prefix remain stable? Is the origin authorised? Are IPv4 and IPv6 both present? Do paths indicate one upstream or several? Are claimed diverse routes actually independent? Does a customer endpoint use the prefix? None of those answers should be assumed before the data appear.
An updated aut-num entity or new route object would be an administrative signal. A PeeringDB profile would be a disclosure signal. A service page, status channel or facility statement would be a commercial signal. Each can improve the picture, but none replaces direct testing. The strongest change would combine sustained routing, an identifiable service endpoint, clear operator boundaries and measured recovery evidence.
Continued absence also needs careful wording. If AS152991 remains unannounced, confidence grows that it is not serving as a public origin, but the inference still does not reach every provider-hosted or private activity. A registry update or return of the number could clarify administrative status. Silence alone cannot.
The observation date must remain attached to the finding because routing is dynamic. The accurate statement is that the cited public views showed no live prefix at the 11 July 2026 cut-off. Future readers should rerun the measurements rather than repeat the zero as a permanent characteristic.
The useful conclusion is narrow and actionable
Ngan Doan Cloud Company Limited has a real, company-specific network registration. APNIC's public record names AS152991 NGANDOANCLOUD-VN, associates it with Vietnam and dates it to 5 September 2024. That is firm evidence of an administrative routing identity.
The operating evidence ends there. At the measured time, RIPEstat reported no current prefixes, no first-seen or last-seen route, no IPv4 or IPv6 collector visibility, no announced address space and no observed neighbour. Its policy-related views contained no prefixes, imports or exports. CAIDA marked the ASN unseen, with no prefix cone and no topology degree. No public material cited here identifies an AS152991 customer endpoint, a facility, installed capacity, a transit path or a recovery design.
Those negatives justify one conclusion and reject two stronger ones. They justify saying that AS152991 provided no live public prefixes to test on 11 July 2026. They reject the claim that the ASN proves a functioning independent cloud network. They also reject the claim that zero routes proves the company has no business or provider-hosted service.
The remaining work belongs to service verification. A buyer should identify where workloads run, who operates the hardware and network, which power and transit dependencies are shared, how much capacity remains usable after a fault, who can restore service, and how data leaves if the provider or contract fails. A sustained route under AS152991 would add a valuable public test surface, but it would still answer only the network part of that chain.
The gap between a cloud-labelled ASN and an empty route view is not merely a missing statistic. It is a warning against using administrative identity as a proxy for physical capacity and recoverability. Ngan Doan Cloud has the number. Until prefixes and service evidence appear, the cloud behind that number remains something customers must verify directly.