Nube pública: cómo valorar costes, seguridad y dependencia

La nube pública permite contratar capacidad informática a través de internet sin comprar ni mantener en las propias instalaciones todos los servidores que se utilizan. Para una empresa, la decisión importante no es solo si quiere «estar en la nube», sino qué servicio trasladará, quién gestionará cada parte y cuánto costará operarlo de forma sostenida.

El término «pública» describe el modelo de prestación: un proveedor ofrece recursos a distintos clientes sobre una infraestructura compartida, con separación lógica entre ellos. No significa que los datos de una empresa sean públicos ni que cualquiera pueda consultarlos. La protección depende de los controles del proveedor y de cómo la organización configure identidades, permisos, redes, datos y aplicaciones.

Qué se contrata y qué sigue bajo control de la empresa

La nube pública abarca servicios distintos. En unos, la organización administra casi todo el sistema; en otros, el proveedor opera también una parte importante de la plataforma. Esa diferencia determina el trabajo técnico y las responsabilidades que permanecen dentro de la empresa.

• Infraestructura como servicio (IaaS): se alquilan recursos como máquinas virtuales, redes y almacenamiento. El proveedor gestiona la infraestructura física, mientras que el cliente suele administrar el sistema operativo, las aplicaciones, las cuentas y buena parte de su configuración.
• Plataforma como servicio (PaaS): el proveedor se ocupa de más componentes de ejecución, como parte del entorno de aplicación o de la base de datos. El equipo se centra en el código, los datos y los permisos que utiliza el servicio.
• Software como servicio (SaaS): se utiliza una aplicación ya operada por el proveedor. La empresa conserva tareas como gestionar usuarios, asignar permisos y decidir qué información introduce y comparte.

Estos nombres describen modelos generales, no una garantía de que dos productos distintos repartan el trabajo de idéntica manera. Antes de contratar, hay que consultar qué administra cada parte, qué opciones de configuración existen y qué controles se pueden auditar. Si se desea ampliar conceptos relacionados, la sección de Computación en la Nube reúne contenidos sobre esta área.

Cuándo aporta flexibilidad y cuándo no resuelve el problema

El pago por uso y la posibilidad de ajustar recursos facilitan responder a demandas variables sin comprar capacidad máxima para todo el año. También pueden acelerar la creación de entornos de desarrollo, pruebas o servicios nuevos. La ventaja es más clara cuando la carga cambia, el despliegue necesita rapidez o la organización no quiere operar directamente una parte de la infraestructura.

La flexibilidad, sin embargo, no convierte automáticamente una aplicación antigua en un servicio más eficiente. Si el programa necesita una configuración concreta, depende de sistemas locales o no puede tolerar cambios en su funcionamiento, migrarlo puede exigir adaptaciones, pruebas y conocimientos que no estaban en el presupuesto inicial. En algunos casos, mantenerlo donde está o mover solo una parte resulta más razonable.

Un ejemplo hipotético: una empresa con una web que recibe picos de actividad podría desplegar componentes que permitan ajustar recursos según la demanda. En cambio, si su sistema de gestión depende de una aplicación antigua y de equipos conectados a la red de la oficina, trasladarlo sin revisar esas dependencias puede añadir latencia y complejidad. El análisis debe empezar por el servicio y sus conexiones, no por una preferencia abstracta por la nube.

El precio de la capacidad no es el coste completo

Comparar el coste de un servidor local con el precio mensual de una máquina virtual no ofrece por sí solo una comparación justa. Hay que incluir almacenamiento, copias de seguridad, tráfico de red, licencias, soporte, observabilidad, administración y tiempo de migración. También cuenta el coste de mantener recursos encendidos o sobredimensionados cuando la carga real es menor.

En los servicios en la nube, el movimiento de datos y la comunicación entre componentes pueden influir en la factura. Por ejemplo, separar una aplicación y una base de datos en distintas zonas o servicios puede generar tráfico facturable según las condiciones del proveedor. Las tarifas concretas cambian entre servicios y ubicaciones, así que deben comprobarse en el cálculo del caso real, no suponerse.

Cómo hacer una estimación útil

1. Identificar la carga: anotar usuarios, horarios de actividad, volumen de datos, crecimiento esperado y necesidades de rendimiento.
2. Dibujar las dependencias: registrar qué sistemas se comunican, qué información intercambian y cuánto tráfico generan.
3. Separar costes fijos y variables: distinguir recursos permanentes de los que aumentan con el uso, y añadir copias, registros, soporte y licencias.
4. Probar distintos escenarios: estimar un periodo normal, uno de demanda alta y otro con recursos infrautilizados. Incluir el coste de salida o traslado de datos si se cambia de proveedor.
5. Asignar responsables: decidir quién revisa consumo, alertas y recursos sin uso; una factura solo es controlable si alguien puede relacionar sus conceptos con servicios y equipos.

Una prueba pequeña sirve para observar consumo y funcionamiento, pero no representa necesariamente el coste de producción. La carga real, la redundancia, la retención de datos y el nivel de soporte pueden cambiar de forma sustancial la estimación.

Seguridad: separar lo que protege el proveedor de lo que configura el cliente

El proveedor protege y mantiene los componentes que forman parte del servicio que ofrece, de acuerdo con las responsabilidades de ese servicio. La empresa, por su parte, debe controlar quién accede, qué permisos tiene cada cuenta, cómo se protegen las credenciales y qué datos se guardan. En IaaS, por ejemplo, el cliente suele asumir más tareas sobre sistemas operativos y aplicaciones que cuando utiliza una solución SaaS.

Un error de permisos puede exponer información aunque la infraestructura física esté correctamente protegida. Por eso, antes de migrar conviene identificar los datos sensibles, limitar privilegios, activar mecanismos de autenticación adecuados y revisar las configuraciones de almacenamiento y red. Las copias de seguridad también requieren una decisión explícita: tener datos en la nube no equivale a disponer de una copia independiente y recuperable.

La organización debe comprobar además qué opciones existen para registrar accesos y cambios, recuperar información y demostrar quién hizo cada operación. Si se almacenan datos personales, información contractual o registros sujetos a obligaciones específicas, la selección del servicio debe incluir la revisión de requisitos aplicables y de las condiciones de tratamiento. El país o la región del centro de datos, por sí solos, no explican todo el recorrido ni todos los accesos posibles a la información.

Continuidad y dependencia del proveedor

La alta disponibilidad no aparece por el mero hecho de contratar un servicio en la nube. Para resistir una interrupción, la aplicación debe estar diseñada y configurada para recuperarse: puede necesitar copias separadas, recursos redundantes, procedimientos de restauración y pruebas. También hay que fijar cuánto tiempo puede estar parada y cuántos datos se podrían perder, y comprobar si la solución satisface esos objetivos.

La dependencia tecnológica se vuelve relevante cuando una aplicación utiliza servicios propios de un proveedor o almacena datos en formatos difíciles de trasladar. Cambiar de plataforma puede requerir adaptar código, exportar información y volver a probar procesos. Evitar cualquier dependencia no siempre compensa: un servicio gestionado puede reducir carga operativa. Lo útil es conocer el coste y el trabajo de una salida posible antes de que sea urgente.

Una decisión práctica antes de migrar

Para cada sistema candidato, conviene preparar una ficha breve con su función, usuarios, dependencias, sensibilidad de los datos, necesidades de disponibilidad, coste actual y responsable técnico. Después, se compara la situación actual con una propuesta concreta: qué servicio se contrataría, quién operaría cada componente, cómo se recuperaría ante un fallo y qué presupuesto cubriría el uso ordinario y los picos.

La decisión puede ser distinta para cada carga. Una empresa puede trasladar primero un entorno de pruebas, mantener una aplicación heredada en sus instalaciones y utilizar software SaaS para otra función. La nube pública es una opción de prestación, no una estrategia completa por sí sola. Su conveniencia se comprueba al relacionar requisitos, responsabilidades, costes y posibilidad de recuperación con el servicio específico que se quiere operar.