Análisis técnico · AWS

Arquitectura AWS —
análisis de despliegue
en 36 horas

Revisión completa del plan de despliegue de una aplicación en AWS: identificación de riesgos de seguridad, disponibilidad y consistencia antes de producción. Trabajo colaborativo con desarrolladores, solution architects e ingenieros.

Análisis pre-producción · 36 horas
Duración
36h
Tipo
Análisis de arquitectura · Pre-producción
Stack
ECS · Fargate · RDS · ElastiCache · S3 · CloudFront · EC2
Equipo
Devs · Solution Architects · Ingenieros · PM
Hallazgos críticos
9 riesgos identificados y documentados
01

Contexto

Una aplicación web con frontend Angular, backend API REST y base de datos PostgreSQL debía desplegarse en AWS. El plan original contemplaba ECS con Fargate para los contenedores, RDS para la base de datos, ElastiCache (Redis) para caché y sesiones, S3 con CloudFront para activos estáticos, y EC2 como generador del VPS.

En 36 horas de trabajo intensivo y colaborativo con desarrolladores, solution architects e ingenieros, se revisó la arquitectura completa, se identificaron riesgos y se propusieron mejoras concretas antes de llegar a producción.

Metodología de trabajo

El análisis se realizó en equipo multidisciplinario. El rol de PM en este contexto fue estructurar los hallazgos, documentar los riesgos, hacer las preguntas correctas y asegurar que cada problema identificado tuviera un responsable y una propuesta de resolución. Los hallazgos en azul corresponden a cambios críticos fundamentales; los en rosa a conflictos o errores que requerían corrección.

02

Arquitectura analizada

El stack completo bajo análisis:

🐳
Docker · ECR
Contenedores e imágenes
⚙️
ECS · Fargate
Orquestación sin servidor
🗄️
RDS PostgreSQL
Base de datos relacional
ElastiCache Redis
Caché y sesiones
🪣
S3 + CloudFront
Estáticos y CDN
🖥️
EC2 · VPS
Infraestructura base
🔐
IAM
Identidad y permisos
🅰️
Angular
Frontend
Diagrama de arquitectura con hallazgos
Cambios críticos
Conflictos / errores
Diagrama de arquitectura AWS con hallazgos marcados
03

Hallazgos y mejoras propuestas

Se identificaron 9 riesgos distribuidos en seguridad, disponibilidad y consistencia de datos. Cada hallazgo incluye el problema identificado y la corrección propuesta.

Crítico · Seguridad
IAM — ECS task execution role con credenciales expuestas
Si ECS se compromete, quedan expuestos S3 (GetObjects) y Secret Value (credenciales sensibles). El ECS task execution role tenía permisos excesivos.
→ Aplicar principio de mínimo privilegio. Separar roles por función. Auditar permisos IAM antes del despliegue.
Error · Seguridad
S3 público por accidente — bucket expone objetos
El bucket S3 podía quedar público accidentalmente, exponiendo objetos. El plan original no contemplaba control de acceso desde CloudFront.
→ Implementar Origin Access Control (OAC) entre CloudFront y S3. El bucket debe quedar privado en el plan operacional.
Conflicto · Consistencia de datos
Inconsistencia entre caché de CloudFront y ElastiCache
Con dos capas de caché (CF + EC), un cambio de precio en RDS puede invalidarse en EC pero CF aún muestra el valor viejo, generando error lógico visible al usuario.
→ TTL corto en CloudFront + invalidación data-driven (BBDD → Cambios → Invalidación CF).
Crítico · Disponibilidad
RDS Proxy → Fargate: riesgo de saturación de conexiones
En escala, Fargate genera contenedores a demanda. RDS db.t3.xlarge tiene un límite de conexiones (~400-500 XS). Sin connection pooling en la app, el riesgo de saturación es real.
→ Implementar connection pooling en la aplicación. Evaluar PgBouncer o RDS Proxy.
Riesgo · Consistencia
Migraciones con Prisma — sin plan de rollback
Si una migración de Prisma falla, la base de datos queda sin consistencia. El plan original no contemplaba rollback estructurado.
→ Definir estrategia de rollback antes de cada migración. Validar en entorno de staging.
Crítico · Disponibilidad
ElastiCache — Cold Start sin precarga
Cuando se despliega con caché vacía, todo el tráfico cae sobre RDS en simultáneo y el sistema colapsa bajo carga inicial.
→ Script de precarga antes del despliegue. Monitorear CPU de RDS post-deploy.
Error · Disponibilidad
ElastiCache sin failover — pérdida de sesiones
Si Redis cae, la app también cae porque no encuentra la sesión del usuario. No había configuración de failover.
→ Configurar ElastiCache con failover habilitado. Evaluar estrategia de sesión alternativa.
Error · Disponibilidad
RDS Single AZ — sin Multi-AZ
RDS configurado en Single AZ implica un único punto de falla. En caso de caída de la zona, la base de datos no tiene réplica disponible.
→ Configurar RDS en Multi-AZ para garantizar consistencia y disponibilidad ante falla zonal.
Crítico · Gobernanza
¿Quién es dueño del despliegue?
El matchmaking entre ECS y Fargate puede generar falla en la gobernanza si no está claro quién tiene ownership del deploy. Fargate implica despliegue no manual — requiere service discovery y autoscaling con CI/CD definido.
→ Definir ownership explícito. Documentar pipeline CI/CD. Establecer responsables por capa.
04

Lo que dejó el análisis

9 riesgos identificados antes de producción — ninguno tuvo que resolverse en caliente con usuarios afectados.

El trabajo colaborativo con devs, solution architects e ingenieros en 36 horas intensivas demostró que la coordinación técnica multiplica la capacidad de detección: cada rol vio lo que los demás no podían ver solos.

La documentación estructurada de hallazgos — con tipo de riesgo, descripción y recomendación — permitió priorizar y asignar responsables sin ambigüedad.

El rol del PM en un análisis técnico no es saber todo — es saber qué preguntar, estructurar lo que el equipo encuentra y asegurar que nada quede sin dueño.

05

Stack y conceptos clave

AWS ECS Fargate ECR RDS PostgreSQL ElastiCache Redis S3 CloudFront IAM EC2 Origin Access Control Connection Pooling Multi-AZ CI/CD Prisma Cold Start Cache Invalidation Angular