Cloud computing: qué es la computación en la nube y cómo funciona

Qué es el cloud computing, las cinco características del NIST, los modelos IaaS, PaaS y SaaS, la nube pública, privada e híbrida y las claves de coste y seguridad.

Ilustración de una nube central conectada a distintos dispositivos y servicios de almacenamiento y datos

El cloud computing o computación en la nube es el suministro de recursos informáticos —servidores, almacenamiento, redes, bases de datos y software— como servicio a través de Internet, con pago por uso y sin comprar ni mantener la infraestructura. El proveedor se encarga del hardware, del mantenimiento y de buena parte de la operación; el cliente decide qué consume y paga solo por lo que usa.

Detrás hay cinco características formales, tres modelos de servicio y varios modelos de despliegue, además de un reparto de responsabilidades que conviene entender antes de migrar nada. Los repasamos con la definición oficial del NIST y con ejemplos de AWS, Azure y Google Cloud.

Qué es el cloud computing según el NIST

La definición de referencia viene del NIST (National Institute of Standards and Technology). Su documento SP 800-145 (2011) lo describe como el acceso por demanda a un conjunto compartido de recursos configurables que se aprovisionan y liberan con un esfuerzo de gestión mínimo.

De ahí salen las cinco características esenciales que distinguen la nube de un hosting tradicional:

  • Autoservicio bajo demanda. El usuario aprovisiona recursos —una máquina, una base de datos— sin esperar semanas.
  • Acceso amplio a la red. Disponibles por Internet desde cualquier dispositivo, con mecanismos estándar.
  • Agrupación de recursos. El proveedor atiende a muchos clientes desde un fondo común y reasigna capacidad.
  • Elasticidad rápida. La capacidad crece o se reduce casi al instante, a menudo de forma automática.
  • Servicio medido. El uso se mide y se factura: se paga por consumo real.

Cómo funciona: del «todo en casa» al pago por uso

Antes de la nube, desplegar un servicio obligaba a comprar servidores, instalarlos en un centro de datos, contratar personal para mantenerlos y renovar el hardware cada pocos años. Todo eso es inversión de capital (capex), tanto si la carga se usa mucho como si no.

La nube convierte ese gasto en un coste operativo (opex): se alquila capacidad y se paga según el consumo. El proveedor asume discos, refrigeración y renovación del hardware; el cliente se centra en su aplicación. Escalar deja de ser una obra: si una base de datos necesita más capacidad, se cambia una opción y en minutos está lista.

El nombre «nube» es una metáfora antigua: desde los años sesenta se dibujaba una nube en los esquemas de red para representar lo que no importaba detallar. El término se popularizó a partir del año 2000 para describir servicios alojados en servidores remotos, un cambio que también forma parte de la historia de los sistemas operativos y su salto a los servicios en red.

IaaS, PaaS y SaaS: los tres modelos de servicio

Se diferencian por cuánto gestiona el proveedor y cuánto queda en manos del cliente. Cuanto más subimos hacia el SaaS, menos control y menos operación asumimos; cuanto más bajamos hacia el IaaS, más flexibilidad y más responsabilidad recuperamos.

IaaS PaaS SaaS
Qué ofrece Máquinas, almacenamiento y redes por demanda Entorno completo para desarrollar y ejecutar aplicaciones Aplicaciones listas para usar por Internet
Gestiona el proveedor Virtualización, hardware y red física Infraestructura, sistemas operativos, middleware y entorno de ejecución Toda la aplicación, incluidos datos y actualizaciones
Gestiona el cliente Sistema operativo, parches, software y aplicaciones Solo la aplicación y sus datos Uso y administración de usuarios
Nivel de control Alto Medio Bajo
Ejemplos Amazon EC2, Azure Virtual Machines, Compute Engine Azure App Service, AWS Elastic Beanstalk, Google App Engine Microsoft 365, Google Workspace, Salesforce

IaaS: infraestructura como servicio

IaaS entrega los componentes básicos: máquinas virtuales, almacenamiento, redes y direcciones IP. Es el modelo más cercano al centro de datos y el de más control: el cliente responde del sistema operativo, de los parches y del software que instala. La documentación de AWS lo describe como la base de los demás modelos.

PaaS: plataforma como servicio

PaaS añade una capa de abstracción: el proveedor gestiona la infraestructura, el sistema operativo, el middleware y el entorno de ejecución, y el cliente solo se ocupa de su aplicación y sus datos. Cómodo para desarrollar sin administrar servidores, a cambio de menos control; Google Cloud lo resume como centrarse en el código y no en la máquina.

SaaS: software como servicio

SaaS es el modelo que ya usamos sin darnos cuenta: aplicaciones completas por Internet donde el proveedor se encarga de todo —infraestructura, actualizaciones, disponibilidad— y el usuario solo se identifica y trabaja. El correo web, una suite ofimática o un CRM en la nube son ejemplos claros.

Modelos de despliegue: pública, privada, híbrida y comunitaria

El modelo de servicio dice qué se consume; el de despliegue, dónde y para quién. El NIST reconoce cuatro, más la multinube en la práctica.

Nube pública

La infraestructura es del proveedor y se comparte entre muchos clientes, aislados lógicamente entre sí. Es el modelo de AWS, Azure, Google Cloud, Oracle o IBM Cloud: cualquiera contrata capacidad en minutos. Ofrece la mayor elasticidad y el menor coste de entrada; a cambio, el control físico y buena parte de la configuración dependen del proveedor.

Nube privada

La infraestructura se dedica a una sola organización, en su propio centro de datos o gestionada por un tercero. Da más control, cumplimiento y previsibilidad, pero exige inversión y personal, y pierde parte de la elasticidad pública. Es habitual en banca, sanidad o administración pública por requisitos regulatorios.

Nube híbrida

Combina dos o más infraestructuras —por ejemplo, una privada y una pública— que, aun siendo entidades separadas, están unidas por tecnología que permite mover datos y aplicaciones entre ellas; el NIST la define por esa portabilidad. Es el modelo habitual cuando parte de la carga no puede salir de las instalaciones y otra sí aprovecha la elasticidad pública. Conectar ambos mundos exige redes y enlaces bien dimensionados.

Nube comunitaria

La comparten varias organizaciones con intereses comunes —misión, requisitos de seguridad o normativa— y se gestiona de forma conjunta. Es menos frecuente, pero el NIST la mantiene como cuarto modelo de despliegue.

Multinube

No es un modelo del NIST, sino una estrategia: usar servicios de varios proveedores a la vez por precio, por evitar depender de uno solo o por aprovechar una capacidad concreta de cada plataforma. La contrapartida es más complejidad de gestión, seguridad y facturación.

Quiénes son los grandes proveedores

El mercado lo lideran Amazon Web Services (AWS), Microsoft Azure y Google Cloud, seguidos de Oracle Cloud, IBM Cloud, Alibaba Cloud y Salesforce. Para el usuario, la diferencia clave no es el catálogo —cada vez más parecido— sino el ecosistema, los precios, las regiones y las certificaciones de cumplimiento. Los tres grandes publican marcos de buena arquitectura (AWS, Azure y Google) útiles para saber qué se espera de un diseño en la nube.

Servicios que se ofrecen en la nube

Además de máquinas virtuales, el catálogo incluye:

  • Almacenamiento de objetos y ficheros: un «disco duro» remoto casi ilimitado para copias, medios y datos.
  • Bases de datos gestionadas: relacionales (SQL Server, PostgreSQL, MySQL) y NoSQL (documentos, clave-valor), con copias y parches incluidos.
  • Análisis y lagos de datos: almacenar y consultar grandes volúmenes, estructurados o no.
  • Servicios de red: redes virtuales, pasarelas entre la red local y la nube, balanceadores y cortafuegos gestionados.
  • Cómputo sin servidor y contenedores: ejecutar código o aplicaciones empaquetadas sin administrar máquinas, o administrarlas por SSH cuando hace falta.
  • Inteligencia artificial, aprendizaje automático e IoT: modelos preentrenados, entrenamiento y gestión de dispositivos conectados.

Ventajas del cloud computing

La ventaja de fondo es que el esfuerzo se desplaza del mantenimiento al producto: TI deja de perder tiempo en comprar hardware o escalar servidores y lo dedica a las aplicaciones. En concreto:

  • Coste inicial bajo y pago por uso: no se compra infraestructura que quizá no se use.
  • Elasticidad: la capacidad se ajusta a la demanda, tanto al alza como a la baja.
  • Despliegue global: publicar un servicio en varias regiones sin abrir centros de datos.
  • Menos carga operativa: parches, réplicas y alta disponibilidad recaen en gran parte en el proveedor.
  • Servicios gestionados: bases de datos, colas, IA o monitorización se consumen sin construirlos desde cero.

Riesgos y limitaciones

La nube no es gratis ni infalible. Los riesgos más reales son:

  • Coste descontrolado. El pago por uso castiga el olvido: un recurso encendido sin usarse sigue facturando.
  • Dependencia del proveedor (vendor lock-in): cuantos más servicios propietarios, más caro es cambiar de plataforma.
  • Seguridad mal configurada. El proveedor protege la infraestructura, no los datos ni los permisos; la mayoría de incidentes nacen de errores de configuración.
  • Latencia y conectividad. Si la red falla o la región está lejos, la aplicación lo nota.
  • Cumplimiento y residencia de datos. Los datos pueden acabar en otro país, con implicaciones legales.
  • Pérdida de control sobre versiones y ventanas de mantenimiento impuestas por el proveedor.

Seguridad y cumplimiento en la nube

La idea clave es el modelo de responsabilidad compartida: el proveedor responde de la seguridad de la nube —instalaciones, hardware, hipervisor, red física— y el cliente, de la seguridad en la nube: datos, configuración, identidades y permisos. Microsoft lo detalla en su guía del modelo de responsabilidad compartida, y AWS y Google aplican la misma lógica.

Por eso la seguridad se juega sobre todo en la gestión de identidades y accesos. Aplicar el principio de mínimo privilegio y ordenar los permisos con control de acceso basado en roles (RBAC) evita que una sola cuenta comprometida llegue a todo; la autenticación multifactor, el cifrado y la segmentación de red cubren el resto.

En el plano normativo, en España el Esquema Nacional de Seguridad fija las categorías básica, media y alta para el sector público y sus proveedores, y el RGPD condiciona el tratamiento de datos personales y las transferencias internacionales, con la AEPD como autoridad de control. Las certificaciones ISO/IEC 27017 y ISO/IEC 27018 cubren, además, los controles específicos de servicios cloud y datos personales.

Costes y FinOps: pagar solo lo que se usa

El modelo de precios es flexible pero fácil de descontrolar: se paga por consumo —cómputo, almacenamiento, peticiones, transferencia de datos— y hay descuentos por reserva o uso comprometido. La diferencia entre una factura razonable y una sorpresa suele estar en la disciplina, no en el proveedor.

Para gestionarla nació FinOps, una práctica que combina tecnología, finanzas y negocio para decidir con datos. El marco de la FinOps Foundation resume el ciclo en tres fases: informar (visibilidad y etiquetado del gasto), optimizar (apagar lo ocioso, ajustar tamaños, elegir el mejor modelo de compra) y operar (presupuestos, alertas y responsabilidad por equipos).

Medidas que rinden de inmediato: etiquetar los recursos, revisar los ociosos, apagar los entornos de desarrollo fuera de horario, ajustar el tamaño de las máquinas y vigilar la transferencia de datos entre regiones, una partida que engaña mucho.

Errores comunes al adoptar la nube

  • Llevar los hábitos del centro de datos. Replicar la arquitectura antigua sin usar servicios gestionados ni elasticidad encarece y complica.
  • No poner el foco en la identidad. La frontera de seguridad ya no es la red, sino los permisos de cada cuenta y servicio.
  • Ignorar la factura. Sin etiquetado ni alertas, el gasto crece por olvido más que por necesidad.
  • Depender de un solo proveedor y de servicios propietarios, lo que dificulta cualquier salida futura.
  • Olvidar el cumplimiento. Elegir región y servicios sin revisar la normativa aplicable puede obligar a rehacer el diseño.
  • No medir. Sin métricas de uso y rendimiento no se sabe si el gasto está bien empleado.

Conclusión

El cloud computing llevó la informática del centro de datos al consumo por uso: cinco características esenciales, tres modelos de servicio —IaaS, PaaS y SaaS— y varios modelos de despliegue, con la multinube como estrategia creciente. Su promesa —agilidad y pago por consumo— se cumple, pero exige gestionar bien la seguridad, el cumplimiento y los costes.

Entender ese marco ayuda a decidir con criterio: qué se contrata como servicio, qué se queda en casa, quién responde de cada capa y cómo se controla la factura.

Preguntas frecuentes

¿Cloud computing y virtualización son lo mismo?

No. La virtualización es la tecnología que permite ejecutar varias máquinas sobre un mismo servidor físico; el cloud computing es el modelo de servicio que, apoyándose en ella, entrega recursos por demanda. Puede haber virtualización sin nube, pero sin virtualización o contenedores no se entiende la nube moderna.

¿Quién es responsable de la seguridad en la nube?

Ambos, según el modelo de responsabilidad compartida. El proveedor protege la infraestructura y la red física; el cliente protege sus datos, identidades, configuración y permisos. La mayoría de los incidentes ocurren en la parte del cliente.

¿Qué es el vendor lock-in y cómo se evita?

Es la dificultad de cambiar de proveedor cuando la aplicación depende de sus servicios propietarios. Se reduce usando estándares y portabilidad donde tenga sentido y manteniendo los datos exportables.

¿Es más barata la nube que un centro de datos propio?

Depende del uso. Para cargas variables o crecientes, el pago por uso suele salir más barato que sobredimensionar hardware; para cargas muy estables, un centro de datos propio bien aprovechado puede compensar. La comparación honesta incluye personal, energía y renovación del equipamiento.

Fuentes