Resumen

  • Outofbox Cloud tiene una ruta pública actual: AS147192 origina 103.174.148.0/23, y esa ruta fue visible para 325 de 326 pares IPv4 de RIPE RIS en la observación del 15 de julio de 2026.
  • La evidencia física se concentra en Sadashiv Nagar, Belagavi. Un informe local de 2020 describió más de 100 servidores instalados y espacio para casi 300, mientras que una visita universitaria de septiembre de 2025 describió racks, refrigeración y energía de respaldo en la misma localidad. Ninguna fuente demuestra la capacidad actual energizada, utilizable o de reserva del sitio.
  • La afirmación de la empresa de ocho regiones de centros de datos no está acompañada en sus páginas públicas de producto por ocho nombres de ciudades, operadores de instalaciones, diseños de energía, cifras de capacidad o un historial de estado región por región. Sus propios términos también niegan la operación ininterrumpida o libre de errores a pesar de una afirmación separada de SLA del 99.99 %.
  • AS147192 tiene un vecino observado, AS141815, registrado a nombre de la entidad legalmente distinta Outofbox Networks Private Limited. Esa red tiene una conectividad de upstream e intercambio más amplia, pero la diversidad de rutas lógicas más allá del primer salto no establece entradas de fibra, conductos, edificios, alimentaciones de servicios públicos o dominios de falla diversos para Outofbox Cloud.

Se anuncian ocho regiones; solo se evidencia una localidad

La frase más trascendental en el sitio de producto de Outofbox Cloud no es el precio de una máquina virtual pequeña. Es la afirmación, en lapágina de Boxesde la empresa, de que los clientes pueden implementar sus cargas de trabajo en ocho regiones de centros de datos. Esa misma página utiliza la frase de marketing "disponibilidad global" y anuncia un tiempo de lanzamiento de 55 segundos y un SLA de disponibilidad del 99.99 %. Estas son propuestas medibles, pero no son evidencia de una huella operativa global. Implican más que una tienda web: suficiente capacidad instalada de cómputo, almacenamiento y direcciones para aceptar un pedido; un plano de control capaz de ubicar la carga de trabajo; una instalación con energía; una ruta enrutada; personal de soporte; y, si la palabra "regiones" se utiliza en su sentido normal de infraestructura, ubicaciones operativas geográficamente distinguibles.

La evidencia pública no permite a un lector enumerar ocho de esas ubicaciones. No aparece ninguna lista de ocho ciudades junto con la afirmación. La página no identifica los propietarios de las instalaciones, socios de coubicación, alimentaciones de servicios públicos, conteos de racks, envolventes de energía, certificaciones, fechas de puesta en servicio o puntos finales de estado regional. Un cliente puede obtener más detalles después de crear una cuenta, y los contratos privados pueden contenerlos.

Sin embargo, la afirmación pública no puede tratarse como prueba de que existen ocho instalaciones independientemente operables, de que todas aceptan implementaciones o de que una carga de trabajo puede conmutar por error entre ellas.

Lo que se puede evidenciar es una huella más pequeña con señales operativas reales. Laentrada de directorio de BTWidentifica a la empresa que es el sujeto de este perfil. Los registros de APNIC asocian a esa empresa con un sistema autónomo y una asignación IPv4 portátil. El sitio web de la empresa y los contactos de registro apuntan a Sadashiv Nagar en Belagavi, Karnataka. Material local independiente describe servidores, racks, refrigeración y energía de respaldo allí. En el momento de la observación, los nombres de dominio web y de control de clientes de la empresa también se resolvían a direcciones dentro de ese bloque IPv4 asignado. La observación de DNS establece solo una asociación de direcciones; la evidencia física y de enrutamiento, consideradas por separado, respaldan una operación local real. Ninguna de ellas respalda un mapa de ocho sitios.

Esa distinción no es pedantería. Un cliente que elige un proveedor regional puede valorar razonablemente el soporte local, la residencia de datos en India y el acceso de menor latencia desde Karnataka. Esos beneficios pueden ser sustanciales incluso si la plataforma está concentrada en una sola ciudad. El riesgo aparece cuando una plataforma local compacta se vende utilizando un lenguaje que los lectores pueden interpretar como geografía de hiperescala. La evaluación correcta no es "no hay infraestructura" ni "ocho regiones están probadas".

Es que la huella de Belagavi está respaldada, mientras que la geografía más allá sigue siendo desconocida en la evidencia pública.

La empresa, la marca anterior y el operador de red no son intercambiables

OUTOFBOX CLOUD PRIVATE LIMITED es una empresa privada india. Un registro de empresa actual derivado de MCA publicado porIndiaFilingsproporciona el número de identificación corporativa U72900KA2021PTC149665, una fecha de incorporación del 19 de julio de 2021, un estado de presentación activo a partir de su actualización de noviembre de 2025 y la oficina registrada en Fourth Floor, Oneness, Sadashiv Nagar, Belagavi. Enumera a Ajit Kumar S Patil y Gowdesh Singangouda Patil como directores. Debido a que esa página republica información del registro en lugar de servir como el registro en sí, el estado de presentación actual preciso debe confirmarse con los datos maestros del Ministerio de Asuntos Corporativos antes de un contrato material.

La marca Outofbox Cloud es anterior a esa empresa. Uninforme local de febrero de 2020describió a OutofBox.cloud como un servicio lanzado desde Belagavi y lo llamó una subsidiaria de propiedad total de FAAST Networks. Dijo que el servicio se ejecutaba en un entorno OpenStack personalizado, tenía más de 100 servidores en ese momento y podía albergar cerca de 300 servidores físicos. El informe también describió el sitio como el primer centro de datos de la marca. Esas declaraciones se refieren a una operación de 2020 y una relación de marca antes de que se incorporara OUTOFBOX CLOUD PRIVATE LIMITED en julio de 2021. Son historia útil, no un certificado de propiedad actual.

Una segunda entidad legal es importante para la historia de la red. APNIC registra AS141815 a nombre deOutofbox Networks Private Limited, mientras que AS147192 pertenece a Outofbox Cloud. Los registros utilizan la misma dirección de Sadashiv Nagar y el mismo número de teléfono, pero diferentes dominios de correo electrónico de contacto de red. Las fuentes de datos corporativos indican directores superpuestos, y el informe de 2020 describe una relación de grupo. Aun así, dos empresas privadas limitadas son dos personas jurídicas. La autorización de telecomunicaciones, contratos, circuitos y espacio de direcciones de la empresa de red no pueden registrarse automáticamente como activos u obligaciones de la empresa de nube.

Esa frontera se vuelve especialmente importante en una falla o una salida. Si un cliente compra cómputo de Outofbox Cloud pero el primer camino de red visible es proporcionado por Outofbox Networks, el cliente necesita saber qué empresa firma el acuerdo de servicio, cuál posee o alquila los servidores, cuál mantiene el arrendamiento de la instalación, cuál factura el ancho de banda, cuál emplea al personal de operaciones de red y qué entidad es responsable de la restauración. Directores, marca, dirección o número de teléfono compartidos pueden facilitar la coordinación. No reemplazan los derechos contractuales.

El sitio web público actual a veces difumina las capas de producto e infraestructura. Anuncia nube pública, nube privada virtual, nube privada, balanceo de carga, Kubernetes gestionado, servicios de plataforma, alojamiento orientado a SAP, una nube comunitaria bancaria, servidores dedicados y coubicación. Algunos pueden entregarse directamente; otros pueden depender de infraestructura o proveedores afiliados. Las páginas públicas no publican una matriz de propiedad por servicio.

Por lo tanto, este perfil atribuye los productos al marketing de la empresa y los recursos numéricos a sus titulares registrados, sin asumir que cada capa es propiedad de la misma entidad.

Qué se evidencia físicamente en Belagavi

La evidencia física reciente más sólida no es un mapa de marketing. Es un relato de septiembre de 2025 del Departamento de Inteligencia Artificial y Ciencia de Datos del Angadi Institute of Technology and Management. Elregistro de actividadesdel departamento dice que los estudiantes visitaron Outofbox Cloud Private Limited en Sadashiv Nagar, Belagavi, el 22 de septiembre. Describe la gestión de máquinas virtuales, nubes privadas virtuales y cortafuegos, y luego identifica servidores físicos y virtuales, racks de servidores, refrigeración, energía de respaldo, enrutadores, conmutadores, cortafuegos y sistemas de almacenamiento en la configuración del centro de datos. El departamento también publicó el relato en suboletín 2025-26.

Esta es una corroboración significativa. Indica que el equipo asociado con la empresa era físicamente visible en la localidad nombrada menos de un año antes de este artículo. Es más útil para la ubicación que una base de datos de geolocalización IP, porque una visita institucional se refiere a un lugar real en lugar de una inferencia de latencia de red o datos de registro. LaAsociación de Empresas de Tecnología de Belagavitambién describe a Outofbox Cloud como alojado localmente y con sede en India, aunque ese perfil de la asociación es promocional y no revela su método de verificación.

La evidencia aún tiene limitaciones. El relato universitario no indica la sala exacta del edificio, el área del piso, la cantidad de racks, la densidad de racks, el servicio público, la topología UPS, la autonomía de la batería, la clasificación del generador, la resistencia del combustible, el deber de enfriamiento, la protección contra incendios, la aprobación de ocupación o el operador de la instalación. No dice si los sistemas vistos llevaban cargas de trabajo de producción de clientes, servían como laboratorio de formación o mezclaban ambas funciones. No identifica etiquetas de propiedad en los equipos.

La dirección compartida aparece en los registros de la empresa y de recursos numéricos como un contacto administrativo; una dirección administrativa no es, por sí misma, un certificado de instalación.

El artículo de 2020 proporciona cifras pero no el estado actual. "Más de 100 servidores" es una afirmación de equipo instalado en un momento dado. "Cerca de 300 servidores físicos" es una afirmación de diseño o capacidad de espacio. No indica cuántas unidades de rack, tomas de corriente o kilovatios estaban energizados en ese entonces. No puede mostrar cuántos servidores permanecen en servicio en 2026, cuántos están listos para clientes, qué proporción está reservada, o si el crecimiento posterior trasladó cargas de trabajo a otro lugar.

La frase "máquinas virtuales prácticamente ilimitadas" en ese informe debe entenderse como lenguaje promocional: cada máquina virtual consume capacidad finita de CPU, memoria, almacenamiento, red, energía y refrigeración.

Ningún registro público localizado para este perfil identifica una segunda instalación de Outofbox Cloud con evidencia física comparable. No se encontró ninguna sanción pública de energía, capacidad de conexión de servicios públicos, aprobación de generador, certificado de no objeción contra incendios, permiso de centro de datos a nivel de edificio o presentación ambiental que pudiera vincularse de manera segura con el piso de producción de la empresa de nube. La ausencia en una búsqueda pública no es prueba de que un documento o aprobación no exista.

Significa que un lector no puede utilizar uno para cuantificar el sitio o probar la afirmación de ocho regiones.

Por lo tanto, el mapa debe dibujarse de manera conservadora. Belagavi es una localidad operativa respaldada y una ubicación de contacto registrada. Mumbai es una ubicación de intercambio lógica respaldada para AS141815 en NIXI, no una prueba de que Outofbox Cloud posea servidores en Mumbai. Las etiquetas de Bengaluru y Chennai devueltas por herramientas comerciales de localización IP son estimaciones de medición, no direcciones de instalaciones. Las regiones anunciadas restantes son desconocidas hasta que la empresa publique nombres de ciudades y la base legal u operativa de cada una.

Un catálogo de productos no es un inventario

Lapágina de preciosactual de Outofbox Cloud hace que el servicio sea económicamente tangible. Enumera configuraciones que van desde un plan pequeño de dos CPU, 2 GB de memoria y 100 GB NVMe a ₹630 por mes hasta combinaciones mucho mayores de cómputo y memoria. La página de Boxes describe instancias de propósito general, optimizadas para CPU, optimizadas para memoria y optimizadas para almacenamiento, y dice que algunos planes usan subprocesos dedicados. Estos detalles muestran lo que la empresa ofrece vender. No revelan la cantidad o generación de hosts físicos, la política de sobresuscripción, la replicación de almacenamiento, el inventario de piezas de repuesto o las reglas de colocación detrás de los planes.

La distinción entre un catálogo y la capacidad importa más durante un aumento o una falla. Un plan puede permanecer visible cuando ningún host adecuado tiene memoria libre. Un panel de control puede aceptar un pedido mientras el cumplimiento del hardware se retrasa. Una vCPU nominalmente dedicada puede estar aislada a nivel del planificador mientras aún comparte un zócalo, canales de memoria, controladores de almacenamiento, conmutadores de top-of-rack y alimentaciones de energía.

La capacidad NVMe puede ser local a un host, replicada entre hosts, respaldada por un clúster de almacenamiento o restaurada desde un servicio de copia de seguridad separado. La tabla de planes pública no resuelve esas posibilidades.

La página de inicio dice que la plataforma tiene más de 40 clientes y más de 500 implementaciones en la nube. Esos son contadores de primera parte sin fecha, definición o auditoría. Una "implementación" podría ser una máquina virtual activa, un lanzamiento de aplicación, una acción de aprovisionamiento histórico, un entorno de prueba o un proyecto de cliente. No puede convertirse en servidores instalados o capacidad vendida.

Tampoco las 512 direcciones IPv4 asignadas imponen una regla de una dirección por servidor: las direcciones pueden servir a hipervisores, máquinas virtuales, traducción de direcciones de red, balanceadores de carga, enrutadores, reservas o asignaciones de clientes.

El sitio web también anuncia balanceo de carga. Un balanceador de carga puede distribuir solicitudes entre múltiples servidores, pero no demuestra redundancia geográfica. Los servidores detrás de él pueden compartir un rack, un conmutador de top-of-rack, un UPS, un bucle de refrigeración, una entrada de edificio y un enrutador ascendente. Asimismo, una nube privada virtual proporciona aislamiento lógico, no una nube físicamente separada. Una oferta de nube privada puede ejecutarse en hardware dedicado dentro de una instalación compartida. Cada uno es útil, pero cada uno aborda una capa de falla diferente.

Para que la capacidad sea de grado de decisión, el proveedor necesitaría conectar los planes a un envolvente operativo: grupos de hosts disponibles por región, reglas de asignación de CPU y memoria, durabilidad del almacenamiento, compromisos de puerto de red, plazos de aprovisionamiento, reserva de mantenimiento y el punto en el que la capacidad "disponible" está realmente energizada y es implementable. Ninguno de esos valores es público. La conclusión segura es que se comercializan productos específicos y los puntos finales de servicio están activos, mientras que el inventario instalado y disponible sigue siendo desconocido.

La red pública es real, compacta y visible

La evidencia operativa actual más clara es AS147192. Elregistro de sistema autónomo de APNICnombra a OOBCLOUD-AS-IN y OUTOFBOX CLOUD PRIVATE LIMITED, marca el registro como activo y muestra una fecha de registro del 13 de octubre de 2021. Elregistro de direcciones de APNICasigna 103.174.148.0 a 103.174.149.255 como espacio IPv4 portátil a la empresa. Eso es un /23 que contiene 512 direcciones. El registro de recursos no tiene un bloque IPv6 correspondiente.

Laobservación de estado de enrutamientode RIPE NCC el 15 de julio de 2026 encontró un prefijo IPv4 originado, 512 direcciones, ningún prefijo IPv6 y un vecino observado. La ruta fue visible para 325 de 326 pares IPv4 en el Servicio de Información de Enrutamiento de RIPE, lo que es una fuerte evidencia de amplia visibilidad de ruta pública en ese momento. Es evidencia de alcanzabilidad, no de una huella operativa global. Elresultado de prefijos anunciadosmuestra 103.174.148.0/23 continuamente en la ventana de observación del 1 al 15 de julio.

La visibilidad tiene historia, no es un artefacto de un día. Elhistorial de enrutamientode RIPE muestra a AS147192 originando el /23 desde noviembre de 2021 hasta la ventana de consulta actual, sujeto a los umbrales de muestreo y visibilidad del sistema de recolección. Elresultado de validación de origen de rutafue válido, con una autorización de origen de ruta que permite a AS147192 originar el /23 y prefijos hasta /24. La validez de RPKI reduce una clase de error de origen; no proporciona tiempo de actividad, capacidad, diversidad de rutas o protección contra un error de operador autorizado.

En el momento de la observación, los registros A para el sitio web público de la empresa y el nombre de host de control del cliente apuntaban a direcciones dentro del /23 asignado a OUTOFBOX CLOUD PRIVATE LIMITED: el sitio principal a 103.174.148.253 y mycloud.outofbox.cloud a 103.174.148.14. Esto establece solo una asociación puntual entre esos nombres de dominio y ese rango asignado.

No establece quién poseía u operaba los servidores o aplicaciones que respondían, dónde estaban alojados físicamente, si alguna de las direcciones era anycast, si alguno de los nombres de host formaba parte de un plano de control de producción, o si alguno de los servicios compartía un dominio de falla con las cargas de trabajo de los clientes.

Elperfil de AS147192 en PeeringDBes informativo principalmente por lo que no documenta. La entrada auto-reportada describe un alcance de Asia-Pacífico, una banda de tráfico de 100-1000 Mbps y 512 direcciones IPv4. Enumera cero conexiones de intercambio público y cero instalaciones, y no se ha actualizado materialmente desde octubre de 2022. PeeringDB es voluntario; los campos en cero pueden indicar información no divulgada o desactualizada en lugar de ausencia física. Sin embargo, no pueden usarse para corroborar ocho regiones.

Por lo tanto, la red es tanto genuina como compacta. Tiene una ruta estable, autorización de origen válida y puntos finales de servicio activos. Sin embargo, toda la superficie de origen pública es un bloque IPv4 sin anuncio IPv6 visible y un vecino inmediato observado. La evidencia de ruta respalda el estado operativo más fuertemente que el sitio web por sí solo. También define una dependencia lógica estrecha que merece examen.

Un vecino inmediato, luego una red más amplia

Laobservación de vecinos de AS147192de RIPE identifica solo a AS141815 en el lado izquierdo de las rutas recolectadas. Un segundo informe basado en colectores alcanza la misma topología básica. Esto no demuestra que haya solo un circuito físico. Los enlaces privados, las sesiones de respaldo, las rutas ocultas por políticas y las conexiones con muy poca visibilidad del colector pueden no aparecer. Lo que demuestra es que la ruta pública disponible para los colectores examinados no mostró diversidad de primer salto independiente.

AS141815 está registrado a nombre de Outofbox Networks Private Limited. Lalista de autorizaciones de ISP de 2026del Departamento de Telecomunicaciones de India enumera a esa empresa, no a Outofbox Cloud Private Limited, con una autorización Categoría B para Karnataka y la misma dirección de Sadashiv Nagar. Esta es una distinción legal valiosa: la empresa de red tiene la autorización de ISP divulgada, mientras que la empresa de nube posee el ASN y el bloque de direcciones de nube visibles. El registro público no muestra el acuerdo entre empresas bajo el cual se suministran el tránsito o las instalaciones.

Más allá de ese primer vecino, AS141815 tiene más opciones de ruta. Elresultado actual de vecinosde RIPE muestra cuatro vecinos observados: AS45117, AS9730, AS137085 y el AS147192 de la empresa de nube. Su estado de enrutamiento muestra cuatro /24 IPv4 originados y ningún IPv6 visible. PeeringDB enumera unaconexión operativa de 1 Gbps en NIXI Mumbaipara AS141815. La existencia de múltiples adyacencias AS externas más allá de AS141815 puede mejorar la elección de ruta y la recuperación de una falla de enrutamiento ascendente.

Aún no demuestra redundancia física para la nube. Dos ASN ascendentes pueden llegar a través de fibras en un solo cable, una entrega de operador, una zanja de calle, una entrada de edificio o un enrutador. Un puerto de intercambio de Internet en Mumbai puede alcanzarse a través de un solo enlace de retorno desde Belagavi. El ASN de la nube puede conectarse al ASN de la red a través de un solo cross-connect o un solo dispositivo.

Ninguna fuente pública identifica proveedores de circuitos, ubicaciones de entrega, reflectores de ruta, pares de enrutadores de borde, entradas de fibra, rutas de conductos, conmutación de protección, tasas comprometidas o resultados de pruebas de conmutación por error.

La distinción entre diversidad lógica y física también se aplica a la geografía. NIXI Mumbai es un punto de intercambio donde AS141815 tiene un puerto; no es evidencia de que Outofbox Cloud opere cómputo o almacenamiento en Mumbai. Una ruta puede atravesar Mumbai mientras la carga de trabajo permanece en Belagavi. Por el contrario, un proveedor podría alquilar cómputo en otro lugar sin anunciarlo desde AS147192. Los mapas de red y las rutas AS muestran la alcanzabilidad de paquetes, no la propiedad del servidor.

Para un cliente, la pregunta útil no es simplemente "¿Cuántos upstreams?" Es: ¿qué falla elimina el acceso a esta carga de trabajo específica? Responder eso requiere un camino desde el host de la máquina virtual y el conmutador de top-of-rack a través del borde de la instalación, el punto de entrega de la red de nube, los circuitos de larga distancia y los proveedores ascendentes. El enrutamiento público revela el medio de esa cadena a nivel de AS. Los extremos de nivel de rack y de ingeniería civil siguen siendo desconocidos.

La capacidad histórica no puede promoverse a capacidad utilizable actual

La cifra de 2020 de más de 100 servidores es el único conteo de equipo instalado público localizado para este perfil. La cifra de "cerca de 300" del mismo informe describe cuántos servidores físicos podría albergar el primer centro de datos. Incluso si ambas fueran precisas cuando se publicaron, representan estados diferentes. El equipo instalado no es espacio de diseño. El equipo energizado no es necesariamente operativo. El equipo operativo no está necesariamente disponible para un nuevo cliente.

El equipo disponible puede ya estar reservado, o puede no satisfacer la combinación de CPU, memoria, almacenamiento y red de una carga de trabajo.

Ninguna fuente de 2026 indica el conteo actual de servidores. Ninguna fuente proporciona megavatios, kilovatios, conteo de racks, densidad de racks o asignación de servicios públicos. Ninguna fuente cuantifica módulos UPS, capacidad de generador, duración de batería, almacenamiento de diésel, redundancia de refrigeración, efectividad del uso de energía o supresión de incendios. Ninguna fuente identifica un diseño N, N+1, 2N o de redundancia distribuida.

La visita estudiantil de 2025 confirma que existían soluciones de refrigeración y energía de respaldo; no especifica su capacidad, condición de mantenimiento o capacidad para soportar una carga de producción completa durante una falla prolongada de servicios públicos.

La afirmación del sitio web de "ocho regiones de centros de datos" también carece de un denominador de capacidad. Una región podría significar una instalación completa operada por la empresa, un rack alquilado, capacidad alquilada de otra nube, un sitio periférico, una ubicación planificada o una etiqueta seleccionable en un panel de control. Esos arreglos crean diferentes obligaciones y modos de falla. Sin nombres de región y divulgaciones de operadores, la capacidad instalada no puede atribuirse a la empresa y la ubicación de los datos del cliente no puede establecerse.

El espacio de direcciones también es fácil de sobreinterpretar. Un /23 le da a la organización 512 direcciones IPv4, no 512 servidores. Un solo servidor puede alojar muchas máquinas virtuales con direcciones privadas detrás de unas pocas direcciones públicas. Un cliente puede recibir varias direcciones públicas. Algunas direcciones son consumidas por funciones de red, broadcast, puerta de enlace, gestión, reserva o antiabuso. El conteo de IPv4 es una entrada de límite superior útil para ciertos productos de direcciones públicas, pero no es un conteo de cómputo, almacenamiento, energía o clientes.

Las configuraciones anunciadas tampoco proporcionan señal de stock. Un plan de 32 núcleos mostrado en línea es una oferta, no una prueba de que un host coincidente esté libre. La empresa puede operar un planificador agrupado, aprovisionar manualmente, mantener hardware de repuesto o comprar capacidad de socios. Las páginas públicas no lo dicen. Los términos no publican un plazo de cumplimiento. Un comprador potencial debe solicitar una confirmación de capacidad fechada para la región y configuración seleccionadas, incluyendo si los recursos están instalados, energizados, probados e inmediatamente asignables.

Por lo tanto, la conclusión defendible de capacidad es estrecha. Capacidad histórica instalada: más de 100 servidores, reportada en 2020 y no auditada independientemente. Capacidad histórica de diseño: cerca de 300 servidores físicos en el primer sitio de Belagavi, reportada en 2020. Presencia física actual: racks, servidores, refrigeración y energía de respaldo observados en una visita educativa de 2025. Capacidad actual instalada, energizada, utilizable, vendida, reservada y de repuesto: desconocida.

Una insignia de 99.99 % necesita un reloj, alcance y remedio

La página de Boxes anuncia un SLA de disponibilidad del 99.99 %. Si se mide durante un año de 365 días sin exclusiones, el 0.01 % de inactividad equivale a aproximadamente 52.6 minutos. Si se mide mensualmente, son aproximadamente 4.4 minutos en un mes de 30 días. Los acuerdos de nivel de servicio reales definen el período de medición, el componente medido, lo que cuenta como no disponible, las exclusiones de mantenimiento, las responsabilidades del cliente, las ventanas de reclamo y los créditos de servicio.

Un porcentaje sin esos términos no puede decirle a un cliente qué remedio sigue a una falla de host, almacenamiento, red o plano de control.

LosTérminos y Condicionespúblicos de la empresa crean incertidumbre adicional. Dicen que la empresa se esfuerza por la disponibilidad y seguridad pero no garantiza una operación ininterrumpida o libre de errores, y niegan responsabilidad por la imposibilidad de usar los servicios. Una orden de servicio firmada por separado puede anular o complementar esos términos del sitio web. No se localizó ningún programa de SLA público, tabla de créditos o archivo de historial de estado para conciliar el porcentaje de marketing con la exención de responsabilidad.

El alcance es crucial. El tiempo de actividad de cómputo puede excluir el sistema operativo del cliente. El tiempo de actividad del host puede coexistir con una red inalcanzable. El tiempo de actividad de la red puede coexistir con corrupción de almacenamiento. Un SLA regional puede excluir una falla multirregional simultánea, mientras que una máquina virtual implementada en una sola región no tiene recuperación geográfica. El éxito de la copia de seguridad no es el éxito de la restauración. La disponibilidad del soporte no garantiza un tiempo de restauración.

Para Outofbox Cloud, la pregunta del SLA está directamente vinculada a la evidencia de red e instalación. ¿Se aplica el 99.99 % a cada Box individual, al grupo de hipervisores, al primer salto de red, al panel de control, al almacenamiento o a todos? ¿Se mide desde sondas externas? ¿Son las ocho regiones alcances de SLA separados? ¿Cuenta una falla de AS141815? ¿Cuenta el mantenimiento planificado en la instalación de Belagavi? ¿Qué crédito está disponible, y es el único remedio del cliente un crédito?

Hasta que un contrato responda esas preguntas, la insignia es una afirmación de marketing en lugar de una garantía de recuperación cuantificada.

Cómo puede fallar el servicio

La primera ruta de falla es la energía de la instalación. Una interrupción de servicios públicos debería transferir la carga crítica al UPS y luego a la generación u otro suministro. La visita de 2025 respalda la presencia de energía de respaldo, pero ninguna fuente pública indica autonomía o redundancia. Un generador puede no arrancar, quedarse sin combustible, sobrecalentarse o soportar solo parte de la carga. Las baterías pueden degradarse. El equipo de conmutación puede crear un punto único de falla.

Si el sitio tiene una sola alimentación de servicios públicos o una sola ruta de distribución, múltiples dispositivos pueden apagarse juntos incluso cuando los servidores individuales tienen fuentes de alimentación duales.

La segunda ruta es la refrigeración. Los servidores pueden mantener energía eléctrica mientras los límites térmicos fuerzan apagados o estrangulamiento. Una instalación compacta necesita suficiente refrigeración para la densidad real de racks, no meramente el área nominal de la sala. Las unidades de aire acondicionado redundantes aún pueden compartir controles, condensadores, bombas o energía. La visita educativa confirma equipo de refrigeración pero no el deber, la redundancia o el mantenimiento. Un cliente no puede inferir resistencia térmica de la presencia de una unidad de refrigeración.

La tercera ruta es el acceso a la red. El único vecino visible públicamente de AS147192 significa que la ruta de la nube llega a Internet observada a través de AS141815. Un segundo upstream más allá de AS141815 puede ayudar si falla una ruta de proveedor, pero no si falla el punto de entrega de la nube a la red, el enrutador de borde compartido, el enlace de retorno de Belagavi o la entrada del edificio. La autorización de origen de ruta protege la legitimidad del origen, no la disponibilidad. Una ruta válida aún puede ser retirada, filtrada o inalcanzable.

La cuarta ruta es el acceso de gestión, cuya arquitectura se desconoce. Los nombres de dominio del sitio web y del panel de control del cliente apuntaban al /23 asignado de la empresa durante la observación, pero ese hecho no identifica la propiedad del servidor o la aplicación, el alojamiento físico, un rol de plano de control de producción o la co-falla con cargas de trabajo de clientes. DNS, autenticación, facturación y soporte se convierten en dependencias de disponibilidad solo donde la arquitectura real las hace así.

Un cliente necesitaría una descripción de arquitectura y procedimientos fuera de banda probados; el registro público no proporciona ninguno.

La quinta ruta es el almacenamiento. Las páginas de precios anuncian cantidades NVMe y copias de seguridad semanales en algunos planes de tipo alojamiento web, pero no explican la replicación para Boxes. NVMe local puede ofrecer un rendimiento excelente mientras expone una máquina virtual a una falla a nivel de host a menos que los datos se repliquen en otro lugar. Un clúster de almacenamiento replicado puede sobrevivir a una falla de disco o nodo, pero no necesariamente a una interrupción del edificio o un error del operador.

Una copia de seguridad semanal limita la exposición del punto de recuperación solo si es exitosa, aislada, retenida y restaurable. El sitio no publica pruebas de restauración ni detalles de ubicación de copias de seguridad.

La sexta ruta es el stock de hardware. Un proveedor regional pequeño puede ofrecer soporte cercano y precios atractivos, pero el tiempo de reemplazo depende de discos de repuesto, fuentes de alimentación, memoria, tarjetas de red, conmutadores y hosts completos. La empresa no publica inventario de piezas ni soporte del fabricante. Un componente fallido puede reemplazarse en minutos si hay un repuesto en el sitio, o en días si debe obtenerse. La capacidad anunciada en una tabla de planes no establece stock de reparación.

La séptima ruta son las personas y la escalada. El sitio anuncia monitoreo y soporte 24/7, pero los términos públicos no definen objetivos de respuesta o restauración. Una cadena de escalada real necesita un incidente reconocido, un responsable técnico, una cadencia de comunicaciones y autoridad para mover una carga de trabajo o reemplazar equipo. Se desconocen el tamaño del equipo de guardia, la separación de operaciones de red, el modelo de control de acceso y el acceso a la instalación fuera del horario laboral.

Los testimonios de clientes en la página de inicio son señales de mercado útiles, pero son seleccionados por la empresa y no sustituyen estadísticas de incidentes.

La octava ruta es la falla de facturación o contrato. Una máquina virtual técnicamente saludable puede volverse no disponible si una cuenta se suspende, un pago se disputa, una queja por abuso se maneja incorrectamente o la entidad proveedora cambia los términos. Los términos del sitio web reservan una amplia discreción y limitan las garantías. Los clientes necesitan períodos de notificación, escalada de disputas, derechos de exportación de datos y un período de gracia definido. Los clientes regulados o críticos también necesitan claridad sobre los subcontratistas y qué entidad legal puede acceder a los datos.

La novena ruta es la migración. La capacidad de arrancar una máquina virtual rápidamente no es lo mismo que la capacidad de irse rápidamente. Las imágenes pueden depender de redes propietarias, bases de datos gestionadas, almacenamiento de objetos, instantáneas o servicios de identidad. Los conjuntos de datos grandes toman tiempo y ancho de banda para exportar. El cobro por salida, los formatos de imagen, la compatibilidad de API y la confirmación de eliminación no se describen públicamente. Sin una exportación probada, el cliente sigue dependiendo tanto de la plataforma como de su equipo de soporte durante un incidente.

La décima ruta es la geografía correlacionada. Si los servidores evidenciados, el plano de control, el punto de entrega de la nube a la red y el personal están concentrados en Sadashiv Nagar, un evento a escala de edificio podría afectarlos a todos. El sitio afirma ocho regiones, pero ninguna fuente pública permite a un cliente seleccionar dos instalaciones nombradas y verificar que tienen operadores separados, redes eléctricas, zonas de inundación, rutas de enlace de retorno y planos de control. La colocación de múltiples servidores dentro de una sala es una ingeniería de disponibilidad útil; no es recuperación ante desastres geográfica.

Estos son escenarios, no afirmaciones de que alguno haya ocurrido. Muestran por qué una ruta actual y un rack fotografiado son evidencia necesaria pero insuficiente para la resiliencia. La confiabilidad depende de cómo están conectadas las capas y de lo que el proveedor ha probado bajo falla.

El lenguaje bancario plantea un estándar de diligencia más alto

Outofbox Cloud anuncia una nube comunitaria bancaria y dice que su plataforma es adecuada para cargas de trabajo sensibles al cumplimiento. Ese lenguaje no demuestra que un banco use el servicio o que la plataforma haya pasado una auditoría particular. Hace que los detalles faltantes sean más consecuentes. Una institución financiera regulada no puede externalizar la responsabilidad simplemente comprando un servicio comercializado para bancos.

Lasdirectrices de 2023 del Banco de la Reserva de India sobre la externalización de servicios de TIincluyen explícitamente la computación en la nube y los servicios de centros de datos. Requieren que las entidades reguladas cubiertas realicen diligencia debida, mapeen las dependencias de la cadena de suministro, monitoreen los niveles de servicio, mantengan acuerdos de continuidad del negocio y recuperación ante desastres, preserven los derechos de auditoría y acceso, y planifiquen una salida. El apéndice de la nube aborda el ciclo de vida de los datos y el movimiento de los servicios alojados en la nube. Esos deberes recaen principalmente en el cliente regulado, pero un proveedor debe poder proporcionar la evidencia y los derechos contractuales que el cliente necesita.

Lasdirectrices de ciberseguridad de CERT-In de 2022imponen obligaciones operativas a los proveedores de servicios, centros de datos, proveedores de VPS y proveedores de nube. Incluyen sincronización de tiempo, informes en seis horas para incidentes especificados, un requisito de registro rotatorio de 180 días dentro de la India y retención de información de registro de clientes especificada durante cinco años después de la cancelación o retiro. Este perfil no localizó atestaciones públicas de cumplimiento de Outofbox Cloud. Esa ausencia no prueba incumplimiento; estos controles pueden ser internos. Un cliente debe preguntar cómo se implementan las obligaciones y cómo interactúan con los compromisos de privacidad, control de acceso y eliminación.

Lapágina de privacidadde la empresa no responde esas preguntas empresariales. Contiene texto genérico de WordPress "Texto sugerido" sobre comentarios, cookies, medios y perfiles de usuario. No identifica el nombre legal corporativo, las regiones de centros de datos, los subprocesadores, la telemetría del servicio en la nube, el cronograma de retención, el contacto de seguridad, el manejo de cargas de trabajo de clientes o las transferencias transfronterizas. Un acuerdo de procesamiento de datos firmado puede proporcionar esos detalles, pero la página pública no debe tratarse como una declaración de privacidad específica de la nube.

Para un banco u otro cliente crítico, la solicitud práctica es un paquete de evidencia: sitios y operadores nombrados; subcontratistas; reglas de ubicación y movimiento de datos; certificaciones de seguridad y alcance; resúmenes de pruebas de penetración y auditorías; historial de incidentes; pruebas de copia de seguridad y restauración; compromisos de tiempo de recuperación y punto de recuperación; topología de energía y red; controles de acceso del personal; gestión de claves; evidencia de eliminación; y un manual de salida.

La huella local compacta del proveedor podría ser una ventaja para la residencia y el soporte, pero solo si el cliente puede verificar dónde residen realmente los datos y las copias.

La localidad de datos está respaldada a nivel de país, no con resolución de ocho regiones

La evidencia asocia fuertemente a Outofbox Cloud con India. La empresa está registrada en Karnataka. APNIC marca sus recursos numéricos en India. Los informes físicos apuntan a Belagavi. La empresa de red asociada tiene una autorización de ISP de Karnataka. La ruta pública y los puntos finales de servicio están activos. Estos hechos respaldan una identidad operativa centrada en India.

No establecen la ubicación de cada carga de trabajo. Un país de registro de IP no es una coordenada de servidor. Un cliente puede ser colocado en hardware propiedad del proveedor, racks alquilados, capacidad de socios u otra nube. Las copias de seguridad pueden residir en otro lugar. Las ocho regiones anunciadas no tienen nombre. La palabra "global" en una página de producto puede describir el alcance de ventas o la alcanzabilidad de Internet en lugar de la geografía del centro de datos.

Esto importa para la soberanía de datos y la latencia. Un cliente que busca residencia en Karnataka debe obtener un contrato que nombre la ciudad y el límite de la instalación, no confiar en la dirección de la empresa. Un cliente que busca residencia en India debe identificar los datos primarios, réplicas, instantáneas, registros y acceso de soporte. Un cliente que busca recuperación geográfica debe identificar un segundo sitio y probar una restauración allí. La evidencia que establece una localidad no puede estirarse para ser evidencia de ocho.

Qué convertiría la afirmación en evidencia de infraestructura

Outofbox Cloud podría mejorar materialmente la evaluación pública sin divulgar detalles de ingeniería sensibles. Primero, podría publicar una lista de ocho regiones con ciudad, país, estado de lanzamiento, si la capacidad es operada por la empresa o por un socio, y qué servicios están disponibles en cada una. Una región marcada como planificada debe separarse de una que acepta cargas de trabajo de producción.

Segundo, podría publicar un programa de nivel de servicio. Ese documento debe definir el componente medido, el método de observación, las exclusiones de mantenimiento, el proceso de reclamo y los créditos. Una página de estado con incidentes históricos y componentes a nivel de región permitiría a los clientes comparar el porcentaje con el historial operativo. Una declaración de que los términos son reemplazados por un SLA firmado reconciliaría la exención de responsabilidad actual.

Tercero, podría proporcionar un diseño de resiliencia de alto nivel para el sitio de Belagavi: número de alimentaciones de servicios públicos, clase de redundancia de UPS y generador, autonomía mínima de combustible, redundancia de refrigeración, protección contra incendios, envolvente de racks y energía, diseño de borde de red y la fecha de la última prueba de conmutación por error. No es necesario que las rutas exactas de los circuitos y los detalles sensibles a la seguridad sean públicos. Resúmenes fechados y asegurados independientemente serían suficientes para distinguir la capacidad instalada, energizada y utilizable.

Cuarto, podría aclarar el límite con Outofbox Networks Private Limited y FAAST Networks. Los clientes necesitan saber quién suministra el tránsito, quién tiene la autorización de telecomunicaciones, quién opera el equipo de borde, si el arreglo es una subcontratación afiliada y qué sucede si esa relación de suministro cambia. Los datos de ruta ya hacen visible la dependencia; la divulgación contractual la haría manejable.

Quinto, podría publicar detalles de portabilidad: exportaciones de imágenes admitidas, formatos de instantáneas, documentación de API, precio de salida, límites de ancho de banda, procedimientos de eliminación y restauración probada a otra región o proveedor. La portabilidad no es una característica secundaria para una nube pequeña. Es parte de la resiliencia porque le da al cliente una ruta de recuperación cuando el proveedor, la instalación o el contrato son el dominio de falla.

Finalmente, podría fechar sus afirmaciones de capacidad. Una declaración trimestral de hosts en servicio, grupos de recursos vendibles, capacidad reservada y repuesto de mantenimiento por región sería inusualmente transparente. Incluso una declaración menos granular, asegurada independientemente y claramente etiquetada, sería mejor que permitir que la cifra de diseño de 300 servidores de un informe de 2020 lleve una interpretación de 2026 que no puede respaldar.

La conclusión operativa

Outofbox Cloud no es meramente un nombre en un índice de empresas. Tiene un sistema autónomo visible desde hace tiempo, un origen IPv4 válidamente autorizado, nombres de dominio públicos que se mapearon dentro de su /23 asignado en el momento de la observación, y evidencia independiente reciente de equipo de nube físico en Belagavi. El caso operativo local es creíble, mientras que la asociación de DNS no identifica la propiedad del servidor ni la ubicación de alojamiento.

El caso de red pública también es claro: AS147192 origina un /23 y llega a Internet observada a través de un vecino AS inmediato, la entidad legalmente distinta pero estrechamente conectada Outofbox Networks Private Limited.

La afirmación de resiliencia más grande aún no está evidenciada. Ocho regiones de centros de datos se anuncian pero no se nombran. Un SLA del 99.99 % se muestra pero no se define públicamente. Un informe histórico proporciona un conteo instalado y un techo de diseño, pero la capacidad actual energizada y utilizable se desconoce. Se vieron racks, refrigeración y energía de respaldo, pero se desconoce su envolvente de ingeniería y tolerancia a fallas. Existe conectividad más amplia detrás de AS141815, pero se desconoce la diversidad física de rutas e instalaciones.

Eso deja una lectura práctica y justa. Outofbox Cloud puede evaluarse como un proveedor pequeño centrado en India con una huella respaldada en Belagavi y una red pública operativa. No debe evaluarse aún, a partir de evidencia pública, como una nube de ocho regiones con conmutación por error geográfica demostrada. Los clientes pueden cerrar esa brecha a través de contratos, evidencia de sitio y arquitectura, confirmación de capacidad, pruebas de restauración y un SLA real. Hasta entonces, el hecho de infraestructura más importante no es qué tan rápido puede lanzarse un Box.

Es cuántos lugares independientemente sobrevivibles pueden mantener ese Box funcionando cuando Belagavi, el primer salto de red o la empresa proveedora fallan.