Alta disponibilidad por menos de $500 al mes: arquitecturas reales probadas

Alta disponibilidad (HA) es la capacidad de un sistema de continuar operando cuando alguno de sus componentes falla. La percepción de que esto requiere presupuestos de enterprise es un mito que deja a muchas organizaciones con arquitecturas de single point of failure evitables. Con los servicios cloud modernos, el patrón mínimo viable de HA cuesta bastante menos de lo que se cree.

El patrón base: multi-AZ con failover automático

La arquitectura de HA más costo-efectiva en AWS despliega los componentes críticos en dos zonas de disponibilidad (AZ) mínimo, con balanceo de carga y failover automático:

Capa de cómputo: 2 instancias EC2 t3.medium ($60/mes c/u) o un Auto Scaling Group con mínimo 2 instancias detrás de un Application Load Balancer ($18/mes). Si una instancia falla o su AZ tiene problemas, el ALB deja de enviarle tráfico y el ASG lanza un reemplazo.

Base de datos: RDS en configuración Multi-AZ ($80-120/mes para db.t3.small con MySQL/PostgreSQL). En Multi-AZ, RDS mantiene una réplica sincrónica en otra AZ y hace failover automático en 60-120 segundos si el primario falla. No requiere ningún cambio en la aplicación —el endpoint DNS se redirige automáticamente.

Cache: ElastiCache con cluster mode o Redis en configuración primario-réplica en AZs diferentes. Si el primario falla, la réplica se promueve automáticamente.

Costo estimado: ~$280-380/mes para una aplicación web de tráfico moderado con esta arquitectura.

Lo que muchos olvidan: la capa de aplicación

El failover automático de la infraestructura no es suficiente si la aplicación no está diseñada para ser stateless. Estos son los problemas más comunes:

Sesiones en memoria: Si almacenas sesiones de usuario en la memoria de la instancia de aplicación, cuando el ALB enruta un request a la otra instancia, el usuario pierde su sesión. Solución: sesiones en Redis o en cookies firmadas del lado del cliente.

Archivos locales: Si la aplicación escribe archivos en el disco de la instancia, esos archivos no existen en la otra instancia. Solución: usar S3 para cualquier almacenamiento de archivos.

Migraciones de base de datos al deploy: Si ejecutas ALTER TABLE como parte del despliegue sin backward compatibility, el tiempo de migración se convierte en downtime. Solución: expand/contract pattern —primero añades la nueva columna, luego migras los datos, luego eliminas la antigua en un deploy posterior.

Checklist de verificación de HA

Antes de declarar que tu arquitectura es de alta disponibilidad, verifica:

• ¿Puedes terminar una instancia aleatoria y el servicio sigue funcionando?
• ¿Puedes forzar un failover de RDS y la aplicación se recupera en menos de 3 minutos?
• ¿Tienes alertas configuradas que notifican antes de que el usuario note el problema?
• ¿Los health checks del ALB detectan instancias no saludables en menos de 60 segundos?
• ¿Los backups de base de datos se verifican periódicamente (no solo se hacen)?

El punto más importante: practica el failover en staging. Una arquitectura HA que nunca se ha probado bajo condiciones de falla es una promesa no verificada. Game Day —simular fallas deliberadas para validar la resiliencia— es la única forma de saber que funciona antes de que el incidente real lo pruebe.