Nube Pública
Cómo funciona
La infraestructura de nube pública es propiedad de un proveedor externo — AWS, Microsoft Azure, Google Cloud Platform (GCP), entre otros — y se comparte entre múltiples inquilinos. Se consumen recursos bajo demanda, se paga por uso, y el proveedor se encarga de la adquisición de hardware, la seguridad física y la gestión de la plataforma base.
Los principales proveedores operan regiones a nivel global. AWS dispone de regiones en España (eu-south-2), Fráncfort (eu-central-1) y París (eu-west-3). Azure opera en Spain Central, Germany West Central y France Central. GCP ofrece europe-southwest1 (Madrid) y europe-west1 (Bélgica). La selección de región es crítica para la latencia, la residencia de datos y el coste — no es una decisión secundaria.
Cuándo la nube pública es la elección correcta
- Cargas de trabajo variables o impredecibles: el autoescalado elimina la incertidumbre de la planificación de capacidad. Se paga por lo que se usa, no por lo que podría necesitarse.
- Startups y equipos de iteración rápida: cero CapEx inicial, aprovisionamiento instantáneo. Se lanza primero y se optimiza después.
- Aplicaciones stateless o cloud-native: microservicios contenedorizados, funciones serverless (AWS Lambda, Azure Functions, Cloud Run) y bases de datos gestionadas (RDS, Cloud SQL) están diseñados para las primitivas de la nube pública.
- Entornos de desarrollo y pruebas: se crean, se ejecutan las pruebas, se destruyen. Reservar capacidad no tiene sentido aquí.
Donde la nube pública se queda corta
- Restricciones de soberanía de datos: el artículo 44 del RGPD restringe las transferencias de datos personales fuera del EEE salvo que existan protecciones adecuadas. Utilizar la región europea de un proveedor con sede en EE. UU. es generalmente aceptable, pero las implicaciones de Schrems II y la evolución del Marco de Privacidad de Datos UE-EE. UU. exigen revisión jurídica, no solo la selección de región. En España, la AEPD supervisa activamente el cumplimiento de estas obligaciones. Además, el ENS (Esquema Nacional de Seguridad) impone requisitos específicos para los sistemas de información del sector público que condicionan la elección de proveedor y ubicación.
- Cargas de trabajo estables y de alta utilización: una VM ejecutándose al 80%+ de utilización 24/7 durante años es casi siempre más barata on-premises o en nube privada. Las Reserved Instances y Savings Plans (que normalmente ofrecen un 30–60% de ahorro sobre el precio bajo demanda, según la propia documentación de AWS) reducen la diferencia pero no la eliminan para cargas verdaderamente estáticas.
- Entornos altamente regulados: algunos reguladores financieros y organismos de defensa exigen aislamiento físico que la separación lógica de inquilinos en nube pública no satisface.
Servicios Gestionados en la Nube
Nube Privada
Cómo funciona
La nube privada dedica la infraestructura a una única organización. Puede ejecutarse on-premises en su propio centro de datos o estar alojada por un tercero (nube privada hospedada). La característica definitoria es la monoarrendamiento y el control directo sobre la pila de infraestructura.
Las nubes privadas modernas utilizan las mismas tecnologías de orquestación que los proveedores públicos. VMware Cloud Foundation, OpenStack, Nutanix y Azure Stack HCI proporcionan modelos de consumo tipo IaaS de manera interna. Las distribuciones de Kubernetes como Red Hat OpenShift o Rancher añaden orquestación de contenedores sobre esta base.
Cuándo tiene sentido la nube privada
- Regímenes de cumplimiento estrictos: las entidades financieras sujetas a normativas bancarias nacionales (p. ej., el Banco de España, la CNMV) en ocasiones se enfrentan a requisitos que exigen aislamiento físico verificable. Las organizaciones sanitarias que manejan datos de pacientes en el marco del RGPD y la normativa española de protección de datos sanitarios a menudo prefieren infraestructura privada para simplificar las cadenas de responsabilidad.
- Cómputo predecible y de alta densidad: las cargas de trabajo HPC, el procesamiento batch a gran escala o el entrenamiento de modelos ML en clústeres dedicados de GPU pueden ser más rentables sobre hardware propio cuando la utilización se mantiene alta.
- Dependencias de aplicaciones heredadas: cargas de trabajo vinculadas a mainframes o aplicaciones con dependencias de IP codificadas de forma rígida, protocolos no TCP/IP o licencias ligadas a núcleos físicos que a menudo no se pueden migrar a nube pública sin una reescritura completa.
Los costes reales que se subestiman
La nube privada no es «gratis porque ya tenemos los servidores». Los proyectos de Cloud FinOps de Opsio revelan de forma consistente costes ocultos: suministro eléctrico y refrigeración de instalaciones, ciclos de renovación de hardware (normalmente cada 3–5 años), personal para gestionar firmware, parches y seguridad física, además del coste de oportunidad de ingenieros realizando tareas indiferenciadas en lugar de desarrollar funcionalidades de producto.
El cálculo honesto: si su utilización media está por debajo del 60%, es probable que esté pagando de más por la nube privada. Si está de forma consistente por encima del 75%, probablemente esté ahorrando dinero en comparación con la nube pública a precio bajo demanda — aunque debe contabilizar el coste en agilidad derivado de los plazos de aprovisionamiento.
Nube Híbrida
Cómo funciona
La nube híbrida conecta infraestructura privada (on-premises o hospedada) con uno o más entornos de nube pública a través de orquestación, redes y, a menudo, capas de identidad compartidas. El factor diferencial respecto a simplemente usar ambas es la integración: las cargas de trabajo, los datos y los planos de gestión operan entre entornos de forma coordinada.
Las tecnologías habilitadoras clave incluyen:
| Tecnología | Propósito | Ejemplos |
|---|---|---|
| Conectividad híbrida | Enlaces de red privados entre on-prem y la nube | AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect |
| Cómputo híbrido | Ejecutar servicios cloud en instalaciones propias | AWS Outposts, Azure Arc, Google Anthos |
| Federación de identidades | Identidad única entre entornos | Azure AD (Entra ID), Okta, AWS IAM Identity Center |
| Orquestación de contenedores | Portabilidad de cargas de trabajo | Kubernetes (EKS, AKS, GKE) con manifiestos consistentes |
| Monitorización y observabilidad | Visibilidad unificada | Datadog, Dynatrace, Grafana Cloud |
Por qué la nube híbrida domina la adopción empresarial
Según el informe State of the Cloud de Flexera, la estrategia híbrida ha sido de forma consistente la dominante entre las grandes empresas durante varios años consecutivos. Las razones son prácticas, no teóricas:
1. La migración es gradual: ninguna empresa traslada todo a la nube pública de un solo paso. La arquitectura híbrida es la transición natural durante cualquier programa de Migración a la Nube.
2. Flexibilidad en la ubicación de cargas de trabajo: los datos sensibles permanecen en infraestructura privada mientras las aplicaciones orientadas al cliente escalan en nube pública. Una empresa española de comercio electrónico podría mantener los datos personales en un entorno privado en España mientras ejecuta su CDN y capa de cómputo en AWS eu-south-2 (España).
3. Capacidad de ráfaga (burst): se ejecuta la carga base on-premises y se escala a nube pública en los picos — tráfico del Black Friday, procesamiento batch de cierre de trimestre, demanda estacional.
4. Recuperación ante desastres y resiliencia: se utiliza la nube pública como destino de DR para las cargas on-premises. AWS Elastic Disaster Recovery, Azure Site Recovery y servicios similares hacen que esto sea operativamente viable.
Desafíos operativos de la nube híbrida
La nube híbrida no es «lo mejor de ambos mundos» sin esfuerzo. Desde las operaciones 24/7 del NOC de Opsio gestionando entornos híbridos, los puntos de fricción recurrentes son:
- Complejidad de red: las cargas sensibles a la latencia divididas entre entornos generan escenarios de depuración complejos. Si la base de datos está on-prem y la aplicación en nube pública, cada consulta atraviesa la interconexión. Esto debe medirse antes de diseñar la arquitectura.
- Postura de seguridad inconsistente: reglas de firewall on-prem, Security Groups en AWS, NSGs en Azure — tres lenguajes de políticas diferentes describiendo la misma intención. La desviación es inevitable sin Infrastructure as Code (Terraform, Pulumi) y validación continua de políticas (OPA, Checkov).
- Fragmentación de la monitorización: una alerta se dispara en CloudWatch, otra en la instancia on-prem de Zabbix y una tercera en Datadog. Sin una capa de observabilidad unificada, el equipo de SOC pierde tiempo correlacionando datos entre consolas en lugar de resolver incidentes.
Multi-Cloud
Multi-Cloud vs. Híbrida: una distinción necesaria
Estos términos se usan a menudo como sinónimos. No deberían serlo. Híbrida significa combinar infraestructura privada y pública. Multi-cloud significa utilizar dos o más proveedores de nube pública. Una organización que usa AWS y Azure es multi-cloud. Una organización que usa AWS y un clúster on-premises de VMware es híbrida. Una organización que hace ambas cosas es híbrida multi-cloud — y gestionarlo es el escenario operativamente más complejo en infraestructura cloud.
Multi-cloud deliberado vs. accidental
Esta distinción importa más que cualquier diagrama de arquitectura. La mayoría de los entornos multi-cloud son accidentales: el equipo de producto eligió AWS, el equipo de datos eligió GCP por BigQuery, y la empresa adquirió otra compañía que ejecutaba todo en Azure. Nadie lo planificó; simplemente ocurrió.
El multi-cloud deliberado tiene justificaciones específicas:
- Requisitos regulatorios: algunos reguladores financieros europeos exigen mitigación del riesgo de concentración — no depender de un único proveedor cloud para servicios críticos. El artículo 21 de la Directiva NIS2 exige «estrategias TIC multiproveedor» en ciertas interpretaciones para las entidades esenciales. En España, el ENS y las directrices del Banco de España refuerzan esta orientación para el sector público y financiero.
- Servicios best-of-breed: GCP BigQuery para analítica, AWS para cómputo general, Azure para la integración con Microsoft 365 y Active Directory. Esto es defendible cuando el coste de la red entre nubes y la sobrecarga operativa compensan la ventaja a nivel de servicio.
- Cobertura geográfica: ningún proveedor tiene regiones en todos los países. Una organización que necesita cómputo local en un país donde solo un proveedor tiene región será multi-cloud por necesidad.
El coste operativo del multi-cloud
Al ejecutar los servicios de DevOps Gestionado de Opsio en entornos multi-cloud, el coste operativo se hace evidente:
- Divergencia de IAM: AWS IAM, Azure Entra ID y GCP IAM utilizan modelos de permisos diferentes, mecanismos de cadena de confianza distintos y formatos de logs de auditoría dispares. Construir una capa unificada de gobernanza de acceso requiere una inversión significativa en herramientas.
- Fragmentación de visibilidad de costes: AWS Cost Explorer, Azure Cost Management y GCP Billing Export emiten datos en esquemas diferentes. Sin una plataforma de Cloud FinOps (Apptio Cloudability, Vantage o similar), no es posible responder a «¿cuánto cuesta ejecutar este producto?» a través de los distintos proveedores.
- Dilución de competencias: cada proveedor cloud tiene miles de servicios. La experiencia profunda en los tres es excepcional. Los equipos dispersos entre proveedores no dominan ninguno.
La recomendación honesta: no adopte multi-cloud como estrategia. Adóptelo solo cuando tenga una razón específica y defendible para cada proveedor adicional, y presupueste la sobrecarga operativa que genera.
Nube Comunitaria
La nube comunitaria — infraestructura compartida entre organizaciones con requisitos comunes — es el modelo menos mencionado pero sigue siendo relevante en sectores concretos. Los ejemplos incluyen nubes comunitarias gubernamentales (AWS GovCloud, Azure Government), comunidades de investigación (GÉANT en Europa, RedIRIS en España) y consorcios sectoriales que comparten infraestructura conforme a normativa.
En la práctica, la nube comunitaria es arquitectónicamente similar a una nube privada con arrendamiento compartido entre organizaciones verificadas. Su relevancia es acotada pero real: si es una administración pública española compartiendo infraestructura con otras administraciones a través del marco del ENS o las iniciativas de la SGAD (Secretaría General de Administración Digital), está utilizando nube comunitaria.
Comparativa de Modelos de Despliegue en la Nube
| Dimensión | Nube Pública | Nube Privada | Nube Híbrida | Multi-Cloud |
|---|---|---|---|---|
| Propiedad | Del proveedor, compartida | De la organización o hospedada | Mixta | Múltiples proveedores |
| CapEx | Ninguno (solo OpEx) | Alto (hardware, instalaciones) | Mixto | Ninguno por proveedor, alto en total |
| Escalabilidad | Casi ilimitada | Limitada por capacidad | Ráfaga hacia nube pública | Casi ilimitada por proveedor |
| Control | Limitado (APIs del proveedor) | Total | Dividido | Limitado por proveedor |
| Simplicidad de cumplimiento | Moderada (responsabilidad compartida) | Alta (usted controla la pila) | Compleja (múltiples ámbitos) | La más compleja |
| Complejidad operativa | Baja a moderada | Moderada a alta | Alta | La más alta |
| Ideal para | Cargas variables, startups | Regulación estricta, cargas estables | La mayoría de las empresas | Necesidades best-of-breed específicas |
| Riesgo de vendor lock-in | Alto (proveedor único) | Bajo (usted es propietario) | Moderado | Bajo (por diseño) |
Cómo elegir el modelo de despliegue en la nube adecuado
Elegir un modelo de despliegue es una decisión a nivel de carga de trabajo, no a nivel de organización. Diferentes aplicaciones dentro de la misma empresa legítimamente pertenecerán a modelos diferentes. Este es el marco de decisión que aplica Opsio:
Paso 1: Clasifique sus cargas de trabajo
Para cada carga de trabajo, evalúe:
- Sensibilidad de los datos: ¿procesa datos personales bajo el RGPD, datos financieros bajo regulaciones bancarias o datos de salud bajo la legislación sanitaria nacional? Bajo la Directiva NIS2, las entidades esenciales e importantes en 18 sectores deben implementar medidas de gestión de riesgos que pueden condicionar las opciones de despliegue. En España, el ENS establece categorías de seguridad (BÁSICA, MEDIA, ALTA) que inciden directamente en qué modelos de despliegue son admisibles para los sistemas del sector público.
- Perfil de rendimiento: ¿sensible a la latencia (necesita proximidad a usuarios u otros sistemas), intensivo en throughput (necesita alto ancho de banda) o intensivo en cómputo (necesita hardware específico como GPUs)?
- Variabilidad de la demanda: ¿estable, con picos estacionales o con ráfagas impredecibles?
- Dependencias de integración: ¿esta carga de trabajo depende de sistemas on-premises (bases de datos, mainframes, APIs heredadas)?
Paso 2: Mapee las restricciones
- Regulatorias: requisitos de residencia de datos del RGPD, ENS para el sector público español, directrices de la AEPD, reglas sectoriales específicas (PSD2 para pagos, MiFID II para negociación bursátil), y la transposición española de la Directiva NIS2.
- Financieras: disponibilidad de presupuesto de CapEx, hardware existente con vida útil remanente, acuerdos de gasto comprometido con proveedores.
- Organizativas: competencias del equipo, herramientas existentes, relaciones con proveedores.
Paso 3: Seleccione por carga de trabajo y luego agregue
Una vez que cada carga de trabajo tiene un modelo objetivo, el agregado determina su modelo organizativo. Si todas las cargas apuntan a la nube pública, su modelo es exclusivamente nube pública. Si las cargas se reparten entre privada y pública, es híbrido. Si abarcan múltiples proveedores públicos, es multi-cloud.
Paso 4: Reevalúe periódicamente
El despliegue en la nube no es una decisión que se configure y se olvide. Las características de las cargas de trabajo cambian. Los precios cambian. La regulación cambia. Opsio recomienda una revisión formal como mínimo anual, alineada con los ciclos de renovación de contratos y los calendarios de auditorías de cumplimiento.
Consideraciones de Cumplimiento Normativo: Unión Europea y España
Unión Europea y España
RGPD: el artículo 44 restringe las transferencias de datos personales fuera del EEE. Las decisiones sobre el modelo de despliegue deben garantizar que los controles de residencia de datos estén implementados a nivel arquitectónico, no solo como política. AWS, Azure y GCP ofrecen compromisos de residencia de datos en regiones de la UE, pero configuraciones como la replicación entre regiones, el caching en CDN y las herramientas de acceso de soporte pueden transferir datos inadvertidamente fuera de los límites previstos. En España, la AEPD ha emitido directrices específicas sobre transferencias internacionales que deben considerarse en el diseño de la arquitectura.
Directiva NIS2: aplicable desde octubre de 2024, NIS2 exige que las entidades esenciales e importantes implementen medidas técnicas y organizativas adecuadas para la gestión de riesgos de ciberseguridad. Esto incluye la seguridad de la cadena de suministro — su proveedor cloud forma parte de su cadena de suministro. Las decisiones sobre el modelo de despliegue deben documentar cómo cada modelo satisface los requisitos del artículo 21 de NIS2. España ha transpuesto esta directiva a su ordenamiento, y el CCN-CERT proporciona guías complementarias de aplicación.
ENS (Esquema Nacional de Seguridad): las administraciones públicas españolas y los proveedores que les prestan servicio deben cumplir el ENS (Real Decreto 311/2022). El ENS establece categorías de seguridad que afectan directamente a la elección de modelo de despliegue: los sistemas clasificados con categoría ALTA pueden requerir controles de aislamiento que solo son viables en nube privada o en proveedores de nube pública con certificación ENS de nivel alto.
Soberanía en la nube: la certificación BSI C5 en Alemania y la etiqueta SecNumCloud en Francia imponen requisitos adicionales a los proveedores cloud. En España, el esquema de certificación bajo el ENS y las guías del CCN (Centro Criptológico Nacional) cumplen una función análoga. Las organizaciones en estos mercados pueden necesitar proveedores con certificaciones nacionales específicas, lo que puede restringir las opciones de modelo de despliegue.
Lo que observa Opsio: patrones operativos en los distintos modelos de despliegue
Al operar SOC y NOC 24/7 en entornos de clientes que abarcan todos los modelos de despliegue, surgen de forma consistente varios patrones:
Los entornos híbridos generan el mayor número de incidentes por fallos en los límites de red. La interconexión entre on-premises y la nube pública (Direct Connect, ExpressRoute) es un punto único de fallo que los equipos monitorizan insuficientemente. Cuando se degrada, los síntomas se manifiestan como lentitud de aplicación en lugar de fallo de red, provocando una depuración misdireccional.
La atribución de costes en multi-cloud es el principal desafío de FinOps. Las organizaciones que ejecutan cargas de trabajo en dos o más proveedores tienen dificultades constantes para responder a preguntas básicas como «¿cuánto cuesta esta aplicación al mes?» sin herramientas dedicadas y una disciplina rigurosa de etiquetado.
Los entornos de nube privada son los que más rápido se desvían de los estándares de seguridad. Los proveedores de nube pública actualizan continuamente las configuraciones por defecto (cifrado en reposo por defecto, mínimos de TLS, bloqueo de acceso público). La infraestructura de nube privada conserva cualquier configuración que se estableció en el momento del despliegue salvo que se mantenga activamente.
Las organizaciones exclusivamente en nube pública son las más rápidas en adoptar nuevas capacidades, pero también las que acumulan más recursos sin utilizar. La facilidad de aprovisionamiento genera sprawl. El informe State of the Cloud de Flexera ha identificado de forma consistente el desperdicio en la nube como una de las principales preocupaciones, y los entornos puramente de nube pública son donde la práctica de FinOps de Opsio encuentra la mayor oportunidad de optimización.
Preguntas Frecuentes
¿Cuáles son los 4 modelos de despliegue en la nube?
Los cuatro modelos definidos por el NIST SP 800-145 son la nube pública (infraestructura compartida operada por un proveedor como AWS, Azure o GCP), la nube privada (infraestructura dedicada para una única organización), la nube híbrida (cargas de trabajo distribuidas entre entornos públicos y privados con orquestación entre ellos) y la nube comunitaria (infraestructura compartida entre organizaciones con requisitos comunes, como las administraciones públicas). Multi-cloud — el uso de múltiples proveedores públicos — se considera a menudo un quinto modelo en la práctica.
¿Cuál es el modelo de despliegue en la nube más utilizado?
La nube híbrida es el modelo más adoptado entre las grandes empresas. El informe State of the Cloud de Flexera ha constatado de forma consistente que la mayoría de las empresas persiguen una estrategia híbrida, combinando recursos on-premises o de nube privada con una o más nubes públicas. Los despliegues exclusivamente en nube pública son más habituales en startups y organizaciones de menor tamaño que carecen de infraestructura heredada que requiera integración on-premises.
¿Qué son IaaS, PaaS y SaaS y cómo se relacionan con los modelos de despliegue?
IaaS (Infrastructure as a Service), PaaS (Platform as a Service) y SaaS (Software as a Service) son modelos de servicio en la nube: describen la capa de abstracción y qué gestiona el proveedor frente a qué gestiona el cliente. Los modelos de despliegue describen dónde y cómo se aloja la infraestructura. Ambos conceptos son independientes: se puede ejecutar IaaS en una nube privada, consumir PaaS en una nube pública o utilizar SaaS entregado a través de una arquitectura híbrida. Elegir un modelo de despliegue no le vincula a un modelo de servicio específico.
¿AWS es una nube pública, privada o híbrida?
AWS es fundamentalmente un proveedor de nube pública, pero admite todos los modelos de despliegue. AWS Outposts lleva la infraestructura gestionada de AWS a su centro de datos on-premises para despliegues privados o híbridos. AWS GovCloud proporciona regiones aisladas para cargas de trabajo del gobierno de EE. UU. AWS Local Zones acercan el cómputo a los usuarios finales. La mayoría de las organizaciones utilizan AWS como componente de nube pública dentro de una estrategia más amplia, ya sea híbrida o multi-cloud.
¿La nube híbrida es más barata que la nube privada?
El coste depende enteramente del perfil de la carga de trabajo. La nube híbrida suele reducir costes en cargas variables porque se puede escalar hacia la nube pública en lugar de sobredimensionar la infraestructura privada para cubrir picos de demanda. Sin embargo, el modelo híbrido introduce costes de red (tarifas de interconexión, cargos por transferencia de datos), complejidad de integración y sobrecarga adicional de herramientas. Para cargas estables con una utilización consistentemente alta, la nube privada puede ser más rentable por unidad de cómputo. El enfoque riguroso: modele el TCO para sus cargas de trabajo específicas en ambos modelos antes de tomar una decisión.
