Tolérance aux pannes

Vérifie si vos équilibreurs de charge d'application sont configurés pour utiliser plus d'une zone de disponibilité (AZ). Une zone de disponibilité est un emplacement distinct isolé des défaillances dans d'autres zones. Configurez votre équilibreur de charge dans plusieurs zones de disponibilité de la même région afin d'améliorer la disponibilité de votre charge de travail.

c1dfprch08

Jaune : ALB se trouve dans une seule zone AZ.

Vert : ALB possède au moins deux AZ.

Assurez-vous que votre équilibreur de charge est configuré avec au moins deux zones de disponibilité.

Pour plus d'informations, consultez Zones de disponibilité pour votre Application Load Balancer.

Pour plus d’informations, consultez la documentation suivante :

Vérifie si le retour sur trace est activé sur un cluster Amazon Aurora MySQL.

Le retour sur trace de cluster Amazon Aurora MySQL est une fonctionnalité qui vous permet de restaurer un cluster de base de données Aurora à un point antérieur sans créer de nouveau cluster. Cela vous permet de restaurer votre base de données à un point donné au cours d'une période de conservation, sans utiliser d'instantané.

Vous pouvez ajuster la fenêtre de temps de retour en arrière (heures) dans le BacktrackWindowInHours paramètre des AWS Config règles.

Pour plus d'informations, consultez Retour en arrière d'un cluster de base de données Amazon Aurora.

c18d2gz131

AWS Config Managed Rule: aurora-mysql-backtracking-enabled

Jaune : le retour sur trace de clusters Amazon Aurora MySQL n'est pas activé.

Activez le retour sur trace pour votre cluster Amazon Aurora MySQL.

Pour plus d'informations, consultez Retour en arrière d'un cluster de base de données Amazon Aurora.

Retour sur trace d'un cluster de base de données Aurora

Vérifie les cas dans lesquels un cluster de base de données Amazon Aurora possède des instances privées et publiques.

En d'autres termes, si l'instance principale est défaillante, un réplica peut être promu comme l'instance principale. Si ce réplica est privé, les utilisateurs qui n'ont qu'un accès public ne pourront plus se connecter à la base de données après le basculement. Nous recommandons que toutes les instances de base de données d'un cluster aient la même accessibilité.

xuy7H1avtl

Jaune : les instances d'un cluster de base de données Aurora n'ont pas la même accessibilité (combinaison de public et de privé).

Modifiez le paramètre Publicly Accessible des instances du cluster de la base de données afin qu'elles soient toutes soit publiques soit privées. Pour plus de détails, consultez les instructions pour les instances MySQL sur Modification d'une instance de base de données exécutant le moteur de base de données MySQL.

Fault Tolerance for an Aurora DB Cluster (Tolérance aux pannes pour un cluster de base de données Aurora)

Vérifie qu'un groupe d'origine est configuré pour les distributions qui incluent deux origines dans Amazon CloudFront.

Pour plus d'informations, consultez Optimisation de la haute disponibilité avec le basculement CloudFront d'origine.

c18d2gz112

AWS Config Managed Rule: cloudfront-origin-failover-enabled

Jaune : le basculement Amazon CloudFront Origin n'est pas activé.

Assurez-vous d'activer la fonctionnalité de basculement d'origine pour vos CloudFront distributions afin de garantir la haute disponibilité de votre contenu aux utilisateurs finaux. Lorsque vous activez cette fonctionnalité, le trafic est automatiquement acheminé vers le serveur d'origine de secours si le serveur d'origine principal n'est pas disponible. Cela permet de limiter les temps d'arrêt potentiels et d'assurer la disponibilité continue de votre contenu.

Vérifie les autorisations de clé AWS Key Management Service (AWS KMS) pour un point de terminaison où le modèle sous-jacent a été chiffré à l'aide de clés gérées par le client. Si la clé gérée par le client est désactivée, ou si la politique de clé a été modifiée pour changer les autorisations autorisées pour Amazon Comprehend, la disponibilité du point de terminaison peut être affectée.

Cm24dfsM13

Rouge : la clé gérée par le client est désactivée, ou la politique de clé a été modifiée pour changer les autorisations autorisées pour l'accès à Amazon Comprehend.

Si la clé gérée par le client a été désactivée, nous vous recommandons de l'activer. Pour plus d'informations, consultez Activation des clés. Si la politique de clé a été modifiée et que vous souhaitez continuer à utiliser le point de terminaison, nous vous recommandons de mettre à jour la politique de AWS KMS clé. Consultez Modification d'une stratégie de clé pour de plus amples informations.

AWS KMS Autorisations

Vérifie si des clusters Amazon DocumentDB sont configurés comme Single-AZ.

L'exécution de charges de travail Amazon DocumentDB dans une Single-AZ architecture n'est pas suffisante pour les charges de travail hautement critiques et la restauration en cas de défaillance d'un composant peut prendre jusqu'à 10 minutes. Les clients doivent déployer des instances de réplication dans des zones de disponibilité supplémentaires pour garantir la disponibilité pendant la maintenance, les pannes d'instance, les pannes de composants ou les pannes de zone de disponibilité.

c15vnddn2x

Jaune : le cluster Amazon DocumentDB possède des instances dans moins de trois zones de disponibilité.

Vert : le cluster Amazon DocumentDB possède des instances dans trois zones de disponibilité.

Si votre application nécessite une haute disponibilité, modifiez votre instance de base de données pour activer Multi-AZ l'utilisation d'instances de réplication. Découvrez la haute disponibilité et la réplication d'Amazon DocumentDB

Comprendre la tolérance aux pannes des clusters Amazon DocumentDB

Régions et zones de disponibilité

Vérifie si la restauration à un instant dans le passe est activée pour vos tables Amazon DynamoDB.

Point-in time-recovery permet de protéger vos tables DynamoDB contre les opérations d'écriture ou de suppression accidentelles. Grâce à la restauration ponctuelle, vous n'avez pas à vous soucier de créer, de gérer ou de planifier des sauvegardes à la demande. Point-in time-recovery restaure les tables à n'importe quel moment au cours des 35 derniers jours. DynamoDB conserve des sauvegardes incrémentielles de votre table.

Pour plus d'informations, consultez la section Point-in-time restauration pour DynamoDB.

c18d2gz138

AWS Config Managed Rule: dynamodb-pitr-enabled

Jaune : Point-in-time la restauration n'est pas activée pour vos tables DynamoDB.

Activez la restauration à un instant dans le passé dans Amazon DynamoDB pour sauvegarder en permanence les données de vos tables.

Pour plus d'informations, consultez Point-in-time la section Restauration : comment ça fonctionne.

Point-in-time restauration pour DynamoDB

Vérifie si les tables Amazon DynamoDB font partie d'un AWS Backup plan.

AWS Backup fournit des sauvegardes incrémentielles pour les tables DynamoDB qui capturent les modifications apportées depuis la dernière sauvegarde. L'inclusion de tables DynamoDB dans un AWS Backup plan permet de protéger vos données contre les scénarios de perte de données accidentelle et d'automatiser le processus de sauvegarde. Cela fournit une solution de sauvegarde fiable et évolutive pour vos tables DynamoDB, assurant ainsi la protection de vos précieuses données et leur restauration selon les besoins.

Pour plus d'informations, voir Création de sauvegardes de tables DynamoDB avec AWS Backup

c18d2gz107

AWS Config Managed Rule: dynamodb-in-backup-plan

Jaune : le tableau Amazon DynamoDB n'est pas inclus dans le AWS Backup forfait.

Assurez-vous que vos tables Amazon DynamoDB font partie d'un AWS Backup plan.

Sauvegardes planifiées

Qu'est-ce que c'est AWS Backup ?

Création de plans de sauvegarde à l'aide de la console AWS Backup

Vérifie si les volumes Amazon EBS sont présents dans les plans de sauvegarde pour AWS Backup.

Incluez les volumes Amazon EBS dans un AWS Backup plan visant à automatiser les sauvegardes régulières des données stockées sur ces volumes. Cela vous protège contre les pertes de données, facilite la gestion des données et permet leur restauration en cas de besoin. Un plan de sauvegarde permet de garantir la sécurité de vos données et de vous assurer que vous êtes en mesure de respecter les objectifs de temps et de points de restauration (RTO/RPO) pour votre application et vos services.

Pour plus d'informations, voir Création d'un plan de sauvegarde.

c18d2gz106

AWS Config Managed Rule: ebs-in-backup-plan

Jaune : le volume Amazon EBS n'est pas inclus dans le AWS Backup forfait.

Assurez-vous que vos volumes Amazon EBS font partie d'un AWS Backup plan.

Création de plans de sauvegarde à l'aide de la AWS Backup console

Qu'est-ce que c'est AWS Backup ?

Mise en route 3 : création d'une sauvegarde planifiée

Vérifie l'âge des instantanés de vos volumes Amazon EBS (disponibles ou en cours d'utilisation). Des défaillances peuvent survenir même si les volumes Amazon EBS sont répliqués. Les instantanés sont conservés sur Amazon S3 pour un stockage durable et une restauration instantanée.

H7IgTzjTYb

Créez des instantanés hebdomadaires ou mensuels de vos volumes. Pour plus d'informations, consultez Creating an Amazon EBS Snapshot (Création d'un instantané Amazon EBS).

Pour automatiser la création de snapshots EBS, vous pouvez envisager d'utiliser AWS Backup Amazon Data Lifecycle Manager.

Amazon Elastic Block Store (Amazon EBS)

Instantanés Amazon EBS

AWS Backup

Amazon Data Lifecycle Manager

Vérifie si vos groupes Amazon EC2 Auto Scaling associés à un Classic Load Balancer utilisent la surveillance de l'état Elastic Load Balancing. La surveillance de l'état par défaut d'un groupe Auto Scaling correspond uniquement à la surveillance de l'état Amazon EC2. Si une instance échoue lors de ces contrôles d'état, elle est marquée comme défectueuse et terminée. Dans ce cas, Amazon EC2 Auto Scaling lance une instance de remplacement. La surveillance de l'état Elastic Load Balancing surveille régulièrement les instances Amazon EC2 afin de détecter et de terminer les instances défectueuses, puis de lancer de nouvelles instances.

Pour plus d'informations, voir Ajouter des bilans de santé d'Elastic Load Balancing.

c18d2gz104

AWS Config Managed Rule: autoscaling-group-elb-healthcheck-required

Jaune : la surveillance de l'état Elastic Load Balancing n'est pas activée pour le groupe Amazon EC2 Auto Scaling attaché au Classic Load Balancer.

Assurez-vous que vos groupes Auto Scaling associés à un Classic Load Balancer utilisent la surveillance de l'état Elastic Load Balancing.

La surveillance de l'état Elastic Load Balancing indique si l'équilibreur de charge est sain et disponible pour traiter les demandes. Cela assure une haute disponibilité pour votre application.

Pour plus d'informations, voir Ajout de la surveillance d'état Elastic Load Balancing à un groupe Auto Scaling.

Vérifie si le rééquilibrage de capacité est activé pour les groupes Amazon EC2 Auto Scaling qui utilisent plusieurs types d'instances.

La configuration des groupes Amazon EC2 Auto Scaling avec le rééquilibrage de capacité permet de s'assurer que les instances Amazon EC2 sont réparties uniformément entre les zones de disponibilité, quels que soient le type d'instance et les options d'achat. Elle utilise une politique de suivi des cibles associée au groupe, telle que l'utilisation de l'UC ou le trafic réseau.

Pour plus d'informations, voir Groupes Auto Scaling avec plusieurs types d'instances et d'options d'achat.

AWS Config c18d2gz103

AWS Config Règle gérée : rééquilibrage automatique des capacités

Le rééquilibrage de capacité n'est pas activé pour le groupe Amazon EC2 Auto Scaling.

Assurez-vous que le rééquilibrage de capacité est activé pour vos groupes Amazon EC2 Auto Scaling qui utilisent plusieurs types d'instances.

Pour plus d'informations, voir Activation du rééquilibrage de capacité (console).

Vérifie si le groupe Amazon EC2 Auto Scaling est déployé dans plusieurs zones de disponibilité ou si le nombre minimal de zones de disponibilité est spécifié. Déployez des instances Amazon EC2 dans plusieurs zones de disponibilité pour assurer une haute disponibilité.

Vous pouvez ajuster le nombre minimum de zones de disponibilité à l'aide du AvailibilityZones paramètre min de vos AWS Config règles.

Pour plus d'informations, voir Groupes Auto Scaling avec plusieurs types d'instances et d'options d'achat.

c18d2gz101

AWS Config Managed Rule: autoscaling-multiple-az

Rouge : plusieurs zones de disponibilité ne sont pas configurées pour le groupe Amazon EC2 Auto Scaling ou le nombre minimal de zones de disponibilité spécifié n'est pas atteint.

Assurez-vous que plusieurs zones de disponibilité sont configurées pour votre groupe Amazon EC2 Auto Scaling. Déployez des instances Amazon EC2 dans plusieurs zones de disponibilité pour assurer une haute disponibilité.

Création d'un groupe Auto Scaling à l'aide d'un modèle de lancement

Création d'un groupe Auto Scaling à l'aide d'une configuration de lancement

Vérifie la distribution des instances Amazon Elastic Compute Cloud (Amazon EC2) dans les zones de disponibilité d'une région.

Les zones de disponibilité sont des emplacements distincts dans une région, isolés des échecs dans d'autres zones de disponibilité. Cela permet d'avoir une connectivité réseau économique à faible latence entre les zones de disponibilité de la même région. En lançant des instances dans plusieurs zones de disponibilité d'une même région, vous pouvez protéger vos applications contre l'échec d'une zone.

wuy7G1zxql

Équilibrez uniformément vos instances Amazon EC2 sur plusieurs zones de disponibilité. Vous pouvez le faire en lançant des instances manuellement ou en utilisant Auto Scaling pour le faire automatiquement. Pour de plus amples informations, veuillez consulter Launch Your Instance (Lancer votre instance) et Load Balance Your Auto Scaling group (Répartir la charge de votre groupe Auto Scaling).

Vérifie si la surveillance détaillée est activée pour vos instances EC2.

Par exemple, la surveillance détaillée pour Amazon EC2 fournit des métriques plus fréquentes, publiées à intervalles d'une minute, contre cinq minutes pour la surveillance basique pour Amazon EC2. L'utilisation de la surveillance détaillée pour Amazon EC2 vous aide à mieux gérer vos ressources Amazon EC2, de sorte que vous puissiez identifier les tendances et agir plus rapidement.

Pour plus d'informations, voir Surveillance basique et surveillance détaillée.

AWS Config c18d2gz144

AWS Config Règle gérée : ec2-instance-detailed-monitoring-enabled

Jaune : la surveillance détaillée n'est pas activée pour les instances Amazon EC2.

Activez la surveillance détaillée de vos instances Amazon EC2 afin d'augmenter la fréquence à laquelle les données métriques Amazon EC2 sont publiées sur Amazon CloudWatch (de 5 à 1 minute d'intervalle).

Vérifie les définitions de tâches Amazon ECS qui sont activement utilisées par l'exécution de tâches ou qui figurent parmi les 5 révisions les plus récentes par famille de définitions de tâches, configurées avec le pilote de journalisation AWS des journaux en mode blocage. Un pilote configuré en mode blocage met en danger la disponibilité du système.

Cette vérification ne prend pas en compte les paramètres de configuration du pilote au niveau du compte.

c1dvkm4z6b

Jaune : le mode des paramètres de configuration de la journalisation du pilote awslogs est réglé sur blocage.

Vert : la définition des tâches Amazon ECS n'utilise pas le pilote awslogs ou le pilote awslogs est configuré en mode non bloquant.

Pour atténuer le risque de disponibilité, envisagez de modifier la définition de tâche La configuration du pilote AWS Logs, qui passe du mode bloquant au mode non bloquant. En mode non bloquant, vous devrez définir une valeur pour le paramètre max-buffer-size. Pour plus d'informations et de conseils sur les paramètres de configuration, consultez la section Prévention de la perte de AWS journaux en mode non bloquant dans le pilote de journal du conteneur Logs.

Utilisation du pilote AWS Logs Log

Choix des options d'enregistrement des conteneurs pour éviter la contre-pression

Prévention de la perte de journaux grâce au mode non bloquant du pilote de AWS journal du conteneur Logs

Vérifie que la configuration de votre service utilise une seule zone de disponibilité (AZ).

Une zone de disponibilité est un emplacement distinct isolé des défaillances dans d'autres zones. Cela permet d'avoir une connectivité réseau économique à faible latence entre les zones de disponibilité d'une même Région AWS. En lançant des instances dans plusieurs zones de disponibilité d'une même région, vous pouvez protéger vos applications contre un point unique de défaillance.

c1z7dfpz01

Créez au moins une tâche supplémentaire pour le service dans une zone de disponibilité différente.

Capacité et disponibilité d'Amazon ECS

Vérifie que votre service Amazon ECS utilise la stratégie de placement par répartition basée sur la zone de disponibilité (AZ). Cette stratégie répartit les tâches entre les zones de disponibilité de la même manière Région AWS et peut contribuer à protéger vos applications contre un point de défaillance unique.

Pour les tâches exécutées dans le cadre d'un service Amazon ECS, la répartition constitue la stratégie de placement des tâches par défaut.

Ce contrôle permet également de vérifier que la répartition est la première ou la seule stratégie dans votre liste de stratégies de placement actives.

c1z7dfpz02

Activez la stratégie de répartition des tâches pour répartir les tâches entre plusieurs zones de disponibilité. Vérifiez que la répartition par zone de disponibilité est la première ou la seule stratégie de placement de tâches active utilisée. Si vous choisissez de gérer le placement dans les zones de disponibilité, vous pouvez utiliser un service de mise en miroir dans une autre zone de disponibilité pour limiter ces risques.

Stratégies de placement des tâches Amazon ECS

Vérifie si des cibles de montage existent dans plusieurs zones de disponibilité d'un système de fichiers Amazon EFS.

Une zone de disponibilité est un emplacement distinct isolé des défaillances dans d'autres zones. La création de cibles de montage dans plusieurs zones de disponibilité géographiquement séparées au sein d'une même région AWS vous permet d'obtenir une disponibilité et une durabilité supérieures pour vos systèmes de fichiers Amazon EFS.

c1dfprch01

Pour les systèmes de fichiers EFS utilisant des classes de stockage unizones, nous vous recommandons de créer de nouveaux systèmes de fichiers utilisant des classes de stockage standard en restaurant une sauvegarde sur un nouveau système de fichiers. Créez ensuite des cibles de montage dans plusieurs zones de disponibilité.

Pour les systèmes de fichiers EFS utilisant des classes de stockage standard, nous vous recommandons de créer des cibles de montage dans plusieurs zones de disponibilité.

Vérifie si les systèmes de fichiers Amazon EFS sont inclus dans les plans de sauvegarde avec AWS Backup.

AWS Backup est un service de sauvegarde unifié conçu pour simplifier la création, la migration, la restauration et la suppression des sauvegardes, tout en fournissant des rapports et des audits améliorés.

Pour plus d'informations, consultez Backing up your Amazon EFS file systems (Sauvegarde de vos systèmes de fichiers Amazon EFS).

c18d2gz117

AWS Config Managed Rule: EFS_IN_BACKUP_PLAN

Rouge : les systèmes de fichiers Amazon EFS ne sont pas inclus dans le AWS Backup forfait.

Assurez-vous que vos systèmes de fichiers Amazon EFS sont inclus dans votre AWS Backup plan afin de vous protéger contre la perte ou la corruption accidentelles de données.

Sauvegarde de vos systèmes de fichiers Amazon EFS

Sauvegarde et restauration d'Amazon EFS à l'aide de AWS Backup.

Vérifie les ElastiCache clusters qui se déploient dans une seule zone de disponibilité (AZ). Ce check vous alerte s'il Multi-AZ est inactif dans un cluster.

Les déploiements dans plusieurs zones de zone de disponibilité améliorent la disponibilité des ElastiCache clusters en effectuant une réplication asynchrone vers des répliques en lecture seule dans une zone de disponibilité différente. Lorsqu'une maintenance planifiée du cluster a lieu ou qu'un nœud primaire n'est pas disponible, ElastiCache convertit automatiquement un réplica en nœud primaire. Ce basculement permet de reprendre les opérations d'écriture du cluster et ne nécessite pas l'intervention d'un administrateur.

ECHdfsQ402

Créez au moins un réplica par partition, dans une zone de disponibilité différente de la principale.

Pour plus d'informations, consultez Minimiser les temps d'arrêt dans ElastiCache (Redis OSS) avec Multi-AZ.

Vérifie si la sauvegarde automatique est activée sur les clusters Amazon ElastiCache (Redis OSS) et si la période de conservation des instantanés est supérieure à la limite spécifiée ou à la limite par défaut de 15 jours. Lorsque les sauvegardes automatiques sont activées, ElastiCache crée une sauvegarde quotidienne du cluster.

Vous pouvez spécifier la limite de conservation des instantanés souhaitée à l'aide des RetentionPeriod paramètres de capture d'écran de vos AWS Config règles.

Pour plus d'informations, consultez la section Sauvegarde et restauration pour ElastiCache (Redis OSS).

c18d2gz178

AWS Config Managed Rule: elasticache-redis-cluster-automatic-backup-check

Rouge : la sauvegarde automatique des clusters Amazon ElastiCache (Redis OSS) n'est pas activée ou la période de conservation des instantanés est inférieure à la limite.

Assurez-vous que la sauvegarde automatique est activée sur les clusters Amazon ElastiCache (Redis OSS) et que la période de conservation des instantanés est supérieure à la limite spécifiée ou à la limite par défaut de 15 jours. Les sauvegardes automatiques peuvent constituer une protection contre la perte de données. En prévision d'une éventuelle défaillance, vous pouvez créer un cluster et restaurer vos données à partir de la sauvegarde la plus récente.

Pour plus d'informations, consultez la section Sauvegarde et restauration pour ElastiCache (Redis OSS).

Pour plus d'informations, voir Planification des sauvegardes automatiques.

Vérifie les clusters MemoryDB déployés dans une zone de disponibilité (AZ). Ce check vous alerte s'il Multi-AZ est inactif dans un cluster.

Les déploiements dans plusieurs AZ améliorent la disponibilité des clusters MemoryDB en répliquant de manière asynchrone vers des réplicas en lecture seule dans une autre AZ. Lorsqu'une maintenance planifiée du cluster a lieu ou qu'un nœud primaire n'est pas disponible, MemoryDB convertit automatiquement un réplica en nœud primaire. Ce basculement permet de reprendre les opérations d'écriture du cluster et ne nécessite pas l'intervention d'un administrateur.

MDBdfsQ401

Créez au moins un réplica par partition, dans une zone de disponibilité différente de la principale.

Pour plus d'informations, consultez la section Minimiser les temps d'arrêt dans MemoryDB avec. Multi-AZ

Vérifie que le nombre de partitions attribuées aux agents d'un cluster Managed Streaming for Kafka (MSK) respecte la limite recommandée.

Cmsvnj8vf1

Suivez les bonnes pratiques recommandées en matière de MSK pour mettre à l'échelle votre cluster MSK ou supprimer les partitions inutilisées.

Vérifie le nombre de zones de disponibilité (AZ) pour votre cluster provisionné Amazon MSK. Le cluster Amazon MSK est composé de plusieurs courtiers qui travaillent ensemble et distribuent les données et le chargement. La production peut être interrompue en cas de maintenance ou de problèmes de courtage dans un cluster 2-AZ.

90046ff5b5

Pour augmenter la disponibilité du cluster, vous pouvez créer un autre cluster dans une configuration à 3 AZs. Migrez ensuite le cluster existant vers le nouveau cluster que vous avez créé. Vous pouvez utiliser la réplication Amazon MSK pour cette migration.

Haute disponibilité d'Amazon MSK

Migration vers Amazon MSK

Vérifie si les domaines Amazon OpenSearch Service sont configurés avec au moins trois nœuds de données et si ZoneAwarenessEnabled c'est vrai. ZoneAwarenessEnabled Lorsque cette option est activée, Amazon OpenSearch Service garantit que chaque partition principale et sa réplique correspondante sont allouées dans différentes zones de disponibilité.

Pour plus d'informations, consultez Configuration d'un domaine multi-AZ dans Amazon OpenSearch Service.

c18d2gz183

AWS Config Managed Rule: opensearch-data-node-fault-tolerance

Jaune : les domaines Amazon OpenSearch Service sont configurés avec moins de trois nœuds de données.

Assurez-vous que les domaines Amazon OpenSearch Service sont configurés avec au moins trois nœuds de données. Configurez un domaine multi-AZ pour améliorer la disponibilité du cluster Amazon OpenSearch Service en allouant des nœuds et en répliquant les données dans trois zones de disponibilité au sein de la même région. Cela évite la perte de données et limite les temps d'arrêt en cas de défaillance d'un nœud ou du centre de données (AZ).

Pour plus d'informations, voir Augmenter la disponibilité d'Amazon OpenSearch Service en déployant dans trois zones de disponibilité.

Vérifie les sauvegardes automatiques des instances de base de données Amazon RDS.

Par défaut, les sauvegardes sont activées avec une période de rétention d'un jour. Les sauvegardes réduisent le risque de perte de données inattendue et permettent d'effectuer une restauration à un instant dans le passé.

opQPADkZvH

Rouge : la période de conservation des sauvegardes d'une instance de base de données est définie sur 0 jours.

Définissez la période de conservation des sauvegardes automatisées de l'instance de base de données sur 1 à 35 jours, en fonction des exigences de votre application. Consultez Working With Automated Backups (Utilisation des sauvegardes automatiques).

Getting Started with Amazon RDS (Démarrer avec Amazon RDS)

Vérifie si une instance Amazon RDS est activée avec des sauvegardes automatisées à l'aide d'Amazon RDS ou avec des sauvegardes continues de AWS Backup. Les sauvegardes continues réduisent le risque de perte de données imprévue et permettent une restauration instantanée.

44fde09ab5

Assurez-vous que la sauvegarde automatique des instances Amazon RDS est configurée soit en définissant une période de rétention supérieure à 0 dans Amazon RDS, soit en créant un plan de sauvegarde continue à l'aide de AWS Backup.

Ajoutez au moins une autre instance de base de données au cluster de bases de données pour améliorer la disponibilité et les performances.

c1qf5bt011

Jaune : les clusters de bases de données ne possèdent qu'une seule instance de base de données.

Ajoutez une instance de base de données de lecteur au cluster de bases de données.

Dans la configuration actuelle, une instance de base de données est utilisée à la fois pour les opérations de lecture et d'écriture. Vous pouvez ajouter une autre instance de base de données pour permettre la redistribution des lectures et une option de basculement.

Pour plus d'informations, consultez la section Haute disponibilité pour Amazon Aurora.

Les clusters de bases de données se trouvent actuellement dans une seule zone de disponibilité. Utilisez plusieurs zones de disponibilité pour améliorer la disponibilité.

c1qf5bt007

Jaune : les clusters de bases de données ont toutes les instances dans la même zone de disponibilité.

Ajoutez les instances de base de données à plusieurs zones de disponibilité de votre cluster de bases de données.

Nous vous recommandons d'ajouter les instances de base de données à plusieurs zones de disponibilité d'un cluster de bases de données. L'ajout d'instances de base de données à plusieurs zones de disponibilité améliore la disponibilité de votre cluster de bases de données.

Pour plus d'informations, consultez la section Haute disponibilité pour Amazon Aurora.

Votre cluster de base de données a toutes les instances de lecteur dans la même zone de disponibilité. Nous vous recommandons de répartir les instances de Reader dans plusieurs zones de disponibilité de votre cluster de bases de données.

La distribution augmente la disponibilité de la base de données et améliore le temps de réponse en réduisant la latence du réseau entre les clients et la base de données.

c1qf5bt018

Rouge : les instances de lecture des clusters de bases de données se trouvent dans la même zone de disponibilité.

Répartissez les instances du lecteur dans plusieurs zones de disponibilité.

Les zones de disponibilité (AZ) sont des emplacements distincts les uns des autres afin de fournir une isolation en cas de panne dans chaque AWS région. Nous vous recommandons de répartir l’instance principale et les réplicas et les instances de lecteur de votre cluster de bases de données sur plusieurs zones de disponibilité afin d’améliorer la disponibilité de votre cluster de bases de données. Vous pouvez créer un Multi-AZ cluster à l'aide de l' Console de gestion AWS API Amazon RDS ou de l'API Amazon RDS lorsque vous créez le cluster. AWS CLI Vous pouvez modifier le cluster Aurora existant en Multi-AZ cluster en ajoutant une nouvelle instance de lecteur et en spécifiant une autre AZ.

Pour plus d'informations, consultez la section Haute disponibilité pour Amazon Aurora.

Vérifie si la surveillance améliorée est activée pour vos instances de base de données Amazon RDS.

La surveillance améliorée d'Amazon RDS fournit des métriques en temps réel pour le système d'exploitation sur lequel votre instance de base de données s'exécute. Vous pouvez afficher toutes les métriques système et les informations de processus pour vos instances de base de données Amazon RDS sur la console Amazon RDS. Vous pouvez également personnaliser le tableau de bord. Grâce à la surveillance améliorée, vous avez une visibilité sur l'état de fonctionnement de votre instance Amazon RDS en temps quasi réel, ce qui vous permet de répondre aux problèmes opérationnels plus rapidement.

Vous pouvez spécifier l'intervalle de surveillance souhaité à l'aide du paramètre MonitoringInterval de vos règles. AWS Config

Pour plus d'informations, voir Vue d'ensemble de la surveillance améliorée et Métriques du système d'exploitation dans la surveillance améliorée.

c18d2gz158

AWS Config Managed Rule: rds-enhanced-monitoring-enabled

Jaune : la surveillance améliorée n'est pas activée ou l'intervalle souhaité n'est pas configuré pour vos instances de base de données Amazon RDS.

Activez la surveillance améliorée pour vos instances de base de données Amazon RDS afin d'améliorer la visibilité sur l'état de fonctionnement de vos instances Amazon RDS.

Pour plus d'informations, voir Surveillance des métriques du système d'exploitation à l'aide de la surveillance améliorée.

Métriques du système d'exploitation dans la surveillance améliorée

La mise à l'échelle automatique du stockage Amazon RDS n'est pas activée pour votre instance de base de données. En cas d'augmentation de la charge de travail de la base de données, la mise à l'échelle automatique de RDS Storage adapte automatiquement la capacité de stockage sans interruption.

c1qf5bt013

Rouge : la mise à l'échelle automatique du stockage n'est pas activée sur les instances de base de données.

Activez la mise à l'échelle automatique du stockage Amazon RDS avec un seuil de stockage maximum spécifié.

La mise à l'échelle automatique du stockage Amazon RDS fait automatiquement évoluer la capacité de stockage sans interruption lorsque la charge de travail de la base de données augmente. La mise à l'échelle automatique du stockage surveille l'utilisation du stockage et augmente automatiquement la capacité lorsque l'utilisation est proche de la capacité de stockage provisionnée. Vous pouvez spécifier une limite maximale au stockage qu'Amazon RDS peut allouer à l'instance de base de données. La mise à l'échelle automatique du stockage n'entraîne aucun coût supplémentaire. Vous ne payez que pour les ressources Amazon RDS allouées à votre instance de base de données. Nous vous recommandons d'activer la mise à l'échelle automatique du stockage Amazon RDS.

Pour plus d'informations, consultez Gestion automatique de la capacité avec la scalabilité automatique du stockage Amazon RDS.

Nous vous recommandons d'utiliser Multi-AZ le déploiement. Les Multi-AZ déploiements améliorent la disponibilité et la durabilité de l'instance de base de données.

c1qf5bt019

Jaune : les instances de base de données n'utilisent pas Multi-AZ le déploiement.

Configurez Multi-AZ pour les instances de base de données concernées.

Dans un Multi-AZ déploiement Amazon RDS, Amazon RDS crée automatiquement une instance de base de données principale et réplique les données vers une instance située dans une zone de disponibilité différente. Lorsqu'il détecte une panne, Amazon RDS bascule automatiquement vers une instance de secours sans intervention manuelle.

Pour plus d’informations, consultez Tarification.

Vérifie si la CloudWatch métrique DiskQueueDepth indique que le nombre d'écritures en file d'attente dans le stockage de la base de données de l'instance RDS a atteint un niveau tel qu'une enquête opérationnelle devrait être suggérée.

Cmsvnj8db3

Envisagez de passer à des instances et à des volumes de stockage qui prennent en charge ces read/write caractéristiques.

Vérifie si la FreeStorageSpace CloudWatch métrique d'une instance de base de données RDS est tombée en dessous d'un seuil raisonnable du point de vue opérationnel.

Cmsvnj8db2

Augmentez l'espace de stockage pour l'instance de base de données RDS dont l'espace de stockage disponible est insuffisant à l'aide de la console de gestion Amazon RDS, de l'API Amazon RDS ou de l'interface de ligne de commande AWS.

Lorsque log_output est défini sur TABLE, davantage de stockage est utilisé que lorsque log_output est défini sur FILE. Nous vous recommandons de définir le paramètre sur FILE pour éviter d'atteindre la limite de taille de stockage.

c1qf5bt023

Jaune : le paramètre log_output des groupes de paramètres DB est défini sur TABLE.

Définissez la valeur du paramètre log_output sur FILE dans vos groupes de paramètres de base de données.

Pour plus d'informations, consultez les fichiers journaux de la base de données MySQL.

Votre instance de base de données rencontre un problème connu : une table créée dans une version de MySQL inférieure à 8.0.26 avec le row_format défini sur COMPACT ou REDUNDANT est inaccessible et irrécupérable lorsque l'index dépasse 767 octets.

Nous vous recommandons de définir la valeur du paramètre innodb_default_row_format sur DYNAMIC.

c1qf5bt036

Rouge : les groupes de paramètres de base de données ont un paramètre non sécurisé pour le paramètre innodb_default_row_format.

Définissez le paramètre innodb_default_row_format sur DYNAMIC.

Lorsqu'une table est créée avec une version de MySQL inférieure à 8.0.26 avec row_format défini sur COMPACT ou REDUNDANT, la création d'index avec un préfixe clé inférieur à 767 octets n'est pas imposée. Après le redémarrage de la base de données, il est impossible d'accéder à ces tables ou de les récupérer.

Pour plus d'informations, consultez les modifications apportées à MySQL 8.0.26 (20/07/2021, disponibilité générale) n sur le site Web de documentation MySQL.

La valeur du paramètre innodb_flush_log_at_trx_commit de votre instance de base de données n'est pas une valeur sûre. Ce paramètre contrôle la persistance des opérations de validation sur le disque.

Nous vous recommandons de définir le paramètre innodb_flush_log_at_trx_commit sur 1.

c1qf5bt030

Jaune : innodb_flush_log_at_trx_commit est défini sur une valeur différente de 1 pour les groupes de paramètres de base de données.

Définissez la valeur du paramètre innodb_flush_log_at_trx_commit sur 1

La transaction de base de données est durable lorsque la mémoire tampon du journal est enregistrée dans le stockage durable. Toutefois, l'enregistrement sur disque a un impact sur les performances. En fonction de la valeur définie pour le paramètre innodb_flush_log_at_trx_commit, le comportement d'écriture et d'enregistrement des journaux sur le disque peut varier.

Pour plus d’informations, consultez Best practices for configuring parameters for Amazon RDS for MySQL, part 1: Parameters related to performance.

Votre instance de base de données a une valeur faible pour le nombre maximal de connexions simultanées pour chaque compte de base de données.

Nous vous recommandons de définir le paramètre max_user_connections sur une valeur supérieure à 5.

c1qf5bt034

Jaune : max_user_connections est mal configuré pour les groupes de paramètres de base de données.

Augmentez la valeur du paramètre max_user_connections à un nombre supérieur à 5.

Le paramètre max_user_connections contrôle le nombre maximum de connexions simultanées autorisées pour un compte utilisateur MySQL. L'atteinte de cette limite de connexion entraîne des échecs dans les opérations d'administration de l'instance Amazon RDS, telles que la sauvegarde, l'application de correctifs et la modification des paramètres.

Pour plus d'informations, consultez la section Définition des limites de ressources du compte sur le site Web de documentation MySQL.

Vérifie les instances de base de données déployées dans une seule zone de disponibilité (AZ).

Multi-AZ les déploiements améliorent la disponibilité des bases de données en effectuant une réplication synchrone vers une instance de secours située dans une autre zone de disponibilité. Au cours de la maintenance planifiée de la base de données ou en cas d'échec d'une instance de base de données ou d'une zone de disponibilité, Amazon RDS passe automatiquement à l'instance de secours. Ce basculement permet de reprendre rapidement les opérations de base de données sans intervention administrative. Amazon RDS ne prenant pas en charge Multi-AZ le déploiement de Microsoft SQL Server, cette vérification n'examine pas les instances de SQL Server.

f2iK5R6Dep

Jaune : une instance de base de données est déployée dans une seule zone de disponibilité.

Si votre application nécessite une haute disponibilité, modifiez votre instance de base de données pour permettre Multi-AZ le déploiement. Voir Haute disponibilité (Multi-AZ).

Régions et zones de disponibilité

Vérifie si vos instances de base de données Amazon RDS sont incluses dans un plan de sauvegarde dans AWS Backup.

AWS Backup est un service de sauvegarde entièrement géré qui facilite la centralisation et l'automatisation de la sauvegarde des données entre les AWS services.

L'ajout de votre instance de base de données Amazon RDS à un plan de sauvegarde est important au regard des obligations de conformité réglementaire, de la reprise après sinistre, des politiques de l'entreprise en matière de protection des données et des objectifs de continuité des activités.

Pour plus d'informations, voir Qu'est-ce que AWS Backup ?.

c18d2gz159

AWS Config Managed Rule: rds-in-backup-plan

Jaune : une instance de base de données Amazon RDS n'est pas incluse dans un plan de sauvegarde avec AWS Backup.

Incluez vos instances de bases de données Amazon RDS dans un plan de sauvegarde avec AWS Backup.

Pour plus d'informations, voir Sauvegarde et restauration d'Amazon RDS à l'aide d'AWS Backup.

Affectation de ressources à un plan de sauvegarde

Le réplica en lecture de votre instance de base de données est en mode accessible en écriture, ce qui autorise les mises à jour depuis les clients.

Nous vous recommandons de définir le paramètre read_only pour TrueIfReplica que les répliques lues ne soient pas en mode écriture.

c1qf5bt035

Jaune : les groupes de paramètres DB activent le mode inscriptible pour les répliques en lecture.

Définissez la valeur du paramètre read_only sur. TrueIfReplica

Le paramètre read_only contrôle l'autorisation d'écriture des clients sur une instance de base de données. La valeur par défaut de ce paramètre est TrueIfReplica. Pour une instance de réplication, TrueIfReplica définit la valeur read_only sur ON (1) et désactive toute activité d'écriture des clients. Pour une master/writer instance, TrueIfReplica définit la valeur sur OFF (0) et active l'activité d'écriture des clients pour l'instance. Lorsque la réplique en lecture est ouverte en mode inscriptible, les données stockées dans cette instance peuvent diverger de celles de l'instance principale, ce qui entraîne des erreurs de réplication.

Pour plus d'informations, consultez la section Meilleures pratiques pour configurer les paramètres d'Amazon RDS pour MySQL, partie 2 : Paramètres liés à la réplication sur le site Web de documentation MySQL.

Les sauvegardes automatiques sont désactivées sur vos ressources de base de données. Les sauvegardes automatiques garantissent une restauration à un instant dans le passé de votre instance de bases de données.

c1qf5bt001

Rouge : les sauvegardes automatiques des ressources Amazon RDS ne sont pas activées

Activez les sauvegardes automatiques avec une période de conservation allant jusqu’à 14 jours.

Les sauvegardes automatisées permettent la restauration instantanée de vos instances de bases de données. Nous vous recommandons d'activer les sauvegardes automatiques. Lorsque vous activez les sauvegardes automatiques pour une instance de base de données, Amazon RDS effectue automatiquement une sauvegarde complète de vos données tous les jours pendant la fenêtre de sauvegarde de votre choix. La sauvegarde capture les journaux de transactions lorsque des mises à jour sont apportées à votre instance de base de données. Vous bénéficiez d'un espace de stockage de sauvegarde correspondant à la taille de stockage de votre instance de base de données sans frais supplémentaires.

Pour plus d’informations, consultez les ressources suivantes :

La synchronisation du journal binaire sur le disque n’est pas appliquée avant la confirmation de la validation de la transaction dans votre instance de base de données.

Nous vous recommandons de définir la valeur du paramètre sync_binlog sur 1.

c1qf5bt031

Jaune : la journalisation binaire synchrone des groupes de paramètres DB est désactivée.

Définissez le paramètre sync_binlog sur 1.

Le paramètre sync_binlog contrôle la manière dont MySQL envoie le journal binaire sur le disque. Lorsque la valeur de ce paramètre est définie sur 1, la synchronisation des journaux binaires sur le disque est activée avant que les transactions ne soient validées. Lorsque la valeur de ce paramètre est définie sur 0, la synchronisation du journal binaire avec le disque est désactivée. Généralement, le serveur MySQL dépend du système d'exploitation pour envoyer régulièrement le journal binaire sur le disque, de la même manière que les autres fichiers. La valeur du paramètre sync_binlog définie sur 0 peut améliorer les performances. Cependant, en cas de panne de courant ou de panne du système d'exploitation, le serveur perd toutes les transactions validées qui n'étaient pas synchronisées avec les journaux binaires.

Pour plus d'informations, consultez la section Meilleures pratiques pour configurer les paramètres d'Amazon RDS pour MySQL, partie 2 : Paramètres liés à la réplication.

Vérifie si la Multi-AZ réplication est activée sur vos clusters de bases de données Amazon RDS.

Un Multi-AZ cluster de bases de données possède une instance de base de données d'écriture et deux instances de base de données de lecture dans trois zones de disponibilité distinctes. Multi-AZ Les clusters de bases de données offrent une haute disponibilité, une capacité accrue pour les charges de travail de lecture et une latence plus faible par rapport aux Multi-AZ déploiements.

Pour plus d'informations, consultez Création d'un Multi-AZ cluster de bases de données.

c18d2gz161

AWS Config Managed Rule: rds-cluster-multi-az-enabled

Jaune : la Multi-AZ réplication n'est pas configurée pour votre cluster de bases de données Amazon RDS

Activez le déploiement d'un Multi-AZ cluster de bases de données lorsque vous créez un cluster de bases de données Amazon RDS.

Pour plus d'informations, consultez Création d'un Multi-AZ cluster de bases de données.

Multi-AZ déploiements de clusters de bases de données

Vérifie si une réplique de Multi-AZ secours est configurée pour vos instances de base de données Amazon RDS.

Amazon RDS Multi-AZ assure la haute disponibilité et la durabilité des instances de base de données en répliquant les données vers une réplique de secours située dans une zone de disponibilité différente. Cela permet un basculement automatique et améliore les performances et la durabilité des données. Lors du déploiement d'une Multi-AZ instance de base de données, Amazon RDS provisionne et gère automatiquement une réplique de secours synchrone dans une zone de disponibilité différente. L'instance de base de données primaire est répliquée de manière synchrone dans les zones de disponibilité sur un réplica de secours afin d'assurer une redondance des données et de limiter les pics de latence lors des sauvegardes système. L'exécution d'une instance de base de données haute disponibilité peut améliorer la disponibilité lors de la maintenance planifiée du système. Elle peut également contribuer à protéger vos bases de données contre la défaillance d'une instance de base de données et la perturbation d'une zone de disponibilité.

Pour plus d'informations, consultez la section Déploiements Multi-AZ d'instances de base de données.

c18d2gz156

AWS Config Managed Rule: rds-multi-az-support

Jaune : aucune Multi-AZ réplique n'est configurée pour une instance de base de données Amazon RDS.

Activez le Multi-AZ déploiement lorsque vous créez une instance de base de données Amazon RDS.

Cette vérification ne peut pas être exclue de l'affichage dans la Trusted Advisor console.

Multi-AZ Déploiements d'instances DB

Vérifie si la ReplicaLag CloudWatch métrique d'une instance de base de données RDS a dépassé un seuil raisonnable du point de vue opérationnel au cours de la semaine écoulée.

ReplicaLag La métrique mesure le nombre de secondes pendant lesquelles une réplique lue se trouve derrière l'instance principale. Le délai de réplication se produit lorsque le réplica en lecture ne peut pas être mis à jour au même rythme que l'instance de base de données principale. En cas de défaillance de l'instance principale, des données peuvent être manquantes dans la réplique lue si le seuil ReplicaLag est supérieur à un seuil raisonnable sur le plan opérationnel.

Cmsvnj8db1

Plusieurs causes peuvent expliquer cette augmentation au-delà des niveaux de sécurité opérationnelle. ReplicaLag Par exemple, cela peut être dû à des instances récemment replaced/launched répliquées à partir d'anciennes sauvegardes, ces répliques nécessitant un temps considérable pour « rattraper » l'instance de base de données principale et les transactions en cours. Ce chiffre ReplicaLag peut diminuer au fil du temps à mesure que le rattrapage se produit. Autre exemple, la vitesse de transaction pouvant être atteinte sur l'instance de base de données principale est supérieure à celle du processus de réplication ou à celle de l'infrastructure de réplica. Cela ReplicaLag peut augmenter au fil du temps car la réplication ne parvient pas à suivre le rythme des performances de la base de données principale. Enfin, la charge de travail peut être surchargée à différentes périodes du day/month /etc., ce qui ReplicaLag entraîne parfois un retard. Votre équipe doit rechercher la cause première possible de l'augmentation de la charge de travail de ReplicaLag la base de données, et éventuellement modifier le type d'instance de base de données ou d'autres caractéristiques de la charge de travail afin de garantir que la continuité des données sur la réplique correspond à vos besoins.

Lorsque le paramètre synchronous_commit est désactivé, des données peuvent être perdues en cas de panne de base de données. La durabilité de la base de données est menacée.

Nous vous recommandons d'activer le paramètre synchronous_commit.

c1qf5bt026

Rouge : le paramètre synchronous_commit est désactivé pour les groupes de paramètres de base de données.

Activez le paramètre synchronous_commit dans vos groupes de paramètres de base de données.

Le paramètre synchronous_commit définit l'achèvement du processus de Write-Ahead journalisation (WAL) avant que le serveur de base de données n'envoie une notification réussie au client. Ce commit est appelé commit asynchrone car le client accuse réception du commit avant que WAL n'enregistre la transaction sur le disque. Si le paramètre synchronous_commit est désactivé, les transactions peuvent être perdues, la durabilité de l'instance de base de données peut être compromise et des données peuvent être perdues en cas de panne d'une base de données.

Pour plus d'informations, consultez les fichiers journaux de la base de données MySQL.

Vérifie si les instantanés automatisés sont activés pour vos clusters Amazon Redshift.

Amazon Redshift prend automatiquement des instantanés incrémentaux qui effectuent le suivi des modifications du cluster depuis l’instantané automatique précédent. Les instantanés automatiques conservent toutes les données requises pour restaurer un cluster à partir d’un instantané. Pour désactiver les instantanés automatiques, définissez la période de conservation sur zéro. Vous ne pouvez pas désactiver les instantanés automatisés pour les types de nœuds RA3.

Vous pouvez spécifier les périodes de conservation minimale et maximale souhaitées à l'aide du MaxRetentionPeriod paramètre MinRetentionPeriod et de vos AWS Config règles.

Instantanés et sauvegardes Amazon Redshift

c18d2gz135

AWS Config Managed Rule: redshift-backup-enabled

Rouge : les instantanés automatisés ne sont pas configurés sur la période de conservation souhaitée pour Amazon Redshift.

Assurez-vous que les instantanés automatisés sont activés pour vos clusters Amazon Redshift.

Pour plus d’informations, consultez Gestion des instantanés à l’aide de la console.

Instantanés et sauvegardes Amazon Redshift

Pour plus d'informations, consultez la page Utilisation des sauvegardes.

Vérifie les jeux d'enregistrements de ressource associés à des surveillances de l'état ayant été supprimées.

Route 53 ne vous empêche pas de supprimer une surveillance de l'état, même si elle est associée à un ou plusieurs enregistrements de ressource. Si vous supprimez une surveillance de l'état sans mettre à jour les jeux d'enregistrements de ressource associés, le routage des requêtes DNS pour votre configuration de basculement DNS ne fonctionnera pas comme prévu.

Les zones hébergées créées par AWS les services n'apparaîtront pas dans les résultats de votre vérification.

Cb877eB72b

Jaune : un ensemble d'enregistrements de ressources est associé à une surveillance de l'état qui a été supprimée.

Créez une nouvelle surveillance de l'état et associez-la à l'ensemble d'enregistrements de ressources. Consultez Création, mise à jour et suppression des surveillances de l'état et Adding Health Checks to Resource Record Sets (Ajout de surveillances de l'état à des ensembles d'enregistrements de ressources).

Vérifie les jeux d'enregistrements de ressource de basculement Amazon Route 53 mal configurés.

Lorsque les surveillances de l'état Amazon Route 53 déterminent que la ressource principale n'est pas intègre, Amazon Route 53 répond aux requêtes avec un jeu d'enregistrements de ressource de sauvegarde secondaire. Vous devez créer des jeux d'enregistrements de ressource principaux et secondaires correctement configurés pour que le basculement fonctionne.

Les zones hébergées créées par AWS les services n'apparaîtront pas dans les résultats de votre vérification.

b73EEdD790

S'il manque un ensemble de ressources de basculement, créez l'ensemble d'enregistrements de ressources correspondant. Voir Creating Failover Resource Record Sets (Création d'ensembles d'enregistrements de ressources de basculement).

Si vos ensembles d'enregistrements de ressources sont associés à la même surveillance de l'état, créez des surveillances de l'état distincts pour chacun d'eux. Voir Création, mise à jour et suppression de surveillance de l'état.

Surveillances de l'état Amazon Route 53 et basculement DNS

Vérifie les jeux d'enregistrements de ressource pouvant bénéficier d'une valeur time-to-live inférieure (TTL).

TTL représente le nombre de secondes pendant lesquelles un jeu d'enregistrements de ressource est mis en cache par les résolveurs DNS. Lorsque vous spécifiez un TTL long, les résolveurs DNS mettent plus de temps à demander des enregistrements DNS mis à jour, ce qui peut retarder inutilement le réacheminement du trafic (par exemple, lorsque DNS Failover détecte une défaillance de l'un de vos terminaux et y répond). Ce contrôle ne porte que sur les enregistrements soumis à une politique de basculement ou s'il existe un bilan de santé associé.

Les zones hébergées créées par AWS les services n'apparaîtront pas dans les résultats de votre vérification.

C056F80cR3

Saisissez une valeur de durée de vie de 60 secondes pour les ensembles d'enregistrements de ressources répertoriés. Pour plus d'informations, consultez Working with Resource Record Sets (Utilisation d'ensembles d'enregistrements de ressources).

Surveillances de l'état Amazon Route 53 et basculement DNS

Vérifie les zones hébergées Amazon Route 53 pour lesquelles votre registre de domaine ou DNS n'utilise pas les bons serveurs de noms Route 53.

Lorsque vous créez une zone hébergée, Route 53 attribue un ensemble de quatre serveurs de noms. Les noms de ces serveurs sont ns- ### .awsdns- ## .com, .net, .org et .co.uk, où ### et représentent ## généralement des nombres différents. Avant que Route 53 puisse acheminer des requêtes DNS pour votre domaine, vous devez mettre à jour la configuration du serveur de noms de votre bureau d'enregistrement afin de supprimer les serveurs de noms affectés par ce dernier. Ensuite, vous devez ajouter les quatre serveurs de noms dans l'ensemble de délégations Route 53. Pour une disponibilité maximale, vous devez ajouter les quatre serveurs de noms Route 53.

Les zones hébergées créées par AWS les services n'apparaîtront pas dans les résultats de votre vérification.

cF171Db240

Jaune : zone hébergée pour laquelle le bureau d'enregistrement de votre domaine n'utilise pas les quatre serveurs de noms Route 53 de l'ensemble de délégations.

Ajoutez ou mettez à jour les enregistrements de serveurs de noms avec votre bureau d'enregistrement ou le service DNS actuel de votre domaine afin d'inclure les quatre serveurs de noms dans votre ensemble de délégations Route 53. Pour trouver ces valeurs, consultez Obtention de la liste des serveurs de noms d'une zone hébergée publique. Pour plus d'informations sur l'ajout ou la mise à jour d'enregistrements de serveurs, consultez Création et migration de domaines et de sous-domaines vers Amazon Route 53.

Utilisation de zones hébergées

Vérifie si la configuration de votre service comporte des adresses IP spécifiées dans au moins deux zones de disponibilité pour la redondance. Une zone de disponibilité est un emplacement distinct isolé des défaillances dans d'autres zones. En spécifiant des adresses IP dans plusieurs zones de disponibilité d'une même région, vous pouvez protéger vos applications contre un point unique de défaillance.

Chrv231ch1

Spécifiez les adresses IP dans au moins deux zones de disponibilité pour la redondance.

Vérifie si les règles de réplication de vos compartiments Amazon S3 sont activées pour Cross-Region la réplication, Same-Region la réplication ou les deux.

La réplication est la copie automatique et asynchrone d'objets dans des compartiments situés dans la même région ou dans des régions différentes. AWS Elle réplique les objets nouvellement créés et les mises à jour d'objets d'un compartiment source vers un ou plusieurs compartiments de destination. Utilisez la réplication de compartiment Amazon S3 pour améliorer la résilience et la conformité de vos applications et de votre stockage de données.

Pour plus d'informations, voir Réplication d'objets.

c18d2gz119

AWS Config Managed Rule: s3-bucket-replication-enabled

Jaune : les règles de réplication des compartiments Amazon S3 ne sont pas activées pour Cross-Region la réplication, Same-Region la réplication ou les deux.

Activez la réplication de compartiment Amazon S3 pour améliorer la résilience et la conformité de vos applications et de votre stockage de données.

Pour plus d'informations, voir Affichage de vos tâches de sauvegarde et de vos points de restauration et Configuration de la réplication.

Procédures : exemples de configurations de réplication

Vérifie les compartiments Amazon Simple Storage pour lesquels la gestion des versions est désactivée ou suspendue.

Lorsque la gestion des versions est activée, vous pouvez facilement récupérer les données en cas d'actions involontaires des utilisateurs ou d'échecs des applications. Vous pouvez utiliser la gestion des versions pour préserver, récupérer et restaurer chaque version de chaque objet stocké dans votre compartiment . Vous pouvez utiliser des règles de cycle de vie pour gérer toutes les versions de vos objets, ainsi que leurs coûts associés, en archivant automatiquement les objets dans la classe de stockage Glacier. Les règles peuvent également être configurées pour supprimer des versions de vos objets après un temps spécifié. Vous pouvez également exiger l'authentification multi-facteur (MFA) pour toute suppression d'objets ou modification de la configuration de vos compartiments.

La gestion des versions ne peut pas être désactivée une fois qu'elle a été activée. Cependant, elle peut être suspendue, ce qui empêche la création de nouvelles versions d'objets. L'utilisation de la gestion des versions peut augmenter vos coûts pour Amazon S3, car vous payez pour le stockage de plusieurs versions d'un même objet.

R365s2Qddf

Activez la gestion des versions sur la plupart des compartiments afin d'éviter la suppression ou l'écrasement accidentels. Voir Utilisation de la gestion des versions et Enabling Versioning Programmatically (Activation de la gestion des versions par programmation).

Si la gestion des versions du compartiment est suspendue, pensez à la réactiver. Pour plus d'informations sur l'utilisation d'objets dans un compartiment dont la gestion des versions est suspendue, consultez la section Gestion des objets dans un Versioning-Suspended compartiment.

Lorsque la gestion des versions est activée ou suspendue, vous pouvez définir des règles de configuration du cycle de vie pour marquer certaines versions d'objets comme ayant expiré ou pour supprimer définitivement les versions d'objets inutiles. Pour plus d’informations, consultez Gestion du cycle de vie des objets.

MFA Delete nécessite une authentification supplémentaire lorsque le statut de gestion des versions du compartiment est modifié ou lorsque des versions d'un objet sont supprimées. L'utilisateur doit saisir des informations d'identification et un code provenant d'un périphérique d'authentification approuvé. Pour de plus amples informations, veuillez consulter Fonction Supprimer MFA.

Utilisation des compartiments

Vérifie si vos Application Load Balancers, Network Load Balancers et Gateway Load Balancers sont configurés avec des sous-réseaux répartis sur plusieurs zones de disponibilité.

Vous pouvez spécifier les zones de disponibilité minimales souhaitées dans les AvailabilityZones paramètres minimaux de vos AWS Config règles.

Pour plus d'informations, voir Zones de disponibilité pour votre Application Load Balancer, Zones de disponibilité – Network Load Balancers et Création d'un Gateway Load Balancer.

c18d2gz169

AWS Config Managed Rule: elbv2-multiple-az

Jaune : les Application Load Balancers, Network Load Balancers et Gateway Load Balancers sont configurés avec des sous-réseaux dans moins de deux zones de disponibilité.

Configurez vos Application Load Balancers, Network Load Balancers et Gateway Load Balancers avec des sous-réseaux répartis sur plusieurs zones de disponibilité.

Zones de disponibilité pour votre Application Load Balancer

Zones de disponibilité (Elastic Load Balancing)

Création d'un Gateway Load Balancer

Il serait utile de vérifier qu'un Subnets.Having nombre suffisant d'adresses IP disponibles figurent parmi les adresses IP ciblées disponibles pour être utilisées lorsque Auto Scaling Group atteint sa taille maximale et doit lancer des instances supplémentaires.

Cjxm268ch1

Augmentation du nombre d'adresses IP disponibles

Examine la configuration de la surveillance de l'état des groupes Auto Scaling.

Si Elastic Load Balancing est utilisé pour un groupe Auto Scaling, la configuration recommandée est d'activer une surveillance de l'état Elastic Load Balancing. Si aucune surveillance de l'état Elastic Load Balancing n'est utilisé, Auto Scaling ne peut agir que sur l'état de l'instance Amazon Elastic Compute Cloud (Amazon EC2). Auto Scaling n'agira pas sur l'application exécutée sur l'instance.

CLOG40CDO8

Si le groupe Auto Scaling a un équilibreur de charge associé, mais que la surveillance de l'état Elastic Load Balancing n'est pas activée, consultez Add an Elastic Load Balancing Health Check (Ajouter une surveillance de l'état Elastic Load Balancing à votre groupe Auto Scaling).

Si le bilan de santé d'Elastic Load Balancing est activé, mais qu'aucun équilibreur de charge n'est associé au groupe Auto Scaling, voir Configurer une Load-Balanced application Auto-Scaled et.

Guide de l'utilisateur Amazon EC2 Auto Scaling

Vérifie la disponibilité des ressources associées à vos configurations de lancement, à vos modèles de lancement et à vos groupes Auto Scaling.

Les groupes Auto Scaling qui pointent vers des ressources indisponibles ne peuvent pas lancer de nouvelles instances Amazon Elastic Compute Cloud (Amazon EC2). Lorsque Auto Scaling est correctement configuré, cela augmente de manière régulière le nombre d'instances Amazon EC2 lors des pics de demande et le diminue automatiquement lors de ralentissements des demandes. Les groupes Auto Scaling et les configurations/launch modèles de lancement qui pointent vers des ressources indisponibles ne fonctionnent pas comme prévu.

8CNsSllI5v

Si l'équilibreur de charge a été supprimé, créez un nouvel équilibreur de charge ou un nouveau groupe cible, puis associez-le au groupe Auto Scaling, ou créez un nouveau groupe Auto Scaling sans l'équilibreur de charge. Pour plus d'informations sur la création d'un nouveau groupe Auto Scaling avec un nouvel équilibreur de charge, voir Configurer une Load-Balanced application Auto-Scaled et. Pour plus d'informations sur la création d'un nouveau groupe Auto Scaling sans équilibreur de charge, consultez Create Auto Scaling Group (Créer un groupe Auto Scaling) dans Getting Started With Auto Scaling Using the Console (Démarrer avec Auto Scaling à l'aide de la console).

Si l'AMI a été supprimée, créez une nouvelle configuration de lancement ou une nouvelle version du modèle de lancement à l'aide d'une AMI valide et associez-la à un groupe Auto Scaling. Pour plus d'informations sur la création d'une nouvelle configuration de lancement, voir Créer une configuration de lancement dans le guide de l'utilisateur d'Amazon EC2 Auto Scaling. Pour plus d'informations sur la création d'un modèle de lancement, voir Créer un modèle de lancement pour un groupe Auto Scaling dans le guide de l'utilisateur Amazon EC2 Auto Scaling.

Si vos modèles de lancement incluent un AWS Systems Manager paramètre qui inclut un ID Amazon Machine Image (AMI), vérifiez le modèle de lancement pour vous assurer que les paramètres font référence à un ID AMI valide, ou apportez les modifications appropriées dans le magasin de AWS Systems Manager paramètres. Pour plus d'informations, consultez la section Utiliser des AWS Systems Manager paramètres plutôt que des ID AMI dans le guide de l'utilisateur d'Amazon EC2 Auto Scaling.

Surveille vos clusters qui exécutent des instances HSM dans une zone de disponibilité (AZ) mono-AZ. Ce contrôle vous avertit si vos clusters risquent de ne pas disposer de la sauvegarde la plus récente.

hc0dfs7601

Créez au moins une instance supplémentaire pour le cluster dans une autre zone de disponibilité.

Les meilleures pratiques pour AWS CloudHSM

Vérifie la résilience de l' Direct Connect appareil utilisé pour connecter votre site à chaque passerelle Direct Connect ou passerelle privée virtuelle.

Cette vérification vous alerte si une passerelle Direct Connect ou une passerelle privée virtuelle n'est pas configurée avec des interfaces virtuelles sur au moins deux emplacements Direct Connect distincts. Le manque de résilience de l'emplacement peut entraîner des temps d'arrêt imprévus pendant la maintenance, une coupure de fibre, une panne de périphérique ou une défaillance complète de l'emplacement.

c1dfpnchv2

Rouge : la passerelle Direct Connect ou la passerelle privée virtuelle est configurée avec une ou plusieurs interfaces virtuelles sur un seul appareil Direct Connect.

Jaune : la passerelle Direct Connect ou la passerelle privée virtuelle est configurée avec des interfaces virtuelles entre plusieurs appareils Direct Connect dans un seul emplacement Direct Connect.

Vert : la passerelle Direct Connect ou la passerelle privée virtuelle est configurée avec des interfaces virtuelles réparties sur au moins deux emplacements Direct Connect distincts.

Pour renforcer la résilience géographique de Direct Connect, vous pouvez configurer la passerelle Direct Connect ou la passerelle privée virtuelle pour vous connecter à au moins deux emplacements Direct Connect distincts. Pour plus d'informations, consultez Direct Connect la recommandation de résilience.

Direct Connect Recommandations en matière de résilience

Direct Connect Test de basculement

Vérifie si une AWS Lambda fonction est configurée avec une file d'attente de lettres mortes.

Une file d'attente de lettres mortes est une fonctionnalité AWS Lambda qui vous permet de capturer et d'analyser les événements ayant échoué, offrant ainsi un moyen de gérer ces événements en conséquence. Votre code peut déclencher une exception, expirer ou manquer de mémoire, ce qui peut entraîner l'échec des exécutions asynchrones de votre fonction Lambda. Une file d'attente de lettres mortes stocke les messages provenant d'invocations ayant échoué, ce qui permet de gérer les messages et de résoudre les problèmes.

Vous pouvez spécifier la ressource de file d'attente de lettres mortes que vous souhaitez vérifier à l'aide du paramètre DLQArns de vos règles. AWS Config

Pour plus d'informations, consultez la section Dead-letter files d'attente.

c18d2gz182

AWS Config Managed Rule: lambda-dlq-check

Jaune : aucune file d'attente de lettres mortes n'est configurée pour la AWS Lambda fonction.

Assurez-vous que vos AWS Lambda fonctions disposent d'une file d'attente de lettres mortes configurée pour contrôler la gestion des messages pour toutes les invocations asynchrones ayant échoué.

Pour plus d'informations, consultez la section Dead-letter files d'attente.

Vérifie qu'une destination d'événement en cas d'échec ou une file d'attente de lettres morte est configurée pour les fonctions Lambda de votre compte pour les invocations asynchrones, afin que les enregistrements des invocations ayant échoué puissent être stockés pour être analysés ou traités ultérieurement.

c1dfprch05

Configurez une destination d'événement en cas d'échec ou une file d'attente de lettres mortes pour que vos fonctions Lambda envoient les invocations ayant échoué ainsi que d'autres informations à l'un des services AWS de destination disponibles pour un débogage ou un traitement ultérieur.

Vérifie la version $LATEST des fonctions VPC-enabled Lambda vulnérables aux interruptions de service dans une seule zone de disponibilité. Il est recommandé de connecter les VPC-enabled fonctions à plusieurs zones de disponibilité pour garantir une haute disponibilité.

L4dfs2Q4C6

Jaune : la version $LATEST d'une fonction VPC-enabled Lambda est connectée aux sous-réseaux d'une seule zone de disponibilité.

Lors de la configuration des fonctions d'accès à votre VPC, choisissez des sous-réseaux dans plusieurs zones de disponibilité afin d'assurer une haute disponibilité.

Vérifie le solde des Outposts Racks. Cela permet d'évaluer si les instances Outposts d'un client sont déployées sur plusieurs Outposts Racks ou sur un seul Outpost Rack. Un seul rack Outposts crée un point de défaillance unique pour les problèmes qui concernent un seul rack (par exemple, les défaillances environnementales). Ces scénarios peuvent être atténués en déployant des avant-postes sur plusieurs Racks.

c243hjzrhn

Si vous exécutez des charges de travail de production AWS Outposts, il est recommandé d'utiliser l'architecture résiliente suivante. Un seul AWS Outposts rack crée un point de défaillance unique. Envisagez d'ajouter à cet emplacement un deuxième AWS Outposts rack d'une capacité suffisante pour un événement de basculement, puis répartissez les charges de travail entre les racks.

Mode de défaillance 4 : racks ou centres de données

Vérifie si un composant d'application (AppComponent) de votre application est irrécupérable. Si l'un AppComponent ne se rétablit pas en cas d'interruption, vous risquez de subir une perte de données inconnue et une interruption du système.

RH23stmM04

Rouge : AppComponent irrécupérable.

Pour vous assurer que vous AppComponent êtes récupérable, examinez et mettez en œuvre les recommandations de résilience, puis effectuez une nouvelle évaluation. Pour plus d'informations sur la révision des recommandations en matière de résilience, consultez la section Ressources supplémentaires.

Examen des recommandations en matière de résilience

Concepts de AWS Resilience Hub

AWS Resilience Hub Guide de l'utilisateur

Vérifie Resilience Hub pour les applications qui ne répondent pas à l'objectif de délai de reprise (RTO) et à l'objectif de point de reprise (RPO) définis par la politique. La vérification vous alerte si votre application ne répond pas aux objectifs RTO et RPO que vous avez définis pour une application dans Resilience Hub.

RH23stmM02

Connectez-vous à la console Resilience Hub et passez en revue les recommandations afin que votre application réponde aux objectifs RTO et RPO.

Concepts du Resilience Hub

Vérifie si vous avez effectué une évaluation pour vos applications dans Resilience Hub. Cette vérification vous avertit si vos scores de résilience sont inférieurs à une valeur spécifique.

RH23stmM01

Connectez-vous à la console Resilience Hub et exécutez une évaluation pour votre application. Passez en revue les recommandations pour améliorer le score de résilience.

Concepts du Resilience Hub

Vérifie le temps écoulé depuis la dernière évaluation d'application. Cette vérification vous avertit si vous n'avez pas effectué d'évaluation de candidature depuis un certain nombre de jours.

RH23stmM03

Connectez-vous à la console Resilience Hub et exécutez une évaluation pour votre application.

Concepts du Resilience Hub

Vérifie le nombre de tunnels actifs pour chacun de vos AWS Site-to-Site VPN s.

Un VPN doit avoir deux tunnels configurés en permanence. Cela permet une redondance en cas de panne ou de maintenance planifiée des périphériques au point de terminaison AWS. Pour certains matériels, un seul tunnel est actif à la fois. Si un VPN n'a aucun tunnel actif, des frais pour le VPN peuvent quand même s'appliquer.

Pour plus d'informations, consultez Qu'est-ce qu' AWS Site-to-Site un VPN ?

c18d2gz123

AWS Config Managed Rule: vpc-vpn-2-tunnels-up

Jaune : un Site-to-Site VPN possède au moins un tunnel en panne.

Assurez-vous que deux tunnels sont configurés pour les connexions VPN. Et, si votre configuration matérielle le permet, assurez-vous que les deux tunnels sont actifs. Si vous n'avez plus besoin d'une connexion VPN, supprimez-la pour éviter des frais.

Pour plus d'informations, voir Votre périphérique de passerelle client et le contenu disponible dans le Centre de connaissances AWS.

Cette vérification identifie un risque de résilience lorsque les AWS charges de travail effectuent des appels interrégionaux vers le point de terminaison mondial STS dans la région de l'Est des États-Unis (Virginie du Nord). AWS les charges de travail qui adressent des requêtes interrégionales au point de terminaison mondial STS situé dans l'est des États-Unis (Virginie du Nord) peuvent être affectées si la connectivité au point de terminaison STS de l'est des États-Unis (Virginie du Nord) est affectée.

En avril 2025, AWS amélioration du point de terminaison mondial pour répondre automatiquement aux appels des terminaux mondiaux STS dans la même région que celle dans laquelle vos charges de travail s'exécutent AWS, toutes étant Régions AWS activées par défaut. Cependant, certaines charges de travail, telles que celles qui s'exécutent dans des régions optionnelles ou celles qui n'utilisent pas de serveurs Amazon DNS, ne bénéficient pas de la latence réduite et de l'isolation des pannes proposées dans le cadre de cette amélioration. Pour ces charges de travail, les demandes de terminaux mondiaux STS sont traitées dans la région de l'Est des États-Unis (Virginie du Nord), ce qui présente un risque de résilience pour votre application et augmente la latence des requêtes STS.

c15m0mgld3

Rouge : les charges de travail effectuent des appels interrégionaux vers le point de terminaison AWS STS mondial situé dans la région de l'Est des États-Unis (Virginie du Nord).

Pour améliorer la résilience et les performances de vos charges de travail, nous vous recommandons de migrer du point de terminaison global STS vers le point de terminaison régional STS. En utilisant un point de terminaison régional, vous pouvez l'utiliser AWS STS dans la même région que vos charges de travail.

La liste suivante répertorie les principaux Gestion des identités et des accès AWS (IAM) effectuant des appels interrégionaux vers le point de terminaison AWS STS mondial situé dans la région de l'Est des États-Unis (Virginie du Nord). En suivant les étapes décrites dans l'article de blog Comment utiliser les AWS STS points de terminaison régionaux, vous pouvez reconfigurer vos charges de travail pour utiliser le point de terminaison STS régional.

Vérifiez les éventuels problèmes à risque élevé (HRI) pour vos charges de travail dans le pilier de fiabilité. Cette vérification est basée sur vos commentaires AWS-Well Architected. Les résultats de la vérification varient selon que vous avez terminé ou non l'évaluation de la charge de travail avec AWS Well-Architected.

Wxdfp4B1L4

AWS Well-Architected a détecté des problèmes à haut risque lors de l'évaluation de votre charge de travail. Ces problèmes offrent la possibilité de réduire les risques et d'économiser de l'argent. Connectez-vous à l'AWS Well-Architectedoutil pour consulter vos réponses et prendre les mesures nécessaires pour résoudre les problèmes en cours.

Vérifie si un Classic Load Balancer est réparti sur plusieurs zones de disponibilité.

Un équilibreur de charge distribue le trafic applicatif entrant sur plusieurs instances Amazon EC2 réparties sur plusieurs zones de disponibilité. Par défaut, l'équilibreur de charge répartit le trafic uniformément entre les zones de disponibilité qui vous activez pour votre équilibreur de charge. En cas de panne d'une zone de disponibilité, les nœuds de l'équilibreur de charge transfèrent automatiquement les demandes aux instances enregistrées saines dans une ou plusieurs zones de disponibilité.

Vous pouvez ajuster le nombre minimum de zones de disponibilité à l'aide du AvailabilityZones paramètre min de vos AWS Config règles

Pour plus d'informations, voir Qu'est-ce qu'un Classic Load Balancer ?.

c18d2gz154

AWS Config Managed Rule: clb-multiple-az

Jaune : Classic Load Balancer n'est pas Multi-AZ configuré ou n'atteint pas le nombre minimum d'AZ spécifié.

Assurez-vous que plusieurs zones de disponibilité sont configurées sur vos Classic Load Balancers. Répartissez votre équilibreur de charge sur plusieurs zones de disponibilité pour garantir la haute disponibilité de votre application.

Pour plus d'informations, voir Didacticiel : Création d'un Classic Load Balancer.

Vérifie les équilibreurs de charge classiques pour lesquels le drainage des connexions n'est pas activé.

Lorsque le drainage des connexions n'est pas activé et que vous désenregistrez une instance Amazon EC2 d'un équilibreur de charge classique, l'équilibreur de charge classique arrête d'acheminer le trafic vers cette instance et ferme la connexion. Lorsque le drainage des connexions est activé, l'équilibreur de charge classique arrête d'envoyer de nouvelles demandes à l'instance désenregistrée mais maintient la connexion ouverte pour répondre aux demandes actives.

7qGXsKIUw

Activez la vidange des connexions pour l'équilibreur de charge classique. Pour plus d'informations, consultez Connexion draining et Enable or Disable Connection Draining for Your Load Balancer (Activer ou désactiver le drainage de la connexion pour votre équilibreur de charge).

Concepts Elastic Load Balancer

Vérifie la distribution cible des groupes cibles dans les zones de disponibilité (AZ) pour l'équilibreur de charge des applications (ALB), l'équilibreur de charge réseau (NLB) et l'équilibreur de charge de passerelle (GWLB).

Cette vérification exclut les éléments suivants :

b92b83d667

Pour une meilleure résilience, assurez-vous que vos groupes cibles ont le même nombre de cibles dans toutes les zones de couverture.

Groupes cibles pour vos équilibreurs de charge d'applications

Enregistrez des cibles auprès de votre groupe cible Application Load Balancer

Vérifie si les points de terminaison de votre Gateway Load Balancer (GWLB) sont configurés comme destination de route depuis une autre zone de disponibilité (AZ).

Les points de terminaison du Gateway Load Balancer transmettent le trafic réseau aux dispositifs de pare-feu situés derrière un Gateway Load Balancer à des fins d'inspection. Chaque point de terminaison Gateway Load Balancer fonctionne dans une zone de disponibilité désignée et est conçu avec une redondance uniquement dans cette zone de disponibilité. Ainsi, toutes les ressources d'une zone de disponibilité particulière doivent utiliser un point de terminaison Gateway Load Balancer dans la même zone de disponibilité. Cela garantit que toute panne potentielle d'un point de terminaison Gateway Load Balancer ou de sa zone de disponibilité n'a pas d'impact sur vos ressources dans une autre zone de disponibilité.

528d6f5ee7

Vérifiez la zone de disponibilité de votre sous-réseau et configurez sa table de routage pour acheminer le trafic via un point de terminaison Gateway Load Balancer situé dans la même zone de disponibilité.

S'il n'existe aucun point de terminaison Gateway Load Balancer dans l'AZ, créez-en un nouveau et acheminez le trafic de votre sous-réseau via celui-ci.

Si la même table de routage est associée à des sous-réseaux de différentes zones de zone de disponibilité, conservez cette table de routage associée aux sous-réseaux résidant dans la même zone de disponibilité que le point de terminaison Gateway Load Balancer. Pour les sous-réseaux de l'autre zone de disponibilité, vous pouvez ensuite associer une table de routage distincte à une route vers un point de terminaison de Gateway Load Balancer dans cette zone de disponibilité.

Il est recommandé de choisir une fenêtre de maintenance pour les modifications d'architecture de votre Amazon VPC.

Vérifie la configuration de votre équilibreur de charge.

Pour augmenter le niveau de tolérance aux pannes dans Amazon Elastic Compute Cloud (Amazon EC2) lors de l'utilisation d'Elastic Load Balancing, nous vous recommandons d'exécuter un nombre égal d'instances sur plusieurs zones de disponibilité dans une région. Un équilibreur de charge configuré augmente les frais, donc il s'agit également d'une vérification d'optimisation des coûts.

iqdCTZKCUp

Assurez-vous que l'équilibreur de charge pointe vers des instances actives et saines dans au moins deux zones de disponibilité. Pour plus d'informations, consultez Ajouter des zones de disponibilité.

Si votre équilibreur de charge est configuré pour une zone de disponibilité sans instances saines, ou en cas de déséquilibre des instances entre les zones de disponibilité, déterminez si toutes les zones de disponibilité sont nécessaires. Omettez les zones de disponibilité inutiles et assurez-vous que les instances sont réparties de manière équilibrée entre les zones de disponibilité restantes. Pour de plus amples informations, veuillez consulter Remove Availability Zone (Supprimer une zone de disponibilité).

Vérifie si l'indépendance des zones de disponibilité (AZ) est configurée pour vos passerelles NAT.

Une passerelle NAT permet aux ressources de votre sous-réseau privé de se connecter en toute sécurité à des services en dehors du sous-réseau à l'aide des adresses IP de la passerelle NAT et supprime tout trafic entrant non sollicité. Chaque passerelle NAT fonctionne dans une zone de disponibilité (AZ) désignée et est conçue de manière redondante uniquement dans cette zone. Par conséquent, vos ressources dans une zone de disponibilité donnée doivent utiliser une passerelle NAT dans la même zone de disponibilité, de sorte que toute panne potentielle d'une passerelle NAT ou de sa zone de disponibilité n'ait aucun impact sur vos ressources dans une autre zone de disponibilité.

c1dfptbg10

Vérifiez la zone de disponibilité de votre sous-réseau et acheminez le trafic via une passerelle NAT dans la même zone de disponibilité.

S'il n'existe aucune passerelle NAT dans la zone de disponibilité, créez-en une et utilisez-la pour acheminer le trafic de votre sous-réseau.

Si la même table de routage est associée à des sous-réseaux dans différentes zones de disponibilité, conservez cette table de routage associée aux sous-réseaux résidant dans la même zone de disponibilité que la passerelle NAT. Pour les sous-réseaux dans l'autre zone de disponibilité, associez une table de routage distincte à un routage vers une passerelle NAT dans cette autre zone de disponibilité.

Nous vous recommandons de choisir une fenêtre de maintenance pour les modifications d'architecture de votre VPC Amazon.

Vérifie si vos AWS Network Firewall points de terminaison sont configurés comme destination d'itinéraire depuis une autre zone de disponibilité (AZ).

Les points de terminaison du pare-feu réseau transmettent le trafic réseau à un pare-feu réseau pour inspection. Chaque point de terminaison du pare-feu réseau fonctionne dans une zone de disponibilité désignée et est construit avec une redondance uniquement dans cette zone de disponibilité. Vos ressources situées dans une zone de disponibilité donnée doivent utiliser un point de terminaison de pare-feu réseau situé dans la même zone de disponibilité. Cela garantit que toute panne potentielle d'un point de terminaison du pare-feu réseau ou de sa zone de disponibilité n'a pas d'impact sur vos ressources dans une autre zone de disponibilité. Le trafic réseau qui provient d'une autre zone de zone de disponibilité à des fins d'inspection du trafic entraîne des frais de transfert de données inter-AZ. Il est recommandé de s'assurer que toutes les ressources d'une zone de disponibilité spécifique utilisent un pare-feu réseau dans la même zone de disponibilité afin d'éviter les frais de données inter-zones de zone de disponibilité.

7040ea389a

Vérifiez la zone de disponibilité de votre sous-réseau et acheminez le trafic via un point de terminaison du pare-feu réseau situé dans la même zone de disponibilité.

S'il n'y a pas de point de terminaison du pare-feu réseau dans la zone AZ, créez un nouveau pare-feu réseau et acheminez le trafic de votre sous-réseau via celui-ci.

Si la même table de routage est associée à plusieurs sous-réseaux dans différentes zones de zone de disponibilité, conservez cette table de routage associée aux sous-réseaux résidant dans la même zone de disponibilité que le point de terminaison du pare-feu réseau. Pour les sous-réseaux situés dans d'autres zones de zone de zone de disponibilité, associez une table de routage distincte à une route vers un point de terminaison du pare-feu réseau dans cette zone de zone de zone de zone de zone de couverture.

Il est recommandé de choisir une fenêtre de maintenance pour les modifications d'architecture de votre Amazon VPC.

Transfert de données au sein du même Région AWS

Comprendre les frais de transfert de données

Indépendance de la zone de disponibilité

Étapes de haut niveau pour la mise en œuvre d'un pare-feu

Création d'un pare-feu

AWS Well-Architected Tool - Utiliser des architectures de cloison pour limiter la portée de l'impact

Vérifie si vos pare-feux réseau sont configurés pour utiliser plus d'une zone de disponibilité (AZ) pour les points de terminaison du pare-feu.

Un AZ est un endroit distinct qui est isolé des défaillances dans d'autres zones. Si le point de terminaison du pare-feu réseau est déployé dans une seule zone de zone de disponibilité, il peut s'agir d'un point de défaillance unique et affecter les charges de travail provenant d'autres zones de zone de disponibilité utilisant le pare-feu réseau pour l'inspection du trafic. Il est recommandé de configurer vos pare-feux réseau dans plusieurs zones de disponibilité de la même région afin d'améliorer la disponibilité de votre charge de travail.

c2vlfg0gqd

Assurez-vous que votre pare-feu réseau est configuré avec au moins deux AZ pour les charges de travail de production.

Configuration du sous-réseau VPC pour AWS Network Firewall

Création d'un pare-feu

Zone de disponibilité

AWS Well-Architected Tool - Déployez la charge de travail sur plusieurs sites

Appliance dans un VPC à services partagés

Vérifie si l'équilibrage de charge entre zones est activé sur les Network Load Balancers.

Cross-zone l'équilibrage de charge permet de maintenir une répartition uniforme du trafic entrant entre les instances situées dans différentes zones de disponibilité. Cela empêche l'équilibreur de charge d'acheminer tout le trafic vers des instances situées dans la même zone de disponibilité, ce qui peut entraîner une répartition inégale du trafic et une surcharge. Cette fonctionnalité renforce également la fiabilité des applications en acheminant automatiquement le trafic vers des instances saines situées dans d'autres zones de disponibilité en cas de défaillance d'une zone de disponibilité.

Pour plus d'informations, consultez la section Équilibrage de Cross-zone charge.

c18d2gz105

AWS Config Managed Rule: nlb-cross-zone-load-balancing-enabled

Assurez-vous que l'équilibrage de charge entre zones est activé sur les Network Load Balancers.

Cross-zone équilibrage de charge (équilibreurs de charge réseau)

Vérifie si un équilibreur de charge réseau (NLB) connecté à Internet est configuré avec un sous-réseau privé. Un équilibreur de charge réseau (NLB) connecté à Internet doit être configuré dans les sous-réseaux publics pour recevoir le trafic. Un sous-réseau public est défini comme un sous-réseau qui possède une route directe vers une passerelle Internet. Si le sous-réseau est configuré comme privé, sa zone de disponibilité (AZ) ne reçoit pas de trafic, ce qui peut entraîner des problèmes de disponibilité.

c1dfpnchv4

Rouge : NLB est configuré avec un ou plusieurs sous-réseaux privés

Vert : aucun sous-réseau privé n'est configuré pour le NLB connecté à Internet

Vérifiez que les sous-réseaux configurés dans un équilibreur de charge connecté à Internet sont publics. Un sous-réseau public est défini comme un sous-réseau qui possède une route directe vers une passerelle Internet. Utilisez l'une des options suivantes :

Vérifie si vos équilibreurs de charge réseau sont configurés pour utiliser plusieurs zones de disponibilité (AZ). Une zone de disponibilité est un emplacement distinct isolé des défaillances dans d'autres zones. Configurez votre équilibreur de charge dans plusieurs zones de disponibilité de la même région afin d'améliorer la disponibilité de votre charge de travail.

c1dfprch09

Jaune : NLB se trouve dans une seule AZ.

Vert : NLB possède au moins deux AZ.

Assurez-vous que votre équilibreur de charge est configuré avec au moins deux zones de disponibilité.

Pour plus d’informations, consultez la documentation suivante :

Vérifie que la configuration d'un ensemble de réplication Incident Manager en utilise plusieurs Région AWS pour prendre en charge le basculement et la réponse régionaux. Pour les incidents créés par CloudWatch des alarmes ou EventBridge des événements, Incident Manager crée un incident de la même manière Région AWS que la règle d'alarme ou d'événement. Si la gestion des incidents est temporairement indisponible dans cette région, le système tente de créer un incident dans une autre région de l'ensemble de réplications. Si l'ensemble de réplications ne comprend qu'une seule région, le système ne pourra pas créer d'enregistrement d'incident tant que la gestion des incidents est indisponible.

cIdfp1js9r

Ajoutez au moins une région supplémentaire à l'ensemble de réplications.

Pour plus d'informations, consultez la section Gestion des Cross-region incidents.

Vérifie à l'aide de modèles de réseau si votre trafic réseau sortant est acheminé via une seule zone de disponibilité (AZ).

Une zone de disponibilité est un emplacement distinct isolé de tout impact dans d'autres zones. En répartissant votre service sur plusieurs zones de disponibilité, vous limitez le rayon d'impact d'une panne de zone de disponibilité.

c1dfptbg11

Si votre application nécessite une haute disponibilité, mettez en œuvre une architecture multi-AZ.

Vérifie si les points de terminaison de votre interface AWS PrivateLink VPC sont configurés pour utiliser plusieurs zones de disponibilité (AZ). Une zone de disponibilité est un emplacement distinct isolé des défaillances dans d'autres zones. Cela permet une connectivité réseau peu coûteuse et à faible latence entre les zones de disponibilité d'une même AWS région. Sélectionnez des sous-réseaux dans plusieurs zones de disponibilité lorsque vous créez des points de terminaison d'interface afin de protéger vos applications contre un point de défaillance unique.

c1dfprch10

Jaune : le point de terminaison du VPC se trouve dans une seule zone de zone de disponibilité.

Vert : le point de terminaison du VPC se trouve dans au moins deux zones de zone de sécurité.

Assurez-vous que le point de terminaison de votre interface VPC est configuré avec au moins deux zones de disponibilité.

Pour plus d’informations, consultez la documentation suivante :

Vérifie le nombre de tunnels actifs pour chacun de vos Site-to-Site VPN.

Un VPN doit avoir deux tunnels configurés en permanence. Cela fournit une redondance en cas de panne ou de maintenance planifiée des périphériques au point de terminaison AWS . Pour certains matériels, un seul tunnel est actif à la fois. Si un VPN n'a aucun tunnel actif, des frais pour le VPN peuvent quand même s'appliquer. Pour plus d'informations, consultez le guide de l'utilisateur du Site-to-Site VPN AWS.

S45wrEXrLz

Assurez-vous que deux tunnels sont configurés pour votre connexion VPN et qu'ils sont tous deux actifs si votre matériel le prend en charge. Si vous n'avez plus besoin d'une connexion VPN, vous pouvez la supprimer pour éviter des frais. Pour plus d'informations, consultez la section Votre appareil de passerelle client ou Supprimer une connexion Site-to-Site VPN.

Vérifie que les courtiers Amazon MQ pour ActiveMQ sont configurés pour une haute disponibilité avec un active/standby courtier dans plusieurs zones de disponibilité.

c1t3k8mqv1

Créez un nouveau courtier avec active/standby le mode déploiement.

Vérifie que les agents Amazon MQ pour RabbitMQ sont configurés pour une haute disponibilité avec des instances de cluster dans plusieurs zones de disponibilité.

c1t3k8mqv2

Créez un nouvel agent avec le mode de déploiement de cluster.