Summary

  • The operator behind almazcloud.network, branded DIAMOND (Russian ALMAZ), sells five priced products — headlined by Cloud Connect at 499 USD per month per physical 10G port, described as a "direct physical peering connection to Yandex, Sberbank, ROSTELECOM" — from its own prior BTW reporting.
  • Autonomous system AS210328, the network registered to the same identity, originates three IPv4 /24 prefixes totalling 512 addresses, announces two of them, holds RPKI-valid ROAs for exactly those two, and is observed with three upstreams and zero peers or downstreams.
  • Every originated prefix is registered to third parties, not to the operator's organisation: Foton Telecom, Vlad Cojuhari and a Kazakhstan-linked Telepatiya Ltd.
  • The registration number cited in the RIPE organisation object maps, via the aggregator audit-it.ru, to a two-employee Sakhalin marine-aquaculture microenterprise with no 2025 revenue — not a Moscow cloud-connect business.
  • Nothing in the retrieved public record places the operator's own website, DNS authority or mail service on AS210328 address space. The seller's own operations are invisible on the network doing the selling.

A buyer searching for low-cost compute and connectivity in the AI era encounters a familiar shape: a small operator with a polished catalogue, dollar prices, and claims of direct interconnection with the largest networks in its market. The operator behind almazcloud.network fits that shape exactly. Its site brands the venture DIAMOND — "on rus. ALMAZ" — and calls it a "brand new progressive cloud services provider" (prior BTW reporting). The catalogue lists CLOUD CONNECT from 499 USD per month per physical 10G port; BGP ANNOUNCEMENTS from 99 USD per month per announced prefix; a NO-BGP GRE TUNNEL from 99 USD per month per 100 Mbps; a CORPORATE CLOUD VPN from 9 USD per month per user; and CLOUD RESELLING from 99 USD per month per connected cloud.

The commercial core of that catalogue is the first product. Direct physical peering with Yandex, Sberbank and Rostelecom is not a marginal add-on; it is the reason a buyer would pay a premium port price to a brand with no public track record. It is also, unusually, the one part of the proposition that can be tested independently, because peering leaves observable traces: shared exchange points, observed neighbours, announced prefixes, RPKI authorisations.

What the routing table shows

Hurricane Electric's BGP toolkit, the most current routing-side tally in the public record, attributes AS210328 to AO ALMAZ with the website almazcloud.network and reports the following measured state: three originated IPv4 prefixes, two announced, two with RPKI-valid ROAs, 512 originated IPv4 addresses, no IPv6, and three observed neighbours — AS202425 (IPV), AS201814 (MEVSPACE sp. z o.o.), and AS48693 (Rices, a privately owned enterprise) (IPregistry). All three relationships are of the transit type. No peer and no downstream appears in any retrieved observation (IPregistry).

The three prefixes are 77.91.65.0/24, 185.136.15.0/24 and 185.218.138.0/24. None of them is registered to AO ALMAZ. Hurricane Electric's description field names IP-FI-FotonTel for the first and Vlad Cojuhari for the other two (IPregistry); a registry mirror describes 185.136.15.0/24 as Telepatiya Ltd, a Kazakhstan-linked registrant (whois.ipip.net/AS210328/185.136.15.0/24). An operator selling connectivity does not own, at the registry level, a single address it announces.

The RPKI picture is narrower still. The rpki-client validator console lists exactly two ROAs under AS210328 — for 77.91.65.0/24 and 185.136.15.0/24, both with maxlen 24 (IPregistry). Per-prefix observation at ping.pe confirms the split: the first two prefixes validate, and 185.218.138.0/24 is RPKI NOT-FOUND for this origin (IPregistry). A network whose flagship product is interconnection announces a third of its space with no route-origin authorisation at all.

The registry anchor and where it points

The RIPE registry records the aut-num with as-name ALMAZ, organisation ORG-ZA238-RIPE, org-name AO ALMAZ, country RU, registration number 1196501003357, org-type OTHER, created 2021-12-27 and last modified 2026-08-21, with a sponsoring organisation ORG-DNJ1-RIPE and a routing policy that speaks only of AS48693 — import from AS48693 accept ANY, export to AS48693 announce AS210328 (whois.ipip.net/AS210328/185.136.15.0/24, IP2Location). The abuse contact is a role object named after the domain itself, with the remark that replies are given only to email written in Russian.

The registration number is the one hard link between the ASN and a legal entity, and the aggregator dossier for it is striking. Audit-it.ru maps OGRN 1196501003357 to AO ALMAZ in Yuzhno-Sakhalinsk, Sakhalin Oblast, registered in May 2019, whose primary activity is marine aquaculture under OKVED 03.21, directed by Khan Marina Menkhoevna, with an average headcount of two employees in 2024 and 2025, no revenue in 2025, a 2024 revenue of 14.6 million roubles, a 2025 net loss of 883 thousand roubles, and microenterprise status under simplified taxation (according to the aggregator audit-it.ru).

The mapping is aggregator-based and should be confirmed against a primary EGRUL extract before being treated as final; as published, it describes a fish-farming microenterprise, not a Moscow cloud-connect operator claiming three interconnection facilities.

Prior BTW reporting already documented the August 2026 registry edit and the divergence between routing collectors and stale mirrors for this ASN (btw.media). The mirror record matters here for a different reason: IPinfo classifies AS210328 as Inactive with zero addresses and zero hosted domains (BTW mirror-divergence record), while Hurricane Electric and IPregistry report 512 originated addresses (ipregistry.co). "No evidence in one mirror" is not evidence of absence — but neither mirror places the operator's own services on its own network.

The delivery question

The question this report adds to the record is operational self-consistency: does the operator run its own published services on the network it sells? The evidence retrieved for this article — the operator's own site, PeeringDB, RIPEstat, registry mirrors, routing collectors, RPKI validators — contains no A-record or DNS-authority observation, no mail-host record and no certificate-transparency entry placing almazcloud.network on AS210328 space. It contains no observation placing those services on any third-party network either.

DNS, mail and certificate layers remain unverified in the public record; what is established is that the positive claim — the operator's services demonstrably run on AS210328 — has no supporting evidence anywhere in the retrieved set.

The operator's own site makes no claim on that point. It states no hosting location, names no legal entity, and prints no registration number; the only bridge between the brand and the ASN in the public record is the operator-maintained PeeringDB record and the registry's own role object. PeeringDB record 19111 is self-declared: organisation AO ALMAZ, long name "ALMAZ (DIAMOND) CLOUD NETWORK", network type NSP, self-reported traffic of 10-20 Gbps with a balanced ratio, three Moscow facilities (Berzarina Data Center, IXcellerate MOS1, Moscow M9), and — remarkably — zero self-reported IPv4 and zero IPv6 prefixes, with substantive fields dating to 2022-07-27 (prior BTW reporting). A record that claims three Moscow interconnection points while reporting zero prefixes is not evidence of operation; it is evidence of intent, typed in 2022.

Taken together, the delivery-side picture is consistent and unsupportive of the catalogue. A network with three upstreams and no peers cannot be selling direct physical peering from the address space it controls, because the observed relationships are exactly the ones a customer of transit would have. A network whose prefixes are registered to three different third parties is not an infrastructure owner but a user of someone else's space.

And a corporate anchor in marine aquaculture on Sakhalin, two employees and no revenue, is not the profile of a company operating 10-20 Gbps of Moscow interconnection — unless the registry number itself is wrong, which only a primary registry extract can resolve.

None of this is proof of wrongdoing, and none of it requires it. The honest description is narrower: as of 5 October 2026, every claim in the almazcloud.network catalogue that a buyer could verify externally — the peering, the capacity, the facilities — is unverifiable from public evidence, and the few things that can be measured point away from the catalogue rather than toward it. The product being sold, measured against the record, is trust. Trust is the one input a buyer should price explicitly.