Summary

  • Haruzakura Cloud has a traceable Chinese public identity: a domain registered in 2023, an archived 2024 storefront using the Chinese name 春樱云计算, and APNIC records registered later in 2024 for AS153458 and an IPv6 allocation in Wuhan.
  • The network evidence is real but narrow. In July 2026, public route collectors saw one RPKI-valid IPv6 /48, no originated IPv4 prefix and one observed upstream, the same organisation that sponsors the ASN and holds the parent address block.
  • The historical site offered VPS, virtual hosting, control-panel functions, backup or snapshot features, DDoS options, multiple country and city labels, tickets and round-the-clock support. Those are seller claims, not independently measured service outcomes.
  • The apex domain had no public A, AAAA or MX answer during a July 2026 check. That does not prove that the business has ceased, but it removes the easiest public route to current product, contract, status and support evidence.
  • A serious buyer should treat the name, website, number resources, route and support claims as separate proofs. The purchase case depends on a current legal identity, workload-level location schedule, support escalation terms, recovery tests, export rights and evidence that the service can operate beyond a single visible network path.

A cloud name with two different kinds of proof

Haruzakura Cloud is a useful test of how easily the word “cloud” can outrun the record behind it. The surviving public material contains enough specificity to rule out the idea that the name is merely an empty directory label. It also contains too many gaps to let a procurement team translate that name directly into operating assurance.

The first kind of proof is commercial. An Internet Archive capture from August 2024 preserves a Chinese-language storefront under the name 春樱云计算. It offered virtual private servers, virtual hosting, a light-host product labelled with UCloud, account registration, a customer console and several location choices. The page described actions such as starting, stopping and restarting a server, reinstalling an operating system, resetting a password, viewing resource use and taking backups or snapshots. It displayed starting prices and made repeated claims about online service, ticket support and 7*24 assistance.

The second kind is infrastructural. APNIC's record for AS153458 identifies HARUZAKURA-AS-AP, country CN, with the description Haruzakura Cloud and a Wuhan address. A separate APNIC record for 2406:840:feac::/48 assigns that IPv6 block to the same name. Public route collectors can see the prefix. A matching route-origin authorisation makes the observed announcement RPKI-valid.

Those proofs answer different questions. The archived page says what somebody using the brand offered in 2024. The registry says who is accountable for an Internet number resource. The routing system says that other networks could learn a path to that resource. None of them, on its own, demonstrates that a customer received the promised virtual machine, that a backup restored, that a support engineer answered at 03:00, or that data stayed in a contracted jurisdiction.

The storefront came before the autonomous system

The dates tell a compact story. Verisign's domain record says haruzakura.com was registered on October 15, 2023 through Alibaba Cloud Computing's HiChina registrar. By August 2024, the archived site was selling products. APNIC registered the Haruzakura organisation entity and IPv6 block on November 12, 2024, then registered AS153458 two days later. The commercial presentation therefore predates the public autonomous-system identity by several months.

That sequence is not inherently suspicious. Hosting sellers often begin on another provider's infrastructure and acquire number resources later. A reseller may never need its own ASN. A young operator may add routing control as it grows. But the chronology prevents a careless inference: the products displayed in August cannot be assumed to have run on AS153458, because the ASN did not yet exist in the public registry. The Hong Kong, Los Angeles, Germany and Chengdu labels on that page also cannot be mapped to the later /48 without server, facility or route evidence.

The offer itself mixed several possible operating roles. Virtual hosting starting at RMB 2.40 suggests a shared-service layer. VPS plans starting at RMB 15 referred to independent IPv4 support, multiple data centres, SSD RAID 10 and bandwidth options. A UCloud-labelled light-host plan starting at RMB 34 described an IPv4 address and global data centres. The page also described a physical-server product as forthcoming. This is a catalogue, not one uniform technical platform. It could combine resources directly operated by Haruzakura, services resold from larger providers and products provisioned through third-party panels.

The public page did not assign responsibility among those layers.

The archived console language is more useful than the adjectives. Power control, reinstall, password reset, resource views, backups and snapshots describe customer actions that could be tested. “Quality network,” “powerful hardware” and “high stability” do not. The first set can become acceptance criteria: how long does provisioning take, which actions are logged, who can override them, and can a snapshot be exported? The second set remains advertising until tied to a measurement and a remedy.

A December 2024 capture complicates the picture. It still promoted cloud servers, root access, power controls, configuration changes and a remote VNC console. Yet it also contained long stretches of unrelated English template copy, generic mobile-app download counters, sample testimonials and app-plan prices. That material should not be used to allege deception; an unfinished redesign is a simpler explanation. But it does show why page content must be graded. A visible counter is not a customer metric when the surrounding labels describe Android, iOS and Windows app downloads on a server-hosting page. The record of a claim survives; the credibility of that claim depends on context.

Identity is a join, not a label

Three names appear across the public material. The commercial brand is 春樱云计算, naturally rendered as Haruzakura Cloud. The August page displayed 湖北春樱云计算信息技术有限公司, or Hubei Haruzakura Cloud Computing Information Technology Co., Ltd., in its footer. APNIC uses the English organisation label Haruzakura Cloud. These names are plausibly connected, but each comes from a different system and each system has a different purpose.

The archived page also displayed the filing number 鄂ICP备2024050251号-1. China's rules for non-commercial Internet information services require filing for covered services provided within China and require accurate information in that process. The footer therefore supplies a concrete identifier that a buyer can verify with the competent authority. It should not be inflated into more than that. A website filing is not a cloud-security certification, a telecom licence for every service, proof of beneficial ownership, or evidence that the products displayed above the footer were operating as described.

Domain registration provides another partial join. Verisign shows an active .com registration and HiChina nameservers. HiChina's own RDAP response places the privacy-redacted registrant in Hubei. It does not disclose a company name or person, so the domain record cannot independently prove that the registrant is the Chinese company named on the old page. It does, however, align geographically with the Hubei identity and the Wuhan address later used in APNIC.

APNIC adds a more attributable technical identity. The ASN record names a human administrative and technical contact, a Wuhan address and an incident-response contact whose email was validated in May 2026. That is meaningful. Number-resource governance depends on reachable people and maintainers, and a recently validated abuse contact is stronger than an abandoned record. Yet validation of that mailbox says nothing about the commercial support queue, the authority of the person to sign a customer contract, or the staffing available to diagnose a hypervisor, storage or application problem.

For procurement, the missing join is straightforward to state. The contracting party should provide a current Chinese business-register extract, its unified social credit code, the exact relationship between that entity and the domain registrant, its authority to use the Haruzakura brand, and the service roles of every subcontractor. The contract name, invoice name, account receiving payment, website filing identity and APNIC organisation need not be textually identical. They do need a documented path between them.

What one IPv6 route proves

The strongest current evidence for Haruzakura is also the easiest to overread. A RIPEstat routing-status snapshot at July 14, 2026 16:00 UTC saw one IPv6 /48 originated by AS153458, no originated IPv4 space and one observed neighbour. The route was visible to 320 of 321 full-feed IPv6 peers in RIPE RIS. That is broad control-plane propagation: the announcement was not merely sitting in a registry without being seen by the wider Internet.

The companion announced-prefixes view identified 2406:840:feac::/48 as the sole sufficiently visible prefix during its two-week window. BGP.Tools and the Hurricane Electric BGP Toolkit independently showed the same basic shape: zero IPv4 prefixes, one IPv6 prefix and one observed external ASN. Agreement across collectors is useful because route views are time-dependent and incomplete.

The /48 is substantial address space in numerical terms, but address count is the wrong measure of cloud capacity. IPv6 allocations are deliberately large. A /48 can support many subnets while carrying no customer workload at all, or it can serve a modest platform. Public routing does not reveal how many addresses are active, how many servers exist, which ports answer, where machines are located, how storage is replicated or whether customer traffic uses the block.

The absence of an originated IPv4 prefix deserves equal care. The old storefront advertised IPv4 in several offers, but those offers predate the ASN. Haruzakura could have used addresses supplied and originated by another provider, could have stopped those products, or could have served customers behind other arrangements. The public evidence supports only a narrower statement: AS153458 itself was not visibly originating IPv4 at the observation point. It does not support the claim that Haruzakura never had IPv4 service.

RPKI improves one part of the picture. The RIPEstat validation result reports a matching route-origin authorisation for AS153458 and the exact /48. As APNIC explains, a valid ROA lets networks verify that the address holder has authorised that ASN to originate the prefix. It helps reduce accidental or malicious origin hijacks.

It does not sign the application, authenticate the company selling a virtual machine, validate the complete AS path or ensure that every upstream rejects bad routes. It does not show DDoS capacity, encryption, patching, access control or recovery. RPKI-valid is a precise and valuable statement. “Secure cloud” is a much larger one.

The sponsor and the single visible path

The prefix record classifies 2406:840:feac::/48 as ASSIGNED NON-PORTABLE. The parent 2406:840::/32 is held by Ningbo Dahuamao Information Technology Co Ltd, according to APNIC's sponsor record. That organisation is also named as the ASN sponsor. Public route collectors see its AS139317 adjacent to Haruzakura, and the RIPEstat neighbours view reported no second neighbour at the observation point.

This is a coherent technical relationship. The sponsor holds the parent address space; Haruzakura receives a non-portable delegation; and the sponsor's ASN is the visible provider-side path. It is stronger evidence than a free-form website badge because registry delegation and global routing agree. It also describes dependence.

Dependence is not the same as weakness. Many capable small networks use one transit provider, and a sponsor can supply valuable registry, routing and operational support. The commercial question is whether the service promise acknowledges the dependency. If Haruzakura's only public route disappears when AS139317 has an outage, configuration error or commercial dispute, what alternate path exists? Does the service have another upstream not visible in the snapshot? Can the prefix move? Who controls the ROA, route objects and emergency changes? What happens to the non-portable block if the sponsor relationship ends?

The answer matters most during abnormal operation. A single provider can be perfectly adequate for a low-cost development host whose owner accepts downtime. It is harder to justify for a workload sold as highly available, a support portal needed during an incident, or a system whose recovery depends on reaching backups through the same path. The buyer should match topology to business impact instead of grading every service against hyperscale architecture.

A PeeringDB record for AS153458 illustrates why claims must be reconciled. The profile, created in March 2026, labels the network Educational/Research, says traffic is in the 1–5 Gbps band, and contains capacity fields for 24 IPv4 and 42 IPv6 prefixes. It lists no exchange, facility, looking glass or public status dashboard. PeeringDB profiles are self-entered. The capacity fields are not the observed route table, which showed zero IPv4 and one IPv6 prefix. Nor does an Educational/Research selection prove that the operator is a university or research institution.

The domain is registered but the service surface is quiet

The domain was active in the registry during the July 2026 review, with HiChina nameservers and an expiration date in October 2026. DNS told a more limited story. A Google Public DNS A query and AAAA query returned successful DNS status and the authoritative start-of-authority record, but no address answer for the apex. An MX query likewise found no inbound-mail destination. The zone did publish an SPF TXT policy referring to Alibaba's mail service, but SPF without an MX record does not make a normal inbound address at the apex reachable.

That observation has a narrow meaning: a browser or mail sender using the bare domain had no ordinary public destination from those record types at that time. It does not establish that every subdomain was absent, that all customer systems were offline, that support used no other domain, or that the company had dissolved. DNS can change quickly, and services can be private or separately named.

Still, silence at the advertised domain carries an operating cost. The historical page was the place where a buyer could see products, terms, account entry points and support language. Without a current site, it is harder to identify the live catalogue, check prices, find an incident notice, review a privacy policy, validate a certificate, or establish which old claims remain in force. The current route does not compensate for that loss because the route does not identify an application endpoint.

The absence of a public status dashboard in PeeringDB compounds the problem. A small provider does not need an elaborate communications operation, but it does need an out-of-band way to tell customers whether the control panel, network, storage and support queue are healthy. If the same domain and route carry both production traffic and incident communications, a network failure can remove the explanation along with the service.

Does the offer meet the meaning of cloud?

The old storefront used cloud language broadly. NIST's definition gives that language a useful operational test: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. It also separates software, platform and infrastructure service models. These are not branding requirements. They help a customer understand what is automated, what is shared and what remains the provider's responsibility.

Haruzakura's archived control-panel claims point toward on-demand infrastructure. A customer could apparently start, stop, restart and reinstall a server, reset credentials and view resource use. Configurations were described as adjustable, and several plans had explicit CPU, memory, storage, bandwidth and traffic quantities. Those are more cloud-like than a bare promise to rent a machine.

Other characteristics are unclear. The page did not show a provisioning-time distribution, an API, an autoscaling mechanism, an image catalogue with provenance, a metering method or a billing ledger tied to resource events. It did not explain whether CPU and memory were reserved, burstable or contended, even while using language such as dedicated resources and full CPU performance. It did not define the resource pool or identify which products were Haruzakura-operated rather than resold. It offered locations but did not publish a region architecture.

The distinction changes the automation risk. In a mature infrastructure service, a console action should pass through authenticated APIs, policy checks, job state, audit events and rollback or recovery paths. In a lightly integrated hosting service, the same button may call a third-party panel or create a manual support task. The customer experience can look similar during a routine reboot and diverge sharply when a job stalls, a password reset targets the wrong instance or a reinstall destroys data.

This is where a demonstration is more valuable than a slide. A buyer should provision a disposable instance, measure the time to ready state, exercise console actions, rotate credentials, create and restore a snapshot, export data, inspect event history, trigger a billing change and close the account. Every action should have an attributable result. Failed actions should expose a state that support can diagnose. Automation that hides uncertainty simply transfers work to the customer's reviewers.

Data locality is a workload map, not a country code

Haruzakura's records contain several geographical signals: Hubei in the domain record, Wuhan in APNIC, Ningbo for the sponsor, country CN on the ASN and prefix, and location labels including Hong Kong, Los Angeles, Germany and Chengdu on the August storefront. None is a complete answer to “Where is my data?”

The country field in an Internet registry is administrative. A route can be originated from equipment elsewhere, carried through several countries and terminate at a server whose storage has a different replication path. A storefront location can describe a virtual machine while its billing data, console metadata, abuse logs and backups sit in other systems. A support engineer can access a workload from a further jurisdiction. A third-party panel can process credentials outside the facility named on the order.

The buyer therefore needs a data-location schedule by data class. At minimum it should cover customer content, attached volumes, snapshots, backups, object storage, network-flow data, console logs, support attachments, identity records, billing records, monitoring telemetry, security logs and deleted-data remnants. For each class, the schedule should identify the primary location, replicas, support-access locations, subprocessors, retention, encryption-key control and deletion process. “China,” “Hong Kong” or “global” is too coarse.

This is an operational requirement as well as a legal one. China's Network Data Security Management Regulations, effective since 2025, require covered processors to establish data-security management and use measures including encryption, backups, access control and authentication, while handling security incidents and bearing responsibility for processed data. The Personal Information Protection Law sets duties around personal information, sensitive information and cross-border provision. The revised Cybersecurity Law, effective in 2026, reinforces network-operation security and responsibility.

Those laws do not let an outsider declare Haruzakura compliant or non-compliant from an ASN page. The applicable role depends on the customer, data, service, contract and access path. They do make vague location language expensive. If a buyer cannot identify who processes which data and where, it cannot confidently classify the transfer, set retention, answer a data-subject request, investigate an incident or design an exit.

The historical catalogue makes this especially important because it appears to combine products from different supply chains. A Haruzakura VPS, a virtual-hosting account and a UCloud-labelled light host may have different infrastructure owners, panels, backup systems and contractual terms. Data sovereignty must follow the actual product chain. The provider should disclose those differences before onboarding, not after a support case exposes them.

Support is a labour system

The August page made support central to the offer. It advertised one-to-one after-sales help, 24x7 ticket delivery, online customer service, professional technicians, free technical support and repeated 7*24 availability. For a small provider, local-language assistance and flexible human intervention can be the strongest reason to buy. It can also become the largest hidden uncertainty.

Availability wording does not define labour. A queue can accept tickets around the clock while engineers work limited hours. One person can cover sales, abuse, network and systems operations until two incidents collide. An online chat can answer account questions without being authorised to change a route or recover storage. “One-to-one” may mean a named contact, a rotating account or simply direct chat. The public page gave no staffing model, severity matrix, first-response target, restoration target or escalation tree.

The APNIC contact surface should not be mistaken for customer support. A validated incident-response mailbox is good resource stewardship. Its purpose is to receive network-abuse and security reports, not to guarantee a response to a failed backup or locked console. The domain's missing MX answer in July 2026 makes it still more important to identify the current commercial channel.

A support schedule should name the covered languages, hours and time zone; distinguish first response from diagnosis, workaround, restoration and final resolution; define severity by business impact; and state how a customer escalates when the portal is unavailable. It should identify who can perform account recovery, routing changes, hypervisor work, storage restoration and facility remote hands. Maintenance notifications, emergency changes and security incidents need separate commitments. So do abuse complaints, which can lead to suspension and require a different evidence chain.

The customer should test the system before a critical migration. Submit a routine technical question outside normal office hours. Ask for a traceable escalation. Run an authorised recovery exercise. Verify the identity checks used before staff reset an administrator account. Request a sample incident notice and post-incident report. The result is not merely a response-time score; it reveals whether the provider has roles, handoffs and records that survive stress.

Local support labour also affects price. A low monthly server fee can coexist with high customer-side supervision: translating tickets, repeating diagnostics, monitoring service health, checking manual changes and escalating through personal contacts. Good support reduces that burden. Opaque support transfers it to the buyer. The relevant commercial metric is therefore not “ticket available 24/7,” but minutes of customer effort per accepted change or resolved incident, alongside repeat incidents and time to stable restoration.

Control panels concentrate both convenience and risk

The historical control surface included some of the most consequential actions in a hosting service: power operations, password reset, operating-system reinstall, remote VNC, backup and snapshot management, and resource changes. These functions replace manual labour and can shorten recovery. They also concentrate privilege.

A stolen console account can become more damaging than a compromised guest password. An attacker may reset credentials, attach recovery media, reinstall a system, delete snapshots or view a console that exposes secrets. A mistaken automation job can target the wrong customer resource. A support worker with broad override rights can bypass normal approval. The security question is not whether a control panel exists; it is whether identity, policy and evidence surround every powerful action.

A buyer should expect multifactor authentication, session controls, role separation, scoped support access, re-authentication for destructive operations, immutable or protected audit events and notification of sensitive changes. Password resets and account recovery should use verified channels that an attacker cannot easily redirect. API tokens, if offered, need scopes, expiration and rotation. Reinstall and snapshot deletion need explicit warnings and recoverable states where feasible. Console access should be logged with actor, target, time, origin and result.

NIST's current incident-response guidance treats preparation, detection, response, recovery and improvement as parts of risk management rather than a help-desk episode after compromise. Applied to a small cloud provider, that means the panel, network, support desk and customer must share an incident model. Who detects suspicious account recovery? Who can isolate an instance without destroying evidence? Which logs survive if the tenant is reinstalled? When is the customer notified? How is a false alarm reversed?

The archived page also offered DDoS protection on some products or as an add-on. That wording does not reveal protected protocols, automatic thresholds, scrubbing location, clean-traffic capacity, null-routing policy, false-positive handling or customer controls. A buyer should ask for the exact protected path and a test procedure. The important outcome is not a nominal mitigation number but whether legitimate traffic remains usable, alerts arrive, support can explain the action and the service returns to normal without hidden configuration drift.

RPKI-valid routing is one positive control in this broader system. It helps authorise the prefix origin. It should sit beside prefix monitoring, route filters, change approval, access logging, incident communication and recovery. Treating the valid ROA as proof of overall security would ignore the far larger attack surface in accounts, panels, guests, storage, support and dependencies.

Backup claims become valuable only at restore time

The August page referred to monthly backups, backups and snapshots, and free technical support. These are attractive features because a low-cost host can become expensive the moment a customer must reconstruct a server. Yet “backup” is one of the least informative words in infrastructure purchasing unless the provider defines an entity, schedule, boundary and restore result.

Monthly may describe the provider's cadence, the included tier or a marketing summary. It does not say whether backups are application-consistent, encrypted, immutable, off-site, replicated across failure domains or retained after cancellation. A snapshot can preserve a corrupted filesystem or compromised credentials perfectly. A backup stored behind the same account and route can disappear with the service it is meant to rescue.

NIST's contingency-planning guidance connects recovery to business-impact analysis, preventive controls, strategies, documented plans, testing, training and maintenance. The practical translation is a recovery objective tied to a workload. The buyer should define how much data loss is tolerable, how long restoration may take, which dependencies must return first and who has authority to invoke the plan.

Haruzakura should be asked for the backup location, failure-domain separation, encryption and key ownership, retention, restore fee, expected restore time, deletion policy and evidence from recent tests. The customer should restore into an isolated environment and verify content, permissions, boot state, network configuration and application integrity. A successful job entry is not enough. Recovery ends when the service is usable and trusted.

Exit is the final recovery scenario. Can a customer export disk images, snapshots, databases, DNS data, firewall rules and audit history in documented formats? Is egress rate-limited or charged? How long does the provider retain copies after closure? Can it issue deletion confirmation? If addresses are provider-dependent, which configurations must change during migration? The non-portable IPv6 delegation makes this last question concrete: customers should assume that provider addresses do not move with them unless the contract and routing design explicitly say otherwise.

A small provider can answer these questions without publishing sensitive architecture. A concise service schedule, a sample restore result and a tested export are enough to turn a vague feature into evidence. Without them, the buyer should maintain an independent backup and rehearse migration from the first month.

Cheap compute can create expensive supervision

The old prices were striking: virtual hosting from RMB 2.40, VPS from RMB 15 and a UCloud-labelled light host from RMB 34. They are historical, not current quotations, but they reveal the likely commercial attraction. For hobby projects, temporary development environments and disposable services, low entry cost can justify a narrower evidence base.

The decision changes when the workload carries customer data, revenue, regulatory duties or hard recovery deadlines. The monthly fee then sits beside integration, migration, monitoring, security review, bilingual support, legal analysis, backup storage and staff time. A buyer may save on compute while paying engineers to verify every change, maintain an external status check, preserve independent backups and chase incidents through an undefined escalation path.

The best comparison unit is a supported workload, not a virtual machine. Price the instance, storage, traffic, addresses, protection, backup, restore, support tier, data export and expected customer labour. Add the cost of a second provider if the single visible route is not sufficient. Add the migration cost if the panel uses a proprietary image format. Add the risk reserve if service credits, notification duties and deletion terms are absent.

Small providers can still win this comparison. They may offer responsive local help, flexible configurations, less bureaucracy and prices that make experimentation possible. The evidence needed is proportionate. A staging server does not require the governance of a bank. But a buyer should state the acceptable failure mode in advance. If the service disappears for a day, if support is unreachable, if a snapshot fails or if the provider relationship ends, what work and data are at risk?

Haruzakura's public footprint does not support a measured claim about reliability, customer count or value. It supports a due-diligence hypothesis: there was a low-cost Chinese hosting offer; a later network identity remains visible; and the current commercial surface is difficult to inspect. The burden is therefore on a current seller to close the evidence gap before a buyer treats the historical price as a bargain.

A practical evidence test

The following questions convert the public gaps into an acceptance plan. They are deliberately specific enough to produce a document, configuration, demonstration or measured result.

Decision area What the public record shows Evidence to require before a critical workload
Contracting identity Chinese company name on an archived page; English brand in APNIC Current register extract, unified social credit code, invoice identity, brand authority and authorised signer
Product boundary Historical mix of VPS, virtual hosting, third-party-labelled light hosts and future physical servers Current catalogue naming infrastructure owner, panel provider, facility, subcontractors and responsibility for each layer
Network One visible RPKI-valid IPv6 /48, no originated IPv4 and one observed provider Current topology, address plan, IPv4 arrangement, route monitoring, failover test and owner for ROA and emergency changes
Availability No public uptime series or service-level schedule Component-specific objective, measurement source, maintenance treatment, exclusions, remedy and recent performance history
Location Administrative CN records plus historical Hong Kong, US, Germany and Chengdu labels Workload-level schedule for compute, storage, backup, logs, metadata, support access and subprocessors
Identity and access Historical console with powerful lifecycle actions MFA, role model, recovery checks, token policy, support-access controls, sensitive-action notices and sample audit events
DDoS and network security Historical protection language; valid route origin Protected path, thresholds, capacity basis, false-positive process, alerting, null-route policy and authorised test result
Backup and recovery Historical backup and snapshot claims RPO/RTO, retention, failure-domain separation, restore procedure, recent restore evidence and customer-run test
Support Historical 7*24, tickets, online service and one-to-one claims Severity matrix, staffed hours, response/restore targets, named escalation, out-of-band channel and exercise results
Incident handling Validated APNIC incident-response contact Customer notification clock, evidence preservation, role split, status communication and sample post-incident report
Exit No public export or deletion terms Formats, egress limits and fees, migration assistance, address renumbering plan, retention window and deletion confirmation
Financial exposure Historical low entry prices Full supported-workload quote, renewal terms, prepayment protection, refund conditions and cap on migration or recovery costs

This table is not a demand for public disclosure of every sensitive detail. Most proof can be shared under a confidentiality agreement or demonstrated in a trial. Nor should a buyer accept a folder of policies without testing the controls. A current legal document can still name the wrong service; an architecture diagram can omit the support channel; a backup report can record job success without a restore.

The strongest evaluation combines documents, observations and exercises. Resolve the service endpoints. Provision and delete a disposable tenant. Inspect the audit history. Open tickets at ordinary and difficult times. Restore a backup. Simulate loss of the primary administrator. Export a workload. Ask the provider to explain a route change and the visible dependency on AS139317. Evidence should agree across those activities.

Results should be scored against the workload's actual impact. A failure in a disposable test environment may be acceptable if the price and exit path are right. The same failure in an identity service or customer database is not. Procurement becomes more rational when it prices uncertainty instead of pretending it is absent.

The operating conclusion

Haruzakura Cloud has more substance than its thin present-day web surface suggests. The historical storefront tied the name to a Chinese commercial offer and a more formal Chinese company name. APNIC later tied the English name to an attributable organisation, ASN and IPv6 block. Public collectors show the route propagating widely, and RPKI shows that the origin is authorised. These are meaningful pieces of evidence.

They stop short of the assurance implied by a cloud purchase. The public route is IPv6-only at the observed origin, dependent on one visible provider and unconnected to a current public product endpoint. The old location, support, backup, DDoS and hardware statements have no corresponding public measurements or current contract. The later website capture is too contaminated by generic template material to support customer or usage claims. The current apex domain does not expose the ordinary web and inbound-mail routes a buyer would expect to use for validation.

That leaves a conditional verdict. Haruzakura could be suitable for a bounded, reversible workload if a current operator can prove the identity chain, demonstrate the service, explain the supplier layers, pass support and restore tests, and give the customer a clean exit. The visible ASN and valid ROA are positive inputs to that assessment. They are not substitutes for it.

For a critical workload, the evidence threshold should be higher. Require a current service and data-location schedule, explicit incident and support duties, tested recovery, independent monitoring, a route-dependency plan and export rights before migration. Keep an external backup and a path to another provider. Treat low price as one line in the model, not the conclusion.

The broader lesson is simple. A cloud name can refer at once to a brand, a seller, a legal entity, a control panel, a set of upstream products and an autonomous system. Operating assurance begins only when those roles are made visible and responsibility survives the handoff between them. Haruzakura's Chinese public record gives a buyer a credible place to start asking. It does not yet give permission to stop.