Summary

  • almazcloud.network's operator AO ALMAZ markets five products on its own site: Cloud Connect from $499/month per 10G physical port, BGP Announcements from $99/month per announced prefix, NO-BGP GRE Tunnels from $99/month per 100Mbps, Corporate Cloud VPN from $9/month per user, and Cloud Reselling from $99/month per connected cloud. The site claims "direct physical peering connection to Yandex, Sberbank, ROSTELECOM, Selected and some other well known cloud providers." [1]
  • Independent routing observations show AS210328 originating three IPv4 prefixes (77.91.65.0/24, 185.136.15.0/24, 185.218.138.0/24), two announced with RPKI-valid ROAs and one (185.218.138.0/24) with RPKI state NOT-FOUND. [3][4]
  • Every routing source consulted agrees AS210328 is transit-only: three upstreams (AS202425 IP Volume inc, AS201814 MEVSPACE, AS48693 Rices), zero observed peers and zero observed downstreams. [3][5][7]
  • The current RIPE aut-num, last modified 2026-08-21, names only AS48693 in its import/export policy — none of the three transit providers and none of the three cloud brands the vendor advertises. [2][10]
  • PeeringDB record 19111 has listed zero registered prefixes since its last update on 2022-07-27, three Moscow colocation facilities, and a "Restrictive" peering policy; it contains no evidence of the advertised interconnects. [6]
  • No independent source consulted corroborates a physical interconnect to Yandex, Sberbank or Rostelecom. The claim is self-declared marketing; the observable record neither proves nor fully disproves it, but the load-bearing evidence a buyer would want is absent.

The Product Catalog Exists Only in One Place

The commercial layer of this story lives entirely on the operator's own landing page. AO ALMAZ presents itself as "DIAMOND (on rus.

ALMAZ)," a cloud services provider, and lists five products with starting prices: BGP Announcements at $99 per month per announced prefix, described as announcing a customer's AS or prefix to its uplink providers for global routability; Cloud Connect at $499 per month per 10G physical port, with the direct peering claim to Yandex, Sberbank, Rostelecom and others; a NO-BGP GRE Tunnel product at $99 per month per 100Mbps, using IPsec GRE to announce customer prefixes from AlmazCloud hardware; Corporate Cloud VPN at $9 per month per user; and Cloud Reselling at $99 per month per connected cloud. [1]

Every commercial claim in this report traces back to that single page. No price list appears in any registry object. No interconnect appears in any routing observation. That asymmetry — a rich vendor catalog on one side, a sparse but independently generated routing record on the other — is the analytical spine of what follows.

What the Routing Record Independently Shows

Three independent aggregators agree on the core counts.

Hurricane Electric reports AS210328 originating three IPv4 prefixes and announcing two, with two RPKI-origin-valid, three BGP neighbors observed, and 512 originated IPv4 addresses; it also carries the heuristic flag "AS210328 announces bogons." [3] The ping.pe BGP records identify the prefixes precisely — 77.91.65.0/24 VALID, 185.136.15.0/24 VALID, 185.218.138.0/24 NOT-FOUND — all originated as "ALMAZ - AO ALMAZ." [4] Hurricane Electric attributes the 77.91.65.0/24 registration to IP-FI-FotonTel and the two 185.x prefixes to an individual named Vlad Cojuhari, descriptions that sit oddly with the cloud-brand positioning.

[3]

The topology is where the commercial claims meet friction. ping.pe's peer listing shows three upstreams — AS202425 (IP Volume inc, Seychelles), AS201814 (MEVSPACE sp. z o.o., Poland), and AS48693 (Rices Privately owned enterprise, Ukraine) — and explicitly reports "No peers were returned for AS210328" and "No downstreams were returned for AS210328." Notably, the AS48693 path was observed only once, versus 290 observations for AS202425 and 267 for AS201814.

[5] IPregistry independently states that AS210328 "does not have any direct peering agreements," reaches the Internet via transit, and "currently has no downstream networks, meaning it does not serve as a transit provider to customer networks." [7]

Why Zero Downstreams Matters for a BGP-Announcement Business

A company selling BGP announcement services would ordinarily leave a visible footprint: customer prefixes announced as downstreams, or at minimum route objects binding customer space to the provider AS. Neither appears in the data consulted. The vendor's own product design explains part of this: the GRE tunnel product announces customer prefixes "on our hardware," which would surface as AS210328-originated space rather than routed downstream ASes, and the BGP-announcement product routes customer space "over our network" to its own uplinks.

[1] In other words, the business model as described could operate with zero observed downstreams. But that same design means an independent observer cannot distinguish a functioning customer base from an empty one — the architecture is observationally opaque by construction.

The peering claim is different in kind. "Direct physical peering connection to Yandex, Sberbank, ROSTELECOM" is a checkable assertion. If those interconnects existed and carried routes, one would expect observed peering sessions with networks in those corporate families. Zero observed peers across collectors, combined with an IPregistry record of no direct peering agreements, does not prove the cables are absent — private interconnects carrying only customer traffic can be invisible to route collectors — but it removes every form of corroboration a technically literate buyer could demand before paying $499 per month for the port.

[5][7]

The Registry Record Has Been Rewritten

The RIPE aut-num for AS210328 was created 2021-12-27 and last modified 2026-08-21T04:38:32Z. The current version carries as-name ALMAZ, organisation ORG-ZA238-RIPE (AO ALMAZ, Russian registration number 1196501003357, org-type OTHER), and an import/export policy naming exactly one routing partner: "import: from AS48693 accept ANY" and "export: to AS48693 announce AS210328." [2][10] Older mirror copies show a materially different object: as-name ALMAZCLOUD, a description referencing the website, and import/export referencing AS12695 (CJSC Digital Network), last modified 2021-12-28.

[9] At least two distinct versions of the same object circulate in third-party mirrors, which means any due-diligence based on cached registry data can return a policy that has since been abandoned.

None of the policy partners in either version — AS48693 currently, AS12695 historically — is Yandex, Sberbank, Rostelecom or their known ASN families. The authoritative RIPE lookup itself was not directly retrievable during this research; the field values quoted here come from RIPE-object mirrors and should be re-verified at the RIPE Database query page before any purchasing decision. [2]

PeeringDB: A Stale Directory, Not a Verdict

PeeringDB record 19111 lists the network as "ALMAZCLOUD," long name "ALMAZ (DIAMOND) CLOUD NETWORK," network type NSP, traffic level 10-20Gbps, a "Restrictive" general policy, "Never via route servers," and three Moscow facilities: Berzarina Data Center, IXcellerate MOS1 and Moscow M9. It registers zero IPv4 and zero IPv6 prefixes and was last updated 2022-07-27. [6] The zero-prefix count contradicts observed routing, confirming the profile is stale. The facility list is more interesting by contrast with IPTrace, which shows the same three facilities and notes co-tenants including Cloudflare, MegaFon, RETN, Selectel, Digital Network (AS12695) and PITER-IX route servers. [9] Colocation in the same buildings as major networks is a genuine capability signal — it means physical interconnection is possible — but it is not evidence that any specific interconnect exists.

What a Buyer Can and Cannot Verify

For a potential customer of the BGP-announcement or GRE products, the verifiable facts are: the AS is live and announces space through three upstreams; two of three prefixes carry valid ROAs; the third is unprotected and also appears in MOAS contexts per the prior briefing on this network; and the registry object was materially rewritten as recently as August 2026. For the Cloud Connect product, the verifiable facts are thinner: three Moscow colocation facilities are on record, and nothing else. The named-brand peering claim rests entirely on the vendor's say-so. [1][4][5][6]

IPinfo offers a useful caution about how much ASN metadata can diverge: it reports no peers, no upstreams, no downstreams and no pingable IPs for AS210328, directly contradicting every other source on upstreams. [8] With one collector seeing nothing and others seeing three upstreams, source disagreement itself becomes a finding: for small networks, "independent verification" means triangulating several collectors, not trusting one.

The Boundary of This Report

Nothing here establishes fraud, service failure, or satisfied customers. The routing record cannot see inside a GRE tunnel or a private interconnect. What it can do is price the evidence: the parts of AlmazCloud's story that are independently observable — prefix origination, RPKI status, transit relationships — check out and are consistent with a small live network. The parts that differentiate the product — brand-name physical peering and an implied interconnection footprint — have no observable support in any source consulted as of 26 September 2026. A buyer, a peering coordinator or a risk analyst should treat that gap as the finding.

Sources

  1. https://almazcloud.network/
  2. https://apps.db.ripe.net/db-web-ui/query?searchtext=AS210328
  3. https://bgp.he.net/AS210328
  4. https://records.ping.pe/210328
  5. https://records.ping.pe/peers/AS210328
  6. https://www.peeringdb.com/net/19111
  7. https://ipregistry.co/AS210328
  8. https://ipinfo.io/AS210328
  9. https://iptrace.net/en/as/210328
  10. https://whois.ipip.net/AS210328
  11. https://ipgeolocation.io/browse/asn/AS210328
  12. https://docs.db.ripe.net/removal-of-personal-data/
  13. https://labs.ripe.net/author/kranjbar/proposed-improvements-to-dummification-of-personal-data-in-the-ripe-database/
  14. https://radar.qrator.net/as-set/AS-ALMAZCLOUD-NETWORK
  15. https://btw.media/en/almazclouds-as210328-registration-versus-real-network-operation
  16. https://yandex.cloud/en/docs/interconnect/pricing
  17. https://btw.media/en/directory/almazcloud-network