El cloud computing dejó de ser una opción para convertirse en la capa de infraestructura por defecto de cualquier organización que necesite escalar sin inmovilizar capital en hardware. La definición de referencia sigue siendo la del NIST (publicación especial 800-145): un modelo que ofrece acceso bajo demanda, a través de la red, a un conjunto compartido de recursos de cómputo configurables (servidores, almacenamiento, redes, aplicaciones) que se aprovisionan y liberan con mínima intervención del proveedor. Las tres grandes nubes públicas (Amazon Web Services, Microsoft Azure y Google Cloud Platform) concentran la mayor parte del mercado mundial, pero elegir entre ellas (o combinarlas) exige entender qué resuelve cada capa de servicio y dónde están los riesgos reales.
Modelos de servicio: IaaS, PaaS y SaaS
La taxonomía clásica del NIST distingue tres modelos según quién gestiona qué. En IaaS (infraestructura como servicio) el proveedor entrega cómputo, red y almacenamiento virtualizado, y el cliente gestiona el sistema operativo hacia arriba: máquinas EC2 en AWS, Virtual Machines en Azure o Compute Engine en GCP. En PaaS (plataforma como servicio) el proveedor abstrae también el sistema operativo y el runtime: AWS Elastic Beanstalk, Azure App Service o Google App Engine permiten desplegar código sin administrar la máquina. En SaaS (software como servicio) se consume la aplicación completa por suscripción, como Microsoft 365 o Google Workspace.
La elección del modelo determina la frontera del modelo de responsabilidad compartida, un concepto que las tres nubes documentan explícitamente y que es la fuente número uno de incidentes de seguridad: el proveedor responde de la seguridad de la nube (hipervisor, hardware, red física), pero el cliente responde de la seguridad en la nube (configuración de IAM, cifrado de datos, parcheo del SO en IaaS, reglas de firewall). Asumir que el proveedor protege lo que en realidad es responsabilidad del cliente es el origen de la mayoría de fugas de datos en buckets S3 o blobs de Azure mal configurados.
Comparativa práctica: AWS vs Azure vs Google Cloud
Las tres plataformas cubren las mismas necesidades básicas, pero sus puntos fuertes difieren. Esta tabla resume las equivalencias de servicios y los criterios de selección más relevantes en proyectos reales.
| Servicio / Criterio | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| Cómputo virtual (IaaS) | EC2 | Virtual Machines | Compute Engine |
| Contenedores gestionados (Kubernetes) | EKS | AKS | GKE |
| Funciones serverless | Lambda | Functions | Cloud Functions / Cloud Run |
| Almacenamiento de objetos | S3 | Blob Storage | Cloud Storage |
| Base de datos relacional gestionada | RDS / Aurora | Azure SQL Database | Cloud SQL / AlloyDB |
| Punto fuerte habitual | Amplitud de catálogo y madurez | Integración con ecosistema Microsoft y entornos híbridos | Analítica de datos e IA (BigQuery, Vertex AI) |
En la práctica, una empresa con fuerte inversión en Active Directory y licencias Microsoft suele encontrar menos fricción en Azure; un equipo de datos que vive de analítica masiva tiende a valorar BigQuery de GCP; y AWS sigue siendo la apuesta segura por amplitud y disponibilidad regional. El precio rara vez es el factor decisivo: las tres aplican un modelo de pago por uso con descuentos por compromiso (Savings Plans en AWS, Reserved Instances en Azure, Committed Use Discounts en GCP) que pueden recortar la factura entre un 30% y un 70% frente a la tarifa bajo demanda.
Estrategias de migración: las 6 R
Migrar a la nube no es un acto único, sino una cartera de decisiones por aplicación. El marco de las 6 R (popularizado por Gartner y AWS) ordena las opciones: Rehosting (lift and shift, mover la máquina tal cual), Replatforming (pequeños ajustes, por ejemplo pasar una base de datos a un servicio gestionado), Repurchasing (sustituir por un SaaS equivalente), Refactoring (rediseñar la aplicación como cloud-native), Retain (mantener on-premise lo que no compensa mover) y Retire (apagar lo que ya no aporta valor). El error frecuente es hacer rehosting masivo esperando ahorros inmediatos: mover una arquitectura ineficiente a la nube suele encarecerla, porque se paga por recursos infrautilizados las 24 horas.
Una migración ordenada empieza por un inventario de dependencias, define una landing zone con cuentas/suscripciones segregadas por entorno (producción, preproducción, sandbox), establece políticas de etiquetado de costes desde el día uno y prioriza por valor de negocio y riesgo técnico. La gobernanza de gasto (FinOps) debe nacer con el proyecto, no añadirse cuando llega la primera factura sorpresa.
Infraestructura como código y arquitecturas cloud-native
La diferencia entre una nube barata y una cara no está en el proveedor, sino en la disciplina operativa. La infraestructura como código (IaC) con Terraform (multi-nube), AWS CloudFormation, Azure Bicep o Google Cloud Deployment Manager convierte la infraestructura en archivos versionados, revisables y reproducibles: se elimina la configuración manual irrepetible (el llamado snowflake server) y se habilita el despliegue idéntico de entornos. Sobre esa base se construyen las prácticas cloud-native: contenedores orquestados con Kubernetes, funciones serverless para cargas event-driven, y arquitecturas desacopladas mediante colas y eventos que escalan cada componente de forma independiente.
En materia de cumplimiento, las tres nubes mantienen certificaciones ISO/IEC 27001 (gestión de seguridad de la información) e ISO/IEC 27017 (controles específicos para servicios cloud), y ofrecen herramientas para tratar datos personales conforme al RGPD, incluyendo la elección de región europea para garantizar la residencia del dato y la firma de acuerdos de tratamiento. La certificación del proveedor, sin embargo, no exime al cliente de configurar correctamente sus propios controles.
FinOps: gobernar el coste como una disciplina
La elasticidad que hace atractiva a la nube es también su mayor trampa financiera: la facilidad para aprovisionar recursos convierte el gasto en una variable que se dispara sin control si nadie la vigila. La práctica FinOps (operaciones financieras en la nube) responde a este reto con un modelo cultural y operativo de tres fases iterativas. La fase de informar da visibilidad del gasto mediante etiquetado consistente de recursos y paneles de coste por equipo, proyecto y entorno. La fase de optimizar aplica acciones concretas: dimensionar correctamente las instancias (rightsizing), apagar entornos de prueba fuera del horario laboral, comprar capacidad reservada para cargas estables y aprovechar instancias spot para trabajos tolerantes a interrupciones. La fase de operar establece presupuestos, alertas de desviación y una responsabilidad clara sobre cada euro consumido.
El cambio de mentalidad clave es que en la nube el coste es una métrica de ingeniería, no solo de finanzas: la decisión de un desarrollador al elegir un tipo de instancia o una región tiene impacto directo en la factura. Las organizaciones maduras incorporan el coste como un atributo más de calidad del software, junto al rendimiento y la seguridad, y revisan el gasto con la misma cadencia con la que revisan los incidentes.
Errores comunes que encarecen y exponen la nube
- Recursos huérfanos: discos, IPs elásticas y snapshots que nadie libera y se facturan mes a mes.
- Sobredimensionar instancias: arrancar máquinas grandes "por si acaso" en lugar de medir y aplicar autoescalado.
- Permisos IAM demasiado amplios: conceder políticas con comodín (
*) en vez de aplicar el principio de mínimo privilegio. - No cifrar por defecto: dejar buckets de almacenamiento de objetos con acceso público o sin cifrado en reposo.
- Olvidar la recuperación ante desastres: no probar nunca la restauración de copias ni definir objetivos de RPO/RTO.
Preguntas frecuentes
¿Multi-cloud o un solo proveedor?
El multi-cloud reduce el riesgo de dependencia de un único proveedor y permite usar lo mejor de cada plataforma, pero multiplica la complejidad operativa, las competencias necesarias y los costes de transferencia de datos entre nubes. Para la mayoría de pymes, una nube principal bien gobernada rinde más que un multi-cloud mal mantenido.
¿La nube es siempre más barata que tener servidores propios?
No de forma automática. La nube convierte inversión (CapEx) en gasto operativo (OpEx) y aporta elasticidad, pero cargas estables y predecibles 24/7 pueden resultar más caras en la nube que reservando capacidad o manteniéndolas on-premise. El ahorro real surge de pagar solo por lo que se usa y de apagar lo que no se necesita.
¿Dónde residen mis datos y quién puede acceder a ellos?
Los datos residen en la región que elija el cliente; para cumplir el RGPD conviene seleccionar regiones de la UE y firmar el acuerdo de tratamiento del proveedor. El cifrado en reposo y en tránsito, junto con una gestión rigurosa de claves e identidades, es responsabilidad del cliente.
¿Qué es el vendor lock-in y cómo se mitiga?
Es la dificultad de cambiar de proveedor por usar servicios propietarios. Se mitiga apoyándose en estándares abiertos (contenedores, Kubernetes, formatos de datos portables) y aislando la lógica de negocio de las APIs específicas de cada nube, aunque renunciar del todo a servicios gestionados también tiene un coste de oportunidad.
Conclusión
No existe una nube "mejor" en abstracto: existe la nube adecuada para una carga de trabajo concreta, un equipo con unas competencias dadas y un marco de cumplimiento determinado. La decisión técnica relevante no es AWS contra Azure contra Google Cloud, sino cómo se gobierna la plataforma elegida: con infraestructura como código que haga reproducible cada entorno, con identidades de mínimo privilegio que cierren la puerta a las fugas, con una práctica FinOps que evite la factura sorpresa y con copias cuya restauración se prueba de verdad. La nube premia a quien automatiza y mide, y castiga a quien improvisa. En Summum Sistemas abordamos cada migración como una cartera de decisiones por aplicación (las 6 R), no como un traslado masivo, porque mover el desorden a la nube solo produce desorden más caro.