Summary

  • The operator site sells five priced products and claims direct physical peering to Yandex, Sberbank and Rostelecom; no independent routing source shows a session with any of them.
  • AS210328 is a small, live network: three IPv4 prefixes originated, two announced, two RPKI-valid, one without a covering ROA, and only transit providers observed — no peers, no downstreams.
  • Each identity link (brand, domain, ASN, sponsoring LIR, corporate registration) is separately checkable, but no retrieved source bridges any two of them into a verified chain.
  • The OGRN 1196501003357 printed in the RIPE organisation object is associated by third-party aggregators with a Yuzhno-Sakhalinsk company — a regional profile that does not match the marketed Moscow cloud business.

The advertised business

The website almazcloud.network presents itself as "DIAMOND (on rus. ALMAZ)", described as a "brand new progressive cloud services provider". It lists exactly five priced products: Cloud Connect starting at $499 per month per 10G physical port; BGP Announcements from $99 per month per announced prefix; a No-BGP GRE Tunnel from $99 per month per 100 Mbps; a Corporate Cloud VPN from $9 per month per user; and Cloud Reselling from $99 per month per connected cloud. The Cloud Connect product carries the catalog's central claim: a "Direct physical peering connection to Yandex, Sberbank, ROSTELECOM, Selected and some other well known cloud providers" [https://almazcloud.network/].

The site publishes several contact mailboxes for sales, network administration, billing, management and abuse handling, and claims REST API and CLI ordering interfaces. What it does not display is any evidence of operation: no capacity figures, no facility list beyond what third parties record, no customer count, no reference customers, no SLA document, no traffic statistics. It is a marketing sheet. It establishes an advertised offering; it does not establish an operating business.

The measured network

Hurricane Electric's BGP toolkit reports AS210328 originating three IPv4 prefixes — 77.91.65.0/24 (registered to IP-FI-FotonTel), 185.136.15.0/24 and 185.218.138.0/24 (both registered to Vlad Cojuhari) — announcing two of them, with 512 originated IPv4 addresses, 717 observed AS paths and an average path length of 5.319 [https://bgp.he.net/AS210328]. ping.pe gives per-prefix RPKI states: 77.91.65.0/24 VALID, 185.136.15.0/24 VALID, 185.218.138.0/24 NOT-FOUND, meaning no covering ROA exists for the third prefix [https://records.ping.pe/210328].

The neighbour table is the decisive fact for this report: HE lists only AS202425 (IPV), AS201814 (MEVSPACE sp. z o.o.) and AS48693 (Rices Privately owned enterprise). These are transit relationships. No observed peer. No observed downstream customer. The network is live — prefixes are announced, paths are collected — but its observable topology is a spoke hanging off three upstreams.

Third-party aggregators do not fully agree on the details, and the disagreements matter. IPtrace reports only two IPv4 prefixes and a "50% RPKI Valid Rate" described as 1 valid and 1 invalid of 2 sampled; neither ping.pe nor HE reproduces an "invalid" verdict for this AS, and "invalid" (a conflicting ROA exists) is a materially different state from "NOT-FOUND" (no ROA exists) [https://iptrace.net/en/as/210328]. IPtrace's commercial fields — "Traffic 10-20Gbps", "Peering Policy Restrictive" — are aggregator estimates, not measurements.

The registry layer

Mirrors of the RIPE aut-num object for AS210328 consistently show: as-name ALMAZ, org ORG-ZA238-RIPE, import "from AS48693 accept ANY", export "to AS48693 announce AS210328", status ASSIGNED, maintainers RIPE-NCC-END-MNT and ALMAZ-MNT, created 27 December 2021, last-modified 21 August 2026 at 04:38:32 UTC, sponsoring-org ORG-DNJ1-RIPE [https://whois.ipip.net/AS210328]. One caveat must be stated plainly: the authoritative RIPE Database web UI returned only an application shell during this research pass, so every "live registry" statement here rests on third-party mirrors that embed RIPE output, not on a first-party read of the record itself.

Even the mirrors disagree with each other on one field: whois.ipip.net shows admin-c/tech-c ZAN42-RIPE, while the HE-embedded copy shows DUMY-RIPE alongside RIPE's standard personal-data-redaction remark block — a redaction artifact that explains part, but not all, of the discrepancy. Robtex holds a plainly stale snapshot naming AS12695 in the policy, last modified December 2021 [https://robtex.com/en/as-numbers/AS210328]. RIPEstat, RIPE NCC's own portal, was captured only as fragmentary text associating the AS with ALMAZ, ORG-ZA238-RIPE and ALMAZ-MNT, with a two-entry prefix table and a data stamp of 30 September 2026; its RPKI and consistency panels were not captured [https://stat.ripe.net/resource/AS210328].

The routing-policy object names exactly one partner, AS48693, while routing observation shows three transit relationships. The object is incomplete relative to the observed topology — a small but telling mismatch between what is registered and what runs.

The corporate layer

The RIPE organisation object ORG-ZA238-RIPE mirrors as org-name AO ALMAZ, country RU, reg-nr 1196501003357, org-type OTHER [https://whois.ipip.net/AS210328]. That fifteen-digit number is an OGRN, and Russian corporate-registry aggregators associate it with AO "ALMAZ" of Yuzhno-Sakhalinsk, INN 6501304360, recorded in a Sakhalin regional business register [https://www.audit-it.ru/contragent/1196501003357_ao-almaz] [https://fish-sakh.ru/businesses/ao-almaz/].

Two gaps open here. First, the association between the OGRN and the network operator rests on third-party aggregators, not a primary EGRUL or FNS extract; the registry name matching is suggestive, not probative. Second — and more striking — the regional profile does not match the marketed business. A Sakhalin-registered joint-stock company named ALMAZ sits roughly 6,000 kilometres from the three Moscow interconnection facilities (Berzarina Data Center, IXcellerate MOS1, Moscow M9) that PeeringDB record 19111 lists for this ASN. PeeringDB is operator-self-maintained, last substantively updated 27 July 2022, and self-reports zero IPv4 and zero IPv6 prefixes — directly contradicting live routing observation — so its facility claims are claims of presence, not proof of active capacity [https://www.peeringdb.com/net/19111]. But even that stale, self-entered record points to Moscow, while the only corporate anchor in the chain points to Sakhalin.

No document retrieved in this research pass bridges the registry name to the network operator: no corporate filing naming the ASN, no payment trail, no sponsorship letter, no delivery record, no customer.