Summary

  • almazcloud.network, operating under the DIAMOND brand, sells five dollar-priced products — including Cloud Connect at $499 per month per 10G physical port and cloud reselling at $99 per month per connected cloud — built around a claim of direct physical peering to Yandex, Sberbank and Rostelecom that no independent routing source consulted for this report corroborates. almazcloud.network BTW: AS210328 identity chain
  • The autonomous system behind the brand, AS210328, originates 512 IPv4 addresses across three /24 blocks registered to third parties — Foton Telecom CJSC and Vlad Cojuhari — not to the operator's own RIPE organisation, AO ALMAZ. Hurricane Electric IPGeolocation
  • Its PeeringDB record self-reports zero prefixes while independent databases observe three, and its only formalized routing counterpart since a 21 August 2026 registry edit is AS48693, a small Ukrainian transit reseller. Hurricane Electric PeeringDB Robtex
  • The evidence pattern fits a brokerage model rather than an infrastructure operator — precisely the profile that AI-era demand for low-cost, loosely-attributed compute makes attractive to resellers and hazardous for buyers.

The gap between what a network sells and what a network shows is the oldest diagnostic in infrastructure analysis. Usually the gap is small: a hosting company advertises dedicated servers, and the routing table confirms address space under its own name, upstreams under contract, and a peering presence at the facilities it names. When the gap is wide, it is not automatically fraud — it is a signal that the commercial layer and the infrastructure layer are different businesses, and that the buyer is being asked to underwrite the difference.

The operator behind almazcloud.network sits at the wide end of that gap. Its website markets five products in dollars: Cloud Connect from $499 per month per 10G physical port, BGP announcements from $99 per month per announced prefix, a "NO-BGP" GRE tunnel service from $99 per month per 100 Mbps, a corporate cloud VPN from $9 per user per month, and cloud reselling from $99 per month per connected cloud. almazcloud.network The catalogue's centrepiece is a claim of "direct physical peering connection" to Yandex, Sberbank, ROSTELECOM and "some other well known cloud providers," with resale of those providers' resources offered through CLI and REST API access. almazcloud.network

What the measurement layer shows is a different organism. Hurricane Electric attributes AS210328 to AO ALMAZ with the almazcloud.network website, and records three originated IPv4 prefixes totalling 512 addresses: 77.91.65.0/24 (registered to Foton Telecom CJSC), 185.136.15.0/24 and 185.218.138.0/24 (both registered to Vlad Cojuhari). Hurricane Electric Two of the three prefixes have valid RPKI originations; the third, 185.218.138.0/24, has been announced under three different origin ASNs — AS209630, AS205997 and AS210328 — and the only ROA that covered it, issued to AS205997, was revoked on 24 August 2026. BTW: mirror divergence

The ownership mismatch is the first structural finding. The address space a cloud vendor needs to demonstrate that it runs infrastructure — prefixes under its own organisation's name — does not exist here. All 512 addresses belong to other parties' registrations. A reseller can operate this way legitimately; a self-described physical-interconnect provider cannot, because the interconnect claim depends on capacity and presence the routing record cannot attribute to it.

The dependency structure is the second finding. The current RIPE aut-num, last modified on 21 August 2026, names exactly one routing counterpart: AS48693, a small Ukrainian transit reseller. Hurricane Electric An older revision of the same object, preserved by Robtex and last modified 28 December 2021, named AS12695 instead — the network operated by the sponsoring LIR organisation, ORG-DNJ1-RIPE. Robtex BTW's prior coverage established this dependency layer in detail: the sponsoring LIR runs a different ASN, and the August 2026 edit swapped the network's single formalized upstream without changing its sponsor. BTW: AS210328 identity chain BTW: mirror divergence

The self-description is the third finding. PeeringDB record 19111 describes ALMAZ (DIAMOND) CLOUD NETWORK as an NSP with 10–20 Gbps of traffic and a restrictive peering policy — and self-reports zero IPv4 and zero IPv6 prefixes. PeeringDB The record was last updated on 27 July 2022, before the current product catalogue existed, and lists three Moscow facilities: Berzarina Data Center, IXcellerate MOS1 and Moscow M9. PeeringDB Aggregators diverge further: IPTrace counts two IPv4 prefixes and a 50% RPKI validity rate; IPGeolocation counts three routes. IPTrace IPGeolocation Four databases, four versions of the same network. BTW: mirror divergence

Now the AI-era question. Demand for compute has outstripped supply of verifiable compute. Buyers — model trainers, inference providers, resellers of GPU time — face list prices at hyperscalers measured in dollars per GPU-hour and lead times measured in quarters. Into that gap step intermediaries offering the same resources at a discount, with attribution loose enough that the buyer cannot easily tell a broker from an operator. almazcloud.network's catalogue is aimed squarely at this buyer: it does not sell its own servers; it sells connection to other people's clouds and the right to resell their resources.

There is nothing inherently illegitimate about brokerage. The problem is asymmetry of verification. A buyer of Cloud Connect at $499 per month is buying a claim about physical fibre in a Moscow facility. A buyer of cloud reselling is buying an account relationship with a third-party cloud, passed through. Neither claim is checkable from the outside using the signals that normally work — because the operator's routing footprint is too small to constrain any statement about it. A 512-address, transit-only network with one formalized peer can be made to sound like anything; the routing table certifies only that it exists.

The buyer-relevant conclusion is therefore procedural, not accusatory. Before purchasing from an operator in this profile — small footprint, third-party prefixes, stale self-reports, single upstream, unverifiable interconnect claims — a buyer should demand the documents that close the chain: a LoA naming the exact prefixes and facilities, a colocation or cross-connect order reference, RPKI ROAs under the operator's own ASN, and a contractual liability path that does not end at an admin@ mailbox. IPGeolocation The routing table cannot vouch for almazcloud.network; that is a fact about verification, not an allegation about conduct.