CLOUD Asre Dadeha Asiatech verkauft gehostete Kapazität, die immer noch von Racks, Transit und Reparaturfenstern abhängt

Zusammenfassung

• Cloud.ir verleiht CLOUD Asre Dadeha Asiatech eine echte Einzelhandelsfläche: Die Website bietet Cloud-Server, VPS-Pläne, Cloud-Speicher, CDN, Cloud-Switching, Cloud-Rechenzentrumsdienste, ein Kundenpanel, veröffentlichte Preise und eine SLA, und in der Fußzeile steht, dass die Website Asre Dadeha Asiatech gehört.
• Der physische Anker ist enger als die Produktsprache. Cloud.ir gibt an, dass seine Infrastruktur auf ASIATECH-Rechenzentren im Iran basiert, und die Über-uns-Seite sagt, dass Cloud.ir seit dem iranischen Jahr 1399 mit mehr als 20 Cloud-Produkten operiert, aber öffentliche Seiten identifizieren nicht das genaue Rack, die Platzierung pro Stadt, die Stromtopologie oder die Wiederherstellungstestergebnisse hinter jeder Kundenarbeitslast.
• Die Netzwerkbeweise sind auf der Control-Plane-Ebene stark. RIPE RDAP identifiziert AS60077 als AT-CLOUD für Asre Dadeha Asiatech, RIPEstat zeigte 18 IPv4-Präfixe und 14.080 IPv4-Adressen, die von AS60077 am 12. Juli 2026 angekündigt wurden, und DNS fürcloud.irwurde auf ein AS60077-Präfix abgebildet. Dasselbe RIPE-Bild zeigte einen beobachteten linken Nachbarn für AS60077: AS43754, die ASIATECH Asiatech Data Transmission company.
• Die Kaufentscheidung ist daher nicht, ob ein Cloud-Produkt existiert. Es ist, ob ein bestimmter Kunde die Platzierung, Kapazitätsreserven, unabhängige Routen, Backup-Lokalisierung, Support-Eskalation, Wartungsausschlüsse, Abrechnungskontinuität und Ausstiegsrechte überprüfen kann, bevor ein Rack, ein Upstream, ein Hardwarebestand oder ein Kontoereignis einen virtuellen Server in eine physische Abhängigkeit verwandelt.

Das Schaufenster ist öffentlich, aber das Infrastrukturversprechen ist immer noch geschichtet

Cloud.ir ist keine geparkte Markenseite. DieStartseite von Cloud.irpräsentiert Cloud-Server, Cloud-Rechenzentrumsdienste, Cloud-Switching, CDN, Cloud-Speicher, Cloud-Domainverwaltung, eine Service-Preisseite, Support-Seiten und einen Kundenlogin-Pfad. Dieselbe Seite enthält eine Telefonnummer, eine E-Mail-Adresse, eine Büroadresse in Teheran und eine Fußzeilenaussage, dass die materiellen und geistigen Rechte der Website Asre Dadeha Asiatech gehören. Für dieses Profil ist das wichtig, weil die Unternehmensidentität mit einer Live-Dienstoberfläche verbunden ist, nicht nur mit einem Routing-Eintrag.

DieÜber-uns-Seitefügt eine Servicehistorie hinzu. Sie sagt, dass Cloud.ir im iranischen Jahr 1399 den Betrieb aufnahm und einer der führenden Cloud-Diensteanbieter Irans mit mehr als 20 Cloud-Produkten geworden ist. Die dort genannten Produktgruppen umfassen Content Distribution, Cloud Computing, Cloud-Sicherheit, Cloud-Speicher, Cloud-Netzwerke und einen Cloud-Marktplatz. Diese Behauptungen sind Unternehmensaussagen, keine unabhängigen Messungen der Kapazität, aber sie machen die grundlegende kommerzielle Haltung klar: CLOUD Asre Dadeha Asiatech verkauft gehostete Kapazität an Kunden, die keine eigene physische Infrastruktur kaufen und betreiben möchten.

Das Einzelhandelsangebot ist auch spezifisch genug, um es zu prüfen. DieCloud-Server-Seitesagt, dass Kunden schnell einen Cloud-Server erstellen, für die genutzten Ressourcen bezahlen, Ressourcen ändern, Netzwerke konfigurieren, IP-Adressen hinzufügen oder ändern, Ressourcen- und Netzwerknutzung überwachen, eine Cloud-Firewall verwenden und Backups planen können. Dieselbe Seite beschreibt Linux-, Windows- und MikroTik-Serveroptionen und sagt, dass Support für Cloud-Server-Kunden rund um die Uhr per Ticket verfügbar ist. Ein Käufer sollte diese als Produktversprechen behandeln, die eine Vertrags- und Testbestätigung benötigen, aber sie sind dennoch konkreter als allgemeine „Cloud“-Sprache.

DiePreisseite von Cloud.irmacht das Produkt noch überprüfbarer. Sie listet VPS-Paketnamen wie AT-VPS-B2, AT-VPS-G1 und AT-VPS-A2 mit Arbeitsspeicher, CPU, Festplatte, einer kostenlosen IP-Adresse, Basis-Traffic, Add-on-IP-Unterstützung, Wiederaufbau-Unterstützung und IPv6 auf den Paketkarten auf. Sie zeigt auch eine stündliche Abrechnung für Cloud-Server-Ressourcen wie Speicher, CPU, Festplatte, IP, empfangenen Traffic und Backup-Stufen. Preisseiten sind keine technischen Diagramme, aber sie zeigen, wie der Dienst verpackt ist: Ein Kunde kauft endliche Rechen-, Speicher-, Adress- und Traffic-Einheiten, die irgendwo existieren müssen, bevor das Steuerfeld sie zuweisen kann.

Das Unternehmen beschreibt auch höherwertige Dienste rund um dieselbe Infrastruktur. DieCloud-Rechenzentrumsseitevermarktet sicheres und einfaches Datenmanagement, Skalierung, Überwachung, Virtualisierung, Containerisierung und geplante Backups. DieCloud-Speicherseitebietet skalierbaren Speicher, kontrolliertes Teilen und Zugriffsverwaltung. DieCDN-Seitebeschreibt Content Distribution durch inländische, zentralisierte und internationale Modi, wobei Benutzeranfragen über geografisch nähere Rechenzentren bedient werden. DieCloud-Switch-Seitepräsentiert verwaltetes virtuelles Networking zwischen Cloud-Servern und Rechenzentren. Jedes Produkt reduziert die Notwendigkeit für den Kunden, eigene Geräte zu besitzen; jedes führt auch eine Abhängigkeit von den Platzierungs-, Netzwerkdesign- und Supportentscheidungen des Anbieters ein.

Das ist der nützliche Rahmen für den Rest des Artikels. CLOUD Asre Dadeha Asiatech ist keine mysteriöse Hülle, aber die sichtbare Dienstoberfläche beseitigt nicht die Notwendigkeit, die unteren Schichten zu testen. Ein Cloud-Server kann nur dann in Sekunden bereitgestellt werden, wenn der Anbieter bereits geeignete Host-Kapazität, Speicher, öffentliche Adressen, Netzwerkerreichbarkeit und Abrechnungsautorisierung hat.

Ein CDN kann eine Anfrage nur dann an einen näheren Edge weiterleiten, wenn dieser Edge existiert, aktuelle Inhalte hat, genügend Cache- und Transitspeicher hat und den Ursprung noch erreichen kann, wenn der eigene Server des Kunden krank ist. Ein Backup ist nur dann nützlich, wenn es außerhalb des Fehlers wiederhergestellt werden kann, der die primäre Arbeitslast beschädigt hat. Die öffentlichen Seiten zeigen das Angebot; sie beweisen nicht jede Belastbarkeitsbehauptung, die ein Produktionskäufer benötigt.

Der physische Anker ist ASIATECH-Rechenzentrumskapazität im Iran

Cloud.irs stärkste physische Aussage ist explizit: seine Cloud-Infrastruktur befindet sich auf ASIATECH-Rechenzentren. DieCloud-Server-Seitesagt, dass die Infrastruktur der Cloud-Dienste von Cloud.ir auf ASIATECH-Rechenzentren bereitgestellt wird, die es als das größte Rechenzentrumsnetzwerk im Iran beschreibt. Sie listet die Verwendung moderner Technologien, ISO27001 und TIA-942 Tier 2 und Tier 3 Behauptungen, Sicherheitssysteme, stabile Netzwerkkonnektivität, hohe Bandbreitennutzung im Iran sowie AC- und DC-Stromunterstützung auf. DieCloud-Rechenzentrumsseitewiederholt denselben ASIATECH-Rechenzentrumsrahmen und sagt, dass die Cloud.ir-Rechenzentren im ganzen Iran die Infrastruktur für Kunden bereitstellen, die mit der Cloud-Migration beginnen.

DieÜber-uns-Seiteist ähnlich. Sie sagt, dass die Rechenzentren von Cloud.ir im ganzen Iran verteilt sind und dass die Infrastruktur auf ASIATECH-Rechenzentren beruht, die große und leistungsstarke Einrichtungen mit globalen Standards abdecken. Sie listet auch AC- und DC-Unterstützung auf. Diese Behauptungen sind wichtig, weil sie den Dienst von einer reinen Einzelhandelsabstraktion zu einer benannten Einrichtungsbetreibergrenze verschieben: Die Cloud-Marke hängt vom Rechenzentrumsbestand und Netzwerk von ASIATECH ab, nicht von einer unbenannten überseeischen Hyperscale-Region.

Außerhalb der Unternehmensseiten gibt die öffentliche Aufzeichnung älteren, aber nützlichen Kontext für diesen Bestand. Rechenzentrum Dynamics berichtete im Juli 2017, dass AsiaTech ein700 Quadratmeter großes Rechenzentrum im Milad Tower im Westen Teherans eröffnete. Dieser Bericht beschrieb AsiaTech als ein 2003 gegründetes Privatunternehmen, das 2013 eine Lizenz für Hosting, dedizierte und geteilte Server und Colocation erhalten hatte, und sagte, es betreibe fünf Rechenzentren und verbinde mehr als 430 Städte im Iran. DataCenterMap listet derzeitAsiatech Milad Tower RechenzentrumundAsiatech Azadegan Rechenzentrumin Teheran, während seine Spezifikationsseite für den Milad Tower besagt, dass von Asiatech keine Kapazitäts-, Strom-, Compliance-, Sicherheits- oder Gebäudedaten bereitgestellt wurden.

Diese externen Referenzen sollten sorgfältig behandelt werden. Sie bestätigen, dass ASIATECH mit benannten Einrichtungen in Teheran und einem breiteren Rechenzentrumsgeschäft in Verbindung gebracht wurde. Sie beweisen nicht, welche Einrichtung einen bestimmten Cloud.ir-VM, CDN-Edge, Speicher-Bucket oder Backup-Kopie im Juli 2026 bedient. Sie beweisen auch nicht, dass der Zustand der Einrichtung von 2017, die Rack-Anzahl, das Stromdesign oder die Kundenzahl unverändert geblieben sind. Die Einrichtungsgeschichte ist ein nützlicher Beweis für ein echtes Infrastrukturunternehmen; sie ist keine aktuelle Platzierungskarte.

Diese Unterscheidung ist für Kunden wichtig. Ein Käufer hört vielleicht „Rechenzentren im ganzen Iran“ und nimmt an, dass zwei vom selben Konto bestellte Server in verschiedenen Gebäuden landen. Das ist möglicherweise nicht der Fall. Sie könnten auf demselben Host, zwei Hosts in einem Rack, zwei Racks hinter einer Stromeinheit, zwei Hallen in einem Gebäude oder getrennten Gebäuden landen, deren Metro-Faser oder Upstream-Edge immer noch konvergiert. Umgekehrt könnte der Anbieter eine bessere Trennung haben, als die öffentlichen Seiten preisgeben. Die öffentlichen Seiten klären den Punkt nicht.

Der Kunde muss nach Platzierungskontrollen, Anti-Affinitätsregeln, benannten Standorten oder Standortcodes, Backup-Standort und fragen, was Cloud.ir für jede Dienstebene mit „Rechenzentrum“ meint.

Strom und Reparaturpersonal sind Teil derselben Frage. Cloud.ir kann zu Recht sagen, dass die Cloud-Nutzung die Last des Kaufs von Geräten und der Wartung eines Serverraums vermeidet. Das macht die physische Wartung nicht verschwinden. Jemand muss immer noch Festplatten, Netzteile, Line Cards und Speicher ersetzen; jemand muss immer noch Elektroarbeiten planen; jemand muss immer noch Generatoren, Batterien, Kühlung und Feuerschutz testen; jemand muss immer noch einen Alarm empfangen und zum Rack gelangen.

Ein Kunde muss nicht jedes private Detail des ASIATECH-Einrichtungsdesigns kennen, aber er muss wissen, welche Verfügbarkeitsversprechen ein Rack-Ereignis, ein Stromwartungsfenster, ein Speicherfehler und ein Mangel an Ersatzhardware überleben.

AS60077 ist sichtbar, und das Mutter-Netzwerk ist die offensichtliche Abhängigkeit

Die Netzwerkaufzeichnung gibt CLOUD Asre Dadeha Asiatech einen zweiten konkreten Anker. RIPE RDAP identifiziertAS60077als AT-CLOUD und verknüpft es mit Asre Dadeha Asiatech über ORG-ADA42-RIPE. Dieselbe RDAP-Antwort enthält administrative und technische Kontakte des Asiatech NOC an einer Adresse in der Miremad-Straße in Teheran sowie eine Asiatech-Missbrauchsrolle. Dies ist ein Registerbeweis für ein echtes autonomes System und eine funktionierende Kontaktkette. Es beschreibt keine einzelnen Server, Kunden oder Betriebszeiten, aber es bestätigt, dass der Cloud-Dienst seine eigene Netzwerkkennung hat.

DieAS-Übersicht von RIPEstat für AS60077meldete den Inhaber als „AT-CLOUD Asre Dadeha Asiatech“ und zeigte, dass es zum Abfragezeitpunkt am 12. Juli 2026 angekündigt wurde. DieRouting-Status-Ansichtzeigte 18 IPv4-Präfixe und 14.080 IPv4-Adressen, die von AS60077 sichtbar waren, wobei die erste Beobachtung des Präfixes auf 2014 datiert und die letzte Beobachtung zum Abfragezeitpunkt erfolgte. Dieselbe RIPE-Ansicht zeigte eine hohe IPv4-Collector-Sichtbarkeit und keinen sichtbaren IPv6-Raum in dieser bestimmten Statusantwort.

Der aktive Dienst verweist auch zurück auf AS60077. DieDNS-Chain-Ansicht von RIPEstat fürcloud.irgab193.151.157.174für den Apex-Namen zurück, und dieNetzwerkinfo-Ansicht für diese Adresseordnete sie193.151.157.0/24und AS60077 zu. Dies beweist nicht, dass jede Kundenarbeitslast innerhalb desselben Präfixes läuft; es zeigt, dass die eigene öffentliche Webpräsenz des Unternehmens vom Cloud-ASN bereitgestellt wird.

Die Abhängigkeit liegt in den Nachbardaten. DieASN-Nachbaransicht von RIPEstat für AS60077zeigte einen beobachteten linken Nachbarn: AS43754. DieAS-Übersicht von RIPEstat für AS43754nennt dieses Netzwerk „ASIATECH Asiatech Data Transmission company“. DieRouting-Status-Ansichtzeigte zum selben Abfragezeitpunkt einen viel größeren Netzwerk-Fußabdruck: 316 IPv4-Präfixe, 209.920 IPv4-Adressen und 86 beobachtete Nachbarn. Das Bild ist direkt: Der Cloud-ASN ist sichtbar, aber seine öffentliche Upstream-Grenze scheint das größere ASIATECH-Netzwerk zu sein.

Looking-Glass-Proben machen die Beziehung in tatsächlichen Pfaden sichtbar. DieLooking-Glass-Daten von RIPEstat für193.151.128.0/22, einem der von AS60077 angekündigten Präfixe, enthielten Pfade, die auf AS43754 AS60077 endeten. Einige globale Proben zeigten auch frühere Upstreams vor AS43754, aber die konsistente nahe-Ursprungs-Abhängigkeit blieb AS43754. Das ist nicht überraschend für ein Cloud-Geschäft, das an dieselbe Unternehmensinfrastrukturgruppe angeschlossen ist, aber es ist wichtig, weil ein Fehler an dieser Grenze viele Dienste gleichzeitig betreffen kann.

Das bedeutet nicht, dass AS60077 fragil ist. Eine einzelne sichtbare Upstream-Beziehung kann völlig vernünftig sein, wenn das Mutter-Netzwerk Carrier-Erreichbarkeit, betriebliche Disziplin und genügend Redundanz hinter den Kulissen hat. Es bedeutet auch nicht, dass AS43754 nur einen externen Pfad hat; RIPEstat zeigte viele Nachbarn für AS43754. Der wichtige Punkt ist enger gefasst: Öffentliche BGP-Beweise beweisen nicht, dass AS60077 selbst mehrere unabhängige Upstreams, separate physische Eingänge, separate Edge-Router oder unabhängige Failover außerhalb von AS43754 hat.

Kunden sollten AS43754 als die sichtbare Upstream-Betriebsgrenze behandeln, es sei denn, Cloud.ir liefert produkt-spezifische Beweise für eine weitere Trennung.

RPKI beantwortet eine andere Frage. DieRPKI-Validierung von RIPEstat für193.151.128.0/22, das von AS60077 stammt, gab einen gültigen Status mit Route-Origin-Autorisierungen zurück, die AS60077 abdecken. Das ist eine positive Routing-Hygiene: Es unterstützt die Legitimität des Route-Origin. Es beweist nicht die Verkehrskapazität, Routendiversität, Stromkontinuität, Kundenisolationsqualität, Backup-Wiederherstellbarkeit oder Support-Reaktion. Eine RPKI-gültige Route kann immer noch versehentlich zurückgezogen, von einem Upstream gefiltert, durch einen Cross-Connect-Ausfall isoliert oder durch einen Server-seitigen Ausfall unbrauchbar gemacht werden.

Installierte Kapazität ist nicht dasselbe wie nutzbare Cloud-Kapazität

Cloud-Käufer sehen tendenziell Ressourcenschieberegler. Der Betreiber sieht den Bestand. CPU, Speicher, Festplatte, Backup-Speicher, öffentliche Adressen, Firewall-Status, Überwachung, Port-Kapazität, Host-Stromaufnahme und Personalzeit müssen alle zusammenpassen, bevor ein Ressourcenschieberegler zu einem funktionierenden Server wird. Die öffentlichen Seiten von Cloud.ir sind nützlich, weil sie einige dieser Zutaten offenlegen, aber sie zeigen nicht den Lagerbestand an.

DiePreisseitelistet Pakete mit festgelegtem Arbeitsspeicher, Prozessor, Festplatten- und Traffic-Mengen auf. Sie listet auch separate stündliche Komponenten für die Cloud-Infrastruktur, einschließlich Backup-Zeitpläne. Das reicht aus, um zu zeigen, dass Cloud.ir den Dienst als bepreisten Ressourcenpool verkauft. Es reicht nicht aus, um zu zeigen, wie viele Hosts im Pool sind, wie viele für Failover reserviert sind, welche Festplattenleistung bei Konflikten verfügbar ist, ob Backup-Speicher an einem anderen Standort liegt, wie schnell eine beschädigte Instanz neu erstellt werden kann oder ob der Anbieter eine große Bestellung während eines Hardware-Engpasses erfüllen kann.

Die Netzwerkzahlen liefern eine äußere Grenze, keine Serveranzahl. DieAngekündigte-Präfixe-Liste von RIPEstat für AS60077zeigte im letzten Abfragezeitraum 18 IPv4-Präfixe, darunter mehrere/22,/23und/24Bereiche. Die 14.080 IPv4-Adressen, die in der Routing-Status-Ansicht gesehen wurden, sind echte öffentliche Adresskapazität, aber Adressen entsprechen nicht virtuellen Maschinen. Einige Adressen dienen Routern, Load Balancern, Firewalls, Nameservern, Kundeninstanzen, Verwaltungsfunktionen oder Reservepools. Ein einzelner Server kann mehrere Adressen verwenden; viele Dienste können hinter einer Adresse sitzen; ungenutzte Adressen können mit einem vollen Compute-Cluster koexistieren.

Die gleiche Vorsicht gilt für die IPv6-Referenzen von Cloud.ir. Die Preisseite zeigt IPv6 auf VPS-Paketkarten an. Die hier verwendete RIPE-Routing-Status-Abfrage zeigte keinen sichtbaren IPv6-Raum für AS60077 zum Abfragezeitpunkt. Das beweist nicht, dass IPv6 im Produkt fehlt: IPv6 kann durch eine andere Vereinbarung bereitgestellt, nur in bestimmten Plänen sichtbar, in anderen Collectoren sichtbar oder auf Drittanbieter-Routing-Seiten anders dargestellt werden.

Es bedeutet, dass ein Kunde, der natives IPv6 benötigt, die tatsächliche Zuweisung, das Routing, das Firewall-Verhalten, den Reverse-DNS, die Backup-Erreichbarkeit und die Support-Eskalation testen sollte, anstatt sich auf ein Paketetikett allein zu verlassen.

Cloud.irs eigene Produktsprache trennt auch Kapazität von Belastbarkeit. Die Cloud-Server-Seite sagt, dass Ressourcen sofort erhöht oder verringert werden können und dass, wenn ein Server nicht verfügbar wird, Daten automatisch von einem anderen Server verfügbar gemacht werden. Die Cloud-Rechenzentrumsseite sagt, dass gespeicherte Daten in mehreren Rechenzentren gehalten werden und dass andere Rechenzentren die Konnektivität bewahren, wenn eines Probleme hat. Das sind wichtige Behauptungen. Sie benötigen auch Präzision. Welche Dienste sind abgedeckt?

Erfolgt die Übertragung automatisch für alle Servertypen oder nur für Daten, die durch eine bestimmte Speicherebene geschützt sind? Werden zwei Rechenzentren standardmäßig genutzt oder nur, wenn der Kunde sie konfiguriert? Ist das Backup heiß, warm oder kalt? Gibt es eine getestete Wiederherstellungszeit? Sind Gutschriften verfügbar, wenn die Automatisierung fehlschlägt?

Ohne diese Antworten sollte ein Käufer „installiert“ und „nutzbar“ getrennt halten. Installierte Kapazität ist die Sammlung von Hosts, Racks, Speicherarrays, Verbindungen und Adressen, die der Anbieter besitzt oder least. Nutzbare Kapazität ist das, was der Kunde jetzt zuweisen kann, ohne einen Host zu überlasten, einen Adresspool zu erschöpfen, eine Platzierungsregel zu verletzen oder von einem müden Techniker abhängig zu sein, der nach Mitternacht ein Teil austauscht. Die öffentlichen Seiten von Cloud.ir beweisen ein bepreistes Cloud-Produkt und ein sichtbares Netzwerk.

Sie legen nicht genug offen, um dies in eine Kapazitätsreserve umzuwandeln.

Die SLA schränkt das Versprechen genau an den Punkten ein, die ein Fehler testen wird

Cloud.ir veröffentlicht eineSLA-Seite, und das ist für Kunden gut, weil es einen Teil des Risikogesprächs in öffentlichen Text verschiebt. Der wichtigste Teil der Seite ist nicht eine große Verfügbarkeitszahl; es sind die Einschränkungen. Die Seite sagt, dass die Verfügbarkeitsgarantie nur während des normalen Betriebs für Netzwerk- und Cloud-Server-Verfügbarkeit gilt. Sie schließt die Serversoftware des Kunden, Betriebssysteme, Konfigurationsprobleme, Denial-of-Service-Angriffe gegen einen Cloud-Server, ausgesetzte oder gestoppte Server, Ausfälle, die nicht das Netzwerk oder den Host-Server betreffen, sowie vorab angekündigte Wartungs- oder kritische Patches aus.

Dieselbe Seite definiert die mittlere Reparatur- oder Wiederherstellungszeit als die durchschnittliche Zeit zur Wiederherstellung des Dienstes basierend auf der Vereinbarung zwischen Anbieter und Kunde. Sie listet dann Fälle auf, die keine Strafen nach sich ziehen, einschließlich höherer Gewalt, Ausrüstung des Kunden, geplanter Ausfallzeiten, vom Kunden angeforderter Unterbrechung, Rechtsverstöße oder Verstöße gegen die SLA, Nichtzahlung und Anordnungen von Justiz- oder Sicherheitsbehörden. Diese Ausschlüsse sind im Hosting nicht ungewöhnlich, aber sie sind entscheidend für einen Kunden, der versucht, das Risiko zu messen.

Sie verschieben viele reale Ausfälle außerhalb einer einfachen Verfügbarkeitsüberschrift.

Betrachten Sie einen Softwarefehler. Wenn das Gastbetriebssystem nach einem Kunden-Update ausfällt, legt der SLA-Text nahe, dass das Problem außerhalb der Verfügbarkeitsgarantie des Anbieters liegt, selbst wenn der Kunde einen vollständigen Dienstausfall erlebt. Das ist vernünftig, wenn Cloud.ir nicht verwaltete Rechenleistung verkauft hat, aber es bedeutet, dass der Käufer separate Wiederherstellungsrechte benötigt: Konsolenzugang, Rescue-Boot, Snapshots, Image-Export, Rollback, Wiederaufbau und klare Support-Grenzen. Ein „Cloud-Server“ ist keine verwaltete Anwendungskontinuität, es sei denn, der Vertrag sagt dies ausdrücklich.

Betrachten Sie ein Denial-of-Service-Ereignis. Die Cloud-Server-Seite bewirbt Cloud-Firewall-Steuerungen und Angriffsmeldung. Die SLA-Seite schließt Denial-of-Service-Angriffe gegen den Cloud-Server von der Verfügbarkeitsgarantie aus. Das Produkt kann dennoch helfen, den Verkehr zu mildern, aber der Kunde sollte nicht davon ausgehen, dass jede angriffsbedingte Unterbrechung eine Entschädigung schafft.

Die Frage wird praktisch: Welches Verkehrsvolumen kann die Firewall bewältigen, was wird an der Cloud-Grenze gefiltert, was erreicht die Instanz, wer kann Filter während eines Angriffs ändern, und wann kann Cloud.ir ein Ziel aussetzen oder drosseln, um andere Kunden zu schützen?

Betrachten Sie die Abrechnung. Der SLA-Ausschluss für Nichtzahlung ist üblich, aber das operationelle Risiko ist nicht trivial. Ein vorausbezahltes Wallet, eine fehlgeschlagene inländische Zahlung, ein Problem mit einer Firmenbankkarte oder eine umstrittene Rechnung kann zu einem Infrastrukturereignis werden, wenn Server ausgesetzt werden, bevor ein Betreiber das Konto klärt.

Ein Unternehmen, das Cloud.ir für die Produktion nutzt, sollte fragen, wie viele Erinnerungen gesendet werden, welche Gnadenfrist gilt, welche Datenaufbewahrung nach der Aussetzung folgt, ob Snapshots zugänglich bleiben und ob der Support den Dienst vorübergehend aufrechterhalten kann, während die Abrechnungsnachweise geprüft werden.

Betrachten Sie Anordnungen öffentlicher Behörden. Die SLA sagt, dass Ausfallzeiten, die durch Justiz- oder Sicherheitsbehörden verursacht werden, außerhalb des Strafrahmens liegen. Das ist eine Lokalitätsfrage, kein Urteil über den Anbieter. Wenn sich die Arbeitslasten, Backups und Support-Konten innerhalb einer Gerichtsbarkeit befinden, muss der Kunde verstehen, wie rechtliche oder politische Anordnungen die Verfügbarkeit, den Datenzugriff, den Domain-Dienst und die Kundenkommunikation beeinflussen können.

Die Antwort kann für eine inländische iranische Website akzeptabel und für einen grenzüberschreitenden Dienst mit widersprüchlichen Compliance-Verpflichtungen inakzeptabel sein. Dieselbe physische Lokalität kann eine Stärke für die Latenz und eine Einschränkung für die Governance sein.

Die SLA schärft daher die Fragen des Käufers. Sie macht Cloud.ir nicht schwächer; sie macht die Dienstform besser erkennbar. Der Kunde sollte zwischen Netzwerkverfügbarkeit, Host-Verfügbarkeit, Gästegesundheit, Speicherintegrität, Backup-Wiederherstellbarkeit, CDN-Verhalten, Kontostatus und rechtlichen Einschränkungen unterscheiden. Die öffentliche SLA fasst diese Ebenen nicht in einem Versprechen zusammen. Das sollte auch ein Produktionskäufer nicht tun.

CDN, Speicher und Cloud-Switching erweitern die Schadensradius sowie die Funktionspalette

Die CDN-, Speicher- und virtuellen Netzwerkdienste von Cloud.ir sind nützlich, weil sie die Last auf einem einzelnen Ursprungsserver reduzieren und Kunden mehr Architekturoptionen geben. Sie machen die Abhängigkeitskarte auch breiter. DieCDN-Seitesagt, dass die inländische Verteilung Anfragen über lokale Rechenzentren beantworten und den Datenverkehr für inländische Nutzer zum halben Preis anbieten kann; sie beschreibt auch, wie Benutzer zu näheren Servern geleitet, Inhalte komprimiert und zwischengespeichert, Anfragen und Antworten überwacht, Zugriffsbeschränkungen nach Land und Schutz vor Angriffen ermöglicht werden. Das ist eine echte Produktgeschichte, aber sie verwandelt eine Website in eine Kette: DNS, CDN-Edge, Cache-Zustand, Erreichbarkeit des Ursprungs, Zertifikatsverwaltung, Kontokonfiguration und Support müssen alle zusammenarbeiten.

Wenn der Ursprungsserver ausfällt, kann das CDN weiterhin zwischengespeicherte statische Inhalte ausliefern. Es kann auch veraltete Inhalte ausliefern, bei dynamischen Routen fehlschlagen oder die Fehlerrate erhöhen, wenn Cache-Fehlschläge einen nicht gesunden Ursprung treffen. Wenn ein CDN-Edge die Upstream-Erreichbarkeit verliert, können Benutzer in einer Region Fehler sehen, während andere keine sehen. Wenn Zugriffsregeln falsch konfiguriert sind, kann eine Lokalitätsfunktion zu einem Verfügbarkeitsproblem werden.

Der Kunde benötigt Cache-Bereinigungssteuerungen, Ursprungs-Schildverhalten, Protokolle, Fail-Open- oder Fail-Closed-Regeln, Sichtbarkeit der Zertifikatserneuerung und eine Möglichkeit, DNS wegzubewegen, wenn der CDN-Dienst selbst zum Fehler wird.

Das Speicherangebot hat eine andere Risikoform. DieCloud-Speicherseitesagt, dass der Dienst es Kunden ermöglicht, die Kapazität zu skalieren, Dateien zu verwalten, Zugriffsschlüssel zu verwalten, Speicher mit Domänen zu verbinden, Dateien zu teilen und Zugriffsebenen zu definieren. Sie sagt auch, dass Daten durch Verteilung auf mehrere Server geschützt werden. Das ist wertvoll, aber die Speicherdauerhaftigkeit ist von außen nicht sichtbar. Ein Kunde muss wissen, ob der Dienst Objektspeicher, Blockspeicher, Dateispeicher oder eine Mischung ist; was Replikation bedeutet; ob Replikate in einem Raum oder mehreren Standorten sitzen; wie Löschungen geschützt sind; ob Versionierung existiert; wie Schlüssel rotiert werden; wie die Wiederherstellung getestet wird; und wie schnell ein vollständiger Export abgeschlossen werden kann.

Der Cloud-Switch-Dienst ist ebenso wichtig. DieCloud-Switch-Seitebeschreibt verwaltetes Networking zwischen Cloud-Servern und Rechenzentren, das den Datenverkehr leitet und private Netzwerke erstellt. Sie sagt auch, dass der Dienst verfügbare alternative Ressourcen identifizieren und bei Störungen automatisch umschalten kann. Diese Art von Funktion kann die manuelle Wiederherstellung reduzieren, wenn sie gut implementiert ist. Sie kann auch zu einem Single Point of Change werden, wenn eine Fehlkonfiguration des privaten Netzwerks eine Gruppe von Servern isoliert, die ansonsten gesund bleiben.

Das tiefere Muster ist, dass eine Funktion sowohl eine Belastbarkeitsschicht als auch eine neue Abhängigkeit sein kann. Backups schützen Daten nur, wenn sie außerhalb der ausfallenden Grenze gespeichert und schnell wiederhergestellt werden können. CDN schützt den Ursprung nur, wenn Inhalte korrekt bereitgestellt werden können, wenn der Ursprung schwach ist. Virtuelles Networking schützt den Ost-West-Verkehr nur, wenn die Steuerungsebene und die Switching-Fabric gesund bleiben. Cloud-Firewalls schützen Kunden nur, wenn Filteränderungen unter Druck sicher vorgenommen werden können.

Der Kunde sollte nicht fragen, ob diese Funktionen abstrakt existieren. Er sollte fragen, wie sich jede Funktion verhält, wenn ein Host, Rack, eine Route, ein Speichercluster, ein Konto oder eine Support-Warteschlange bereits ausfällt.

Lokalität ist ein Produktmerkmal, kein Slogan

Datenlokalität ist einer der stärksten Gründe, bei Cloud.ir zu kaufen. Die Unternehmensseiten stellen die Cloud-Infrastruktur auf ASIATECH-Rechenzentren im Iran, die CDN-Seite betont inländische Verteilungsoptionen, und die Netzwerkbeweise zeigen die öffentliche Cloud-Site auf AS60077 mit einem iranischen ASIATECH-Mutter-Netzwerk. Für iranische Benutzer und Unternehmen kann das niedrigere Latenz, inländische Zahlungsabstimmung, vertraute Support-Sprache, lokale Verkehrsökonomie und einen Anbieter bedeuten, dessen physischer Bestand in der Nähe der Zielgruppe ist.

Aber Lokalität muss pro Dienst definiert werden. Ein virtueller Server kann im Iran laufen, während ein E-Mail-Relay, eine Verwaltungskonsole, ein Analysedienst, ein Backup-Kopie oder ein Support-Anhang einen anderen Weg nimmt. Ein CDN-Produkt kann inländische und internationale Verteilungsmodi anbieten. Ein Speicherdienst kann über mehrere Server replizieren, ohne zu sagen, ob diese Server in getrennten Gebäuden stehen. Ein Kunde kann den genauen Standort jeder Kopie von Daten nicht aus der Firmenadresse, der Top-Level-Domain, dem autonomen Systemnamen oder dem Satz „Rechenzentren im ganzen Iran“ ableiten.

Cloud.irs eigene Regionenzeile für ein kundenorientiertes Profil kann global sein, weil die IP-Erreichbarkeit global ist und Cloud-Kunden überall mit einem funktionierenden Konto und Netzwerkpfad sein können. Das ist etwas anderes als zu sagen, dass das Unternehmen globale Regionen betreibt. Die hier geprüften öffentlichen Produktbeweise weisen am stärksten auf iranische Infrastruktur und den inländischen Rechenzentrumsbestand von ASIATECH hin. Wenn ein Kunde einen reinen Iran-Dienst benötigt, sollte er eine schriftliche Erklärung zu Compute, Speicher, Backup, Protokoll- und Supportzugriffslokalität anfordern.

Wenn ein Kunde länderübergreifende Kontinuität benötigt, sollte er fragen, ob Cloud.ir dies selbst bereitstellt oder ob der Kunde es mit einem anderen Anbieter aufbauen muss.

Lokalität verändert auch die Reaktion auf Vorfälle. Eine inländische iranische Inhaltsseite könnte das inländische CDN-Verhalten und die ASIATECH-Einrichtungen von Cloud.ir bevorzugen, weil die meisten Benutzer in der Nähe dieser Pfade sitzen. Ein internationaler SaaS-Anbieter könnte sich Sorgen um Zahlungszugang, Sanktionsrisiko, Latenz für ausländische Benutzer, Routenfilterung, Streitbeilegung und die Fähigkeit machen, Daten unter Druck zu exportieren.

Ein öffentlicher oder regulierter Nutzer könnte die lokale Einrichtungskontrolle schätzen, benötigt aber eine strengere Aussage darüber, wer auf Daten zugreifen kann, wo Snapshots liegen und wie Anordnungen von Behörden behandelt werden. Dieselbe Infrastruktur kann für einen Kunden gut geeignet und für einen anderen ungeeignet sein.

Der praktische Test ist Evidenz. Fragen Sie nach den Regions- und Standortoptionen, die im Kundenpanel verfügbar sind. Fragen Sie, ob zwei Instanzen in getrennten Einrichtungen platziert werden können. Fragen Sie, wo geplante Backups gespeichert werden. Fragen Sie, wo CDN-Protokolle und Speichermetadaten aufbewahrt werden. Fragen Sie, ob Support-Ingenieure auf Kundendatenträger, Snapshots, Schlüssel oder Konsolen zugreifen können und von wo. Fragen Sie, ob ein vollständiger Export abgeschlossen werden kann, ohne das Konto für einen weiteren langen Abrechnungszyklus aktiv zu halten.

Ein Anbieter, der diese Fragen ruhig beantworten kann, ist leichter zu vertrauen als einer, der sich nur auf allgemeine Lokalitätssprache stützt.

Die Hauptfehlerpfade verlaufen über Rack, Route, Hardwarebestand, Kontostatus und Migration

Der wahrscheinlichste Cloud.ir-Fehler, für den ein Kunde planen sollte, ist kein dramatischer Totalausfall. Es ist ein Teilausfall, der zwischen den vertraglichen Ebenen liegt. Ein VM kann in Ordnung sein, während eine Upstream-Route beeinträchtigt ist. Eine Route kann in Ordnung sein, während die Speicherleistung zusammenbricht. Ein Backup kann existieren, während der Wiederherstellungsdurchsatz zu langsam ist. Ein CDN kann statische Inhalte beantworten, während dynamische Funktionen fehlschlagen. Ein Kundenpanel kann erreichbar sein, während die Zahlung einen Wiederaufbau verhindert.

Diese mittleren Zustände sind es, in denen Kunden erfahren, ob der Dienst genügend operative Details dahinter hat.

Der Rack-Pfad beginnt mit physischer Hardware. Ein Host-Ausfall kann einen gut gestalteten VM auf einen anderen Host verschieben, wenn es gemeinsamen Speicher, freie Host-Kapazität und funktionierende Orchestrierung gibt. Er kann auch einen Kunden auf ein Teil warten lassen, wenn lokaler Speicher, Bare-Metal-Zuweisung oder eine nicht redundante Komponente betroffen sind. Öffentliche Cloud.ir-Seiten legen die Hypervisor-Plattform, Host-Klasse, lokale versus gemeinsame Speicheroptionen oder Ersatzhardware-Politik nicht offen.

Kunden sollten fragen, was passiert, wenn ein physischer Server ausfällt, welche Dienste automatisch neu starten, welche ein Ticket erfordern und ob es eine garantierte maximale Zeit gibt, um auf gleichwertiger Hardware neu aufzubauen.

Der Upstream-Pfad beginnt mit der sichtbaren Abhängigkeit von AS60077 von AS43754. Wenn AS43754 eine Route filtert, ein Edge-Problem hat, eine Richtlinie ändert oder einen breiteren Vorfall erleidet, können Dienste von AS60077-Kunden betroffen sein, selbst wenn die Kunden-VMs eingeschaltet sind. Da öffentliche Daten AS43754 als beobachtete Upstream-Grenze für AS60077 zeigen, sollte der Kunde fragen, ob der Cloud-ASN separate physische Edge-Router, mehrere Übergaben zu AS43754, direkten externen Transit und aktuelle Failover-Tests hat.

Es reicht nicht zu sagen, dass das Mutter-Netzwerk viele Nachbarn hat; die relevante Frage ist, was an der Cloud-Grenze passiert.

Der Hardwarebestandspfad betrifft Wachstum und Reparatur. Stündliche Cloud-Preise und sofortige Skalierung sind nur nützlich, wenn es freie CPU-Kerne, RAM, Festplatten, Adressen und Switch-Ports gibt. Ein Käufer, der eine Kampagne, Veranstaltung, Einführung oder Migration plant, sollte fragen, ob Kapazität reserviert werden kann, ob große Erhöhungen eine Vorankündigung erfordern und ob der Anbieter zusätzliche Kapazität in einer separaten Fehlerdomäne platzieren kann. Ein kleinerer Käufer sollte eine einfachere Frage stellen: Wenn mein aktueller Host ausfällt, gibt es bereits genügend freien Platz, um meinen Server woanders neu zu starten?

Der Support-Pfad betrifft Zeit und Autorität. Cloud.ir sagt, dass Cloud-Server-Kunden rund um die Uhr Tickets einreichen können. Das ist besser als ein enger Geschäftszeitenkanal, aber der Kunde benötigt dennoch Eskalationsziele. Wer kann eine BGP-Route ändern? Wer kann einen Rack-Besuch autorisieren? Wer kann ein gelöschtes Backup wiederherstellen? Wer kann eine Kontosperrung rückgängig machen? Wer kann eine rechtliche oder sicherheitsrelevante Anordnung erklären? Wenn das Support-Team der ersten Stufe nur eine Anfrage weiterleiten kann, umfasst die Reparaturzeit jede Übergabe.

Der Migrationspfad ist das letzte Sicherheitsnetz. Ein Kunde kann schwächere Beweise tolerieren, wenn er schnell gehen kann. Das erfordert aktuelle Backups, exportierbare Images oder Dateien, dokumentierte IP- und DNS-Änderungsverfahren, bekannte TTLs, Konto-Zugriff, der während Abrechnungsstreitigkeiten verfügbar bleibt, und genügend Bandbreite, um Daten zu verschieben. Es erfordert auch, versteckte Lock-Ins zu vermeiden: private Netzwerkadressen, die nicht reproduziert werden können, Speicherfunktionen ohne Exportpfad, CDN-Regeln, die nicht anderswo neu erstellt werden können, oder Snapshots, die nicht heruntergeladen werden können.

Die öffentlichen Cloud.ir-Seiten beschreiben Wiederaufbau, Backups und Kontooperationen, aber sie legen keine vollständigen Portabilitätsbedingungen offen. Produktionsnutzer sollten diese erhalten, bevor sie sie benötigen.

Was ein Käufer überprüfen sollte, bevor er sich auf Cloud.ir verlässt

Die erste Überprüfungsaufgabe ist die Platzierung. Cloud.ir sollte sagen können, welche Dienste in welchen iranischen Standorten platziert werden können, ob ein Standort ein bestimmtes Gebäude, eine Halle oder eine logische Bezeichnung ist und ob zwei Instanzen getrennt gehalten werden können. Wenn die Antwort ist, dass die Cloud sich darum kümmert, sollte der Kunde eine Fehlerdomänenbeschreibung in einfacher Sprache anfordern. Ein kleiner Anbieter benötigt keine Hyperscale-Terminologie, um zuverlässig zu sein, aber er benötigt ehrliche Grenzen.

Die zweite Aufgabe ist die Netzwerkdiversität. AS60077 ist sichtbar und legitim, und AS43754 ist ein beträchtliches Mutter-Netzwerk. Das ist ein guter Ausgangspunkt. Es ist nicht dasselbe wie der Beweis, dass der Kundenverkehr ein AS43754-Edge-Ereignis überleben kann. Fragen Sie nach dem normalen Pfad, dem Backup-Pfad, dem Edge-Router-Design, der DDoS-Handhabungsgrenze, den RPKI- und Route-Filtering-Praktiken und ob Cloud.ir vorübergehend ein Kundenpräfix ankündigen oder eine öffentliche Adresse während eines Vorfalls verschieben kann. Für die meisten VPS-Kunden wird die Antwort nein sein, aber die Frage klärt die Abhängigkeit.

Die dritte Aufgabe ist der Nachweis der Wiederherstellung. Backups sind als Produktfunktionen aufgeführt, und die Preisseite unterscheidet wöchentliche, dreitägige und tägliche Backup-Komponenten. Der Kunde sollte fragen, wie Snapshots geplant werden, was erfasst wird, was nicht erfasst wird, wo Backup-Kopien gespeichert werden, wie lange sie aufbewahrt werden, welche Wiederherstellungszeit typisch ist, ob eine Wiederherstellung auf einen anderen Standort abzielen kann und ob der Anbieter aktuelle Wiederherstellungstests hat. Ein Backup, das die beschädigte Grenze nicht verlassen kann, ist nur gegen eine enge Klasse von Fehlern versichert.

Die vierte Aufgabe sind Wartung und Ausschlüsse. Die SLA schließt angekündigte Wartungs- und kritische Patches von der Verfügbarkeitsberechnung aus. Fragen Sie, wie Wartung angekündigt wird, wie viel Vorlauf gegeben wird, ob Notfallarbeiten ohne normale Vorankündigung durchgeführt werden können, ob der Kunde ein Fenster wählen kann und ob mehrere Kundenressourcen gemeinsam gewartet werden. Ein Wartungsfenster ist nicht schlecht; ein unklares Fenster ist schlecht.

Die fünfte Aufgabe ist die Kontinuität des Kontos. Da Nichtzahlung außerhalb des SLA-Strafrahmens liegt, sollten Produktionskäufer die Wallet-Finanzierung, den Rechnungszeitpunkt, Aussetzungsschwellenwerte, Einspruchswege und die Datenaufbewahrung nach der Aussetzung verstehen. Dies ist besonders wichtig für Teams außerhalb Irans, Teams mit Beschaffungsverzögerungen und Teams, deren Zahlungszugang von einer Person abhängt. Ein Abrechnungsfehler kann zu einem vermeidbaren Ausfall werden.

Die sechste Aufgabe ist der Ausstieg. Exportieren Sie ein kleines Server-Image, stellen Sie ein Backup in einer sauberen Instanz wieder her, bewegen Sie einen DNS-Eintrag vom CDN weg, erstellen Sie eine Firewall-Richtlinie anderswo neu und dokumentieren Sie die Zeit. Diese Tests müssen nicht groß sein, um aufschlussreich zu sein. Sie zeigen, ob die Abstraktionen des Anbieters dem Kunden helfen, sich zu erholen, oder hauptsächlich dem Kunden helfen, zu bleiben.

Die Betriebsthese: echter Dienst, starke Netzwerksichtbarkeit, unvollständiger physischer Nachweis

CLOUD Asre Dadeha Asiatech verdient ein höheres Vertrauensniveau als ein Unternehmen mit nur einem veralteten Routing-Eintrag. Cloud.ir ist aktiv, der Dienstekatalog ist spezifisch, die Preisseite legt konkrete Ressourcenpakete offen, die SLA ist öffentlich und RIPE-Einträge platzen AS60077 als AT-CLOUD Asre Dadeha Asiatech in die öffentliche Routing-Tabelle. DNS für die Unternehmenssite zeigt auf AS60077. AS60077 hat einen sichtbaren Adressbestand, und seine Abhängigkeit vom Mutter-Netzwerk AS43754 ist beobachtbar, nicht versteckt.

Das macht den Dienst nicht vollständig transparent. Die öffentliche Aufzeichnung zeigt nicht die genaue Rechenzentrumsplatzierung von Kundenarbeitslasten, die Anzahl der verfügbaren Hosts, die Menge an Ersatzhardware, die reale Wiederherstellungszeit, den Standort jedes Backups, die physische Diversität von Routen, das Route-Failover-Design an der Cloud-Grenze oder die Konto- und Migrationsbedingungen, auf die ein Kunde bei einem Streit angewiesen wäre. Cloud.irs eigenes Marketing macht starke Aussagen über Verfügbarkeit und Datenpersistenz, während seine SLA praktische Grenzen für das zieht, was abgedeckt ist.

Die richtige Lesart ist daher ausgewogen. Das Produkt existiert. Das Netzwerk ist sichtbar. Die physische Abhängigkeit ist real. Ein Käufer kann Cloud.ir vernünftigerweise für Arbeitslasten in Betracht ziehen, die von der Nähe zu iranischen Rechenzentren, der inländischen Infrastruktur von ASIATECH und einem lokalen Cloud-Steuerfeld profitieren. Derselbe Käufer sollte vermeiden, das Cloud-Etikett als Beweis für Multi-Site-Resilienz, Routendiversität oder nahtlosen Ausstieg zu behandeln. Das sind technische und vertragliche Fakten, die eingeholt, getestet und schriftlich festgehalten werden müssen.

Für eine kleine Website mag die verbleibende Unsicherheit akzeptabel sein, wenn Backups unabhängig sind und DNS schnell bewegt werden kann. Für ein stark frequentiertes iranisches Medienobjekt können das CDN und das inländische Hosting wertvoll sein, aber der Betreiber sollte einen Ursprungsfehler, das Cache-Verhalten und die Support-Eskalation vor dem Start testen. Für regulierte oder grenzüberschreitende Daten sind die Schlüsselfragen Lokalität, Behördenexposition, Support-Zugriff und Exportrechte.

Für jeden Produktionskunden ist die letzte Disziplin dieselbe: Kaufen Sie den Cloud-Dienst, aber prüfen Sie die Geschichte hinter Rack, Route, Reparatur und Migration.