Comment fonctionnent les vérifications de l'état des demandes Commencez à vérifier l'état des demandes Options de configuration Paramètres par défaut Intégration d'Amazon EC2 Auto Scaling Gestion du déploiement, de l'application des correctifs sur place et des remplacements Tester une nouvelle vérification de l'état d'une application Réseau avancé Résolution des problèmes Surveiller les vérifications de l'état des applications Sécurité et autorisations Tarification Quotas

Vérifications de l'état des demandes

Les vérifications de l'état des applications vous permettent de surveiller les performances et l'état de santé de vos applications exécutées sur Amazon EC2. Grâce aux vérifications de l'état des applications, vous pouvez détecter les problèmes de santé des applications et y répondre en surveillant vos applications via des chemins et des ports configurables. Par exemple, vous pouvez utiliser les vérifications de l'état des applications pour confirmer que votre serveur Web écoute sur le port prévu et accepte les nouvelles connexions.

Les contrôles d'état des applications surveillent les réponses HTTP et HTTPS de vos applications sur des chemins et des ports configurables. Ils s'exécutent toutes les 60 secondes et s'intègrent à Amazon EC2 Auto Scaling, ce qui vous permet d'automatiser le remplacement des instances dont les applications sont altérées.

Table des matières

Comment fonctionnent les vérifications de l'état des demandes
Commencez à vérifier l'état des demandes
Options de configuration
Paramètres par défaut
Intégration d'Amazon EC2 Auto Scaling
Gestion du déploiement, de l'application des correctifs sur place et des remplacements
Tester une nouvelle vérification de l'état d'une application
Réseau avancé
Résolution des problèmes
Surveiller les vérifications de l'état des applications
Sécurité et autorisations
Tarification
Quotas

Comment fonctionnent les vérifications de l'état des demandes

Les vérifications de l'état des applications envoient des requêtes HTTP ou HTTPS à un terminal qui écoute sur un port réseau de votre instance toutes les 60 secondes. AWS compare le code de réponse au comparateur de code d'état que vous avez configuré. La vérification est marquée comme étant affaiblie après un certain nombre de demandes échouées consécutives, et redevient saine après plusieurs demandes consécutives réussies. Les deux comptes sont définis par défaut à 2 et sont configurables. Pour de plus amples informations, veuillez consulter Seuils d'évaluation.

Note

Les vérifications de l'état de la demande renvoient la demande de bilan de santé HTTP/2.

La vérification du protocole HTTPS ne valide pas le certificat du serveur.

Lors d'un redémarrage, les contrôles d'état de l'application signalent un échec jusqu'à ce que l'instance soit à nouveau disponible, car l'application ne peut pas répondre aux demandes de vérification de l'état pendant le redémarrage du système d'exploitation.

Architecture réseau

Les vérifications de l'état des applications proviennent du service de vérification de l'état des applications Amazon EC2. Pour accéder à vos instances, AWS créez une interface réseau élastique gérée (ENI) dans votre VPC. AWS crée un ENI par combinaison de sous-réseau source et de groupe de sécurité auquel sont associées des instances. AWS crée l'ENI géré lorsqu'une vérification de l'état d'une application nécessite pour la première fois cette combinaison, et la supprime lorsqu'aucune vérification d'état de l'application restante ne l'exige. L'ENI géré n'est pas pris en compte dans la limite ENI de votre instance, mais dans votre limite globale d'ENI par VPC.

Les vérifications de l'état des applications permettent d'accéder à vos instances depuis un point de vue privé au sein de votre VPC. La portée décrit l'origine de la vérification, et non une propriété de l'adresse IP de votre instance. AWS crée l'ENI géré dans un sous-réseau de votre VPC et atteint l'instance via le chemin du réseau privé.

Le trafic du bilan de santé provient d'instances Amazon EC2 AWS gérées dans la même zone de disponibilité que l'instance cible (ou la zone de disponibilité parente pour les cibles de la zone locale), passe par le réseau AWS interne et ne traverse pas l'Internet public. Pour plus d'informations, consultez les FAQ Amazon VPC sur le site Web Amazon Web Services.

AWS chemins réseau gérés et gérés par le client

Les vérifications de l'état des applications prennent en charge deux modes d'intégration qui déterminent qui sélectionne les sous-réseaux sources et les groupes de sécurité pour le bilan de santé ENI et les sous-réseaux et groupes de sécurité de destination pour les instances cibles.

AWS chemins réseau gérés

AWS sélectionne les sous-réseaux sources et les groupes de sécurité pour le bilan de santé ENI et les sous-réseaux et groupes de sécurité de destination pour les instances cibles.

Customer-managed chemins réseau

Vous spécifiez les sous-réseaux source et les groupes de sécurité pour le bilan de santé ENI et les sous-réseaux et groupes de sécurité de destination pour les instances cibles.

Utilisez des chemins réseau gérés par le client lorsque vous devez contrôler de quels sous-réseaux et groupes de sécurité provient le trafic de contrôle de santé, par exemple lorsque votre VPC est soumis à une segmentation réseau stricte, à des règles de pare-feu ou à des exigences de conformité qui limitent les sources pouvant atteindre les points de terminaison de votre application.

Vous choisissez le mode en incluant ou en omettant le --health-check-paths paramètre dans la commande de création. Si vous omettez ce --health-check-paths paramètre, AWS sélectionne les sous-réseaux source et de destination ainsi que les groupes de sécurité (chemins réseau AWS gérés). Si vous incluez le --health-check-paths paramètre, vous le gérez (chemins réseau gérés par le client).

Versions d’adresses IP

Chaque vérification de l'état de l'application est associée à une seule version IP (IPv4 ou IPv6). Pour surveiller une instance sur IPv4 et IPv6, créez deux contrôles d'état de l'application distincts et associez les deux à l'instance.

Les contrôles atteignent votre instance depuis votre VPC pour IPv4 et IPv6.

Vérifiez les valeurs d'état

Chaque contrôle individuel indique l'un des statuts suivants :

passed: la vérification s'est terminée avec succès
failed: le contrôle a échoué. La réponse inclut le code d'état HTTP renvoyé par votre application. Pour obtenir des conseils d'interprétation et de correction, voirRésolution des problèmes.
initializing: le chèque n'a pas encore terminé sa première évaluation
insufficient-data: le chèque n'a pas reçu suffisamment de données pour déterminer un résultat
not-applicable: le check n'est pas associé à l'instance

L'état global de l'application indiqué pour l'instance regroupe tous les résultats de vérification individuels. La situation générale est l'une des suivantes :

ok: tous les contrôles ont été réussis
impaired: échec d'une ou de plusieurs vérifications
initializing: une ou plusieurs vérifications n'ont pas encore terminé leur première évaluation
insufficient-data: un ou plusieurs contrôles signalent des données insuffisantes
not-applicable: toutes les vérifications de statut des applications associées sont exclues de l'agrégation
suppressed: l'évaluation de la vérification de l'état de l'application est supprimée pour l'instance

Agrégation

Vous pouvez marquer chaque vérification de l'état de l'application comme étant incluse ou exclue du statut général de l'instance. Par défaut, une case est cochéeincluded.

included: La vérification contribue à l'état général de l'instance et Amazon EC2 Auto Scaling l'utilise.
excluded: Le check indique son statut individuel mais ne contribue pas à l'état général de l'instance et Amazon EC2 Auto Scaling ne l'utilise pas. Utilisez ce paramètre pour valider un nouveau contrôle en production sans affecter l'état général ni déclencher le remplacement d'Amazon EC2 Auto Scaling. Il s'agit du flux de travail recommandé lors de l'ajout d'un check à une charge de travail de production existante ; voirTester une nouvelle vérification de l'état d'une application.

Commencez à vérifier l'état des demandes

Conditions préalables

Avant de créer une vérification de l'état de votre demande, assurez-vous de disposer des éléments suivants :

Un VPC avec les instances que vous souhaitez surveiller.
Un point de terminaison d'application sur chaque instance capable de répondre aux requêtes HTTP ou HTTPS sur le port et le chemin HTTP que vous allez configurer.
Un groupe de sécurité sur chaque instance de destination qui autorise le trafic entrant sur le port de contrôle à partir du groupe de sécurité source utilisé par la vérification de l'état de l'application. Consultez Sécurité et autorisations.

Étape 1 : Configurer votre application

Configurez le point de terminaison de votre application pour répondre aux requêtes HTTP ou HTTPS sur le port et le chemin HTTP que vous indiquerez lors de la création du check. Renvoie un code de réponse inclus dans votre comparateur de codes d'état pour indiquer que l'application est saine.

Assurez-vous que le groupe de sécurité de l'instance de destination autorise le trafic entrant sur le port de contrôle en provenance du groupe de sécurité source utilisé par la vérification de l'état de l'application. Pour les chemins réseau gérés, AWS fournit le groupe de sécurité source lors de la création du check. Pour les chemins réseau gérés par le client, vous spécifiez le groupe de sécurité source lorsque vous créez le check.

Étape 2 : Création d'une définition de contrôle

Utilisez l' AWS interface de ligne de commande pour créer une vérification de l'état de l'application.

Étape 3 : Associer le check à des instances

Associez le check aux instances que vous souhaitez surveiller, soit par ID d'instance, soit par tag.

Les opérations d'association et de dissociation renvoient des résultats de réussite et d'échec par instance. Si certaines instances ne peuvent pas être associées (par exemple, parce que la vérification est déjà associée), ces instances apparaissent dans les résultats infructueux avec une raison.

Étape 4 : Afficher les résultats

Consultez l'état de santé de l'application par instance.

Options de configuration

Les contrôles d'état des applications acceptent plusieurs paramètres de configuration. Cette section décrit les paramètres dont le comportement n'est pas évident d'après le nom du paramètre. Pour obtenir la liste complète des paramètres et des règles de validation, consultez CreateApplicationStatusCheck et AssociateApplicationStatusCheck dans le manuel Amazon EC2 API Reference.

Seuils d'évaluation

FailureThreshold: Le nombre de demandes échouées consécutives avant que la vérification ne soit marquée comme étant altérée. Par défaut : 2.
SuccessThreshold: Le nombre de demandes réussies consécutives avant que la vérification ne soit à nouveau considérée comme saine. Par défaut : 2.
Timeout: Le nombre de secondes d'attente d'une réponse avant que la demande ne soit enregistrée comme ayant échoué. Appliqué en tant que délai d'attente forcé ; si votre application ne répond pas dans cette fenêtre, la demande est enregistrée comme un échec, quelle que soit la réponse éventuelle. Par défaut : 6. Plage valide : 1 à 30.

Délai de grâce de démarrage

InitializationGracePeriodSeconds: Le nombre de secondes à attendre après le lancement d'une instance avant de AWS commencer à évaluer le check. Utilisez ce paramètre pour donner aux applications le temps de commencer à écouter avant le début des vérifications. Si le délai de grâce est trop court, Amazon EC2 Auto Scaling peut remplacer les nouvelles instances avant que leur application ne soit prête. Par défaut : 300. Plage valide : 1 à 600.

Champ d'application IP

IpScope: Les vérifications de l'état des applications utilisent la private portée ; elles sont exécutées depuis votre VPC. Pour IPv4, cela correspond à l'adresse IP privée de l'instance. Pour IPv6, AWS ne classe pas l'adresse comme publique ou privée ; le check accepte n'importe quelle adresse IPv6 et l'évalue depuis votre VPC.

Index des appareils

DeviceIndex: L'index du périphérique réseau de votre instance qui est AWS évalué pour le bilan de santé. Modifiez cette option lorsque le périphérique réseau principal de votre instance n'est pas celui que vous souhaitez vérifier. Valeur par défaut : 0.

L'agrégation, la version IP et les chemins de vérification de l'état (sous-réseaux source et destination et groupes de sécurité) sont abordés dans leurs propres sections plus haut sur cette page.

Paramètres par défaut

Dans le AWS cas des chemins réseau gérés, les vérifications de l'état des applications utilisent les valeurs par défaut suivantes.

Paramètre	Par défaut
Intervalle de contrôle	60 secondes (fixe ; non configurable)
Seuil d'échec	2 échecs consécutifs
Seuil de réussite	2 succès consécutifs
Timeout	6 secondes
Matcher de code d'état	200
Chemin HTTP	/
Versions d’adresses IP	ipv4
Champ d'application IP	privé
Index des appareils	0
Période de grâce d'initialisation	300 secondes
Agrégation	inclus
Sous-réseaux sources et groupes de sécurité	Géré par AWS

Intégration d'Amazon EC2 Auto Scaling

Amazon EC2 Auto Scaling arrête et remplace automatiquement les instances dont l'état général de l'application est indiquéimpaired, à condition que la vérification soit incluse dans l'agrégation. Aucune configuration de groupe Auto Scaling n'est requise au-delà de l'association de la vérification de l'état de l'application aux instances du groupe.

Amazon EC2 Auto Scaling utilise l'état général de l'instance, et non le statut de vérification individuel. Les cases cochées excluded n'activent pas les actions Amazon EC2 Auto Scaling. Les vérifications de l'suppressedétat n'entraînent pas les actions d'Amazon EC2 Auto Scaling.

Utilisez le InitializationGracePeriodSeconds paramètre de vérification pour laisser le temps aux nouvelles instances de démarrer avant que les vérifications de l'état de l'application ne commencent. Si la période de grâce est trop courte, les nouvelles instances peuvent être résiliées et remplacées par Amazon EC2 Auto Scaling avant que leur application ne soit prête à traiter le trafic.

Pour plus d'informations sur la manière dont Amazon EC2 Auto Scaling utilise les bilans de santé, consultez les rubriques Contrôles de santé pour les instances d'un groupe Auto Scaling et Utiliser les contrôles d'état des applications avec un groupe Auto Scaling dans le Guide de l'utilisateur d'Amazon EC2 Auto Scaling.

Gestion du déploiement, de l'application des correctifs sur place et des remplacements

Les déploiements, les correctifs sur place et les autres opérations de maintenance peuvent arrêter ou redémarrer temporairement votre application. Pendant cette période, les contrôles de statut des applications signalent un échec car l'application ne peut pas répondre aux demandes de contrôle de santé. Si vos instances font partie d'un groupe Auto Scaling dont les vérifications de l'état des applications sont incluses dans l'agrégation, Amazon EC2 Auto Scaling peut mettre fin à ces instances et les remplacer même si l'interruption est attendue.

Option A : Supprimer la coche

Utilisez la suppression pour les fenêtres de maintenance limitées dont vous connaissez la durée. La suppression est appliquée au niveau de l'instance. Vous spécifiez une durée ou vous l'omettez pour supprimer la vérification jusqu'à ce que vous désactiviez la suppression.

En cas de suppression, l'état général de la demande pour l'instance est affichésuppressed. Amazon EC2 Auto Scaling n'agit pas sur les suppressed instances.

Option B : Exclure le chèque de l'agrégation

Si vous souhaitez que le check continue à évaluer et à signaler son statut individuel sans affecter l'état général ni déclencher des actions Amazon EC2 Auto Scaling, définissez le paramètre d'agrégation du check sur. excluded Cela est utile pour les scénarios à plus long terme tels que le déploiement d'une nouvelle version de vérification ou la validation d'une modification sans risquer de la remplacer, et dans les cas où vous souhaitez que la télémétrie se poursuive sans impact opérationnel.

Pour de plus amples informations, veuillez consulter Agrégation.

Option C : dissocier le chèque

Utilisez la dissociation pour une suppression de longue durée ou pour une durée indéfinie.


aws ec2 disassociate-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --instance-ids i-0123456789abcdef0

Si vous avez associé par tag, supprimez le tag de l'instance pour le dissocier. Après dissociation, l'état général de la demande pour l'instance est indiqué. not-applicable

Conseils de déploiement

Les déploiements constituent le scénario de maintenance le plus courant nécessitant une suppression. Utilisez la suppression lorsque votre outil de déploiement possède un hook pré-déploiement et un hook post-déploiement afin de pouvoir supprimer la vérification avant le début du déploiement et désactiver la suppression une fois le déploiement terminé.

Le schéma général est le suivant :

Dans le hook de pré-déploiement, appelez enable-application-status-check-suppression pour l'instance, avec une durée qui couvre la fenêtre de déploiement prévue.
Effectuez le déploiement.
Dans le hook post-déploiement, appelez https://docs.aws.amazon.com/cli/latest/reference/ec2/disable-application-status-check-suppression.html disable-application-status-check-suppression pour l'instance.

Si votre outil de déploiement ne possède pas de hooks, supprimez le lecteur du CI/CD pipeline qui invoque le déploiement.

Tester une nouvelle vérification de l'état d'une application

Vous pouvez valider une nouvelle vérification de l'état d'une application en production avant qu'elle ne commence à contribuer à la surveillance au niveau de votre instance. Définissez le paramètre d'agrégation au excluded moment de la création du check, puis confirmez qu'il indique l'état attendu et les codes de réponse HTTP. Lorsque vous êtes prêt, modifiez le paramètre pour included que la vérification contribue à l'état général de l'instance et s'intègre à Amazon EC2 Auto Scaling.

Créez la vérification avec le paramètre d'agrégation défini surexcluded.


aws ec2 create-application-status-check \
        --protocol https \
        --port 443 \
        --path "/health" \
        --status-code-matcher "200" \
        --aggregation excluded

Associez le contrôle à une instance de test ou à un sous-ensemble de votre parc de production.
Attendez au moins deux intervalles de contrôle (environ deux minutes) pour permettre au contrôle de terminer une évaluation initiale.
Utilisez describe-application-status pour vérifier que le check indique l'état attendu et le code de réponse HTTP.
```
aws ec2 describe-application-status \
        --instance-ids i-0123456789abcdef0
```
Si le contrôle donne les résultats escomptés, mettez à jour le paramètre d'agrégation included pour que le contrôle contribue à l'état général de l'instance et déclenche les actions Amazon EC2 Auto Scaling.
```
aws ec2 modify-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --aggregation included
```

Réseau avancé

Les vérifications de l'état des applications proviennent d'un ENI géré dans le sous-réseau source et le groupe de sécurité que vous spécifiez (ou que vous AWS sélectionnez pour vous). Pour les charges de travail qui nécessitent une disponibilité supérieure à celle fournie par une configuration à source unique, ou pour les charges de travail qui s'exécutent dans des zones locales ou des avant-postes, considérez les modèles suivants.

Local Zones

Pour les instances exécutées dans AWS des zones locales, l'interface réseau élastique (ENI) gérée se trouve dans la AWS région parente et non dans la zone locale. Le trafic de vérification de l'état entre la région mère et vos instances de zone locale passe par la liaison du service de zone locale, ce qui peut entraîner des frais de transfert de données supplémentaires.

Résolution des problèmes

Lorsqu'une vérification de l'état d'une demande indique qu'elle est défectueuse, mais que vous pensez que votre application est saine, vérifiez chacun des points suivants :

Accessibilité des instances. Vérifiez que les contrôles de l'état de l'instance et du système sont effectuésok.
Règle entrante du groupe de sécurité. Le groupe de sécurité de l'instance de destination doit autoriser le trafic entrant sur le port de contrôle en provenance du groupe de sécurité source utilisé par la vérification de l'état de l'application. Pour les chemins réseau AWS gérés, AWS fournit le groupe de sécurité source ; pour les chemins réseau gérés par le client, utilisez le groupe de sécurité que vous avez spécifié comme source.
Pare-feu hôte. Tout pare-feu au niveau de l'hôte (iptables, pare-feu Windows, pare-feu hôte tiers) de l'instance doit autoriser le trafic entrant sur le port de contrôle.
Point final de l'application. L'application doit écouter sur le port et le chemin que vous avez configurés. Confirmez en envoyant une demande locale depuis l'instance (curl http://localhost:PORT/PATH).
Incompatibilité de protocole. Si la vérification est configurée en HTTPS mais que le point de terminaison sert uniquement le protocole HTTP (ou vice versa), tous les appels échoueront.
Matcher de code d'état. Vérifiez que le code de réponse réel de votre application est inclus dans le comparateur de codes d'état que vous avez configuré.
Chemin réseau. Si vous avez configuré des chemins réseau gérés par le client, vérifiez que le sous-réseau source et le groupe de sécurité sont connectés au sous-réseau de destination. Utilisez VPC Reachability Analyzer pour tracer le chemin réseau.
Quota ENI disponible. AWS crée une interface réseau élastique gérée (ENI) dans votre compte pour chaque combinaison de sous-réseau source et de groupe de sécurité. Vérifiez que votre compte dispose d'un ENI disponible dans son quota pour le VPC. Si votre compte a atteint son quota ENI par VPC, vous AWS ne pouvez pas créer l'ENI géré et la vérification ne peut pas être exécutée. Pour plus d’informations, consultez Quotas Amazon VPC.

Codes de motif

La réponse describe-application-status inclut un motif pour chaque vérification. La raison contient le code d'état HTTP renvoyé par votre application (sous forme de numéro), ainsi que le protocole utilisé pour la vérification. Une case est cochée passed si le code d'état renvoyé est inclus dans votre comparateur de codes de statut, et dans le failed cas contraire.

La raison inclut également un code de motif et, pour les HTTP-level résultats, le protocole et le code d'état HTTP renvoyé. La raison contient les champs suivants :

Code

Code de motif du résultat de la vérification de l'état de la demande. L’une des valeurs suivantes :

ResponseCodeMatched: le code d'état HTTP renvoyé par le bilan de santé correspondait au code configuréStatusCodeMatcher.
ResponseCodeMismatch: le code d'état HTTP renvoyé par le bilan de santé ne correspondait pas au code configuréStatusCodeMatcher.
ConnectionTimeout: la connexion à la cible a expiré.
ResponseTimeout: le bilan de santé a expiré en attendant une réponse de la cible.
ConnectionRefused: la cible a refusé la connexion au contrôle de santé.
ConnectionReset: la connexion au bilan de santé a été réinitialisée avant qu'une réponse ne soit reçue.

Pour ResponseCodeMatched etResponseCodeMismatch, le StatusCode champ contient le code d'état HTTP renvoyé et le Protocol champ contient le protocole utilisé pour le bilan de santé. Pour les erreurs de connexion, telles que ConnectionTimeoutResponseTimeout,ConnectionRefused, etConnectionReset, les Protocol champs StatusCode et ne sont pas présents.

Protocol

Protocole utilisé pour le bilan de santé. L'un de HTTP nosHTTPS.

StatusCode

Code d'état HTTP renvoyé par le bilan de santé.

Utilisez le code d'état HTTP renvoyé pour identifier la raison pour laquelle une vérification a échoué. Voici quelques exemples courants :

Code de statut HTTP	Sens typique	Remédiation courante
`200`	L'application a renvoyé une réponse positive.	Aucune. Il s'agit généralement d'un état de santé.
`301`, `302`	L'application a renvoyé une redirection. Les appels de bilan de santé ne suivent pas les redirections.	Dirigez le chemin du bilan de santé vers la destination de la redirection, ou ajoutez le code de redirection à votre comparateur de codes d'état si vous le considérez comme sain.
`401`, `403`	L'application nécessite une authentification ou l'accès au chemin de vérification de santé est refusé.	Configurez le chemin de contrôle de santé pour qu'il ne soit pas authentifié, ou effectuez des contrôles de santé sur un chemin ne nécessitant pas d'informations d'identification.
`404`	Le chemin de contrôle de santé configuré n'a pas été trouvé dans l'application.	Vérifiez que le chemin correspond à l'itinéraire desservi par votre application.
`500`	L'application a renvoyé une erreur interne au serveur.	Examinez les journaux des applications sur l'instance.
`502`, `503`, `504`	L'application est joignable mais signale des problèmes en amont ou de capacité.	Examinez l'état de santé, les dépendances et la capacité des applications. Si votre application renvoie ces codes au démarrage, augmentez`InitializationGracePeriodSeconds`.

Pour la ApplicationStatusReason structure complète, consultez la référence ApplicationStatusReason de l'API Amazon EC2.

Erreurs courantes

Le groupe de sécurité n'autorise pas le trafic entrant en provenance de la source du contrôle de santé sur le port de contrôle.
L'application est liée à l'interface réseau 127.0.0.1 et n'écoute pas cette dernière.
Le chemin de vérification de l'état renvoie une redirection (301, 302) plutôt qu'une réponse positive, et le comparateur de code d'état n'inclut pas le code de redirection.
Le check est configuré pour HTTPS mais l'application ne sert que le HTTP, ou vice versa.
Le démarrage de l'application est plus long que la InitializationGracePeriodSeconds valeur, et Amazon EC2 Auto Scaling remplace l'instance avant qu'elle ne soit prête.

Surveiller les vérifications de l'état des applications

Vous pouvez contrôler les vérifications de l'état des demandes de trois manières :

Amazon CloudWatch. La StatusCheckFailed_Application métrique reflète l'état général de l'application pour l'instance et peut déclencher des alarmes. La métrique est agrégée par instance sur les contrôles associés dont le paramètre d'agrégation estincluded. CloudWatch publie également une métrique par vérification pour chaque vérification associée, nomméeStatusCheckFailed_Application_application-status-check-id.
décrive-l'état de l'instance . Renvoie l'état général de la demande ainsi que les autres informations relatives à l'état de votre instance.
décrire l'état de l'application . Renvoie des résultats détaillés par instance, y compris le statut individuel de chaque check associé et le code d'état HTTP renvoyé par votre application.

Utilisez la CloudWatch métrique pour l'automatisation pilotée par alarme. À utiliser describe-instance-status lorsque vous l'interrogez déjà pour l'état de l'instance. À utiliser describe-application-status pour une visibilité détaillée après chaque contrôle.

Sécurité et autorisations

AWS crée et gère les interfaces réseau utilisées pour les vérifications de l'état des applications via un rôle lié à un service. Aucune configuration IAM n'est requise pour que le service crée ces ENI. Le rôle lié à un service utilise la politique EC2ApplicationStatusChecksServiceRolePolicy AWS gérée.

Pour créer, associer, décrire, supprimer et supprimer vous-même les contrôles d'état des applications, votre utilisateur ou votre rôle IAM a besoin des autorisations Amazon EC2 correspondantes. Consultez la référence de l'API Amazon EC2 pour obtenir la liste complète des actions.

Le groupe de sécurité de votre instance doit autoriser le trafic entrant en provenance du groupe de sécurité source du contrôle de santé sur le port que vous avez configuré. Avec les chemins réseau AWS gérés, AWS fournit le groupe de sécurité source ; avec les chemins réseau gérés par le client, utilisez le groupe de sécurité que vous avez spécifié comme source.

Tarification

Les vérifications de l'état des applications sont facturées en fonction des éléments suivants :

Des frais horaires de 0,01 USD pour chaque interface réseau élastique (ENI) gérée, par zone de disponibilité.
La CloudWatch tarification standard d'Amazon s'applique aux statistiques de vérification de l'état des applications.

Quotas

Les vérifications de l'état des demandes sont soumises à des quotas AWS de service. Pour les noms des quotas, les valeurs par défaut et les descriptions, consultez la section Points de terminaison et quotas Amazon EC2 dans la Référence AWS générale.

Outre les quotas de AWS service qui affectent les interfaces réseau gérées, les contrôles d'état des applications comportent les quotas de service suivants. Vous pouvez consulter votre utilisation et demander des augmentations depuis la console Service Quotas.

Dans ces quotas, une cible est une instance unique surveillée par un bilan de santé. Si plusieurs bilans de santé surveillent une instance, chaque paire d'instances et de bilans de santé est considérée comme une cible distincte. Une association est une règle de balise unique ou un ID d'instance unique que vous associez à un bilan de santé. Chaque ID de règle ou d'instance compte comme une association, quel que soit le nombre d'instances auxquelles il est résolu.

Quota	Par défaut	Ajustable
Bilans de santé par compte	50	Oui, automatiquement
Associations par bilan de santé	50	Oui, automatiquement
Associations par compte	200	Oui, automatiquement
Objectifs par compte	5 000	Oui, sur demande

La plupart des augmentations de quotas sont approuvées automatiquement. L'augmentation des cibles par compte nécessite une demande et une approbation manuelle.

Important

Si le nombre de cibles de votre compte dépasse le quota de cibles par compte, les cibles dépassant cette limite ne sont pas contrôlées et ne signalent pas l'état de la demande. Pour éviter les lacunes dans le suivi, maintenez votre nombre cible dans les limites du quota ou demandez une augmentation.

Nous vous recommandons de créer une CloudWatch alarme Amazon lorsque l'état de votre application vérifie l'utilisation des quotas afin d'être averti avant que vous n'atteigniez un quota. Service Quotas publie des mesures d'utilisation dans AWS/Usage CloudWatch l'espace de noms dans lequel vous pouvez créer l'alarme.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Créez des alarmes de contrôle de statut

Événements de changement d’état