Arquitectura AWS para una operación logística transfronteriza 24/7

Contexto

El cliente es una empresa de transporte transfronterizo que opera entre USA y México, con 150 empleados, 370 tractocamiones y 500 cajas en servicio continuo. La operación corre sobre un conjunto de aplicaciones internas: despacho, mecánica, gate, drivers, nómina, interchanges y un sitio público.

Cuando entré como Senior DevOps Engineer a inicios de 2025, la infraestructura cloud había crecido orgánicamente. Algunas aplicaciones escribían directamente contra la base de datos de producción desde sesiones de desarrollo local. Los secretos estaban duplicados en varios lugares. SSL se gestionaba de forma independiente por app. No había una baseline compartida de costo, seguridad ni confiabilidad entre entornos.

Mi responsabilidad: hacerme cargo de la arquitectura AWS de punta a punta y estandarizar el modelo operativo del conjunto de aplicaciones.

La arquitectura

Reconstruí la arquitectura alineada con los cinco pilares del AWS Well-Architected Framework.

Cómputo y networking

• ECS Fargate para todos los servicios productivos. Sin instancias EC2 que gestionar, autoscaling configurado por servicio.
• CloudFront + ACM frente a toda superficie pública, con una estrategia centralizada de certificados para todos los subdominios.
• Route 53 como única fuente de verdad para DNS, con failover por health-checks en rutas críticas.
• Topología de VPC por entorno para mantener dev, staging y producción completamente aislados.

Datos

• RDS PostgreSQL con read replicas para cargas de reportería y un usuario readonly_dev dedicado para queries ad-hoc seguros sobre producción.
• Una base de datos staging separada, sembrada desde dumps de producción, eliminando la necesidad de desarrollar contra datos productivos.
• pgvector para features con embeddings.

Despliegue

• Pipelines GitHub Actions por repositorio (cada app es su propio repo), con:
  • Linting, type-check y test gate
  • Build → push a ECR → deploy vía swap de task-definition de ECS (blue-green, minimumHealthyPercent=100, maximumPercent=200)
  • Rollback automático ante fallo en health-check
• Gestión de secretos estandarizada entre GitHub Secrets, Dockerfile build args y variables de entorno de workflow.

Observabilidad

• CloudWatch Logs con retención de 30 días y metric filters sobre patrones clave: saturación de conexiones, picos 5xx, fallas de deploy.
• CloudWatch Alarms enrutadas a SNS, con runbooks específicos por categoría (memory pressure, connection saturation, dependencias externas).

Problemas clave resueltos

1. Reducción de costos del 50–75% entre entornos

Las facturas mensuales iniciales iban de $700 a $6,000+ entre entornos, con gasto significativo no justificado.

Acciones que movieron el número:

• Right-sizing de task definitions de ECS basado en métricas reales de CloudWatch, no estimaciones.
• IOPS de storage RDS ajustados en entornos que no requerían provisioned IOPS.
• Lifecycle policies de ECR: proteger :latest*, mantener 20 builds históricos, eliminar el resto.
• Retención de CloudWatch Logs estandarizada en 30 días para logs operacionales, más larga solo donde compliance lo requería.
• Apagado programado de entornos no productivos los fines de semana.

Rango mensual final: $350 a $3,400/mes, con curvas de costo predecibles.

2. Migración de apps fuera del acceso directo a la DB de producción

Tres aplicaciones escribían a producción directamente desde sesiones de desarrollo local. Esto ponía en riesgo data real: 28K+ inspecciones, ~500 operadores, años de registros de despacho.

El fix fue estructural:

• Creé una base de datos staging con el mismo esquema, sembrada desde dumps de producción.
• Introduje un usuario readonly_dev con privilegios SELECT únicamente sobre producción para queries seguros.
• Agregué un flag DISABLE_EMAIL a nivel del servicio SES para prevenir envíos accidentales de email a clientes durante sesiones de dev.
• Documenté el nuevo workflow de local-dev para que se volviera el default del equipo.

3. Offline-first para operaciones de campo

Varias operaciones suceden en entornos con conectividad intermitente (camiones en yards, drivers en cruces remotos). Diseñé un modelo de captura y sync offline-first para las apps de campo: las escrituras van a storage local, las sync queues reconcilian cuando regresa la red, y la resolución de conflictos sucede del lado del servidor con audit trail por operador.

4. Manejo de URLs same-origin entre worktrees

El NEXT_PUBLIC_API_URL de cada app estaba hardcoded a localhost:3000, lo cual rompía al correr dos worktrees en puertos distintos. Diseñé una estrategia same-origin: derivar el API base de la propia request en dev, fallback a la URL productiva configurada en producción. Documentado como playbook por app para aplicar el fix de forma consistente en todas las aplicaciones.

Resultado

• Una huella AWS multi-app operando dentro de presupuestos definidos con comportamiento de costo predecible.
• Un workflow de desarrollo local seguro donde el equipo puede correr cualquier app localmente sin arriesgar datos productivos.
• Un perfil de resiliencia para operaciones de campo que maneja pérdida de conectividad.
• Un modelo de despliegue consistente entre todas las apps con rollback automático ante falla.

Hacia adelante, las decisiones arquitectónicas se evalúan contra los pilares del Well-Architected Framework y la baseline operativa establecida aquí.