YISU CLOUD LTD sells hosted capacity that still depends on racks, transit and repair windows

Summary

• YISU CLOUD LTD has stronger public operating evidence than a bare corporate shell: Yisu's own site markets cloud and hosting services, APNIC RDAP lists Yisu-controlled AS136970, AS138152 and AS142403 as active Hong Kong autonomous systems, and RIPEstat shows all three announced on July 12, 2026.
• That evidence still does not disclose rack ownership, named facility leases, power topology, cooling redundancy, support staffing depth, or tested customer migration paths. Public routing proves reachable address space; it does not prove how much usable compute capacity can survive maintenance or failure.
• The most important customer risk is a hosted-capacity squeeze: a rack, upstream, hardware-stock, support, billing, migration or provider-contract failure that leaves a small customer with visible IP service but limited leverage over the physical layer underneath.

The storefront is broader than the proof of the plant

YISU CLOUD LTD's public face is a cloud storefront, not a passive route label. The international home page at yisu.com/intl advertises elastic cloud computing, bare metal servers, managed MySQL, anti-DDoS IP, light servers, load balancing and SSL certificates. The same page says the company offers instant cloud-service access in locations such as Tokyo, Frankfurt, Washington and Los Angeles, while its location map also names Hong Kong, Singapore, Japan, South Korea, Germany, Bangkok, India, Indonesia, Australia and the United States. That is a wide commercial claim: Yisu is selling customers the idea that capacity can be ordered through a panel and used as a global hosting surface.

The company's own About Yisu Cloud page makes the claim more explicit. It says Yisu was founded in 2017, calls it a global cloud-service provider, and says it has built cloud-computing services for enterprises, developers and government organisations. It also says Yisu has established green energy-saving data centres and operating offices in Beijing, Shanghai, Guangzhou, Hangzhou, Hong Kong and other Chinese regions, as well as Europe, South Korea, Japan, Singapore and the United States. The same page claims more than 50,000 cloud servers, more than 30,000 cumulative users, more than 2,800 CDN nodes, 130 TB/s of CDN bandwidth and DDoS defence capability above 5,000 Gbps. These are large numbers for a provider with limited independent facility disclosure.

That gap is the article's starting point. The public evidence supports Yisu as a real hosted-service operator with active network infrastructure. It does not support treating every location or scale claim as an audited capacity measure. A product page can say "cloud server"; a customer order can produce a virtual machine; a BGP table can show Yisu-originated routes; yet none of those facts identifies the data hall, rack count, power-feed design, spare-parts pool, repair queue, or customer exit plan. Hosted capacity always looks abstract at purchase time. In failure, it becomes physical.

Yisu's product pages make that physical dependency unusually clear. The Elastic Cloud Computing page says customers can choose CPU, memory, bandwidth and dedicated IP, and it promotes RAID-backed data protection, snapshots, custom internal networks, security groups and DDoS attack defence. The Bare Metal Server page goes one layer lower: it sells dedicated physical servers in single-tenant environments, with automatic operating-system installation, network configuration, disk attachment and lifecycle controls. The Light Server page is simpler but still depends on compute, network and storage being bundled reliably. These are not only software promises. They require servers, disks, switch ports, power, cooling, IP stock, transit, and staff who can rebuild or move customers when something breaks.

The fair reading is neither dismissal nor credulity. Yisu's public network record is substantial enough to study. Its website is specific enough to show a service catalogue. But the facility layer remains opaque enough that customers should ask how the marketed capacity maps to racks, leases and repair windows. The company's own evidence gives the services a shape; the routing evidence gives the network a skeleton; the missing facility evidence defines the risk.

Three Yisu ASNs are visible, but they do different jobs

The strongest hard anchors are APNIC and RIPEstat records for three Yisu-controlled ASNs. APNIC RDAP for AS136970 lists "YISUCLOUDLTD-AS-AP - YISU CLOUD LTD" as an active Hong Kong autonomous system, registered in September 2017 and last changed in January 2021. APNIC RDAP for AS138152 lists "YISUCLOUDLTD-HK - YISU CLOUD LTD" as active, registered in August 2018 and last changed in January 2021. APNIC RDAP for AS142403 lists the same YISUCLOUDLTD-HK name as active, registered in June 2021. All three records point to the same Yisu registrant family in Hong Kong.

RIPEstat confirms that these are not dormant labels. Its AS-overview pages show AS136970, AS138152 and AS142403 as announced on July 12, 2026. The routing-status calls are more useful because they give scale: AS136970 had 17 visible IPv4 prefixes, AS138152 had 44 visible IPv4 prefixes, and AS142403 had 70 visible IPv4 prefixes at the RIPEstat query time. Each showed zero visible IPv6 /48s in that view. In aggregate, that is 131 routed /24 equivalents, or 33,536 IPv4 addresses before any accounting for addresses reserved, filtered, rented, suspended or used internally.

BGP.tools gives a complementary outside view. Its AS136970 page describes Yisu as a content network with 17 IPv4 prefixes, upstreams through ASLINE and AS142403, and one downstream listing for AS142403. Its AS138152 page shows 44 IPv4 prefixes and upstreams through Zenlayer, Cogent and China Telecom Next Generation Carrier Network. Its AS142403 page shows 70 IPv4 prefixes, upstreams through NTT America, AS136970 and HK Kwaifong Group Limited, and one downstream listing for AS136970. Those pages are not facility certificates, but they do show that Yisu's public Internet presence is not confined to one route or one carrier.

The three ASNs also suggest different operating roles. AS136970 looks like an older Yisu network with a smaller prefix set and an internal tie to AS142403. AS138152 looks like a transit-diverse service network with Zenlayer, Cogent, China Telecom Backbone and China Telecom Next Generation Carrier Network visible in BGP.tools or RIPEstat data. AS142403 looks like the largest public edge, carrying many Yisu-described Hong Kong and AFRINIC-described /24s and connecting to NTT, HK Kwaifong Group and AS136970. A customer does not need to memorise the AS map.

It matters because outages, filtering and repair times can be different depending on which AS and upstream path hosts the customer's service.

PeeringDB adds a notable absence. Queries for AS136970, AS138152 and AS142403 return no network entry. That does not prove Yisu lacks peering, facilities or private interconnection. Many smaller hosting networks do not maintain a PeeringDB page, and some buy transit rather than advertise exchange presence. But the absence leaves customers without a public facility list, exchange list, traffic policy or NOC notes from PeeringDB. For a hosted-capacity buyer, that means the public Internet can see the routes, while the physical and interconnection footprint remains mostly behind the storefront.

The address-space mix points to leasing and aggregation, not a single simple pool

Yisu's routed address space is not one neat corporate allocation. APNIC shows some ranges directly under Yisu. For example, 39.109.104.0/24 sits inside an APNIC inetnum for YISU CLOUD LTD in Hong Kong, with APNIC routing information that also shows an origin through AS133115. 103.100.208.0/24 sits in a 103.100.208.0/22 assigned portable block for YISU CLOUD LTD, again with an APNIC route entry through AS133115. Those records are useful because they tie at least part of the visible service surface to Yisu's own APNIC-held numbering.

Other Yisu-originated routes have a more layered story. 43.225.157.0 is in an APNIC allocation described as Better Cloud Limited at Kwai Chung, not a direct Yisu allocation. 103.142.86.0 is described as SHENGYD(HK)LIMITED, with a route entry originated by AS138152. 103.144.244.0 is described as PROSPUR INT'L CO., LIMITED, also with an AS138152 route entry. AFRINIC-served examples add another layer: 154.92.14.0/24 is described as Yisu Cloud Ltd in Hong Kong and originated by AS142403, while 156.227.232.0/24 is described as Cloud Innovation Ltd with country RU and a route description for Yisu Cloud Ltd through AS138152.

This mixture is common in the low-cost hosting and anti-DDoS market. Providers often combine their own portable address space with leased, delegated or routed customer and partner space. The operational implication is simple: advertised IP stock is not the same thing as permanently controlled compute capacity. If a customer receives an address from a block held by another LIR, the service can still work perfectly, but contract terms, abuse handling, geolocation, route authorization, reputation and transfer options may depend on parties beyond Yisu.

That matters when a customer needs to move an instance, reclaim an address, keep search traffic from shifting regions, or answer a banking or compliance review.

The RDAP records include another small but important warning. The Yisu abuse-contact record is marked with remarks saying that [email protected] is invalid in the APNIC RDAP records for AS138152 and AS142403, with a last-changed date in March 2026 for the abuse record. That does not mean Yisu is unreachable through every support channel; its site lists [email protected] on the contact page, and customers buying service would use the customer portal. It does mean the public registry hygiene for abuse handling is not as strong as it should be for a hosting provider whose service includes DDoS mitigation and customer-facing IP resources.

Address-space hygiene is not merely bureaucratic. In a cloud service, IP reputation can decide whether customer mail is delivered, whether a payment gateway accepts traffic, whether a CDN allows origin access, whether a search engine misplaces the site, or whether an abuse report reaches someone before a route is filtered. Yisu's visible route scale is meaningful. The mixture of direct, partner, and AFRINIC-served descriptions means customers should ask what they can keep, move or replace if a provider contract or IP delegation changes.

Product promises turn into physical dependencies quickly

Yisu's Elastic Cloud Computing page sells flexible CPU, memory, bandwidth and storage choices, and says cloud resources can be scaled horizontally and vertically. That is the commercial convenience of cloud hosting. The physical question is what happens when many customers want the same resource in the same location at the same time. Horizontal scaling requires spare host capacity, spare switch ports, enough public or private IP stock, and storage back ends that can absorb new I/O. Vertical scaling requires hypervisor capacity or migration to a bigger host. Neither is guaranteed by a product selector alone.

The same page makes reliability claims: up to 99.95 percent service availability and no less than 99.9999 percent data reliability, RAID data protection, snapshots, custom networks and security features. A customer should read those claims as service design claims, not as proof of an audited region. RAID can protect against some disk faults, but it does not protect against a whole rack losing power, a control plane outage, a storage controller failure, operator error, a failed snapshot restore, or a network drain that leaves a customer cut off from its data.

Snapshots are valuable only if they are stored separately enough from the failed system and can be restored within the customer's tolerance.

The Bare Metal Server page is even more exposed to physical constraints. It advertises dedicated servers in single-tenant environments, quick deployment, 24/7 operation and maintenance, physical isolation, RAID10 data redundancy, multi-link network technology and network isolation. Bare metal is attractive because the customer avoids virtualisation overhead and noisy-neighbour risk. It is also less elastic than a virtual server when hardware stock is tight. A bare-metal failure may require a spare chassis, compatible disks, manual diagnostics, remote-hands access, or an OS reinstall. If Yisu has spare hardware in the same facility, recovery can be fast. If it has to wait for a facility visit or a replacement part, the repair window becomes the product.

Yisu's RDS for MySQL page says its database service uses enterprise-level SSD storage, high availability, read/write splitting, flexible backups and primary-secondary deployment on different servers. That architecture can reduce single-server risk, but it raises new dependency questions. Are the primary and secondary in different racks, different power domains or only different hosts? Are backups kept in a different storage cluster? Can a customer export a usable dump during an incident, or only through a working control panel? Does a failover preserve application credentials and connection endpoints? A managed database service is convenient exactly because it hides these mechanics. The buyer still needs a portability plan.

The Elastic Load Balancer page sells Layer 4 and Layer 7 forwarding, health checks, session persistence, and redundant design. The strongest use of a load balancer is to absorb individual server failure. The weakest use is to place all customer instances behind a load balancer that itself depends on one site, one upstream path, one account, or one control plane. Yisu's page says service-node activation and deactivation do not affect current service. That is plausible for a well-designed cluster, but the public page does not identify the cluster's facility spread or whether customer workloads can be balanced across regions.

The Anti-DDoS IP page is the most network-dependent product of all. It advertises large DDoS cleaning capability, real-IP hiding, TCP/UDP/HTTP/HTTPS support, DNS flood protection and 24/7 support. The page also contains both "over 5000 GB" and "1000G+" style capacity language, which should be read carefully because marketing pages often mix total platform capacity, per-product tiers and best-case scrubbing peaks. DDoS defence is not only a bandwidth number. It depends on clean upstream capacity, scrubbing locations, false-positive control, routing speed, attack-type coverage, and whether a customer can move away if the protected IP becomes blocked or saturated.

Hong Kong is the public anchor, while global capacity remains harder to verify

Yisu's legal and network records are strongly Hong Kong-anchored. APNIC RDAP lists YISU CLOUD LIMITED as an HK organisation with an address at World Peace Centre, Wo Tong Tsui Street, Kwai Chung, and APNIC whois records for Yisu-held IP blocks repeat the same Hong Kong contact family. Yisu's public site also says its global strategy includes Hong Kong, and its location map distinguishes Hong Kong from other listed regions. The Hong Kong anchor is credible.

What remains less clear is how much of the service catalogue is operated by Yisu-owned racks, leased cages, rented servers, reseller contracts, or partner capacity in each advertised location.

Hong Kong is a plausible place to build this kind of service. The government's data-centre portal calls Hong Kong a prime data-centre location because of robust telecoms, external submarine cable systems, a liberalised telecom market, around 300 licensed broadband providers, high power reliability, free flow of information and data-privacy law. The Digital Policy Office's Data Centre Facilitation page says the government supports data centres as core infrastructure for finance, trading, logistics and cloud computing, and notes that a Sandy Ridge Data Facility Cluster site was awarded in March 2026. The same page says Hong Kong benefits from reliable power, sound telecommunications infrastructure and low natural-disaster risk.

The supply side is not frictionless. A June 2024 Legislative Council reply on properties available for data-centre use said Hong Kong had about 970,000 square metres of data-centre floor area at that time, estimated a short-to-medium-term operator demand of about 300,000 square metres, and expected total floor area to reach 1.5 million square metres by 2026. The same reply discussed industrial-building conversion, redevelopment, floor height, load bearing, fire safety, security, sewage, parking, lifts, toilets, power supply and backup generation as practical issues. That is exactly the physical world behind a cloud provider's product grid.

For Yisu, the public evidence does not tie every advertised region to named facilities. The home page's quick-buy offers mention Tokyo, Frankfurt, Washington and Los Angeles, while the about page names United States, Germany, Bangkok, India, South Korea, Japan, Hong Kong, Singapore, Indonesia and Australia with activated, constructing and planning labels. Those are useful commercial signals, but they should not be converted into independent availability zones without further proof.

A region label can mean owned racks, rented dedicated servers, virtual capacity from a third party, a DDoS-cleaning point, or an ordering location in the user interface.

The operational boundary is therefore the real issue. If Yisu controls a rack directly, it can split power feeds, replace a disk, coordinate cross-connect repair and enforce access procedures. If Yisu resells a provider's server in another country, it depends on that provider's remote-hands queue, spare parts, billing status, maintenance windows and route policy. If Yisu provides an anti-DDoS front end in one place and origin hosting in another, the customer depends on both. Global hosting is valuable precisely because it gives choice. It is risky when the buyer cannot tell which party controls the failure domain.

Transit diversity exists, but it is not the same as site diversity

Yisu's routing is not single-homed in the simplest sense. RIPEstat's AS138152 neighbour view shows four observed neighbours on July 12, 2026: AS174, AS21859, AS4134 and AS4809. BGP.tools labels those as Cogent, Zenlayer, China Telecom Backbone and China Telecom Next Generation Carrier Network in its public page for AS138152. That is a meaningful mix for a Hong Kong and China-facing hosting provider. It suggests Yisu can reach customers through global transit, hosting-oriented transit and China Telecom-related paths.

AS142403 has a different shape. RIPEstat's AS142403 neighbour view shows AS133115, AS136970 and AS2914 on the left side, with AS136970 also appearing on the right side. BGP.tools identifies those visible upstreams as HK Kwaifong Group Limited, Yisu's own AS136970 and NTT America. AS136970, in turn, appears in RIPEstat's neighbour view with AS142403 and AS18013, which BGP.tools identifies as Yisu and ASLINE. The result is a network where the Yisu ASNs are interdependent and where outside transit differs by ASN.

That is better than a single visible upstream, but it does not settle the physical-resilience question. BGP neighbours can exist in the same building, on the same meet-me room path, through the same cross-connect provider, or through circuits that share a duct outside the facility. They can also be geographically diverse. Public BGP data rarely distinguishes those cases.

A customer who sees AS138152 connected to Zenlayer, Cogent and China Telecom paths still needs to know whether its server is attached to redundant top-of-rack switches, whether those switches exit through separate routers, and whether a maintenance window on one facility can remove all practical reachability.

Yisu's China-facing marketing makes this especially important. The home and about pages repeatedly mention CN2-style bandwidth and fast return paths to domestic users. China Telecom Next Generation Carrier Network visibility on AS138152 supports the idea that China-facing transit matters to the service. It does not prove end-to-end performance from every advertised city or from every mainland access network. China-facing routes can be valuable, congested, filtered, expensive, or contract-limited depending on the circuit and provider.

A service that works well for a Hong Kong customer may behave differently for a mainland enterprise, a Southeast Asian user or a North American origin.

The public absence from PeeringDB also matters here. A PeeringDB page could list exchanges, facilities, traffic policy and NOC contacts. The no-entry result for Yisu's three ASNs leaves public transit evidence scattered across BGP tools and registry records. That does not make the network weak by itself. It makes customer due diligence more manual. The buyer should ask which AS will originate its service IP, which upstreams will carry it, whether failover has been tested, whether DDoS protection changes the path, and whether Yisu can move the route or service to a different region without forcing a rebuild.

Support and billing are part of the infrastructure

Yisu's website sells technical control, but the service depends on administrative systems too. The home page promotes a console, one-click deployment, monitoring graphs, configuration management and 24/7/365 technical support. The contact page gives a support email and a web form. The product pages route customers toward sign-up, login, billing, add-funds and console links. In a low-cost hosting model, these systems are not secondary. If billing, account verification or the control panel fails, a customer may be unable to renew a server, replace an IP, open a ticket, resize storage or recover from suspension.

Support depth is particularly important because Yisu sells both virtual and physical products. Virtual servers can often be restarted, reinstalled or resized through automation. Bare metal can require hands-on work. DDoS protection can require live traffic analysis and route tuning. Managed MySQL can require backup restoration, failover decisions and performance triage. Load balancing can require health-check correction or certificate replacement. A provider can advertise 24/7 support, but the real metric is whether support can change something at the rack, on the router or in the customer account during a live incident.

The APNIC contact-health note should not be overread, but it should not be ignored. RDAP's remark that the [email protected] contact is invalid does not necessarily describe customer support. It does, however, show that the public abuse contact attached to Yisu's APNIC resources has a validation problem. Hosting providers live with abuse reports every day: compromised servers, phishing pages, scanners, DDoS command nodes, spam, credential stuffing, open proxies and bot traffic. If abuse mail bounces or is poorly monitored, upstreams and reputation providers can escalate by filtering or null-routing address space.

That can affect innocent customers who share a prefix or upstream segment.

Billing risk is similar. Cloud users often think of cloud as elastic, but many lower-cost providers operate on prepaid balances. If a customer's card fails, a balance runs out, a fraud check stalls, or a reseller account is suspended, compute can disappear faster than in an enterprise contract. Yisu's login and billing links show a conventional panel-led service. The public site does not explain grace periods, data-retention windows, account-lock procedures or export rights. Those terms decide whether a customer can survive an administrative problem.

Support windows also shape migration. A customer can move a static website quickly if it keeps backups and DNS control. A customer running a stateful database, game server, paid API, ad-tech endpoint or China-facing site may need IP continuity, data snapshots, firewall rules, certificates and route reputation. Yisu's pages talk about snapshots, backups and smooth migration in product-specific language, but the public pages do not define cross-provider export guarantees. In a provider-contract failure, the most important support question is not whether a ticket receives a polite reply.

It is whether the customer can get the data, addresses and service configuration out before the clock runs out.

Locality and data sovereignty need a buyer-side plan

The assignment's locality question is central for Yisu because its marketing spans Hong Kong, mainland China, Asia-Pacific, Europe and the United States, while its legal and network records are strongly Hong Kong based. Data locality is not only about where a company is registered. It is about where the workload runs, where backups reside, where support staff can access data, where DDoS traffic is cleaned, which laws govern transfer, and what happens when the customer needs proof.

Hong Kong's public data-centre portal stresses free flow of information and the Personal Data (Privacy) Ordinance as advantages for data-centre operators. The Privacy Commissioner has also published guidance on cloud computing, warning data users to conduct due diligence on cloud providers, contractual protection, subcontracting, security, data access, retention and cross-border transfer. That guidance is written for customers, not only providers. The key point for Yisu buyers is that a hosted-service claim does not answer locality questions by itself.

Yisu's product pages do not publicly expose a region-by-region data-processing schedule. They do not say whether managed MySQL backups stay in the same location, whether snapshots replicate out of region, whether anti-DDoS cleaning changes the jurisdictional path of traffic, whether support can access customer disks from outside Hong Kong, or whether a customer can contractually pin data to a chosen region. Some small customers may not care. For customers in finance, health, public services, regulated e-commerce, gaming, ad tech or mainland-related operations, those details matter.

The address-space mix complicates geolocation. Some Yisu-originated blocks are Hong Kong-described APNIC space. Some are AFRINIC-served ranges with Hong Kong, Russian or other descriptions in whois data. Some are described under other Hong Kong companies but originated by Yisu. IP geolocation vendors may map those addresses differently. A customer may buy "Hong Kong" service and find that fraud tools, ad platforms or payment processors read the IP as another jurisdiction until databases update. That is not necessarily Yisu's fault, but it is a predictable operational issue when hosting providers use mixed IP pools.

Data sovereignty also intersects with customer exit. A customer who needs to prove locality should not rely on a product-location dropdown. It should retain independent backups, document where its service is ordered, record the assigned IP ranges and ASNs, ask for written statements about backup location and support access, and test restore into another provider. Yisu's network and product evidence makes it a credible candidate for some hosted use cases. It does not remove the customer's duty to verify where the data, logs and backup copies actually sit.

Failure paths that would expose the hidden physical layer

The first failure path is rack or host failure. For a Yisu cloud server, the customer may see a restart, reduced performance, disk I/O errors or an instance that fails to boot. For bare metal, the same failure can be slower because a physical server may require component replacement or a full migration. If Yisu has spare host capacity and reliable automation, the customer can be moved. If the affected location is supply constrained, the customer waits for repair or accepts a different region. The public product pages do not reveal spare-capacity policy.

The second failure path is upstream or route failure. AS138152 has several visible neighbours, but not every customer prefix necessarily benefits equally. AS142403's path mix is different, and AS136970 depends partly on AS142403. A route leak, filtering action, cross-connect outage, contract dispute or DDoS mitigation change could affect one ASN or prefix group while leaving another healthy. Customers should therefore monitor their actual assigned prefix and AS, not only the provider's main domain. A server can be running while the route to it is sick.

The third failure path is hardware-stock exhaustion. Yisu sells low-cost elasticity and bare metal. If a location sells out, customers may still see a purchase page, but provisioning can slow, substitute hardware can differ, or repair can depend on parts delivery. The BMS page advertises auto provisioning, OS installation and disk attachment after purchase. That is useful when stock exists. It is fragile when the stock is exhausted or when a specific CPU, memory, SSD or bandwidth tier is no longer available in the requested facility.

The fourth failure path is support overload. Anti-DDoS traffic, abuse complaints, upstream filtering and control-panel issues can produce many tickets at once. Yisu's Anti-DDoS IP page says the service can hide the origin IP, support multiple protocols and provide customized strategies. During a real attack, the customer needs rapid tuning: false-positive control, protected-domain changes, origin lock-down, route changes and post-attack cleanup. If support is thin, the promised scrubbing capacity may not translate into usable recovery for each customer.

The fifth failure path is billing or account lockout. A prepaid hosting customer may lose access because of balance, risk review, abuse handling, payment channel failure or reseller status. That kind of outage is not visible in BGP. It can still be fatal if the customer cannot renew, export, snapshot or open tickets. Yisu's public pages do not describe termination grace periods or data-retention terms. Customers should assume they need off-platform backups and DNS control.

The sixth failure path is migration failure. Yisu's pages mention snapshots, backups, smooth migration and flexible configuration. Those are valuable only if a customer has tested them. A hosted service that runs for years can accumulate local dependencies: firewall rules, private networks, whitelisted IPs, database endpoints, SSL certificates, anti-DDoS front doors and monitoring tied to Yisu-specific controls. A provider outage becomes much worse when the customer discovers that its own architecture cannot move.

What would make Yisu's operating claim stronger

The fastest way to improve the public confidence grade would be facility disclosure at a non-sensitive level. Yisu does not need to publish cage numbers. It could identify which regions are Yisu-operated, which are partner-operated, and which are resale or virtual capacity. It could disclose whether Hong Kong services sit in one or more facilities, whether those facilities have separate power domains, whether China-facing transit is physically diverse, and whether managed MySQL replicas and backups can cross facilities. That would turn a marketing map into an operating map.

Transit disclosure would also help. Yisu's BGP evidence already shows multiple upstream paths, but customers need to know how those paths map to products. A cloud server on AS142403 may have a different upstream mix from one on AS138152. A DDoS-protected IP may route through a cleaning network before reaching the origin. A bare-metal product may be bound to a different facility from a light server. A customer-facing page that says which AS and transit mix apply by location would reduce uncertainty without exposing sensitive operational details.

IP-governance disclosure would be valuable because Yisu's visible route set includes direct Yisu blocks, partner-described APNIC blocks and AFRINIC-described ranges. Customers should know whether assigned IPs are portable within Yisu, whether replacement IPs can be issued quickly, whether geolocation correction is supported, whether abuse notices are handled through a validated mailbox, and whether IP reputation problems trigger suspension or remediation. For many small hosting customers, IP continuity is as important as CPU continuity.

Recovery evidence would matter most. Public incident summaries, maintenance histories, restore targets, backup-retention terms, bare-metal replacement windows and export procedures are more useful than a generic reliability percentage. A provider can honestly offer 99.95 percent service availability and still leave one customer unable to recover a database fast enough. What customers need is not only uptime math; they need proof that failover and restoration have been rehearsed.

Finally, Yisu could make locality easier to verify. A region-by-region statement for compute, storage, snapshots, support access and anti-DDoS traffic would help regulated customers decide whether Yisu fits their risk model. Hong Kong is a credible and attractive base for hosting. Global capacity is useful. But customers who care about data sovereignty need contract language and technical controls, not only a region label in a purchase flow.

Bottom line

YISU CLOUD LTD is a real public infrastructure subject. Its website sells a broad cloud and hosting catalogue, APNIC records tie multiple active ASNs to the company, RIPEstat sees 131 visible IPv4 /24s across three Yisu ASNs on July 12, 2026, and BGP.tools shows non-trivial upstream diversity. This is not a ghost provider.

The operating evidence is still incomplete. Public sources do not prove the facility count, rack ownership, power design, cooling redundancy, hardware-stock depth, support staffing, DDoS clean-capacity distribution, managed-database restore behaviour, or cross-region migration limits behind Yisu's service catalogue. The strongest conclusion is therefore measured: Yisu has visible hosted-service infrastructure and a Hong Kong-anchored network record, but customers should treat its marketed capacity as dependent on physical sites and third-party paths that are only partly visible.

For small websites, test environments and cost-sensitive workloads, that may be acceptable if the customer keeps backups and monitors the assigned prefix. For stateful, regulated or revenue-critical workloads, the buyer should ask harder questions before relying on Yisu as a primary platform: which facility, which ASN, which upstreams, which backup location, which support escalation path, which exit method, and which repair window. Cloud capacity is sold as a control-panel choice.

At YISU CLOUD LTD, as at every hosting provider, the service ultimately stands or falls on racks, transit and people who can fix things when the control panel is no longer enough.