AWS frente a Azure frente a GCP: guía de evaluación de habilidades de plataforma cloud

El problema de contratar por plataforma cloud

Necesitas a una persona ingeniera DevOps sénior. Tienes cinco candidaturas excelentes. Dos son profundamente AWS; una es fuerte en Azure; una usa GCP; una es agnóstica de cloud pero con menos profundidad operacional.

¿A quién contratas? Depende. Pero la mayoría de los equipos lo hace mal: o contratan para la plataforma específica y crean riesgo de bloqueo de proveedor, o contratan a la generalista y descubren que la brecha de conocimiento de plataforma es más profunda de lo previsto.

La respuesta correcta es evaluar ambas cosas: conocimiento operacional específico de plataforma y pensamiento sistémico transferible.

Cuándo evaluar habilidades específicas de plataforma

Evalúa profundidad en AWS/Azure/GCP si:

• Tu stack actual está atado a esa plataforma
• Tu necesidad es profundizar la experiencia en esa nube
• Tus requisitos contractuales o de cumplimiento exigen un cloud concreto

Evalúa fundamentos agnósticos de cloud si:

• Eres multi-cloud o podrías migrar
• Contratas pensamiento sistémico por encima de dominio de herramienta
• La candidatura trabajará entre plataformas

La mayoría de los equipos deberían evaluar ambos: «¿Sabe operar AWS bien?» Y «¿Sabe razonar sobre arquitectura con independencia de la plataforma?».

Marco de evaluación AWS

Habilidades a evaluar

1. IAM y modelado de seguridad

   • ¿Sabe diseñar acceso de mínimo privilegio para una arquitectura de microservicios?
   • ¿Entiende SCP frente a políticas inline frente a políticas gestionadas?
   • ¿Sabe explicar por qué no se deben usar credenciales root?

2. Red y conectividad

   • Diseño de VPC: subredes, enrutado, NACL, security groups
   • Cuándo usar Direct Connect frente a VPN frente a Internet Gateway
   • Trade-offs de red multi-cuenta o multi-región

3. Almacenamiento y bases de datos

   • Optimización EBS: gp3 frente a io2, throughput aprovisionado
   • Estrategias de failover y backup en RDS
   • Políticas de ciclo de vida y versionado en S3 para retención de datos

4. Escalado de cómputo

   • EC2 Auto Scaling Groups frente a Spot Instances
   • Trade-offs ECS frente a EKS
   • Implicaciones de cold start de Lambda en cargas productivas

Ejemplos de preguntas

Escenario take-home:

«Diseña un sistema para ingerir 10 GB de logs al día desde 100 instancias EC2, almacenarlos de forma duradera y consultarlos con latencia inferior al segundo. Tienes presupuesto de 2.000 $/mes. Solo AWS. Explica tus elecciones».

Una buena respuesta considera:

• CloudWatch Logs para recolección (gestionado) frente a Firehose + S3 + Athena (optimizado en coste)
• Políticas de retención de logs para gestionar costes
• Estrategia de indexado (particionado de Athena, o Elasticsearch)
• Patrones de consulta y si la latencia sub-segundo es real o asumida

Una respuesta débil salta a Elasticsearch sin cuestionarse si es necesario.

Diagnóstico en vivo:

«Tu instancia RDS llegó al 80 % de CPU y tus tareas ECS auto-escaladas no pueden conectar a la base de datos durante 2 minutos cada hora, siempre a la misma hora. Cuéntame cómo lo depurarías».

La candidatura debe pensar:

• Correlacionar picos de conexión ECS con carga RDS
• Buscar consultas lentas vía Enhanced Monitoring
• Buscar fugas de conexión (la app no cierra conexiones)
• Considerar si algo más se ejecuta a esa hora (backups, informes)

Marco de evaluación Azure

Habilidades a evaluar

1. Identidad y acceso (Azure AD / Entra)

   • Managed identity frente a service principals
   • RBAC con roles personalizados
   • Políticas de Conditional Access para seguridad

2. Red y seguridad

   • NSG, UDR y peering
   • Azure Firewall frente a NVA
   • Private endpoints y service endpoints

3. Almacenamiento y cómputo

   • Managed disks, premium SSD, ephemeral OS disks
   • App Service frente a Container Instances frente a AKS
   • Failover groups en Azure SQL frente a réplicas de lectura

4. Observabilidad

   • Application Insights frente a Azure Monitor
   • Consultas Log Analytics (KQL)
   • Diagnostic settings y retención

Ejemplos de preguntas

Escenario take-home:

«Estás migrando una aplicación on-premises a Azure. La app necesita IP fija, tiene requisitos estrictos de cumplimiento y debe estar aislada de otros tenants. Diseña la arquitectura de red e identidad».

Buenas respuestas incluyen:

• Subred dedicada con reglas NSG
• Private endpoint para bases de datos
• Managed identity para autenticación de la app
• Políticas de red para control de tráfico

Conversación en vivo:

«Tu Azure Web App va lenta, pero Azure Monitor muestra CPU normal. La latencia se disparó tras desplegar nuevo código. ¿Qué revisas primero?».

La candidatura debe pensar:

• Trazas y dependencias en Application Insights
• CPU del plan de App Service frente a cuellos de botella a nivel de app
• Cambios a nivel de código (consultas nuevas, llamadas bloqueantes)
• Pooling de conexiones a base de datos
• Latencia de dependencias de terceros

Marco de evaluación GCP

Habilidades a evaluar

1. IAM y jerarquía de organización

   • Service accounts y gestión de claves
   • Roles personalizados y mínimo privilegio
   • Organization policies y constraints

2. Cómputo y orquestación

   • Zonas y regiones de Compute Engine
   • Diseño y autoescalado de clúster GKE
   • Cloud Run para cargas serverless

3. Datos y almacenamiento

   • Buckets de Cloud Storage, versionado, ciclo de vida
   • BigQuery para warehousing de datos
   • Failover en Cloud SQL y Cloud Spanner

4. Observabilidad (Google Cloud Operations)

   • Cloud Logging y enrutado de logs
   • Cloud Trace y profiling
   • Cloud Monitoring y métricas personalizadas

Ejemplos de preguntas

Escenario take-home:

«Tienes un trabajo batch que corre cada día en Compute Engine, procesa 1 TB de datos y tarda 2 horas. Quieres reducir coste manteniendo el SLA. Diseña una solución».

Buenas respuestas pueden considerar:

• Preemptible VMs (rentables, aceptables para batch)
• BigQuery para consulta (más rápido que procesar en Compute Engine)
• Cloud Run si es paralelizable
• Spot VMs para cargas tolerantes a fallos

Depuración en vivo:

«Tu servicio Cloud Run hace timeout en algunas peticiones. Los logs están limpios. La latencia P99 pasó de 50 ms a 2 s tras un despliegue. Sigue el rastro».

La candidatura debe pensar:

• Revisar trazas para ver qué operación es lenta
• Investigar dependencias nuevas (base de datos, APIs externas)
• Comprobar límites de conexión a base de datos
• Revisar la asignación de memoria (¿necesita más Cloud Run?)
• Buscar patrones de cold start

Evaluación entre plataformas (agnóstica)

Para candidaturas que han usado varias nubes, evalúa habilidades transferibles:

Pregunta:

«Has diseñado sistemas en AWS y Azure. ¿Qué patrones de diseño se transfieren entre ellas? ¿Qué es fundamentalmente distinto?».

Una buena respuesta reconoce:

• Los conceptos centrales (VPC, IAM, bases de datos gestionadas) son similares
• Los detalles de implementación difieren significativamente
• Los modelos de coste difieren (instancias reservadas frente a compromiso)
• La curva de aprendizaje en cada plataforma es corta una vez entiendes la primera

Esto indica que no es dogmática y puede moverse entre nubes.

Estructura de evaluación para contratación cloud

1. 30 minutos take-home (escenario específico de plataforma con restricciones)
2. 30 minutos de diagnóstico en vivo (en su plataforma de experiencia)
3. 15 minutos de conversación de arquitectura (probar si entiende los trade-offs entre plataformas)

Cuándo contratar multi-cloud frente a especialista de plataforma

Contrata generalistas multi-cloud si:

• Estás migrando entre plataformas
• Necesitas flexibilidad para negociar condiciones con proveedores
• Estás construyendo infraestructura como código portable

Contrata especialistas de plataforma si:

• Tu decisión de plataforma está fijada
• Necesitas conocimiento operacional profundo de los casos límite de esa plataforma
• Estás optimizando costes en un cloud concreto

La mayoría de las organizaciones de ingeniería sanas necesitan ambos: unas pocas especialistas profundas y más generalistas que puedan operar entre nubes.

Construir evaluaciones equitativas entre plataformas

Si evalúas tanto a candidaturas AWS como Azure, estructura tus preguntas con consistencia. Pide a cada candidatura que diseñe el mismo sistema, simplemente en su plataforma. Compara: ¿las arquitecturas tienen un pensamiento de trade-off equivalente? ¿O alguna candidatura tomó atajos?

¿Lista para construir tu evaluación de contratación cloud? Explora recursos de DevOps y Cloud Engineering y cómo interpretar los resultados.