El problema
Cuando tengo que elegir entre Azure y AWS, ya no empiezo por el catálogo. Empiezo por cinco preguntas sobre el equipo y el negocio, y casi siempre la respuesta sale sola.
Comparar servicios uno a uno es el error habitual. Los dos proveedores tienen máquinas, contenedores, funciones, data lake e identidad. La diferencia está en cuánto le cuesta a tu equipo operar cada uno y en qué ya tienes montado.
No se elige el mejor cloud: se elige el que tu equipo puede operar bien con lo que ya tiene.
Las cinco preguntas
Antes de abrir ninguna tabla comparativa, respondo esto:
- Stack del equipo. ¿Qué conoce ya el equipo y qué herramientas usa a diario?
- Compliance. ¿Hay requisitos de seguridad, auditoría o residencia de datos que limiten opciones?
- Velocidad. ¿Cuánto tiempo hay hasta el primer resultado útil?
- Coste operativo. ¿Cuánta plataforma puede sostener el equipo sin quemarse?
- Riesgo. ¿Cuánta complejidad nueva se acepta, y quién la mantiene después?
Fíjate en que ninguna habla de precio por hora. El coste que más pesa a medio plazo es el de las personas que operan la plataforma.
Dos enfoques distintos
AWS destaca por granularidad y amplitud. Tiene muchas piezas pequeñas y un control fino de cada una. Encaja cuando la arquitectura es muy a medida y el equipo ya tiene madurez cloud.
Azure destaca por la integración con el stack Microsoft: Entra ID, Microsoft 365, SQL Server y Power Platform. Encaja cuando la organización ya vive ahí y lo que importa es adoptar rápido con poca fricción.
Ninguno de los dos enfoques es mejor. Uno premia al equipo que quiere afinar; el otro, a la organización que quiere reutilizar lo que ya tiene.
Equivalencias por dominio
Esta tabla es la misma que la del diagrama. Sirve para orientarse, no para decidir: los servicios se parecen, pero no son idénticos.
| Dominio | AWS | Azure |
|---|---|---|
| Compute | EC2 · ECS/EKS · Lambda | VM · AKS · Functions |
| Datos | S3 · Glue · Athena · Redshift | ADLS · Data Factory · Synapse |
| Identidad | IAM, muy granular | Entra ID, federado |
Compute
Máquinas, Kubernetes gestionado y funciones existen en los dos lados. AWS ofrece más variantes y combinaciones, como ECS para quien no quiere Kubernetes. Azure da una experiencia más integrada con las herramientas de Microsoft.
Si busco variedad de patrones y control, miro AWS. Si busco coherencia con lo que ya usa la organización, Azure llega antes.
Datos
AWS encaja muy bien en un modelo centrado en el lake: S3 como base y piezas que se combinan encima. Lo cuento en Arquitectura ETL de 3 capas en AWS con Glue y Athena.
Azure brilla cuando el destino es el BI corporativo y un gobierno unificado. Allí Microsoft empuja hacia Fabric, así que conviene saber qué estrategia sigue la organización antes de elegir piezas.
Las equivalencias de la tabla no son uno a uno. Migrar «Glue a Data Factory» no es cambiar un nombre: cambian el modelo de ejecución y la forma de depurar.
Identidad
Es el dominio donde más se nota la diferencia. IAM de AWS es muy granular y potente, pero exige diseño disciplinado: sin convenciones claras, las políticas se vuelven inmanejables.
Entra ID facilita la federación con el entorno corporativo. Donde la identidad Microsoft ya está madura, Azure ahorra mucho trabajo. En equipos cloud-first con DevOps fuerte, IAM da una precisión difícil de igualar.
El coste lo pone el diseño
Ningún cloud es barato por defecto. El coste lo marcan el diseño, la disciplina FinOps y el gobierno, no el logo del proveedor.
Los dos tienen calculadora de precios y los dos pueden salir caros con una arquitectura mal pensada. Por eso no comparo tarifas: caducan, y el patrón elegido pesa mucho más. Los primeros ajustes que haría están en FinOps en AWS: 10 quick wins en 30 días.
Multi-cloud: cuándo sí y cuándo no
Multi-cloud tiene sentido con un motivo concreto. Por ejemplo, un requisito regulatorio o de residencia de datos, reducir la dependencia de un proveedor o la fusión de organizaciones con stacks distintos.
Sin ese motivo, solo duplica complejidad. Un equipo pequeño sin estándares de plataforma acaba operando dos clouds a medias en vez de uno bien.
Multi-cloud es una estrategia, no un objetivo. Si nadie sabe explicar el caso de negocio, la respuesta es un solo cloud.
Un ejemplo en quince minutos
Así aplicaría las cinco preguntas a un caso típico. Una empresa con Microsoft 365, SQL Server en sus servidores y un equipo de plataforma pequeño. Quiere analítica y automatizaciones en pocos meses.
- Stack: todo el día a día es Microsoft.
- Compliance: la identidad corporativa ya está gobernada en Entra ID.
- Velocidad: el primer resultado útil manda sobre la flexibilidad.
- Coste operativo y riesgo: el equipo no puede absorber mucha plataforma nueva.
Mi lectura: Azure como plataforma principal y refuerzo del gobierno desde el primer día. AWS solo para casos concretos con una ventaja técnica clara y alguien que los mantenga.
Si el escenario fuera un equipo cloud-native con DevOps maduro y una arquitectura muy a medida, la misma lista me llevaría a AWS.
Cómo lo resumo
- Organización muy integrada con Microsoft: empiezo por Azure y refuerzo el gobierno.
- Equipo que busca flexibilidad cloud-native: AWS suele dar más recorrido.
- Necesidades reales de los dos: fronteras claras por dominio y nada duplicado sin motivo.
Lo que aprendí
La pregunta que más decide no es técnica: es qué stack domina ya el equipo. Y la tabla de equivalencias sirve para orientarse, pero engaña si se lee como una migración uno a uno.
Relacionado: Guía AZ-900: plan de 4 semanas para Azure Fundamentals · Guía AWS SAA-C03: plan de 6 semanas para aprobar
Si tienes dudas o lo estás montando tú, cuéntamelo.