Diagrama de arquitectura AWS multirregión de alta disponibilidad

La mayoría de los diagramas de arquitectura AWS multirregión fallan de la misma forma: dos cajas idénticas con las etiquetas us-east-1 y eu-west-1, una al lado de la otra, sin nada entre ellas. Parece alta disponibilidad, pero no responde ninguna de las preguntas que hará quien revise el diseño o quien esté de guardia. ¿Adónde van las escrituras? ¿En qué dirección se replican los datos? ¿Qué mueve el tráfico cuando una región se degrada, y quién o qué lo decide? Este artículo explica qué debe mostrar el diagrama, en qué se diferencian sobre el papel active-active y active-passive, y cómo dibujarlo en Archboard a partir de un ejemplo gratuito.

Qué debe mostrar un diagrama de arquitectura AWS multirregión

Lee el diagrama de arriba abajo, como viaja una petición.

1. Entrada global: Route 53 y CloudFront

• Amazon Route 53 va por encima de las dos regiones, no dentro de una. Pon la política de enrutamiento en la etiqueta de la arista: failover (registros primario y secundario ligados a health checks), latency-based (cada usuario va a la región con menor latencia) o weighted. Dibuja también los health checks: el enrutamiento failover solo funciona si existen.
• Amazon CloudFront va delante de los orígenes regionales. Si usas un origin group con origin failover, dibuja ambos orígenes y marca cuál es el primario. El origin failover de CloudFront se aplica a peticiones GET, HEAD y OPTIONS; las escrituras necesitan su propio camino.

2. Entrada regional: Application Load Balancer

Un ALB es un recurso regional que abarca las Availability Zones que habilitas para él. Dibuja uno por región, dentro del límite de la región, con destinos en al menos dos AZ.

3. Cómputo repartido entre Availability Zones

Servicios de Amazon ECS, node groups de Amazon EKS o grupos de EC2 Auto Scaling, lo que ejecute tu aplicación, repartidos en dos o tres frames de AZ. El diagrama debe dejar claro un punto: la pérdida de una AZ se resuelve dentro de la región, y la pérdida de una región se resuelve en la capa global.

4. La capa de datos, con flechas

Aquí es donde la mayoría de los diagramas se quedan callados. Cada almacén de datos tiene su propio modelo de replicación, y la dirección de la flecha lo cuenta todo.

Añade una nota: las reglas de replicación de S3 se aplican a objetos nuevos; los objetos que ya existían antes de la regla necesitan S3 Batch Replication. Alguien lo preguntará.

5. Secretos y configuración

AWS Secrets Manager puede replicar un secreto a otras regiones, y AWS KMS admite claves multi-Region. Systems Manager Parameter Store es regional. Dibuja de dónde lee cada región sus secretos y su configuración. Una conmutación que funciona hasta que la aplicación no puede descifrar la contraseña de su base de datos no es una conmutación.

6. Observabilidad y plano de control

Muestra qué detecta un fallo y qué actúa sobre él: health checks de Route 53, alarmas de CloudWatch en cada región, canaries sintéticos y un panel entre regiones. Si la conmutación se activa con los routing controls de Amazon Application Recovery Controller (ARC) o con un runbook, ponlo también en el diagrama. El pilar de fiabilidad de AWS Well-Architected recomienda apoyarse en operaciones del plano de datos y no en cambios del plano de control durante la recuperación. El failover de DNS basado en health checks es un ejemplo de lo primero, y el diagrama es el lugar adecuado para mostrar de cuál dependes.

Active-active frente a active-passive

AWS describe cuatro estrategias de recuperación ante desastres. Tres de ellas ejecutan algo en una segunda región, y cada una cambia lo que el diagrama debe contar.

Los números los pones tú. Escribe tus objetivos de RTO y RPO en el canvas, junto a la estrategia, para poder contrastar el diagrama con el requisito de negocio.

Active-active no es automáticamente mejor. Elimina el paso de promoción, pero te obliga a decidir cómo gestiona cada almacén las escrituras concurrentes. Con Aurora Global Database solo escribe una región a la vez, así que un diseño active-active construido sobre ella sigue teniendo una única región de escritura. Dibújalo tal cual es.

Haz explícita la ruta de conmutación

Usa tres estilos de arista y explícalos en una leyenda:

• Ruta de peticiones: flechas continuas desde los usuarios a través de DNS, CDN, ALB y cómputo.
• Replicación: flechas discontinuas entre almacenes de datos, etiquetadas con dirección y modo (async, multi-active).
• Conmutación: una ruta separada y etiquetada que muestra adónde va el tráfico cuando la región primaria no está sana.

Después numera la secuencia de conmutación en una nota del canvas:

1. Route 53 health check on primary ALB fails
2. Route 53 failover record answers with the secondary region
3. Aurora secondary cluster is promoted to writer (global database failover)
4. ECS service / Auto Scaling group in the secondary region scales out
5. Alarms confirm traffic and error rates in the secondary region

Si un paso es manual, indica quién lo ejecuta. Si un paso depende de una API del plano de control, márcalo.

Errores comunes

• Una región dibujada dos veces sin flujo de datos. Dos copias de la misma pila sin flechas de replicación no dicen nada sobre la recuperación.
• Ocultar el plano de control. Health checks, routing controls y runbooks deciden si la conmutación ocurre. Si los omites, el diagrama describe un sistema que no puede conmutar.
• Sin flechas de conmutación. La ruta de peticiones en operación normal es solo la mitad de la historia.
• Servicios globales dibujados dentro de una región. Route 53 y CloudFront son globales; meterlos en un frame de región sugiere una dependencia que no existe, u oculta una que sí.
• Sin AZ. La redundancia a nivel de región no sustituye a la redundancia a nivel de AZ; muestra ambas.
• Estado olvidado. Cachés, colas y almacenes de sesiones también son regionales. Muestra dónde viven y qué les pasa.

Cómo construirlo en Archboard

En Archboard lo construyes con nodos de los packs Cloud y Network: nodos de primera clase con puertos que etiquetas con los nombres de los servicios de AWS, de modo que cada caja muestra tanto su función como el servicio exacto. Así se construye el diagrama.

1. Estudia la plantilla gratuita. Abre /examples/multi-region-cloud-ha. Muestra una CDN, un balanceador de carga en dos regiones, cómputo y una base de datos gestionada entre regiones. Úsala como referencia o cópiala en tu espacio de trabajo con Usar este ejemplo, y luego amplíala con las capas anteriores.
2. Crea los límites de regiones y AZ. Añade dos frames Region del pack Cloud con las etiquetas us-east-1 (primary) y eu-west-1 (secondary). Dentro de cada uno, añade elementos Frame del pack Core para las AZ.
3. Coloca la capa global encima de las regiones. Internet del pack Network para los usuarios, DNS del pack Network con la etiqueta Route 53 (failover routing) y CDN del pack Cloud con la etiqueta CloudFront.
4. Rellena cada región. Cloud LB del pack Cloud con la etiqueta ALB, nodos Compute en cada frame de AZ con ECS service o EC2 Auto Scaling group (o un nodo Kubernetes Cluster para EKS), nodos Managed DB con Aurora (writer) y Aurora (secondary, read-only), otro para DynamoDB global table, y Object Storage con la etiqueta S3.
5. Conecta puertos y etiqueta cada arista. Ruta de peticiones, dirección y modo de replicación, ruta de conmutación. Usa las etiquetas de arista para la política de enrutamiento y el tipo de replicación.
6. Añade el plano de control y las notas. Nodos Box del pack Core para Secrets Manager, CloudWatch y health checks; una Note con la secuencia de conmutación numerada; un bloque Markdown con tus objetivos de RTO y RPO y la estrategia elegida.

Cuenta tus nodos antes de empezar: un mapa completo de dos regiones suele superar los 15 nodos de diagrama por diagrama del plan Free (las notas y los textos cuentan aparte, hasta 150), así que Pro es la opción natural, con nodos ilimitados, inserción en tu sitio de documentación y exportación a PDF. Hay más patrones en la página del caso de uso cloud.

Preguntas frecuentes

¿Puedo usar los iconos oficiales de AWS en Archboard? Los nodos Cloud y Network tipados de Archboard son independientes del proveedor, pero puedes añadir logos de AWS buscando en Iconify con el nodo Icon del pack Core (por ejemplo logos:aws-route53) o subir los AWS Architecture Icons oficiales como imágenes. Etiqueta cada nodo con el nombre del servicio de AWS, como Route 53 o Aurora Global Database, y el diagrama se leerá con claridad para cualquiera que conozca AWS.

¿Debo dibujar regiones y AZ? Sí. Las AZ muestran cómo sobrevives a la caída de una zona; las regiones, cómo sobrevives a una caída regional. Son modos de fallo distintos con mecanismos distintos.

¿Active-active o active-passive? Parte de tus objetivos de RTO y RPO y de tu modelo de datos. Si tu base de datos principal tiene una sola región de escritura, active-passive (pilot light o warm standby) suele ser el diseño más simple y más fiel a la realidad. Escribe la decisión en el diagrama.

¿Cómo lo comparto? Exporta SVG o PNG (con marca de agua en Free), comparte un enlace público o incrústalo en tu documentación con Pro.

Empieza gratis — un asiento, sin tarjeta de crédito