Summary
- RIPE records identify CLOUDY INFORMATION SYSTEMS LLC as a Russian local Internet registry with a Moscow address, registration number, contact telephone, two assigned autonomous system numbers, and three associated IPv4 ranges.
- RIPEstat showed AS204520 announcing one
/24on July 15, 2026, while AS199000 was not announced. That is useful evidence of a real network footprint, but it is not evidence of a particular cloud product, customer workload, service level, recovery design, or security control. - A prospective customer should require service-specific proof covering workload and backup location, control-plane dependencies, resilience, incident escalation, support staffing, data return, and deletion before treating the company name as operating assurance.
The strongest public evidence is about identity and numbering
A cloud provider can be difficult to assess from the outside because the visible brand, contracting company, network operator and facility owner may all be different. In the case of CLOUDY INFORMATION SYSTEMS LLC, the clearest public anchor is not a product page. It is the set of records maintained around Internet number resources.
The RIPE NCC member listing names CLOUDY INFORMATION SYSTEMS LLC, gives a Moscow address, a telephone number and an [email protected] contact, and lists the area served as the Russian Federation. The corresponding RIPE organisation record identifies the organisation as a local Internet registry, records Russian registration number 1157746211424, and was last modified on May 13, 2026.
Those are meaningful identity signals. A local Internet registry is an organisation that manages Internet number resources under the RIPE NCC framework. A current organisation record also gives investigators, network operators and customers a consistent name against which to compare route and address data.
But this evidence has a limit. RIPE's purpose is coordination of Internet resources, not certification of corporate solvency, cloud architecture, customer support quality or contractual performance. The registration number in the record is a useful key for legal due diligence, but the RIPE entry alone does not establish current corporate standing. A buyer should still match the contracting party, bank beneficiary, tax details and signatory authority against the appropriate company record before money or production data changes hands.
Two assigned ASNs tell different present-tense stories
The company is linked to two autonomous system numbers in the RIPE Database: AS204520, named OIS-AS, and AS199000, named ALPGROUP. An autonomous system number identifies a network that can present a routing policy to the rest of the Internet. Holding one is stronger evidence of network-operating capability than simply owning a cloud-themed domain.
The records describe both ASNs as assigned and list route-policy relationships with AS29226 and AS43226. Yet assignment and current visibility are not the same thing. RIPEstat's July 15 view marked AS204520 as announced, and its announced-prefix view showed 176.122.18.0/24 visible during the July 1 to July 15 observation window. A /24 contains 256 IPv4 addresses. IPinfo's AS204520 profile likewise classified it as a hosting network, associated it with goodcloud.ru, and reported two upstreams, no downstream networks and no known IPv6 addresses.
AS199000 was different at the same point in time. RIPEstat marked the ASN as not announced, and its announced-prefix result was empty for the same July window. That does not show that the number has been abandoned, nor does it establish whether resources once associated with it are being originated elsewhere. It says only that RIPEstat did not see AS199000 announcing qualifying routes at the observation time.
That distinction matters in procurement. A list of assigned resources is a capability map; a route observation is evidence of current Internet visibility. Neither one identifies the virtualisation platform, storage layer, tenant isolation model or service customers using the addresses.
The address holdings are larger than the visible route
A RIPE inverse lookup on the organisation handle associates CLOUDY INFORMATION SYSTEMS LLC with three IPv4 ranges: 171.22.236.0/22, 176.122.18.0/24 and 91.241.4.0/24. Together they contain 1,536 IPv4 addresses. The same lookup returned no IPv6 allocation for the organisation.
The ranges add substance to the company's public footprint, but the numbers need careful reading. Allocation or assignment records establish responsibility for address resources; they do not demonstrate that every address is routed, occupied by a server, offered to customers or protected by the same controls. In this review, RIPEstat directly confirmed only the 176.122.18.0/24 announcement from AS204520. The other records remain relevant to an ownership and responsibility map, but they should not be presented as a live capacity count.
Even the small visible route can be informative. IPinfo reported 13 hosted domains across five addresses in AS204520 and recorded a successful probe to one address from Moscow in February 2026. That is evidence that at least part of the range has supported reachable Internet services. It is not a customer reference and does not reveal whether those services were infrastructure management endpoints, company systems or hosted workloads.
For an enterprise buyer, the next useful artefact would be a service-specific network map: customer ingress, management endpoints, upstream diversity, denial-of-service handling, DNS dependencies, address ownership, route security, and the path used by support engineers. Without it, the public route record is a clue to the operating surface, not a diagram of it.
A cloud label does not reveal the service underneath
The name CLOUDY INFORMATION SYSTEMS LLC and the goodcloud.ru domain strongly suggest a cloud or hosting proposition. The network data is consistent with hosting activity. What the frozen public record did not supply was a verifiable service catalogue that connected named products to this company and its network resources.
During this review, goodcloud.ru resolved in DNS but did not return an accessible HTTPS service page from the research environment. That point-in-time result should not be treated as proof that the company has no functioning website or no customers. Web access can fail because of geography, filtering, maintenance, server policy or a transient network problem. It does mean the site could not be used here to verify product names, pricing, customer terms, documentation, a status page, certifications or support hours.
The DNS picture also resists a simplistic reading. The root domain resolved to an address outside the three ranges linked to the company in the RIPE organisation lookup. Its authoritative name-server set included both NIC.RU names and ns.goodcloud.ru, with the latter resolving inside 176.122.18.0/24; mail exchange pointed to Yandex. Hosting a corporate site or mail through another provider is common and says little about where customer workloads run. It does, however, show why a domain name cannot stand in for a dependency map.
A credible service claim would connect the layers. It would identify the contracting entity; name the compute, storage, backup or managed-service offer; state the facility and jurisdiction; describe third-party dependencies; define the service level; and show how customers can obtain support and recover data. None of those claims can safely be reconstructed from an ASN.
Data locality needs a workload answer, not a country code
The RIPE records place the organisation and its resource service area in Russia. That is relevant, but it does not settle data sovereignty. A country field in a network record may describe the holder of an address block rather than the physical position of every server using it. Geolocation databases are also observations and estimates, not contractual commitments.
The buyer's question is therefore not simply, "Is this a Russian network?" It is: where will each category of customer data be stored, copied, processed and administered? That question should cover primary volumes, snapshots, off-site backups, logs, monitoring telemetry, support attachments, identity systems, billing records and encryption keys. It should also cover the people and systems that can reach them.
For regulated or cross-border workloads, four answers matter. First, the provider should name the facility or at least the legal jurisdiction and availability zone in the contract. Second, it should disclose replication and backup locations, including any subcontractor. Third, it should describe remote administrative access and the countries from which support staff may connect. Fourth, it should set out the process for data return, retention and verified deletion after termination.
These are not demands for architectural trivia. They determine which laws and operational teams can touch customer information, whether a regional incident can affect all copies, and whether a customer can leave without losing evidence or business continuity.
A mailbox is an accountability point, not a support promise
The RIPE material provides more contact evidence than many thinly documented providers. The member page supplies a telephone number and administrative email. The organisation record links named administrative and technical contacts. A separate RIPE abuse contact record supplies [email protected]. Those details make the network less anonymous and create routes for operational or abuse escalation.
Still, a reachable contact is not the same as a staffed support function. The public records do not say whether assistance is available around the clock, which languages are covered, how customers authenticate, how severity is assigned, or what response and restoration targets apply. They do not show an incident status channel, escalation manager, service-credit process or post-incident review practice.
Support labour is part of cloud architecture because people close the gaps that automation cannot. When a control plane fails, a backup will not mount, an account is compromised or a route disappears, the useful measure is not whether an email address exists. It is whether a qualified person is accountable, awake, authorised to act, and able to communicate with both the customer and any facility or upstream provider.
A buyer should test that system before launch. Open a pre-sales technical case and a support case. Record acknowledgement time, technical depth and escalation behaviour. Ask who owns a priority-one incident at 03:00 local time, whether that person is an employee or contractor, and who can approve emergency access. The answers should appear in the service schedule, not remain a salesperson's reassurance.
The evidence request that turns a name into assurance
The public record is strong enough to justify a focused diligence process. It is not strong enough to skip one. A practical evidence request would cover the following points:
| Question | Evidence to request | What it resolves |
|---|---|---|
| Who is responsible? | Company extract, signatory authority, contract entity and matching payment details | Whether the visible network operator and legal counterparty align |
| What is being sold? | Current service description, architecture boundary and customer responsibility matrix | Whether "cloud" means virtual machines, hosting, backup, managed operations or something else |
| Where is data handled? | Contracted workload, backup, log, support and key-management locations | Jurisdiction, transfer and concentration risk |
| How does the service fail safely? | Availability design, dependency map, recovery objectives and recent recovery-test evidence | Whether redundancy and restoration claims are operationally credible |
| How is access controlled? | Identity controls, privileged-access process, logging, vulnerability handling and independent assurance reports | Whether tenant and administrative access are governed |
| Who responds? | Support hours, languages, severity model, named escalation path and response targets | Whether human support matches workload criticality |
| How does a customer leave? | Export formats, egress process, termination assistance, retention window and deletion evidence | Portability and exit risk |
| How does the network map to the service? | Current prefixes, origin ASNs, upstream design, route-security controls and endpoint inventory | Which public network evidence actually belongs to the purchased service |
The provider may have satisfactory answers that are shared only under confidentiality. That is normal for detailed diagrams and security reports. The important point is that claims should be supported by current artefacts and contractual commitments, not inferred from the company name or the existence of number resources.
The verdict: a real footprint, with assurance still to be earned
CLOUDY INFORMATION SYSTEMS LLC is not merely an untraceable cloud label. The public record connects the name to a Russian registration number, a Moscow contact address, RIPE NCC membership, assigned network resources, accountable contact roles and one currently visible IPv4 route. That gives researchers and potential customers a concrete starting point.
The same record also sets the boundary of what can be said. It does not establish a defined cloud product, audited control environment, customer service level, workload location, recovery capability or support operation. AS204520's visible /24 is proof of routing activity, not proof of operating assurance. AS199000's assigned-but-unannounced state is a diligence question, not a verdict.
The responsible conclusion is therefore neither endorsement nor dismissal. The company has a verifiable network identity and a modest observable footprint. Before a critical workload relies on it, the buyer should make the service, locality, dependency and support claims explicit, testable and contractual. That is the point at which a cloud name starts to become an accountable operating promise.