Post actualizado el día octubre 28, 2026 by DeiviSanzPlay
Por qué esta comparativa no empieza con una tabla de precios
He migrado cargas de trabajo entre proveedores cloud en cuatro proyectos distintos durante los últimos años: una tienda de comercio electrónico con picos estacionales, una API para una app de logística, un almacén de datos para un equipo de analistas y un sistema interno de gestión documental. En todos esos casos, la decisión no se tomó leyendo la calculadora de precios de cada proveedor, sino probando el comportamiento real de la infraestructura bajo condiciones parecidas a las de producción. La comparativa de servicios cloud que encontrarás aquí está construida desde esa experiencia, no desde los folletos comerciales.
La primera lección que aprendí es incómoda: el proveedor que gana en la comparativa teórica rara vez es el que mejor encaja en un proyecto concreto. Depende de dónde esté tu equipo, qué latencia toleran tus usuarios, cuánto peso tenga tu factura de egreso de datos y cuánta tolerancia tengas a la complejidad operativa. No hay un ganador absoluto, y desconfía de quien te diga lo contrario.
Lo que de verdad diferencia a AWS, Azure y Google Cloud en el día a día
Los tres hiperescaladores cubren lo esencial: máquinas virtuales, contenedores gestionados, bases de datos relacionales, almacenamiento de objetos, funciones serverless y redes privadas. Las diferencias aparecen en los detalles operativos que solo notas cuando llevas meses con la plataforma encendida.
AWS: madurez y un ecosistema enorme
En el proyecto de comercio electrónico usamos AWS porque necesitábamos autoescalado agresivo durante campañas y una CDN con presencia amplia. Lo que funcionó bien: la variedad de tipos de instancia y la documentación, que aunque abrumadora, casi siempre tiene respuesta a problemas poco comunes. Lo que no funcionó tan bien: la curva de aprendizaje de IAM. Un error de configuración de permisos nos bloqueó un despliegue durante horas y el mensaje de error no ayudaba demasiado. Si tu equipo es pequeño y no tiene a alguien dedicado a la nube, la superficie de configuración puede jugar en tu contra.
Azure: la puerta natural si vives en el ecosistema Microsoft
Para el sistema de gestión documental, la empresa ya usaba Active Directory y Office 365, así que Azure fue la opción lógica. La integración con la identidad corporativa y con las herramientas de ofimática ahorró mucho trabajo de integración. El punto débil que encontramos: la documentación a veces está fragmentada entre el portal clásico y el nuevo, y algunas funciones cambian de nombre con frecuencia. Para un equipo con perfil administrativo y poca experiencia en infraestructura, esto puede generar confusión. No lo recomendaría como primera nube para alguien que quiera aprender desde cero con ejemplos estables.
Google Cloud: datos y contenedores con buen sabor
El almacén de datos para analistas fue el caso donde Google Cloud brilló. BigQuery permitió consultar volúmenes que en un motor relacional tradicional habrían requerido una planificación mucho más cuidadosa. La integración con herramientas de BI fue sencilla y el modelo de facturación por consulta procesada resultó cómodo para un uso intermitente. La advertencia: si tu equipo viene de SQL clásico, la sintaxis y el modelo de particionado requieren adaptación. Y si haces consultas mal optimizadas de forma recurrente, la factura puede crecer sin que lo notes hasta el cierre de mes.
Proveedores alternativos: cuándo tienen sentido
No todo es hiperescalador. En la API de logística evaluamos DigitalOcean y Hetzner por coste y simplicidad. Para un servicio con tráfico moderado y un equipo de dos personas, un droplet o un servidor dedicado con Docker puede ser suficiente y mucho más barato que una arquitectura equivalente en AWS. La contrapartida es clara: menos servicios gestionados, menos regiones y menos herramientas de observabilidad integradas. Esto no funciona para empresas que necesitan cumplimiento normativo estricto en múltiples jurisdicciones o que dependen de servicios gestionados muy específicos.
Cloudflare también ha entrado en la conversación con sus funciones de cómputo en el borde. Para tareas de transformación ligera o autenticación cerca del usuario, puede evitar un salto de red. Pero no lo usaría como plataforma principal para una base de datos transaccional; su modelo está pensado para otra cosa.
El coste oculto que casi nadie mira al principio: la salida de datos
En la comparativa de servicios cloud, el precio por hora de cómputo es la métrica más visible y probablemente la menos determinante. Lo que realmente movió la aguja en nuestros proyectos fue el coste de transferencia de datos hacia fuera y entre zonas. En la tienda de comercio electrónico, servir imágenes y vídeos desde el almacenamiento de objetos sin una CDN delante habría disparado la factura. Colocar la CDN cambió el panorama.
También aprendimos a vigilar el tráfico entre servicios internos. Dos componentes que se hablan por la red pública dentro del mismo proveedor pueden generar cargos que se evitan usando la red privada. Es un detalle técnico, pero tiene impacto directo en la factura mensual. Si estás comparando proveedores, pide siempre una estimación de egreso basada en tu patrón de tráfico real, no en el promedio del sector.
Latencia y ubicación: la prueba que sí importa
Antes de decidir, hicimos una prueba sencilla en cada proyecto: desplegar una versión mínima del servicio en la región candidata y medir tiempos de respuesta desde las ubicaciones reales de los usuarios. En la API de logística, la diferencia entre una región y otra era perceptible para los operarios que usaban la app en campo. No fue una diferencia dramática, pero sí suficiente para elegir la región más cercana aunque el precio por hora fuera ligeramente superior.
La lección: la latencia no se negocia con descuentos. Si tu aplicación es interactiva y el usuario nota el retraso, la región adecuada es parte del producto. Si tu carga es por lotes y tolera minutos de espera, tienes más margen para optimizar coste.
Bases de datos gestionadas: cuándo pagar la prima
Mantener un motor de base de datos por tu cuenta implica copias de seguridad, actualizaciones de versión, réplica y monitorización. En un equipo sin especialista en bases de datos, una instancia gestionada puede justificar su sobrecoste solo por evitar una caída en fin de semana. En el proyecto de la tienda elegimos gestionado y dormimos mejor. En el de la API, con una carga más predecible y un equipo con experiencia, un servidor propio con copias automatizadas nos dio un control que agradecimos cuando necesitamos ajustar parámetros del motor.
Esto no funciona para todos: si tu equipo no tiene a nadie que sepa administrar un motor relacional, el ahorro se convierte en riesgo. Y si la carga crece de forma imprevisible, la instancia gestionada con autoescalado suele ser más segura que un servidor único.
Serverless: útil, pero no para todo
Las funciones serverless resolvieron bien tareas puntuales: procesar una imagen al subirla, enviar una notificación, validar un webhook. El modelo de pago por ejecución encaja con cargas intermitentes. El problema aparece con procesos largos o con estado. En un flujo de generación de informes que tardaba varios minutos, la función superaba los límites de tiempo y tuvimos que rediseñar la arquitectura hacia un contenedor. No es que serverless no funcione, es que no funciona para cargas que no encajan en su modelo de ejecución.
Otro punto a vigilar: el arranque en frío. Para una API con tráfico constante no se nota, pero para un servicio que recibe peticiones cada varios minutos, la primera respuesta puede ser más lenta. Si tu experiencia de usuario depende de esa primera impresión, conviene medirlo antes de comprometerse.
Cómo haría la comparativa si empezara hoy
Primero, definiría el perfil de carga: interactiva o por lotes, predecible o con picos. Segundo, listaría las dependencias del equipo: identidad corporativa, herramientas de datos, lenguajes y frameworks. Tercero, estimaría el coste total incluyendo egreso de datos y servicios gestionados, no solo cómputo. Cuarto, desplegaría una prueba real durante una o dos semanas en la región candidata. Y quinto, revisaría la documentación y el soporte en el idioma del equipo.
La comparativa de servicios cloud útil no es la que declara un ganador, sino la que te ayuda a descartar opciones con criterios concretos. En mi experiencia, el proveedor correcto es el que encaja con tu equipo, tu latencia y tu patrón de gasto, aunque en la tabla general no quede primero. Y si algo no encaja, cambiar de proveedor más adelante es posible, pero cuanto más acoplada esté tu arquitectura a servicios exclusivos, más caro será el movimiento. Diseñar con cierta portabilidad desde el principio es una inversión que agradecerás.
Transparencia sobre esta comparativa
Los proveedores y servicios mencionados son reales y las experiencias descritas corresponden a proyectos concretos, pero no incluyo cifras exactas de coste ni métricas de rendimiento porque varían según configuración, región y momento. Las fuentes que respaldan las características generales de cada plataforma son la documentación oficial de AWS, Microsoft Azure, Google Cloud, DigitalOcean, Hetzner y Cloudflare, además de guías de buenas prácticas publicadas por esas mismas organizaciones. No garantizo que los resultados se repitan en tu caso: la nube depende demasiado del contexto. Lo que sí puedo afirmar es que probar antes de comprometerse y mirar más allá del precio por hora evita sorpresas.
Perfiles verificables: Sitio web
Publicado el 28 de October de 2026. Última revisión: 28 de October de 2026.
