1. Arquitectura general y balanceador
¿El balanceador es ALB o NLB? ¿Por qué?
En mi arquitectura monolítica uso un ALB (Application Load Balancer). Este se sitúa entre API Gateway y ECS. API Gateway redirige las peticiones HTTP hacia el ALB, y el ALB las distribuye al Target Group donde están registradas las Tasks de ECS que ejecutan la API Flask.
¿Qué sucede si se elimina el Load Balancer?
API Gateway perdería la ruta de comunicación hacia ECS. Aunque las Tasks podrían seguir existiendo, las peticiones externas no llegarían correctamente a la API Flask.
2. ECS, Fargate, Docker, ECR y CloudFormation
¿Tu ECS escala realmente?
ECS puede escalar horizontalmente aumentando el número de Tasks, pero en mi configuración actual no implementé autoscaling automático. Si el DesiredCount está en 1, se mantiene una sola Task. Para escalar, sería necesario añadir Application Auto Scaling.
¿Qué ocurre si elimino el ECS Service?
El Cluster, la Task Definition y el repositorio ECR pueden persistir, pero no habría ningún proceso que mantenga la Task en ejecución. El Load Balancer se quedaría sin destinos sanos y la API dejaría de funcionar.
¿La Task Definition es el archivo YAML?
No exactamente. El archivo YAML representa la plantilla completa de CloudFormation. Dentro de ese YAML existe un recurso específico llamado Task Definition, donde se define la configuración para ejecutar el contenedor.
¿Qué pasa si borras ECR o la imagen Docker?
ECR almacena la imagen, no ejecuta la aplicación. Si la imagen desaparece, una Task ya lanzada podría seguir funcionando, pero ECS no podría crear nuevas Tasks ni realizar redespliegues al no tener una imagen que descargar.
¿Cuándo usarías ECS en vez de Lambda?
Usaría ECS para procesos de larga duración, servicios siempre activos, mayor control del entorno o contenedores con dependencias específicas. Lambda es preferible para ejecuciones cortas y bajo demanda.
3. Bases de datos: RDS, DynamoDB, VPC e IAM
¿Por qué usaste RDS si solo gestionas productos?
Para este CRUD simple también podría usarse DynamoDB. Elegí RDS en la arquitectura monolítica para representar un modelo tradicional con una API Flask conectada a una base de datos relacional PostgreSQL.
¿Por qué DynamoDB no necesita Security Group y RDS sí?
Porque RDS reside dentro de una VPC y se accede mediante una conexión tradicional (endpoint, puerto y Security Groups). DynamoDB es un servicio gestionado de AWS al que se accede mediante API e IAM.
Si DynamoDB no necesita VPC, ¿para qué sirven los VPC Endpoints?
Sirven para que recursos privados dentro de la VPC, como ECS, accedan a servicios de AWS (ECR, S3, CloudWatch) sin salir a Internet. Para Lambda con DynamoDB no son estrictamente necesarios si la función está fuera de la VPC.
¿Por qué RDS en monolítica y DynamoDB en desacoplada?
RDS encaja con una arquitectura tradicional donde Flask se conecta a una base relacional. DynamoDB es ideal para serverless, ya que Lambda accede mediante API e IAM, evitando conexiones persistentes y configuraciones de red complejas.
¿Qué pasa si RDS se satura?
Las consultas aumentan su latencia, el sistema puede rechazar conexiones y la API podría devolver errores o timeouts. En ese caso, se deben revisar métricas, escalar RDS, optimizar consultas o implementar un pool de conexiones.
4. Lambda, API Gateway y errores
Lambda tarda 16 segundos, pero el código tarda 12. ¿Qué puede ser?
Probablemente se trate de un Cold Start. Es el tiempo adicional que requiere Lambda para preparar el entorno antes de ejecutar el código. Esto se puede verificar en CloudWatch.
API Gateway devuelve 500, pero la Lambda funciona sola. ¿Qué puede ser?
Puede ser un problema de integración: permisos insuficientes para invocar la Lambda, formato de respuesta incorrecto, timeout de API Gateway, problemas de CORS o una configuración errónea del método.
¿Cómo sabe API Gateway que una Lambda falla?
Porque la Lambda devuelve un error, una excepción, una respuesta mal formada o no responde antes del timeout. API Gateway traduce esto en una respuesta de error para el cliente.
¿Cómo diagnosticas un error 500?
Primero revisaría los CloudWatch Logs. Analizaría los registros de API Gateway, Lambda o ECS según la arquitectura, y verificaría la conectividad con la base de datos.
5. Estado, escalado, rendimiento y costes
¿Tu API guarda estado?
No, la API es stateless. Cada petición se procesa de forma independiente. El estado persistente reside exclusivamente en la base de datos (RDS o DynamoDB).
Llegan 10.000 peticiones pidiendo 100.000 productos. ¿Qué pasa?
Se puede saturar la API o la base de datos. En la monolítica, ECS o RDS podrían colapsar. En la desacoplada, Lambda escala mejor, pero DynamoDB también tiene límites. La solución es paginar, filtrar, limitar resultados y utilizar caché.
¿Por qué la desacoplada puede ser más barata?
Porque Lambda solo se ejecuta bajo demanda y DynamoDB se ajusta al uso real. En la monolítica, recursos como ECS, el Load Balancer y RDS permanecen activos constantemente, generando costes fijos.
¿Qué componente escala peor en tu monolítica?
ECS, si solo hay una Task sin autoscaling. Asimismo, RDS puede convertirse en un cuello de botella ante alta concurrencia. Se optimizaría mediante autoscaling, caché, paginación y escalado vertical u horizontal de la base de datos.