Summary
- APNIC records give Walks Cloud Inc. a dated resource identity around AS38856, 103.159.118.0/23 and 2406:d040::/32, while RIPEstat observed both prefixes announced on 20 July 2026. This is a strong public network-resource spine, but it is not an audit of applications, customer workloads, physical sites or available hosting stock.
- PeeringDB records an operational 10G STUIX attachment for AS38856 and describes an open-peering network profile. The port record is an exchange-edge fact, not a promise of 10G customer throughput, diverse transit, automatic failover or unused capacity.
- WalksCloud's own pages describe managed hosting, data-centre deployment, virtualization, monitoring, backup and security work. A buyer can use that operating surface to frame due diligence, but should still request dated evidence for facility roles, power and cooling, routes and upstreams, headroom, restore tests, migration windows and incident response.
The public record is a boundary map, not a capacity certificate
The most useful way to read WalksCloud's public footprint is to treat each source as evidence for a different layer. APNIC can establish that Internet number resources are registered under a particular identity. PeeringDB can describe how a network presents itself to the interconnection community and can record a connection at an exchange. RIPEstat can show that route collectors observed an autonomous system and prefixes at a particular time. WalksCloud's own site can describe the work it offers and the methods it says it uses.
None of those sources, alone or in combination, automatically measures the physical and operational conditions behind a customer's hosted workload.
That distinction matters because recognizable numbers create an impression of precision. An autonomous system number, two exact prefixes and a 10,000 Mbps exchange-port field look like a compact technical portrait. They are precise fields, but their meanings are bounded. The autonomous system number identifies a routing actor. A registered prefix identifies an address resource. A visible route shows that part of the global routing system saw an announcement. An exchange-port speed describes the nominal port recorded for an interconnection.
Those observations do not reveal how much traffic was flowing, which routes carried it, how much headroom remained, whether a customer service was healthy, or how a failure would be handled.
The public evidence therefore supports a narrower and more valuable conclusion than a broad claim about cloud scale. WalksCloud has a legible network edge around AS38856. That edge can be checked against independent resource and routing systems. Its official material also presents a managed-service scope that spans hosting operations, data-centre deployment, virtualization, monitoring, backup and security. A customer can use these facts to ask better questions about dependency. The facts do not settle those questions in advance.
This article follows that boundary rather than treating every technical record as interchangeable. It asks what is registered, what was visible, what was self-described, what was offered as a service, and what remains a customer-side verification task. The featured image follows the same discipline: it is an AI-generated realistic editorial reconstruction of a modest managed-hosting operations room, not documentary evidence of Walks Cloud Inc., WalksCloud, AS38856, STUIX, a real employee, a real rack, a disclosed facility, customer capacity or a tested redundancy design.
The result is not a score for WalksCloud. It is a method for reading a small hosted-service operator without inflating sparse but credible network facts into an unsupported account of its internal platform. That method is especially important when procurement decisions depend less on whether a network exists than on exactly where responsibility, capacity and recovery obligations sit.
APNIC establishes a dated resource identity
APNIC's RDAP record for AS38856 is the clearest starting point because it anchors the public network identity in registry data. The record names WalksCloud-AS, assigns the country code TW, marks the resource active, and gives a registration timestamp of 3 December 2020. It also records a last-changed timestamp of 22 May 2026. Its remarks connect the resource to Walks Cloud Inc. and a Taipei City registration context. These details make it reasonable to associate the company name, the WalksCloud brand context and AS38856 when discussing the registered network resources.
The related IPv4 and IPv6 records reinforce that identity. APNIC records 103.159.118.0/23 as WALKSCLOUD-NET, active, with country code TW. Its registration timestamp is 30 November 2020, and its last-changed timestamp is 22 May 2026. APNIC also records 2406:d040::/32 as WALKSCLOUD-NET, active, with the same country code. That IPv6 resource was registered on 30 November 2020 and last changed on 22 May 2026. Taken together, the autonomous system and address records form a coherent registered-resource set.
Registry coherence is useful in several practical ways. It gives a buyer or technical reviewer stable identifiers to place in an evidence request. It reduces ambiguity about which autonomous system and address blocks the public discussion concerns. It allows route observations to be compared with the registered resources instead of relying on brand names alone. It also supplies dates, which matter when someone is trying to distinguish a current record from an old marketing page or an undated diagram.
The limits are equally important. RDAP does not say that every address is in active customer use. It does not reveal the number of servers, virtual machines, racks or sites behind the addresses. It does not show whether the company owns, leases or merely manages any physical space. A Taipei contact context is not proof that a network operations centre, customer rack or data room is located at that address. Registration status is not a statement about power, cooling, hardware health, application availability, staffing or contractual performance.
The IPv4 and IPv6 records also answer a different question from route visibility. A resource can be registered without being visible in the global routing observations used by a particular measurement service. Conversely, a routing observation must be interpreted in light of its collection method and time window. The APNIC records establish entitlement and public identity at the registry layer; they do not by themselves establish that the routes were visible on 20 July 2026. That second claim requires routing evidence.
For due diligence, this means the APNIC layer should be preserved in its exact role. It is strong evidence when the question is, "Which resources are publicly registered, under what names, with what status and dates?" It is weak evidence when the question is, "How much service can this company deliver to us next month?" Moving from the first question to the second requires several additional layers, and none should be silently filled in by the apparent authority of a registry record.
RIPEstat shows two visible prefixes at a defined time
RIPEstat adds the observation layer that APNIC cannot supply. Its AS overview for AS38856 reported the holder as WalksCloud-AS, associated with Walks Cloud Inc., and returned announced=true for a query window on 20 July 2026. Its announced-prefixes result listed 103.159.118.0/23 and 2406:d040::/32, with timelines running from 6 July through 20 July 2026. The match between the observed prefixes and the two APNIC resource records strengthens the public picture: the registered IPv4 and IPv6 resources were not merely names on registry pages, but appeared in the routing observations represented by RIPEstat.
The date is essential. Route visibility is a changing condition, not a permanent property conferred by registration. Saying that the two prefixes were visible on 20 July 2026 is materially different from saying that they are always visible. The former is a dated observation. The latter would require continuous evidence that the cited material does not provide. A careful account therefore preserves the time boundary rather than converting a snapshot into an indefinite promise.
RIPEstat itself notes that very-low-visibility routes are excluded from the announced-prefixes result. That caveat prevents another common overreach. The returned set is useful for identifying the prefixes visible through the service's method, but it should not be treated as a complete map of every route, upstream relationship or special-purpose announcement associated with the network. It says even less about private addressing, internal segmentation, customer overlays or paths that are not represented in the public route collectors.
Most importantly, announced=true is not an application-health signal. A prefix may be visible while a website, virtual machine, storage service or customer application is impaired. The route observation does not test DNS resolution, TLS termination, server response, database availability, storage consistency, authentication, billing systems or support handling. It does not show that packets reached every intended destination with acceptable latency or loss. It does not reveal whether a customer workload was running in the address space at all.
The two-prefix result also should not be used as a proxy for scale. One IPv4 prefix and one IPv6 prefix can support many different operational designs. Address-block size does not disclose how addresses are allocated, how densely systems are deployed, or how much compute and storage sits behind them. The IPv6 /32 is a substantial addressing resource in numerical terms, but IPv6 address abundance is not evidence of physical inventory. The IPv4 /23 likewise says nothing by itself about occupied racks or sellable instances.
What RIPEstat does provide is a useful cross-check for the network edge. A customer can establish that the identifiers named in a proposal correspond to publicly visible routing resources at a stated date. That can become the first item in a broader review: ask for the intended customer prefixes and autonomous-system paths, compare them with current route observations, then request an architecture explanation for primary and failure states. The public route data begins that conversation. It cannot complete it.
The 10G STUIX attachment is an edge fact
PeeringDB's netixlan record supplies the most striking number in WalksCloud's public network profile. It records an operational STUIX attachment for AS38856 with a speed of 10000, an IPv4 exchange address of 103.158.187.24 and an IPv6 exchange address of 2a0f:5707:ffe3::24. The record says the connection uses the route server, reports no BFD support, and carries an update timestamp of 25 March 2026. Read accurately, this is evidence that the public interconnection profile includes a 10G exchange edge at STUIX.
The related PeeringDB exchange record describes STUIX as Student & Technology United Internet Exchanges in Taipei City, Taiwan, in the Asia Pacific region. It records Ethernet media, IPv6 and unicast support, and points to STUIX's public site and statistics service. Those details define the exchange context. They do not describe WalksCloud's internal switching, upstream transit, customer access, server estate or facility ownership.
A 10G port is useful evidence because it indicates the nominal interface speed recorded for the exchange attachment. It can support concrete technical questions. Is this connection used for production customer traffic, research traffic, route-server peering, direct bilateral peering, or some combination? What proportion of traffic can reach useful destinations through STUIX? What are the normal and peak utilization levels in each direction? What happens if the port, exchange fabric or path to the exchange fails? Which upstreams carry traffic that cannot use the exchange?
The record cannot answer those questions. A 10G interface can carry almost no traffic, can be heavily utilized at particular periods, or can serve only a subset of destinations. The exchange may improve local reachability without replacing paid transit. The nominal port rate may exceed the capacity of another link in the path. Internal routers, cross-connects, firewalls, server interfaces or remote-access circuits may impose different limits. Commercial policy can also determine which traffic is eligible to use the connection. Customer-usable throughput is an end-to-end property, not a field copied from one edge.
The lack of recorded BFD support should also remain a narrow fact. It does not prove that failure detection is poor, nor does it establish the absence of other liveness mechanisms. It is simply what the netixlan record reports for that attachment. A buyer concerned with convergence should ask how route failure is detected, what timers and monitoring apply, how the route-server session is handled, and how traffic moves when the exchange path is unavailable.
The correct procurement treatment is to turn the 10G record into a test prompt. Ask for dated utilization graphs at the relevant aggregation points, not only the exchange port. Ask for route and traffic examples showing what uses STUIX. Ask for a failure design that identifies the paths before, during and after an outage. If the proposed service includes a throughput commitment, connect that commitment to the narrowest bottleneck and to a measurement method. The public record makes these questions more specific. It does not answer them on WalksCloud's behalf.
PeeringDB describes a network profile, not a facility estate
PeeringDB's network record for AS38856 identifies the profile as Walks Cloud Internet Service, links it to the WalksCloud website, and lists the IRR AS-set AS-WC. It classifies the network as Network Services with an Asia Pacific scope, records IPv6 support, and describes an open peering policy with one exchange and no listed facilities. It also reports one IPv4 prefix, 100 IPv6 prefixes, a balanced traffic ratio and a traffic band of 20-100Mbps.
These are valuable interconnection descriptors, but PeeringDB is an ecosystem directory maintained through entity-supplied information. The fields are best read as the network's public interconnection presentation, not as independent measurements of its complete estate. The profile can help peers find policy, scope, addresses and exchange presence. It is not designed to serve as a financial audit, a facility inventory or a continuous traffic monitor.
The 20-100Mbps traffic band is particularly easy to misuse. It should not be described as a committed bandwidth, peak observation, billing rate, capacity ceiling or customer allocation. It is a broad profile band, and its relationship to the 10G port cannot be inferred without measured traffic data. A network may maintain a higher-speed interface for burst headroom, operational simplicity, exchange requirements or future use while reporting much lower aggregate traffic. It may also have traffic that does not traverse the exchange. The two figures belong to different fields and answer different questions.
The prefix counts require similar caution. The profile's "1 IPv4 prefix" aligns in a general way with the single visible IPv4 block in the cited RIPEstat result. The "100 IPv6 prefixes" field does not mean that RIPEstat should display 100 global IPv6 announcements, nor does it prove 100 customer networks. PeeringDB fields can reflect how the entity characterizes its routing footprint for interconnection purposes. The cited RIPEstat result observed one IPv6 /32. Without a more detailed route and addressing explanation, converting the profile number into a deployment count would be speculation.
The facility count of zero is a boundary, not a verdict. It means the PeeringDB profile does not list a facility for the network. It does not prove that WalksCloud has no equipment in any facility, because exchange access can be arranged through several technical and commercial models and profiles can be incomplete. At the same time, the zero count certainly cannot support a claim that WalksCloud owns or operates a data-centre footprint. The public profile offers no such proof.
For a hosted-service buyer, this gap should trigger a direct inventory request. Which legal entity contracts for each relevant data-centre space? Is WalksCloud the tenant, a remote operator, a reseller, a consultant or some combination? Which cages, racks or virtual environments support the proposed workload? Which physical and network components are under its direct control, and which depend on third parties? The PeeringDB record helps locate the edge of public knowledge. It should not be stretched to fill the unlisted facility layer.
Official service pages define an operating surface
WalksCloud's official English homepage presents the company as delivering management information system services across hardware, software and network operations. It places IT and MIS hosting, security management and device management among its top-level lines. This is the company's own description of what it seeks to do for customers. It is relevant to the hosted-service boundary because it suggests that the commercial offer is broader than raw virtual-machine rental or Internet transit.
The IDC Data Center Deployment and Maintenance page expands that scope. It says WalksCloud guides deployments from design and cabling through vendor coordination and remote operations, including planning around power, cooling, networking, security and compliance. The value of this page is not that it proves a particular facility arrangement. Rather, it shows the domains in which the company says it can coordinate work. A customer considering a deployment can use those domains as a responsibility map.
The Virtualization and Cloud Solutions page names Proxmox VE, Ceph, software-defined networking and hybrid network designs. It discusses GPU nodes, high availability, replication, backups, disaster-recovery practices and managed operations where needed. These terms indicate a technical service vocabulary and a set of design possibilities. They do not establish that spare GPU nodes exist today, that a particular Ceph cluster has a given fault tolerance, or that replication has succeeded under customer-relevant failure conditions.
The Website and Server Hosting Operations page describes end-to-end operation of application stacks, with hardening, automation, observability and incident response across cloud, colocation or on-premises workloads. That language is useful because it highlights a service that can span infrastructure the company does not own. It also reinforces why ownership cannot be inferred from operational responsibility. An operator can manage a workload in a customer's site, in leased colocation or on infrastructure supplied by another company.
The office-network service page belongs to the same official service corpus, but its presence should be read only as part of the company's stated scope. It does not verify the topology, equipment or performance of any specific customer network. Likewise, the cases index shows that WalksCloud publishes material about migrations, budget constraints, backup reporting, controller hosting, network design and data-centre relocation. These subjects suggest practical engagement with operational trade-offs.
The page titles and summaries are not independent customer attestations, and they should not be used to identify customers beyond what the public pages disclose.
Taken together, the official pages support a bounded statement: WalksCloud markets and explains a managed operating surface that includes infrastructure planning, hosting operations, virtualization, networks, monitoring, backup and security. They do not supply a current asset register. They do not show customer count, revenue, staffing levels, rack occupancy, spare storage, power allocation or measured recovery performance. The right way to use them is to translate service language into evidence requests, not to treat the language itself as proof that every capability is deployed and available for a new customer.
Service breadth can increase dependency before it reduces risk
A broad managed-service offer can be attractive because it reduces the number of interfaces a customer must coordinate. One team may be able to help with network design, server operation, virtualization, monitoring, backup and incident handling. That can simplify accountability in day-to-day work. It can also concentrate dependency if the same operator controls several layers and the customer has limited access to the underlying evidence.
The public material suggests that WalksCloud can work across cloud, colocation and on-premises environments. That flexibility makes it especially important to identify the actual delivery model for a proposed service. A customer should not assume that every engagement uses AS38856, the STUIX attachment or the two visible prefixes. Some workloads may use third-party cloud networks, a colocation carrier, a customer's own addresses or an on-premises circuit. The public network footprint establishes one capability around the company; it does not define every architecture sold under the brand.
Responsibility should therefore be decomposed by layer. At the physical layer, someone controls space, power, cooling, cabling and access. At the network layer, someone controls addressing, routing, transit, peering, switching, filtering and external circuits. At the compute and storage layer, someone owns or leases hardware and decides how spare capacity is reserved. At the virtualization layer, someone maintains clusters, images, replication and scheduling. At the application layer, someone handles releases, secrets, dependencies and observability.
At the service layer, someone receives incidents, communicates status and exercises recovery procedures.
WalksCloud may perform several of these roles, but the cited pages do not prove which roles apply to a specific contract. Nor do they show which functions are subcontracted, which depend on a facility operator, or which remain with the customer. A clear proposal should name the responsible party for each layer, identify any fourth-party dependency, and show the evidence available to the customer.
This matters economically as well as technically. A bundled service price can hide the cost of exit if system knowledge, credentials, backup formats, network addressing and vendor relationships are concentrated with one operator. Conversely, a well-documented managed service can lower operational cost if the customer receives usable records, tested runbooks, portable backups and clear transition assistance. The difference is not visible in an ASN record or a service-page claim.
The best due diligence therefore asks how service breadth is governed. Who can authorize a route change? Who holds facility access credentials? Who can restore data without the primary management plane? Can the customer export configurations and monitoring history? Are backup copies available outside the same failure domain? How are subcontractors disclosed? What happens to addresses, DNS, certificates and system documentation at termination? These questions convert a general managed-service promise into a dependency model a buyer can evaluate.
WalksCloud's monitoring method points toward better evidence
WalksCloud's official monitoring and Akvorado material is notable because it describes an analytical sequence rather than merely advertising visibility. The pages frame network observation as a progression: verify exporters and ingestion, inspect aggregate volume, divide top talkers by direction, source, destination, autonomous system and country, correlate the result with SNMP, Syslog and network-management alerts, then turn the findings into capacity or anomaly decisions.
That sequence offers the right conceptual answer to a tempting but flawed shortcut. A port speed cannot stand in for measured capacity. To understand whether a link has headroom, an operator first needs confidence that telemetry is complete. It then needs time-based volume data, directional analysis and a view of which sources and destinations drive load. Device counters and event logs help distinguish traffic growth from interface errors, routing changes or collection failures. Only after those checks can a team make a defensible capacity decision.
The published method does not disclose AS38856's current traffic. It does not show utilization on the STUIX attachment, transit links, server interfaces or customer circuits. It gives no percentile, sampling rate, retention period, packet-loss result or alert history for the network discussed here. It should therefore be cited as WalksCloud's stated observability practice, not as evidence that any particular link is lightly loaded or continuously monitored.
For a customer, however, the method provides a useful structure for requesting evidence. First, ask which interfaces and flow exporters cover the proposed service path. Second, ask how the operator detects missing or delayed telemetry. Third, request aggregate and directional utilization over a representative period, including peak events. Fourth, ask for top-talker analysis at a level that protects other customers while still showing concentration risk. Fifth, compare flow observations with interface counters, device health and incident logs. Finally, ask what capacity or routing changes resulted from the evidence.
That last step is often omitted. Monitoring is not equivalent to control. A dashboard may display congestion while no commercial or technical option exists to relieve it quickly. A mature capacity discussion should connect thresholds to decision rights, lead times, budget approval, port upgrades, transit orders and customer communication. It should also identify which measurements the customer can see directly and which are available only through periodic reports.
The monitoring pages therefore strengthen the article's evidence boundary in an unusual way. They do not prove capacity, but they describe why capacity should be measured rather than inferred. Applied rigorously, the same method would test the significance of the 10G STUIX record, the 20-100Mbps PeeringDB band and any contractual throughput figure. The public edge becomes a starting hypothesis; dated telemetry and change records determine what it means for a real service.
Physical capacity remains outside the cited public evidence
The largest unresolved area is the physical service substrate. The cited records do not identify a rack, cage, room or building used for a particular WalksCloud service. They do not state whether Walks Cloud Inc. owns hardware, leases space, resells another operator's capacity, manages customer-owned systems, or combines these models. The IDC deployment page describes work around power, cooling, cabling and vendor coordination, but service competence is not an inventory.
A buyer evaluating hosted infrastructure needs a more concrete description. At minimum, the operator should identify each site that can affect the service, the legal and operational role of each party there, and the assets assigned to the customer. If an address must remain confidential, the evidence can still name the facility operator, metropolitan area, failure domain and contractual role under appropriate disclosure terms. What matters is that the buyer can distinguish a primary site from an office, a management location, a remote-hands relationship or a backup destination.
Power claims should be similarly specific. A statement that a site has backup power is incomplete without the supported load, redundancy design, maintenance status, fuel arrangement, transfer sequence and evidence from recent tests. Cooling requires information about design limits, monitoring and failure response. Rack capacity requires an inventory showing occupied and reserved units, power density, network ports and lead times. None of those conditions can be inferred from an active ASN or an exchange connection.
The same applies to compute and storage. The virtualization page discusses GPU nodes, high availability, Ceph, replication and backup, but the public sources do not show spare nodes, usable storage, replication health or failure-domain placement. A customer should ask which resources are dedicated, reserved or shared; what happens under host failure; how much capacity remains after applying redundancy; and how quickly replacement hardware can be obtained. Advertised technical options do not establish current stock.
Site diversity is another unproven area. The public record cited here does not demonstrate multiple independent sites. Even two named locations would not automatically create resilience if they share power, carriers, management systems, staff, upstream contracts or a common control plane. A claim of geographic redundancy should be accompanied by a dependency diagram and a test showing that the secondary environment can carry the intended service without relying on the failed primary component.
These requests are not accusations. They are normal ways to align a hosted-service promise with the physical conditions required to deliver it. WalksCloud's public pages demonstrate awareness of the relevant domains, but public service descriptions are necessarily general. The procurement task is to move from that general operating surface to a dated, customer-specific bill of materials and responsibility map.
Network diversity cannot be inferred from exchange presence
STUIX provides evidence of one exchange attachment, while the PeeringDB profile reports one exchange and no listed facilities. Those fields do not reveal the full set of upstream transit relationships or physical paths serving AS38856. RIPEstat's two visible prefixes likewise do not identify every upstream, because the cited results are about announcement state and prefix visibility rather than a complete path analysis.
This gap matters because an Internet exchange and an upstream transit service solve different reachability problems. An exchange can provide direct or route-server-mediated paths to participating networks. Transit generally supplies broader reachability, including destinations not available through local peering. A hosted service may use both. The resilience of the result depends on route policy, physical circuits, routers, cross-connects, upstream concentration and operational response, not merely on the existence of an exchange port.
A buyer should request a path inventory for the proposed service. It should identify the relevant customer-facing access, edge routers, exchange links, transit circuits and any overlay or security service in the path. For each component, the operator should state the physical endpoint, commercial supplier, capacity, normal role and failure role. Two circuits bought from different brands may share the same duct, building entrance, remote device or wholesale carrier. Diversity should be proven at the failure-domain level.
Routing policy deserves equal attention. The PeeringDB profile lists AS-WC and an open peering policy, but those fields do not show local preference, route filters, communities, maximum-prefix settings or failover behavior. The netixlan record says the STUIX attachment is a route-server peer. A customer does not need every confidential policy detail, but it should understand which classes of destination normally use the exchange, what alternate path exists, and what operational event causes a change.
IPv4 and IPv6 should be tested separately. The public record shows both 103.159.118.0/23 and 2406:d040::/32 visible, and the STUIX record includes addresses for both protocols. That is positive evidence of dual-stack representation at the public edge. It does not prove equivalent performance, filtering, monitoring or failure behavior. A service sold as dual stack should have protocol-specific reachability and recovery evidence.
Finally, network diversity must be tied to customer outcomes. A second upstream does little for a workload that depends on one firewall, one switch, one DNS configuration or one storage system. Conversely, a modest public routing footprint can support a well-designed service if dependencies are explicit and tested. The available evidence cannot decide which description fits WalksCloud. It can only show why the decision requires more than counting ports and prefixes.
Backup and recovery claims need observed outcomes
WalksCloud's official backup, security and virtualization pages discuss tools and practices that include Proxmox Backup Server, Proxmox Mail Gateway, Wazuh, replication, backups and disaster-recovery work. These references establish a service vocabulary and indicate that the company addresses backup and security operations in its public offer. They do not establish a recovery point objective, recovery time objective or successful restore for any particular customer.
The difference between configured backup and recoverable service is fundamental. A backup job can report success while omitting data, preserving corruption, lacking necessary keys or depending on a management system that is unavailable during an incident. Replication can copy deletion or encryption damage to another location. A secondary environment can exist but lack enough compute, current network policy or application dependencies to take over. Tool names do not resolve these risks.
A buyer should begin with scope. Which data, configurations, virtual machines, secrets, logs and external dependencies are included? Which are excluded? How often is each item protected, and how is completion verified? Where are copies stored, under whose account, and in which failure domain? Are any copies immutable or administratively separated from the primary environment? What retention and deletion rules apply?
The next step is restore evidence. A dated test should identify the selected recovery point, the data volume, the environment into which it was restored, the start and completion times, validation checks, observed failures and remediation. Application owners should participate, because infrastructure-level restoration does not prove that a service is functionally correct. If a contract includes an RPO or RTO, the test should measure against the same definition used in the agreement.
Disaster recovery requires an even wider exercise. It should account for routing, DNS, certificates, identity systems, storage consistency, configuration state, staff access, vendor escalation and customer communication. The cited public pages do not show that WalksCloud has completed such an exercise for a customer-ready environment, so this article makes no claim that disaster recovery is proven. The proper conclusion is that the official service scope gives customers a basis for asking how these controls are implemented and tested.
Security outcomes need the same restraint. The presence of hardening, monitoring or named security tools in a service description is not proof that no incident occurred or that every system is correctly configured. A buyer should ask about control ownership, patch timing, alert coverage, privileged access, evidence retention, incident severity definitions and notification obligations. Independent assurance, where appropriate, should match the actual service boundary rather than a broader corporate statement.
The public cases material around backup reporting and operational constraints may help illustrate the kinds of problems WalksCloud discusses. It should not be converted into undisclosed customer evidence. For procurement, only dated, relevant and permissioned evidence can demonstrate that the proposed recovery design works at the required scale.
Hosted-service dependency is a chain of separate proofs
The network-resource spine is strong because several public records align. APNIC connects AS38856, WalksCloud-AS, Walks Cloud Inc., 103.159.118.0/23 and 2406:d040::/32. RIPEstat observed the autonomous system announced and the two prefixes visible on 20 July 2026. PeeringDB records an operational 10G STUIX attachment and a recognizable interconnection profile. This consistency supports confidence that the public network identity is real and currently legible.
Hosted-service dependency begins where that confidence stops. A customer depends not just on the existence of an edge, but on a sequence that may include facility access, power, cooling, hardware, storage, hypervisors, switching, routing, upstreams, DNS, security controls, monitoring, staff procedures and external suppliers. The service works only when the required parts work together. Evidence for one part cannot silently certify the others.
That is why source types should remain separate in a review. Registry records answer identity and resource-allocation questions. PeeringDB answers questions about public interconnection presentation. RIPEstat answers dated route-observation questions. Official service pages answer what the company says it offers. Monitoring method pages answer how it says traffic and alerts should be analyzed. Customer-specific documents and tests must answer capacity, architecture, recovery and accountability questions.
Collapsing these layers creates two opposite errors. The first is overconfidence: a buyer sees a 10G port and assumes abundant hosted capacity, or sees a disaster-recovery service description and assumes tested failover. The second is needless dismissal: a reviewer sees a small public routing footprint and assumes the operator cannot deliver a useful managed service. Neither conclusion follows from the cited evidence. Small operators can be capable and well controlled; large public footprints can still hide weak customer-specific designs.
A proportionate assessment asks whether the proof matches the risk. A low-impact managed website may require basic architecture, backup and support evidence. A critical application with strict recovery targets needs detailed facility, network, capacity, security and exercise records. The public evidence can help determine where to begin, but the customer's workload determines how far verification must go.
This approach also clarifies what should be refreshed over time. Resource registration changes slowly. Route visibility and utilization can change quickly. Hardware headroom may change with each sale or failure. Backup success is only as current as the latest valid job and restore test. Incident readiness decays if staff, suppliers or systems change. A due-diligence package should therefore attach dates and refresh intervals to each claim instead of presenting one undifferentiated statement of capability.
A practical buyer verification sequence
A disciplined buyer can turn the public record into a staged evidence request without demanding unnecessary disclosure. The first stage is identity. Confirm that the contracting entity is Walks Cloud Inc., identify any subcontracting entity, and map the proposal's autonomous system, prefixes, domains and service endpoints. If AS38856, 103.159.118.0/23 or 2406:d040::/32 are relevant, the proposal should say how. If they are not, the proposal should identify the actual network dependencies instead of leaning on the public footprint.
The second stage is architecture. Request a current diagram that separates physical sites, facilities, network edges, upstreams, exchange paths, compute clusters, storage, management systems and external services. Each component should have an owner and an operational role. The diagram should show both normal traffic and failure paths. It should distinguish customer-dedicated resources from shared resources and identify where capacity is reserved rather than merely available on request.
The third stage is measured capacity. Ask for dated utilization at every plausible bottleneck, including customer access, firewalls, routers, exchange and transit links, hypervisors, storage and backup systems. The WalksCloud monitoring method suggests a useful standard: verify collection, inspect aggregate volume, break down major contributors, correlate with device and event data, then explain the resulting decision. Capacity evidence should include peaks, trends, headroom policy and upgrade lead times.
The fourth stage is resilience. Request the relevant circuit and facility failure domains, routing behavior, power and cooling design, hardware replacement process, backup separation and recovery procedures. Do not accept a component count as proof of independence. Two links, two servers or two sites are useful only if a credible failure cannot disable both and if the service can operate on the surviving resources.
The fifth stage is testing. Select failures that reflect the promised service: loss of the STUIX path, loss of an upstream, host failure, storage-node failure, backup restoration, loss of management access or unavailability of a primary site. Record what was tested, when, with what load, what succeeded, what failed and what changed afterward. A tabletop discussion is useful for roles and communications, but it should not be confused with a technical failover or restore.
The sixth stage is operations and exit. Define support hours, severity levels, notification timing, escalation, maintenance, change approval, customer access to telemetry and evidence retention. Then establish how configurations, data, backups, addresses, credentials and documentation can be transferred. Managed hosting is safest when the customer can verify service while it is running and can leave without reconstructing the environment from memory.
None of these requests assumes that WalksCloud lacks the relevant capability. They reflect what the public sources cannot establish. A responsive answer may be a document, a live demonstration, a redacted contract, an independent report or a customer-specific test. The form can vary. The essential requirement is that the evidence be dated, scoped to the proposed service and clear about who controls each dependency.
Reading the economics behind the technical boundary
The hosted-service boundary also shapes price. A 10G exchange port may be inexpensive or costly relative to the rest of the service, but the port rate alone says little about the economics of delivering a customer workload. Transit, cross-connects, rack space, power, remote hands, hardware depreciation, software support, backup storage, monitoring and staff time can dominate. A buyer who treats the edge speed as the product risks comparing unlike offers.
Shared infrastructure can lower cost by spreading fixed resources across customers, yet it introduces allocation questions. How is CPU, memory, storage performance, Internet capacity and support attention divided under peak load? Is headroom a contractual reserve, an internal target or simply today's unused amount? What happens when a new customer arrives? Public routing records cannot answer these questions, and official service breadth does not quantify them.
Small-scale operations can have advantages. A compact team may provide direct technical access and tailor systems closely to a customer's needs. It may also have concentration risk if expertise, credentials or supplier relationships depend on a few people. The cited sources do not disclose staffing or customer concentration, so neither strength nor weakness should be assumed. A buyer can ask for on-call coverage, escalation depth, documentation practices and contingency arrangements without demanding personal details.
Upgrade lead time is another economic variable. A nominal 10G exchange connection may offer ample edge headroom while storage, compute, transit or facility power takes weeks to expand. Conversely, cloud or colocation arrangements may allow some resources to scale quickly but expose the customer to supplier pricing and account dependency. A credible proposal should state which components can be expanded, by how much, at what notice and under whose commercial agreement.
Recovery promises also carry cost. Off-site copies, immutable retention, spare hardware, duplicate circuits and regular exercises require resources. A low price may reflect an intentionally narrower recovery scope rather than poor execution, while a higher price does not prove that controls exist. The buyer should connect each charge to a defined capability and evidence item.
This is where WalksCloud's public emphasis on operational work can become useful. The service pages frame value around design, coordination, observability, hardening and incident response, not only raw infrastructure. To evaluate that value, a customer should ask what recurring outputs it receives: capacity reviews, change records, backup reports, restore evidence, incident analyses and updated diagrams. Those artifacts make managed operations visible and reduce dependence on assertions. They also make price comparison more meaningful because the buyer can see which operational obligations are included.
The bounded conclusion
The public record supports a clear but deliberately limited reading of WalksCloud. APNIC records AS38856 under the WalksCloud-AS identity and records two active WALKSCLOUD-NET resources, 103.159.118.0/23 and 2406:d040::/32. RIPEstat observed the autonomous system announced and those two prefixes visible on 20 July 2026. PeeringDB records an operational 10G STUIX attachment, dual-stack exchange addresses and an open-peering network profile. These are credible, dated facts about the public network edge.
They are not a physical-capacity audit. The 10G field does not guarantee 10G of customer-usable throughput. The 20-100Mbps profile band is not a commitment, peak or ceiling. Two visible prefixes do not prove application health. An active resource does not prove spare servers or storage. One exchange connection does not establish diverse transit. A facility count of zero in PeeringDB neither proves the absence of equipment nor supplies evidence of a facility estate.
WalksCloud's official pages add a second layer. They describe managed hosting, IDC deployment, virtualization and cloud work, office networking, monitoring, backup, security and operational response. The Akvorado and monitoring material articulates a sensible progression from verified telemetry to traffic analysis and capacity decisions. The cases index shows that the company publishes around practical migrations, backup reporting, network design and operational constraints. This material establishes what WalksCloud says it works on and how it frames some operational problems.
It still does not verify customer-ready rack stock, power and cooling state, spare compute, GPU availability, carrier diversity, generator runtime, multiple independent sites, restore performance, RPO, RTO or a successful disaster-recovery exercise. Those are customer-specific claims that require dated customer-specific evidence. The same is true of support response, incident outcomes and workload performance.
The appropriate buyer response is neither to dismiss the network footprint nor to inflate it. Use the registered resources to establish identity. Use the route observations to confirm dated visibility. Use the STUIX record to ask how the exchange edge participates in normal and failure traffic. Use the service pages to map responsibilities. Use the published monitoring method as a standard for requesting measured capacity. Then ask for physical inventory, path diversity, utilization, restore tests, migration plans and incident procedures at the scope and date relevant to the proposed service.
That evidence-layer discipline is the central finding. WalksCloud's public records are strongest when they are allowed to remain what they are: a legible network-resource spine and a stated managed-operations surface. Their value is reduced, not increased, when they are made to carry claims about facilities, capacity or recovery that they were never designed to prove.
Sources
- APNIC RDAP, AS38856 - https://rdap.apnic.net/autnum/38856
- APNIC RDAP, 103.159.118.0/23 - https://rdap.apnic.net/ip/103.159.118.0/23
- APNIC RDAP, 2406:d040::/32 - https://rdap.apnic.net/ip/2406:d040::/32
- RIPEstat, announced prefixes for AS38856 - https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS38856
- RIPEstat, AS38856 overview - https://stat.ripe.net/data/as-overview/data.json?resource=AS38856
- WalksCloud, English homepage - https://walks.cloud/en/
- WalksCloud, cases - https://walks.cloud/en/cases/
- WalksCloud, backup and security - https://walks.cloud/en/services/backup-security/
- WalksCloud, hosting operations - https://walks.cloud/en/services/hosting-operations/
- WalksCloud, IDC deployment - https://walks.cloud/en/services/idc-deployment/
- WalksCloud, IT monitoring - https://walks.cloud/en/services/it-monitoring/
- WalksCloud, office network - https://walks.cloud/en/services/office-network/
- WalksCloud, virtualization and cloud - https://walks.cloud/en/services/virtualization-cloud/
- WalksCloud, Akvorado flow collector overview - https://walks.cloud/en/tech/akvorado-flow-collector-overview/
- WalksCloud, Akvorado traffic analysis workflow - https://walks.cloud/en/tech/akvorado-traffic-analysis-workflow/
- PeeringDB, STUIX exchange record - https://www.peeringdb.com/api/ix/3352
- PeeringDB, AS38856 network record - https://www.peeringdb.com/api/net?asn=38856
- PeeringDB, AS38856 netixlan record - https://www.peeringdb.com/api/netixlan?asn=38856