Uno de los aspectos más importantes al diseñar arquitecturas en AWS capaces de soportar nuestras cargas de trabajo —o las de nuestros clientes— es analizarlas desde tres grandes perspectivas:
1️⃣ Comprender el negocio y su necesidad real
Antes de elegir servicios o patrones, es fundamental entender qué necesita el negocio, qué problema se debe resolver y qué métricas definen el éxito.
2️⃣ Identificar los servicios adecuados
AWS ofrece una amplia variedad de servicios; elegir los correctos es clave para lograr eficiencia, seguridad y escalabilidad.
3️⃣ Entender cómo está construida la infraestructura de AWS (tema central de este artículo)
Conocer la estructura física y lógica sobre la que funcionan nuestros servicios es esencial para diseñar arquitecturas resilientes, disponibles y preparadas para fallos.
📌 En este artículo analizaremos en detalle:
- Regiones
- Zonas de Disponibilidad (AZs)
- Alta Disponibilidad (HA)
- Recuperación ante Desastres (DR)
- RTO
- RPO
Preámbulo
Cuando hablamos de arquitecturas resilientes en la nube, lo primero que debemos entender no son los servicios, sino la infraestructura física que los soporta. AWS fue diseñada desde su base para tolerar fallas, aislar riesgos y garantizar continuidad incluso ante desastres mayores.
Aquí explico un claro resumen de cómo se organiza esta infraestructura.
🌎 Regiones en AWS:
Una Región de AWS es una ubicación física geográfica, como us-east-1, eu-west-1 o sa-east-1.
Están distribuidas estratégicamente a nivel global, lo que permite:
✔️ Reducir la latencia para usuarios locales
✔️ Cumplir normativas de soberanía de datos
✔️ Aislar fallas entre países o continentes
✔️ Crear estrategias de DR multi-región
Cada región en AWS, esta compuesta por al menos 3 Zonas de Disponibilidad (AZ), lo que permite crear distintas estrategias de resiliencia.
Importante:
Las regiones en AWS, no comparten infraestructura eléctrica, de red ni datacenters entre sí. Son entornos completamente independientes.
🧩 Zonas de Disponibilidad en AWS (AZ):
Una AZ puede estar compuesta por uno o varios datacenters discretos, separados por varios kilómetros entre sí, pero conectados mediante enlaces privados, de baja latencia y alta capacidad.
Ejemplos:
us-east-1a, us-east-1b, us-east-1c.
Características clave:
- Energía independiente
- Sistemas de enfriamiento propios
- Conectividad redundante
- Aislamiento físico real
- Conexión interna de baja latencia
Estas características permiten ejecutar sistemas en activo-activo dentro de la región.
En otras palabras:
Si una AZ falla, las otras continúan operando.
🟢 Alta Disponibilidad (HA) en AWS
La Alta Disponibilidad (HA) es la capacidad de un sistema para seguir funcionando incluso cuando uno o varios componentes fallan.
En AWS, la HA se construye distribuyendo recursos entre múltiples AZ dentro de la misma región.
Características claves de HA usando Multi-AZ en AWS
✔️ Redundancia geográfica intra-región
✔️ Tolerancia a fallas locales (AZ caída)
✔️ Balanceo de carga inteligente (ALB/NLB)
✔️ Replicación sincrónica donde aplica
RDS Multi-AZ
EFS Multi-AZ
✔️ Auto Scaling distribuido entre AZ
¿Por qué es importante la HA en nuestros sistemas y negocio?
- Reduce la probabilidad de caída total del servicio.
- Garantiza continuidad operativa.
- Permite cumplir SLAs estrictos (99.9% a 99.99%).
- Minimiza el impacto de mantenimientos programados.
En resumen, HA = resiliencia dentro de una región.
🔥 Disaster Recovery (DR) en AWS
La Recuperación ante Desastres (DR) es la capacidad de restaurar la operación del sistema cuando ocurre un desastre de gran escala, normalmente una falla completa de una región.
Características clave del DR
✔️ Aislamiento total entre regiones
✔️ Replicación entre regiones (generalmente asincrónica):
S3 Cross-Region Replication
Aurora Global Database
RDS Cross-Region Read Replicas
✔️ Despliegue de ambientes completos o parciales, según la estrategia:
Backup & Restore —-> más económico, mayor RTO
Pilot Light
Warm Standby
Active-Active -—-> más costoso, menor RTO
✔️ Dependencia de las métricas RTO y RPO
La elección de la estrategia depende de estos dos métricas, las cuales son muy importantes y vienen dadas por la capacidad y necesidad del negocio de mantener su continuidad operativa.
⏱️ RTO y RPO: Métricas que gobiernan HA y DR
RTO — Recovery Time Objective: Tiempo máximo que el negocio acepta que un sistema esté fuera de servicio.
Ejemplo:
Si un retail sufre la caída de la región donde opera su sistema de ventas, el RTO indica cuánto tiempo puede estar sin vender antes de que el impacto sea crítico.
Es decir, cuánto tiempo pueden estar “fuera del aire” sin que la situación se convierta en un problema serio para la organización.
RPO — Recovery Point Objective: es la cantidad máxima de datos que el negocio acepta perder.
Ejemplo:
Si la región cae, el RPO indica cuántas transacciones no registradas puede tolerar el retail sin impacto significativo.
En otras palabras, es cuántas ventas podrían no registrarse antes de que la situación se convierta en un problema serio para la organización.
*Diagrama de referencia una solucion HA (activo-activo), con un DR en el cual solamente la capa aplicativo y web, se encuentra apagado. *
RPO ~ 0 min ---> la data se replica otra región de manera Async (BBDD)
RTO <= 30 min ---> Encendido de maquinas y pruebas de funcionamiento
🧭 Conclusión:
Para comprender bien la diferencia entre HA y DR, basta recordar su alcance:
HA actúa dentro de una región, distribuyendo carga entre AZs.
DR actúa entre regiones, permitiendo recuperar operaciones ante fallas catastróficas.
Conocer esta infraestructura es clave para diseñar soluciones robustas, resilientes y alineadas al negocio.
Happy learnning on AWS!
Top comments (0)