ML Cloud and the Russian record behind an ordinary cloud storefront

Summary

• ML Cloud has a visible operating surface: its site offers virtual and dedicated servers, GPU capacity, 1C hosting, network announcements, address leasing, administration and support, while AS215376 provides an attributable Russian network identity. Those facts show a service proposition and network presence, but not the quality, ownership or lawful availability of every advertised location and resource.
• Counterparty identity is unusually consequential. The public site names ML Cloud Limited at a Hong Kong address and bank account; network records name ML Cloud Ltd in Russia and link its resource administration to a Media Land maintainer; U.S. authorities name ML.Cloud LLC in St Petersburg. A buyer cannot safely treat these labels as interchangeable without current legal documents, sanctions screening and a contract that identifies the exact seller and service chain.
• OFAC designated ML Cloud in November 2025 as part of coordinated U.S., Australian and British action. On July 14, 2026, the U.S. Department of Justice announced charges alleging that ML.Cloud and related parties supplied infrastructure and support used for ransomware and other cybercrime. The designation is an operative compliance fact; the criminal charges remain allegations, and all defendants are presumed innocent unless proven guilty.
• The practical decision is no longer a normal comparison of server price and specifications. It is whether a customer can lawfully transact, fund and support the service; map each workload to a facility and network path; obtain trustworthy change, abuse and recovery records; and leave before a payment, route, account or legal disruption becomes an outage.

The server can work while the supplier fails the decision

Cloud procurement often begins with a simple comparison. A buyer lines up processor models, memory, storage, traffic allowances, setup time and monthly cost. Support and location appear as secondary columns. If the machine starts, passes a benchmark and responds to a ticket, the provider seems to have cleared the important hurdles.

ML Cloud shows why that method is incomplete. Its home page presents an ordinary infrastructure catalogue: virtual servers, physical servers, GPU machines, 1C systems, administration and technical support. It says virtual capacity can scale quickly, dedicated machines can be ready in minutes, basic AntiDDoS protection is included, and a custom panel helps customers manage infrastructure and expenses. Nothing in that interface alone tells a prospective customer that the company name appears in a coordinated sanctions action or a federal criminal case.

The difference is not cosmetic. Infrastructure depends on more than a running processor. The customer needs a lawful payment path, a counterparty able to perform the agreement, an account that remains accessible, addresses that continue to route, staff who can recover a failed host, and an exit path that returns data and configurations. A sanctions event can interrupt banking, licences, insurance, suppliers or support even when the server itself remains healthy. A law-enforcement action can change the risk of seizure or provider cooperation. A disputed company identity can leave the customer unsure which entity owes the promised remedy.

That is the central mechanism in this case: counterparty risk becomes technical risk. Legal and financial constraints can reach the same control points that operators use to keep a service available. A blocked payment can lead to suspension. A supplier withdrawal can remove replacement hardware or connectivity. An inaccessible panel can prevent a customer from changing a firewall or rebuilding a machine. A staff departure can strand unresolved support cases. A route can remain visible while the business behind it loses the ability to respond.

The public record therefore has to be read in layers. Product pages describe what the seller says it offers. Company and payment pages identify the names through which it says it contracts. Network databases show registered and observed routing resources. Government notices state sanctions determinations and criminal allegations. Customer discussion can reveal questions worth testing, but not general performance. None of these layers should be substituted for another.

For a buyer, this is not an invitation to speculate. It is a reason to make the decision more disciplined. The provider should neither be cleared because a test machine starts nor condemned through claims the public evidence does not establish. The correct approach is to separate verified facts, first-party assertions, observations and allegations, then ask whether the remaining uncertainty is tolerable for the intended workload and lawful for the customer.

One brand points to several company surfaces

The name is easy to recognise and difficult to contract with confidently from the public pages alone. The storefront uses ML Cloud, ML-Cloud and ML Cloud LLC in different places. Its documents page says "ML Cloud Limited" supplies services through a public offer accepted when a customer takes the specified action. Its contact page gives a Hong Kong address, identifies ML Cloud Limited as the beneficiary of an HSBC Hong Kong account and repeats the same address for correspondence.

The network record points elsewhere. A third-party presentation of RIPE fields for AS215376 names ML Cloud Ltd, country RU, registration number 1227800008182 and an address in St Petersburg. The organisation entity is administered by a maintainer named mnt-ru-media-land-1. The autonomous-system entity uses the name mlcloud, and the resource history places its creation in March 2024. These are meaningful identity anchors because they connect a name, country, organisation and network number.

They do not reconcile the legal picture. A network organisation entity exists to administer Internet number resources. It is not a certified company extract, ownership register or contract. A maintainer label shows which credential set can manage database entities; it does not by itself prove corporate ownership. A Hong Kong bank beneficiary can be part of a legitimate cross-border group; it does not by itself explain which company owns the Russian network or accepts liability for a server in Amsterdam, Warsaw or Kazan.

The government record adds a third naming surface. The U.S. Department of Justice announcement names ML.Cloud LLC, describes it as headquartered in St Petersburg and says it was owned by Yulia Pankova at the time covered by the investigation and indictment. The U.S. Treasury announcement calls ML Cloud a sister company of Media Land. Those statements make the relationship operationally relevant, while still leaving a buyer to establish how the named Russian entity relates to the Hong Kong seller displayed on the current site.

A sound identity check would begin with a current corporate extract for every entity expected to sign, invoice, receive funds, control the account, operate the network or process customer data. It would identify directors, beneficial owners, signing authority, registered addresses and ownership links. The order form, service schedule, invoice, bank beneficiary and privacy terms should use names that can be reconciled to those records. If one company sells and another operates, the agreement should state which one owes service credits, returns data, handles abuse and answers a legal notice.

This may appear bureaucratic beside a low-cost server. It is actually part of recovery design. During an outage, the customer needs to know who has authority to restore access and who can be compelled to perform. During an exit, it needs the entity holding the data and the entity receiving payment to cooperate. Under sanctions, it needs to know whether ownership or control rules reach an apparently different affiliate. The exact name is therefore not a footnote. It determines whether the commercial promise can be enforced and whether a payment can be made at all.

A designation and an indictment are different kinds of fact

The two U.S. actions must be described separately. On November 19, 2025, the Treasury Department announced coordinated action with Australia and the United Kingdom against Media Land and related parties. Treasury designated ML Cloud under U.S. cyber-related authorities and described it as a Media Land sister company whose infrastructure was often used with Media Land, including in ransomware and DDoS attacks. For U.S. persons and transactions within U.S. jurisdiction, OFAC blocking rules are not a reputation score. They are a legal constraint, subject to the exact listing, ownership rules, applicable licences and current guidance.

The July 14, 2026 Justice Department announcement concerns criminal charges. It says an indictment returned in December 2024 was unsealed in the Northern District of Ohio and names three Russian nationals, Medialand LLC and ML.Cloud LLC. Prosecutors allege that the businesses provided servers and related services used by criminal customers for malware, ransomware, phishing, brute-force attacks, fraudulent domains and criminal marketplaces. The release concerns a case said to have caused more than $62 million in victim losses, but it does not attribute that entire figure to ML.Cloud alone.

An indictment is not a conviction. The Department expressly says it is an allegation and that every defendant is presumed innocent unless proven guilty beyond a reasonable doubt. That caveat is not a ceremonial sentence to be buried at the end of the analysis. It controls how the evidence should be used. The charges justify heightened diligence and explain the enforcement context. They do not establish every allegation as proven, show that every ML Cloud customer acted unlawfully or permit claims beyond the charging record.

The sanctions designation has a different status. It remains a government determination with direct transaction consequences even while criminal liability is unresolved. A customer should check the current OFAC entry, equivalent British and Australian measures, local sanctions law, ownership and control, payment institutions, insurers, resellers and any relevant licence. A company outside the United States can still face a practical block if its bank, card network, software vendor or upstream applies sanctions restrictions.

The analysis must be performed by qualified counsel and compliance staff for the customer's actual jurisdiction and transaction.

This distinction changes the purchase sequence. For an ordinary host, a technical trial may come first. Here, legal identity and sanctions screening have to precede payment, account creation, data transfer or support engagement. If the customer cannot establish a lawful route to transact and continue transacting, there is no technical configuration that repairs the decision. Benchmark results become irrelevant.

The same discipline should continue in public discussion. It is reasonable to report the designation, the charges and the relationships stated by authorities. It is not reasonable to turn a network maintainer name into proof of every alleged act, to assign criminal intent to ordinary users, or to treat a forum complaint as corroboration of a federal case. Each record has its own scope. The value comes from joining them carefully without erasing those limits.

The catalogue describes real operating choices

The enforcement context should not obscure the shape of the product. ML Cloud's pages describe several distinct infrastructure boundaries, and each creates a different allocation of labour and risk. The home page markets virtual machines on NVMe storage, physical servers, GPU-equipped dedicated systems and 1C servers. It also lists administration, network announcements and IP address leasing. The support material refers to virtual machines, Kubernetes clusters, subnets, local networks among products or sites and customer-supplied operating-system images.

Virtual servers put much of the software boundary with the customer. The provider supplies compute, storage, network access and a panel; the customer normally chooses the image, configures access, patches the operating system, protects credentials and restores applications. Rapid creation can save hours of manual coordination, but it also makes it easy to create forgotten machines, expose a port, retain an outdated image or accumulate charges across attached resources.

Dedicated servers shift hardware replacement toward the provider while leaving application continuity unresolved. Full access to a physical machine can help with performance isolation, unusual software and GPU work. It can also increase migration time because a replacement chassis is not the same thing as a recovered workload. A buyer needs a rebuild image, current configuration, off-host backup and tested restoration procedure. "Ready from 120 seconds" is a provisioning claim, not a recovery-time commitment.

GPU servers add supply and lifecycle dependencies. The site names several NVIDIA models and presents them for machine learning, rendering, transcoding and CUDA workloads. A customer should establish whether the exact model is guaranteed, whether it is dedicated, how failed hardware is replaced, which driver and firmware combinations are supported, and whether data can move to a different model without breaking the application. Sanctions and export controls may add supplier and replacement uncertainty that is not visible in the hourly or monthly price.

The 1C offer adds application labour. ML Cloud says specialists can migrate and customise 1C. That promise reaches beyond renting a server into database, application and business-process work. The customer should define who backs up the database, tests upgrades, supports integrations, handles licensing and validates a restored environment. A server-level snapshot can be crash-consistent yet still fail to produce a usable business system. Recovery should be accepted by people who understand the application, not only by an infrastructure status light.

The road map is particularly useful because it separates some claimed present capabilities from planned ones. It marks virtual, dedicated and GPU servers and Global VLANs as complete, while placing cloud databases, AI-based DDoS protection, IaaS, cloud storage, Kubernetes, cross-site migration, DNS, load balancing and other services in later stages. The wording and timing remain first-party and not independently verified, but the page warns a careful reader against treating the whole menu of aspirations as an already delivered platform.

This matters commercially. A buyer comparing ML Cloud with a mature public cloud may see familiar nouns and assume familiar operating depth. A virtual machine and a future database service do not create the same control plane, permissions model, event history or recovery contract as an integrated platform. The service should be bought for demonstrated present functions, with planned features valued at zero until they are available, documented, tested and contractually within scope.

Automation saves clicks and creates a record problem

The strongest automation claim is the custom control panel. ML Cloud says customers can select capacity, provision virtual servers quickly, manage expenses and use hourly billing for virtual machines. Its documents page says business customers can obtain monthly closing records through an account ticket. Together, those details imply a service in which account state, resource state, support state and billing state are connected through customer-facing software and staff actions.

That connection is useful when it is attributable. A small technical team can start a test server without waiting for a procurement exchange. It can increase a virtual configuration, install an image and stop capacity when the experiment ends. A finance user can compare usage with invoices. A support specialist can inspect the affected product and coordinate a reboot or configuration change. These functions replace repetitive email and manual setup.

They also concentrate authority. A compromised account may be able to create costly machines, replace an operating system, expose a network service or delete a resource. A billing suspension may remove access when the customer most needs to export data. A support intervention can repair a server, but an unauthorised intervention can alter evidence or availability. The public pages do not describe multifactor authentication, separate user roles, high-risk action approval, immutable event history or customer export of account activity.

A prospective customer should therefore test the records around the action, not only the action itself. When a virtual machine is created, does the account show who requested it, when it became available, which image and location were used and which charges began? When a configuration changes, can the prior state be recovered? When support reboots a machine, does the customer see the request, operator, reason and result? When a resource is deleted, what happens to disks, snapshots, addresses, logs and billing?

The same questions apply to automatic DDoS protection. The home page says basic filtering is included continuously and invites customers to open a ticket if an attack exceeds the standard system. This describes an escalation boundary, not a measured security outcome. The customer needs to know the protected addresses, detection method, traffic thresholds, diversion process, collateral filtering risk, event reporting, emergency contact and treatment of attacks aimed at applications rather than bandwidth. It should also determine whether a sanctioned provider can continue to obtain any third-party filtering on which the service depends.

Automation is valuable when it produces a repeatable, reviewable lifecycle. Provision, change, protect, bill, recover and delete should each leave records that a customer can inspect. Without that history, the panel can make activity faster while making responsibility harder to establish. In ML Cloud's case, where company identity and relationships carry exceptional weight, attribution at the account level is not optional administrative polish. It is part of the customer's evidence that its own use remained controlled and lawful.

Support is a production dependency, not a chat icon

ML Cloud makes human assistance central to its proposition. Its support page lists email, live chat, Telegram and account tickets. It says staff explain product functions, help configure services, guide migrations, connect networks across products or sites, troubleshoot slowness and instability, and perform reboots or configuration changes. The contact page advertises continuous support availability.

That scope can be valuable for a small customer. A provider specialist may diagnose whether a failure sits in the guest operating system, virtual network, physical host or upstream path. A migration engineer can reduce downtime when moving data. A person with access to the hardware can recover a dedicated server that remote software cannot reach. Local or regionally familiar staff can also shorten communication during an incident.

The published support promise lacks the records needed to price it as assurance. There are no public severity definitions, response targets, resolution distributions, escalation contacts or compensation rules in the examined pages. "24/7" can mean that a message is accepted at any hour, that a first-line responder is present, or that a senior network engineer can act immediately. Those are very different services.

A 2025 LowEndTalk discussion illustrates the question without resolving it. A customer complained about delayed delivery and no response. An account posting as mlcloud said managers had missed the order and that the problem was being addressed; the customer later said the issue was resolved. Other posts raised ticket questions. The identities and details were not independently verified, and one conversation cannot support a general claim about current performance. Its narrow lesson is that a buyer should test the handoff among ordering, support and technical action.

The test should be designed around real failure. Open a low-severity case and record acknowledgement, ownership, useful diagnosis and closure. Then agree how a high-severity event would bypass the normal case channel. Confirm which languages are staffed at the required hours, who can change a route or replace hardware, and who has authority to restore an account blocked by billing or identity checks. Ask how the provider communicates when the panel or normal email path is unavailable.

Support access also has to survive the counterparty problem. If a payment bank refuses a transfer, can staff preserve service while compliance reviews it? If a supplier terminates an account, can ML Cloud move the workload? If government action limits a location or company, which team tells customers, and how much export time remains? These questions may sit outside a normal support script, but they are now foreseeable operating scenarios.

The commercial price of support should include customer labour. If the provider lacks clear severity and escalation records, the customer must maintain more monitoring, more on-call expertise and a faster exit capability. A cheap server can become expensive when senior staff spend hours proving that a problem is outside the guest system or trying to reach someone with authority. The right measure is not whether chat answered once. It is how many customer minutes are needed to reach an accountable decision during repeated events.

AS215376 proves a network identity, not a service outcome

The network evidence is concrete and narrow. Public routing observers identify AS215376 as mlcloud or ML Cloud Ltd in the Russian Federation. The BGP observation page records the autonomous system as active and allocated under RIPE, with a registration date of March 4, 2024. In its observed snapshot it showed one originated IPv4 /24, no visible IPv6 origin, one upstream and two peers. The reproduced registration fields link the organisation and route administration to mnt-ru-media-land-1.

The IPIP presentation of registry data showed a wider set of associated resources: four IPv4 /24s and three IPv6 /48s, with route-origin and Internet Routing Registry annotations. Cloudflare Radar independently provides a routing page for the same ASN and country. The differences among these views are not necessarily contradictions. One page may list registered or low-visibility resources while another reports only routes visible under its current collection method. Topology changes over time.

The disciplined conclusion is that ML Cloud has an attributable network identity and publicly recorded address resources. That is stronger than a brand with no visible network connection. It gives customers and abuse reporters a number to monitor. It lets an operator compare registered policy with observed origin, check route authorisation and watch whether prefixes or upstreams change.

It does not prove nine data centres, private capacity, 40 Gbit/s connectivity, DDoS performance or application uptime. One visible route can carry many services or very few. An upstream label does not reveal physical fibre diversity. A valid route-origin authorisation can reduce one form of routing error while saying nothing about host security, lawful customer use or whether a database restores. A Russian country field in the network entity does not locate every server.

The Media Land maintainer name is relevant because Treasury separately states that ML Cloud is a Media Land sister company and the Justice Department describes related operations. Even so, the network field should be represented accurately. It shows administrative linkage in the RIPE data; the government announcements provide the broader relationship claim. Neither establishes that every route, facility or employee is shared.

A customer still considering an allowable relationship would need an address and test machine for the exact site and product before commitment. It should observe IPv4 and IPv6 reachability from real users, record route origins and upstream changes, test packet loss and latency over time, and learn whether the supplied address comes from AS215376 or another network. It should ask who can change route objects, who receives abuse reports, and how quickly a hijacked or misannounced route can be withdrawn.

The exit plan must include addresses. If the customer leases an address from ML Cloud or uses the provider for route announcement, migration may require DNS changes, allow-list updates, certificate work and reputation rebuilding. The customer should know whether addresses are portable, how reverse DNS is handled, how long routes remain after termination and whether a clean transition is possible if normal cooperation stops. Network-resource evidence becomes useful when it is connected to that workload-level plan.

City names do not settle data sovereignty

ML Cloud's data-centre page names Moscow, St Petersburg, Kazan, Saratov, Rostov-on-Don, Krasnodar, Riga, Amsterdam and Warsaw across its public material. It describes Tier III-level reliability, N+1 arrangements, surveillance, cooling specifications and a Global VLAN of up to 40 Gbit/s. It also discusses a planned liquid-cooled facility and expansion beyond Russia.

These claims describe an attractive geographic menu, but the public page does not provide a complete facility map. It does not consistently attach each specification to a named operator and street address. It does not publish certificate owners or numbers, explain whether ML Cloud owns, leases or resells space, or state which legal entity contracts for each site. A repeated block of facility characteristics can create the appearance of uniformity without proving that every location has the same design.

Data locality has at least four layers here. The machine may sit in one country. Backups, logs or support attachments may be stored in another. Administrators may access the system from a third. The customer may contract and pay through a company in a fourth. A city selector answers only part of that picture. The Hong Kong contact and payment surface, Russian network registration and multi-country facility claims make the layers especially important.

The customer should require a location schedule for the primary machine, replicated data, backup copies, snapshots, management records and support access. It should identify the facility operator, network provider, seller, operator and data processor for each layer. It should also define whether ML Cloud can move a workload or address without approval, what happens when a location is withdrawn, and which country's law governs access and disputes.

Sanctions can turn locality into a continuity problem. A server in Amsterdam does not necessarily remove exposure if a designated Russian company controls the account or receives the payment. Conversely, a Hong Kong invoice does not prove that operation or data processing is outside Russia. Ownership and control analysis must follow the actual entities and service relationships, not the label on a location menu.

Physical resilience needs the same precision. Two city names may provide geographic separation, but only if the customer can replicate between them, the paths and control systems do not share a critical dependency, and recovery can proceed when one site or the provider's central account system fails. The road map places cross-site migration in a later stage, so the buyer should not infer live workload mobility from the Global VLAN claim. A private network among sites and an orchestrated recovery service are different capabilities.

The right evidence would include a workload placement confirmation, facility assurance documents, dependency map, replication design and restore exercise. If those records cannot be obtained, the service may still be suitable for disposable or publicly reproducible work where lawful, but not for data whose location, recovery or legal handling must be demonstrated. Sovereignty is an evidence obligation, not a flag beside a server plan.

Abuse handling reaches ordinary customers too

Hosting is a dual-use business. The same virtual machine can run a legitimate application, a phishing page, a security test or a command system for malware. Providers cannot identify intent from hardware alone. Their operating quality depends partly on how they accept customers, monitor signals, process complaints, preserve evidence, stop harmful activity and allow appeals when an automated or external report is wrong.

The U.S. authorities allege something more serious than passive misuse in the ML.Cloud case. The Justice Department says the charged companies supplied infrastructure and technical support to criminal co-conspirators, while Treasury says ML Cloud infrastructure was often used with Media Land in ransomware and DDoS activity. Those are the relevant government statements. The indictment remains unproven, but the sanctions designation and the specificity of the allegations make abuse governance a direct purchase concern.

An ordinary customer can be harmed by weak abuse control even when its own conduct is legitimate. Address space can acquire a poor reputation, causing email or traffic to be blocked. A broad mitigation can interrupt neighbouring services. A provider may suspend an account on a complaint without enough notice to export data. Law-enforcement attention can affect shared infrastructure. Upstreams may withdraw service if they judge the risk too high. The customer's application then inherits consequences from behaviour it did not control.

Before any allowable engagement, a buyer would need the current acceptable-use terms, abuse contact, verification process, complaint handling timeline, suspension policy and appeal route. It should ask how the provider separates tenants, preserves records and prevents one customer from consuming shared defensive capacity. It should learn whether dedicated addresses are available and check their reputation before assigning production domains or mail.

The provider should also explain how it handles lawful security research, customer compromise and emergency remediation. A victim whose server is taken over needs a path to contain the incident without losing every record required to investigate it. A mistaken report needs review. A confirmed malicious account needs rapid action. These decisions require trained people and attributable case history, not only an automated block.

For ML Cloud, the customer must evaluate whether any promised policy can be relied upon while sanctions and charges are active. A written rule is useful only if the company can still staff it, its upstreams accept it and counterparties cooperate. The answer may be that the residual risk is unacceptable even outside a direct legal prohibition. That is a commercial conclusion based on dependency exposure, not a declaration about facts not yet proven in court.

The cheap-server calculation has acquired new cost lines

The commercial case for a smaller provider usually rests on price, straightforward products, useful locations and responsive people. ML Cloud says it offers hourly virtual capacity, flexible terms, unrestricted traffic and infrastructure without overselling. Those features can be attractive for experiments, regional services, GPU work or businesses that prefer direct support to a complex global platform.

The headline price is now a poor estimate of total cost. A prospective customer must add sanctions screening, legal review, entity verification, payment resilience, address and supplier checks, enhanced monitoring, backup outside the provider, incident preparation and faster migration capability. Banks and insurers may require explanations. Customers or partners may prohibit the dependency. Staff may need to document why the relationship is lawful and how data stays controlled.

Continuity reserves also cost money. A customer that cannot trust a single counterparty should maintain current copies elsewhere, automation that can recreate the service, spare capacity with another provider and DNS or traffic controls that support movement. It should rehearse the move. If a workload depends on a dedicated GPU or unusual address arrangement, equivalent replacement capacity may be expensive or unavailable at short notice.

There is also option value in leaving early. A low monthly rate can encourage a team to postpone portability work until applications, addresses and data have accumulated. That turns a small initial saving into a large switching bill. The correct comparison includes the cost and time to export disks, databases, entity data, account records, network rules, logs and billing evidence. It includes the risk that normal support or payment channels may not be available during the exit.

No benchmark can offset an unlawful transaction. Even where counsel concludes that a particular relationship is permitted, technical value must exceed the added supervision and disruption risk. The relevant metric is not rubles per virtual processor. It is the cost per accepted month of controlled, lawful and recoverable service after customer labour and standby arrangements.

A simple decision model can make this explicit. First apply a legal and policy gate. Then score identity confidence, workload locality, control history, network evidence, support performance, abuse handling, restore success and exit time. Assign a cost to every unresolved item. A cheap server that fails the gate receives no commercial score. A permitted service with weak recovery evidence should be priced as a temporary or replaceable dependency, not as a foundation for critical operations.

This approach also avoids moral theatre. The customer does not need to guess at unproven criminal liability in order to make a cautious decision. The designation, relationship evidence, company ambiguity and operational dependencies are enough to create measurable costs. Good procurement turns those costs into conditions, tests and stop rules.

A buyer's proof should follow one workload from order to exit

The most revealing diligence exercise would trace a small, non-sensitive workload through the whole service lifecycle, but only after counsel and compliance approve any contact and payment. The purpose would not be to collect a polished demonstration. It would be to connect each public promise to a responsible entity, observable record and recovery action.

Start with identity. Record the exact legal seller, invoice issuer, bank beneficiary, account operator, network operator, facility operator and support provider. Match company numbers, addresses, directors and ownership. Screen every relevant party under current sanctions rules. Put the approved names and service locations into the agreement. Establish what event requires renewed screening, such as an ownership change, new payment account or different facility.

Then order the smallest representative resource. Preserve the plan, location, specifications, terms and quoted support scope. Verify the delivered processor, memory, storage, address, route origin and site statement. Compare the first invoice with the order. Confirm who can access the account, enable every available authentication control and create separate roles if supported.

Exercise the control surface. Create and rebuild the machine, install a customer image, change a network rule, attach or replace storage, review expenses and open a support case. For every action, check whether the service records actor, time, prior state and result. Try to export those records. Determine whether support activity appears in the same history and whether an emergency action requires customer approval.

Test failure rather than only setup. Stop the guest unexpectedly and validate application recovery. Treat the machine as lost and rebuild it elsewhere from customer-held material. Restore the latest backup into a clean environment and measure data loss, elapsed time and staff effort. Simulate loss of the normal administrator account and learn how identity recovery works without weakening security. Ask support to explain, not merely perform, each intervention.

Inspect the network boundary. Observe routes for the assigned address over several periods, compare them with AS215376 and identify any other origin. Test reachability from actual customer regions. Review reverse DNS, abuse contact, DDoS escalation and address reputation. Establish what must change if the customer moves to another provider.

Finally, leave. Export data and configurations, move the workload, change DNS, revoke access, close the resource and reconcile the final bill. Request deletion confirmation and the records required for tax, audit or dispute. Measure the customer hours consumed. An exit rehearsal often reveals more about a cloud service than a launch because it crosses product, support, billing, identity and network boundaries at once.

For ML Cloud, there must also be a stop rule. A sanctions match that counsel cannot resolve, an unexplained counterparty substitution, a bank route inconsistent with the approved entity, refusal to identify the facility, inability to export the workload or loss of a critical upstream should trigger cancellation or migration. The stop rule should be agreed before convenience makes the dependency hard to unwind.

The useful scorecard measures records and recovery

A conventional hosting scorecard rewards attractive specifications and a long feature list. A more useful one asks whether the service can support repeated decisions under stress. The following measures connect ML Cloud's public proposition to evidence a customer could actually collect:

Decision area	Evidence to obtain	Repeatable measure
Counterparty	Current extracts, ownership, sanctions result, signed agreement, matching invoice and beneficiary	Unresolved identity exceptions; days since rescreening
Provisioning	Order, delivered specification, actor history and billing start	Time to usable resource; mismatch rate; customer minutes per launch
Access control	User list, authentication settings, role matrix and recovery process	Privileged accounts; stale users; time to revoke and restore access
Network	Assigned address, route origin, upstream view, reverse DNS and abuse path	Route changes; reachability failures; time to correct a routing error
Support	Severity, acknowledgement, owner, action history and closure evidence	Response time; useful-action time; customer escalation minutes
Backup	Customer-held copy, retention, restore record and clean target	Recovery point; recovery time; successful restores per attempt
Locality	Named facility, replication sites, operator and access countries	Unexplained location changes; age of placement confirmation
Abuse	Complaint record, evidence review, action, appeal and closure	Time to contain; mistaken suspension rate; appeal time
Exit	Export formats, dependencies, deletion evidence and final bill	Hours to migrate; data reconciled; residual accounts and charges

These measures do not require the provider to publish every customer or reveal sensitive architecture. They require enough evidence for the customer to know what happened to its own service. That is the correct scale of assurance for a private infrastructure purchase.

The scorecard also keeps different evidence classes apart. A route observer can confirm that an address origin was visible, but only a restore test shows that an application returns. A company extract can confirm a legal name, but only a sanctions analysis establishes whether the proposed transaction is allowed. A support ticket can show response time, but only the customer can decide whether the response restored the business process.

ML Cloud's public record currently creates a high burden before those operational measures even begin. The OFAC designation is not cured by a successful trial. The indictment cannot be treated as a conviction. The Hong Kong payment surface cannot be assumed to eliminate Russian ownership or control. The Russian ASN cannot be assumed to locate a server in Warsaw. The scorecard works because it refuses each of those substitutions.

What remains uncertain is part of the answer

The public evidence examined here leaves important gaps. It does not include certified current extracts for the Hong Kong and Russian companies, a complete ownership chart, the exact current checkout agreement, facility contracts, independent service-level reports, a customer-visible event-history specification, support performance distribution, restore history or a security assessment. It does not show which current routes carry which products or which legal entity employs the people answering support.

The company pages contain claims that should be tested rather than repeated as results. Rapid dedicated-server delivery, no overselling, unlimited traffic, basic DDoS protection, Tier III-level reliability, high-speed site links and continuous support may all describe real capabilities. The available pages do not provide independent measurement or consistent workload-level scope. The product road map further indicates that several platform functions remain in progress.

The network record has its own uncertainty. Observer views differ on visible prefixes, peers and upstreams. That is normal in a changing routing system, but it means a static count should not be used as a proxy for scale or resilience. Registered IPv6 resources do not guarantee an IPv6 service to a particular customer. Several city names do not establish physically separate paths.

The government record is strong about what the agencies did and said. Treasury imposed sanctions and described a relationship to Media Land. The Justice Department announced charges and allegations. The record examined here does not include a final criminal judgment because the Department says the defendants are presumed innocent. Future court proceedings, sanctions amendments, licences, ownership changes or government notices could change the picture, so screening has to be current at the moment of any decision.

Uncertainty is not an empty conclusion. It determines workload placement. A customer may decide that no engagement is lawful or consistent with policy. Another, after qualified review, may find a narrow permitted use but still restrict it to reproducible, non-sensitive, short-lived capacity with independent backups. A critical database, regulated personal data, payment system or sole recovery copy would require much stronger evidence and continuity than the public record supplies.

The provider could reduce uncertainty by reconciling its company names, publishing current ownership and contracting information, naming facilities and certificate scope, documenting account security and event history, defining support service levels, explaining abuse governance and providing clear export and deletion commitments. None of those steps would erase sanctions or decide a criminal case. They would make the ordinary operating proposition easier to evaluate on its own terms.

The cloud name is now a control question

ML Cloud is not merely a name on a directory card. The public material describes servers, staff, locations, a panel and a registered network. AS215376 gives the brand an attributable routing surface. The catalogue shows where automation could reduce setup labour and where people remain essential for migration, troubleshooting, hardware work and recovery.

But the decisive evidence sits outside the specification table. U.S. sanctions apply to ML Cloud. U.S. prosecutors have charged ML.Cloud LLC and related parties, while expressly recognising the presumption of innocence. The storefront presents a Hong Kong contracting and payment surface that is not fully reconciled in public with the Russian entities and network records. Those facts connect company identity and legal status directly to service continuity.

The practical lesson is wider than one provider. Cloud assurance is a chain of attributable records: who sold the service, who received funds, who controlled the account, where the workload ran, which network carried it, who changed it, who answered an incident, how it was restored and how it left. If one link cannot be established, a polished panel and a responsive server do not fill the gap.

For ML Cloud, the first decision is legal eligibility, not performance. The second is whether the customer's policy and risk appetite can tolerate the relationships and disruption paths that remain. Only then do processor, storage, network and support tests matter. A buyer that reverses that order risks learning that a technically adequate server was never an adequate dependency.