CLOUD Asre Dadeha Asiatech vend une capacité hébergée qui dépend toujours des racks, du transit et des fenêtres de réparation

Résumé

• Cloud.ir donne à CLOUD Asre Dadeha Asiatech une véritable surface de vente au détail: le site propose des serveurs cloud, des plans VPS, du stockage cloud, du CDN, du cloud switching, des services de centre de données cloud, un panneau client, des prix publiés et un SLA, et son pied de page indique que le site appartient à Asre Dadeha Asiatech.
• L'ancrage physique est plus étroit que le langage produit. Cloud.ir indique que son infrastructure repose sur les centres de données ASIATECH en Iran, et la page à propos indique que Cloud.ir opère depuis l'année iranienne 1399 avec plus de 20 produits cloud, mais les pages publiques n'identifient pas le rack exact, le placement ville par ville, la topologie d'alimentation ou les résultats de test de restauration derrière chaque charge de travail client.
• Les preuves réseau sont solides au niveau du plan de contrôle. RIPE RDAP nomme AS60077 comme AT-CLOUD pour Asre Dadeha Asiatech, RIPEstat a montré 18 préfixes IPv4 et 14 080 adresses IPv4 annoncés par AS60077 le 12 juillet 2026, et le DNS pourcloud.ircorrespondait à un préfixe AS60077. La même vue RIPE a montré un voisin gauche observé pour AS60077: AS43754, la société ASIATECH Asiatech Data Transmission.
• La question d'achat n'est donc pas de savoir si un produit cloud existe. Il s'agit de savoir si un client donné peut vérifier le placement, la capacité disponible, les routes indépendantes, la localité des sauvegardes, l'escalade du support, les exclusions de maintenance, la continuité de facturation et les droits de sortie avant qu'un rack, un amont, un stock de matériel ou un événement de compte ne transforme un serveur virtuel en dépendance physique.

La vitrine est publique, mais la promesse d'infrastructure reste stratifiée

Cloud.ir n'est pas une page de marque en sommeil. Lapage d'accueil de Cloud.irprésente des serveurs cloud, des services de centre de données cloud, du cloud switching, du CDN, du stockage cloud, de la gestion de domaine cloud, une page de service-prix, des pages de support et un chemin de connexion client. La même page porte un numéro de téléphone, une adresse e-mail, une adresse de bureau à Téhéran et une déclaration de pied de page indiquant que les droits matériels et intellectuels du site appartiennent à Asre Dadeha Asiatech. Pour ce profil, cela importe car l'identité de l'entreprise est liée à une surface de service active, pas seulement à un enregistrement de routage.

Lapage à proposajoute un historique de service. Elle indique que Cloud.ir a commencé ses opérations en l'année iranienne 1399 et est devenu l'un des principaux fournisseurs de services cloud d'Iran avec plus de 20 produits cloud. Les groupes de produits nommés incluent la distribution de contenu, le cloud computing, la sécurité cloud, le stockage cloud, le réseau cloud et une place de marché cloud. Ces affirmations sont des déclarations de l'entreprise, non des mesures indépendantes de capacité, mais elles clarifient la posture commerciale de base: CLOUD Asre Dadeha Asiatech vend une capacité hébergée à des clients qui ne veulent pas acheter et exploiter leur propre infrastructure physique.

L'offre de vente au détail est également suffisamment spécifique pour être inspectée. Lapage serveur cloudindique que les clients peuvent créer rapidement un serveur cloud, payer pour les ressources qu'ils utilisent, modifier les ressources, configurer le réseau, ajouter ou modifier des adresses IP, surveiller l'utilisation des ressources et du réseau, utiliser un pare-feu cloud et planifier des sauvegardes. La même page décrit les options de serveur Linux, Windows et MikroTik et indique que le support pour les clients serveur cloud est disponible via soumission de ticket 24h/24. Un acheteur doit traiter ces promesses comme des promesses produit nécessitant une confirmation contractuelle et de test, mais elles sont néanmoins plus concrètes qu'un langage générique de "cloud".

Lapage des prixde Cloud.ir rend le produit encore plus inspectable. Elle répertorie des noms de packages VPS tels que AT-VPS-B2, AT-VPS-G1 et AT-VPS-A2 avec la mémoire, le CPU, le disque, une adresse IP gratuite, le trafic de base, le support d'IP additionnelle, le support de reconstruction et IPv6 affichés sur les cartes de package. Elle montre également une tarification horaire pour les ressources de serveur cloud telles que la mémoire, le CPU, le disque, l'IP, le trafic reçu et les niveaux de sauvegarde. Les pages de prix ne sont pas des schémas d'ingénierie, mais elles exposent comment le service est conditionné: un client achète des unités finies de calcul, de stockage, d'adresse et de trafic qui doivent exister quelque part avant que le panneau de contrôle puisse les allouer.

L'entreprise décrit également des services de niveau supérieur autour de la même infrastructure. Lapage centre de données cloudcommercialise une gestion sécurisée et facile des données, la mise à l'échelle, la surveillance, la virtualisation, la conteneurisation et la sauvegarde planifiée. Lapage stockage cloudprésente un stockage évolutif, un partage contrôlé et une gestion des niveaux d'accès. Lapage CDNdécrit la distribution de contenu via des modes domestique, centralisé et international, avec les requêtes des utilisateurs servies par des emplacements de centre de données géographiquement plus proches. Lapage cloud switchprésente un réseau virtuel géré entre serveurs cloud et centres de données. Chaque produit réduit le besoin du client de posséder des équipements; chacun introduit également une dépendance aux décisions de placement, de conception réseau et de support du fournisseur.

Voilà le cadre utile pour le reste de l'article. CLOUD Asre Dadeha Asiatech n'est pas une coquille mystérieuse, mais la surface de service visible ne supprime pas le besoin de tester les couches inférieures. Un serveur cloud ne peut être provisionné en secondes que si le fournisseur dispose déjà de la capacité hôte appropriée, du stockage, des adresses publiques, de la joignabilité réseau et de l'autorisation de facturation.

Un CDN ne peut acheminer une requête vers un bord plus proche que si ce bord existe, a du contenu frais, dispose de suffisamment de cache et de capacité de transit, et peut toujours atteindre l'origine lorsque le propre serveur du client est défaillant. Une sauvegarde n'a de valeur que si elle peut être restaurée en dehors de la défaillance qui a endommagé la charge de travail primaire. Les pages publiques montrent l'offre; elles ne prouvent pas par elles-mêmes chaque affirmation de résilience dont un acheteur de production a besoin.

L'ancrage physique est la capacité des centres de données ASIATECH en Iran

La déclaration physique la plus forte de Cloud.ir est explicite: son infrastructure cloud repose sur les centres de données ASIATECH. Lapage serveur cloudindique que l'infrastructure des services cloud de Cloud.ir est déployée sur les centres de données ASIATECH, qu'elle décrit comme le plus grand réseau de centres de données en Iran. Elle énumère l'utilisation de technologies modernes, les certifications ISO27001 et TIA-942 Tier 2 et Tier 3, les systèmes de sécurité, la connectivité réseau stable, une consommation élevée de bande passante en Iran, et le support d'alimentation AC et DC. Lapage centre de données cloudrépète le même cadre de centre de données ASIATECH et indique que les centres de données Cloud.ir à travers l'Iran fournissent une infrastructure aux clients commençant la migration cloud.

Lapage à proposest similaire. Elle indique que les centres de données de Cloud.ir sont répartis à travers l'Iran et que son infrastructure repose sur les centres de données ASIATECH couvrant des installations grandes et puissantes avec des normes mondiales. Elle liste également le support AC et DC. Ces affirmations sont importantes car elles déplacent le service d'une abstraction de vente au détail pure à une frontière d'exploitation de site nommé: la marque cloud dépend du parc de centres de données et du réseau d'ASIATECH, non d'une région hyperscale à l'étranger non nommée.

En dehors des pages de l'entreprise, les archives publiques fournissent un contexte plus ancien mais utile pour cet ensemble. centres de données Dynamics a rapporté en juillet 2017 qu'AsiaTech avait ouvert un centre de données de 700 mètres carrés dans la tour Milad à l'ouest de Téhéran. Ce rapport décrivait AsiaTech comme une entreprise privée créée en 2003, indiquait qu'elle avait obtenu une licence en 2013 pour l'hébergement, les serveurs dédiés et partagés et la colocation, et indiquait qu'elle exploitait cinq centres de données et connectait plus de 430 villes à travers l'Iran.

DataCenterMap répertorie actuellement le centre de données Asiatech Milad Tower et le centre de données Asiatech Azadegan à Téhéran, tandis que sa page de spécifications de Milad Tower indique qu'aucune donnée de capacité, d'alimentation, de conformité, de sécurité ou de bâtiment n'a été fournie par Asiatech.

Ces références externes doivent être manipulées avec précaution. Elles corroborent qu'ASIATECH a été associée à des installations nommées à Téhéran et à une activité plus large de centre de données. Elles ne prouvent pas quelle installation dessert une VM particulière de Cloud.ir, un bord CDN, un bucket de stockage ou une copie de sauvegarde en juillet 2026. Elles ne prouvent pas non plus que l'état de l'installation de 2017, le nombre de racks, la conception électrique ou le nombre de clients reste inchangé.

L'historique des installations est une preuve utile d'une entreprise d'infrastructure réelle; ce n'est pas une carte de placement actuelle.

Cette distinction importe aux clients. Un acheteur peut entendre "centres de données à travers l'Iran" et supposer que deux serveurs commandés sur le même compte atterrissent dans des bâtiments séparés. Ce n'est peut-être pas le cas. Ils pourraient atterrir sur le même hôte, deux hôtes dans un rack, deux racks derrière une unité d'alimentation, deux salles dans un bâtiment, ou des bâtiments séparés dont la fibre métropolitaine ou le bord amont converge encore. Inversement, le fournisseur pourrait avoir une meilleure séparation que ce que les pages publiques divulguent. Les pages publiques ne tranchent pas la question.

Le client doit demander des contrôles de placement, des règles d'anti-affinité, des sites nommés ou des codes de site, l'emplacement de la sauvegarde, et ce que Cloud.ir entend par "centre de données" pour chaque niveau de service.

L'alimentation et la main-d'œuvre de réparation font partie de la même question. Cloud.ir peut dire à juste titre que l'utilisation du cloud évite au client le fardeau d'acheter des équipements et de maintenir une salle de serveurs. Cela ne fait pas disparaître la maintenance physique. Quelqu'un doit encore remplacer les disques, les blocs d'alimentation, les cartes de ligne et la mémoire; quelqu'un doit encore planifier les travaux électriques; quelqu'un doit encore tester les générateurs, les batteries, le refroidissement et les systèmes d'incendie; quelqu'un doit encore recevoir une alerte et atteindre le rack.

Un client n'a pas besoin de connaître chaque détail privé de la conception des installations d'ASIATECH, mais il a besoin de savoir quelles promesses de disponibilité survivent à un événement de rack, une fenêtre de maintenance électrique, une panne de stockage et une pénurie de matériel de remplacement.

AS60077 est visible, et le réseau parent est la dépendance évidente

L'enregistrement réseau donne à CLOUD Asre Dadeha Asiatech un deuxième ancrage concret. RIPE RDAP identifieAS60077comme AT-CLOUD et le lie à Asre Dadeha Asiatech via ORG-ADA42-RIPE. La même réponse RDAP inclut des contacts administratifs et techniques du NOC Asiatech à une adresse rue Miremad à Téhéran, ainsi qu'un rôle d'abus Asiatech. Il s'agit d'une preuve de registre d'un système autonome réel et d'une chaîne de contact opérationnelle. Elle ne décrit pas les serveurs individuels, les clients ou la disponibilité, mais elle confirme que le service cloud a son propre identifiant réseau.

L'aperçu AS pour AS60077de RIPEstat a rapporté le titulaire comme "AT-CLOUD Asre Dadeha Asiatech" et a montré qu'il était annoncé au moment de la requête du 12 juillet 2026. Savue de statut de routagea montré 18 préfixes IPv4 et 14 080 adresses IPv4 visibles depuis AS60077, avec la première observation de préfixe datant de 2014 et la dernière observation au moment de la requête. La même vue RIPE a montré une visibilité élevée du collecteur IPv4 et aucun espace IPv6 visible dans cette réponse de statut particulière.

Le service actif pointe également vers AS60077. Lavue de chaîne DNS pourcloud.irde RIPEstat a retourné193.151.157.174pour le nom apex, et lavue info réseau pour cette adressel'a mappée à193.151.157.0/24et AS60077. Cela ne prouve pas que chaque charge de travail client s'exécute à l'intérieur du même préfixe; cela montre que la propre présence web publique de l'entreprise est servie depuis l'ASN cloud.

La dépendance réside dans les données de voisinage. Lavue de voisin ASN pour AS60077de RIPEstat a montré un voisin gauche observé: AS43754. L'aperçu AS pour AS43754de RIPEstat nomme ce réseau "ASIATECH Asiatech Data Transmission company." Savue de statut de routagea montré une empreinte réseau beaucoup plus large au même moment de requête: 316 préfixes IPv4, 209 920 adresses IPv4 et 86 voisins observés. L'image est directe: l'ASN cloud est visible, mais sa frontière amont publique semble être le plus grand réseau ASIATECH.

Des échantillons de looking glass rendent la relation visible dans les chemins réels. Lesdonnées de looking glass pour193.151.128.0/22, l'un des préfixes annoncés de AS60077, incluaient des chemins se terminant par AS43754 AS60077. Certains échantillons globaux montraient également des amonts plus en amont avant AS43754, mais la dépendance proche de l'origine restait AS43754. Ce n'est pas surprenant pour une activité cloud attachée au même groupe d'infrastructure d'entreprise, mais cela importe car une défaillance à cette frontière peut affecter de nombreux services à la fois.

Cela ne signifie pas que AS60077 est fragile. Une seule relation amont visible peut être parfaitement raisonnable lorsque le réseau parent a une portée de transporteur, une discipline opérationnelle et une redondance suffisante en coulisses. Cela ne signifie pas non plus que AS43754 n'a qu'un seul chemin externe; RIPEstat a montré de nombreux voisins pour AS43754. Le point important est plus étroit: les preuves BGP publiques ne prouvent pas que AS60077 lui-même a plusieurs amonts indépendants, des entrées physiques séparées, des routeurs de bord séparés ou un basculement indépendant en dehors d'AS43754.

Les clients devraient traiter AS43754 comme la frontière opérationnelle amont visible à moins que Cloud.ir ne fournisse des preuves spécifiques au produit d'une séparation supplémentaire.

RPKI répond à une question différente. Lavalidation RPKI pour193.151.128.0/22originé par AS60077a retourné un statut valide avec des autorisations d'origine de route couvrant AS60077. C'est une hygiène de routage positive: cela soutient la légitimité de l'origine de la route. Cela ne prouve pas la capacité de trafic, la diversité des routes, la continuité électrique, la qualité de l'isolation client, la récupérabilité des sauvegardes ou la réponse du support. Une route valide RPKI peut encore être retirée par erreur, filtrée par un amont, isolée par une défaillance de cross-connect ou rendue inutile par une panne côté serveur.

La capacité installée n'est pas la même chose que la capacité cloud utilisable

Les acheteurs cloud ont tendance à voir des curseurs de ressources. L'opérateur voit un inventaire. CPU, mémoire, disque, espace de sauvegarde, adresses publiques, état du pare-feu, surveillance, capacité du port, consommation électrique de l'hôte et temps du personnel doivent tous s'aligner avant qu'un curseur de ressources ne devienne un serveur fonctionnel. Les pages publiques de Cloud.ir sont utiles car elles révèlent certains de ces ingrédients, mais elles ne révèlent pas le niveau de stock.

Lapage des prixrépertorie des packages avec des quantités fixes de mémoire, processeur, disque et trafic. Elle répertorie également des composants horaires séparés pour l'infrastructure cloud, y compris les planifications de sauvegarde. Cela suffit à montrer que Cloud.ir vend le service comme un pool de ressources tarifé. Cela ne suffit pas à montrer combien d'hôtes sont dans le pool, combien sont réservés pour le basculement, quelle performance de disque est disponible en cas de contention, si l'espace de sauvegarde se trouve sur un site séparé, à quelle vitesse une instance endommagée peut être recréée, ou si le fournisseur peut satisfaire une commande importante en cas de pénurie de matériel.

Les chiffres réseau fournissent une limite extérieure, pas un nombre de serveurs. Laliste des préfixes annoncés pour AS60077montrait 18 préfixes IPv4 dans la période de requête récente, incluant plusieurs plages/22,/23et/24. Les 14 080 adresses IPv4 vues dans la vue de statut de routage sont une capacité d'adresses publiques réelles, mais les adresses ne sont pas égales aux machines virtuelles. Certaines adresses servent les routeurs, les équilibreurs de charge, les pare-feu, les serveurs de noms, les instances client, les fonctions de gestion ou les pools de réserve. Un seul serveur peut utiliser plusieurs adresses; de nombreux services peuvent se trouver derrière une seule adresse; des adresses inutilisées peuvent coexister avec un cluster de calcul complet.

La même prudence s'applique aux références IPv6 de Cloud.ir. La page des prix montre IPv6 sur les cartes de package VPS. La requête de statut de routage RIPE utilisée ici n'a montré aucun espace IPv6 visible pour AS60077 au moment de la requête. Cela ne prouve pas que IPv6 est absent du produit: IPv6 peut être fourni via un arrangement différent, exposé seulement dans certains plans, visible dans d'autres collecteurs ou représenté différemment sur des sites de routage tiers.

Cela signifie qu'un client ayant besoin d'IPv6 natif devrait tester l'allocation réelle, le routage, le comportement du pare-feu, le DNS inversé, la joignabilité de la sauvegarde et l'escalade du support plutôt que de se fier à une seule étiquette de package.

Le langage produit de Cloud.ir sépare également la capacité de la résilience. La page serveur cloud indique que les ressources peuvent être augmentées ou diminuées instantanément et que lorsqu'un serveur devient indisponible, les données sont automatiquement rendues disponibles à partir d'un autre serveur. La page centre de données cloud indique que les données stockées sont conservées dans plusieurs centres de données et que d'autres centres de données préservent la connectivité si l'un d'eux a des problèmes. Ce sont des affirmations importantes. Elles nécessitent également de la précision. Quels services sont couverts?

Le transfert est-il automatique pour tous les types de serveur ou seulement pour les données protégées par une couche de stockage particulière? Deux centres de données sont-ils utilisés par défaut ou seulement si le client les configure? La sauvegarde est-elle chaude, tiède ou froide? Existe-t-il un temps de récupération testé? Des crédits sont-ils disponibles si l'automatisation échoue?

Sans ces réponses, un acheteur devrait garder "installé" et "utilisable" séparés. La capacité installée est la collection d'hôtes, de racks, de baies de stockage, de liens et d'adresses que le fournisseur possède ou loue. La capacité utilisable est ce que le client peut allouer maintenant sans surcharger un hôte, épuiser un pool d'adresses, violer une règle de placement ou dépendre d'un technicien fatigué pour remplacer une pièce après minuit. Les pages publiques de Cloud.ir prouvent un produit cloud tarifé et un réseau visible. Elles ne divulguent pas assez pour convertir cela en réserve de capacité.

Le SLA réduit la promesse exactement aux points qu'une panne mettra à l'épreuve

Cloud.ir publie unepage SLA, et c'est une bonne chose pour les clients car elle déplace une partie de la conversation sur les risques dans un texte public. La partie la plus importante de la page n'est pas un grand nombre de disponibilité; ce sont les limitations. La page indique que la garantie de disponibilité s'applique uniquement à la disponibilité du réseau et du serveur cloud en fonctionnement ordinaire. Elle exclut les logiciels serveur du client, les systèmes d'exploitation, les problèmes de configuration, les attaques par déni de service contre un serveur cloud, les serveurs suspendus ou arrêtés, les pannes autres que le réseau ou le serveur hôte, et la maintenance ou les correctifs critiques annoncés à l'avance.

La même page définit le temps moyen de réparation ou de récupération comme le temps moyen de restauration du service basé sur un accord entre le fournisseur et le client. Elle répertorie ensuite les cas qui n'entraînent pas de pénalités, y compris la force majeure, l'équipement du client, les temps d'arrêt planifiés, l'interruption demandée par le client, les violations de la loi ou du SLA, le non-paiement, et les ordres des autorités judiciaires ou de sécurité. Ces exclusions ne sont pas inhabituelles dans l'hébergement, mais elles sont décisives pour un client essayant de mesurer le risque.

Elles déplacent de nombreuses pannes réelles en dehors d'un simple titre de disponibilité.

Considérez une panne logicielle. Si le système d'exploitation invité se casse après une mise à jour client, le texte du SLA suggère que le problème est en dehors de la garantie de disponibilité du fournisseur même si le client subit une perte de service totale. C'est raisonnable si Cloud.ir a vendu du calcul non géré, mais cela signifie que l'acheteur a besoin de droits de récupération séparés: accès à la console, boot de secours, instantanés, export d'image, restauration, reconstruction et limites de support claires. Un "serveur cloud" n'est pas une continuité d'application gérée à moins que le contrat ne le dise.

Considérez un événement de déni de service. La page serveur cloud promeut les contrôles de pare-feu cloud et le signalement d'attaques. La page SLA exclut les attaques par déni de service contre le serveur cloud de la garantie de disponibilité. Le produit peut toujours aider à atténuer le trafic, mais le client ne devrait pas supposer que chaque interruption causée par une attaque crée une compensation.

La question devient pratique: quel volume de trafic le pare-feu peut-il gérer, qu'est-ce qui est filtré en bordure cloud, qu'est-ce qui atteint l'instance, qui peut modifier les filtres pendant une attaque, et quand Cloud.ir peut-il suspendre ou limiter le débit d'une cible pour protéger d'autres clients?

Considérez la facturation. L'exclusion SLA pour non-paiement est ordinaire, mais le risque opérationnel n'est pas trivial. Un portefeuille prépayé, un paiement domestique échoué, un problème de carte bancaire d'entreprise ou une facture contestée peut devenir un événement d'infrastructure si les serveurs sont suspendus avant qu'un opérateur ne résolve le compte.

Une entreprise utilisant Cloud.ir pour la production devrait demander combien de rappels sont envoyés, quelle période de grâce s'applique, quelle rétention de données suit la suspension, si les instantanés restent accessibles, et si le support peut temporairement préserver le service pendant que les preuves de facturation sont examinées.

Considérez les ordres des autorités publiques. Le SLA indique que les temps d'arrêt causés par les autorités judiciaires ou de sécurité sont en dehors du cadre de pénalités. C'est une question de localité, pas un jugement sur le fournisseur. Si les charges de travail, les sauvegardes et les comptes de support sont à l'intérieur d'une seule juridiction, le client doit comprendre comment les ordres légaux ou politiques peuvent affecter la disponibilité, l'accès aux données, le service de domaine et les communications avec le client.

La réponse peut être acceptable pour un site web iranien domestique et inacceptable pour un service transfrontalier avec des obligations de conformité conflictuelles. La même localité physique peut être une force pour la latence et une contrainte pour la gouvernance.

Le SLA affine donc les questions de l'acheteur. Il ne rend pas Cloud.ir plus faible; il rend la forme du service plus connaissable. Le client devrait distinguer la disponibilité du réseau, la disponibilité de l'hôte, la santé de l'invité, l'intégrité du stockage, la récupérabilité des sauvegardes, le comportement du CDN, le statut du compte et les contraintes légales. Le SLA public ne réduit pas ces couches en une seule promesse. Un acheteur de production ne devrait pas non plus le faire.

Le CDN, le stockage et le cloud switching élargissent le rayon d'impact ainsi que l'ensemble des fonctionnalités

Les services de CDN, de stockage et de réseau virtuel de Cloud.ir sont utiles car ils peuvent réduire la charge sur un seul serveur d'origine et donner aux clients plus de choix d'architecture. Ils rendent également la carte des dépendances plus large. Lapage CDNindique que la distribution domestique peut répondre aux requêtes via des centres de données locaux et créer du trafic à moitié prix pour les utilisateurs domestiques; elle décrit également le routage des utilisateurs vers des serveurs plus proches, la compression et la mise en cache du contenu, la surveillance des requêtes et réponses, les limites d'accès par pays et la protection contre les attaques. C'est une véritable histoire produit, mais elle transforme un site en chaîne: DNS, bord CDN, état du cache, joignabilité de l'origine, gestion des certificats, configuration du compte et support doivent tous fonctionner ensemble.

Si le serveur d'origine tombe en panne, le CDN peut continuer à servir du contenu statique mis en cache. Il peut également servir du contenu obsolète, échouer sur les routes dynamiques, ou augmenter les taux d'erreur lorsque les misses de cache atteignent une origine malsaine. Si un bord CDN perd la joignabilité amont, les utilisateurs d'une région peuvent voir des erreurs tandis que d'autres non. Si les règles d'accès sont mal configurées, une fonctionnalité de localité peut devenir un problème de disponibilité.

Le client a besoin de contrôles de purge du cache, du comportement de l'origine de secours, des journaux, des règles de fail-open ou fail-closed, de la visibilité du renouvellement des certificats et d'un moyen de déplacer le DNS si le service CDN devient la panne.

L'offre de stockage a une forme de risque différente. Lapage stockage cloudindique que le service permet aux clients de faire évoluer la capacité, de gérer les fichiers, de gérer les clés d'accès, de connecter le stockage aux domaines, de partager des fichiers et de définir des niveaux d'accès. Elle indique également que les données sont protégées par une distribution sur plusieurs serveurs. C'est précieux, mais la durabilité du stockage n'est pas visible de l'extérieur. Un client a besoin de savoir si le service est un stockage d'objets, un stockage en bloc, un stockage de fichiers ou un mélange; ce que signifie la réplication; si les répliques se trouvent dans une seule salle ou sur plusieurs sites; comment les suppressions sont protégées; si le versioning existe; comment les clés sont rotées; comment la récupération est testée; et à quelle vitesse une exportation complète peut être réalisée.

Le service cloud switch est tout aussi important. Lapage cloud switchdécrit un réseau géré entre serveurs cloud et centres de données, routant le trafic et créant des réseaux privés. Elle indique également que le service peut identifier les ressources alternatives disponibles et basculer automatiquement en cas de perturbation. Ce type de fonctionnalité peut réduire la récupération manuelle si elle est bien implémentée. Elle peut également devenir un point de défaillance unique si une mauvaise configuration du réseau privé isole un groupe de serveurs par ailleurs sains.

Le schéma plus profond est qu'une fonctionnalité peut être à la fois une couche de résilience et une nouvelle dépendance. Les sauvegardes ne protègent les données que si elles sont stockées en dehors de la frontière défaillante et peuvent être restaurées rapidement. Le CDN ne protège l'origine que si le contenu peut être servi correctement lorsque l'origine est faible. Le réseau virtuel ne protège le trafic est-ouest que si le plan de contrôle et la matrice de commutation restent sains. Les pare-feu cloud ne protègent les clients que si les modifications de filtres peuvent être effectuées en toute sécurité sous pression.

Le client ne devrait pas demander si ces fonctionnalités existent dans l'abstrait. Il devrait demander comment chaque fonctionnalité se comporte lorsqu'un hôte, un rack, une route, un cluster de stockage, un compte ou une file d'attente de support est déjà en panne.

La localité est un attribut de produit, pas un slogan

La localité des données est l'une des raisons les plus fortes d'acheter chez Cloud.ir. Les pages de l'entreprise placent l'infrastructure cloud sur les centres de données ASIATECH en Iran, la page CDN met l'accent sur les options de distribution domestique, et les preuves réseau montrent le site cloud public sur AS60077 avec un réseau parent iranien ASIATECH. Pour les utilisateurs et entreprises iraniens, cela peut signifier une latence plus faible, un alignement des paiements domestiques, un langage de support familier, une économie de trafic locale et un fournisseur dont le parc physique est proche du public visé.

Mais la localité doit être définie par service. Un serveur virtuel peut s'exécuter en Iran tandis qu'un relais e-mail, une console de gestion, un service d'analyse, une copie de sauvegarde ou une pièce jointe de support emprunte un autre chemin. Un produit CDN peut offrir des modes de distribution domestique et internationale. Un service de stockage peut répliquer sur plusieurs serveurs sans dire si ces serveurs sont dans des bâtiments séparés.

Un client ne peut pas déduire l'emplacement exact de chaque copie de données à partir de l'adresse de l'entreprise, du domaine de premier niveau, du nom du système autonome ou de la phrase "centres de données à travers l'Iran".

La propre ligne régionale de Cloud.ir pour un profil orienté acheteur peut être globale car la joignabilité IP est globale et les clients cloud peuvent être n'importe où avec un compte fonctionnel et un chemin réseau. Cela est différent de dire que l'entreprise opère des régions globales. Les preuves produit publiques examinées ici pointent le plus fortement vers l'infrastructure iranienne et le parc de centres de données domestiques d'ASIATECH. Si un client a besoin d'un service uniquement iranien, il devrait demander une déclaration écrite sur la localité du calcul, du stockage, de la sauvegarde, des journaux et de l'accès au support.

Si un client a besoin d'une continuité multi-pays, il devrait demander si Cloud.ir lui-même fournit cela ou si le client doit le construire avec un autre fournisseur.

La localité change également la réponse aux incidents. Un site de contenu iranien domestique peut préférer le comportement CDN domestique de Cloud.ir et les installations ASIATECH car la plupart des utilisateurs se trouvent près de ces chemins. Un fournisseur SaaS international peut s'inquiéter de l'accès aux paiements, de l'exposition aux sanctions, de la latence des utilisateurs étrangers, du filtrage des routes, de la résolution des litiges et de la capacité d'exporter des données sous pression.

Un utilisateur du secteur public ou réglementé peut valoriser le contrôle local des installations mais avoir besoin d'une déclaration plus stricte sur qui peut accéder aux données, où se trouvent les instantanés et comment les ordres des autorités sont traités. La même infrastructure peut être bien adaptée à un client et inadaptée à un autre.

Le test pratique est la preuve. Demandez les choix de région et de site disponibles dans le panneau client. Demandez si deux instances peuvent être placées dans des installations séparées. Demandez où sont stockées les sauvegardes planifiées. Demandez où sont conservés les journaux CDN et les métadonnées de stockage. Demandez si les ingénieurs de support peuvent accéder aux disques, instantanés, clés ou consoles des clients, et depuis où. Demandez si une exportation complète peut être réalisée sans maintenir le compte actif pour un autre long cycle de facturation.

Un fournisseur qui peut répondre à ces questions calmement est plus facile à faire confiance qu'un autre qui se repose uniquement sur un langage de localité large.

Les principaux chemins de défaillance passent par le rack, la route, le stock de matériel, le statut du compte et la migration

La panne la plus probable de Cloud.ir pour laquelle un client devrait planifier n'est pas une panne totale dramatique. C'est une panne partielle qui se situe entre les couches contractuelles. Une VM peut être bien alors qu'une route amont est dégradée. Une route peut être bien alors que les performances de stockage s'effondrent. Une sauvegarde peut exister alors que le débit de restauration est trop lent. Un CDN peut répondre pour le contenu statique alors que les fonctions dynamiques échouent. Un panneau client peut être joignable alors que le paiement empêche une reconstruction.

Ces états intermédiaires sont là où les clients apprennent si le service a suffisamment de détails opérationnels derrière lui.

Le chemin du rack commence par le matériel physique. Une panne d'hôte peut déplacer une VM bien conçue vers un autre hôte s'il y a un stockage partagé, une capacité hôte de réserve et une orchestration fonctionnelle. Elle peut également laisser un client attendre une pièce si du stockage local, une allocation bare-metal ou un composant non redondant est impliqué. Les pages publiques de Cloud.ir ne divulguent pas la plateforme hyperviseur, la classe d'hôte, les choix de stockage local par rapport au stockage partagé, ou la politique de matériel de réserve.

Les clients devraient demander ce qui se passe lorsqu'un serveur physique tombe en panne, quels services redémarrent automatiquement, lesquels nécessitent un ticket, et s'il existe un temps maximum garanti pour reconstruire sur du matériel équivalent.

Le chemin amont commence par la dépendance visible d'AS60077 envers AS43754. Si AS43754 filtre une route, a un problème de bord, change une politique ou subit un incident plus large, les services clients d'AS60077 peuvent être affectés même lorsque les VMs client sont allumées. Parce que les données publiques montrent AS43754 comme la frontière amont observée pour AS60077, le client devrait demander si l'ASN cloud a des routeurs de bord physiques séparés, plusieurs points d'accès dans AS43754, un transit externe direct, et des tests de basculement récents.

Il ne suffit pas de dire que le réseau parent a de nombreux voisins; la question pertinente est ce qui se passe en bordure cloud.

Le chemin du stock de matériel concerne la croissance et la réparation. La tarification cloud horaire et la mise à l'échelle instantanée ne sont utiles que s'il y a des cœurs CPU, de la RAM, des disques, des adresses et des ports de commutateur de réserve. Un acheteur planifiant une campagne, un événement, un lancement ou une migration devrait demander si la capacité peut être réservée, si les augmentations importantes nécessitent un préavis, et si le fournisseur peut placer une capacité supplémentaire dans un domaine de défaillance séparé.

Un acheteur plus petit devrait poser une question plus simple: si mon hôte actuel tombe en panne, y a-t-il déjà assez de place de réserve pour redémarrer mon serveur ailleurs?

Le chemin du support concerne le temps et l'autorité. Cloud.ir indique que les clients serveur cloud peuvent soumettre des tickets à toute heure. C'est mieux qu'un canal d'heures de bureau étroites, mais le client a toujours besoin d'objectifs d'escalade. Qui peut modifier une route BGP? Qui peut autoriser une visite de rack? Qui peut restaurer une sauvegarde supprimée? Qui peut annuler une suspension de compte? Qui peut expliquer un ordre légal ou de sécurité? Si l'équipe de support de première ligne ne peut que transmettre une demande, le temps de réparation inclut chaque transfert.

Le chemin de migration est le dernier filet de sécurité. Un client peut tolérer des preuves plus faibles s'il peut partir rapidement. Cela nécessite des sauvegardes actuelles, des images ou fichiers exportables, des procédures documentées de changement d'IP et de DNS, des TTL connus, un accès au compte qui reste disponible pendant les litiges de facturation, et une bande passante suffisante pour déplacer les données.

Cela nécessite également d'éviter un verrouillage caché: des adresses réseau privées qui ne peuvent pas être reproduites, des fonctionnalités de stockage sans chemin d'exportation, des règles CDN qui ne peuvent pas être recréées ailleurs, ou des instantanés qui ne peuvent pas être téléchargés. Les pages publiques de Cloud.ir décrivent la reconstruction, les sauvegardes et les opérations de compte, mais elles ne divulguent pas les conditions complètes de portabilité. Les utilisateurs de production devraient les obtenir avant d'en avoir besoin.

Ce qu'un acheteur devrait vérifier avant de compter sur Cloud.ir

La première tâche de vérification est le placement. Cloud.ir devrait pouvoir dire quels services peuvent être placés dans quels emplacements iraniens, si un emplacement est un bâtiment distinct, une salle ou une étiquette logique, et si deux instances peuvent être maintenues séparées. Si la réponse est "notre cloud gère cela", le client devrait demander une description du domaine de défaillance en langage simple. Un petit fournisseur n'a pas besoin de terminologie hyperscale pour être fiable, mais il a besoin de limites honnêtes.

La deuxième tâche est la diversité réseau. AS60077 est visible et légitime, et AS43754 est un réseau parent substantiel. C'est un bon point de départ. Ce n'est pas la même chose que de prouver que le trafic client peut survivre à un événement de bord d'AS43754. Demandez le chemin normal, le chemin de secours, la conception du routeur de bord, la limite de traitement DDoS, les pratiques RPKI et de filtrage de routes, et si Cloud.ir peut annoncer temporairement un préfixe client ou déplacer une adresse publique pendant un incident. Pour la plupart des clients VPS, la réponse sera non, mais la question clarifie la dépendance.

La troisième tâche est la preuve de restauration. Les sauvegardes sont répertoriées comme fonctionnalités produit, et la page des prix distingue les composants de sauvegarde hebdomadaire, trois jours et quotidien. Le client devrait demander comment les instantanés sont planifiés, ce qui est capturé, ce qui ne l'est pas, où les copies de sauvegarde sont stockées, combien de temps elles sont conservées, quel est le temps de restauration typique, si une restauration peut cibler un autre site, et si le fournisseur a des résultats de test de restauration récents.

Une sauvegarde qui ne peut pas quitter la frontière endommagée est une assurance uniquement contre une classe étroite de pannes.

La quatrième tâche est la maintenance et les exclusions. Le SLA exclut la maintenance annoncée et les correctifs critiques du calcul de disponibilité. Demandez comment la maintenance est annoncée, combien de préavis est donné, si un travail d'urgence peut avoir lieu sans préavis normal, si le client peut choisir une fenêtre, et si plusieurs ressources client sont maintenues ensemble. Une fenêtre de maintenance n'est pas mauvaise; une fenêtre peu claire est mauvaise.

La cinquième tâche est la continuité du compte. Puisque le non-paiement est en dehors du cadre de pénalités du SLA, les acheteurs de production devraient comprendre le financement du portefeuille, le calendrier des factures, les seuils de suspension, les voies de recours et la rétention des données après suspension. C'est particulièrement important pour les équipes en dehors de l'Iran, les équipes avec des retards d'approvisionnement et les équipes dont l'accès au paiement dépend d'une seule personne. Un échec de facturation peut devenir une panne évitable.

La sixième tâche est la sortie. Exportez une petite image serveur, restaurez une sauvegarde dans une instance propre, déplacez un enregistrement DNS loin du CDN, recréez une politique de pare-feu ailleurs et documentez le temps. Ces tests n'ont pas besoin d'être importants pour être révélateurs. Ils montrent si les abstractions du fournisseur aident le client à récupérer ou aident principalement le client à rester.

La thèse opérationnelle: service réel, forte visibilité réseau, preuve physique incomplète

CLOUD Asre Dadeha Asiatech mérite un niveau de confiance plus élevé qu'une entreprise avec seulement une entrée de routage obsolète. Cloud.ir est actif, le catalogue de services est spécifique, la page des prix expose des packages de ressources concrets, le SLA est public, et les enregistrements RIPE placent AS60077 dans la table de routage publique en tant qu'AT-CLOUD Asre Dadeha Asiatech. Le DNS pour le site de l'entreprise pointe vers AS60077. AS60077 a un parc d'adresses visible, et sa dépendance au réseau parent AS43754 est observable plutôt que cachée.

Cela ne rend pas le service totalement transparent. Les archives publiques ne montrent pas le placement exact en centre de données des charges de travail client, le nombre d'hôtes disponibles, la quantité de matériel de réserve, le temps de restauration réel, l'emplacement de chaque sauvegarde, la diversité physique des routes, la conception du basculement des routes en bordure cloud, ou les conditions de compte et de migration sur lesquelles un client compterait en cas de litige.

Le propre marketing de Cloud.ir fait des déclarations fortes sur la disponibilité et la persistance des données, tandis que son SLA trace des limites pratiques autour de ce qui est couvert.

La lecture correcte est donc équilibrée. Le produit existe. Le réseau est visible. La dépendance physique est réelle. Un acheteur peut raisonnablement considérer Cloud.ir pour des charges de travail qui bénéficient de la proximité des centres de données iraniens, de l'infrastructure domestique d'ASIATECH et d'un panneau de contrôle cloud local. Le même acheteur devrait éviter de traiter l'étiquette cloud comme une preuve de résilience multi-site, de diversité des routes ou de sortie sans couture. Ce sont des faits d'ingénierie et contractuels qui doivent être obtenus, testés et écrits.

Pour un petit site web, l'incertitude restante peut être acceptable si les sauvegardes sont indépendantes et que le DNS peut bouger rapidement. Pour une propriété médiatique iranienne à fort trafic, le CDN et l'hébergement domestique peuvent être précieux, mais l'opérateur devrait tester la panne de l'origine, le comportement du cache et l'escalade du support avant un lancement. Pour les données réglementées ou transfrontalières, les questions clés sont la localité, l'exposition aux autorités, l'accès au support et les droits d'exportation.

Pour tout client de production, la discipline finale est la même: achetez le service cloud, mais auditez l'histoire du rack, de la route, de la réparation et de la migration qui se cache derrière.