Summary

  • The operator behind almazcloud.network brands itself DIAMOND and sells five dollar-priced products, including Cloud Connect from 499 USD/month per physical 10G port, advertising direct physical peering to Yandex, Sberbank and Rostelecom (DIAMOND storefront).
  • Every observable fact about its autonomous system AS210328 describes a much smaller network: roughly 512 originated IPv4 addresses across three /24 prefixes, three observed transit neighbours, no observed peers or downstreams (Hurricane Electric BGP toolkit; ping.pe AS210328).
  • The divergence is not one mismatch but a pattern: storefront versus routing, self-report versus measurement, modelled traffic versus observed behaviour, contact posture versus registry activity, and a two-employee corporate anchor versus an enterprise product catalog.
  • Each individual inconsistency has been documented before. What has not been tested is whether the operator's self-presentation holds together as a single identity claim. It does not.

An operator's identity is not one claim. It is a stack: a legal entity, a registry footprint, a routing behaviour, a self-reported operator profile, and a commercial storefront. When those layers agree, a buyer, a peer or an abuse-desk analyst can reason about who they are dealing with. When they diverge, the divergence itself becomes the finding — not because divergence is proof of anything in particular, but because each layer is independently verifiable, and the gaps between them can be measured precisely.

This report runs that test against almazcloud.network, the DIAMOND-branded cloud operator whose network is RIPE autonomous system AS210328, registered to an organisation named AO ALMAZ. Prior BTW reporting has measured this network's footprint, documented the delivery gap between what it sells and what runs on its own address space, separated its registry clock from its market clock, and read the contents of its 2026 registry edits. What none of that reporting directly asked is the question a careful buyer would ask first: does the operator's own self-description cohere with the same public sources' observations about its network?

The answer, assembled from eighteen public sources retrieved on 2026-10-05, is a systematic no — and the shape of the disagreement is more informative than any single number.

The storefront claim

Start with what the operator says about itself. The almazcloud.network homepage brands the operation 'DIAMOND (on rus. ALMAZ)' and describes it as a 'brand new progressive cloud services provider'. The catalog lists five products: 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 100Mbps; a Corporate Cloud VPN from 9 USD per month per user; and Cloud Reselling from 99 USD per month per connected cloud, with claimed all-in-one CLI and REST API ordering interfaces (DIAMOND storefront).

The flagship product is Cloud Connect, which advertises a 'Direct physical peering connection to Yandex, Sberbank, ROSTELECOM, Selected and some other well known cloud providers' (DIAMOND storefront). This is a specific, checkable claim: not 'we can route you to Yandex', but a physical interconnection to named networks, three of the largest in Russia.

The storefront also publishes role-based contact mailboxes, including a director-level address, but no capacity figures, facility list, service-level agreement, customer count or traffic statistics (DIAMOND storefront).

So the commercial self-description is specific about prices, named counterparties and contact channels, and silent about capacity, infrastructure and customers. That asymmetry is the first thread.

What the routing table says

AS210328, as observed by Hurricane Electric's BGP toolkit, is attributed to AO ALMAZ in the Russian Federation with almazcloud.network as the company website. It originates three IPv4 prefixes, announces two, originates zero IPv6 prefixes, and carries 512 originated IPv4 addresses. Its observed BGP neighbours number exactly three: AS202425 (IPV), AS201814 (MEVSPACE sp. z o.o.) and AS48693 (Rices Privately owned enterprise) — all transit relationships, with no peers or downstreams shown (Hurricane Electric BGP toolkit). ping.pe independently lists three prefixes under the AS origin — 77.91.65.0/24 (RPKI VALID), 185.136.15.0/24 (RPKI VALID) and 185.218.138.0/24 (RPKI NOT-FOUND) — and related records report no peers and no downstreams for the AS (ping.pe AS210328).

The first coherence failure is therefore direct: a product priced at 499 USD per month for a 'direct physical peering connection' to Yandex, Sberbank and Rostelecom sits on an autonomous system where no peering session of any kind is observable. Every neighbour in the routing table is a transit upstream. The physical interconnection the storefront sells is not visible anywhere a buyer could check.

This is not new in isolation — the earlier BTW delivery-gap investigation documented that the operator's own services are not found on the address space it sells (BTW dependency layer; BTW identity chain). What the coherence audit adds is that the mismatch is not confined to the operator's own services. The peering promise fails against every observation source simultaneously, not just against one measurement.

The self-report layer

Operators also describe themselves in databases they control. PeeringDB record 19111, named 'ALMAZCLOUD' with the long name 'ALMAZ (DIAMOND) CLOUD NETWORK' and organization AO ALMAZ, self-reports zero IPv4 prefixes and zero IPv6 prefixes, network type NSP, traffic levels of 10-20Gbps, a balanced ratio, regional scope, a policy of 'Never via route servers', and Moscow facility presences including Berzarina Data Center and IXcellerate MOS1 (PeeringDB record 19111).

Set that self-report beside the observations. Hurricane Electric and ping.pe observe three originated prefixes and 512 IPv4 addresses (Hurricane Electric BGP toolkit; ping.pe AS210328). The self-reported 'zero prefixes' is not a rounding difference; it contradicts the routing table at the level of basic existence. The self-reported '10-20Gbps' traffic figure sits on a network whose average observed AS-path length is 5.319 across 717 observed paths, with exactly three transit neighbours (Hurricane Electric BGP toolkit) — a profile of a very small, very peripheral network, not a multi-gigabit hub.

Aggregator models compound the problem. IPTrace models AS210328 as an NSP with 'Traffic 10-20Gbps', 'Ratio Balanced', 'Peering Policy Restrictive', two IPv4 prefixes, zero IX points, three facilities, and a '50% RPKI Valid Rate' it describes as one valid and one invalid prefix of two sampled (IPTrace ASN detail). Its two-prefix count conflicts with ping.pe's three, and its 'invalid' verdict differs materially from ping.pe's NOT-FOUND — an RPKI state meaning a conflicting ROA exists, not that no ROA does. Meanwhile IPinfo classifies the same ASN as 'Inactive' with zero IPv4 addresses, zero IPv6 addresses and zero hosted domains, last updated 28 December 2021 — roughly four years stale, and contradicted by every other observation source (IPinfo AS210328).

The self-report ecosystem, in other words, disagrees with itself as well as with observation. A buyer consulting any single database would form a materially wrong picture in at least one direction: too big (the traffic models), too small (IPinfo's zero addresses), or structurally absent (PeeringDB's zero prefixes).

The registry layer

The RIPE registry record is the most consequential layer, because it is the authoritative statement of who holds the resource. The aut-num for AS210328 carries as-name ALMAZ, organisation ORG-ZA238-RIPE, status ASSIGNED, created 27 December 2021 and last-modified 21 August 2026. Since the August edit, its declared routing policy names exactly one counterpart: import 'from AS48693 accept ANY' and export 'to AS48693 announce AS210328' (IPIP.net RIPE mirror; Hurricane Electric BGP toolkit). The sponsoring organisation remains ORG-DNJ1-RIPE.

The organisation object ORG-ZA238-RIPE is 'AO ALMAZ', country RU, registration number 1196501003357, org-type OTHER, created 21 December 2021 and last-modified 13 May 2026, with its contact e-mail replaced by RIPE's redaction placeholder (IPIP.net RIPE mirror). Its maintainer-reference list names DN-MNT, FREENET-MNT and RETN-MNT — maintainer objects belonging to other operators. The abuse/role object ZAN42-RIPE is named 'almazcloud.network', states that replies are given only to emails written in Russian, and was last modified on 14 February 2022 (IPIP.net RIPE mirror).

RIPEstat's own portal, in a snapshot dated 30 September 2026 15:37:00, lists two prefixes with country attribution: 77.91.65.0/24 at 50% RU and 185.136.15.0/24 at 50% KZ (RIPEstat AS210328). The country split is itself notable: a nominally Russian cloud operator's originated space is half attributed to Kazakhstan, which sits oddly beside a marketing pitch aimed at buyers seeking Russian cloud connectivity.

Corporate-registry mirrors for INN 1196501003357 confirm the legal entity behind ORG-ZA238-RIPE (Checko; Audit-it; Tochka). Prior BTW reporting established that this entity is a two-employee mariculture micro-enterprise on Sakhalin (BTW identity chain).

Read together, the registry layer tells a coherent but narrow story: a small legal entity holding an AS number, whose routing policy is a single transit relationship, whose abuse contact has not been touched since February 2022, and whose organisation object was edited once in May 2026 — an edit prior reporting showed to be routine record maintenance with no change in routing behaviour (BTW August 2026 registry edit; BTW acquisition-window analysis).

The pattern, not the parts

Any single one of these facts has an innocent explanation. A stale PeeringDB record happens. Aggregator models are estimates. An abuse contact that answers only Russian is a policy choice. A small legal entity can host a large operation through contractors. Prior BTW coverage documented each of these individually, as separate findings.

The coherence audit's contribution is the joint observation. Five distinct divergences, each verifiable against independent sources, hold simultaneously across every layer of the identity chain:

First, the peering promise versus the routing table: a storefront selling physical interconnection to three named major networks, against an AS with zero observed peers or downstreams and a declared policy naming one transit upstream (DIAMOND storefront; Hurricane Electric BGP toolkit).

Second, the self-report versus measurement: PeeringDB's zero prefixes against three observed prefixes and 512 addresses (PeeringDB record 19111; ping.pe AS210328).

Third, modelled commerce versus observed behaviour: a 'Restrictive' peering policy and 10-20Gbps traffic model attached to a network with no peering sessions anywhere (IPTrace ASN detail).

Fourth, the contact posture: a storefront publishing a director mailbox and abuse-report addresses, against a registry abuse role untouched since February 2022 that answers only Russian-language mail (DIAMOND storefront; IPIP.net RIPE mirror).

Fifth, the corporate scale: an enterprise catalog with dollar-priced interconnect products, anchored to a two-employee Sakhalin mariculture entity (Checko; BTW identity chain).

What makes this a structural rather than incidental divergence is that the layers do not merely disagree — they disagree in a consistent direction. The self-presentation is always larger, more capable and more connected than the observation. Storefront above self-report, self-report above model, model above measurement: the identity inflates as you move away from the routing table and toward the sales page.

What the evidence can and cannot establish

Careful boundaries matter. None of the sources retrieved establishes fraud, misrepresentation in a legal sense, or the absence of any real service. The storefront wording and prices were captured as provider-reported excerpts, not verbatim page fetches, and should be re-verified against the live page before any consequential decision (DIAMOND storefront). Routing metrics are observation-window dependent and can change. IPinfo's 'Inactive' verdict is a documented freshness outlier, not a current fact (IPinfo AS210328). Hurricane Electric's flag that 'AS210328 announces bogons' is unexplained and could reflect collector artifacts (Hurricane Electric BGP toolkit). The IPIP pages are mirrors of RIPE data, not first-party reads of the authoritative database.

What the evidence does establish is a measurable, reproducible description of the divergence itself. A buyer, a prospective peer, or an abuse analyst does not need to resolve the operator's intentions to act: the observable record answers the operative question — what can be verified — with unusual clarity. Here, almost nothing in the commercial pitch is corroborated by anything outside the pitch. Two further third-party surfaces consulted in the retrieval window complete the comparison: the IPv6-AS name directory entry for Ao Almaz and IPregistry's AS210328 record.

Why this matters beyond one network

AS210328 is a small network, and its strangeness might justify a shrug if it were unusual. It is not. The information environment around small autonomous systems is structurally asymmetric: the operator writes the storefront and the self-reports; the observations are scattered across collectors with different windows, different coverage and different failure modes; and the aggregator models that fill the gaps are trained on, and perpetuate, the self-reports. The result is an identity chain where each layer's errors compound rather than cancel.

Prior BTW reporting on this operator documented the ledger-tended, market-frozen asymmetry — registry activity continuing through 2026 while the commercial surface and observable routing stayed static since 2022 (BTW ledger and storefront). The coherence audit closes the loop: the ledger activity did not update the self-reports either. PeeringDB still says zero prefixes; the abuse contact still says February 2022; the storefront still sells a peering product the routing table cannot show. The 2026 edits changed the registry's facts, not the operator's story.

For the buyer, the practical test is the one this report performed. Do not ask what the operator says about itself across its surfaces; ask what each layer's most independent source says, and check whether the layers agree. Where a self-description grows monotonically as it moves away from verifiable observation, the verifiable core is the thing worth pricing.