Summary

What the registry actually ties together

Start with the part of the record that does not require interpretation. The RIPE database object for AS210328 names as-name ALMAZ and organisation ORG-ZA238-RIPE, and the organisation object carries the legal name AO ALMAZ, country RU and registration number 1196501003357. Its remarks point at almazcloud.network, and the abuse contact is an abuse-contact mailbox on the almazcloud.network domain. The aut-num was created on 2021-12-27 and last modified on 2026-08-21T04:38:32Z, with a sponsoring organisation ORG-DNJ1-RIPE. https://ipgeolocation.io/browse/asn/AS210328 PeeringDB, a voluntary and self-maintained registry, independently lists record 19111 under the name ALMAZCLOUD with organization AO ALMAZ and long name "ALMAZ (DIAMOND) CLOUD NETWORK", with https://almazcloud.network/ as the company website. https://www.peeringdb.com/net/19111

That is a complete chain from a Russian legal entity, through a RIPE membership object, to an autonomous system number and a marketing domain. The chain is real and independently cross-referenced. What it establishes is identity and intent to be reachable, not operation. A PeeringDB entry is a declaration of intended footprint; it proves nothing about running services, and this one was last substantively updated on 2022-07-27, with the RIR status field touched on 2024-06-26. https://www.peeringdb.com/net/19111

The commercial claim, stated precisely

The operator's first-party site is unusually concrete. It prices five products: CLOUD CONNECT from $499 per month per 10G physical port; BGP ANNOUNCEMENTS from $99 per month per prefix; NO-BGP GRE TUNNEL from $99 per month per 100Mbps; CORPORATE CLOUD VPN from $9 per month per user; and CLOUD RESELLING from $99 per month per connected cloud. The headline promise is a "direct physical peering connection to Yandex, Sberbank, ROSTELECOM, Selected and some other well known cloud providers", plus reselling of those providers' cloud resources. https://almazcloud.network/

This is a meaningful claim precisely because it is falsifiable. A 10G physical cross-connect to Yandex's or Rostelecom's fabric implies either a bilateral peering session or a route exchange visible in BGP data. If AS210328 sold physical peering to those networks, independent route collectors would eventually observe session evidence: shared IXP records, AS-path adjacency, or the counterparties' own listings. The claim is dated, priced and specific — everything a routing record needs to test it.

What the routing record shows

Hurricane Electric's ASN page attributes AS210328 to AO ALMAZ and reports three IPv4 prefixes originated, two announced, two RPKI-originated-valid, no IPv6, 512 IPv4 addresses originated, 717 IPv4 AS paths observed, and an average AS path length of 5.319. The observed peers are AS202425 (IPV), AS201814 (MEVSPACE sp. z o.o.) and AS48693 (Rices Privately owned enterprise) — all upstream/transit-type relationships. https://bgp.he.net/AS210328 ping.pe independently lists the same three prefixes under origin "ALMAZ - AO ALMAZ" with RPKI status VALID for 77.91.65.0/24 and 185.136.15.0/24 and NOT-FOUND for 185.218.138.0/24. https://records.ping.pe/210328

The prefix descriptions on the Hurricane Electric page are themselves informative: 77.91.65.0/24 is labelled IP-FI-FotonTel, while 185.136.15.0/24 and 185.218.138.0/24 are labelled Vlad Cojuhari — a person who is not the origin AS's registrant. https://bgp.he.net/AS210328 A network selling its own datacenter connectivity would typically announce space under its own administrative control. Announcing prefixes whose descriptive registrant is a third party is a signature of an announcement service — which, notably, is exactly one of the products almazcloud.network sells. https://almazcloud.network/

Against the peering promise, the observable topology is unambiguous so far as these collectors reach: three upstreams, zero observed peers, zero downstreams, and no adjacency to Yandex, Sberbank or Rostelecom in the collected paths. https://bgp.he.net/AS210328 https://records.ping.pe/210328 Route-collector "peers" are inferred relationships rather than contractual ones, so the absence is not a legal finding; but it does mean no independent BGP observation corroborates the physical cross-connect claim to date.

The RPKI split and the revoked competitor

The RPKI record is the strongest independent evidence in the file. The rpki-client console lists exactly two ROAs for AS210328 — 77.91.65.0/24 maxlen 24 and 185.136.15.0/24 maxlen 24, both from the RIPE repository — and no ROA for the third prefix. https://console.rpki-client.org/AS210328.html That matches the VALID/VALID/NOT-FOUND statuses on ping.pe and the "2 RPKI valid" count on bgp.he.net, three sources agreeing on the split. https://records.ping.pe/210328 https://bgp.he.net/AS210328

The third prefix has its own story. A ROA covering 185.218.138.0/24 (maxlen 24) was issued to asID 205997 — a different autonomous system — and it failed validation because its certificate was revoked on Monday 24 August 2026, having been valid from 2026-02-18 to 2026-07-01 nominal dates per the object. http://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/03/913a3a-f550-46f0-acc7-cd3ca5975712/1/d_jfHKcWqSUAsdXVXLjJb7Gc6bo.roa.html Prior BTW coverage recorded the prefix in a multi-origin (MOAS) state across AS209630, AS205997 and AS210328, with the prefix registrant Vlad Cojuhari differing from the origin AS registrant AO ALMAZ. https://btw.media/zh/almazcloud-network-as210328-briefing So in late August 2026 the competing ROA was revoked, AS210328 holds no ROA over it, and yet the prefix continues to be observed under AS210328's origin. A prefix announced without any covering ROA is exactly the configuration RPKI-rejecting networks filter. Whatever service depends on 185.218.138.0/24 reaching route-strict consumers is reachable only through networks that do not enforce.

The August sequence

Two dated events sit within three days of each other. On 2026-08-21T04:38:32Z, the RIPE aut-num's routing policy was rewritten to import from AS48693 and export to AS210328 — consolidating the visible upstream relationship into the paperwork. https://ipgeolocation.io/browse/asn/AS210328 On 2026-08-24, the asID 205997 ROA over the MOAS prefix was revoked at the certificate layer. http://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/03/913a3a-f550-46f0-acc7-cd3ca5975712/1/d_jfHKcWqSUAsdXVXLjJb7Gc6bo.roa.html The coincidence is worth flagging, not interpreting: a registry-side policy change and an RPKI-side revocation both landing in the same week may reflect routine housekeeping, a dispute resolution, or an upstream migration. The record does not say. What it does say is that the operator's documented routing posture has been actively revised recently, which is inconsistent with the "Inactive" classification other sources assign.

The mirror problem

Anyone researching AS210328 from search results encounters sources that contradict each other, and the disagreements are not subtle. IPTrace's ASN detail page still shows the 2021 aut-num with import/export toward AS12695, an update date of 2021-12-28, and zero prefixes and zero peering networks — conflicting with the current RIPE object's AS48693 policy and with every aggregate observatory's two-to-three prefix count. https://iptrace.net/en/as/210328 IPinfo classifies the ASN as Inactive with zero prefixes, again against the aggregate evidence. https://btw.media/zh/almazcloud-network-as210328-briefing Meanwhile PeeringDB's own prefix counters read 0/0, last touched 2022. https://www.peeringdb.com/net/19111

Three independent classes of sources — a registry mirror, a commercial geolocation/classification provider, and the PeeringDB self-report — each describe a network that does not, as of September 2026, exist as they describe it. The observation-window problem is general in this space: most of the usable snapshots here were retrieved on 2026-09-19 with unknown crawl windows, so every count in this article is a dated observation, not a live query result.

The evidence boundary

Prior BTW analysis of this subject laid out the layer problem: registration, routing, DNS, website and certificate layers each answer different questions, and none alone proves a cloud service in operation; equally, a thin observable footprint does not prove a network is inactive or a service does not exist. https://btw.media/en/almazcloud-network-evidence-boundary This report adopts that boundary. What the record shows as of the September 2026 snapshot:

The unanswered question remains the one that has hung over this subject since BTW first catalogued its public checks: is there any independent evidence of a delivered cloud service? The August revisions show administrative activity. The routing record shows announcements and upstream transit. Nothing in the public record yet shows a workload.