Summary

  • Data Cloud LLC is visible in RIPE records as the holder of AS48107, with the holder label DATACLOUD-AS Data Cloud LLC and a contact address at China-Belarus Great Stone Industrial Park in the Minsk region. That supports a Belarus operating identity, but it does not prove how many racks, servers, customers or recovery sites sit behind the name.
  • RIPEstat showed AS48107 as announced on 2026-07-11, with one current visible IPv4 prefix, 80.71.147.0/24, no current IPv6 announced space, and 327 of 327 IPv4 RIS full-feed peers seeing the origin at the query time. The public edge is live, but it is small.
  • The current public neighbor observation showed one adjacent ASN, AS56740 DataHata Ltd. The RIPE aut-num object also lists policy entries for AS56740, AS21305 IP TelCom LLC, AS42772 A1, and AS12406 Business Network Ltd. Those records show possible routing counterparties or intended policy, not a verified active multi-carrier failover design.
  • The route-origin validation result for 80.71.147.0/24 and AS48107 was unknown, with no validating ROAs returned. That is not proof of hijack or misuse, but it means customers should treat route-origin assurance as an open operational question.
  • The evidence grade is Medium. Public records prove a real AS, a current /24 route and a Belarus location signal. They do not prove customer-facing capacity depth, facility redundancy, spare-hardware stock, contractual support response, data-portability rights or a tested disaster-recovery path.

The visible edge is small, and that is the point

Data Cloud LLC is a useful infrastructure subject because the public evidence is neither empty nor complete. The company is attached to a live autonomous system, AS48107, and that means the market does not have to start from a blank name. The RIPE RDAP aut-num record identifies AS48107 as DATACLOUD-AS, names Data Cloud LLC in the organization and role records, and gives a Belarus address at China-Belarus Great Stone Industrial Park, Smolevichskiy District, Minsk Region. The RIPEstat AS overview also labels the holder as DATACLOUD-AS Data Cloud LLC and showed the AS as announced at the 2026-07-11 query time.

That is enough to establish a real network-resource footprint. It is not enough to establish the service a customer thinks it is buying. Hosted capacity becomes valuable only after the resource layer is tied to facility access, hardware inventory, transit, power, support labour and an exit plan. A route can remain globally visible while the customer-facing service behind it is small, under-documented or dependent on a single repair chain. A company can also operate a legitimate small network without publishing the kind of detail that would let an outsider verify recoverable capacity.

The current route state is narrow. RIPEstat's routing-status view reported one IPv4 prefix, 256 IPv4 addresses, no IPv6 prefixes, and one observed neighbor. The announced-prefixes view showed only 80.71.147.0/24 in the two-week window ending 2026-07-11. That small public edge is not automatically a weakness; many specialized service providers operate with compact address space. But it changes the buyer's diligence. A small routed footprint leaves little margin for assumption. The buyer should not infer multiple data halls, multi-region cloud capacity or deep hardware stock from the existence of one /24.

The important question is therefore not whether Data Cloud LLC appears in public Internet records. It does. The question is what that reachable edge can carry, how it is repaired, and how customers leave or fail over if the single visible public layer is not enough.

Great Stone is a location signal, not a full facility audit

The address in RIPE RDAP matters because it locates Data Cloud LLC's registered network contact in a specific Belarus industrial-park context rather than leaving the company as a loose Internet label. The RDAP organization and role entries put Data Cloud LLC at China-Belarus Great Stone Industrial Park, Smolevichskiy District, Minsk Region, postal code 222210. That location signal is more specific than a country code. It suggests the company is not merely a routing alias; it is connected to a physical investment zone where data, logistics, manufacturing and cross-border services are marketed as part of a business environment.

But a postal or role address is not a rack audit. It does not disclose whether the servers carrying customer workloads sit in a building inside the park, in a nearby Minsk data hall, in a third-party Belarus colocation room, or behind a leased arrangement with another operator. It does not disclose the number of cabinets, the power density per rack, the generator runtime, the cooling topology, the cross-connect count or the remote-hands contract. It also does not tell customers whether Data Cloud LLC owns the infrastructure, leases it, subcontracts it, or combines several arrangements.

That distinction is central to hosted-service risk. A provider can invoice for cloud, VPS, bare-metal or managed capacity while relying on a chain of facility landlords, IP lessors, transit providers, equipment suppliers and support contractors. If the chain is well managed, customers may never see it. If one link fails, the customer discovers the physical service boundary during the incident.

The Great Stone address should therefore be read as a starting point for diligence. It tells the customer where to ask about facility access and jurisdiction. It does not settle the questions that decide recoverability: how many buildings are active, whether those buildings are independent, which power domains feed the racks, who can enter after hours, which carriers terminate there, how spares are stored, and whether backup or migration capacity is already installed or only promised.

For Data Cloud LLC, the public address gives the article a concrete physical anchor. It does not justify language that would imply a verified, owned, resilient data-centre estate. The current public evidence is strongest when it is kept modest: Belarus location signal, live AS, one routed /24, limited public interconnection detail.

AS48107 shows present reachability, not broad cloud depth

RIPEstat is useful here because it separates identity from route visibility. The AS overview ties AS48107 to Data Cloud LLC. The routing-status endpoint describes what collectors could see at the query time. On 2026-07-11, that meant 80.71.147.0/24 was the last-seen route, 327 of 327 IPv4 RIS full-feed peers saw the origin, and there was no IPv6 visibility in the same view.

The positive reading is straightforward: AS48107 was not a dead administrative shell at that moment. The current /24 was visible to the full IPv4 peer set used in the RIPEstat response. The prefix overview for 80.71.147.0/24 also showed the prefix as announced and associated the origin with AS48107, holder DATACLOUD-AS Data Cloud LLC.

The limiting reading is just as important. One /24 is a narrow public edge. It can support management endpoints, customer services, small hosted workloads, NAT pools, control systems or a limited public-facing estate. It cannot, by itself, prove a sizable public cloud platform. It does not show the number of servers. It does not show storage architecture. It does not show backup capacity. It does not show whether customers are multi-tenant, dedicated, colocated, managed, or simply using network services adjacent to a larger provider.

That is why the phrase "hosted capacity" has to be tested at the layer below the invoice. If a customer buys virtual machines, the questions are about hypervisor count, storage replication and recovery. If a customer buys dedicated servers, the questions are about hardware stock, replacement timing and reinstall paths. If a customer buys managed service, the questions are about staff coverage, credentials, change control and support escalation. AS48107 can prove there is a public routing surface. It cannot answer those capacity questions alone.

The most useful conclusion is neither promotional nor dismissive. Data Cloud LLC has a live public edge. The edge is compact enough that a buyer should ask for exact service maps and failure tests before treating the company as a resilient cloud substitute.

The address block points to leased or upstream resource economics

The routed prefix adds another layer of dependency. The RIPEstat whois view for 80.71.147.0/24 identifies the inetnum as AE-IX-20210923, country BY, status ALLOCATED PA, with organization ORG-IF47-RIPE. The RIPE RDAP prefix record shows that organization as IPX - FZCO, with an address in Dubai, and shows the administrative and technical contact as IPX. The same RIPEstat whois response includes route objects for 80.71.147.0/24 with origin AS48107, created on 2021-09-24 and maintained by IP-RIPE.

That structure matters because Data Cloud LLC's public service edge appears to depend on number resources whose registry organization is not Data Cloud LLC itself. There is nothing unusual about provider-aggregated or leased address space in hosting. Smaller infrastructure companies often use address resources from sponsors, upstreams or specialist lessors. The economic issue is that dependency becomes part of the service promise. If the address arrangement changes, customers may need renumbering, DNS changes, firewall updates, reputation repair or traffic migration.

This is not a claim that the arrangement is unstable. The route history suggests the current prefix has been visible for years. It is a claim that customers should identify the contractual boundary. Who controls the address lease or assignment? What happens if the sponsor changes policy? Can Data Cloud LLC keep the same addresses if it changes transit providers? Are customer IP assignments portable, or are they tied to the provider's current resource contract? How much notice is required before renumbering?

The prefix-routing-consistency endpoint showed the route as both in BGP and in whois, with origin 48107 and RIPE as the IRR source. That is a good consistency signal for the current route. It is not a substitute for a customer portability clause. Routing consistency says the public route and registry route object agree. It does not say the customer can move workloads without outage, keep IP addresses after termination, or obtain reputation history if a spam or abuse incident affects a shared block.

For hosted capacity, address-resource economics are part of the physical dependency chain. Data Cloud LLC's customers should treat the /24 not as an abstract number but as scarce infrastructure attached to contracts and operational rights.

RPKI is an unresolved control, not a fatal flaw

Route-origin validation is a narrow but useful resilience check. It asks whether a Route Origin Authorization allows a specific AS to originate a specific prefix. For Data Cloud LLC's current visible prefix, RIPEstat's RPKI validation endpoint returned status unknown and no validating ROAs for 80.71.147.0/24 originated by AS48107. That result should not be sensationalized. It does not mean the route is hijacked, invalid or unauthorized under the legacy IRR system. It means the stronger cryptographic origin signal was not present in that query.

For a customer, the practical implication is simple. If a network or upstream enforces Route Origin Validation strictly, an invalid route can be dropped and an unknown route may be treated according to local policy. Unknown is better than invalid in many operational policies, but it is not as reassuring as valid. For a hosted provider whose public edge is one current /24, route-origin assurance becomes more visible because there are fewer other public prefixes to absorb a control-plane mistake.

The broader technical context is explained in RFC 6811, which describes BGP prefix origin validation, and in RIR material such as ARIN's RPKI page and APNIC's resource-certification page. Those sources are not Data Cloud LLC evidence; they explain why an unknown validation state belongs in the risk discussion.

The diligence request should be concrete. Does the holder of the 80.71.147.0/24 resource support ROA publication for AS48107? If not, why not? If yes, why was the public validation view unknown at the query time? Is there a planned RPKI change window? Who can authorize it, the address-resource holder, sponsor, upstream or Data Cloud LLC? How are customers notified if a route-origin change might affect reachability?

RPKI does not solve power, hardware, storage or support problems. It is one guardrail around route hijack and mistaken origin announcements. But for a small public edge, missing origin-validation proof should not be treated as a detail to clean up later. It is part of the same recoverability story as transit diversity and migration rights.

The upstream picture is broader on paper than in current observation

Data Cloud LLC's aut-num policy object is more expansive than the current neighbor view. The RIPEstat whois record for AS48107 lists import and export entries for AS56740, AS21305, AS42772 and AS12406. RIPEstat's AS overview identifies those ASNs as DataHata Ltd, IP TelCom LLC, A1, and Business Network Ltd. On paper, that looks like several Belarus or regional network counterparties.

The current observation is narrower. RIPEstat's ASN-neighbours endpoint reported one unique neighbor, AS56740, at the latest available query time. That does not mean the other policy entries are false. They may reflect inactive sessions, backup arrangements, private policy, old plans, filters that were not visible to RIPE collectors, or sessions that do not appear as current adjacent paths. It does mean customers should not equate a policy object with active, tested, capacity-bearing transit diversity.

The distinction is a classic hosted-service trap. A provider can list multiple upstreams in registry policy and still have one effective default path at the moment a customer cares. It can have multiple contracts but insufficient commit, cross-connect or router headroom after a failure. It can have a backup that exists in configuration but is not tested with production traffic. It can also have private or provider-facing arrangements that public collectors do not reveal. The public record is a clue, not a failover certificate.

The buyer's questions should use both records. Ask Data Cloud LLC which of the four named counterparties currently carry production traffic, which are standby, which are historical, and which can carry the full customer load during an incident. Ask whether the paths terminate in separate rooms, buildings and power domains. Ask for a recent maintenance or failover test summary, not only a list of ASNs. Ask whether routing communities, local preference, DDoS filtering or blackhole handling depend on one upstream's tooling.

The public evidence supports a conservative conclusion: Data Cloud LLC has a live route and at least one currently visible upstream relationship, with additional policy names that require verification before they can be treated as resilience.

PeeringDB absence leaves interconnection economics mostly dark

PeeringDB is not mandatory for an operator, but its absence or emptiness changes what outsiders can infer. A query to PeeringDB's API for ASN 48107 returned no network object at the research cut-off. A PeeringDB search for AS48107 is therefore useful mainly as a negative or limited signal. It means there was no public PeeringDB profile to disclose exchange attachments, facility entries, peering policy, traffic levels, prefix counts or contact roles.

That is not a criticism by itself. Many networks, especially smaller or primarily transit-served operators, do not maintain a PeeringDB profile. PeeringDB is voluntary and self-maintained. The absence of a profile does not prove there is no facility, no exchange, no private interconnect and no customer service.

It does, however, remove one common source of interconnection evidence. If a provider lists exchange points and facilities, a buyer can ask whether those sites host production routers, whether exchange sessions are default-capable, and whether the facility list matches customer data placement. Without that profile, the diligence burden shifts to direct disclosure. Data Cloud LLC customers need to ask for a route and facility summary rather than assuming one can be reconstructed from public interconnection directories.

The missing profile also has an economics angle. Peering and direct interconnection can reduce transit cost and improve performance to selected networks, but they require operational discipline: route filters, max-prefix limits, monitoring, NOC contact hygiene, and facility or exchange fees. A transit-only model may be simpler and perfectly adequate for a small hosted estate. It can also concentrate bargaining power in upstream contracts and leave customers more exposed to price changes, congestion or DDoS-handling policy.

Public routing records do not settle which model Data Cloud LLC uses. The only current visible neighbor in RIPEstat was AS56740; the aut-num object lists other possible counterparties; PeeringDB does not add exchange or facility detail. That combination calls for direct evidence before a customer treats the service as multi-homed in the operational sense.

Route history shows continuity, but not unchanged service

Data Cloud LLC's routing history has depth. The RIPEstat routing-history endpoint showed 80.71.147.0/24 visible from 2021-09-30 through 2026-07-11 in the summarized query. It also showed an older prefix, 93.91.164.0/24, visible from 2008-12-19 through 2020-12-15. The routing-status endpoint reported the first seen route as 93.91.164.0/24 in December 2008 and the last seen route as 80.71.147.0/24 in July 2026.

History matters because it argues against treating AS48107 as a fresh one-day test. The current /24 has a multi-year public route record. That supports operational continuity at the routing layer. It also gives buyers a way to ask better questions: what changed around the move from the older 93.91.164.0/24 history to the current 80.71.147.0/24 path? Was it a resource migration, provider change, service change, corporate change or simply the visible route collector history of different blocks?

But historical routing should not be overread. A route timeline does not show customer counts. It does not show whether servers were active throughout the period. It does not show whether a data-centre project expanded, paused, relocated or changed suppliers. It does not show the quality of incident response. It does not show how many workloads could be restored if the current prefix, upstream or facility were disrupted.

The key risk is a buyer purchasing continuity by implication. A long route history can become a trust shortcut: if the AS has been seen for years, surely the service is mature. That may be true, but the public record proves only that collectors observed origins over time. For customer dependency, continuity has to be demonstrated in operational terms: backup tests, maintenance notices, support history, service-level commitments, data-export procedures and evidence that a failure of the current edge does not strand the workload.

Data Cloud LLC's route history is a positive signal. It should support, not replace, a direct service review.

Installed capacity and usable capacity are different numbers

The economics of a small hosted provider are built around conversion. The provider converts racks, servers, transit, electricity, addresses, vendor credit and support hours into a monthly service. The customer sees a price and an interface; the provider manages the input costs. The risk is that the customer's "capacity" may be installed in one sense but not usable in the failure scenario that matters.

For Data Cloud LLC, the visible public capacity is a /24. That tells us almost nothing about the private inventory underneath. The same public route could serve a small number of high-value managed customers, a control plane, a virtual-hosting platform, dedicated servers, VPN endpoints, test workloads, or a mixed environment. The address count is not a server count. The AS path is not a storage diagram. The Great Stone address is not a power single-line diagram.

Usable capacity asks a different question. If one top-of-rack switch fails, can customer services move? If the upstream AS56740 path is degraded, does traffic shift to another path automatically and at sufficient bandwidth? If a server motherboard fails, is there a spare on site? If the facility has a power event, are customer workloads duplicated elsewhere or merely backed up? If the support portal depends on the same infrastructure, how are customers contacted during the incident?

This is why hosted-service due diligence should be written as test cases, not slogans. "Redundant" should mean which components are redundant and under what measured load. "Backup" should mean the restore target, the last tested date, the restore time and the failure modes excluded. "Local hosting" should mean where primary data, backup data and support access actually reside. "Cloud" should mean the automation and abstraction layer, not immunity from hardware.

The public evidence around Data Cloud LLC does not provide those test results. It does provide enough to define the tests. The small public edge makes the diligence focused: verify route failover, resource rights, physical placement, hardware spares, support coverage and export rights before treating the service as recoverable hosted capacity.

Power and facility access set the repair clock

Most cloud failures are eventually physical. A route can go down because a router loses power, a fibre path is cut, a cross-connect is mispatched, a line card fails, a facility change goes wrong, or a provider's upstream sees a policy error. The repair time depends less on the cloud label than on access: who receives the alarm, who can enter the site, which spares exist, who controls the ticket with the landlord or carrier, and whether the replacement path has been pre-built.

Data Cloud LLC's public records do not disclose those arrangements. That is normal for a small or mid-size infrastructure provider, but it leaves a real customer question. If the company operates from or around Great Stone, does the service depend on one building, one room or one colocation cage? Does the company control remote hands directly, or does it submit work orders to another operator? Is there a local spares stock for optics, disks, power supplies and routers? Are there vendor support contracts in Belarus, or do some repairs depend on imported hardware and customs timing?

This matters because the official incident clock usually starts after detection and classification, while the customer's outage starts when the workload becomes unreachable. The gap between those clocks is where trust is won or lost. A provider with a small public route edge can still provide good service if it is honest about restoration limits and has practised replacement steps. A provider with impressive marketing can still disappoint if its parts and people are not where the failure occurs.

The customer should ask for operational evidence that matches the service purchased. For virtual machines, ask for host evacuation and storage recovery tests. For bare metal, ask for spare server and disk replacement times. For managed services, ask who has credentials and how changes are approved during an incident. For network service, ask how routing, DDoS mitigation and upstream escalation work when the visible neighbor path is impaired.

The public record cannot answer these questions for Data Cloud LLC. It can only show why the questions are essential.

Data locality is a service claim, not a country code

The assignment region for Data Cloud LLC is BY, and the public records support Belarus as the main jurisdictional signal. RIPE RDAP places Data Cloud LLC's network contact at Great Stone Industrial Park in the Minsk region. The prefix whois record marks 80.71.147.0/24 with country BY. Those are meaningful facts for data-sovereignty and locality analysis.

They are not a complete data-locality guarantee. Country fields in network registries do not always equal the physical location of every server or backup. A contact address is not proof of where customer data is processed. An IP block country code is not proof that storage, logs, support access and backups remain in the same jurisdiction. A service sold by a Belarus-registered or Belarus-located entity can still depend on foreign address-resource organizations, foreign hardware suppliers, remote support tools, upstream carriers or backup services.

Belarus data-protection context therefore belongs in the diligence, but it should be handled carefully. The official Belarus legal portal hosts the Law on Personal Data Protection, and the National Center for Personal Data Protection provides institutional context. These sources establish that personal-data handling is a regulated topic in Belarus. They do not prove which Data Cloud LLC customers handle personal data, which controller or processor role Data Cloud LLC accepts, or whether any particular service is compliant.

For customers, the locality questions should be contractual and technical. Where are primary workloads hosted? Where are backups stored? Which employees or contractors can access systems from outside Belarus? Are logs and monitoring data exported? Which upstream providers or address-resource holders can affect service continuity? What happens if the customer must demonstrate that data stayed within a defined jurisdiction?

Data Cloud LLC's public evidence supports inclusion in the data-sovereignty topic because the company has a Belarus location signal and provides a hosted-infrastructure surface. It does not support broad compliance conclusions. The correct claim is narrower: locality is a material question, and public records provide only partial answers.

Customers should treat migration as part of resilience

The hardest hosted-service failure is not always the outage itself. It is the trapped state after the outage, when a customer wants to move but lacks clean exports, current backups, portable addressing, documented dependencies or staff time. That risk is sharper for small hosted providers because the same team may be responsible for support, billing, network operations and migration help.

Data Cloud LLC's public route record makes migration questions concrete. If customer services use addresses from 80.71.147.0/24, are those addresses portable or provider-assigned? If a customer moves to another provider, how long can the old addresses remain active? Is there a paid migration window? Are reverse DNS, reputation and firewall allowlists part of the support plan? If a customer uses managed services, can it export configuration, images, snapshots, DNS zones and logs without waiting for manual intervention?

Billing is another failure path. A customer can lose service through a payment dispute, sanctions friction, currency mismatch, supplier price change or address-resource contract issue without any hardware failure. The public evidence cannot say whether Data Cloud LLC has those risks under control, but the small public footprint and external address-resource organization make the topic worth asking. Who holds the upstream and address contracts? What happens if costs change suddenly? Are customers given notice before IP, transit or facility changes?

Good migration planning is not an insult to the provider. It is how a customer makes a hosted service safe to use. A provider that can document exports, backups and porting limits usually becomes more credible, not less. For Data Cloud LLC, the due diligence should require a clear exit runbook for each service type: virtual servers, dedicated servers, managed applications, storage, DNS, network service and support credentials.

The article's central warning is therefore not that Data Cloud LLC is unsafe. It is that the public record cannot prove customer recoverability. Migration rights and restore tests are where the buyer closes that evidence gap.

Unofficial signals can suggest activity, but they cannot settle it

Public routing aggregators are useful cross-checks, but they need careful handling. Pages such as BGP.tools for AS48107, Hurricane Electric's BGP Toolkit, IPinfo's AS48107 page, and Cloudflare Radar's AS48107 routing view can help a reader verify that the AS exists in public Internet data and see how third-party tools summarize prefixes or paths. They are not contract documents, and they can lag or differ from each other.

The same is true of any hosting directory, market listing, archive, search result or reseller page that mentions Data Cloud LLC. Such signals may show that a name is circulating in the market, that an IP block has reverse-DNS or service associations, or that the company has been indexed by infrastructure tools. They cannot prove current customer count, service quality, facility location, owner control or recovery obligations.

The right use of unofficial signals is triangulation. If RIPEstat says the AS is announced, a BGP aggregator shows the same current prefix, and RDAP shows the Data Cloud LLC identity, the evidence for a live network edge becomes stronger. If a market page claims broad cloud capacity but routing data shows one /24 and no public interconnection profile, the buyer should ask for private proof rather than accepting the market page. If a search result says "data centre" but no official or technical record confirms facility details, the claim remains a lead.

What evidence would settle more? A current service catalogue from Data Cloud LLC, a facility and carrier disclosure, a looking-glass or route policy page, a status page with incident history, a PeeringDB profile, a valid RPKI ROA for the current prefix, customer-facing terms for backups and exports, or third-party certification tied to the actual site. None of those is required for a company to operate. Their absence simply lowers what outsiders can responsibly claim.

For this profile, unofficial signals are secondary. The article relies most heavily on RIPE, RDAP and RIPEstat because those sources directly support identity, address, prefix and route state.

The failure path is one rack, one route, one support queue

The practical failure path for Data Cloud LLC should be described from the customer's side. The customer does not experience "an autonomous system issue". The customer experiences unreachable servers, unavailable applications, lost administrative access, delayed ticket response, failed backups, changed addresses, or a migration that cannot be completed before a business deadline.

The single visible prefix and single currently observed neighbor make three tests especially important. First, route failure: if AS56740 is unavailable or a policy mistake affects the path, what carries production traffic? The aut-num object lists additional policy counterparties, but the customer needs to know which paths are live, which are standby and which are historical. Second, facility failure: if the active rack, room or power domain fails, what installed capacity continues service?

Third, support failure: if the same small team handles network, server and customer requests, how are incidents prioritized when many customers open tickets at once?

Those tests should be tied to measurable commitments. How many minutes to acknowledge a critical issue? How many hours to restore a failed physical host? How recent is the last backup restore test? How much traffic can the alternate path carry during peak use? Which customer actions are self-service, and which require a support queue? What evidence is provided after a maintenance window?

The answers may be perfectly acceptable for some customers and insufficient for others. A small local application may tolerate a manual recovery process if the price and support relationship are right. A regulated workload may require documented locality, backup immutability and tested failover. A public e-commerce service may require DDoS response, upstream diversity and export rights. The same provider can be appropriate or inappropriate depending on the dependency.

Data Cloud LLC's public evidence does not decide that fit. It frames the risk conversation around the visible constraints: compact address space, one current public neighbor, unknown route-origin validation and undisclosed facility depth.

How a buyer should verify Data Cloud LLC before relying on it

The verification plan should be short, technical and tied to the actual service. First, confirm the service boundary. Ask which legal entity signs the contract, which entity controls AS48107, which address resources are assigned to customer services, and whether the customer receives provider-assigned or portable IPs. The public RDAP record and RIPEstat whois record provide the starting identifiers, but the contract has to align with them.

Second, confirm the network boundary. Ask Data Cloud LLC to identify current production upstreams, standby upstreams and any private interconnects. Ask how AS56740, AS21305, AS42772 and AS12406 relate to the current service, because those names appear in the aut-num policy but not all appear in the current RIPEstat neighbor observation. Ask for route-origin validation status and a plan for ROA publication if the current unknown RPKI state is still accurate.

Third, confirm the facility boundary. Ask where primary compute, storage and backups are physically located, who owns or leases the racks, how power and cooling are backed up, and who performs remote hands. The Great Stone address in RDAP is a useful lead, but it is not proof of workload placement. The customer should ask for a site description appropriate to the risk, even if the provider cannot disclose every security detail.

Fourth, confirm the recovery boundary. Ask for the latest restore test, backup retention, off-site or second-site design, hardware replacement plan, DDoS escalation, support coverage hours and customer communication method during an outage. These are not luxury questions. They are the difference between a cheap hosted service and a recoverable service.

Fifth, confirm the exit boundary. Ask how data, images, DNS, logs and IP dependencies are exported. If the service is hard to leave, the customer is buying not only hosting but lock-in. A credible provider can define the limits plainly.

What the public record supports today

The public record supports five firm statements. Data Cloud LLC is named in RIPE RDAP and RIPEstat records for AS48107. The AS was announced in the RIPEstat overview at the July 2026 query time. The current visible prefix was 80.71.147.0/24, with no current IPv6 visible in the routing-status view. The route object for that /24 points to origin AS48107. The current neighbor observation identified AS56740, while the aut-num object also lists policy entries for AS21305, AS42772 and AS12406.

The same record does not support five stronger statements. It does not prove the company runs a broad public cloud. It does not prove the current customer workload location. It does not prove multi-site failover. It does not prove route-origin validation. It does not prove that all policy-listed upstreams are currently active and capacity-bearing.

That boundary is the article's main finding. Data Cloud LLC has enough public infrastructure evidence to be treated as an operating network subject rather than a name-only entry. It does not have enough public evidence to let a customer outsource diligence. The company may have more capacity, redundancy and support than public sources show. If so, the evidence needed is straightforward: current facility disclosure, route-diversity proof, RPKI status, recovery tests, service terms and exit procedures.

For BTW readers tracking infrastructure dependency, Data Cloud LLC sits in the category of small visible hosted-capacity operators whose importance can be underestimated precisely because the public footprint is compact. One /24 can still carry critical customer services. One upstream path can still become the decisive failure point. One support queue can still determine whether an outage is a nuisance or a business interruption.

The safest conclusion is disciplined curiosity. Data Cloud LLC's AS48107 is real and visible. Its hosted-capacity promise still depends on racks, transit, power, hardware, support labour and migration paths that public records only partially expose.