Amazon ECS : l'autoscaling à 20 secondes mis à l'épreuve

Une minute, c'est long quand un pic de trafic arrive. L'autoscaling d'Amazon ECS peut s'appuyer depuis juin sur des métriques de CPU et de mémoire publiées toutes les 20 secondes, au lieu de 60. Dans un article technique publié le 3 novembre, AWS détaille ses mesures : avec ces métriques, le déclenchement de la montée en charge passe de 363 à 86 secondes, soit 76 % plus vite. De quoi aider les équipes à décider si l'option vaut son coût.

Ce que change la haute résolution

Annoncée le 18 juin 2026, la fonction permet aux politiques de target tracking d'Application Auto Scaling de réagir à des métriques à 20 secondes. AWS indique avoir aussi optimisé la chaîne de publication de ces métriques vers CloudWatch, afin qu'elles arrivent avec moins de délai.

Selon l'annonce, la fonction est disponible dans toutes les régions commerciales d'AWS et dans GovCloud (US), pour les trois modes de calcul d'ECS : Fargate, ECS Managed Instances et EC2. Container Insights n'est pas nécessaire.

D'après AWS, le délai entre le déclenchement et le placement des nouvelles tâches tombe de 386 à 109 secondes (-72 %).

Un protocole de test détaillé

Les mesures ont été réalisées dans la région US West (Oregon), avec des tâches de 1 vCPU, une politique visant 60 % de CPU moyen et une plage de 1 à 128 tâches. La charge était générée avec k6, et les résultats sont des médianes sur 24 exécutions par scénario.

L'indicateur principal est le temps de non-respect du SLA : la durée cumulée des fenêtres de 6 secondes où plus de 10 % des requêtes ont échoué (erreur, requête abandonnée ou réponse de plus de 2 secondes). Trois profils ont été testés, avec un écart variable entre métriques à 60 et à 20 secondes :

• montée progressive (application Rust) : de 2 013 à 633 secondes sur Fargate, de 1 692 à 30 secondes sur Managed Instances ;
• pics répétés (application Java) : de 2 232 à 1 131 secondes sur Fargate, de 1 593 à 750 secondes sur Managed Instances ;
• croissance régulière (application Node.js) : de 750 à 3 secondes sur Fargate, de 969 à 102 secondes sur Managed Instances.

AWS note aussi une réduction en charge plus rapide, donc moins de tâches payées inutilement, et des résultats plus réguliers d'une exécution à l'autre. Ces chiffres restent ceux de l'éditeur, obtenus sur des charges synthétiques : chaque équipe a intérêt à mesurer l'effet sur sa propre application.

Activer l'option, et ce qu'elle coûte

L'activation se fait en deux temps. Il faut d'abord activer les métriques à 20 secondes dans la configuration de surveillance du service, puis attendre la fin du déploiement pour un service existant. On associe ensuite une politique de target tracking utilisant les métriques prédéfinies ECSServiceAverageCPUUtilizationHighResolution ou ECSServiceAverageMemoryUtilizationHighResolution.

La fonction elle-même n'est pas facturée, et les métriques standard à 60 secondes restent gratuites. En revanche, les métriques à 20 secondes sont des métriques CloudWatch haute résolution, facturées au tarif de CloudWatch. Sur un grand nombre de services, la ligne peut compter.

Pour les équipes qui suivent l'évolution des services de conteneurs d'AWS, ce gain de réactivité s'ajoute à un calendrier chargé, avec notamment la fin du support étendu de Kubernetes 1.31 sur EKS le 26 novembre.