Les statuts d’application EC2 détectent une application morte quand la machine, elle, est saine
Amazon EC2 introduit des statuts d’application qui sondent vos endpoints HTTP ou HTTPS toutes les 60 secondes et signalent une application défaillante même quand l’instance est en bonne santé. Associés à Auto Scaling, ils déclenchent le remplacement automatique de l’instance dès que l’application ne répond plus.
10 août 2026. AWS annonce les application status checks, une nouvelle sonde EC2 qui surveille la couche applicative. 60 secondes. La cadence à laquelle la sonde interroge vos endpoints HTTP ou HTTPS. 0,01 dollar. Le coût horaire par interface réseau gérée, par zone de disponibilité.
Le problème que cette fonctionnalité résout est vieux comme le cloud : les statuts EC2 historiques vous disent si la machine est vivante, jamais si l’application qu’elle héberge répond. Entre les deux, il y a toute la distance qui sépare « l’instance est saine » de « le service est en panne ».
Ce que les statuts d’instance ne voient pas
Depuis toujours, EC2 propose deux niveaux de statut. Le instance status check vérifie le matériel et l’hyperviseur ; le system status check vérifie que le système d’exploitation et la pile réseau de l’instance fonctionnent. Les deux répondent à une seule question : l’instance est-elle joignable et démarrée ?
Ils ne répondent jamais à celle qui compte en production : le serveur web accepte-t-il encore des connexions ? Le daemon Docker tourne-t-il ? La configuration réseau est-elle correcte ? L’interface passe-t-elle encore du trafic ? Une instance peut afficher 2/2 checks passed pendant que le processus applicatif est bloqué, que le port écoute plus rien, ou qu’un changement de configuration a cassé la pile réseau.
Les trois niveaux de statut se complètent sans se remplacer :
| Statut | Ce qu’il vérifie | Angle mort |
|---|---|---|
| Instance | Matériel, hyperviseur, connectivité | Les processus applicatifs |
| Système | OS et pile réseau de l’instance | La santé du service exposé |
| Application | Réponse HTTP/HTTPS d’un endpoint | Aucun — c’est le niveau service |
Jusqu’ici, combler cet angle mort relevait du bricolage maison : une sonde CloudWatch custom, un health-check de load balancer, un agent de supervision, ou un simple cron qui teste un endpoint. Autant de pièces à maintenir, et surtout autant de signaux déconnectés d’Auto Scaling.
Comment ça marche
Les application status checks ramènent cette surveillance dans le plan de contrôle EC2. Vous définissez un check en précisant le protocole (HTTP ou HTTPS), le port, le chemin (par exemple /health) et le matcher de codes de statut qui signale une application saine (par exemple 200). EC2 envoie alors une requête à ce port et ce chemin toutes les 60 secondes.
Le jugement est binaire et lissé. Un check est marqué impaired après un certain nombre d’échecs consécutifs, et repasse healthy après un certain nombre de succès consécutifs — deux par défaut, réglable. La requête part en HTTP/2, et la variante HTTPS ne valide pas le certificat du serveur.
L’architecture réseau mérite d’être comprise. La sonde n’arrive pas de l’extérieur : AWS crée une ENI gérée dans votre VPC, une par combinaison de sous-réseau source et de groupe de sécurité ayant des instances associées. Le trafic part d’instances gérées par AWS dans la même zone de disponibilité que la cible, transite par le réseau interne, et ne traverse jamais l’Internet public. Cette ENI gérée ne compte pas dans la limite d’ENI par instance, mais bien dans le quota de Network interfaces per Region.
L’intégration Auto Scaling change la donne
C’est le vrai apport. Les application status checks s’intègrent nativement à Auto Scaling : quand une application est marquée impaired, le groupe peut remplacer l’instance automatiquement. La boucle « détection → réaction » se ferme sans lambda de glue, sans alarme custom, sans intervention humaine.
L’association se fait par ID d’instance ou par tag — y compris le tag système aws:autoscaling:groupName, qui permet d’associer un check à toutes les instances d’un groupe en une commande. Chaque check peut être marqué included (contribue au statut global et déclenche Auto Scaling) ou excluded (reporte son statut sans déclencher de remplacement). Le workflow recommandé pour ajouter un check à une charge en production est justement de le déployer en excluded d’abord, de valider, puis de le basculer en included.
Le statut global d’une instance agrège tous les checks associés : ok si tout passe, impaired si au moins un échoue, plus les états transitoires initializing, insufficient-data et suppressed.
La mise en place en quelques commandes
Le flux complet tient en trois étapes via l’AWS CLI. Créer le check :
aws ec2 create-application-status-check \
--protocol https --port 443 --path "/health" \
--status-code-matcher "200"L’associer à des instances, par ID ou par tag de groupe :
aws ec2 associate-application-status-check \
--application-status-check-id asc-1234567890abcdef0 \
--target-tag-associations Key=aws:autoscaling:groupName,Value=my-asgPuis lire le statut par instance :
aws ec2 describe-application-status --instance-ids i-0123456789abcdef0Pour les VPC à segmentation stricte, des règles de pare-feu ou des contraintes de conformité, le mode customer-managed network paths (paramètre --health-check-paths) vous laisse choisir les sous-réseaux et groupes de sécurité sources et destinations ; sinon, AWS les sélectionne pour vous.
Pendant les déploiements, on suspend le jugement
Un statut impaired déclenche un remplacement d’instance — exactement ce qu’on ne veut pas au milieu d’un déploiement canari ou d’un patch en place. La documentation prévoit l’état suppressed : l’évaluation du check est suspendue pour l’instance le temps d’une maintenance. C’est la différence entre une sonde qui signale un incident et une sonde qui en provoque un pendant la fenêtre de mise à jour.
Le lissage par défaut va dans le même sens : deux échecs consécutifs avant de basculer impaired, deux succès avant de repasser healthy. Un simple redémarrage — pendant lequel l’application ne répond pas, mécaniquement — ne déclenche donc pas de remplacement inutile.
Limites et coûts
Le service n’est pas gratuit, mais le tarif est prévisible : 0,01 dollar par heure et par ENI gérée, par zone de disponibilité, plus le tarif CloudWatch standard pour les métriques. Les quotas sont généreux — 50 checks par compte, 50 associations par check, 200 associations par compte, 5 000 cibles par compte — et pour la plupart ajustables automatiquement.
Deux limites de conception à garder en tête. La sonde ne parle que HTTP et HTTPS : pas de TCP brut, pas de gRPC health-check, pas d’exécution de script. Et chaque check est associé à une seule version IP (IPv4 ou IPv6) ; surveiller les deux impose deux checks. Pour une application qui ne répond qu’en TCP ou qui exige une validation applicative riche, le health-check du load balancer ou un CloudWatch custom reste nécessaire.
Côté observabilité, les statuts alimentent des métriques CloudWatch (au tarif standard) et des événements de changement d’état : vous pouvez brancher une alarme sur le passage à impaired, ou un système d’automatisation sur l’événement, sans interroger l’API à la main.
Verdict
Si vous tournez sur EC2 avec Auto Scaling et un endpoint HTTP, les application status checks remplacent la plupart de vos sondes maison : ils détectent l’application morte là où les statuts d’instance détectent la machine morte, et ils ferment la boucle de remplacement sans colle externe. Déployez-les en excluded d’abord, puis basculez en included une fois le matcher validé.
Si vos applications ne répondent pas en HTTP — services TCP purs, gRPC avec probes riches, contrats de santé complexes — conservez votre supervision actuelle. Le service comble un angle mort précis, il ne remplace pas un système d’observabilité complet.
Le signal de fond : en déplaçant la détection d’incident de la VM vers l’application et en la reliant nativement à Auto Scaling, AWS acte que la santé d’une charge de travail se mesure au niveau du service, pas du serveur. C’est une brique de plus vers des groupes qui se réparent tout seuls.