Resumen
- Cloud.ir le da a CLOUD Asre Dadeha Asiatech una superficie minorista real: el sitio ofrece servidores en la nube, planes VPS, almacenamiento en la nube, CDN, conmutación en la nube, servicios de centro de datos en la nube, un panel de cliente, precios publicados y un SLA, y su pie de página indica que el sitio web pertenece a Asre Dadeha Asiatech.
- El ancla física es más estrecha que el lenguaje del producto. Cloud.ir dice que su infraestructura se encuentra en los centros de datos de ASIATECH en Irán, y la página de información dice que Cloud.ir opera desde el año iraní 1399 con más de 20 productos en la nube, pero las páginas públicas no identifican el rack exacto, la ubicación ciudad por ciudad, la topología de energía o los resultados de las pruebas de restauración detrás de cada carga de trabajo del cliente.
- La evidencia de red es sólida en la capa del plano de control. RIPE RDAP identifica a AS60077 como AT-CLOUD para Asre Dadeha Asiatech, RIPEstat mostró 18 prefijos IPv4 y 14,080 direcciones IPv4 anunciadas por AS60077 el 12 de julio de 2026, y el DNS de
cloud.irse asignó a un prefijo de AS60077. La misma vista de RIPE mostró un vecino del lado izquierdo observado para AS60077: AS43754, ASIATECH Asiatech Data Transmission company. - Por lo tanto, la pregunta de compra no es si existe un producto en la nube. Es si un cliente determinado puede verificar la ubicación, el margen de capacidad, las rutas independientes, la localidad de la copia de seguridad, la escalabilidad del soporte, las exclusiones de mantenimiento, la continuidad de la facturación y los derechos de salida antes de que un evento de rack, upstream, stock de hardware o cuenta convierta un servidor virtual en una dependencia física.
El escaparate es público, pero la promesa de infraestructura todavía está en capas
Cloud.ir no es una página de marca estacionada. Lapágina de inicio de Cloud.irpresenta servidores en la nube, servicios de centro de datos en la nube, conmutación en la nube, CDN, almacenamiento en la nube, gestión de dominios en la nube, una página de precios de servicios, páginas de soporte y una ruta de inicio de sesión para clientes. La misma página lleva un número de teléfono, una dirección de correo electrónico, una dirección de oficina en Teherán y una declaración en el pie de página de que los derechos materiales e intelectuales del sitio web pertenecen a Asre Dadeha Asiatech. Para este perfil, esto importa porque la identidad de la empresa está vinculada a una superficie de servicio en vivo, no solo a un registro de enrutamiento.
Lapágina de informaciónagrega un historial de servicio. Dice que Cloud.ir comenzó a operar en el año iraní 1399 y se ha convertido en uno de los principales proveedores de servicios en la nube de Irán con más de 20 productos en la nube. Los grupos de productos mencionados incluyen distribución de contenido, computación en la nube, seguridad en la nube, almacenamiento en la nube, redes en la nube y un mercado en la nube. Estas afirmaciones son declaraciones de la empresa, no mediciones independientes de capacidad, pero dejan clara la postura comercial básica: CLOUD Asre Dadeha Asiatech vende capacidad alojada a clientes que no quieren comprar y operar su propia infraestructura física.
La oferta minorista también es lo suficientemente específica como para inspeccionarla. Lapágina de servidor en la nubedice que los clientes pueden crear un servidor en la nube rápidamente, pagar por los recursos que usan, cambiar recursos, configurar redes, agregar o cambiar direcciones IP, monitorear el uso de recursos y redes, usar un firewall en la nube y programar copias de seguridad. La misma página describe opciones de servidor Linux, Windows y MikroTik y dice que el soporte para clientes de servidores en la nube está disponible a través del envío de tickets las 24 horas del día. Un comprador debe tratar estas como promesas de producto que necesitan confirmación contractual y de pruebas, pero aún son más concretas que el lenguaje genérico de “nube”.
Lapágina de preciosde Cloud.ir hace que el producto sea aún más inspeccionable. Enumera nombres de paquetes VPS como AT-VPS-B2, AT-VPS-G1 y AT-VPS-A2 con memoria, CPU, disco, una dirección IP gratuita, tráfico base, soporte de IP adicional, soporte de reconstrucción e IPv6 mostrados en las tarjetas de paquetes. También muestra medición por hora para recursos de servidor en la nube como memoria, CPU, disco, IP, tráfico recibido y niveles de copia de seguridad. Las páginas de precios no son diagramas de ingeniería, pero revelan cómo se empaqueta el servicio: un cliente está comprando unidades finitas de cómputo, almacenamiento, dirección y tráfico que deben existir en algún lugar antes de que el panel de control pueda asignarlas.
La empresa también describe servicios de nivel superior alrededor de la misma infraestructura. Lapágina de centro de datos en la nubecomercializa gestión de datos segura y fácil, escalado, monitoreo, virtualización, contenerización y copia de seguridad programada. Lapágina de almacenamiento en la nubepresenta almacenamiento escalable, uso compartido controlado y gestión de niveles de acceso. Lapágina de CDNdescribe la distribución de contenido a través de modos nacional, centralizado e internacional, con solicitudes de usuarios servidas a través de ubicaciones de centros de datos geográficamente más cercanas. Lapágina de conmutación en la nubepresenta redes virtuales gestionadas entre servidores en la nube y centros de datos. Cada producto reduce la necesidad del cliente de poseer equipos; cada uno también introduce una dependencia de las decisiones de ubicación, diseño de red y soporte del proveedor.
Ese es el marco útil para el resto del artículo. CLOUD Asre Dadeha Asiatech no es un caparazón misterioso, pero la superficie de servicio visible no elimina la necesidad de probar las capas inferiores. Un servidor en la nube se puede aprovisionar en segundos solo cuando el proveedor ya tiene capacidad de host adecuada, almacenamiento, direcciones públicas, alcanzabilidad de red y autorización de facturación. Una CDN puede enrutar una solicitud a un borde más cercano solo cuando ese borde existe, tiene contenido fresco, suficiente capacidad de caché y tránsito, y aún puede alcanzar el origen cuando el servidor del cliente está enfermo.
Una copia de seguridad importa solo si se puede restaurar fuera de la falla que dañó la carga de trabajo principal. Las páginas públicas muestran la oferta; no prueban por sí mismas todas las afirmaciones de resiliencia que un comprador de producción necesita.
El ancla física es la capacidad del centro de datos de ASIATECH en Irán
La declaración física más sólida de Cloud.ir es explícita: su infraestructura en la nube se encuentra en los centros de datos de ASIATECH. Lapágina de servidor en la nubedice que la infraestructura de los servicios en la nube de Cloud.ir está implementada en los centros de datos de ASIATECH, que describe como la red de centros de datos más grande de Irán. Enumera el uso de tecnologías modernas, ISO27001 y afirmaciones TIA-942 Nivel 2 y Nivel 3, sistemas de seguridad, conectividad de red estable, alto consumo de ancho de banda en Irán y soporte de energía AC y DC. Lapágina de centro de datos en la nuberepite el mismo marco de centro de datos de ASIATECH y dice que los centros de datos de Cloud.ir en Irán proporcionan infraestructura para clientes que comienzan la migración a la nube.
Lapágina de informaciónes similar. Dice que los centros de datos de Cloud.ir están distribuidos por Irán y que su infraestructura se basa en los centros de datos de ASIATECH que cubren instalaciones grandes y potentes con estándares globales. También enumera soporte AC y DC. Estas afirmaciones son importantes porque mueven el servicio de una abstracción minorista pura a un límite de operador de instalación con nombre: la marca en la nube depende del patrimonio del centro de datos y la red de ASIATECH, no de una región de hiperescala en el extranjero sin nombre.
Fuera de las páginas de la empresa, el registro público proporciona un contexto más antiguo pero útil para ese patrimonio. centros de datos Dynamics informó en julio de 2017 que AsiaTech abrió uncentro de datos de 700 metros cuadrados en la Torre Milad en el oeste de Teherán. Ese informe describía a AsiaTech como una empresa privada establecida en 2003, decía que había obtenido una licencia en 2013 para alojamiento, servidores dedicados y compartidos y coubicación, y decía que operaba cinco centros de datos y conectaba más de 430 pueblos y ciudades de Irán. DataCenterMap actualmente enumera elCentro de datos de la Torre Milad de Asiatechy elCentro de datos de Azadegan de Asiatechen Teherán, mientras que su página de especificaciones de la Torre Milad dice que Asiatech no proporcionó datos de capacidad, energía, cumplimiento, seguridad o edificio.
Esas referencias externas deben manejarse con cuidado. Corroboran que ASIATECH ha estado asociado con instalaciones con nombre en Teherán y un negocio de centros de datos más amplio. No prueban qué instalación atiende a una VM particular de Cloud.ir, borde de CDN, bucket de almacenamiento o copia de seguridad en julio de 2026. Tampoco prueban que la condición de la instalación de 2017, el recuento de racks, el diseño de energía o el recuento de clientes permanezcan sin cambios. El historial de la instalación es evidencia útil de una empresa de infraestructura real; no es un mapa de ubicación actual.
Esa distinción importa a los clientes. Un comprador puede escuchar “centros de datos en todo Irán” y asumir que dos servidores pedidos desde la misma cuenta aterrizan en edificios separados. Puede que no. Podrían aterrizar en el mismo host, dos hosts en un rack, dos racks detrás de una unidad de energía, dos salas en un edificio, o edificios separados cuya fibra metropolitana o borde ascendente aún converge. Por el contrario, el proveedor podría tener una mejor separación de la que revelan las páginas públicas. Las páginas públicas no resuelven el punto.
El cliente tiene que preguntar por controles de ubicación, reglas antiafinidad, sitios con nombre o códigos de sitio, ubicación de la copia de seguridad y qué significa Cloud.ir por “centro de datos” para cada nivel de servicio.
La energía y la mano de obra de reparación son parte de la misma pregunta. Cloud.ir puede decir justamente que el uso de la nube evita la carga del cliente de comprar equipos y mantener una sala de servidores. Eso no hace que el mantenimiento físico desaparezca. Alguien todavía tiene que reemplazar discos, fuentes de alimentación, tarjetas de línea y memoria; alguien todavía tiene que programar trabajos eléctricos; alguien todavía tiene que probar generadores, baterías, refrigeración y sistemas contra incendios; alguien todavía tiene que recibir una alerta y llegar al rack.
Un cliente no necesita conocer cada detalle privado del diseño de la instalación de ASIATECH, pero sí necesita saber qué promesas de disponibilidad sobreviven a un evento de rack, una ventana de mantenimiento de energía, una falla de almacenamiento y una escasez de hardware de reemplazo.
AS60077 es visible, y la red principal es la dependencia obvia
El registro de red le da a CLOUD Asre Dadeha Asiatech un segundo ancla concreta. RIPE RDAP identifica aAS60077como AT-CLOUD y lo vincula a Asre Dadeha Asiatech a través de ORG-ADA42-RIPE. La misma respuesta RDAP incluye contactos administrativos y técnicos de NOC de Asiatech en una dirección de la calle Miremad en Teherán, además de un rol de abuso de Asiatech. Esta es una evidencia de registro de un sistema autónomo real y una cadena de contacto operativo. No describe servidores individuales, clientes o tiempo de actividad, pero confirma que el servicio en la nube tiene su propio identificador de red.
Lavisión general de AS de RIPEstat para AS60077informó al titular como “AT-CLOUD Asre Dadeha Asiatech” y mostró que anunciaba en el momento de la consulta del 12 de julio de 2026. Suvista de estado de enrutamientomostró 18 prefijos IPv4 y 14,080 direcciones IPv4 visibles desde AS60077, con la primera observación de prefijo que data de 2014 y la observación más reciente en el momento de la consulta. La misma vista de RIPE mostró una alta visibilidad del recolector IPv4 y ningún espacio IPv6 visible en esa respuesta de estado particular.
El servicio activo también apunta a AS60077. Lavista de cadena DNS de RIPEstat paracloud.irdevolvió193.151.157.174para el nombre de la cúpula, y lavista de información de red para esa direcciónla asignó a193.151.157.0/24y AS60077. Esto no prueba que cada carga de trabajo del cliente se ejecute dentro del mismo prefijo; muestra que la propia presencia web pública de la empresa se sirve desde el ASN de la nube.
La dependencia está en los datos de vecinos. Lavista de vecinos ASN de RIPEstat para AS60077mostró un vecino del lado izquierdo observado: AS43754. Lavisión general de AS de RIPEstat para AS43754nombra a esa red “ASIATECH Asiatech Data Transmission company”. Suvista de estado de enrutamientomostró una huella de red mucho más grande en el mismo momento de la consulta: 316 prefijos IPv4, 209,920 direcciones IPv4 y 86 vecinos observados. La imagen es directa: el ASN de la nube es visible, pero su límite ascendente público parece ser la red ASIATECH más grande.
Las muestras de looking glass hacen visible la relación en rutas reales. Losdatos del looking glass de RIPEstat para193.151.128.0/22, uno de los prefijos anunciados de AS60077, incluyeron rutas que terminaban en AS43754 AS60077. Algunas muestras globales también mostraron upstreams anteriores antes de AS43754, pero la dependencia cercana al origen seguía siendo AS43754. Eso no es sorprendente para un negocio en la nube adjunto al mismo grupo de infraestructura corporativa, pero importa porque una falla en ese límite puede afectar muchos servicios a la vez.
Esto no significa que AS60077 sea frágil. Una sola relación upstream visible puede ser perfectamente razonable cuando la red principal tiene alcance de operador, disciplina operativa y suficiente redundancia detrás de escena. Tampoco significa que AS43754 tenga solo un camino externo; RIPEstat mostró muchos vecinos para AS43754. El punto importante es más estrecho: la evidencia BGP pública no prueba que AS60077 mismo tenga múltiples upstreams independientes, entradas físicas separadas, routers de borde separados o conmutación por error independiente fuera de AS43754.
Los clientes deben tratar a AS43754 como el límite operativo upstream visible a menos que Cloud.ir proporcione evidencia específica del producto de una separación adicional.
RPKI responde una pregunta diferente. Lavalidación RPKI para193.151.128.0/22originado por AS60077devolvió estado válido con autorizaciones de origen de ruta que cubren AS60077. Eso es una higiene de enrutamiento positiva: respalda la legitimidad del origen de la ruta. No prueba la capacidad de tráfico, la diversidad de rutas, la continuidad de energía, la calidad del aislamiento del cliente, la recuperabilidad de la copia de seguridad o la respuesta del soporte. Una ruta válida de RPKI aún puede ser retirada por error, filtrada por un upstream, aislada por una falla de conexión cruzada o inutilizada por una interrupción del lado del servidor.
La capacidad instalada no es lo mismo que la capacidad utilizable en la nube
Los compradores de nube tienden a ver controles deslizantes de recursos. El operador ve inventario. CPU, memoria, disco, espacio de copia de seguridad, direcciones públicas, estado del firewall, monitoreo, capacidad del puerto, consumo de energía del host y tiempo del personal deben alinearse antes de que un control deslizante de recursos se convierta en un servidor funcional. Las páginas públicas de Cloud.ir son útiles porque revelan algunos de esos ingredientes, pero no revelan el nivel de existencias.
Lapágina de preciosenumera paquetes con cantidades fijas de memoria, procesador, disco y tráfico. También enumera componentes por hora separados para la infraestructura en la nube, incluidos los programas de copia de seguridad. Eso es suficiente para mostrar que Cloud.ir vende el servicio como un grupo de recursos con precio. No es suficiente para mostrar cuántos hosts hay en el grupo, cuántos están reservados para conmutación por error, cuánto rendimiento de disco está disponible bajo contención, si el espacio de copia de seguridad se encuentra en un sitio separado, qué tan rápido se puede recrear una instancia dañada, o si el proveedor puede satisfacer un pedido grande durante una escasez de hardware.
Los números de red proporcionan un borde exterior, no un recuento de servidores. Lalista de prefijos anunciados de RIPEstat para AS60077mostró 18 prefijos IPv4 en el período de consulta reciente, incluidos varios rangos/22,/23y/24. Las 14,080 direcciones IPv4 vistas en la vista de estado de enrutamiento son capacidad de direcciones públicas real, pero las direcciones no equivalen a máquinas virtuales. Algunas direcciones sirven a routers, balanceadores de carga, firewalls, servidores de nombres, instancias de clientes, funciones de gestión o grupos de repuesto. Un solo servidor puede usar varias direcciones; muchos servicios pueden estar detrás de una dirección; las direcciones no utilizadas pueden coexistir con un clúster de cómputo completo.
La misma precaución se aplica a las referencias IPv6 de Cloud.ir. La página de precios muestra IPv6 en las tarjetas de paquetes VPS. La consulta de estado de enrutamiento de RIPE utilizada aquí no mostró espacio IPv6 visible para AS60077 en el momento de la consulta. Eso no prueba que IPv6 esté ausente del producto: IPv6 puede suministrarse a través de un arreglo diferente, exponerse solo en ciertos planes, ser visible en otros recolectores o representarse de manera diferente en sitios de enrutamiento de terceros.
Significa que un cliente que necesita IPv6 nativo debe probar la asignación real, el enrutamiento, el comportamiento del firewall, el DNS inverso, la alcanzabilidad de la copia de seguridad y la escalabilidad del soporte en lugar de confiar solo en una etiqueta de paquete.
El lenguaje de producto de Cloud.ir también separa la capacidad de la resiliencia. La página del servidor en la nube dice que los recursos se pueden aumentar o disminuir instantáneamente y que cuando un servidor no está disponible, los datos se ponen a disposición automáticamente desde otro servidor. La página del centro de datos en la nube dice que los datos almacenados se mantienen en múltiples centros de datos y que otros centros de datos preservan la conectividad si uno tiene problemas. Esas son afirmaciones importantes. También necesitan precisión. ¿Qué servicios están cubiertos?
¿La transferencia es automática para todos los tipos de servidor o solo para los datos protegidos por una capa de almacenamiento particular? ¿Se usan dos centros de datos por defecto o solo si el cliente los configura? ¿La copia de seguridad es en caliente, en tibio o en frío? ¿Hay un tiempo de recuperación probado? ¿Hay créditos disponibles si la automatización falla?
Sin esas respuestas, un comprador debe mantener separados lo “instalado” y lo “utilizable”. La capacidad instalada es la colección de hosts, racks, matrices de almacenamiento, enlaces y direcciones que el proveedor posee o alquila. La capacidad utilizable es lo que el cliente puede asignar ahora sin sobrecargar un host, agotar un grupo de direcciones, violar una regla de ubicación o depender de un técnico cansado para reemplazar una pieza después de la medianoche. Las páginas públicas de Cloud.ir prueban un producto en la nube con precio y una red visible. No revelan lo suficiente para convertir eso en una reserva de capacidad.
El SLA reduce la promesa exactamente en los puntos que una falla pondrá a prueba
Cloud.ir publica unapágina de SLA, y eso es bueno para los clientes porque mueve parte de la conversación sobre riesgos a un texto público. La parte más importante de la página no es un gran número de tiempo de actividad; son las limitaciones. La página dice que la garantía de tiempo de actividad se aplica solo a la disponibilidad de red y servidor en la nube durante la operación ordinaria. Excluye el software del servidor del cliente, los sistemas operativos, los problemas de configuración, los ataques de denegación de servicio contra un servidor en la nube, los servidores suspendidos o detenidos, las interrupciones distintas de la red o del servidor host, y el mantenimiento o los parches críticos que se anunciaron con anticipación.
La misma página define el tiempo medio de reparación o recuperación como el tiempo promedio para restaurar el servicio según el acuerdo entre el proveedor y el cliente. Luego enumera los casos que no incurren en penalizaciones, incluidos fuerza mayor, equipo del cliente, tiempo de inactividad planificado, interrupción solicitada por el cliente, violaciones de la ley o del SLA, falta de pago y órdenes de autoridades judiciales o de seguridad. Estas exclusiones no son inusuales en el alojamiento, pero son decisivas para un cliente que intenta medir el riesgo. Mueven muchas interrupciones reales fuera de un titular simple de tiempo de actividad.
Considere una falla de software. Si el sistema operativo invitado se rompe después de una actualización del cliente, el texto del SLA sugiere que el problema está fuera de la garantía de tiempo de actividad del proveedor, incluso si el cliente experimenta una pérdida total del servicio. Eso es razonable si Cloud.ir vendió cómputo no gestionado, pero significa que el comprador necesita derechos de recuperación separados: acceso a la consola, arranque de rescate, instantáneas, exportación de imágenes, reversión, reconstrucción y límites de soporte claros.
Un “servidor en la nube” no es continuidad de aplicación gestionada a menos que el contrato lo diga.
Considere un evento de denegación de servicio. La página del servidor en la nube promueve controles de firewall en la nube e informes de ataques. La página del SLA excluye los ataques de denegación de servicio contra el servidor en la nube de la garantía de tiempo de actividad. El producto puede ayudar a mitigar el tráfico, pero el cliente no debe asumir que cada interrupción inducida por un ataque crea una compensación.
La pregunta se vuelve práctica: ¿qué volumen de tráfico puede manejar el firewall, qué se filtra en el borde de la nube, qué llega a la instancia, quién puede cambiar los filtros durante un ataque y cuándo puede Cloud.ir suspender o limitar la velocidad de un objetivo para proteger a otros clientes?
Considere la facturación. La exclusión del SLA por falta de pago es ordinaria, pero el riesgo operativo no es trivial. Una billetera prepaga, un pago nacional fallido, un problema con una tarjeta bancaria corporativa o una factura disputada pueden convertirse en un evento de infraestructura si los servidores se suspenden antes de que un operador resuelva la cuenta.
Una empresa que usa Cloud.ir para producción debe preguntar cuántos recordatorios se envían, qué período de gracia se aplica, qué retención de datos sigue a la suspensión, si las instantáneas siguen siendo accesibles y si el soporte puede preservar temporalmente el servicio mientras se revisa la evidencia de facturación.
Considere las órdenes de autoridad pública. El SLA dice que el tiempo de inactividad causado por autoridades judiciales o de seguridad está fuera del marco de penalización. Eso es un problema de localidad, no un juicio sobre el proveedor. Si las cargas de trabajo, las copias de seguridad y las cuentas de soporte están dentro de una jurisdicción, el cliente necesita entender cómo las órdenes legales o políticas pueden afectar la disponibilidad, el acceso a los datos, el servicio de dominio y las comunicaciones con el cliente.
La respuesta puede ser aceptable para un sitio web iraní doméstico e inaceptable para un servicio transfronterizo con obligaciones de cumplimiento conflictivas. La misma localidad física puede ser una fortaleza para la latencia y una restricción para la gobernanza.
Por lo tanto, el SLA agudiza las preguntas del comprador. No hace que Cloud.ir sea más débil; hace que la forma del servicio sea más conocible. El cliente debe distinguir entre disponibilidad de red, disponibilidad del host, salud del invitado, integridad del almacenamiento, recuperabilidad de la copia de seguridad, comportamiento de la CDN, estado de la cuenta y restricciones legales. El SLA público no colapsa esas capas en una sola promesa. Tampoco debería hacerlo un comprador de producción.
CDN, almacenamiento y conmutación en la nube expanden el radio de explosión además del conjunto de características
Los servicios de CDN, almacenamiento y redes virtuales de Cloud.ir son útiles porque pueden reducir la carga en un único servidor de origen y dar a los clientes más opciones de arquitectura. También hacen que el mapa de dependencias sea más amplio. Lapágina de CDNdice que la distribución doméstica puede responder a las solicitudes a través de centros de datos locales y crear tráfico a mitad de precio para usuarios domésticos; también describe el enrutamiento de usuarios a servidores más cercanos, la compresión y almacenamiento en caché de contenido, el monitoreo de solicitudes y respuestas, los límites de acceso por país y la protección contra ataques. Esa es una historia de producto real, pero convierte un sitio en una cadena: DNS, borde de CDN, estado de caché, alcanzabilidad del origen, manejo de certificados, configuración de cuenta y soporte deben funcionar juntos.
Si el servidor de origen falla, la CDN puede continuar sirviendo contenido estático en caché. También puede servir contenido obsoleto, fallar en rutas dinámicas o aumentar las tasas de error cuando los fallos de caché alcanzan un origen no saludable. Si un borde de CDN pierde alcanzabilidad upstream, los usuarios en una región pueden ver errores mientras que otros no. Si las reglas de acceso están mal configuradas, una característica de localidad puede convertirse en un problema de disponibilidad.
El cliente necesita controles de purga de caché, comportamiento del escudo de origen, registros, reglas de apertura o cierre en caso de fallo, visibilidad de renovación de certificados y una forma de mover el DNS si el servicio de CDN se convierte en la falla.
La oferta de almacenamiento tiene una forma de riesgo diferente. Lapágina de almacenamiento en la nubedice que el servicio permite a los clientes escalar capacidad, gestionar archivos, gestionar claves de acceso, conectar almacenamiento a dominios, compartir archivos y definir niveles de acceso. También dice que los datos están protegidos mediante la distribución en múltiples servidores. Eso es valioso, pero la durabilidad del almacenamiento no es visible desde el exterior. Un cliente necesita saber si el servicio es almacenamiento de objetos, almacenamiento en bloque, almacenamiento de archivos o una mezcla; qué significa la replicación; si las réplicas están en una sala o en múltiples sitios; cómo se protegen las eliminaciones; si existe el versionado; cómo se rotan las claves; cómo se prueba la recuperación; y qué tan rápido se puede completar una exportación completa.
El servicio de conmutación en la nube es igualmente importante. Lapágina de conmutación en la nubedescribe redes gestionadas entre servidores en la nube y centros de datos, enrutamiento de tráfico y creación de redes privadas. También dice que el servicio puede identificar recursos alternativos disponibles y conmutar automáticamente durante una interrupción. Ese tipo de característica puede reducir la recuperación manual si se implementa bien. También puede convertirse en un punto único de cambio si una mala configuración de red privada aísla un grupo de servidores que de otro modo permanecen saludables.
El patrón más profundo es que una característica puede ser tanto una capa de resiliencia como una nueva dependencia. Las copias de seguridad protegen los datos solo si se almacenan fuera del límite de falla y se pueden restaurar rápidamente. La CDN protege el origen solo si el contenido se puede servir correctamente cuando el origen está débil. Las redes virtuales protegen el tráfico este-oeste solo si el plano de control y la tela de conmutación permanecen saludables. Los firewalls en la nube protegen a los clientes solo si se pueden hacer cambios de filtro de manera segura bajo presión.
El cliente no debe preguntar si estas características existen en abstracto. Deben preguntar cómo se comporta cada característica cuando un host, rack, ruta, clúster de almacenamiento, cuenta o cola de soporte ya está fallando.
La localidad es un atributo del producto, no un eslogan
La localidad de los datos es una de las razones más fuertes para comprar de Cloud.ir. Las páginas de la empresa colocan la infraestructura en la nube en los centros de datos de ASIATECH en Irán, la página de CDN enfatiza las opciones de distribución doméstica, y la evidencia de red muestra el sitio de nube pública en AS60077 con una red principal iraní de ASIATECH. Para usuarios y empresas iraníes, eso puede significar menor latencia, alineación de pagos domésticos, lenguaje de soporte familiar, economía de tráfico local y un proveedor cuyo patrimonio físico está cerca de la audiencia prevista.
Pero la localidad debe definirse por servicio. Un servidor virtual puede ejecutarse en Irán mientras que un relé de correo electrónico, consola de gestión, servicio de análisis, copia de seguridad o archivo adjunto de soporte toma otra ruta. Un producto CDN puede ofrecer modos de distribución doméstica e internacional. Un servicio de almacenamiento puede replicarse en varios servidores sin decir si esos servidores están en edificios separados.
Un cliente no puede inferir la ubicación exacta de cada copia de datos a partir de la dirección de la empresa, el dominio de nivel superior, el nombre del sistema autónomo o la frase “centros de datos en todo Irán”.
La propia fila de región de Cloud.ir para un perfil orientado al comprador puede ser global porque la alcanzabilidad IP es global y los clientes de la nube pueden estar en cualquier lugar con una cuenta funcional y una ruta de red. Eso es diferente de decir que la empresa opera regiones globales. La evidencia del producto público revisada aquí apunta más fuertemente a la infraestructura iraní y al patrimonio del centro de datos doméstico de ASIATECH. Si un cliente necesita un servicio solo para Irán, debe solicitar una declaración por escrito sobre la localidad de cómputo, almacenamiento, copia de seguridad, registro y acceso de soporte.
Si un cliente necesita continuidad en varios países, debe preguntar si Cloud.ir mismo proporciona eso o si el cliente debe construirlo con otro proveedor.
La localidad también cambia la respuesta a incidentes. Un sitio de contenido iraní doméstico puede preferir el comportamiento de CDN doméstico de Cloud.ir y las instalaciones de ASIATECH porque la mayoría de los usuarios están cerca de esas rutas. Un vendedor de SaaS internacional puede preocuparse por el acceso a pagos, la exposición a sanciones, la latencia de usuarios extranjeros, el filtrado de rutas, la resolución de disputas y la capacidad de exportar datos bajo presión.
Un usuario del sector público o regulado puede valorar el control local de la instalación pero necesita una declaración más estricta sobre quién puede acceder a los datos, dónde se encuentran las instantáneas y cómo se manejan las órdenes de las autoridades. La misma infraestructura puede ser adecuada para un cliente e inadecuada para otro.
La prueba práctica es la evidencia. Pregunte por las opciones de región y sitio disponibles en el panel del cliente. Pregunte si dos instancias pueden colocarse en instalaciones separadas. Pregunte dónde se almacenan las copias de seguridad programadas. Pregunte dónde se mantienen los registros de CDN y los metadatos de almacenamiento. Pregunte si los ingenieros de soporte pueden acceder a los discos, instantáneas, claves o consolas del cliente, y desde dónde. Pregunte si se puede completar una exportación completa sin mantener la cuenta activa durante otro ciclo de facturación largo.
Un proveedor que puede responder estas preguntas con calma es más fácil de confiar que uno que se basa solo en un lenguaje amplio de localidad.
Los principales caminos de falla pasan por rack, ruta, stock de hardware, estado de cuenta y migración
La falla más probable de Cloud.ir para la que un cliente debe planificar no es una interrupción total dramática. Es una falla parcial que se encuentra entre las capas contractuales. Una VM puede estar bien mientras una ruta upstream está degradada. Una ruta puede estar bien mientras el rendimiento del almacenamiento colapsa. Una copia de seguridad puede existir mientras el rendimiento de restauración es demasiado lento. Una CDN puede responder contenido estático mientras las funciones dinámicas fallan. Un panel de cliente puede ser accesible mientras el pago impide una reconstrucción.
Estos estados intermedios son donde los clientes aprenden si el servicio tiene suficiente detalle operativo detrás.
El camino del rack comienza con el hardware físico. Una falla del host puede mover una VM bien diseñada a otro host si hay almacenamiento compartido, capacidad de host de repuesto y orquestación funcional. También puede dejar a un cliente esperando una pieza si está involucrado almacenamiento local, asignación de metal desnudo o un componente no redundante. Las páginas públicas de Cloud.ir no revelan la plataforma del hipervisor, la clase de host, las opciones de almacenamiento local versus compartido ni la política de hardware de repuesto.
Los clientes deben preguntar qué sucede cuando falla un servidor físico, qué servicios se reinician automáticamente, cuáles requieren un ticket y si hay un tiempo máximo garantizado para reconstruir en hardware equivalente.
El camino upstream comienza con la dependencia visible de AS60077 de AS43754. Si AS43754 filtra una ruta, tiene un problema de borde, cambia una política o sufre un incidente más amplio, los servicios del cliente de AS60077 pueden verse afectados incluso cuando las VM del cliente están encendidas. Debido a que los datos públicos muestran a AS43754 como el límite upstream observado para AS60077, el cliente debe preguntar si el ASN de la nube tiene routers de borde físico separados, múltiples traspasos a AS43754, algún tránsito externo directo y pruebas de conmutación por error recientes.
No es suficiente decir que la red principal tiene muchos vecinos; la pregunta relevante es qué sucede en el borde de la nube.
El camino del stock de hardware se trata de crecimiento y reparación. Los precios por hora de la nube y el escalado instantáneo son útiles solo si hay núcleos de CPU, RAM, discos, direcciones y puertos de switch de repuesto. Un comprador que planea una campaña, evento, lanzamiento o migración debe preguntar si la capacidad se puede reservar, si los aumentos grandes requieren aviso y si el proveedor puede colocar capacidad adicional en un dominio de falla separado. Un comprador más pequeño debe hacer una pregunta más simple: si mi host actual falla, ¿hay suficiente espacio de repuesto para reiniciar mi servidor en otro lugar?
El camino del soporte se trata de tiempo y autoridad. Cloud.ir dice que los clientes de servidores en la nube pueden enviar tickets en cualquier momento. Eso es mejor que un canal estrecho de horas hábiles, pero el cliente aún necesita objetivos de escalabilidad. ¿Quién puede cambiar una ruta BGP? ¿Quién puede autorizar una visita al rack? ¿Quién puede restaurar una copia de seguridad eliminada? ¿Quién puede revertir una suspensión de cuenta? ¿Quién puede explicar una orden legal o de seguridad? Si el equipo de soporte de primera línea solo puede reenviar una solicitud, el tiempo de reparación incluye cada traspaso.
El camino de migración es la red de seguridad final. Un cliente puede tolerar evidencia más débil si puede irse rápidamente. Eso requiere copias de seguridad actualizadas, imágenes o archivos exportables, procedimientos documentados de cambio de IP y DNS, TTL conocidos, acceso a la cuenta que permanece disponible durante disputas de facturación y suficiente ancho de banda para mover datos. También requiere evitar el bloqueo oculto: direcciones de red privada que no se pueden reproducir, características de almacenamiento sin una ruta de exportación, reglas de CDN que no se pueden recrear en otro lugar o instantáneas que no se pueden descargar.
Las páginas públicas de Cloud.ir describen reconstrucción, copias de seguridad y operaciones de cuenta, pero no revelan los términos completos de portabilidad. Los usuarios de producción deben obtenerlos antes de necesitarlos.
Lo que un comprador debe verificar antes de confiar en Cloud.ir
La primera tarea de verificación es la ubicación. Cloud.ir debe poder decir qué servicios se pueden colocar en qué ubicaciones iraníes, si una ubicación es un edificio distinto, una sala o una etiqueta lógica, y si dos instancias se pueden mantener separadas. Si la respuesta es “nuestra nube lo maneja”, el cliente debe solicitar una descripción del dominio de falla en lenguaje sencillo. Un proveedor pequeño no necesita terminología de hiperescala para ser confiable, pero sí necesita límites honestos.
La segunda tarea es la diversidad de red. AS60077 es visible y legítimo, y AS43754 es una red principal sustancial. Ese es un buen punto de partida. No es lo mismo que probar que el tráfico del cliente puede sobrevivir a un evento de borde de AS43754. Pregunte por la ruta normal, la ruta de respaldo, el diseño del router de borde, el límite de manejo de DDoS, las prácticas de RPKI y filtrado de rutas, y si Cloud.ir puede anunciar temporalmente un prefijo del cliente o mover una dirección pública durante un incidente. Para la mayoría de los clientes VPS, la respuesta será no, pero la pregunta aclara la dependencia.
La tercera tarea es la evidencia de restauración. Las copias de seguridad se enumeran como características del producto, y la página de precios distingue entre componentes de copia de seguridad semanal, de tres días y diaria. El cliente debe preguntar cómo se programan las instantáneas, qué se captura, qué no se captura, dónde se almacenan las copias de seguridad, cuánto tiempo se retienen, cuál es el tiempo de restauración típico, si una restauración puede dirigirse a otro sitio y si el proveedor tiene resultados de pruebas de restauración recientes.
Una copia de seguridad que no puede salir del límite dañado es un seguro solo contra una clase estrecha de fallas.
La cuarta tarea es el mantenimiento y las exclusiones. El SLA excluye el mantenimiento anunciado y los parches críticos del cálculo del tiempo de actividad. Pregunte cómo se anuncia el mantenimiento, cuánto aviso se da, si el trabajo de emergencia puede ocurrir sin aviso normal, si el cliente puede elegir una ventana y si múltiples recursos del cliente se mantienen juntos. Una ventana de mantenimiento no es mala; una ventana poco clara es mala.
La quinta tarea es la continuidad de la cuenta. Dado que la falta de pago está fuera del marco de penalización del SLA, los compradores de producción deben entender el financiamiento de la billetera, el tiempo de las facturas, los umbrales de suspensión, las rutas de apelación y la retención de datos después de la suspensión. Esto es especialmente importante para equipos fuera de Irán, equipos con demoras en las adquisiciones y equipos cuyo acceso de pago depende de una sola persona. Una falla de facturación puede convertirse en una interrupción evitable.
La sexta tarea es la salida. Exporte una imagen de servidor pequeña, restaure una copia de seguridad en una instancia limpia, mueva un registro DNS fuera de la CDN, recreue una política de firewall en otro lugar y documente el tiempo. Estas pruebas no necesitan ser grandes para ser reveladoras. Muestran si las abstracciones del proveedor ayudan al cliente a recuperarse o principalmente ayudan al cliente a quedarse.
La tesis operativa: servicio real, fuerte visibilidad de red, prueba física incompleta
CLOUD Asre Dadeha Asiatech merece un nivel de confianza más alto que una empresa con solo una entrada de enrutamiento obsoleta. Cloud.ir está activo, el catálogo de servicios es específico, la página de precios expone paquetes de recursos concretos, el SLA es público y los registros de RIPE colocan a AS60077 en la tabla de enrutamiento pública como AT-CLOUD Asre Dadeha Asiatech. El DNS del sitio de la empresa apunta a AS60077. AS60077 tiene un patrimonio de direcciones visible, y su dependencia de la red principal de AS43754 es observable en lugar de oculta.
Eso no hace que el servicio sea completamente transparente. El registro público no muestra la ubicación exacta del centro de datos de las cargas de trabajo del cliente, el número de hosts disponibles, la cantidad de hardware de repuesto, el tiempo de restauración en el mundo real, la ubicación de cada copia de seguridad, la diversidad física de las rutas, el diseño de conmutación por error de rutas en el borde de la nube, o los términos de cuenta y migración en los que un cliente confiaría durante una disputa.
El propio marketing de Cloud.ir hace afirmaciones sólidas sobre la disponibilidad y la persistencia de los datos, mientras que su SLA dibuja límites prácticos sobre lo que está cubierto.
Por lo tanto, la lectura correcta es equilibrada. El producto existe. La red es visible. La dependencia física es real. Un comprador puede considerar razonablemente a Cloud.ir para cargas de trabajo que se benefician de la proximidad del centro de datos iraní, la infraestructura doméstica de ASIATECH y un panel de control de nube local. El mismo comprador debe evitar tratar la etiqueta de nube como prueba de resiliencia multisitio, diversidad de rutas o salida sin problemas. Esos son hechos de ingeniería y contractuales que deben obtenerse, probarse y documentarse.
Para un sitio web pequeño, la incertidumbre restante puede ser aceptable si las copias de seguridad son independientes y el DNS puede moverse rápidamente. Para una propiedad de medios iraní de alto tráfico, la CDN y el alojamiento doméstico pueden ser valiosos, pero el operador debe probar la falla del origen, el comportamiento de la caché y la escalabilidad del soporte antes de un lanzamiento. Para datos regulados o transfronterizos, las preguntas clave son la localidad, la exposición a la autoridad, el acceso de soporte y los derechos de exportación.
Para cualquier cliente de producción, la disciplina final es la misma: compre el servicio en la nube, pero audite la historia del rack, la ruta, la reparación y la migración detrás de él.