Diagramme d'architecture AWS multi-région haute disponibilité

La plupart des diagrammes d'architecture AWS multi-région échouent de la même manière : deux boîtes identiques étiquetées us-east-1 et eu-west-1, côte à côte, sans rien entre elles. Cela ressemble à de la haute disponibilité, mais ne répond à aucune des questions que posera un relecteur ou l'ingénieur d'astreinte. Où vont les écritures ? Dans quel sens les données sont-elles répliquées ? Qu'est-ce qui déplace le trafic quand une région se dégrade, et qui ou quoi en décide ? Cet article détaille ce que le diagramme doit montrer, comment active-active et active-passive diffèrent sur le papier, et comment le dessiner dans Archboard à partir d'un exemple gratuit.

Ce qu'un diagramme d'architecture AWS multi-région doit montrer

Lisez le diagramme de haut en bas, comme le parcours d'une requête.

1. Entrée globale : Route 53 et CloudFront

• Amazon Route 53 se place au-dessus des deux régions, pas dans l'une d'elles. Indiquez la politique de routage sur le libellé de l'arête : failover (enregistrements primaire et secondaire liés à des health checks), latency-based (chaque utilisateur va vers la région à la latence la plus faible) ou weighted. Dessinez aussi les health checks : le routage failover ne fonctionne que s'ils existent.
• Amazon CloudFront se place devant les origines régionales. Si vous utilisez un origin group avec origin failover, dessinez les deux origines et indiquez laquelle est primaire. L'origin failover de CloudFront s'applique aux requêtes GET, HEAD et OPTIONS ; les écritures ont besoin de leur propre chemin.

2. Entrée régionale : Application Load Balancer

Un ALB est une ressource régionale qui couvre les Availability Zones que vous activez pour lui. Dessinez-en un par région, à l'intérieur de la limite de la région, avec des cibles dans au moins deux AZ.

3. Le calcul réparti sur les Availability Zones

Services Amazon ECS, node groups Amazon EKS ou groupes EC2 Auto Scaling, selon ce qui exécute votre application, répartis sur deux ou trois frames d'AZ. Le diagramme doit rendre un point évident : la perte d'une AZ est absorbée dans la région, la perte d'une région est absorbée par la couche globale.

4. La couche de données, avec des flèches

C'est là que la plupart des diagrammes se taisent. Chaque magasin de données a son propre modèle de réplication, et le sens de la flèche dit tout.

Ajoutez une note : les règles de réplication S3 s'appliquent aux nouveaux objets ; les objets existant avant la règle nécessitent S3 Batch Replication. Quelqu'un posera la question.

5. Secrets et configuration

AWS Secrets Manager peut répliquer un secret vers d'autres régions, et AWS KMS prend en charge les clés multi-Region. Systems Manager Parameter Store est régional. Dessinez l'endroit où chaque région lit ses secrets et sa configuration. Une bascule qui fonctionne jusqu'au moment où l'application ne peut plus déchiffrer le mot de passe de sa base n'est pas une bascule.

6. Observabilité et plan de contrôle

Montrez ce qui détecte une panne et ce qui agit : health checks Route 53, alarmes CloudWatch dans chaque région, canaries synthétiques et un tableau de bord inter-régions. Si la bascule est déclenchée par les routing controls d'Amazon Application Recovery Controller (ARC) ou par un runbook, placez-les aussi sur le diagramme. Le pilier Fiabilité d'AWS Well-Architected recommande de s'appuyer sur des opérations du plan de données plutôt que sur des changements du plan de contrôle pendant la reprise. Le failover DNS piloté par des health checks relève de la première catégorie, et le diagramme est le bon endroit pour montrer de laquelle vous dépendez.

Active-active ou active-passive

AWS décrit quatre stratégies de reprise après sinistre. Trois d'entre elles font tourner quelque chose dans une seconde région, et chacune change ce que le diagramme doit dire.

Les chiffres sont à vous de les fixer. Écrivez vos objectifs de RTO et de RPO sur le canvas, à côté de la stratégie, pour pouvoir confronter le diagramme à l'exigence métier.

L'active-active n'est pas automatiquement meilleur. Il supprime l'étape de promotion, mais vous oblige à décider comment chaque magasin de données gère les écritures concurrentes. Avec Aurora Global Database, une seule région écrit à la fois : une conception active-active bâtie dessus garde donc une région d'écriture unique. Dessinez-le tel quel.

Rendez le chemin de bascule explicite

Utilisez trois styles d'arêtes et expliquez-les dans une légende :

• Chemin des requêtes : flèches pleines depuis les utilisateurs, à travers DNS, CDN, ALB et calcul.
• Réplication : flèches en pointillés entre magasins de données, avec le sens et le mode (async, multi-active).
• Bascule : un chemin distinct et étiqueté qui montre où va le trafic quand la région primaire est en mauvaise santé.

Numérotez ensuite la séquence de bascule dans une note sur le 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 une étape est manuelle, indiquez qui l'exécute. Si une étape dépend d'une API du plan de contrôle, signalez-le.

Erreurs fréquentes

• Une région dessinée deux fois, sans flux de données. Deux copies de la même pile sans flèches de réplication ne disent rien de la reprise.
• Masquer le plan de contrôle. Health checks, routing controls et runbooks décident si la bascule a lieu. Sans eux, le diagramme décrit un système incapable de basculer.
• Aucune flèche de bascule. Le chemin des requêtes en fonctionnement normal n'est que la moitié de l'histoire.
• Services globaux dessinés dans une région. Route 53 et CloudFront sont globaux ; les placer dans un frame de région suggère une dépendance inexistante, ou en masque une réelle.
• Pas d'AZ. La redondance au niveau région ne remplace pas la redondance au niveau AZ ; montrez les deux.
• État oublié. Caches, files d'attente et stockages de sessions sont eux aussi régionaux. Montrez où ils se trouvent et ce qu'il leur arrive.

Le construire dans Archboard

Dans Archboard, vous construisez ce diagramme avec les nœuds des packs Cloud et Network : des nœuds à part entière, dotés de ports, que vous étiquetez avec les noms des services AWS. Chaque boîte montre ainsi à la fois son rôle et le service exact. Voici comment construire le diagramme.

1. Étudiez le modèle gratuit. Ouvrez /examples/multi-region-cloud-ha. Il montre un CDN, un load balancer sur deux régions, du compute et une base de données managée répartie entre les régions. Servez-vous-en comme référence, ou copiez-le dans votre espace de travail avec Utiliser cet exemple, puis complétez-le avec les couches décrites plus haut.
2. Créez les limites de régions et d'AZ. Ajoutez deux frames Region du pack Cloud, étiquetés us-east-1 (primary) et eu-west-1 (secondary). Dans chacun, ajoutez des éléments Frame du pack Core pour les AZ.
3. Placez la couche globale au-dessus des régions. Internet du pack Network pour les utilisateurs, DNS du pack Network étiqueté Route 53 (failover routing) et CDN du pack Cloud étiqueté CloudFront.
4. Remplissez chaque région. Cloud LB du pack Cloud étiqueté ALB, nœuds Compute dans chaque frame d'AZ étiquetés ECS service ou EC2 Auto Scaling group (ou un nœud Kubernetes Cluster pour EKS), nœuds Managed DB étiquetés Aurora (writer) et Aurora (secondary, read-only), un autre pour DynamoDB global table, et Object Storage étiqueté S3.
5. Reliez les ports et étiquetez chaque arête. Chemin des requêtes, sens et mode de réplication, chemin de bascule. Utilisez les libellés d'arêtes pour la politique de routage et le type de réplication.
6. Ajoutez le plan de contrôle et les notes. Nœuds Box du pack Core pour Secrets Manager, CloudWatch et les health checks ; une Note avec la séquence de bascule numérotée ; un bloc Markdown avec vos objectifs de RTO et de RPO et la stratégie retenue.

Comptez vos nœuds avant de commencer : une carte complète sur deux régions dépasse généralement les 15 nœuds de diagramme par diagramme du plan Free (les notes et les textes sont comptés à part, jusqu'à 150), Pro est donc le choix naturel, avec des nœuds illimités, l'intégration dans votre site de documentation et l'export PDF. D'autres modèles sont disponibles sur la page du cas d'usage cloud.

FAQ

Puis-je utiliser les icônes officielles AWS dans Archboard ? Les nœuds Cloud et Network typés d'Archboard sont indépendants des fournisseurs, mais vous pouvez ajouter des logos AWS en cherchant dans Iconify avec le nœud Icon du pack Core (par exemple logos:aws-route53), ou importer les AWS Architecture Icons officielles comme images. Étiquetez chaque nœud avec le nom du service AWS, comme Route 53 ou Aurora Global Database, et le diagramme se lit clairement pour quiconque connaît AWS.

Faut-il dessiner à la fois les régions et les AZ ? Oui. Les AZ montrent comment vous survivez à la panne d'une zone, les régions comment vous survivez à une panne régionale. Ce sont des modes de défaillance et des mécanismes différents.

Active-active ou active-passive ? Partez de vos objectifs de RTO et de RPO et de votre modèle de données. Si votre base principale n'a qu'une région d'écriture, l'active-passive (pilot light ou warm standby) est souvent la conception la plus simple et la plus fidèle. Écrivez la décision sur le diagramme.

Comment le partager ? Exportez en SVG ou PNG (avec filigrane sur Free), partagez un lien public, ou intégrez-le à votre documentation avec Pro.

Commencez gratuitement — un siège, sans carte bancaire