Preguntas de entrevista Arquitecto cloud

La alta disponibilidad y la recuperación ante desastres son preocupaciones relacionadas pero distintas, y las diseño por separado. Para HA, parto de despliegues multi-AZ como base para cualquier carga de trabajo de producción: ningún componente debería tener un punto único de fallo dentro de una región. Uso servicios gestionados donde manejan HA de forma nativa, como RDS Multi-AZ, ECS con ALB y S3. Defino SLOs desde el principio (típicamente 99,9% o 99,95%) y trabajo hacia atrás para determinar qué nivel de redundancia justifica el coste. Para DR, defino objetivos RTO y RPO con los stakeholders antes de tocar la infraestructura. Una carga de trabajo con un RTO de cuatro horas es muy diferente de una con quince minutos: la primera puede usar snapshots diarios a una región secundaria, mientras que la segunda necesita replicación casi en tiempo real y un standby activo. También programo simulacros de DR trimestrales, porque un plan de recuperación no probado no es un plan.

El control de costes a escala es tanto un problema organizativo como técnico. En el lado técnico, implemento políticas de etiquetado aplicadas en la creación de cuentas para que cada recurso tenga un centro de coste, equipo y etiqueta de entorno desde el primer día. Uso AWS Cost Explorer o GCP Billing con alertas de presupuesto por equipo, dando a los ingenieros visibilidad sobre lo que cuestan sus cargas de trabajo en casi tiempo real. También realizo una comprobación semanal de Trusted Advisor o Recommender para identificar recursos infrautilizados y oportunidades de dimensionamiento correcto. El lado organizativo importa igual: defiendo un modelo donde los equipos poseen su gasto en la nube y tienen una revisión mensual. Esto crea responsabilidad sin necesitar un guardián central. He visto programas de FinOps bien gestionados reducir el gasto en la nube entre un 30 y un 40% en seis meses sin ninguna regresión de rendimiento.

El zero-trust parte del principio de que ninguna ubicación de red es inherentemente confiable, lo que significa pasar de controles basados en perímetro a controles basados en identidad y contexto. En la práctica esto significa reemplazar los patrones de acceso VPN con proxies conscientes de la identidad como Google BeyondCorp o AWS Verified Access, aplicar políticas IAM de mínimo privilegio con revisiones de acceso regulares, y cifrar datos en tránsito y en reposo por defecto. Uso SCPs de AWS o GCP Organisation Policies para imponer controles a nivel de cuenta para que ningún equipo pueda abrir accidentalmente un bucket S3 público o deshabilitar CloudTrail. También separo las cargas de trabajo en diferentes cuentas o proyectos por límite de seguridad en lugar de solo por entorno. La gestión de secretos va a través de Secrets Manager o Vault, con políticas de rotación que hacen imposibles las credenciales de larga duración.

Esta decisión debe estar guiada por el riesgo de negocio, el calendario y el coste final de ejecutar la carga en cada estado, no por una preferencia general por un enfoque. El lift-and-shift es el primer paso correcto cuando el objetivo principal es salir de un centro de datos en un plazo fijo, cuando la aplicación es estable y de poco cambio, o cuando el equipo carece de experiencia cloud-native para re-arquitecturar de forma segura. La re-arquitectura cloud-native tiene sentido cuando la carga tiene patrones de carga variable que el serverless o la conteneurización servirían mejor, o cuando el coste operativo de ejecutar la versión liftada en VMs cloud es comparable o superior al on-premise. Típicamente recomiendo un enfoque por fases: lift primero, luego re-arquitecturar los componentes donde el beneficio de coste u operativo es más claro.

Lideré la migración de un ERP monolítico legacy a AWS para un cliente manufacturero. La aplicación no había sido modificada en siete años y tenía dependencias no documentadas en unidades de red y objetos COM locales. Las descubrimos solo durante la migración piloto de la primera unidad de negocio. En lugar de intentar arreglarlo todo antes de migrar, introduje un patrón strangler-fig: liftamos el monolito a una flota EC2 detrás de un ALB, luego identificamos los tres componentes más sensibles a la red y los reemplazamos con equivalentes gestionados de AWS durante doce semanas. También descubrimos que la aplicación escribía archivos temporales en una ruta local codificada en configuración: lo detectamos en staging gracias a una capa de emulación de sistema de archivos de red que habíamos configurado como red de seguridad. La migración se completó a tiempo y el cliente vio una reducción del 22% en costes de infraestructura en el primer trimestre completo en la nube.

Un equipo de desarrollo quería almacenar todo el estado de sesión en un gran cluster de ElastiCache sin ninguna replicación, como medida de ahorro de costes. La aplicación estaba orientada al consumidor y la pérdida de esa caché desconectaría a todos los usuarios activos. Construí un modelo de costes mostrando que la diferencia entre un cluster de nodo único y uno replicado era menos de $400 al mes, frente a una pérdida de ingresos proyectada de aproximadamente $12.000 por hora de inactividad según el volumen de transacciones de la aplicación. Lo presenté no como una opinión de arquitectura sino como un cálculo riesgo/coste, enmarcando la pregunta de replicación como una decisión de negocio para el propietario del producto con información completa. El equipo acordó la configuración replicada y también añadimos un camino de expiración de sesión elegante.

Me uní a un equipo que gastaba unos $180.000 al mes en AWS. Lo primero que hice fue obtener un desglose de Cost Explorer por servicio y etiqueta, que reveló que el 34% del gasto era en instancias EC2 funcionando con menos del 15% de utilización de CPU de media. Un 12% adicional era en tarifas de transferencia de datos causadas por una arquitectura que enrutaba todo el tráfico entre servicios a través de una NAT Gateway en lugar de usar VPC endpoints para S3 y DynamoDB. Redimensioné las instancias infrautilizadas usando las recomendaciones de Compute Optimizer, reduciendo el gasto en EC2 un 28%. Reemplacé el enrutamiento NAT Gateway con VPC endpoints, eliminando completamente el coste de transferencia de datos. También convertí el gasto on-demand de las cargas de trabajo de línea base estable a Compute Savings Plans. La reducción total fue de $180.000 a aproximadamente $98.000 al mes en tres meses.

Mi enfoque estándar es Terraform con una arquitectura basada en módulos, donde las primitivas de infraestructura compartidas (VPCs, roles IAM, grupos de seguridad) viven en una biblioteca de módulos central y los equipos individuales las consumen como dependencias en lugar de escribir las suyas. Uso Terragrunt para gestionar la configuración entre entornos, manteniendo los valores específicos del entorno en archivos YAML y el código Terraform agnóstico al entorno. El estado se almacena en S3 con bloqueo DynamoDB y un bucket de estado separado por entorno y cuenta. La CI/CD ejecuta terraform plan en cada PR, publicando la salida del plan como comentario para revisión antes de cualquier apply. Para equipos nuevos en IaC, implemento una capa policy-as-code con Open Policy Agent o Checkov para detectar configuraciones incorrectas de seguridad antes de la revisión de código.

El multi-cloud se propone a menudo como estrategia de mitigación de riesgos pero introduce sus propios riesgos: complejidad operativa, fragmentación de habilidades y mayor coste total de propiedad. Aconsejo a los clientes distinguir entre multi-cloud genuino (cargas de trabajo activas en dos o más proveedores simultáneamente) y portabilidad cloud (construir de manera que no cree dependencias fuertes). Para la mayoría de organizaciones, la portabilidad cloud mediante conteneurización y capas de datos abstraídas es la respuesta correcta: preserva opciones sin pagar el coste operativo de gestionar dos entornos cloud diariamente. El verdadero multi-cloud tiene sentido en tres escenarios: requisitos regulatorios que exigen diversidad de proveedores, adquisiciones donde integrar la infraestructura costaría más que gestionar dos estates, y servicios específicos donde un proveedor es claramente superior para una carga particular.

El punto de partida es mapear el presupuesto de latencia: ¿cuál es el tiempo de respuesta máximo aceptable para la solicitud del usuario, y cómo se distribuye entre tránsito de red, cómputo y almacenamiento? Para una aplicación distribuida globalmente usaría un CDN como CloudFront o Fastly para activos estáticos y respuestas API cacheables en el borde, colocando cómputo en tres o cuatro regiones seleccionadas según la geografía de usuarios. El enrutamiento de API va a través de un equilibrador de carga global como AWS Global Accelerator o GCP Global LB, dirigiendo solicitudes a la región sana más cercana. Para la capa de datos, la decisión depende de los requisitos de consistencia: si la consistencia eventual es aceptable, DynamoDB Global Tables o Spanner proporcionan lecturas de baja latencia globalmente. Si se requiere consistencia fuerte, mantengo una única región primaria con réplicas de lectura en regiones secundarias. También implementaría circuit breakers en el límite regional.