Cloud9 Cloud 9 Ltd. vende capacidad alojada que aún depende de racks, tránsito y ventanas de reparación

Resumen

• El propio sitio público de Cloud9 la presenta como un proveedor georgiano de alojamiento, nube y centro de datos, con servicios que incluyencolocación y racks,VPS,VDS,servidores dedicados,alojamiento compartido,correo Zimbra, dominios, SSL y servicios de portal para clientes.
• La evidencia de red es significativa.RIPEstat muestra AS57814como anunciado para el titular Cloud9 Cloud 9 Ltd. el 12 de julio de 2026, mientras queAS49297está vinculado al mismo titular pero no está anunciado. Los recuentos RIPE RIS para AS57814 muestran28 prefijos IPv4 originados, 13 prefijos IPv4 en tránsito, tres prefijos IPv6 originados y dos prefijos IPv6 en tránsito.
• El centro de gravedad físico es Tiflis. Lapágina del centro de datosde Cloud9 afirma que la mayoría de sus servicios se prestan desde su propio centro de datos en Tiflis, yPeeringDB enumerauna instalación Cloud9 Dinamo Arena en A. Tsereteli Ave 2, Tiflis, con presencia en un punto de intercambio y contactos de soporte públicos.
• El riesgo para el comprador no es que Cloud9 sea invisible. Es que la evidencia pública aún no demuestra la capacidad de conmutación por error específica para el cliente, la disponibilidad de hardware de repuesto, el rendimiento de la restauración de copias de seguridad, la escalada de soporte o los derechos de salida. Los clientes deben verificar esos términos antes de tratar la capacidad alojada en Cloud9 como un sustituto de su propio diseño de continuidad.

La empresa es lo suficientemente visible para analizarla

Cloud9 Cloud 9 Ltd. merece una lectura más concreta que muchas pequeñas entradas de alojamiento porque coinciden varios registros públicos independientes. El sitio web de la empresa utiliza la marca Cloud9 para un negocio de alojamiento y centro de datos en Georgia. Lapágina de iniciodescribe a Cloud9 como un proveedor profesional de alojamiento web y un operador experimentado de centro de datos en Georgia. El pie de página muestra una dirección operativa en 2 Akaki Tsereteli Ave., Dinamo Stadium, Gate 5, Tiflis, Georgia 0112, con un número de teléfono y un correo electrónico de soporte. Lostérminos de servicioidentifican a "Cloud 9 LLC", con número de identificación de empresa 405063755, con una dirección legal en Tiflis y correos electrónicos de contacto para asuntos contractuales y de soporte. La denominación no es perfectamente uniforme en todas las superficies públicas, pero la dirección, el dominio y los registros de registro apuntan al mismo operador de alojamiento georgiano.

Los registros RIR hacen que esa identidad sea más que una afirmación en un sitio web.RIPE RDAP para AS57814indica que la organización registrada es Cloud 9 Ltd., muestra la dirección 2 Tsereteli ave, 0112, Tiflis, Georgia, y proporciona contactos administrativos, técnicos y de abuso públicos.RIPE RDAP para ORG-CL434-RIPEindica que la organización es Cloud 9 Ltd., la misma dirección de Tiflis, un número de teléfono y un correo electrónico de contacto.RIPE RDAP para AS49297vincula otro sistema autónomo a la misma organización y conjunto de contactos.

Esto es importante porque los servicios visibles de la empresa son servicios de infraestructura. Cloud9 vende capacidad orientada al cliente: alojamiento compartido, servidores virtuales, servidores dedicados, colocación, correo, dominios, certificados y servicios de centro de datos. Un cliente que compra esos servicios no está comprando simplemente una marca; el cliente está confiando en el espacio en rack, la alimentación, el enrutamiento, el trabajo de soporte y los términos contractuales. La evidencia pública es lo suficientemente sólida como para situar a Cloud9 en esa categoría.

No es lo suficientemente sólida como para responder a todas las preguntas sobre la continuidad del cliente sin los documentos de contrato y diseño.

El marco más importante es, por lo tanto, práctico. Cloud9 es visible como un proveedor de alojamiento y red georgiano en funcionamiento. También concentra gran parte de la historia del cliente en torno a una instalación con nombre en Tiflis. Esa combinación es útil para el servicio regional y la localidad de los datos. También significa que un cliente debe preguntar dónde se ejecuta realmente cada servicio, cómo falla, cómo se recupera y qué sucede si el cliente necesita irse rápidamente.

El registro de red tiene dos números de AS, pero solo uno está visiblemente activo

La imagen del enrutamiento público tiene un centro claro y una salvedad importante.La vista general de AS de RIPEstat para AS57814muestra al titular como Cloud9 Cloud 9 Ltd. y marca el AS como anunciado en el momento de la consulta del 12 de julio de 2026.La vista general de AS de RIPEstat para AS49297muestra la misma cadena de titular pero marca ese AS como no anunciado en el mismo momento de la consulta.Los datos de prefijos anunciados de RIPEstat para AS57814enumeran un amplio conjunto de rutas visibles, incluyendo 185.229.110.0/24, 45.138.44.0/22 y 195.69.140.0/22 entre otras, mientras queel mismo endpoint para AS49297no devuelve prefijos anunciados.

Esa distinción debe preservarse. Sería erróneo decir que cada AS relacionado con Cloud9 está transportando tráfico activamente. También sería erróneo decir que la empresa no tiene una red visible. AS57814 está claramente activo en la vista de rutas pública.Los recuentos de prefijos RIPE RISmuestran 28 prefijos IPv4 originados, 13 prefijos IPv4 en tránsito, tres prefijos IPv6 originados y dos prefijos IPv6 en tránsito para AS57814 en el momento de la consulta del 12 de julio de 2026. Estos recuentos no prueban cuántos clientes están activos, cuán completa está la plataforma o cuánta capacidad sobrante existe, pero sí muestran una superficie de red materialmente mayor que una sola ruta inactiva.

Los ejemplos de rutas también muestran la visibilidad actual de los prefijos.La vista general del prefijo 185.229.110.0/24 en RIPEstatdice que el prefijo es anunciado por AS57814 y lo relaciona con 185.229.108.0/22.La muestra de estado BGP de RIPEstat para 185.229.110.0/24devolvió cientos de observaciones de ruta, con rutas que llegaban a AS57814 a través de ASes de tránsito o pares como AS20771 y AS35805 en la muestra.BGP.tools para AS57814describe a Cloud 9 Ltd. como una red de larga duración que se empareja con otras redes y tiene transportadores de tránsito, yBGP.tools para 185.229.110.0/24muestra ese prefijo originado por AS57814.

La inferencia operativa es equilibrada. Cloud9 no es un revendedor sin ubicación y sin red. La empresa tiene un AS activo, visibilidad IPv4 e IPv6, objetos de ruta y datos de peering públicos. Pero la visibilidad de rutas no es lo mismo que una garantía para el cliente. Un cliente aún necesita saber cuáles de sus cargas de trabajo se asientan en los prefijos propios de Cloud9, cuáles se asientan en plataformas de proveedores, qué rutas transportan servicios de respaldo y si un evento de conmutación por error tiene suficiente margen después de la carga normal del cliente.

El centro de datos es el corazón de la oferta

Lapágina del centro de datosde Cloud9 es inusualmente directa sobre la dependencia física. Dice que la mayoría de los servicios proporcionados por Cloud9 se prestan desde su propio centro de datos con sede en Tiflis. La página describe un centro de datos neutral en cuanto a operadores, monitorización 24/7/365 por parte de ingenieros, controles de seguridad, redundancia eléctrica, detección y extinción de incendios, control climático e interconectividad. Dice que la instalación está alimentada por tres subestaciones eléctricas independientes y un generador diésel de respaldo de 630 kVA; también dice que la zona de colocación cuenta con alimentación eléctrica redundante N+N con SAI. Para la conectividad, Cloud9 dice estar conectada a los principales operadores de telecomunicaciones y a pequeños proveedores de servicios de Internet a través de fibra oscura reservada con varias rutas alternativas y 250 Gbps de capacidad total de interconexión.

PeeringDB respalda la afirmación de la instalación de Tiflis de una manera diferente.El registro de instalación de PeeringDB para Cloud9 Dinamo Arenaenumera la instalación en A. Tsereteli Ave 2, Tiflis, Georgia 0112, con Cloud9 LTD como organización, una nota de que el negocio proporciona servicios de centro de datos, alojamiento, nube e ISP en Georgia, recuento de redes 7, recuento de intercambios 1 y recuento de transportadores 1.La relación red-instalación de PeeringDB para net_id 20057también vincula AS57814 a Cloud9 Dinamo Arena. Esa evidencia pública de PeeringDB no certifica el diseño de ingeniería, pero proporciona un anclaje de instalación independiente que coincide con el patrón de dirección en las propias páginas de Cloud9.

La cuestión clave es la capacidad instalada frente a la utilizable. Una página de centro de datos puede nombrar subestaciones, SAI y un generador, pero un cliente necesita saber cómo se comportan esos activos durante el mantenimiento y los fallos. ¿Cuántos racks están realmente construidos y alimentados? ¿Cuál es la potencia permitida por rack? ¿Cuánta capacidad de SAI y generador sobra después de la carga actual? ¿Cuánto combustible está contratado durante un corte de suministro prolongado? ¿Son realmente independientes las rutas de alimentación hasta el rack del cliente, o se comparten antes de un punto de fallo?

¿Cómo se prueba el arranque del generador bajo carga? Las páginas públicas no responden a esas preguntas con la profundidad que necesita un cliente.

La misma distinción se aplica a la conectividad. Una declaración de 250 Gbps de interconexión total es significativa, especialmente en un mercado regional, pero no es lo mismo que el ancho de banda disponible para el cliente durante un fallo. Un cliente necesita saber si su servicio utiliza tránsito compartido, una ruta de IXP, una conexión cruzada privada, una ruta de ISP local o una ruta de red troncal de Cloud9; si la ruta de respaldo sale del mismo edificio; y si alguna garantía de ancho de banda sobrevive a un corte de fibra o al mantenimiento del operador.

Las páginas públicas de Cloud9 dan suficiente confianza como para considerar que el centro de datos es real. No eliminan la necesidad de probar lo que un cliente puede consumir realmente durante una situación de estrés.

El alojamiento es un servicio de rack antes de ser un servicio en la nube

El menú minorista de Cloud9 es amplio. La empresa vendealojamiento compartido Linux,alojamiento compartido Windows,VPS,VDS,servidores dedicados,correo Zimbra,dominios, certificados y colocación. Lostérminos de serviciodescriben servicios de alojamiento, registro de dominios, alquiler de servidores virtuales, alquiler de servidores físicos, servicios de correo electrónico, servicios de centro de datos, seguridad y defensa contra DDoS, planificación de infraestructura de servidores, servicios DevOps y servicios en la nube. No todos tienen la misma dependencia.

El alojamiento compartido depende de servidores web, paneles de control, DNS, almacenamiento y políticas de soporte. El VPS depende del host físico, el hipervisor, el almacenamiento, las instantáneas y los controles de vecino ruidoso. El VDS se anuncia como un producto de servidor virtual más potente, pero aún depende de la asignación del servidor físico y del diseño de conmutación por error. El alquiler de servidores dedicados depende del hardware propiedad de Cloud9, del stock de reemplazo, del acceso a la consola remota y de la disponibilidad del personal.

La colocación depende del propio equipo del cliente, de los servicios de rack de Cloud9 y de la capacidad del cliente para reparar o autorizar manos remotas. El correo depende del funcionamiento del servidor de correo, del filtrado de spam, del DNS, del almacenamiento, de las copias de seguridad y de las herramientas de migración.

Las páginas de producto públicas hacen legible la oferta minorista, pero no pueden probar la disponibilidad de recursos por sí solas. Un plan VPS puede enumerar CPU, memoria y almacenamiento, pero el rendimiento real depende de la contención, la disposición del almacenamiento y la capacidad de fallo. Un servidor dedicado puede estar disponible para su compra, pero una placa base, un disco o una fuente de alimentación que fallen dependen del inventario de repuestos y de la respuesta del personal.

Una cuenta de alojamiento compartido puede ser barata, pero el tiempo de restauración depende de la frecuencia de las copias de seguridad, de su integridad y de si el sistema de copias de seguridad está aislado del servidor fallido. Un servicio de dominio o de correo puede gestionarse a través de un portal de cliente, pero la recuperación del cliente puede depender de si el DNS y las exportaciones de buzones de correo se pueden mover rápidamente.

Por eso, la capacidad alojada aún necesita una auditoría física por parte del cliente. La cuestión no es simplemente si el servicio existe. Es si el servicio sigue siendo utilizable después de que falle un host, un switch, un sistema de almacenamiento, una unidad de refrigeración, una ruta de alimentación, una conexión cruzada o un turno de soporte. La información pública de Cloud9 respalda a un proveedor de servicios real con una instalación y una red. No publica suficientes detalles como para inferir la supervivencia específica del cliente en cada uno de esos modos de fallo.

La colocación traza un límite claro de propiedad

Lapágina de colocaciónes una de las fuentes públicas más valiosas porque expone el límite entre la capacidad propiedad de Cloud9 y el equipo propiedad del cliente. Cloud9 vende opciones de colocación de 1U, 2U y torre, medios racks, racks completos y jaulas personalizadas. Las ofertas de 1U y 2U incluyen alimentación dual A/B, un enlace de 1 Gb/s y un enlace de gestión; la oferta de servidor torre incluye alimentación simple, un enlace de 1 Gb/s y un enlace de gestión. La página dice que la conectividad de 1 Gb/s es ilimitada hacia los ISP georgianos e incluye 30 Mb/s de conectividad global por cliente. También dice que el enlace de gestión es para acceso IPMI, iLO, iDRAC o BMC con IP interna y acceso VPN seguro.

Esos detalles son comercialmente útiles y también revelan los límites. La colocación no es lo mismo que el alojamiento dedicado gestionado. Las preguntas frecuentes de Cloud9 afirman que en la colocación el equipo es responsabilidad del cliente, mientras que Cloud9 ofrecerá asistencia para acelerar la corrección. Dice que Cloud9 tiene ingenieros disponibles 24/7/365 para manos remotas, y que Cloud9 ha realizado migraciones a gran escala, dependiendo cada migración de la carga de trabajo.

También dice que el espacio y las direcciones IP pueden estar listos en menos de 24 horas después del presupuesto y el pago inicial, mientras que los racks completos y las jaulas pueden tardar más debido a las piezas y la mano de obra.

Para los clientes, ese límite es decisivo durante las interrupciones. Si un servidor colocado tiene un fallo de disco, una avería en la fuente de alimentación o un problema de firmware, Cloud9 puede proporcionar manos remotas solo dentro del contrato del cliente y de los repuestos disponibles o del plan de reemplazo. Si el cliente no tiene discos de repuesto, ni credenciales de consola remota, ni medios de arranque documentados y ningún destino de migración, el rack puede permanecer encendido mientras la aplicación sigue fuera de línea.

Lo mismo ocurre con los cambios de red: un enlace de gestión ayuda solo si el cliente tiene derechos de acceso, detalles de VPN, credenciales conocidas y una ruta de consola probada.

El lenguaje de precios y ancho de banda también merece atención. Un enlace local de 1 Gb/s y 30 Mb/s de conectividad global pueden ser suficientes para muchos usos de alojamiento georgiano, pero no es lo mismo que el ancho de banda de nube global. Un cliente que presta servicios a usuarios internacionales, realiza copias de seguridad externas o exporta grandes volúmenes de datos necesita saber cómo se comportan el tráfico a ráfagas, la facturación, la congestión y la migración de emergencia más allá del uso mensual normal. La página de colocación da crédito a Cloud9 por hacer público el límite.

También proporciona a los compradores los términos que deben verificar antes de colocar allí hardware crítico.

El peering y la diversidad de rutas parecen mejores que la hipótesis más débil

La hipótesis de riesgo inicial de la asignación advertía de una huella pública escasa. La evidencia real de rutas y peering es más sólida.El registro de red AS57814 en PeeringDBenumera a Cloud9 como un perfil de servicios de red con AS57814, sitio webhttps://www.cloud9.ge/, soporte IPv6, alcance regional, tráfico saliente pesado, tráfico autoinformado de 200-300 Gbps, política de peering general abierta, un recuento de instalaciones y un recuento de intercambios. Enumera el AS-SET del IRR como AS-SET-CLOUD9. El perfil es automantenido y no debe tratarse como capacidad auditada, pero es un perfil de infraestructura pública, no una página en blanco.

La entrada netixlan de PeeringDBenumera a Cloud9 en IXP.ge con un puerto de 10.000 Mb/s, dirección IPv4 185.1.224.232, estado de servidor de rutas verdadero y estado operativo verdadero.El registro IXP.ge de PeeringDBdescribe el intercambio como en Tiflis y Kutaisi, con Cloud9 Dinamo Arena entre las entradas de instalaciones. La propiapágina del centro de datosde Cloud9 dice que la empresa también es un operador de punto de intercambio de Internet y proporciona conexiones cruzadas a los operadores. En conjunto, estas fuentes respaldan un papel significativo de interconexión local.

RIPEstat también muestra consistencia en las políticas de rutas en un conjunto más amplio de prefijos y pares.La consistencia de enrutamiento de AS para AS57814enumera muchos prefijos como presentes tanto en BGP como en los datos de enrutamiento de whois, incluyendo 45.138.44.0/22, 185.229.108.0/24, 185.229.109.0/24, 185.229.110.0/24, 188.93.88.0/24 y 195.69.140.0/22. También muestra varios pares de importación y exportación en BGP y whois, incluyendo AS49628, AS20771, AS35805, AS16010 y AS34797, junto con otros pares visibles en BGP que no están presentes en los datos whois comprobados.Los datos de longitud de ruta AS de RIPEstatmuestran AS57814 visible desde muchas ubicaciones de recolectores.

No es el perfil de un host de un solo prefijo con un único tránsito observable. Aun así, la diversidad en la capa de enrutamiento debe traducirse en resiliencia del servicio. Una ruta puede tener múltiples caminos mientras que un servicio de cliente sigue dependiendo de un switch de top of rack, un array de almacenamiento, una ruta de distribución de energía o una decisión de soporte.

Un cliente debe preguntar qué proveedores se utilizan para su servicio, si las rutas se monitorizan activamente, si Cloud9 puede cambiar el tráfico durante un evento de mantenimiento y si la accesibilidad internacional sigue siendo aceptable cuando un par o proveedor de tránsito está afectado.

La higiene de enrutamiento es parcial pero visible

La seguridad del enrutamiento es un área donde Cloud9 tiene evidencia visible, aunque debe evaluarse prefijo por prefijo.La validación RPKI de RIPEstat para AS57814 y 185.229.110.0/24devuelve un estado válido, incluyendo ROAs de validación para el origen 57814 que cubren 185.229.110.0/24 y 185.229.108.0/22. Eso es importante porque una autorización de origen de ruta válida ayuda a las redes a rechazar anuncios del origen incorrecto para ese prefijo. No resuelve el tiempo de inactividad de la aplicación, pero reduce una clase de errores de enrutamiento o secuestros.

Elendpoint de consistencia de enrutamiento de ASofrece otra señal positiva al mostrar muchos prefijos de Cloud9 tanto en los datos de enrutamiento BGP como en whois. El AS-SET del perfil de PeeringDB también proporciona a las redes un objeto público para usar en la política de enrutamiento. Estas son buenas señales para un proveedor regional, porque muchos incidentes operativos comienzan con un filtro de rutas, un objeto obsoleto, una ROA faltante o un desajuste entre lo que un proveedor anuncia y lo que un tránsito está dispuesto a transportar.

La salvedad es que la evidencia no es una certificación universal. El enlace de validación RPKI anterior valida un prefijo representativo, no todas las rutas. La salida de consistencia de enrutamiento de AS muestra algunas rutas whois que no están actualmente en BGP y algunos pares en BGP pero no en la política whois comprobada. Eso es normal para muchas redes, pero significa que las afirmaciones de cara al cliente deben medirse con respecto al prefijo o servicio exacto.

Un cliente que utiliza una dirección de un bloque determinado debe preguntar si ese bloque tiene una ROA válida, un objeto de ruta mantenido, filtros de tránsito documentados y un contacto de monitorización que pueda responder a fugas de rutas o pérdida de alcance.

La higiene de enrutamiento también debe relacionarse con los derechos de migración. Si el servicio de un cliente utiliza direcciones IP proporcionadas por Cloud9, el cliente necesita saber si esas direcciones pueden moverse con la carga de trabajo o si el DNS, los certificados, las listas de permitidos y la reputación del correo deben reconstruirse en otro lugar. La evidencia de red de Cloud9 es lo suficientemente sólida como para que los servicios del cliente puedan estar profundamente integrados con su espacio de direcciones. Eso hace que la documentación limpia sea más importante, no menos.

Las afirmaciones de energía y refrigeración necesitan pruebas específicas para el cliente

Las afirmaciones públicas del centro de datos de Cloud9 son lo suficientemente detalladas como para ser utilizadas, pero no lo suficientemente detalladas como para reemplazar la evidencia de ingeniería en un contrato. Lapágina del centro de datosdice que la instalación está alimentada por tres subestaciones eléctricas independientes y un generador diésel de 630 kVA. Dice que la zona de colocación tiene alimentación eléctrica redundante N+N y un sistema SAI. Describe la detección temprana de temperatura, humo y fuego, un sistema de extinción de incendios 3M Novec 1230, refrigeración DX, control de temperatura y humedad, sin ventanas ni paredes orientadas al exterior en las salas de servidores y solo tuberías de extinción de incendios cerca. También dice que todos los sistemas clave son monitorizados 24/7/365 por ingenieros.

Esas son las categorías correctas: energía, incendios, refrigeración, seguridad física y monitorización. La pregunta restante es si el cliente recibe un servicio redundante después de eventos de mantenimiento ordinarios y de fallo creíbles. Si un cliente compra colocación 1U con alimentación dual A/B, ¿se llevan ambas alimentaciones realmente a rutas de alimentación separadas, o puede un componente afectar a ambas? Si un cliente compra colocación en torre con alimentación simple, ¿ha valorado el cliente el riesgo de una sola fuente de alimentación?

Si un cliente alquila un servidor dedicado, ¿incluye el contrato los tiempos de reemplazo de componentes y una ruta de reemplazo de hardware? Si un servidor virtual se ejecuta en hardware de Cloud9, ¿qué nivel de fallo del host o del almacenamiento puede absorber la plataforma sin tiempo de inactividad?

La refrigeración tiene limitaciones ocultas similares. La refrigeración DX puede ser apropiada para la instalación, pero el cliente necesita conocer los límites de densidad a nivel de rack, el diseño de pasillo caliente y frío, la ubicación de los sensores y la ruta de escalada cuando un rack se calienta demasiado. Una instalación puede tener un diseño de refrigeración redundante mientras que un rack de cliente específico sigue estando limitado por el flujo de aire o la densidad de energía. La extinción de incendios también importa de manera diferente para la colocación física y los servicios virtuales.

Un evento de extinción de incendios puede proteger el equipo de daños mayores, pero aún puede resultar en controles de acceso de emergencia, ventanas de inspección y retrasos en la recuperación.

El sitio público dice que la instalación es de nivel 3 en el sentido de que puede programar el mantenimiento sin interrumpir el servicio. Las preguntas frecuentes sobre colocación explican el nivel 3 como el sistema de clasificación del Uptime Institute y dicen que el centro de datos de Cloud9 está en el nivel 3. Los clientes deben preguntar si Cloud9 posee una certificación de terceros vigente o si utiliza el término para describir la intención del diseño. La distinción no es pedante.

Un diseño alineado con los conceptos de Tier III es útil, pero una instalación certificada, un registro de mantenimiento auditado y una carta de redundancia específica para el cliente tienen un peso probatorio diferente.

El portal simplifica el servicio, pero la facturación y el acceso se convierten en dependencias

Lostérminos de serviciode Cloud9 son importantes porque muestran cómo los clientes tocan realmente la infraestructura. Los términos dicen que un usuario se registra en cloud9.ge y recibe una cuenta personal en el portal de Cloud9 en my.cloud9.ge, donde el usuario puede comprar nuevos productos, gestionar productos existentes, cancelar productos no deseados, controlar los pagos y abrir tickets de soporte en cualquier momento. Los términos también establecen que el usuario es responsable de mantener la confidencialidad de la cuenta y de las acciones realizadas con la misma.

Ese diseño del portal es útil. Permite a los clientes gestionar la infraestructura sin esperar una conversación de ventas. También convierte el acceso a la cuenta en una dependencia de continuidad. Si la cuenta de correo electrónico autorizada del cliente se pierde, si las credenciales se ven comprometidas, si un miembro del personal se va o si los contactos de facturación no se actualizan, la capacidad del cliente para abrir tickets, cancelar servicios, controlar los pagos o realizar cambios de emergencia puede verse afectada.

Los términos ponen la responsabilidad en el usuario de mantener actualizados los datos de las personas de contacto, el registro, el correo electrónico y el teléfono. Es un lenguaje legal ordinario, pero se vuelve operativo durante una interrupción.

La facturación es otra dependencia de la ruta de reparación. Si un problema de factura o de período de liquidación desactiva un servicio, el cliente puede experimentar una interrupción técnica cuya causa raíz es administrativa. El cliente debe saber cómo notifica Cloud9 a los contactos de la cuenta, cuánto aviso se aplica antes de la suspensión o terminación, si la restauración de emergencia está disponible después del pago y qué persona puede autorizar un cambio durante una crisis. Los términos públicos pueden describir el contrato general.

Los clientes críticos aún necesitan un gobierno de la cuenta: propiedad compartida del portal, contactos documentados, reglas de baja y escalada de soporte probada.

La retención y eliminación de datos también importan. Los términos y el lenguaje de privacidad de Cloud9 dicen que los datos personales y los datos de prestación de servicios pueden almacenarse durante períodos legales y de servicio definidos, y que los datos pueden ser eliminados o destruidos después del período de retención correspondiente. Los clientes deben distinguir entre los datos de la cuenta, los registros, las copias de seguridad, los datos de los buzones de correo, los archivos alojados y las imágenes de las máquinas virtuales.

La capacidad de un cliente para abandonar Cloud9 depende del formato de exportación, del momento de la eliminación, de la disponibilidad de las copias de seguridad y de si el cliente puede recuperar los datos después de la cancelación.

La lección práctica es simple: el portal es parte de la infraestructura. Los clientes deben asegurarlo como el acceso a producción, asignar más de un mantenedor autorizado, mantener los datos de facturación actualizados y verificar el procedimiento de soporte de emergencia antes del primer incidente.

La soberanía de los datos es una fortaleza solo si la ubicación del servicio es explícita

La afirmación de localidad más fuerte de Cloud9 es la presencia georgiana. El sitio web de la empresa, los términos, los registros RIPE y PeeringDB apuntan todos a Tiflis.RIPE RDAP para ORG-CL434-RIPEenumera a Cloud 9 Ltd. en Tiflis.El registro de instalación de PeeringDBenumera Cloud9 Dinamo Arena en Tiflis.La geolocalización de RIPEstat para 185.229.110.0/24coloca ese prefijo representativo en Tiflis en el momento del resultado de julio de 2026. La página del centro de datos de Cloud9 dice que la mayoría de los servicios se prestan desde el propio centro de datos de Cloud9 en Tiflis.

Para los clientes que necesitan alojamiento georgiano, soporte local o acceso de baja latencia a las redes georgianas, eso es valioso. Muchas empresas no quieren que cada carga de trabajo se envíe a una región de hiperescala en otra jurisdicción, especialmente cuando el soporte al cliente, las solicitudes regulatorias, el idioma y las rutas de Internet locales importan. Las ofertas de colocación y servidores virtuales de Cloud9 pueden leerse, por lo tanto, como una apuesta por la capacidad local: el cliente compra proximidad, una empresa local, acceso a operadores locales e instalación local.

La palabra "mayoría" sigue siendo importante. Las páginas públicas de Cloud9 no prueban que cada servicio, copia de seguridad, registro de correo, función del portal, servicio DNS, servicio de seguridad o conjunto de datos de soporte se almacene solo en Georgia. Lapolítica de privacidadhabla del procesamiento de datos personales y la prestación de servicios, pero el texto público no asigna cada producto a una ubicación de almacenamiento. Lostérminos de servicioenumeran una amplia cartera de servicios, incluidos dominios, certificados, correo, seguridad, defensa contra DDoS y servicios en la nube, algunos de los cuales pueden implicar sistemas de terceros. Eso es normal para las empresas de alojamiento, pero significa que la localidad de los datos debe especificarse por servicio.

Un cliente con requisitos de soberanía debe, por lo tanto, pedir a Cloud9 una declaración de ubicación del servicio. ¿Dónde está la carga de trabajo principal? ¿Dónde están las copias de seguridad? ¿Dónde están los registros? ¿Dónde están los tickets de soporte? ¿Qué registros externos, autoridades de certificación, sistemas de seguridad de correo o procesadores de pagos tocan los datos del cliente? ¿Se pueden exportar y eliminar todos los datos en un calendario definido? Si el cliente necesita procesamiento solo en Georgia, ¿qué productos de Cloud9 califican y cuáles no?

La evidencia pública de Cloud9 respalda a Tiflis como un fuerte centro de gravedad. No resuelve automáticamente todas las cuestiones de soberanía de datos.

El DNS y los servicios de dominio hacen que Cloud9 forme parte del plano de control de los clientes

Cloud9 venderegistro de dominios, alojamiento adyacente al DNS y servicios de correo, por lo que su papel puede ir más allá de la computación. El panel de servidores de nombres del sitio enumera los servidores de nombres de cPanel para alojamiento Linux, Windows y VPS: ns1.cpanel.ge y ns2.cpanel.ge para alojamiento Linux, ns5.cpanel.ge y ns6.cpanel.ge para alojamiento Windows, y ns3.cpanel.ge y ns4.cpanel.ge para alojamiento VPS. Las observaciones públicas de DNS muestran que cloud9.ge utiliza ns1.cpanel.ge y ns2.cpanel.ge como servidores de nombres autoritativos, que cloud9.ge se resuelve a 188.93.90.171, y que su registro MX apunta a tbs01-mail02.cpanel.ge. Estos nombres vinculan la oferta web, de alojamiento y de correo al espacio de nombres de servicio del propio proveedor.

Esto es importante porque el DNS es un plano de control, no una decoración. Si un cliente aloja un sitio web, un dominio de correo o una aplicación en Cloud9 y utiliza los servidores de nombres gestionados por Cloud9, un incidente de DNS puede afectar a la migración, la conmutación por error y la recuperación incluso cuando el servidor subyacente está en buen estado. Por el contrario, si el cliente mantiene el DNS en un proveedor independiente y utiliza Cloud9 solo para la computación o la colocación, el cliente puede redirigir el tráfico más rápidamente durante un problema del servicio de Cloud9.

La elección correcta depende de la tolerancia al riesgo y del nivel de habilidad del cliente.

El registro de dominios añade otra capa. Un cliente que compra dominios a través de Cloud9 debe saber cómo funciona el acceso al registro, si el cliente puede obtener códigos de transferencia rápidamente, quién recibe los avisos de renovación, si los bloqueos de dominio están activos y qué sucede si un problema de facturación coincide con la renovación. Un dominio puede sobrevivir a cualquier proveedor de alojamiento, pero solo si el cliente mantiene el control de las credenciales, los datos del registrante y los derechos de transferencia.

El correo aumenta aún más las apuestas. El correo Zimbra puede ser conveniente para las empresas que desean un producto de buzón alojado local, pero la recuperación del correo depende del DNS, de las copias de seguridad de los buzones, de los formatos de exportación, de la reputación antispam, de las contraseñas de los usuarios y de los tiempos de soporte. Los clientes deben preguntar cómo se pueden exportar los buzones, cómo se restauran los registros DNS, cuánto tiempo permanece recuperable el correo eliminado y qué compromiso de soporte se aplica durante una interrupción del correo.

Los servicios de dominio y correo de Cloud9 son partes legítimas de su oferta. También hacen de Cloud9 un proveedor de plano de control para los clientes que, de otro modo, podrían pensar que solo están comprando servidores.

Las principales vías de fallo son ordinarias, no exóticas

Las vías de fallo más creíbles de Cloud9 no son eventos de ciencia ficción. Son problemas de infraestructura familiares: un fallo de alimentación en un rack, un incidente de refrigeración, un fallo de hardware, una fuga de rutas, un fallo del transportador de tránsito, un evento de DDoS, una suspensión de facturación, un problema de acceso al portal, una copia de seguridad fallida, una sustitución lenta de repuestos, una migración fallida o una cola de soporte que crece más rápido de lo que el personal puede despejarla.

Debido a que Cloud9 ofrece tanto servicios alojados como colocación, el impacto en el cliente depende de lo que el cliente haya comprado.

Para un cliente de alojamiento compartido, el fallo puede ser un sitio web fuera de línea, una base de datos no disponible, un error de DNS, un problema de inicio de sesión en el panel de control o un retraso en la restauración de la copia de seguridad. Para un cliente de VPS o VDS, el fallo puede ser la contención del host, un fallo de almacenamiento, el mantenimiento del hipervisor, una consola de gestión inaccesible o la pérdida de red. Para un cliente de servidor dedicado, el fallo puede ser un componente físico que requiera inventario y sustitución manual.

Para un cliente de colocación, el fallo puede ser hardware propiedad del cliente al que Cloud9 puede ayudar a acceder pero que no posee. Para un cliente de dominio, el fallo puede ser la pérdida de control sobre el nombre en lugar del servidor. Para un cliente de correo electrónico, el fallo puede ser el acceso al buzón, el enrutamiento DNS, la puesta en cola del correo o la reputación de spam.

La vista de rutas sugiere que Cloud9 tiene más diversidad de red que un pequeño proveedor con un solo enlace, pero eso no elimina la concentración del servicio. Si muchos servicios de clientes están dentro de una misma instalación, un evento a nivel de instalación puede seguir siendo importante incluso con múltiples transportadores. Si las copias de seguridad se almacenan en el mismo sitio, la recuperación puede retrasarse por el mismo incidente que deja fuera de línea la producción. Si los tickets de soporte y el acceso a la facturación dependen del portal, un problema de cuenta o del portal puede complicar la reparación técnica.

Si un cliente posee equipos colocados pero no tiene repuestos locales, la instalación puede estar funcionando normalmente mientras la carga de trabajo del cliente sigue caída.

Es por eso que la evidencia pública de Cloud9 debe leerse como un punto de partida para la diligencia debida, no como un sustituto de la misma. Los clientes deben preguntar qué falla en conjunto. ¿Los servidores alojados, el DNS, el portal y los destinos de copia de seguridad comparten el mismo edificio? ¿Tiene el servicio un segundo sitio? ¿Las instantáneas se almacenan fuera del sistema de almacenamiento principal? ¿Se prueban los cambios de ruta? ¿Puede un cliente mover un dominio, un buzón de correo o una imagen de servidor durante una disputa o emergencia?

Cada respuesta reduce la brecha entre "alojado en un centro de datos" y "recuperable cuando el centro de datos, la red o la ruta de la cuenta están bajo estrés".

La migración es el coste oculto de la capacidad barata

La página de colocación de Cloud9 dice que la empresa ha realizado migraciones a gran escala y que ayudará a los clientes a planificar y ejecutar un traslado a su centro de datos. Es una señal positiva porque la habilidad de migración es importante en el alojamiento regional. Pero cada migración tiene dos caras: entrar en el proveedor y salir del proveedor. Los clientes a menudo negocian la primera cara cuidadosamente e ignoran la segunda hasta que un corte, un cambio de precios, una demanda de cumplimiento o una venta del negocio fuerza la pregunta.

El problema de salida es diferente para cada servicio de Cloud9. Los clientes de alojamiento compartido necesitan archivos del sitio web, bases de datos, zonas DNS, cuentas de correo y registros. Los clientes de VPS necesitan imágenes de VM, instantáneas o construcciones de servidor reproducibles. Los clientes de VDS y servidores dedicados necesitan acceso al sistema operativo, rutas de copia de datos, reglas de firewall, imágenes, licencias y planes de renumeración de IP. Los clientes de colocación necesitan acceso físico, ventanas de envío, coordinación de manos remotas, mapas de cableado y listas de equipos.

Los clientes de dominio necesitan códigos de transferencia y registros de registrante desbloqueados. Los clientes de correo necesitan exportaciones de buzones, cambios de DNS y reconfiguración del usuario. Un cliente que utiliza varios servicios a la vez necesita el mapa completo.

El ancho de banda puede convertirse en el factor limitante. La página de colocación de Cloud9 dice que la conectividad estándar del cliente incluye 1 Gb/s ilimitado hacia los ISP georgianos y 30 Mb/s de conectividad global por cliente. Eso puede ser perfectamente adecuado para cargas de trabajo locales normales, pero una exportación masiva a otro país puede comportarse de manera muy diferente.

Si un cliente necesita mover terabytes de máquinas virtuales, copias de seguridad o buzones de correo, el cliente debe saber si hay actualizaciones temporales de ancho de banda disponibles, cuánto cuestan y si el tráfico de migración compite con el tráfico de producción.

El direccionamiento IP es otro coste oculto. Si los servicios de un cliente se construyen en torno a direcciones IP proporcionadas por Cloud9, la migración requiere cambios de DNS, reemisión de certificados, actualizaciones de la lista de permitidos del firewall, reconstrucción de la reputación del correo y comunicación con el cliente. Si el cliente tiene direcciones independientes del proveedor o mantiene el DNS con TTL corto e independiente, la migración puede ser más fácil. La presencia de red de Cloud9 es útil, pero un cliente no debe asumir que el espacio de direcciones utilizado hoy puede viajar con el servicio mañana.

La postura más segura para el comprador es tratar el primer plan de migración y el plan de salida como un solo documento. Si Cloud9 es el proveedor adecuado, aún debería ser posible definir cómo el cliente recupera los datos, los dominios, los buzones de correo, las imágenes del servidor y el equipo bajo su propio control.

Lo que los clientes deben verificar antes de colocar cargas de trabajo críticas

La evidencia pública respalda a Cloud9 como un proveedor de infraestructura georgiano real. Las preguntas del cliente son, por lo tanto, más avanzadas que "¿existe?" El primer conjunto se refiere a la instalación y la capacidad. ¿Qué instalación exacta aloja el servicio? ¿Es Cloud9 Dinamo Arena, otra sala de Cloud9 o una plataforma de terceros? ¿Cuántos racks, alimentaciones eléctricas, rutas de refrigeración y rutas de red están implicados para el servicio específico del cliente? ¿Cuál es la densidad de energía del cliente, la asignación de ancho de banda y la capacidad de conmutación por error?

¿Hay un segundo sitio y está activo, en caliente o solo de respaldo?

El segundo conjunto se refiere a la operación de la red. ¿Qué prefijos utilizará el servicio del cliente? ¿Están cubiertos por ROAs RPKI válidas y objetos de ruta actuales? ¿Qué tránsitos y pares transportan el tráfico del cliente? ¿Obtiene el cliente alguna garantía de diversidad de rutas? ¿Qué sucede si falla IXP.ge, un tránsito, una ruta de fibra o una conexión del edificio? ¿Cómo se manejan las fugas de rutas, los eventos DDoS y los problemas de accesibilidad internacional? ¿Qué visibilidad puede ver el cliente durante un incidente?

El tercer conjunto se refiere a la recuperación de datos. ¿Con qué frecuencia se realizan las copias de seguridad? ¿Dónde se almacenan? ¿Son inmutables o están aisladas de las credenciales de producción? ¿Con qué frecuencia se prueban las restauraciones? ¿Con qué rapidez se puede restaurar un servidor virtual completo, un buzón de correo o una base de datos? ¿Puede un cliente restaurar sin que el portal principal de Cloud9 esté disponible? ¿Están incluidas las exportaciones de copias de seguridad en el precio y las exportaciones de emergencia están limitadas por el ancho de banda?

El cuarto conjunto se refiere al soporte y al control. ¿Quién responde fuera del horario laboral? ¿Qué problemas están cubiertos por las manos remotas y cuáles son facturables? ¿Cuál es la ruta de escalada de soporte para la colocación, la sustitución de servidores dedicados, los cambios de ruta, las transferencias de dominio y las interrupciones del correo? ¿Cuántos contactos autorizados puede mantener el cliente? ¿Qué sucede si el contacto de facturación se va? ¿Puede el cliente designar contactos de emergencia separados de los contactos de facturación?

El quinto conjunto se refiere a la salida. ¿Puede el cliente recibir una lista de activos actual, un archivo de zona DNS, una exportación de buzón de correo, una imagen de VM, una copia de seguridad, un código de transferencia de dominio y un registro de acceso a petición? ¿Cuánto aviso se requiere? ¿Qué sucede durante una disputa? ¿Cuánto tiempo son recuperables los servicios eliminados o cancelados? ¿Qué datos se destruyen y cuándo? Estas preguntas no son hostiles. Son los términos mínimos que convierten un servicio alojado en una dependencia responsable.

Conclusión

Cloud9 Cloud 9 Ltd. debe considerarse como un proveedor de alojamiento y centro de datos georgiano en funcionamiento con evidencia de infraestructura pública creíble. Sus propias páginas venden los servicios relevantes. Los registros RIPE vinculan a Cloud 9 Ltd. con AS57814 y AS49297, y RIPEstat muestra AS57814 como anunciado mientras que AS49297 no es visible en BGP. AS57814 tiene una superficie de rutas significativa en IPv4 e IPv6, con visibilidad de origen y tránsito. PeeringDB sitúa a Cloud9 en Cloud9 Dinamo Arena en Tiflis y muestra presencia en IXP.ge.

La página del centro de datos de Cloud9 hace afirmaciones concretas sobre la instalación en cuanto a energía, refrigeración, extinción de incendios, monitorización e interconexión de operadores.

Eso es suficiente para ir más allá de la interpretación más débil. Cloud9 no es simplemente un nombre en un directorio. Es un proveedor de infraestructura local con una oferta centrada en la instalación, presencia de enrutamiento público y productos minoristas que pueden importar para las empresas, desarrolladores, organismos públicos y proveedores de servicios regionales georgianos. La propuesta de valor es clara: comprar capacidad alojada o colocada cerca de las redes georgianas, con soporte local y un operador de centro de datos que se presenta como neutral en cuanto a operadores.

El riesgo restante es el mismo riesgo que acompaña a todos los proveedores regionales de nube y alojamiento. La etiqueta de nube no borra los racks, el tránsito, la energía, el hardware, el DNS, la facturación, el acceso a la cuenta o la migración. Las páginas públicas no prueban la capacidad sobrante durante un fallo de componente, la velocidad de restauración tras un incidente de copia de seguridad, los derechos de exportación del cliente, la escalada fuera de horario o la conmutación por error limpia de una instalación a otra. Los clientes pueden utilizar bien Cloud9 si documentan esos términos. No deben usarlo como una caja negra.

Para cargas de trabajo críticas, la capacidad de Cloud9 debe tratarse como real pero dependiente del contrato. La empresa tiene suficiente evidencia de infraestructura pública para ser tomada en serio. La seguridad del cliente depende de convertir esa evidencia en respuestas específicas: dónde se ejecuta la carga de trabajo, qué falla con ella, cómo sobreviven las rutas, cómo se restauran las copias de seguridad, quién repara el hardware, quién responde fuera de horario, qué sucede cuando una factura o un contacto de cuenta falla y cómo sale el cliente sin perder datos o control.