Summary

  • The live RIPE aut-num for AS210328 was last modified on 21 August 2026, switching its routing policy to a single peer, AS48693, while the organisation object ORG-ZA238-RIPE (AO ALMAZ, RU, registration number 1196501003357) was last touched on 13 May 2026 (IPIP WHOIS mirror).
  • Three IPv4 prefixes are originated under the AS; routing observers report two announced, two RPKI-origin-valid, zero IPv6, 512 originated IPv4 addresses and 717 observed AS paths, with peers AS202425, AS201814 and AS48693 (Hurricane Electric BGP toolkit).
  • The third prefix, 185.218.138.0/24, is a multi-origin AS announced by three networks and has no valid ROA for AS210328; the only known ROA covering it belonged to another holder whose certificate was reportedly revoked on 24 August 2026 — a timestamp reported second-hand and never directly verified from the primary ROA object (ping.pe; BTW revocation-sequence note).
  • Third-party mirrors remain frozen in different years: an IPTrace variant still embeds a 2021-era object naming a different upstream, while PeeringDB record 19111 self-reports zero prefixes, contradicting the three visible in live routing (IPTrace; PeeringDB).
  • The operator's site sells direct physical peering to Yandex, Sberbank and Rostelecom from $499 per month; no independent routing observation in the current record corroborates that topology (almazcloud.network).

A network that is easier to observe than to identify

Every network carries two identities. One lives in the routing system, where anyone with looking glasses and route collectors can measure what is actually announced. The other lives in registry records, where a legal organisation, a registration number and a country are written down once and then copied — with varying fidelity — across a dozen commercial databases. AS210328 is a compact case study in what happens when the routing layer is small enough to verify end to end, but the institutional layer never closes.

The registration chain is documented. The aut-num object AS210328, named ALMAZ, belongs to organisation ORG-ZA238-RIPE — AO ALMAZ, country RU, org-type OTHER, registration number 1196501003357 — with status ASSIGNED, created on 27 December 2021 and last modified on 21 August 2026, importing from and exporting to AS48693 and sponsored by ORG-DNJ1-RIPE (IPIP WHOIS mirror). The organisation object itself was created on 21 December 2021 and last modified on 13 May 2026, with an abuse contact role object ZAN42-RIPE, named "almazcloud.network", holding an abuse mailbox on the almazcloud.network domain (IPIP WHOIS mirror). IPGeolocation's mirror independently confirms the 27 December 2021 allocation date, the ASSIGNED status, the RIPE registry source and the same May and August 2026 modification timestamps (IPGeolocation).

What that registration number resolves to in Russian corporate records has already been examined in BTW's identity-verification investigation, which found that third-party registry aggregators describe the number as belonging to a two-employee marine fish-farming operation in Sakhalin rather than a Moscow cloud operator. That finding is not repeated here as new evidence; the point for this execution check is narrower — as of 30 September 2026, nothing in the RIPE record itself closes that gap, and the objects continue to be maintained under the ALMAZ-MNT and RIPE-NCC-END-MNT maintainers.

The routing footprint, as it stands

The observable routing layer is modest and internally consistent across the best-quality observers. Hurricane Electric's toolkit attributes AS210328 to AO ALMAZ in the Russian Federation and reports three IPv4 prefixes originated, two announced, two RPKI-originated-valid, zero IPv6, 512 originated IPv4 addresses and 717 observed AS paths with an average path length of 5.319. Its listed peers are AS202425 (IPV), AS201814 (MEVSPACE sp. z o.o.) and AS48693 (Rices Privately owned enterprise) (Hurricane Electric). IPGeolocation's mirror shows the same three routes, zero IPv6 routes, and the same per-prefix registrant attributions: 77.91.65.0/24 under Foton Telecom CJSC, and 185.136.15.0/24 and 185.218.138.0/24 under Vlad Cojuhari (IPGeolocation).

That last detail matters. The prefixes this AS announces are registered in the RIPE inetnum hierarchy to different legal parties than the origin AS itself — a structure that is not inherently improper, since prefix sponsorship and AS registration are separate chains, but which means a dispute over any one prefix has three parties to reconcile: the AS registrant, the prefix registrant and whoever actually holds the ROA. On the current record, no party has published an explanation of that structure.

RPKI: two valid, one contested, and a second-hand timestamp

ping.pe's live status table reports RPKI VALID for 77.91.65.0/24 and 185.136.15.0/24 under origin AS210328, and NOT-FOUND for 185.218.138.0/24 (ping.pe). Secondary reports citing the rpki-client validation console describe exactly two ROA payloads published for asID 210328 in the RIPE repository — 77.91.65.0/24 and 185.136.15.0/24, both with maxlen 24 — and none for 185.218.138.0/24 (rpki-client console, as reported). A methodological caveat is required: those console pages were not directly retrieved during this research, so the two-ROA description is second-hand and is stated here as such; the primary console is the right place for any reader to verify it directly.

For 185.218.138.0/24, the known history is more tangled. The only ROA ever covering it, per the same secondary reporting, was issued to asID 205997 with a nominal validity window beginning 18 February 2026, and its certificate was reportedly revoked on 24 August 2026 at 05:53:28 UTC — a timestamp BTW's own prior reporting has labelled unconfirmed, and which this research likewise could not verify from the primary object (ROA object page, as reported; BTW revocation-sequence note). The prefix is a multi-origin AS (MOAS), announced simultaneously by AS209630 (LLC VASH KREDIT BANK), AS205997 and AS210328. Whatever the administrative explanation, the routing-security outcome is unambiguous: a prefix with three origins and no valid ROA for any of them today will be rejected by RPKI-enforcing peers regardless of which origin announces it.

The August 2026 acquisition window — a new ROA for the second prefix issued on 20 August 2026, roughly four and a half years after the AS allocation, and the aut-num rewrite one day later — has been reconstructed in detail from certificate timestamps in BTW's earlier reporting (BTW acquisition-window story). The current check confirms that posture has not moved since: the live objects still carry the 21 August modification, and the contested prefix still lacks ROA protection for this AS.

Four mirrors, four years

If the live record is comparatively tidy, the databases a buyer actually consults are not. PeeringDB record 19111 registers ALMAZCLOUD / AO ALMAZ under the long name "ALMAZ (DIAMOND) CLOUD NETWORK", type NSP, with three Moscow facilities (Berzarina Data Center, IXcellerate MOS1, Moscow M9), 10–20 Gbps of balanced traffic — and, remarkably, a self-reported count of zero IPv4 and zero IPv6 prefixes. The record was last updated on 27 July 2022, with its RIR-status check refreshed on 26 June 2024; the zero-prefix self-report directly contradicts the three originated prefixes visible in live routing (PeeringDB).

An IPTrace variant for the same ASN embeds an even older object: as-name ALMAZCLOUD, an import from and export to AS12695, and a last-modified stamp of 28 December 2021 — before the August 2026 policy change to AS48693 ever happened. Another variant of the same page reportedly shows the newer policy and a "50% RPKI valid rate" with "2 IPv4 Prefixes", a count matching neither HE's three-originated/two-announced picture nor the live objects (IPTrace). Robtex, for completeness, labels the AS as ALMAZCLOUD with the almazcloud.network description and the same org handle — a short, low-weight echo of the registry data (Robtex).

The practical consequence is that a procurement engineer checking any single source can conclude the network does not exist (inactive mirrors), has two prefixes (IPTrace variant), has three prefixes but no upstream diversity (HE), or self-reports no prefixes at all (PeeringDB). None of these is a malicious fabrication; each is a snapshot at a different decay stage. But a purchase decision — a $99-per-month BGP announcement, a $499 cloud-connect port — would rest on whichever one the engineer happened to open. RIPE's own data API publishes RPKI validation state as the authoritative, timestamped layer (RIPEstat RPKI validation endpoint documentation), yet the commercial mirrors closest to buyers are the slowest to refresh.

What the marketing says the record does not

The operator's own site is the most confident document in the set. It markets CLOUD CONNECT from $499 per month per 10G physical port with a claimed "direct physical peering connection to Yandex, Sberbank, ROSTELECOM" and other large providers; BGP ANNOUNCEMENTS from $99 per month per announced prefix; a NO-BGP GRE TUNNEL product from $99 per month per 100 Mbps; CORPORATE CLOUD VPN from $9 per month per user; and CLOUD RESELLING from $99 per month (almazcloud.network).

Against the observed topology, the gap is stark. The live record shows a network with a single documented registry peer (AS48693), three observed BGP peers overall, and no indication of an exchange-point or facility peering session with Yandex, Sberbank or Rostelecom (Hurricane Electric). A customer buying the CLOUD CONNECT product on the strength of that claim is buying something the public record cannot corroborate. BTW's claim-by-claim corroboration ledger reached the same reconciliation against the 29 September snapshot (BTW claim ledger); the current check finds the ledger unchanged a day later. A companion briefing on the same network's mirror divergence also remains part of the public record (BTW briefing).

What remains genuinely unresolved

Three things this report cannot settle, stated plainly. First, whether the registration number 1196501003357's Sakhalin attribution reflects a data error, an unrefreshed aggregator record or something more consequential — that question requires Russian corporate registry primaries, not routing evidence. Second, the exact operational relationship between the three parties on 185.218.138.0/24, including why a prefix registered to Vlad Cojuhari is announced by a bank's AS, a third operator's AS and AO ALMAZ's AS simultaneously.

Third, the revocation timestamp of 24 August 2026, which remains second-hand until someone reads the primary ROA object directly. Everything else in this report — the registry chain, the routing counts, the RPKI status split, the mirror staleness — is verifiable today by any reader with a browser, and the links above point at exactly those verification points.