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

Zusammenfassung

• Cloud.ir verschafft CLOUD Asre Dadeha Asiatech eine echte Einzelhandelsfläche: Die Seite bietet Cloud-Server, VPS-Pläne, Cloud-Speicher, CDN, Cloud-Switching, Cloud-Rechenzentrumsdienste, ein Kundenpanel, veröffentlichte Preise und eine SLA, und die Fußzeile gibt an, dass die Seite Asre Dadeha Asiatech gehört.
• Die physische Verankerung ist enger als die Produktsprache. Cloud.ir gibt an, dass seine Infrastruktur auf den ASIATECH-Rechenzentren im Iran basiert, und die Über-Seite gibt an, dass Cloud.ir seit dem iranischen Jahr 1399 mit mehr als 20 Cloud-Produkten operiert, aber die öffentlichen Seiten identifizieren nicht das genaue Rack, die Stadt-für-Stadt-Platzierung, die Stromtopologie oder die Ergebnisse von Wiederherstellungstests hinter jeder Kunden-Workload.
• Die Netzwerknachweise sind auf der Kontrollebene solide. RIPE RDAP benennt 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 das DNS fürcloud.irentsprach einem AS60077-Präfix. Die gleiche RIPE-Ansicht zeigte einen beobachteten linken Nachbarn für AS60077: AS43754, die Firma ASIATECH Asiatech Data Transmission.
• Die Kaufentscheidung ist also nicht, ob ein Cloud-Produkt existiert. Es geht darum, ob ein bestimmter Kunde die Platzierung, die verfügbare Kapazität, die unabhängigen Routen, die Lokalität der Backups, die Eskalation des Supports, die Wartungsausschlüsse, die Abrechnungskontinuität und die 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 bleibt geschichtet

Cloud.ir ist keine ruhende Markenseite. DieStartseite von Cloud.irpräsentiert Cloud-Server, Cloud-Rechenzentrumsdienste, Cloud-Switching, CDN, Cloud-Speicher, Cloud-Domainverwaltung, eine Service-Preis-Seite, Support-Seiten und einen Kundenlogin-Pfad. Dieselbe Seite trägt eine Telefonnummer, eine E-Mail-Adresse, eine Büroadresse in Teheran und eine Fußzeilenerklärung, dass die materiellen und geistigen Rechte der Seite Asre Dadeha Asiatech gehören. Für dieses Profil ist das wichtig, weil die Identität des Unternehmens mit einer aktiven Dienstoberfläche verbunden ist, nicht nur mit einem Routing-Eintrag.

DieÜber-Seitefügt eine Service-Historie hinzu. Sie gibt an, dass Cloud.ir seinen Betrieb im iranischen Jahr 1399 aufgenommen hat und mit über 20 Cloud-Produkten zu einem der führenden Cloud-Diensteanbieter Irans geworden ist. Die genannten Produktgruppen umfassen Content-Distribution, Cloud-Computing, Cloud-Sicherheit, Cloud-Speicher, Cloud-Netzwerk und einen Cloud-Marktplatz. Diese Behauptungen sind Aussagen des Unternehmens, keine unabhängigen Kapazitätsmessungen, aber sie verdeutlichen die grundlegende Geschäftsposition: CLOUD Asre Dadeha Asiatech verkauft gehostete Kapazität an Kunden, die keine eigene physische Infrastruktur kaufen und betreiben wollen.

Das Einzelhandelsangebot ist auch spezifisch genug, um geprüft zu werden. DieCloud-Server-Seitegibt an, dass Kunden schnell einen Cloud-Server erstellen, für die genutzten Ressourcen bezahlen, Ressourcen ändern, das Netzwerk konfigurieren, IP-Adressen hinzufügen oder ändern, die Ressourcen- und Netzwerknutzung überwachen, eine Cloud-Firewall verwenden und Backups planen können. Dieselbe Seite beschreibt Optionen für Linux-, Windows- und MikroTik-Server und gibt an, dass der Support für Cloud-Server-Kunden rund um die Uhr per Ticket-Einreichung verfügbar ist. Ein Käufer muss diese Versprechen als Produktversprechen behandeln, die eine vertragliche und testweise Bestätigung erfordern, aber sie sind dennoch konkreter als eine generische Cloud-Sprache.

DiePreisseitevon Cloud.ir macht das Produkt noch überprüfbarer. Sie listet VPS-Paketnamen wie AT-VPS-B2, AT-VPS-G1 und AT-VPS-A2 mit Speicher, CPU, Festplatte, einer kostenlosen IP-Adresse, Basis-Traffic, Unterstützung für zusätzliche IPs, Rebuild-Support und IPv6 auf den Paketkarten. Sie zeigt auch eine stündliche Preisgestaltung für Cloud-Server-Ressourcen wie Speicher, CPU, Festplatte, IP, eingehenden Traffic und Backup-Stufen. Die Preisseiten sind keine technischen Zeichnungen, aber sie legen offen, wie der Dienst verpackt ist: Ein Kunde kauft endliche Einheiten von Rechenleistung, Speicher, Adresse und Traffic, die irgendwo existieren müssen, bevor das Steuerfeld sie zuweisen kann.

Das Unternehmen beschreibt auch höherwertige Dienste rund um die gleiche Infrastruktur. DieCloud-Rechenzentrumsseitebewirbt sicheres und einfaches Datenmanagement, Skalierung, Überwachung, Virtualisierung, Containerisierung und geplante Backups. DieCloud-Speicherseitepräsentiert skalierbaren Speicher, kontrolliertes Teilen und Zugriffsstufenverwaltung. DieCDN-Seitebeschreibt Content-Distribution über Haus-, Zentral- und internationale Modi, wobei Benutzeranfragen von geografisch näheren Rechenzentren bedient werden. DieCloud-Switch-Seitepräsentiert ein verwaltetes virtuelles Netzwerk zwischen Cloud-Servern und Rechenzentren. Jedes Produkt reduziert das Bedürfnis des Kunden, Ausrüstung zu besitzen; jedes führt auch eine Abhängigkeit von den Platzierungs-, Netzwerkdesign- und Supportentscheidungen des Anbieters ein.

Dies ist der nützliche Rahmen für den Rest des Artikels. CLOUD Asre Dadeha Asiatech ist keine geheimnisvolle Hülle, aber die sichtbare Dienstoberfläche beseitigt nicht die Notwendigkeit, die unteren Schichten zu testen. Ein Cloud-Server kann nur in Sekunden provisioniert werden, wenn der Anbieter bereits über die entsprechende Host-Kapazität, Speicher, öffentliche Adressen, Netzerreichbarkeit und Abrechnungsautorisierung verfügt.

Ein CDN kann eine Anfrage nur dann an einen näheren Edge weiterleiten, wenn dieser Edge existiert, aktuellen Content hat, über ausreichend Cache und Transitzufuhr verfügt und die Quelle noch erreichen kann, wenn der eigene Server des Kunden ausfällt. Ein Backup hat nur Wert, wenn es außerhalb des Fehlers wiederhergestellt werden kann, der die primäre Workload beschädigt hat. Die öffentlichen Seiten zeigen das Angebot; sie beweisen nicht von selbst jede Resilienzbehauptung, die ein Produktionskäufer benötigt.

DieÜber-Seiteist ähnlich. Sie gibt an, dass die Rechenzentren von Cloud.ir im ganzen Iran verteilt sind und seine Infrastruktur auf den ASIATECH-Rechenzentren basiert, die große und leistungsstarke Einrichtungen mit Weltstandards 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 Betriebsgrenze verschieben: Die Cloud-Marke ist abhängig vom Rechenzentrumspark und Netzwerk von ASIATECH, nicht von einer unbenannten Hyperskala-Region im Ausland.

Außerhalb der Unternehmensseiten liefern öffentliche Archive einen älteren, aber nützlichen Kontext für dieses Portfolio. centers de donnees Dynamics berichtete im Juli 2017, dass AsiaTech ein 700 Quadratmeter großes Rechenzentrum im Milad Tower im Westen Teherans eröffnet hatte. Dieser Bericht beschrieb AsiaTech als ein 2003 gegründetes privates Unternehmen, gab an, dass es 2013 eine Lizenz für Hosting, dedizierte und gemeinsame Server und Colocation erhalten hatte, und gab an, dass es fünf Rechenzentren betreibe und mehr als 430 Städte im Iran verbinde.

DataCenterMap listet derzeit das Asiatech Milad Tower Rechenzentrum und das Asiatech Azadegan Rechenzentrum in Teheran, während seine Spezifikationsseite für den Milad Tower angibt, dass keine Kapazitäts-, Strom-, Compliance-, Sicherheits- oder Gebäudedaten von Asiatech bereitgestellt wurden.

Diese externen Referenzen sind mit Vorsicht zu behandeln. Sie bestätigen, dass ASIATECH mit benannten Einrichtungen in Teheran und einer breiteren Rechenzentrumsaktivität verbunden war. Sie beweisen nicht, welche Einrichtung eine bestimmte Cloud.ir-VM, einen CDN-Edge, einen Speicher-Bucket oder eine Backup-Kopie im Juli 2026 bedient. Sie beweisen auch nicht, dass der Einrichtungszustand von 2017, die Rack-Anzahl, das elektrische Design oder die Kundenzahl unverändert geblieben sind. Die Einrichtungshistorie ist ein nützlicher Nachweis eines realen Infrastrukturunternehmens; es ist keine aktuelle Platzierungskarte.

Diese Unterscheidung ist für Kunden wichtig. Ein Käufer kann hören "Rechenzentren im ganzen Iran" und annehmen, dass zwei auf demselben Konto bestellte Server in separaten 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 Räumen in einem Gebäude oder separaten Gebäuden landen, deren städtische Glasfaser oder Upstream-Edge dennoch konvergiert. Umgekehrt könnte der Anbieter eine bessere Trennung haben, als die öffentlichen Seiten preisgeben. Die öffentlichen Seiten entscheiden nicht über die Frage.

Der Kunde muss Platzierungskontrollen, Anti-Affinitätsregeln, benannte Standorte oder Standortcodes, den Backup-Standort und anfordern, was Cloud.ir für jede Dienstebene mit "Rechenzentrum" meint.

Strom und Reparaturkräfte sind Teil derselben Frage. Cloud.ir kann zu Recht sagen, dass die Cloud-Nutzung dem Kunden die Last abnimmt, Ausrüstung zu kaufen und einen Serverraum zu unterhalten. Das löscht die physische Wartung nicht aus. Jemand muss immer noch Festplatten, Netzteile, Line Cards und Speicher ersetzen; jemand muss immer noch elektrische Arbeiten planen; jemand muss immer noch Generatoren, Batterien, Kühlung und Brandschutz testen; jemand muss immer noch eine Warnung erhalten und das Rack erreichen.

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

AS60077 ist sichtbar, und das übergeordnete Netz ist die offensichtliche Abhängigkeit

Der Netzeintrag gibt CLOUD Asre Dadeha Asiatech eine zweite konkrete Verankerung. RIPE RDAP identifiziertAS60077als AT-CLOUD und verbindet 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 Registerbeleg für ein echtes autonomes System und eine betriebliche Kontaktkette. Es beschreibt keine einzelnen Server, Kunden oder Verfügbarkeit, aber es bestätigt, dass der Cloud-Dienst seine eigene Netz-ID hat.

DerAS-Überblick für AS60077von RIPEstat meldete den Inhaber als "AT-CLOUD Asre Dadeha Asiatech" und zeigte, dass es zum Zeitpunkt der Anfrage vom 12. Juli 2026 angekündigt wurde. SeineRouting-Status-Ansichtzeigte 18 IPv4-Präfixe und 14.080 IPv4-Adressen, die von AS60077 sichtbar waren, mit der ersten Präfix-Beobachtung im Jahr 2014 und der letzten Beobachtung zum Zeitpunkt der Anfrage. Dieselbe RIPE-Ansicht zeigte eine hohe IPv4-Collector-Sichtbarkeit und keinen in dieser speziellen Statusantwort sichtbaren IPv6-Raum.

Der aktive Dienst verweist ebenfalls auf AS60077. DieDNS-Kettenansicht fürcloud.irvon RIPEstat gab193.151.157.174für den Apex-Namen zurück, und dieNetzinfo-Ansicht für diese Adresseordnete sie193.151.157.0/24und AS60077 zu. Dies beweist nicht, dass jede Kunden-Workload innerhalb desselben Präfixes ausgeführt wird; es zeigt, dass die eigene öffentliche Webpräsenz des Unternehmens von der Cloud-ASN aus bedient wird.

Die Abhängigkeit liegt in den Nachbarschaftsdaten. DieASN-Nachbarschaftsansicht für AS60077von RIPEstat zeigte einen beobachteten linken Nachbarn: AS43754. DerAS-Überblick für AS43754von RIPEstat nennt dieses Netz "ASIATECH Asiatech Data Transmission company." SeineRouting-Status-Ansichtzeigte zum gleichen Anfragezeitpunkt einen viel breiteren Netz-Fußabdruck: 316 IPv4-Präfixe, 209.920 IPv4-Adressen und 86 beobachtete Nachbarn. Das Bild ist direkt: Die Cloud-ASN ist sichtbar, aber ihre öffentliche Upstream-Grenze scheint das größere ASIATECH-Netz zu sein.

Looking-Glass-Stichproben machen die Beziehung in echten Pfaden sichtbar. DieLooking-Glass-Daten für193.151.128.0/22, einem der angekündigten Präfixe von AS60077, enthielten Pfade, die mit AS43754 AS60077 endeten. Einige globale Stichproben zeigten auch weiter entfernte Upstreams vor AS43754, aber die quellnahe Abhängigkeit blieb AS43754. Dies ist nicht überraschend für ein Cloud-Geschäft, das an die gleiche Unternehmensinfrastrukturgruppe angeschlossen ist, aber es ist wichtig, weil ein Fehler an dieser Grenze viele Dienste gleichzeitig betreffen kann.

Dies bedeutet nicht, dass AS60077 fragil ist. Eine einzige sichtbare Upstream-Beziehung kann vollkommen vernünftig sein, wenn das übergeordnete Netz Trägerreichweite, betriebliche Disziplin und ausreichende Redundanz im Hintergrund hat. Es bedeutet auch nicht, dass AS43754 nur einen einzigen externen Pfad hat; RIPEstat zeigte viele Nachbarn für AS43754. Der wichtige Punkt ist enger: Die öffentlichen BGP-Beweise belegen nicht, dass AS60077 selbst mehrere unabhängige Upstreams, separate physische Eingänge, separate Edge-Router oder einen unabhängigen Failover außerhalb von AS43754 hat.

Kunden sollten AS43754 als die sichtbare betriebliche Upstream-Grenze betrachten, es sei denn, Cloud.ir liefert produktspezifische Belege für eine zusätzliche Trennung.

RPKI beantwortet eine andere Frage. DieRPKI-Validierung für193.151.128.0/22mit Ursprung AS60077gab einen gültigen Status mit Route-Origin-Authorizations zurück, die AS60077 abdecken. Dies ist eine positive Routing-Hygiene: Es stützt die Legitimität des Routenursprungs. Es beweist keine Verkehrskapazität, Routendiversität, Stromversorgungskontinuität, Qualität der Kundenisolation, Wiederherstellbarkeit von Backups oder Support-Antwort. Eine RPKI-gültige Route kann immer noch versehentlich zurückgezogen, durch einen Upstream gefiltert, durch einen Cross-Connect-Fehler isoliert oder durch einen serverseitigen Ausfall unbrauchbar gemacht werden.

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

Cloud-Käufer neigen dazu, Ressourcen-Schieberegler zu sehen. Der Betreiber sieht einen Bestand. CPU, Speicher, Festplatte, Backup-Speicher, öffentliche Adressen, Firewall-Status, Überwachung, Port-Kapazität, Host-Stromverbrauch und Personalzeit müssen alle zusammenspielen, bevor ein Ressourcen-Schieberegler zu einem funktionierenden Server wird. Die öffentlichen Seiten von Cloud.ir sind nützlich, weil sie einige dieser Zutaten offenbaren, aber sie offenbaren nicht den Lagerbestand.

DiePreisseitelistet Pakete mit festen Mengen an Speicher, CPU, Festplatte und Traffic. Sie listet auch separate stündliche Komponenten für die Cloud-Infrastruktur auf, einschließlich Backup-Planungen. Dies 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 den Failover reserviert sind, welche Festplattenleistung bei Konkurrenz verfügbar ist, ob sich der Backup-Speicher auf einem separaten Standort befindet, wie schnell eine beschädigte Instanz neu erstellt werden kann oder ob der Anbieter eine große Bestellung bei Hardwareknappheit erfüllen kann.

Die Netzwerkkennzahlen liefern eine Außengrenze, keine Serveranzahl. DieListe der angekündigten Präfixe für AS60077zeigte 18 IPv4-Präfixe im aktuellen Anfragezeitraum, darunter mehrere/22,/23und/24Bereiche. Die 14.080 in der Routing-Status-Ansicht gesehenen IPv4-Adressen sind eine tatsächliche öffentliche Adresskapazität, aber Adressen sind nicht gleich 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 einzigen Adresse sitzen; ungenutzte Adressen können zusammen mit einem voll belasteten Rechencluster existieren.

Die gleiche Vorsicht gilt für Cloud.irs IPv6-Referenzen. Die Preisseite zeigt IPv6 auf den VPS-Paketkarten. Die hier verwendete RIPE-Routing-Status-Abfrage zeigte zum Zeitpunkt der Abfrage keinen für AS60077 sichtbaren IPv6-Raum. Dies beweist nicht, dass IPv6 im Produkt fehlt: IPv6 kann über eine andere Vereinbarung bereitgestellt werden, nur in bestimmten Tarifen verfügbar sein, in anderen Collectoren sichtbar sein oder auf Drittanbieter-Routing-Seiten anders dargestellt werden.

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

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

Ist die Übernahme automatisch für alle Servertypen oder nur für Daten, die durch eine bestimmte Speicherschicht geschützt sind? Werden standardmäßig zwei Rechenzentren verwendet 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. Die installierte Kapazität ist die Sammlung von Hosts, Racks, Speicher-Arrays, Verbindungen und Adressen, die der Anbieter besitzt oder mietet. Die 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 ersetzt. Die öffentlichen Seiten von Cloud.ir belegen einen bepreisten Cloud-Dienst und ein sichtbares Netzwerk.

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

Die SLA reduziert das Versprechen genau auf die Punkte, die ein Ausfall prüfen wird

Cloud.ir veröffentlicht eineSLA-Seite, und das ist gut für Kunden, weil es einen Teil der Risikodiskussion in öffentlichen Text verschiebt. Der wichtigste Teil der Seite ist nicht eine große Verfügbarkeitszahl; es sind die Einschränkungen. Die Seite gibt an, dass die Verfügbarkeitsgarantie nur für die Netzwerk- und Cloud-Server-Verfügbarkeit im ordentlichen Betrieb gilt. Sie schließt kundenseitige Serversoftware, Betriebssysteme, Konfigurationsprobleme, Denial-of-Service-Angriffe auf einen Cloud-Server, ausgesetzte oder gestoppte Server, andere Ausfälle als Netzwerk oder Host-Server und im Voraus angekündigte Wartung oder kritische Patches aus.

Dieselbe Seite definiert die mittlere Reparatur- oder Wiederherstellungszeit als die durchschnittliche Zeit zur Wiederherstellung des Dienstes basierend auf einer Vereinbarung zwischen Anbieter und Kunde. Sie listet dann Fälle auf, die keine Strafen nach sich ziehen, darunter höhere Gewalt, Kundenausrüstung, geplante Ausfallzeiten, vom Kunden angeforderte Unterbrechung, Verstöße gegen Gesetze oder 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 tatsächliche Ausfälle außerhalb eines einfachen Verfügbarkeitstitels.

Betrachten Sie einen Softwarefehler. Wenn das Gastbetriebssystem nach einem Kunden-Update kaputt geht, legt der SLA-Text nahe, dass das Problem außerhalb der Verfügbarkeitsgarantie des Anbieters liegt, selbst wenn der Kunde einen vollständigen Dienstausfall erleidet. Dies ist vernünftig, wenn Cloud.ir unmanaged Computing verkauft hat, aber es bedeutet, dass der Käufer separate Wiederherstellungsrechte benötigt: Konsolenzugriff, Notfall-Boot, Snapshots, Image-Export, Wiederherstellung, Rebuild und klare Support-Grenzen. Ein "Cloud-Server" ist keine verwaltete Anwendungskontinuität, es sei denn, der Vertrag sagt dies.

Betrachten Sie ein Denial-of-Service-Ereignis. Die Cloud-Server-Seite bewirbt Cloud-Firewall-Kontrollen und Angriffserkennung. Die SLA-Seite schließt Denial-of-Service-Angriffe auf den Cloud-Server von der Verfügbarkeitsgarantie aus. Das Produkt kann trotzdem helfen, den Verkehr zu mildern, aber der Kunde sollte nicht annehmen, dass jede durch einen Angriff verursachte Unterbrechung eine Entschädigung schafft.

Die Frage wird praktisch: Welches Verkehrsvolumen kann die Firewall bewältigen, was wird am Cloud-Edge gefiltert, was erreicht die Instanz, wer kann während eines Angriffs Filter ä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 betriebliche Risiko ist nicht trivial. Ein vorausbezahltes Portemonnaie, eine fehlgeschlagene Inlandszahlung, ein Problem mit der Firmenkreditkarte 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 Mahnungen gesendet werden, welche Gnadenfrist gilt, welche Datenspeicherung nach der Aussetzung erfolgt, ob Snapshots weiterhin zugänglich sind und ob der Support den Dienst vorübergehend aufrechterhalten kann, während Abrechnungsnachweise geprüft werden.

Betrachten Sie Anordnungen von Behörden. Die SLA gibt an, dass Ausfallzeiten durch Justiz- oder Sicherheitsbehörden außerhalb des Sanktionsrahmens liegen. Dies ist eine Frage der Lokalität, kein Urteil über den Anbieter. Wenn sich Workloads, Backups und Support-Konten innerhalb einer einzigen Gerichtsbarkeit befinden, muss der Kunde verstehen, wie rechtliche oder politische Anordnungen Verfügbarkeit, Datenzugriff, Domain-Dienst und Kommunikation mit dem Kunden beeinflussen können.

Die Antwort kann für eine irische Inlandswebsite 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 verfeinert also die Fragen des Käufers. Sie macht Cloud.ir nicht schwächer; sie macht die Form des Dienstes erkennbarer. Der Kunde sollte zwischen Netzwerkverfügbarkeit, Host-Verfügbarkeit, Gastzustand, Speicherintegrität, Backup-Wiederherstellbarkeit, CDN-Verhalten, Kontostatus und rechtlichen Einschränkungen unterscheiden. Die öffentliche SLA reduziert diese Schichten nicht auf ein einziges Versprechen. Ein Produktionskäufer sollte dies auch nicht tun.

CDN, Speicher und Cloud-Switching erweitern den Einflussbereich ebenso wie den Funktionsumfang

Cloud.irs CDN-, Speicher- und virtuelle Netzwerkdienste sind nützlich, weil sie die Last auf einem einzelnen Quellserver reduzieren und den Kunden mehr Architekturwahlmöglichkeiten bieten können. Sie machen die Abhängigkeitskarte auch breiter. DieCDN-Seitegibt an, dass die Hausverteilung Anfragen über lokale Rechenzentren bedienen und den Traffic für Hausnutzer zum halben Preis erstellen kann; sie beschreibt auch das Routing von Benutzern zu näheren Servern, Komprimierung und Caching von Inhalten, Überwachung von Anfragen und Antworten, länderspezifische Zugriffsbeschränkungen und Angriffsschutz. Dies ist eine echte Produktgeschichte, aber sie verwandelt eine Website in eine Kette: DNS, CDN-Edge, Cache-Zustand, Quellerreichbarkeit, Zertifikatsverwaltung, Kontokonfiguration und Support müssen alle zusammenspielen.

Wenn der Quellserver ausfällt, kann das CDN weiterhin zwischengespeicherte statische Inhalte ausliefern. Es kann auch veraltete Inhalte ausliefern, bei dynamischen Routen fehlschlagen oder die Fehlerraten erhöhen, wenn Cache-Fehlschläge eine ungesunde Quelle erreichen. Wenn ein CDN-Edge die Upstream-Erreichbarkeit verliert, sehen Benutzer in einer Region möglicherweise Fehler, während andere keine sehen. Wenn Zugriffsregeln falsch konfiguriert sind, kann eine Lokalitätsfunktion zu einem Verfügbarkeitsproblem werden.

Der Kunde benötigt Cache-Leerungssteuerungen, Fallback-Quellverhalten, Protokolle, Fail-Open- oder Fail-Closed-Regeln, Sichtbarkeit der Zertifikatserneuerung und eine Möglichkeit, DNS zu verschieben, wenn der CDN-Dienst zum Ausfall wird.

Das Speicherangebot hat eine andere Risikoform. DieCloud-Speicherseitegibt an, dass der Dienst es Kunden ermöglicht, die Kapazität zu skalieren, Dateien zu verwalten, Zugriffsschlüssel zu verwalten, Speicher mit Domains zu verbinden, Dateien zu teilen und Zugriffsstufen festzulegen. Sie gibt auch an, dass Daten durch Verteilung auf mehrere Server geschützt werden. Dies ist wertvoll, aber die Speicherhaltbarkeit ist von außen nicht sichtbar. Ein Kunde muss wissen, ob der Dienst Objektspeicher, Blockspeicher, Dateispeicher oder eine Mischung ist; was Replikation bedeutet; ob sich die Repliken in einem einzelnen Raum oder an mehreren Standorten befinden; 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 erfolgen kann.

Der Cloud-Switch-Dienst ist ebenso wichtig. DieCloud-Switch-Seitebeschreibt ein verwaltetes Netzwerk zwischen Cloud-Servern und Rechenzentren, das Verkehr leitet und private Netzwerke erstellt. Sie gibt auch an, dass der Dienst verfügbare alternative Ressourcen identifizieren und bei einer Störung automatisch umschalten kann. Diese Art von Funktionalität kann die manuelle Wiederherstellung reduzieren, wenn sie gut implementiert ist. Sie kann auch zu einem Single Point of Failure werden, wenn eine Fehlkonfiguration des privaten Netzwerks eine Gruppe ansonsten gesunder Server isoliert.

Das tiefere Muster ist, dass eine Funktion sowohl eine Resilienzschicht als auch eine neue Abhängigkeit sein kann. Backups schützen Daten nur, wenn sie außerhalb der ausgefallenen Grenze gespeichert sind und schnell wiederhergestellt werden können. Das CDN schützt die Quelle nur, wenn Inhalte korrekt ausgeliefert werden können, wenn die Quelle schwach ist. Das virtuelle Netzwerk 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 durchgeführt 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, ein Rack, eine Route, ein Speichercluster, ein Konto oder eine Support-Warteschlange bereits ausgefallen ist.

Lokalität ist ein Produktattribut, kein Slogan

Datenlokalität ist einer der stärksten Gründe, bei Cloud.ir zu kaufen. Die Unternehmensseiten platzieren die Cloud-Infrastruktur auf den ASIATECH-Rechenzentren im Iran, die CDN-Seite betont die Hausverteilungsoptionen, und die Netzwerkbeweise zeigen die öffentliche Cloud-Site auf AS60077 mit einem iranischen Mutternetz ASIATECH. Für iranische Benutzer und Unternehmen kann dies geringere Latenz, Ausrichtung der Inlandszahlungen, vertraute Support-Sprache, lokale Verkehrsökonomie und einen Anbieter bedeuten, dessen physischer Park in der Nähe des Zielpublikums liegt.

Aber die Lokalität muss pro Dienst definiert werden. Ein virtueller Server kann im Iran laufen, während ein E-Mail-Relay, eine Verwaltungskonsole, ein Analysedienst, eine Backup-Kopie oder ein Support-Anhang einen anderen Weg nimmt. Ein CDN-Produkt kann Haus- und internationale Verteilungsmodi anbieten. Ein Speicherdienst kann auf mehreren Servern replizieren, ohne zu sagen, ob diese Server sich in separaten Gebäuden befinden. Ein Kunde kann den genauen Standort jeder Datenkopie nicht aus der Firmenadresse, der Top-Level-Domain, dem Namen des autonomen Systems oder dem Satz "Rechenzentren im ganzen Iran" ableiten.

Cloud.irs eigene regionale Linie für ein käuferorientiertes Profil kann global sein, weil die IP-Erreichbarkeit global ist und Cloud-Kunden überall mit einem funktionierenden Konto und einem Netzwerkpfad sein können. Dies ist etwas anderes als zu sagen, dass das Unternehmen globale Regionen betreibt. Die hier untersuchten öffentlichen Produktbelege weisen am stärksten auf die iranische Infrastruktur und den heimischen Rechenzentrumspark von ASIATECH hin. Wenn ein Kunde einen rein iranischen Dienst benötigt, sollte er eine schriftliche Erklärung zur Lokalität von Computing, Speicher, Backup, Protokollen und Support-Zugang anfordern.

Wenn ein Kunde multiländische 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 ändert auch die Reaktion auf Vorfälle. Eine iranische Inlands-Content-Site bevorzugt möglicherweise Cloud.irs CDN-Hausverhalten und ASIATECH-Einrichtungen, weil die meisten Benutzer in der Nähe dieser Pfade sind. Ein internationaler SaaS-Anbieter könnte sich über Zahlungszugang, Sanktionsexposition, Latenz für ausländische Benutzer, Routing-Filterung, Streitbeilegung und die Fähigkeit zur Datenausfuhr unter Druck sorgen.

Ein öffentlicher oder regulierter Nutzer kann die lokale Kontrolle über die Einrichtungen schätzen, aber eine strengere Erklärung darüber benötigen, wer auf Daten zugreifen kann, wo sich Snapshots befinden 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 sind Nachweise. Fragen Sie nach den im Kundenpanel verfügbaren Regions- und Standortwahlmöglichkeiten. Fragen Sie, ob zwei Instanzen in separaten 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 Kundenfestplatten, Snapshots, Schlüssel oder Konsolen zugreifen können, und von wo aus. Fragen Sie, ob ein vollständiger Export durchgeführt werden kann, ohne das Konto für einen weiteren langen Abrechnungszyklus aktiv zu halten.

Ein Anbieter, der diese Fragen ruhig beantworten kann, ist vertrauenswürdiger als einer, der sich nur auf breite Lokalitätssprache stützt.

Die Hauptfehlerpfade führen über Rack, Route, Hardwarebestand, Kontostatus und Migration

Der wahrscheinlichste Ausfall von Cloud.ir, für den ein Kunde planen sollte, ist kein dramatischer Totalausfall. Es ist ein teilweiser Ausfall, der zwischen den Vertragsebenen liegt. Eine VM kann in Ordnung sein, während eine Upstream-Route beeinträchtigt ist. Eine Route kann in Ordnung sein, während die Speicherleistung einbricht. Ein Backup kann existieren, während die Wiederherstellungsbandbreite zu langsam ist. Ein CDN kann für statische Inhalte antworten, während dynamische Funktionen fehlschlagen. Ein Kundenpanel kann erreichbar sein, während die Zahlung einen Rebuild verhindert.

Diese Zwischenzustände sind der Punkt, an dem Kunden erfahren, ob der Dienst genügend betriebliche Details dahinter hat.

Der Rack-Pfad beginnt mit der physischen Hardware. Ein Host-Ausfall kann eine gut gestaltete VM auf einen anderen Host verschieben, wenn es gemeinsamen Speicher, Reserve-Host-Kapazität und funktionierende Orchestrierung gibt. Er kann einen Kunden auch auf ein Teil warten lassen, wenn lokaler Speicher, Bare-Metal-Zuweisung oder eine nicht redundante Komponente betroffen ist. Die öffentlichen Seiten von Cloud.ir legen die Hypervisor-Plattform, die Host-Klasse, die Wahl zwischen lokalem und gemeinsamem Speicher oder die Reserve-Hardware-Richtlinie nicht offen.

Kunden sollten fragen, was passiert, wenn ein physischer Server ausfällt, welche Dienste automatisch neu starten, welche einen Ticket benötigen und ob es eine maximale garantierte Zeit für den Wiederaufbau auf äquivalenter Hardware gibt.

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 die Kundendienste von AS60077 betroffen sein, selbst wenn die Kunden-VMs eingeschaltet sind. Da die öffentlichen Daten AS43754 als beobachtete Upstream-Grenze für AS60077 zeigen, sollte der Kunde fragen, ob die Cloud-ASN separate physische Edge-Router, mehrere Einstiegspunkte in AS43754, direkten externen Transit und aktuelle Failover-Tests hat.

Es reicht nicht zu sagen, dass das Mutternetz viele Nachbarn hat; die relevante Frage ist, was am Cloud-Edge passiert.

Der Hardwarebestands-Pfad betrifft Wachstum und Reparatur. Die stündliche Cloud-Preisgestaltung und sofortige Skalierung sind nur nützlich, wenn es Reserve-CPU-Kerne, RAM, Festplatten, Adressen und Switch-Ports gibt. Ein Käufer, der eine Kampagne, ein Ereignis, einen Start oder eine Migration plant, sollte fragen, ob Kapazität reserviert werden kann, ob große Erhöhungen 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 genug Reserveplatz, um meinen Server woanders neu zu starten?

Der Support-Pfad betrifft Zeit und Autorität. Cloud.ir gibt an, dass Cloud-Server-Kunden jederzeit Tickets einreichen können. Dies ist besser als ein enger Bürozeitenkanal, 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 aufheben? Wer kann eine rechtliche oder sicherheitsbehördliche Anordnung erklären? Wenn das Support-Team der ersten Ebene nur eine Anfrage weiterleiten kann, beinhaltet die Reparaturzeit jede Übergabe.

Der Migrationspfad ist das letzte Sicherheitsnetz. Ein Kunde kann schwächere Nachweise tolerieren, wenn er schnell gehen kann. Dies erfordert aktuelle Backups, exportierbare Images oder Dateien, dokumentierte IP- und DNS-Änderungsverfahren, bekannte TTLs, einen Kontozugang, der während Abrechnungsstreitigkeiten verfügbar bleibt, und ausreichende 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 anderswo nicht nachgebildet werden können, oder Snapshots, die nicht heruntergeladen werden können. Die öffentlichen Seiten von Cloud.ir beschreiben Rebuild, Backups und Kontovorgänge, aber sie legen die vollständigen Portabilitätsbedingungen nicht 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 an welchen iranischen Standorten platziert werden können, ob ein Standort ein separates Gebäude, ein Raum oder ein logisches Etikett ist und ob zwei Instanzen getrennt gehalten werden können. Wenn die Antwort "Unser Cloud verwaltet das" ist, sollte der Kunde eine Beschreibung der Fehlerdomäne in einfacher Sprache anfordern. Ein kleiner Anbieter benötigt keine Hyperskala-Terminologie, um zuverlässig zu sein, aber er braucht ehrliche Grenzen.

Die zweite Aufgabe ist die Netzwerkdiversität. AS60077 ist sichtbar und legitim, und AS43754 ist ein substantielles Mutternetz. Dies ist ein guter Ausgangspunkt. Es ist nicht dasselbe wie zu beweisen, dass der Kundenverkehr ein AS43754-Edge-Ereignis überleben kann. Fragen Sie nach dem normalen Pfad, dem Backup-Pfad, dem Edge-Router-Design, der DDoS-Verarbeitungsgrenze, den RPKI- und Routing-Filterpraktiken und ob Cloud.61 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 Wiederherstellungsnachweis. 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, wo Backup-Kopien gespeichert werden, wie lange sie aufbewahrt werden, wie die typische Wiederherstellungszeit ist, ob eine Wiederherstellung auf einen anderen Standort abzielen kann und ob der Anbieter aktuelle Wiederherstellungstestergebnisse hat. Ein Backup, das die beschädigte Grenze nicht verlassen kann, ist eine Versicherung nur gegen eine enge Klasse von Fehlern.

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

Die fünfte Aufgabe ist die Kontokontinuität. Da Nichtzahlung außerhalb des Sanktionsrahmens der SLA liegt, sollten Produktionskäufer die Portemonnaie-Finanzierung, den Rechnungszeitplan, die Sperrschwellen, die Rechtsbehelfe und die Datenspeicherung nach der Sperrung verstehen. Dies ist besonders wichtig für Teams außerhalb Irans, Teams mit Beschaffungsverzögerungen und Teams, deren Zahlungszugang von einer einzelnen 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, verschieben Sie einen DNS-Eintrag vom CDN weg, erstellen Sie eine Firewall-Richtlinie anderswo neu und dokumentieren Sie die Zeit. Diese Tests müssen nicht umfangreich sein, um aufschlussreich zu sein. Sie zeigen, ob die Abstraktionen des Anbieters dem Kunden bei der Wiederherstellung helfen oder hauptsächlich helfen, dass der Kunde bleibt.

Die operative These: echter Service, hohe 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 Dienstkatalog ist spezifisch, die Preisseite legt konkrete Ressourcenpakete offen, die SLA ist öffentlich, und die RIPE-Einträge platzieren AS60077 als AT-CLOUD Asre Dadeha Asiatech in der öffentlichen Routing-Tabelle. Das DNS für die Unternehmenswebsite verweist auf AS60077. AS60077 hat einen sichtbaren Adresspool, und seine Abhängigkeit vom Mutternetz AS43754 ist beobachtbar und nicht versteckt.

Dies macht den Dienst nicht vollständig transparent. Die öffentlichen Aufzeichnungen zeigen nicht die genaue Rechenzentrumsplatzierung der Kunden-Workloads, die Anzahl der verfügbaren Hosts, die Menge der Ersatzhardware, die tatsächliche Wiederherstellungszeit, den Standort jedes Backups, die physische Diversität der Routen, das Failover-Design der Cloud-Edge-Router oder die Konto- und Migrationsbedingungen, auf die ein Kunde im Streitfall angewiesen wäre. Cloud.irs eigenes Marketing macht starke Aussagen über Verfügbarkeit und Datenpersistenz, während seine SLA praktische Grenzen um das Abgedeckte zieht.

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

Für eine kleine Website kann die verbleibende Unsicherheit akzeptabel sein, wenn Backups unabhängig sind und DNS schnell bewegt werden kann. Für eine stark frequentierte iranische Medienseite können CDN und In-House-Hosting wertvoll sein, aber der Betreiber sollte Quellausfälle, Cache-Verhalten und Support-Eskalation vor dem Start testen. Für regulierte oder grenzüberschreitende Daten sind die Schlüsselfragen Lokalität, Behördenexposition, Support-Zugang und Ausfuhrrechte.

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