Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Schémas d'évacuation des zones de disponibilité Après avoir détecté un impact dans une seule zone de disponibilité, l'étape suivante consiste à évacuer cette zone de disponibilité. L'évacuation doit atteindre deux résultats. Tout d'abord, vous souhaitez arrêter d'envoyer du travail vers la zone de disponibilité concernée. Cela peut signifier différentes choses selon les architectures. Dans le cas d'une charge de travail de type requête/réponse, cela signifierait empêcher que des requêtes HTTP ou gRPC provenant de vos clients ne soient envoyées à l'équilibreur de charge ou à d'autres ressources de la zone de disponibilité. Dans un système de traitement par lots ou de files d'attente, cela peut signifier l'arrêt des ressources informatiques pour traiter le travail dans la zone de disponibilité concernée. Vous devrez également empêcher les ressources des zones de disponibilité non affectées d'interagir avec les ressources de la zone de disponibilité affectée, par exemple, une instance EC2 envoyant du trafic vers un[point de terminaison VPC de l'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html)dans la zone de disponibilité concernée ou en se connectant à l'instance principale d'une base de données. Le deuxième résultat est d'empêcher le provisionnement de nouvelles capacités dans la zone de disponibilité affectée. Cela est important car les nouvelles ressources, telles que les instances ou les conteneurs EC2, mises à disposition dans la zone de disponibilité affectée sont susceptibles d'avoir le même impact que les ressources existantes. De plus, étant donné que le premier résultat empêche de leur envoyer du travail, ils ne peuvent pas absorber la charge pour laquelle ils ont été provisionnés. Cela entraîne une charge accrue sur les ressources existantes, ce qui peut finalement conduire à*brunir*ou une indisponibilité totale de la charge de travail. Plusieurs services de mise à l'échelle automatique sont disponibles dansAWSle cas échéant :[Mise à l'échelle automatique d'Amazon EC2](https://aws.amazon.com/ec2/autoscaling/),[Mise à l'échelle automatique des applications](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html), et[AWS Auto Scaling](https://aws.amazon.com/autoscaling/). En outre, des services tels qu'Amazon ECS, Amazon EKS et[AWS Batch](https://aws.amazon.com/batch/)peuvent planifier le travail sur les hôtes dans les zones de disponibilité d'un VPC dans le cadre de leur fonctionnement normal. **Topics** + [Indépendance de la zone de disponibilité](availability-zone-independence.md) + [Plans de contrôle et plans de données](control-planes-and-data-planes.md) + [Évacuation contrôlée par avion de données](data-plane-controlled-evacuation.md) + [Évacuation contrôlée par le plan de commande](control-plane-controlled-evacuation.md) + [Récapitulatif](evacuation-summary.md)