Summary

  • The RIPE organisation object ORG-ZA238-RIPE behind AS210328 is named AO ALMAZ and cites Russian registration number 1196501003357; independent corporate-registry aggregators resolve that number to a Sakhalin-based AO ALMAZ engaged in marine fish farming, with roughly two employees and about RUB 14.6 million in 2024 revenue — a profile materially inconsistent with the Moscow-marketed cloud operator trading as almazcloud.network.
  • Independent routing evidence contradicts the operator's headline sales claims: collectors observe three upstream providers and no observed peers or downstreams, while the operator's site advertises direct physical peering to Yandex, Sberbank and Rostelecom.
  • The prefix 185.218.138.0/24 is announced by three different origin networks and carries no covering ROA for AS210328, and its registration is attributed to a third party — a layered dispute condition that no public record has resolved.
  • The structural problem is not one bad record. It is that nothing in the public evidence chain requires a network's registry identity to match its marketed business, and the verification tools a buyer can use (PeeringDB, RIPE database, corporate registers) disagree with each other or are stale.

A network record is only as accountable as the identity behind it. AS210328 was created on 2021-12-27 in the RIPE database as the autonomous system of AO ALMAZ, organisation ORG-ZA238-RIPE, country RU, citing Russian registration number 1196501003357 [https://whois.ipip.net/AS210328]. On its face, that is an ordinary registry entry: a legal entity, a number, a handle. But follow the number and the picture becomes contested. Russian corporate-registry aggregators — audit-it.ru [https://www.audit-it.ru/contragent/1196501003357_ao-almaz] and dela.pravo.tech [https://dela.pravo.tech/public/company/1196501003357] — resolve registration number 1196501003357 to a Sakhalin-based AO ALMAZ whose registered activity is marine fish farming, whose director is recorded as Khan Marina Menkhoevna, and whose 2024 revenue was about RUB 14.6 million with roughly two employees. Nothing in that profile describes a cloud operator selling BGP announcements from Moscow.

This mismatch is established here as an unresolved identity-verification question, not as proof of deception. The mapping between the RIPE reg-nr and the Sakhalin entity rests on third-party aggregators; no primary EGRUL/FNS record was available in this research, and the discrepancy could reflect a data-entry error in the RIPE organisation object, an org object genuinely attached to the wrong legal entity, or an aggregator error. Each explanation carries a different remedy, and each is testable. That is precisely why the gap matters: today, no public mechanism forces the test to happen.

Meanwhile the network operates. Independent routing collectors observe AS210328 originating three IPv4 prefixes — 77.91.65.0/24, 185.136.15.0/24 and 185.218.138.0/24 — of which two validate under RPKI, with 512 originated IPv4 addresses and exactly three observed upstream relationships: AS202425 (IPV), AS201814 (MEVSPACE) and AS48693 (Rices) [https://bgp.he.net/AS210328]. No peers and no downstream networks appear in those observations, and one commercial aggregator, updated 21 August 2026, states directly that AS210328 has no direct peering agreements and reaches the internet only through transit [https://ipregistry.co/AS210328].

That last sentence sits uncomfortably next to the operator's own marketing. The almazcloud.network site, trading as DIAMOND, prices five products — Cloud Connect from $499 per month per 10G port, BGP announcements from $99 per month per prefix, a no-BGP GRE tunnel from $99 per month per 100 Mbps, a corporate cloud VPN at $9 per user, and cloud reselling at $99 per month — and claims "direct physical peering connection to Yandex, Sberbank, ROSTELECOM" [https://almazcloud.network/]. Among the three upstream relationships collectors observe, no adjacency to Yandex, Sberbank or Rostelecom appears at all. A buyer paying for "direct physical peering" to those companies is buying something no independent record corroborates.

The cryptographic layer adds structure to the dispute. The rpki-client console lists exactly two ROAs referencing AS210328 — for 77.91.65.0/24 and 185.136.15.0/24, both with max length 24, both published in the RIPE repository — and none for 185.218.138.0/24, which ping.pe likewise marks NOT-FOUND [https://console.rpki-client.org/AS210328.html] [https://console.rpki-client.org/] [https://records.ping.pe/210328]. Meanwhile AS205997, operated by Vlad Cojuhari, currently holds a ROA over 185.136.15.0/24 — the same prefix AS210328 also covers — and no ROA for 185.218.138.0/24 [https://console.rpki-client.org/AS205997.html]. The disputed third prefix is more tangled still: it is announced by three different origins, AS209630 (LLC VASH KREDIT BANK), AS205997 (Vlad Cojuhari) and AS210328 (AO ALMAZ), while its registration is attributed to Cojuhari, a party distinct from the AS210328 operator [https://bgp.he.net/net/185.218.138.0/24]. Prior BTW coverage recorded a 2026-08-24 revocation timestamp for the 185.218.138.0/24 authorization; this research could not independently confirm that timestamp, so it is reported here as unconfirmed.

Public mirrors disagree about even the basics. IPinfo classifies AS210328 as Inactive with zero IPv4 and IPv6 addresses and no peers, last updated 2021-12-28 [https://ipinfo.io/AS210328], while live collectors show active prefixes. IPinfo also describes 185.218.138.0/24 as RPKI valid under AS205997, which the rpki-client console contradicts. TheIpAPI and older mirrors reproduce 2021-era two-prefix snapshots [https://theipapi.com/asn/210328] [https://robtex.com/en/as-numbers/AS210328] [https://iptrace.net/en/as/210328]. PeeringDB record 19111 independently carries the identity chain — organisation AO ALMAZ, long name "ALMAZ (DIAMOND) CLOUD NETWORK", website almazcloud.network — but its substantive fields were last updated 2022-07-27 and it lists zero prefixes with self-declared traffic of 10-20 Gbps [https://www.peeringdb.com/net/19111]. The Berzarina facility record the ASN cites is real and Selectel-operated [https://www.peeringdb.com/fac/9865], but a directory entry for a facility does not evidence occupancy.

The registry objects themselves are consistent across mirrors: the aut-num was rewritten on 2026-08-21T04:38:32Z to an import policy of "from AS48693 accept ANY" under sponsoring organisation ORG-DNJ1-RIPE [https://whois.ipip.net/AS210328], and the RIPE role object ZAN42-RIPE publishes an abuse mailbox for the domain with a remark that replies are given only to emails written in Russian [https://ipgeolocation.io/browse/asn/AS210328]. An abuse contact that answers only in Russian is not itself a violation, but for a network selling services priced in dollars to an international market, it narrows the practical remedy path for most potential complainants.

What does a buyer actually verify before sending money to a network like this? In principle, three checks: the RIPE database for the legal organisation, PeeringDB for operational posture, and a corporate register for the legal entity. Each one fails here, in a different way. The RIPE org object points to a registration number that resolves to a fish-farming company. PeeringDB is three years stale. Corporate registers are third-party aggregators unless one pays for primary EGRUL extracts, and even then the registry-to-operator link must be taken on trust.

The remedy question is therefore structural: RIPE NCC membership agreements do require accurate registration data, but nothing in the public evidence chain surfaces a mismatch between a reg-nr and the business the network markets, and no buyer-facing tool aggregates that check. Until verification is routine, the operational record — what collectors observe, what ROAs exist, what upstreams carry the traffic — remains the only evidence layer that does not depend on the operator's own declarations.