La nube híbrida consiste en repartir las cargas de trabajo de una empresa entre su propia infraestructura y una nube pública, y operar las dos mitades como una sola plataforma. Muchas pymes la eligen a propósito como diseño definitivo y la mantienen durante años. La pregunta útil es qué carga concreta gana en cada sitio. En este artículo repasamos qué conviene dejar en AWS, qué conviene mantener o traer de vuelta a tu sala de servidores y cómo se conectan las dos partes sin acabar pagando dos infraestructuras.
Qué es la nube híbrida
Una nube híbrida es un entorno en el que parte de los sistemas de la empresa se ejecutan en infraestructura propia (un CPD, una sala de servidores o una nube privada) y parte en una nube pública como AWS, con red, identidad y operación compartidas entre ambas. Lo que la distingue de tener «cosas sueltas en varios sitios» es precisamente eso último, que se administra como un único entorno y no como dos mundos con dos consolas, dos inventarios y dos criterios de seguridad.
Conviene separarla de dos términos que se confunden. La nube privada es infraestructura de uso exclusivo de la empresa, en su CPD o alojada, con la elasticidad y la automatización de la nube pero dentro de su perímetro. El modelo multinube es usar varios proveedores públicos a la vez. La híbrida combina público y privado, y en la práctica muchas pymes están en ese punto aunque no lo llamen así.
Qué conviene dejar en AWS
La nube pública gana claramente en las cargas que no son constantes ni predecibles, y en todo lo que preferimos no operar nosotros.
- La web pública, la tienda y las campañas. Tráfico que se multiplica un martes concreto y vuelve a caer. Dimensionar hierro propio para el pico significa pagarlo los otros 360 días.
- Entornos de prueba y preproducción efímeros. Levantar una copia del entorno para validar una versión y destruirla al terminar es donde el pago por uso rinde de verdad.
- Las copias fuera de sede y la recuperación ante desastres. Un almacenamiento de objetos con bloqueo (Object Lock) permite copias inmutables que nadie puede borrar hasta que expira la retención, ni siquiera con la cuenta de administrador. Es la pieza que hoy separa una copia de una copia que sobrevive a un ransomware.
- Servicios gestionados que no aportan nada operar en casa. Colas, distribución de contenido, DNS, envío masivo de correo transaccional o un almacén de datos para informes.
- Presencia en otras regiones. Si hay filiales o clientes fuera de España, poner un frontal cerca del usuario en la nube pública es cuestión de minutos.
Qué conviene traer a tu CPD
El movimiento inverso, el que casi nadie anticipa, aparece a los dos o tres años de haber migrado todo. Estas son las cargas que suelen volver.
- Sistemas estables que trabajan las 24 horas. Un ERP, una base de datos de producción o un servidor de ficheros con consumo plano no aprovechan la elasticidad, y en la nube se paga la elasticidad aunque no se use. Con máquinas encendidas todo el mes, un servidor propio bien amortizado suele costar bastante menos.
- Todo lo que genera mucho tráfico de salida. Lo que descuadra las facturas suele ser la salida de datos hacia internet, más que el cómputo. AWS incluye 100 GB gratis al mes de salida a internet agregados entre servicios y regiones, y a partir de ahí se paga por gigabyte. Si mueves vídeo, planos, copias o imágenes en volumen, ese concepto crece más rápido que ningún otro.
- Datos con requisitos de soberanía o contrato. Historiales clínicos, datos de menores, expedientes con cláusulas de residencia, propiedad industrial. Una nube privada resuelve la soberanía del dato sin renunciar a automatizar.
- Aplicaciones con licencias por núcleo o socket. Algunos fabricantes penalizan el despliegue en nube pública hasta hacerlo inviable frente al mismo software sobre hierro propio.
- Cargas atadas a la planta o al laboratorio. Un sistema que dialoga con maquinaria, control de accesos, cámaras o instrumentación necesita latencia baja y no puede depender de que la línea de fibra esté en pie.
Ese análisis, hecho carga por carga y con números, es exactamente el que planteamos en nuestra comparativa sobre nube o servidor propio.
Cómo se unen las dos mitades
Aquí es donde una híbrida bien montada se distingue de dos infraestructuras que casualmente pertenecen a la misma empresa. Hay cuatro piezas que tienen que ser únicas.
- La red. Un túnel VPN IPsec entre la oficina y la nube es el punto de partida razonable para la mayoría de pymes. Cuando el volumen o la latencia lo justifican se pasa a un enlace dedicado, que cuesta más pero da ancho de banda estable y salida de datos más barata.
- La identidad. Un solo directorio y un solo inicio de sesión para los dos lados, con doble factor. Dos sistemas de usuarios independientes es el origen de buena parte de los agujeros que encontramos en auditorías.
- Las copias y los objetivos de recuperación. El RTO (cuánto puedes estar parado) y el RPO (cuántos datos puedes perder) se fijan por servicio, no por ubicación, y la prueba de restauración periódica se hace en los dos entornos. De una copia que nunca se ha restaurado no se sabe si sirve.
- La monitorización y el endurecimiento. Un único panel con métricas, registros y alertas, monitorización con opción de guardia 24/7 para incidencias críticas, y el mismo criterio de hardening con referencia a los CIS Benchmarks en las máquinas de casa y en las de AWS.
A esas cuatro añadimos una quinta que no es técnica pero decide si el modelo sale a cuenta, la disciplina de costes. Practicar FinOps en una híbrida es tan simple como revisar cada mes qué se está pagando en la nube, apagar lo que no se usa y comprobar que las cargas siguen estando en el lado que les conviene. Sin eso, la factura solo sube.
Un escenario típico: el fabricante que volvió a medias
Una empresa industrial de unas noventa personas con planta propia migró todo a la nube pública en un proyecto de un año. El ERP, el sistema de planta, el servidor de ficheros con los planos y la web acabaron en el mismo proveedor. A los dieciocho meses la factura mensual se había duplicado respecto a la estimación inicial y nadie sabía explicar del todo por qué. Al desglosarla aparecieron dos causas dominantes, las máquinas del ERP y de la base de datos encendidas de forma permanente, y el tráfico de salida de los planos que las oficinas técnicas descargaban a diario.
La revisión se hizo por carga de trabajo. El ERP, la base de datos y el repositorio de planos volvieron a dos servidores propios en la sede, virtualizados y con alta disponibilidad. La web, el portal de clientes, los entornos de pruebas y las copias fuera de sede se quedaron en la nube, estas últimas con retención inmutable. Los dos lados quedaron unidos por un túnel VPN, con un solo directorio y un solo sistema de monitorización.
El ahorro fue solo una parte del resultado. Las oficinas técnicas dejaron de sufrir esperas al abrir ficheros grandes, el coste mensual de nube bajó a menos de la mitad, y la recuperación ante desastres quedó mejor que antes, porque ahora las copias están en un sitio distinto de donde corren los sistemas. Lo que no cambió fue el equipo, siguen siendo dos personas de sistemas, y esa es la razón por la que la operación se apoya en un servicio gestionado en lugar de en más contrataciones.
Errores habituales en un proyecto híbrido
El primero es híbrido por inercia, no por decisión. Se migró una parte, se paró el proyecto y lo que quedó a medias se llamó híbrido. Ahí no hay ventajas, hay dos infraestructuras que se pagan enteras y ningún criterio para saber qué va dónde.
El segundo es no medir antes de mover. Sin conocer el consumo real de cada sistema (CPU media, no pico; datos de salida al mes; horas de uso efectivo), la estimación de coste en la nube siempre sale optimista. Medir un mes completo antes de decidir cuesta poco y evita sorpresas caras.
El tercero es duplicar la operación. Dos herramientas de copias, dos formas de dar de alta a un usuario, dos maneras de parchear. Cada duplicidad multiplica el trabajo y crea huecos por los que se cuelan los incidentes. Si el equipo interno es pequeño, la híbrida solo funciona con procesos únicos y automatizados. Cuando el proyecto se plantea en etapas, con una carga cada vez y una revisión entre etapa y etapa, sale mucho mejor; lo detallamos en cómo migrar una empresa a la nube por fases.
Por dónde empezar
El punto de partida es un inventario por carga de trabajo, antes de elegir proveedor, contestando cuatro preguntas para cada una. Cuánto varía su consumo a lo largo del mes, cuántos datos saca hacia fuera, qué exigencias legales o contractuales tiene el dato que maneja, y cuánto tiempo puede estar parada. Con esas cuatro respuestas, la ubicación de cada sistema se decide casi sola, y el resultado casi nunca es todo en un lado.
Nosotros hacemos ese ejercicio con nuestros clientes antes de mover nada, y luego operamos lo que quede en cada lado, la parte pública dentro del servicio de Cloud y AWS y la parte propia como nube privada gestionada. Si tienes la sospecha de que estás pagando de más en un sitio o pasando apuros en el otro, cuéntanos tu caso y lo miramos con tus cargas reales en un diagnóstico sin compromiso.
Si aún estás decidiendo el reparto, aquí comparamos con números nube o servidor propio para tu empresa.