Summary

  • Intelion Cloud can be anchored to a Russian limited-liability company registered in March 2024, a detailed public service agreement and RIPE organisation records at the same Moscow address. The English Intelion Cloud LTD label is therefore connected to a real corporate and network surface, although each record still has its own purpose.
  • AS214186 was fully visible to RIPEstat's 326 IPv4 collectors on July 15, 2026, announcing two RPKI-valid /24s. This is meaningful operating evidence, but it is a compact IPv4 footprint with one observed neighbour, no observed IPv6 and address blocks registered to another organisation rather than proof of every infrastructure claim on the website.
  • Intelion publishes a credible automation story around self-service resources, OpenStack, virtual networking, metered compute and an AI support agent. The same terms reveal the controls that matter: a default-selected access key, customer-approved actions, one-gigabit VM limits, ticket-triggered downtime, scheduled backup options and balance-dependent retention.
  • Locality and support are service-specific. Russian compute locations do not keep every inference request in Russia, and public support wording ranges from round-the-clock to narrower contractual hours. A buyer needs a workload data map, a signed support matrix and current carrier evidence before treating the cloud name as operating assurance.

A cloud name is a bundle of promises

The easiest mistake in cloud due diligence is to ask whether a provider is real and stop when the answer becomes yes. A corporate record is found. A website takes payment. An autonomous system appears in a routing database. The box marked identity is checked, and all the other claims begin to borrow confidence from it.

Intelion Cloud is a useful case because the public record is strong enough to reward investigation and uneven enough to punish shortcuts. This is not a directory name with no product behind it. The company offers GPU servers, virtual infrastructure, dedicated machines and an inference service. It publishes legal terms in readable Markdown as well as PDF. It names technologies, network design choices, support channels, data locations and retention rules. Its autonomous system is currently announcing routes. There is enough material to understand how a customer relationship is supposed to work.

Yet the records do not collapse into one simple certificate of quality. The Russian company record establishes a legal counterparty. The website describes an ambitious service. The customer documents allocate rights and obligations. RIPE records show number-resource administration. Route collectors show which origins are visible at a given time. A product page describes support. None of these sources answers every question asked by the others.

That separation is not pedantry. It maps directly to failure. If a payment is disputed, the contracting entity and billing record matter. If a prefix disappears, the autonomous system, route authorisation and carrier escalation matter. If a model request contains regulated data, the selected processing region matters. If a stopped virtual machine is left unfunded, the retention clause matters. If a GPU fails outside office hours, the difference between facility monitoring and customer-facing technical support matters.

The right way to read Intelion Cloud is therefore as an operating system made from several public promises. Identity, automation, network reach, locality, support and recovery are separate modules. The provider has published more detail than many small infrastructure companies do. That is a positive signal because it gives a buyer something testable. It also creates an obligation to reconcile statements when the site, the contract and outside observation describe different edges of the same service.

The central judgment is not that Intelion Cloud has too little proof. It is that the available proof changes the buyer's job. The question is no longer whether there is a service behind the name. The question is whether the specific service a customer intends to buy is bounded tightly enough that every important promise can be assigned to a record, a control and an accountable responder.

The corporate anchor is young and specific

The Russian Federal Tax Service search returns one company for tax number 9703176519: OOO "Intelion Oblako", a Russian limited-liability company registered in Moscow on March 14, 2024. The result gives OGRN 1247700236519 and identifies Maksim Nikolaevich Vyaznikov as general director. Intelion's about page publishes the same tax and registration numbers, the same Moscow jurisdiction and a Presnenskaya Embankment address. It names Vyaznikov as chief executive and describes the company's main activity as data processing, hosting and related services.

That agreement between an official company search and the provider's own legal page is the cleanest identity anchor in the evidence. It connects the customer-facing brand to a legal entity capable of making a public offer, invoicing customers and receiving notices. The user agreement repeats the OGRN and tax number and says that account registration, funding or use accepts the offer. The public terms also define the control panel, account balance, electronic documents and channels for legal messages. These details make the commercial surface more legible than a brand page alone.

The network identity joins at a different point. RIPE registered organisation ORG-ICL71-RIPE in September 2024 under the name Intelion Cloud LTD and the same Moscow address. Five days later, AS214186 was registered with the name INTLMN and the Intelion organisation as registrant. The autonomous-system record was modified in February 2026, while the organisation record was changed again in May. The company website, RIPE organisation and autonomous-system record are therefore not merely old names that happen to resemble one another. They share a current address, brand and operational contact surface.

There are still useful limits. The company is young. The March 2024 registration date does not prove that every facility, employee or related activity began then, and it does not supply a long history of performance. The RIPE organisation uses the English LTD rendering while the contracting company is the Russian OOO "Intelion Oblako". A contact email in the RIPE organisation uses the intelionmine.ru domain, while the abuse role uses intelion.cloud. That pattern may reflect an administrative relationship or the company's history, but the records reviewed here do not define a corporate group or transfer liability from one brand to another.

A buyer should make the join explicit in the contract pack. The service order, invoice beneficiary, data-processing terms, abuse contact and network letter should all identify the legal entity and the role it is performing. If equipment, carrier agreements or support staff are supplied by affiliates or contractors, those responsibilities should be named. The public record supplies a credible starting point. It should not force a customer to infer the legal chain during an outage.

The about page also claims that Intelion is entered in Russia's hosting-provider register and gives accredited IT-company number 73678. Those are relevant regulatory clues, but the fixed evidence does not contain a company-specific government extract confirming every detail. The responsible conclusion is that Intelion publicly asserts those statuses and provides identifiers for verification. They should be checked in a procurement exercise, particularly when eligibility, data handling or tax treatment depends on them.

Corporate identity matters here because the service is not merely downloadable software. A customer is entrusting a company with physical accelerators, storage, network access, account funds and possibly model requests. The stronger the automation, the more consequential the legal anchor becomes. An account can provision capacity in minutes; a dispute about deleted data, failed service or a compromised access key will still move at the speed of contracts, evidence and people.

The product is more legible than the cloud label

Intelion's home page now makes a concrete offer. It advertises GPU servers in Russia, per-second charging, the ability to stop compute and stop paying for it, disk retention after shutdown, public IPv4, a gigabit connection and access through SSH, VNC or RDP. A user creates an account, funds a balance, launches a server and connects. The intended workloads include model training, image and video generation, computer vision, inference and speech processing.

The underlying documents broaden that surface. The user agreement covers dedicated servers, the Cloud Platform and related services. The Cloud Platform terms define virtual machines, virtual disks, isolated virtual networks, backups, database clusters, file storage, public addresses and projects. The dedicated-server terms describe provider-owned physical equipment assembled for the customer and normally supplied within 24 hours when capacity exists. The Inference Platform terms define an HTTPS API for large-language and other machine-learning models, with metered requests and explicit processing regions.

That is not one product. It is at least three operational bargains under one name.

The dedicated-server customer receives remote use of a physical machine and accepts hardware-specific constraints. The cloud customer creates logical resources on shared infrastructure and operates its own guest system. The inference customer sends a request to a model endpoint whose provider and processing region may sit outside Intelion's own facilities. The website can market all three as AI infrastructure, but their failure modes, evidence and data paths are different.

This distinction improves procurement. A buyer seeking an A100 for a short training run should ask about accelerator allocation, disk persistence, network cap, image provenance and recovery from host failure. A team buying a long-lived dedicated machine should focus on component replacement, remote hands, grace periods, spares and rebuild time. An application calling an inference endpoint should care about model version, request logging, region, external-provider dependency, rate limits and deprecation notice. The word cloud cannot do that analytical work.

The public inventory is also visibly dynamic. The H100 page said the card was unavailable on July 15 and pointed customers to an A100 alternative. That small fact is more useful than an evergreen claim of broad capacity. It reminds buyers that a product catalogue describes what a provider wants to offer, while an order describes what is actually reserved. For scarce accelerators, the due-diligence unit should be a dated configuration: model, memory, quantity, host topology, interconnect, storage class, region, availability date and substitution rights.

Intelion names OpenStack, OVN/Open vSwitch, PostgreSQL, Redis, Celery, NVMe and NUMA among the technologies behind its platform. That list is consistent with a modern self-service cloud control plane. It also needs to remain what it is: a first-party architecture clue. A technology logo does not establish the deployed version, patch state, tenant isolation, storage durability or operational competence. Those questions require configuration evidence and tests.

What the public product record does establish is a boundary substantial enough to examine. Customers are not simply being asked to trust a name. They can see the intended resource model, network limits, billing basis, support channel, retention rules and service remedies. The next step is to understand where automation changes the work rather than pretending it makes the work disappear.

Self-service moves labour into policy and exceptions

The attractive part of Intelion's offer is speed. A customer selects resources, funds an account and creates a machine through the control panel. The terms say service begins when a resource is created inside a project and sufficient funds exist. Customers choose virtual machines, disks and networks, adjust quotas and operate guest systems remotely. Billing records are generated from the provider's measurements of consumed services.

This is enterprise automation in a recognisable form. A sequence that once required a hardware request, a purchase order, a rack visit, an operating-system install and manual network configuration becomes a controlled transaction. The customer receives capacity when needed and releases it when the task ends. For bursty GPU work, that can change both cost and experimentation speed.

But the labour has not vanished. It has moved into policy design, capacity management, metering, account security, image maintenance, exception review and recovery. Someone must define project limits. Someone must decide which GPU substitutions are acceptable. Someone must investigate a billing mismatch. Someone must approve a port exception, restore a failed workload or explain why an advertised resource is unavailable. The platform is efficient when those responsibilities are explicit; it becomes opaque when the control panel is treated as the whole service.

Intelion's own documents reveal several examples. A host is described as connected at 10 Gbps, shared among the virtual machines running on it, while each VM is limited to 1 Gbps. The provider can reduce bandwidth or suspend service when use threatens shared infrastructure or other customers. Public ports are subject to permanent blocks, default closures and request-based exceptions. Account and project limits can be adjusted, but technical possibility and provider approval remain part of the process.

Those are reasonable multi-tenant controls. They are also where customer expectations meet operator discretion. An application may have a public IPv4 address and still be unable to use a particular protocol. A VM may have a one-gigabit ceiling while the marketing page describes a faster fabric inside the facility. A project may be able to request more addresses but not receive them instantly. A buyer should convert each relevant control into an operating rule before launch: who can request an exception, what evidence is needed, how long approval normally takes and what happens if the request is rejected.

Metering deserves the same treatment. Per-second charging is valuable only if the events that start, stop and preserve resources are well understood. The home page says stopping a server stops compute charges and keeps the disk free for 30 days. The July cloud terms provide the more complete state machine. If a VM has not run for 30 consecutive days, Intelion may remove the instance while retaining the disk and move it to metered cold storage after at least 24 hours' notice.

If the balance reaches zero in cold storage, the customer has 72 hours to fund the account before the provider may delete the disk and its data without another notice.

The simple sales message and detailed contract are not necessarily contradictory. Free stopped-disk storage can cover an initial period, followed by paid cold storage. But the difference is operationally important. A customer who hears only "stop and do not pay" may design an archive process that the terms do not support indefinitely. Automation has made the state transition easy; it has also made balance alerts, notification delivery and retention monitoring part of data protection.

The control plane should therefore be evaluated as a record system. Can a customer export resource history, usage events, configuration changes, support messages and billing measurements? Are timestamps consistent? Can an administrator distinguish a user action from a provider action? Is a stopped machine, a cold disk and a deleted resource represented clearly? Can alerts reach more than one responsible person? These are not decorative enterprise features. They determine whether the customer can reconstruct what happened after a disputed charge or lost workload.

Intelion has published enough mechanics to make those questions precise. That is an advantage. The buyer's task is to verify that the interface, contract and support practice use the same definitions.

AS214186 is small, current and real

The strongest evidence outside Intelion's own site is AS214186. RIPE assigned the autonomous system on September 16, 2024, under the name INTLMN and registered it to Intelion Cloud LTD. RIPEstat first observed a current origin route from it on October 15, 2024. On July 15, 2026, the system was announced and visible to all 326 IPv4 RIPE RIS peers included in the response.

The footprint was compact: two IPv4 /24s, 512 addresses in total. RIPEstat saw no IPv6 announcements and one neighbouring autonomous system. Both /24s had been present throughout the July 1-15 observation window. Secondary route summaries likewise reported two IPv4 prefixes, no IPv6 and one visible upstream, AS12389, PJSC Rostelecom.

These facts matter. A live autonomous system gives Intelion a public routing identity distinct from a reseller page sitting entirely behind another host's address space. Full collector visibility means the two origin routes were not obscure announcements seen at one edge. The first-seen date follows the ASN allocation by about a month, which is consistent with a new network being brought into operation. The record has also been maintained in 2026.

At the same time, the numbers set a boundary around the inference. Two /24s do not prove a geographically broad network, large capacity, diverse transit, low latency or many customers. One observed neighbour is a topology clue, not a complete carrier contract. No IPv6 announcement is a real current limitation in the public routing view, but it does not say whether IPv6 exists inside private networks or is planned. The route table can verify reachability at the origin layer. It cannot verify the GPU, storage or support behind an address.

The absence of a PeeringDB network profile for AS214186 adds little by itself. PeeringDB is voluntary. A small service can buy transit, use private connections and operate perfectly well without maintaining a public peering page. What the absence does mean is that a buyer cannot use that directory to cross-check facilities, exchange points, traffic scale or peering policy. The provider must supply current interconnection evidence directly if it matters to the service.

This is where scale should be read honestly. Intelion's public routing surface is not empty, dormant or merely registered. It is also not a vast internet backbone. It looks like the focused origin footprint of a young cloud operator: enough to advertise customer-facing IPv4 space under its own ASN, small enough that each prefix and external path matters. For an enterprise buyer, that concentration increases the value of exact route, carrier and recovery evidence.

Origin authorisation is not address ownership

Both current announcements have valid RPKI origin authorisations for AS214186. RIPEstat's validator found a valid route-origin authorisation for 194.67.95.0/24 and another for 185.182.108.0/24, each permitting AS214186 to originate the /24. This is one of the best details in the network record.

RPKI validity narrows a specific risk. Networks that perform route-origin validation can see that the registered authorisation agrees with Intelion's origin ASN and prefix length. That makes an accidental or unauthorised conflicting origin easier to reject. For a two-prefix network, keeping both authorisations valid is a practical operating control rather than a compliance ornament.

It does not answer every ownership question. The RIPE address records name RADIO-FSU/RADIO-MSU NETWORK Ltd as registrant for both ranges. Each record separately contains an Intelion reference: one names Intelion Cloud LTD and links the company site, while the other includes the domain. This is consistent with Intelion being authorised to use and announce address space registered to another organisation. It is not evidence that Intelion legally owns the blocks.

That distinction becomes important during renewal, abuse response or migration. The organisation that holds the address resource, the organisation authorised to originate it, the carrier accepting the route and the customer using an address can all be different. A valid route today does not by itself reveal how long Intelion can use the prefixes, who can change the route authorisation or what happens if the underlying arrangement ends.

A customer that depends on stable source addresses should ask for the service-specific chain: which prefix will be assigned, who is the registered holder, what agreement supports Intelion's use, who maintains the route-origin authorisation, whether the address can move between carriers and what notice applies if renumbering becomes necessary. For a short training job, this may be a minor concern. For allow-listed enterprise integrations, mail infrastructure or licensed software tied to an address, it can become a migration risk.

The positive conclusion remains meaningful. Intelion is not simply announcing unvalidated space and asking observers to accept the name. The two route-origin pairs were valid at capture. The careful conclusion is equally important: valid origin is evidence of authorised routing, not a deed to the address block and not a guarantee of the services reached through it.

Redundancy has to be reconciled one layer at a time

Intelion's website makes a specific resilience claim. It says a data centre near Samara uses physically separate MegaFon and Rostelecom internet lines and announces the provider's PI /24s over both, allowing traffic to move without an address change if one line fails. That is a much better statement than the usual promise of redundant connectivity because it identifies carriers, routing behaviour and the expected failure outcome.

The external record supports part of that story and leaves part open. The RIPE aut-num object declares import and export policy with AS12389, Rostelecom, and AS21446, SOTEL LLC. RIPEstat observed one neighbour on July 15. Secondary route summaries identified Rostelecom as the visible upstream. A March 2026 probe in Samara also reached Intelion's network through Rostelecom. The sources therefore agree on a current Rostelecom path. They do not show MegaFon as an observed neighbour in the captured global view, while the declared second network in the RIPE object is SOTEL rather than MegaFon.

This is a discrepancy to investigate, not a verdict. A carrier can supply a physical service through another autonomous system. A backup session may not be visible from every collector, may be configured but idle, or may have changed after a public record was written. A website can also simplify a wholesale arrangement into a retail carrier name. The frozen evidence cannot determine which explanation applies.

The buyer should resist two equally weak conclusions. One is that the dual-carrier claim must be false because one neighbour was observed. The other is that two names on a website prove independent end-to-end paths. BGP diversity, physical route diversity and commercial supplier diversity are different controls. Two sessions can share a duct, a router, a power feed or an upstream failure domain. One visible origin can still have a standby design that works as intended.

Current evidence should therefore be requested at each layer. A route view can show both sessions and the prefixes advertised over them. A topology drawing can show handoff equipment and physical entry paths. Carrier orders can identify the contracting service. A controlled failover record can show whether established traffic moves, how long convergence takes and whether customer addresses remain stable. Monitoring history can show packet loss and utilisation before and after a transition.

The network is compact enough that this should be manageable. There are two public prefixes, two RPKI authorisations and a small declared external policy. Intelion does not need to produce a grand backbone narrative. It needs to show that the specific redundancy sold to a customer is current, tested and attached to the facility and service in the order.

Locality belongs to the workload, not the company name

Intelion is a Russian company selling servers described as located in Russia. Its about page marks Moscow, Samara Region, Tver Region and Tula as operating locations and identifies Kemerovo and Khakassia as forthcoming. The home page describes an active data centre near Samara. For a customer seeking Russian compute capacity, these are directly relevant statements.

They are not a universal data-residency answer. A legal address is not a server location. An autonomous-system country is not a disk location. A BGP route tells the internet how to reach an address, not where the data behind it is stored. Even a facility list does not say which product is available in which site or where backups, control-plane records, support transcripts and billing data reside.

Intelion's own product structure makes this distinction unavoidable. A virtual machine and its disk may be placed on the provider's Russian infrastructure. A dedicated server occupies a particular physical site. The Inference Platform can take a very different path. Its May 2026 terms define two processing-region classes: Russia for open-weight models on Intelion's own infrastructure, and International for cloud models processed through AWS Bedrock in Frankfurt or US regions. The selected model's provider and region are supposed to be visible in the control panel and model-list endpoint before a request is sent.

That is a useful disclosure. It means a customer does not have to pretend that every model endpoint is local simply because the invoice comes from a Russian provider. It also means the customer has to make an active architectural choice. A request sent to an international model crosses the Russian border, and the terms assign the customer responsibilities associated with that transfer when personal data is present.

The inference terms add more detail. Intelion says request and generated content are not used to train the models and are not retained after processing, except for technical fault logging or legal requirements. Usage metadata, including model, timing, token counts, key identifier, customer identifier, status and cost, is retained for three years. Customers are promised access to at least 180 days of their own usage metadata. These statements create a more useful data map than the general word cloud, but they remain contractual claims rather than an independent test of every model provider.

An enterprise data map should therefore follow the workload through all of its states. For a VM, that includes the image, boot disk, attached storage, backups, snapshots, host logs, console access, support artefacts and deleted-resource state. For an inference request, it includes request content, generated content, model provider, region, transient fault logs, usage metadata and any application logs kept by the customer. For account administration, it includes identity documents, billing events, contact details and support conversations.

The buyer should then assign a permitted geography and retention rule to each state. "Servers in Russia" is too broad to perform that function. A defensible requirement sounds more like this: a named VM, disk and backup remain in a named Russian location; support access is logged; international model endpoints are disabled for the project; metadata retention is understood; and any exception requires an authorised change. That is data sovereignty as an operating control rather than a slogan.

Intelion's public documents make such a conversation possible. They also show why locality cannot be inferred from the company name. The same account can reach local compute and international model infrastructure. The decisive field is the service and region selected for the workload.

The AI support agent creates an access-control decision

Intelion describes itself as an AI-native cloud, and the most concrete expression of that idea appears in the July Cloud Platform terms. The provider says it offers a software AI agent to help configure and maintain virtual machines. During machine creation, a public key for the agent is controlled by a checkbox that is selected by default unless the customer clears it. The terms say employees do not use that key, the agent performs only actions agreed with the customer in chat, and the customer can revoke access by deleting the key.

This is more than a marketing label. It turns support into a privileged automation workflow. The agent may be able to enter a customer machine and take actions that would otherwise require an administrator. If it works well, it can reduce routine setup labour and shorten the distance between a support conversation and a configuration change. It can also make a support error faster and more repeatable.

The central issue is not whether an AI agent is safe in the abstract. It is whether the access boundary is visible and governable for the customer's workload. A default-selected checkbox means the customer should not rely on passive consent. An enterprise account may need a policy that disables agent access by default and enables it only for a specific ticket, machine and time window. A regulated workload may prohibit it entirely.

The terms provide a useful skeleton for that control: a distinct key, prior agreement in chat and customer revocation. A buyer should ask for the rest of the evidence. Which identity signs the agent's key? Is the key unique per customer or machine? What commands can the agent execute? Where is the proposed action displayed? Can a customer require a second approval? Are commands and outputs logged immutably? Does revocation close active sessions? How are model errors, instruction injection and compromised support accounts handled? Can secrets be masked before context is sent to any model?

These are not speculative edge cases. The business value of the agent comes from its ability to act. The blast radius comes from the same property. The terms say actions are agreed in chat, but agreement can mean anything from a clear command preview to a vague conversational confirmation. An enterprise buyer should define what constitutes approval and retain the record needed to prove it.

The agent also changes local support labour rather than replacing it. Someone must design its permissions, maintain its software, review failed actions, handle exceptions and take over when the machine is unreachable. Intelion's site separately claims an on-site engineer can reboot through IPMI, replace a disk or memory module and address a failed GPU. The software agent and the engineer solve different problems. One acts inside the logical machine; the other can touch physical equipment. A credible support model explains how work moves between them.

Intelion deserves credit for putting the agent-access mechanics into public terms. Many services would leave such a feature in a product description. The disclosure lets a buyer ask the correct question: not "does the cloud use AI?" but "what authority does the agent receive, and how is every exercise of that authority approved, observed and reversed?"

Support is split across four different clocks

The public material uses several forms of the word support, and they should not be treated as synonyms.

The first clock is infrastructure monitoring. Intelion says it collects port flaps, CRC errors and utilisation around the clock and keeps an engineer on site at the data centre. That describes detection and physical intervention. It is relevant to a failed switch, disk, memory module or GPU. It does not by itself tell a customer when a message will be answered.

The second clock is product-page availability. The H100 page says round-the-clock technical support in one section, then displays support seven days a week from 09:00 to 21:00 Moscow time near the product card. Those statements are broader than ordinary office hours but not identical to each other. The page also says backup and system administration can be additional services, which suggests that the scope of included help is as important as the clock.

The third clock is the baseline contract. Section 13.3 of the March 2026 user agreement says technical support is provided on working days from 09:00 to 18:00 UTC+3 for no more than 30 minutes a day; additional time is charged under a separate tariff. Requests are accepted by email or the official Telegram account. Unless a service order grants something stronger, this is the most consequential public description of the customer's support entitlement.

The fourth clock is the service-availability clock. Cloud Platform availability is described as 24x7x365. That says when the service is meant to function, not when a human must answer. A platform can carry a 24-hour availability commitment while the included support desk works a narrower schedule. That design may be adequate for self-managed, non-critical workloads. It may be a serious gap for a production system that needs immediate diagnosis or physical intervention.

The contrast is not proof that Intelion fails to respond outside office hours. It is proof that the buyer should not infer an entitlement from a product phrase. The provider may sell enhanced support, maintain an operations duty rota or respond voluntarily. The public contract simply does not make all of those possibilities part of the baseline promise.

A useful support schedule should name severity, channel, acknowledgement target, technical engagement target, update frequency, restore objective and escalation owner. It should distinguish account questions from infrastructure incidents, abuse reports, security events, data-restoration requests and paid administration. It should also state whether the 30-minute daily limit applies during a provider-caused outage and whether an on-site engineer can be engaged directly by the support desk at all hours.

Local support labour is valuable precisely because cloud failures cross layers. An API may report that a VM is running while the guest is inaccessible. A route may be globally visible while a storage path is stalled. A customer may approve an agent action that cannot fix a failed GPU. The organisation needs someone who can correlate control-plane state, network observation, host telemetry and physical equipment. The public record shows pieces of that operating model. The contract needs to connect them.

A perfect percentage can still leave a practical gap

Intelion's availability language is unusually ambitious. The July Cloud Platform terms state 24x7x365 availability and 100 percent operability per hour, subject to exclusions. The dedicated-server terms state 100 percent per month, again with exclusions. The Inference Platform uses 99.5 percent monthly availability and excludes beta models along with specified failures outside Intelion's control.

Those percentages should not be averaged into one company-wide number. They apply to different services, measurement periods and dependency chains. More importantly, the remedy mechanics determine what the number does for a customer.

For the Cloud Platform, technical work is excluded from unavailable time, including planned and unplanned work directed at keeping equipment functioning or correcting faults. Downtime begins when the customer sends a message through the ticket system and ends when restoration work finishes. Compensation is extra time using the same service, generally matching the unavailable period, and the customer must request it. An interruption longer than five minutes but shorter than an hour is treated as one hour for compensation.

This structure creates three practical consequences. First, monitoring by the provider does not necessarily start the contractual outage clock; the customer's ticket does. Second, the headline percentage is not a historical measurement published for outside review. It is a promise calculated under defined exclusions. Third, the remedy is service time, not necessarily compensation for the customer's consequential loss, staff time or failed workload.

None of that makes the SLA meaningless. A clear clock, a minimum one-hour compensation unit and a 100 percent target give the customer a contractual route to a remedy. But the arrangement rewards customers who monitor independently and open tickets promptly. A team that assumes the provider's 24-hour monitoring automatically creates a claim may discover that its own notification timestamp is the important evidence.

The cloud terms also contain an incomplete clause where the communications operator and contract details were meant to be identified. That drafting gap sits beside the more specific carrier claims on the website. It does not erase the routes or circuits. It does weaken the contract's ability to identify the network dependency without outside context. A customer should have that field completed in the service order or an attached technical schedule.

The right test is not whether 100 percent sounds plausible. It is whether the service definition includes the component the customer cares about. A VM can be marked available while an optional software package is broken; the main agreement explicitly says the VM SLA does not extend to third-party software additions. A public IP can be allocated while a route is impaired. An inference endpoint can be reachable while a particular external model is unavailable. Buyers need component-level monitoring and a remedy tied to business impact, especially for long-running training jobs that can lose more than the minutes of the outage.

Retention and recovery sit behind the friendly stop button

The stop button is central to Intelion's commercial proposition. Stop the server, stop compute charges, keep the disk for a period and resume later. For intermittent AI work, that is a sensible model. It keeps expensive accelerators from billing while preserving the environment that took time to prepare.

The contract reveals the state transitions underneath it. The customer can schedule backups, including more than one routine, but the availability of a backup resource is not the same as automatic protection of every disk. The H100 product page also treats backup as a service that may be added. A buyer should therefore assume that recovery protection must be selected, configured and tested unless an order says otherwise.

After 30 days without a VM launch, Intelion may remove the instance while keeping the disk and moving it into cold storage. Notice is promised at least 24 hours before that transition. Cold storage is metered. If the account balance reaches zero, a 72-hour funding window begins, after which the disk and its data may be deleted without another notice. That sequence makes account balance and contact delivery part of the recovery design.

This matters for teams that use GPU capacity in bursts. A research environment may sit untouched between experiments. A departed employee may be the only recipient of billing notices. A procurement delay may prevent a balance top-up during the grace window. None of those events is a storage-system failure, yet each can end in data loss under an automated retention rule.

The remedy is operational discipline. Important data should exist outside the lifecycle of a single metered disk. Backup schedules should be verified by restore tests. Account alerts should reach a shared operational address. Funding and deletion thresholds should be monitored through a separate system where possible. An exit plan should define how images, data and configuration records are exported before service ends.

Intelion's public terms are valuable because they show the deletion mechanism before a customer discovers it. The buyer should use that clarity. The comforting headline explains how to pause cost. The contract explains how not to mistake a paused resource for an archive.

What a buyer should ask Intelion to prove

The evidence supports a real company, real product documents and a live public routing surface. A procurement review can therefore move past generic questionnaires and request a compact, service-specific proof pack.

First, reconcile identity. The order should name OOO "Intelion Oblako", its registration and tax numbers, the address for notices and the brand under which support operates. It should state whether any affiliate, facility operator or contractor holds equipment, address resources or customer data. Network and abuse contacts should be tied to the service rather than left as unassigned email addresses.

Second, freeze the purchased configuration. Record the GPU model and memory, CPU, RAM, disk class, public-address arrangement, VM bandwidth cap, region, operating image, billing event and earliest substitution rule. If a cluster is required, record interconnect topology and the test used to accept it. A catalogue page is too fluid to serve as the technical schedule.

Third, request current network evidence. The useful packet is small: both origin prefixes, current route-origin authorisations, the external autonomous systems expected in normal and failover states, a date-stamped route view, physical carrier handoffs and a recent failover result. Ask why the site names MegaFon and Rostelecom while the RIPE policy object names Rostelecom and SOTEL, and how the one-neighbour collector view fits the intended design. An answer can be perfectly ordinary; it still needs to be explicit.

Fourth, build a data-location matrix. List VM disks, backups, snapshots, control-plane metadata, support records, identity documents, billing data, inference content and inference metadata. Assign each a region, processor, retention period, deletion event and export method. Disable international model routes where they are not permitted. Do not use the location of the invoice or IP address as a proxy.

Fifth, govern privileged automation. Decide whether the AI support key can be installed by default. Require a unique identity, narrow scope, time-limited enablement, action preview, approval record, command log and revocation test. Establish the human escalation path for an agent failure and make clear which secrets or regulated data the agent may encounter.

Sixth, sign a support matrix. Put the included hours, 30-minute limit, paid support tier, incident channels, severity levels, acknowledgement targets and on-site escalation into one schedule. Separate platform monitoring from customer response. Name the people or roles authorised to declare an incident, approve a risky change and request a restore.

Seventh, test the SLA and retention state machine. Open a test incident and confirm which timestamp starts the clock. Verify how compensation is requested. Stop a non-critical VM, observe notices, review cold-storage charging and restore it. Confirm that low balance alerts reach the right team. Restore from a backup into a separate environment and record the time and data loss.

Eighth, run a workload benchmark that measures the service rather than the GPU name. Capture job completion time, storage throughput, network transfer, failure recovery, queue delay and total billed cost. Repeat it after a configuration change. Intelion's public materials do not supply independently verified performance, so the customer's own acceptance run should become the baseline.

These requests are proportionate to the evidence. They do not ask a young provider to pretend it is a global hyperscaler. They ask it to show that the particular resources, paths, locations and people behind a contract can deliver what the customer is buying.

The public record is useful because it is not seamless

Intelion Cloud has crossed an important threshold. The name now connects to a registered Russian company, a functioning control-plane proposition, detailed customer terms, an active autonomous system, two current RPKI-valid routes and a visible account and support model. A buyer can ask informed questions because there is real material to interrogate.

The same record prevents an easy endorsement. The public route surface is compact. Address registration and route origin belong to different organisations. Carrier descriptions do not align neatly across the website, RIPE policy and collector view. Russian infrastructure does not keep every inference request in Russia. Product support phrases are broader than the baseline agreement. A 100 percent availability figure depends on exclusions, customer ticket timing and a service-time remedy. A stopped disk can eventually enter a balance-driven deletion path.

These are not reasons to dismiss the provider. They are the actual shape of the decision. Intelion's value will come from making expensive compute easier to obtain and operate. Its assurance will come from keeping the records behind that convenience current, reconcilable and actionable when something fails.

The fair conclusion is therefore conditional but not evasive. Intelion Cloud LTD has more public operating substance than a cloud name alone. The route table, contracts and product mechanics support that statement. Whether it is the right platform for a particular enterprise workload depends on the next layer of proof: a fixed configuration, a tested path, a workload-level data map, controlled privileged access and a human escalation promise strong enough for the consequences of failure.