Summary

  • APNIC's public RDAP record identifies AS152970 as HOALACCLOUD-VN, names Hoa Lac Cloud Company Limited, marks the resource active in Vietnam and gives a registration date of 9 August 2024. That establishes a number-resource identity, not an operating cloud service.
  • At the 11 July 2026 observation time, RIPEstat showed zero current prefixes for AS152970, empty first-seen and last-seen fields, zero IPv4 and IPv6 route-collector visibility, and zero observed neighbours. CAIDA separately marked the AS as unseen, with a prefix cone of zero and degree zero.
  • APNIC also registers 160.30.86.0/23 and 2001:df4:2540::/48 to the company. Both were publicly visible with AS135967 as origin, not AS152970. This indicates reachable company-labelled address resources while making delivery through another network the central dependency to understand.
  • Public records do not establish that Hoa Lac Cloud owns a data centre, operates racks, sells a current VPS or managed-cloud product, has diverse transit, or can restore customer workloads. Its website currently resolves through infrastructure registered to another provider and serves a default hosting page, which is a weak operational signal rather than a product catalogue.
  • The practical test is whether the company can document service placement, the AS135967 arrangement, power and carrier boundaries, usable failover capacity, support authority, backup restoration and data portability. Until then, AS152970 is best read as an allocated capability awaiting direct public routing evidence.

The most important fact is the sequence

The Hoa Lac Cloud story begins with an order of events. A company was incorporated, number resources were registered, address blocks became reachable through another autonomous system, and yet the company's own AS number had still not appeared in the public routing views examined here. That sequence matters more than the cloud label. It describes an infrastructure position in which administrative capability exists before independent route evidence.

The authoritative identity point is the APNIC RDAP record for AS152970. It names HOALACCLOUD-VN, identifies Hoa Lac Cloud Company Limited, places the record in Vietnam, marks it active and dates both registration and last change to 9 August 2024. The public contact entity is also dated that day. These details are narrow but firm: an AS number was registered to the named company through the Asia-Pacific number-resource system.

An autonomous system number is permission and identity within interdomain routing. It is not itself a route, router, transit contract or customer service. The distinction is easy to lose because an ASN looks like a finished infrastructure fact. In practice, it is closer to a reserved control-plane identity. It becomes publicly observable only when networks accept and propagate routes carrying that number as an origin or in an AS path.

That next step had not occurred for AS152970 in the supplied 11 July 2026 snapshot. The RIPEstat announced-prefixes view returned an empty prefix list. The routing-status view returned empty first-seen and last-seen entities, zero IPv4 prefixes, zero IPv6 prefixes and no visibility from either the IPv4 or IPv6 collector peers in that result. This is not a marginal network with a faint signal. It is a registered AS with no direct signal in those observations.

The careful conclusion is temporal. AS152970 existed in the registry before public routing evidence for AS152970 appeared. That does not guarantee that an announcement will follow, and it does not say the company is inactive in every other sense. It says the administrative record is ahead of the public control plane.

What zero visibility means, and what it does not

The zero values deserve precision. RIPEstat reported 0 of 327 IPv4 RIS peers and 0 of 322 IPv6 RIS peers seeing AS152970 at the observation time. It recorded no announced address space and no observed neighbours. Its ASN-neighbours result showed left, right, unique and uncertain neighbour counts all at zero. The routing-consistency result contained no prefixes, imports or exports.

CAIDA supplies a separate perspective. Its AS Rank entry for AS152970 labels the number HOALACCLOUD-VN and associates it with Vietnam, but sets seen to false. The record gives a prefix cone of zero, address count of zero, and customer, peer, provider and total degree values of zero. Independent systems therefore agree on the central negative finding even though they organise the data differently.

Zero public visibility means there is no evidence in those datasets that AS152970 was originating globally propagated prefixes or participating in observed interdomain paths at that time. It means no public BGP neighbour can be inferred from those observations. It also prevents meaningful claims about the AS's transit diversity, route stability, propagation reach or route-origin security, because there is no current AS152970 route set on which to perform those tests.

It does not mean Hoa Lac Cloud owns no server, has no customer, conducts no business or provides no service. A company can use provider-assigned addresses, place servers behind another operator's network, buy managed hosting, use private addressing, or keep an ASN dormant while preparing an edge. A private or provider-mediated service may be real without its customer's ASN appearing globally.

The absence also does not prove an outage. An outage is a loss relative to an established service state. The public datasets do not supply an earlier AS152970 route to lose: first-seen and last-seen are empty. Calling this a withdrawal or failure would invent a past routing state that the evidence does not show. The defensible phrase is no observed public routing evidence for AS152970.

The address blocks make the case more interesting

Hoa Lac Cloud is not represented only by an ASN. APNIC's RDAP record for 160.30.86.0/23 names the company, labels the network HOALACCLOUD-VN, marks the allocation active in Vietnam and dates it to 9 August 2024. A parallel RDAP record for 2001:df4:2540::/48 does the same for IPv6. The records share the company description, locality and public contact used by the AS entry.

These allocations are concrete resources. The IPv4 /23 contains 512 addresses in total, while an IPv6 /48 provides a conventional site-scale block with a very large address range. But registered address capacity is not the same as installed compute, sold virtual machines, storage durability or customer demand. Even usable IP address count is smaller than total mathematical size once network, broadcast and operational reservations are considered for IPv4.

The route origin is the pivotal detail. RIPEstat's network-information result for 160.30.86.0/23 identified AS135967, not AS152970. Its routing-status result for the IPv4 block recorded a first observation on 22 August 2024, a current observation on 11 July 2026, and visibility from 325 of 327 IPv4 RIS peers. The result also listed route objects from APNIC, NTTCOM and RADB.

The IPv6 picture has the same structure. The network-information result for 2001:df4:2540::/48 identified AS135967, while the IPv6 routing-status result showed the prefix visible from 321 of 322 IPv6 RIS peers in the observation. It too was first seen on 22 August 2024.

The timing is suggestive: the address and ASN records were created on 9 August, and the company-labelled address blocks appeared through AS135967 less than two weeks later. What this suggests is an implementation in which another network supplied public origination. What it cannot prove is the commercial arrangement, the location of machines, whether Hoa Lac Cloud controlled routers, whether customers used those addresses, or why AS152970 remained unannounced. A contract, network diagram, operator statement or observed future migration would settle those questions more directly.

AS135967 is the visible dependency, not an implied relationship claim

The public route tells us that AS135967 carried the company-labelled IPv4 and IPv6 prefixes. It does not by itself define the legal or commercial relationship between the two organisations. BGP can reveal origin and path observations, but it does not publish an invoice, service description or responsibility matrix.

The APNIC registry does add context. An RDAP lookup for the website address 103.74.123.7 places that address in CNBKNS-VN, described as a branch of BachKim Network Solutions JSC. RIPEstat also maps that website address to AS135967. The public technical contact attached to Hoa Lac Cloud's number resources uses the same personal name as a technical contact on that older network record. This overlap is a meaningful signal of operational proximity.

It remains only a signal. Shared personnel, provider infrastructure and route origination can arise from ownership, partnership, managed service, contracted transit, reseller activity or ordinary customer-provider arrangements. The records do not let a reader select one of those explanations with confidence. It would be wrong to convert technical adjacency into an undisclosed corporate relationship.

For customers, the practical issue is responsibility. Because AS135967 is the current public origin for Hoa Lac Cloud's address space, loss of that arrangement could remove public reachability even while the Hoa Lac Cloud address registrations remain active. If the arrangement is managed, the time to restore service may depend on another operator's network team. If it is transitional, a move to AS152970 could introduce a planned routing change that needs careful handling.

The due-diligence question is therefore not merely "Who is the upstream?" It is: who originates each prefix today, who is authorised to change that origin, which party controls route objects and route-origin authorisations, who holds the router configuration, and what happens to customer addresses if the provider agreement ends? The observed origin makes these questions specific rather than hypothetical.

A default website is evidence of a boundary, not a service catalogue

The domain hoalaccloud.vn provides another small but revealing public signal. At the time examined, its DNS A record pointed to 103.74.123.7, an address registered within the BachKim network allocation. The domain's nameservers used bkdns.vn, and the web server returned a generic control-panel default page rather than a Hoa Lac Cloud product site. HTTPS presented a certificate that was not publicly trusted by the standard client used for the check.

Those observations must be kept in proportion. A default page does not show that the company's services are down. A website can be parked while private sales continue, a customer portal can live elsewhere, or a provider can operate without using its corporate homepage as a service endpoint. DNS and a web front page are not a complete operating audit.

They do weaken any attempt to infer a current customer-facing cloud offer from the company name alone. There was no visible product catalogue, facility list, status page, service-level statement, support escalation route, backup description or data-export policy on the root page. The website did not supply evidence that could close the gaps left by BGP.

The signal is consistent with the network evidence: public presentation depends on another operator's address space, while the company's own ASN is not visible. It cannot prove whether that architecture is temporary or intentional. A maintained site with named services, legal contracting details, facility disclosures and an independent status channel would improve the public operating picture, but even that would still require technical verification.

Secondary company information is similarly bounded. A Vietnamese legal-information listing reports an incorporation date of 5 July 2024, an active status, the international name Hoa Lac Cloud Company Limited, and information-technology services as the main registered activity. That chronology fits the August resource registrations. Because the page is a secondary presentation of government-derived information, it supports corporate context more than infrastructure operation.

The name Hoa Lac does not prove a facility in Hoa Lac

The registry description gives an address in Hoa Lac Village, Binh Yen Commune, Thach That District, Hanoi. That is a location attached to the resource holder. It is not a machine-room coordinate. Companies can register at an office, residence, shared address or administrative headquarters while placing equipment in a third-party data centre elsewhere.

This distinction is especially important because "Hoa Lac" evokes a recognised technology area west of central Hanoi. The name may invite readers to imagine a purpose-built data hall, local power infrastructure and proximity to the Hoa Lac Hi-Tech Park. The public records cited here do not establish any of those physical claims for Hoa Lac Cloud Company Limited.

To prove a physical cloud location, the company would need to identify at least the facility or provider class, the city or campus, the party that controls site access, and the boundary between company-owned hardware and rented capacity. A confidential facility letter or contract excerpt can sometimes provide this evidence without exposing a sensitive rack number. Power-domain and carrier-entry details can likewise be shared under appropriate confidentiality.

Without that proof, locality should be expressed at the resource-registration level: Vietnamese number resources associated with a Hanoi address. It should not be stretched into "servers in Hoa Lac," "owned Hoa Lac data centre" or "local sovereign cloud." Those are materially stronger propositions.

Physical location affects failure analysis. A leased server in another operator's Hanoi facility has a different repair path from an owned rack in a Hoa Lac building. A virtual server rented from a third party has a different portability problem from customer workloads running on hardware owned by Hoa Lac Cloud. Location is therefore not decorative company detail. It determines who can touch the equipment, which power and fibre failures are shared, and how quickly a migration can occur.

A cloud service is more than reachable address space

The address blocks show a potential service surface, but cloud delivery requires several layers that BGP does not measure. At minimum there must be compute, memory, storage, switching, routing, power, cooling, physical security, monitoring, support and a commercial system that keeps customer access authorised. Managed service adds configuration responsibility and people able to restore or migrate workloads.

None of those layers is disclosed by AS152970's registration. The /23 and /48 do not reveal how many servers exist, whether any are dedicated to customers, how storage is protected, or whether capacity is owned or resold. A routed /23 can front a substantial platform, a small cluster, a proxy, a hosting panel, or nearly nothing. Address space is not a reliable proxy for revenue or machine count.

This is where hosting economics becomes concrete. A small provider can lower entry cost by leasing racks, buying transit through an established network and using a shared support arrangement. That can be commercially rational. It also means resilience depends on contracts and queues outside the brand customers see. The provider must either transfer strong supplier commitments to customers or retain enough alternative capacity to absorb a supplier failure.

The same logic applies to AS independence. Operating a separate ASN can improve control over routing policy and provider choice, but only if the ASN originates routes through working sessions. A dormant ASN does not add path diversity. It may represent future capability, administrative preparation or an unused option. Until AS152970 appears with prefixes and neighbours, it cannot be counted as a second route plane beside AS135967.

Customers should ask for a service map with boundaries. Which addresses front customer workloads? Which autonomous system originates them? Where do hypervisors and storage reside? Who controls the top-of-rack switch? Which company opens a carrier ticket? Which company can approve a route change? A map that stops at the Hoa Lac Cloud brand conceals the dependencies that determine recovery.

Installed capacity and usable capacity are different numbers

Providers often describe capacity in installed terms: server cores, memory, storage terabytes, uplink speed or address blocks. Customers experience usable capacity, which is what remains after maintenance, component failure and reserved headroom. They rely on recoverable capacity, which is what can be restored within an agreed time without unacceptable data loss.

Public evidence supplies no installed-capacity figure for Hoa Lac Cloud. That absence should prevent both optimism and pessimism. It would be speculative to claim a large platform, but equally speculative to conclude there is no hardware. The correct response is to define the proof needed.

For compute, useful evidence includes physical host count, failure-domain layout, normal and peak utilisation, admission limits, and spare inventory. For storage, it includes replication topology, backup independence, restore throughput and the largest recent restoration exercise. For network capacity, it includes interface sizes, committed transit, peak utilisation, traffic engineering and remaining capacity when one link or router is removed.

An address block adds no assurance on these points. The 512 addresses represented by the IPv4 /23 do not equal 512 active servers. Network address translation, virtual hosting, anycast, load balancers and reserved addresses break any simple mapping. The IPv6 /48 is even less suitable as a machine-count proxy because IPv6 allocation practice deliberately provides abundant address space.

Capacity proof should be failure-shaped. If one host fails, where do its virtual machines restart and how much spare memory exists? If one storage node fails, does rebuild traffic saturate the network? If AS135967 loses an upstream, does the remaining path carry peak load? If a rack loses power, is the recovery copy in a genuinely separate power and facility domain? Aggregate capacity numbers cannot answer these questions.

The route handoff is a potential single point of commercial failure

The company-labelled prefixes' origin through AS135967 creates a dependence that is both technical and commercial. Technically, AS135967's routers and upstream sessions determine whether the prefixes enter the global table. Commercially, continued origination may depend on a service agreement, account status, payment, acceptable-use decisions and support escalation.

That does not mean the arrangement is fragile. A managed provider can deliver stronger routing operations than a new company could build alone. AS135967 may have multiple upstreams, experienced engineers and mature filtering. The point is that Hoa Lac Cloud's resilience cannot be assessed without understanding how much of that capability is contractually available to it.

The public route view for the /23 showed broad collector visibility, which is a positive reachability signal for the address block. It does not disclose physical diversity. Two apparent upstream paths may share a fibre duct, router, building entrance or power system. Broad BGP propagation can coexist with one local handoff.

The customer should seek a path diagram that begins at the hosted server rather than at the global route table. It should show server interface, switching, edge router, cross-connect, facility meet-me room, carrier and upstream. It should identify shared components and state which path remains under each tested failure. Commercial counterparties should be attached to the same diagram.

The migration question is equally important. If Hoa Lac Cloud later originates its blocks from AS152970, will the addresses stay unchanged? Will AS135967 continue as a transit provider or disappear from the origin? Are route objects and route-origin authorisations ready for the change? How will caches, filtering and customer allowlists be handled? A future AS activation can improve control, but a poorly prepared cutover can also create reachability loss.

Route-origin security cannot be assumed from allocation

Registration establishes who the number system associates with a resource. Routing security asks whether an origin is authorised and whether networks validate that authorisation. These are related but separate controls.

The empty AS152970 prefix set means there is no current AS152970 prefix-origin pair to assess. A reader should not interpret that as either valid or invalid routing. It is simply absent. The company-labelled prefixes originated by AS135967 are separate pairs and should be checked against current Route Origin Authorisations before procurement or a routing change.

The method is described in RFC 6811, which defines BGP origin validation using the Resource Public Key Infrastructure. The broader operational context in RFC 7454 covers filtering and BGP security practices. Neither standard certifies Hoa Lac Cloud; they explain the controls an operator should implement and a customer should ask about.

For a future AS152970 launch, the company would need coordinated registry, route-policy and filtering work. The origin authorisation should match the intended prefix and maximum length. Upstream filters should accept the new origin. Internet Routing Registry entities should be accurate. Monitoring should catch an invalid or unexpectedly more-specific announcement. Rollback should be possible without losing both old and new paths.

The public RADB search for AS152970 and APNIC-derived whois views can provide clues, but route-policy databases can be incomplete or stale. Current provider confirmation and observed propagation remain necessary. Security posture should be assessed on the route actually in use, not the ASN printed on a company record.

Power and facility recovery remain entirely off the public map

BGP can reveal a path while hiding the power system beneath it. Every routed service ultimately depends on utility supply, switchgear, uninterruptible power systems, batteries, generators, fuel, cooling and people authorised to operate them. A customer buying cloud capacity is indirectly buying those systems even if the invoice contains only virtual resources.

Hoa Lac Cloud's public records do not name a facility, power design, cooling arrangement or maintenance regime. They do not show whether the company owns hardware, leases a rack, rents bare metal, or resells virtual capacity. As a result, no claim about Tier level, concurrent maintainability, generator duration or multi-site design is justified.

Evidence should distinguish design from operation. A facility brochure may describe two utility feeds, but the customer's rack could still use one power distribution path. A server may have two power supplies connected to the same circuit. A backup site may exist but lack enough compute or storage to restore all protected workloads. Tested configuration matters more than nominal architecture.

The useful questions are specific. Which facility operator supplies power? Are both server power supplies connected to independent distribution paths? How long can generators run under contracted fuel arrangements? When was a loaded transfer last tested? Does cooling remain redundant during maintenance? Who can enter the room after hours, and what is the response commitment for remote hands?

Public silence is not evidence of bad engineering. Many providers keep sensitive facility detail private. The answer can be provided under confidentiality. What matters is that a buyer does not fill the silence with an imagined Hoa Lac data centre simply because the company name and registry address contain Hoa Lac.

Hardware stock and support labour define the repair clock

Cloud language makes hardware seem interchangeable, but repair still depends on the right component and the right person meeting at the right place. A failed power supply, disk, optic, switch or router cannot be restored by an address registration. Spare stock, vendor support and site access set the practical recovery time.

For a small or young provider, stock strategy can be economically difficult. Holding spare servers and network parts ties up capital. Relying on suppliers reduces capital cost but lengthens recovery when inventory is scarce or import logistics are slow. Leasing infrastructure transfers some stock responsibility to the lessor, but also transfers control over repair priority.

Hoa Lac Cloud's public evidence does not show how these choices have been made. Customers should ask which parts are held on site, which are available elsewhere in Hanoi, and which require vendor shipment. They should ask whether the team can replace components directly or must wait for facility staff. They should also ask whether one engineer holds unique knowledge or credentials.

Support capacity is a real infrastructure constraint. An incident affecting many hosted customers creates a burst of tickets just when technical staff are busiest. If the same people answer routine support, manage routing and perform hardware work, restoration can slow even when replacement parts exist. A credible plan separates communication, triage, technical authority and physical intervention.

The evidence that would settle this is operational: support hours, escalation contacts, recent response measures, spare lists, vendor entitlements and restoration exercise results. A generic uptime percentage cannot reveal whether the provider can replace a failed edge device at 2am.

Billing and provider contracts can remove service without broken equipment

Infrastructure failure is not always physical. A disputed bill, expired contract, suspended account, domain lapse or loss of facility access can stop a cloud service while every server remains healthy. The visible reliance on another origin network makes commercial continuity especially relevant for Hoa Lac Cloud.

A customer should understand whether the AS135967 arrangement is prepaid, monthly, term-based or embedded in a broader managed service. It should know what notice applies before suspension and whether critical routing continues during a billing dispute. It should also know whether customer addresses can remain reachable if Hoa Lac Cloud changes provider.

Provider contracts often contain asymmetry. Hoa Lac Cloud may promise customers a response or availability target that is stronger than the commitment it receives from a transit, hosting or facility supplier. Unless the company holds spare capacity or negotiated priority, the downstream promise can be difficult to enforce during a supplier incident.

The remedy is not necessarily to disclose commercial prices. It is to disclose responsibility and continuity. Which supplier controls each dependency? What commitment flows through? Which failures are excluded? Does Hoa Lac Cloud have a second contract that can carry the service, or only a right to request restoration from the first provider?

Exit terms belong in the same conversation. If a supplier contract ends, can the company move its portable IPv4 and IPv6 blocks while preserving customer configurations? If customer addresses are embedded in firewalls or allowlists, how much notice and testing is needed? Portable resources can improve migration options, but only if routing authority, data movement and support coordination are ready.

Data locality requires a placement record, not a VN label

The APNIC country field and Vietnamese company address establish resource-registration context. They do not prove where customer data, backups, logs or support systems are stored. An ASN country is not a storage-location certificate, and a prefix registered in Vietnam can carry traffic to systems placed elsewhere.

This matters because Vietnam has explicit legal rules around certain data. The government's Decree 53/2022/ND-CP publication records the decree and its 1 October 2022 effective date. The official full text includes provisions on storing specified categories of data in Vietnam. Applicability depends on the service, data and organisation; the existence of a local provider or local address block does not by itself demonstrate compliance.

A customer needs a placement matrix covering primary data, replicas, backups, logs, account information, monitoring and support tickets. The matrix should identify facility country, operating entity, subcontractor access and deletion process. It should distinguish physical storage from remote administration and from legal control.

Hoa Lac Cloud's public materials do not provide such a matrix. Nor do they establish a sovereign-cloud architecture, government certification or sector-specific eligibility. Those claims would require legal and technical documents tied to the actual service.

Data locality also affects recovery. A backup stored in the same building may satisfy a country requirement while failing the customer's disaster-recovery objective. A recovery site in another jurisdiction may improve physical diversity while complicating data restrictions. The right design depends on both legal requirements and failure tolerance, and both must be explicit.

Backup existence is not restoration capability

Hosted services commonly advertise backup as a feature, but a backup is useful only if it is complete, isolated, recent enough and restorable within the customer's deadline. Public routing data cannot answer any of those questions for Hoa Lac Cloud.

Customers should identify who initiates backups, where copies are stored, how credentials are separated and whether destructive access to production also reaches backups. They should ask whether copies survive loss of the primary provider arrangement. If backup traffic, storage and control all depend on the same rack or supplier, the apparent redundancy may fail as one unit.

Restoration throughput matters as much as retention. A provider can retain many terabytes and still be unable to restore them quickly over a constrained link. The relevant exercise is a timed recovery of a representative workload into an isolated environment, followed by application validation. Snapshot creation alone is not a recovery test.

The route evidence suggests one additional scenario: loss of AS135967 origination. Could Hoa Lac Cloud restore reachability through another origin without changing every customer endpoint? If not, can customers use alternative addresses or DNS within the required time? Data may remain intact while the service is unreachable, so network recovery and data recovery must be exercised together.

A credible result would state recovery time, recovery point, data volume, dependencies, failures encountered and customer actions. Until such evidence is available, backup and disaster recovery should remain unanswered questions rather than assumed features of a company with "Cloud" in its name.

Portability is the customer's final resilience control

When a provider cannot restore service, the customer needs an exit. Portability is therefore not merely a procurement convenience. It is the last recovery path after rack, upstream, support, billing or corporate failure.

The technical exit must cover data and configuration. A virtual-machine disk without network rules, identity settings, encryption keys and application metadata may not produce a working service elsewhere. A source summary without logs or entity-store contents may be incomplete. Proprietary images or management interfaces can make apparently standard workloads difficult to move.

The commercial exit must cover timing and access. How long can a customer retrieve data after cancellation? Can export continue during a billing dispute? Is there a bandwidth charge or rate limit? Who assists if the normal control panel is unavailable? Can the customer obtain an export without relying on a single administrator?

Hoa Lac Cloud's portable number resources may help the provider change network suppliers, but they do not automatically make customer workloads portable. Customers generally do not control the provider's /23 or /48. Unless contracts say otherwise, moving a workload may require new addresses, DNS changes and allowlist updates.

A practical test is to move one representative service before dependency becomes critical. Measure the export, import, address change, DNS update and validation time. Record which steps require Hoa Lac Cloud, AS135967, a facility operator or another supplier. That exercise converts an abstract cloud dependency into a known recovery path.

What would count as genuine redundancy

Redundancy is not the number of items in a diagram. It is the survival of an intended service after a defined failure. For Hoa Lac Cloud, every redundancy claim should be traced across compute, storage, network, power, management and people.

Two servers are not redundant if they share one storage array. Two storage copies are not independent if one administrator or ransomware event can erase both. Two network links are not diverse if both depend on AS135967's same edge router or fibre entrance. Two sites are not a recovery system if the second lacks data, compute headroom or current configuration.

The unannounced AS152970 should not be counted as route redundancy. It may become a useful control point in the future, but today the observed company-labelled prefixes use AS135967. The relevant network test is what happens when the current origin, handoff or upstream path is removed.

Evidence should include recent failure exercises. A route failover should show convergence and remaining capacity. A host failure should show restart placement. A storage test should show a complete restore. A facility exercise should show that management, DNS, monitoring and customer communication remain available. A support drill should show who has authority to act.

The best redundancy statement is scoped and measurable: which service, which failure, what capacity remained, how long recovery took and what did not recover. A broad "high availability" label has little value without those boundaries.

Who is affected if the current arrangement fails

The public evidence does not identify Hoa Lac Cloud customers, so no customer list or market footprint should be inferred. The affected population can still be described by dependency class.

Any service using 160.30.86.0/23 or 2001:df4:2540::/48 depends on continued routing of those prefixes. If AS135967 stops originating them and no alternative origin appears, externally reachable services on the blocks would lose global reachability even if their local machines stayed powered. The actual impact would depend on which addresses are assigned and which applications use them.

Customers whose DNS, mail, control panels or monitoring depend on the same network could lose both production and the tools needed to diagnose it. Customers with fixed IP allowlists would face additional work if recovery required new addresses. Customers with backups inside the same provider boundary might retain data but lack an independent route to retrieve it.

The company itself is also exposed. A young provider can suffer reputational and cash-flow damage from an incident even when the root cause sits with a supplier. If responsibility is unclear, customer communication slows and each party may wait for another to act.

This is why affected-party analysis must follow the service rather than the brand. The company should be able to map addresses, workloads, customers, supplier dependencies and recovery priorities. Public BGP can identify the shared route edge; only internal service records can identify the full blast radius.

How to monitor the record without overreading it

AS152970 is useful precisely because its future state can be observed. The RIPEstat AS page, Cloudflare Radar routing view, BGP.tools page and Hurricane Electric BGP Toolkit provide different public lenses. A future prefix appearance, neighbour observation or route-history entry would materially change the evidence.

Monitoring should cover the company-labelled address blocks separately. Their origin can change even while AS152970 remains dormant. An unexpected more-specific route, invalid origin state, reduced visibility or disappearance would warrant investigation. Agreement among multiple route collectors is more useful than a single directory label.

Website monitoring belongs in a different category. A replacement of the default page with a maintained service site would improve evidence of customer-facing activity, but it would not prove routing independence or facility resilience. DNS changes could reveal a provider move, though they would still require registry and BGP cross-checks.

Company-registry and technical-contact changes may also matter. They can signal ordinary administration, growth, restructuring or provider changes. None should be interpreted alone. The discipline is to attach each signal to the narrow fact it supports.

The most decisive future event would be an AS152970 announcement of the company's /23, /48 or other registered prefixes with stable visibility and documented upstreams. Even then, the article's physical questions would remain. A live AS can prove an operating route edge; it cannot by itself prove adequate power, compute, support or recovery.

The evidence scorecard is intentionally uneven

Identity evidence is strong. APNIC RDAP directly names Hoa Lac Cloud Company Limited on AS152970 and on the IPv4 and IPv6 blocks. The records share location, contact and registration timing. RIPEstat and CAIDA repeat the AS name and country from the resource system.

Direct AS152970 operating evidence is negative. Prefix count is zero. First-seen and last-seen are empty. Visibility is zero. Neighbour count is zero. Routing-consistency imports and exports are empty. CAIDA says seen=false, prefix cone zero and degree zero. These are multiple expressions of the same absence, not independent proof of a physical condition.

Address reachability evidence is positive but points elsewhere. The /23 and /48 were broadly visible through AS135967 at the observation time. That establishes a public route surface for company-labelled resources. It also establishes that AS152970 was not the observed origin.

Corporate-context evidence is moderate. A secondary legal-information page reports a July 2024 formation and active status, matching the sequence before the August number registrations. This says little about current cloud products or capacity.

Service, facility and resilience evidence is weak. The public website was a default page. No named facility, rack estate, capacity figure, service-level commitment, recovery exercise, transit contract, support matrix or portability terms were found in the public materials used here. The evidence grade is therefore Negative for direct AS152970 routing, while the broader company-resource picture is mixed: strong registration, positive third-party origination, and unverified cloud operation.

A procurement test built around the actual uncertainty

A buyer considering Hoa Lac Cloud should begin by asking the company to identify the exact service being sold. Is it VPS, bare metal, colocation, managed hosting, backup, network transit or a reseller arrangement? Which legal entity signs the agreement, and which supplier performs each operational function?

The next request should be an address and origin map. It should list the prefixes used for the service, the current origin AS, upstreams, route-origin authorisations, route objects and planned changes. It should explain the role of AS152970 and why the company-labelled blocks are currently originated by AS135967.

The physical request should name facility location at an appropriate level, hardware ownership, rack and power boundaries, carrier entrances, remote-hands responsibility, spare strategy and site-access escalation. Claims of a second site should include usable capacity and a recent recovery result.

The service request should cover monitoring, incident declaration, support hours, escalation authority, status communication, maintenance notice, backup, restoration and customer data export. Each promise should be tested against supplier commitments. If a third party is the pacing dependency, the contract should say so.

Finally, the buyer should run a small exercise before placing critical workloads. Test route reachability from multiple networks, restore a backup, export a workload, open an urgent ticket and record the time to a qualified response. This is more informative than treating the ASN registration as a certificate of readiness.

The narrow conclusion is the useful one

Hoa Lac Cloud Company Limited has a real Vietnamese number-resource footprint. AS152970 is registered, active in the registry and tied to the company as HOALACCLOUD-VN. The company also holds an IPv4 /23 and IPv6 /48 that were publicly visible in July 2026.

But the routing evidence has an important asymmetry. AS152970 itself had no prefixes, no first or last observation, no collector visibility and no neighbours. The company-labelled address blocks were originated by AS135967. The public website also sat on address space registered to that other network and showed a default page.

That combination is not evidence of a failed cloud. It is evidence of a resource holder whose reachable public surface depends on another autonomous system while its own AS record remains ahead of direct BGP operation. The distinction protects the company from unsupported accusations and protects customers from unsupported assurance.

The next proof must come from operation: a stable AS152970 route or a clearly documented managed-origin design; named service placement; power, carrier and facility boundaries; tested recovery; support authority; and a workable data exit. Until those proofs appear, the ASN should be read as capability reserved in the registry, not resilience delivered to customers.