Bonnes pratiques pour les changements de zone dans ARC

Assurez-vous d'avoir prévu une capacité suffisante, que vous l'avez prédimensionnée ou que vous pouvez la dimensionner automatiquement, pour faire face à la charge supplémentaire imposée aux zones de disponibilité lorsque vous commencez un changement de zone. Dans le cas d'une architecture axée sur la restauration, il est généralement recommandé de prédimensionner la capacité de calcul afin d'inclure une marge de manœuvre suffisante pour répondre aux pics de trafic lorsque l'une de vos trois répliques (généralement) est hors ligne.

Lorsque vous entamez un changement de zone pour une ressource prise en charge et que le trafic est transféré hors d'une zone AZ, la capacité utilisée par votre application pour traiter les demandes est supprimée. Vous devez vous assurer que vous avez prévu un transfert de trafic en dehors d'un AZ et que vous pouvez continuer à traiter les demandes pendant le resteAZs.

Lorsqu'Amazon Application Recovery Controller (ARC) déplace le trafic pour éviter une perturbation, par exemple en utilisant le décalage de zone ou le décalage automatique de zone, le mécanisme ARC utilisé pour déplacer le trafic de votre application est une mise à jour. DNS Une DNS mise à jour entraîne le renvoi de toutes les nouvelles connexions hors de la zone affectée.

Cependant, les clients disposant de connexions ouvertes préexistantes peuvent continuer à faire des demandes concernant l'emplacement altéré jusqu'à ce qu'ils se reconnectent. Pour garantir un rétablissement rapide, nous vous recommandons de limiter la durée pendant laquelle les clients restent connectés à vos terminaux.

Testez régulièrement le déplacement du trafic hors des zones de disponibilité pour votre application en commençant par des changements de zone. Planifiez et exécutez les changements de zone de départ, de préférence dans les environnements de test et de production, dans le cadre des tests de basculement réguliers visant à restaurer vos applications en cas de sinistre. Des tests réguliers sont essentiels pour garantir que vous êtes prêt et que vous avez la confiance nécessaire pour atténuer les problèmes lorsqu'un événement opérationnel se produit.

Les décalages zonaux fonctionnent en marquant une ressource, c'est-à-dire une réplique d'application, comme étant défectueuse dans une zone de disponibilité. Il est donc essentiel de s'assurer que les ressources de vos applications sont généralement saines et qu'elles absorbent activement le trafic dans les zones de disponibilité d'une région. Nous vous recommandons de disposer de tableaux de bord pour suivre cela, y compris, par exemple, des métriques Elastic Load Balancing pour les cibles non conformes et bytesProcessed par zone de disponibilité.

Envisagez de surveiller l'état de vos ressources depuis une deuxième région adjacente. Les avantages de cette approche sont qu'elle peut être plus représentative de l'expérience de vos utilisateurs finaux et qu'elle réduit également le risque que votre application et votre surveillance soient touchées par le même sinistre en même temps.

Pour démarrer un changement de zone lorsque vous devez restaurer une application rapidement, avec peu de dépendances, nous vous recommandons d'utiliser les actions AWS Command Line Interface ou API avec changement de zone, avec des informations d'identification préenregistrées, si possible. Vous pouvez également commencer à changer de zone dans le AWS Management Console, pour faciliter l'utilisation. Mais lorsqu'une restauration rapide et fiable est essentielle, les opérations sur le plan de données constituent un meilleur choix. Pour plus d'informations, consultez le Guide de API référence Zonal Shift.

Un changement de zone déplace le trafic hors d'une zone de disponibilité de façon temporaire, afin d'atténuer les perturbations. Vous devez restaurer la ressource pour la mise en service de l'application dès que vous avez pris des mesures pour corriger un problème. Cela garantit que l'ensemble de votre application est restauré dans son état d'origine entièrement redondant et résilient.