🔥 Hace unos días internet explotó: hubo un fallo en AWS, en la región us-east-1 (Virginia), en el servicio DynamoDB.
Al final se vio que fue un problema de DNS, pero eso llevó a que muchos servicios de AWS fallaran —y con ellos, muchísimos otros que usamos todos los días: Amazon.com, Canva, Fortnite, Clash of Clans, Visa, Perplexity y muchos más.
Y, como siempre, esta noticia llevó a todos a preguntarse:
¿Deberíamos tener una estrategia multi-cloud o multi-region?
En este post quiero hablar un poco de esto, porque muchas veces se mencionan estas estrategias como si fuera algo simple de aplicar, y no lo es.
Estrategia “multi-algo”
Las organizaciones crean software para resolver problemas de negocio. Puede ser para clientes, proveedores o uso interno, pero siempre hay un valor asociado.
Y si hay valor, también hay riesgo cuando ese software no está disponible.
Por ejemplo:
Imaginá que sos un ecommerce que vende online. Tu tienda genera la mayor parte del negocio.
Si el sitio está caído, no vendés. En cambio, el software de fulfillment es importante, pero si no está disponible por unas horas, el impacto es mucho menor, porque el proceso es asíncrono para el cliente.
Entonces, cuando diseñás tu arquitectura, tenés que entender qué tan crítico es cada servicio y cuánto cuesta que no esté disponible.
Si tu tienda vende €1.000 por hora, una caída de 24 horas te hace perder €24.000.
La pregunta es: ¿qué tan probable es que eso pase? ¿Dónde están los riesgos?
¿En tu aplicación? ¿En la seguridad? ¿En el despliegue? ¿O en los servicios de AWS?
AWS tiene un modelo de responsabilidad compartida, y entenderlo te ayuda a evaluar esos riesgos.
Un fallo completo de una región es raro. Pero ha pasado que servicios específicos fallen, como este último caso de DynamoDB. Podríamos decir que algo así ocurre una vez al año o cada dos años. Es raro, pero tampoco es improbable.
¿Entonces cómo te preparás?
Primero: ¿tenés que prepararte para eso?
Muchas empresas se lanzan a implementar estrategias multi-cloud, con meses de trabajo, miles de líneas de código y complejidad extra, para protegerse de algo que quizás pase una vez al año.
Y esa complejidad extra también aumenta el riesgo: más puntos de fallo, más desafíos de seguridad.
Desde mi punto de vista, eso tiene sentido solo para pocas organizaciones.
Otras empresas piensan en estrategias multi-region, que suelen tener más sentido, aunque también implican costo y mantenimiento adicional.
Volviendo al ejemplo del ecommerce: si podés perder €24.000 en un día, ¿vale la pena invertir más que eso en una estrategia multi-cloud o multi-region?
No siempre.
Qué es una estrategia multi-region
Una estrategia multi-region significa desplegar tus aplicaciones y datos en más de una región de AWS para aumentar la disponibilidad, resiliencia y reducir la latencia.
No implica tener todo corriendo en todas partes. Hay distintos niveles:
-
Active-Passive: Una región activa y otra en espera (solo se usa si la principal falla). → Ejemplo: producción en
us-east-1y respaldo eneu-west-1. -
Active-Active: Dos o más regiones sirven tráfico al mismo tiempo. → Ideal para apps globales, pero más compleja de mantener (sincronización de datos, balanceo, etc.).
En el mundo serverless, estas estrategias son más fáciles de implementar que en arquitecturas tradicionales. Podés tener la misma infraestructura serverless desplegada en varias regiones, y si no hay tráfico, el costo adicional es casi nulo.
Muchas organizaciones usan una estrategia multi-region no solo por la disponibilidad, la usan para mejorar la latencia, sirviendo a los usuarios desde la región más cercana. De esta forma pueden proveer mejores servicios y además ofrecer más resiliencia.
Te dejo un artículo que escribí hace tiempo (y sigue siendo válido) sobre cómo lograr esto con servicios serverless: Global event-driven applications
Entonces, ¿qué deberías hacer?
Aunque tener múltiples regiones activas con serverless es más fácil, también aumenta la complejidad: más despliegues, más código, más mantenimiento.
Por eso, es algo que hay que evaluar según el riesgo del negocio.
Si trabajás en sectores como banca, salud, sistemas públicos o transporte, puede tener sentido diseñar una arquitectura multi-region. Necesitás sistemas muy resilientes, pensados no solo para tolerar fallas de región, sino también fallas internas de tus propios componentes. (Ese tema da para otro post.)
Pero si tenés un ecommerce local o un pequeño SaaS, probablemente no necesites una estrategia multi-region. Quizás te conviene más hacer que tu aplicación sea offline-first para mejorar la experiencia de usuario durante cortes temporales.
Por ejemplo, si tenés una app de eventos, podés guardar en memoria local los eventos visitados o a los que el usuario ya se registró.
Podés combinar enfoques: que la venta de tickets sea multi-region, pero que la visualización de eventos funcione offline. Así minimizás el impacto de una caída y maximizás la disponibilidad percibida.
Y también está bien no hacer nada.
A veces, en un análisis de riesgo, simplemente concluís que hay cosas que pueden pasar, pero no vale la pena mitigarlas porque hay riesgos más relevantes en los que enfocarte.
¿Vos tenés una estrategia multi-region? ¿O confiás en una sola región y un buen diseño?