Une entreprise exploite une application web sur une seule instance EC2 qui ralentit aux heures de pointe lorsque l'utilisation du CPU dépasse 95 %. Un script user-data installe des packages personnalisés sur l'instance au lancement, ce qui prend plusieurs minutes. L'entreprise va créer un groupe Auto Scaling à l'aide d'un modèle de lancement, avec des types d'instances mixtes, des capacités de CPU variables et une limite de capacité maximale. L'entreprise souhaite réduire la latence de l'application lorsque de nouvelles instances sont lancées lors d'événements de mise à l'échelle. Quelle approche répond à cette exigence ?

La politique de mise à l'échelle dynamique est appropriée car elle ajuste la capacité en fonction de la demande réelle (utilisation CPU élevée). Les pools chauds permettent de maintenir des instances pré-initialisées et prêtes à l'emploi, réduisant ainsi la latence de démarrage lors des événements de mise à l'échelle. Les hooks de cycle de vie Auto Scaling sont le mécanisme correct pour exécuter des actions personnalisées, comme l'installation de packages via le script user-data, pendant le démarrage ou l'arrêt d'une instance, garantissant que l'instance est entièrement configurée avant de recevoir du trafic. Les autres options sont incorrectes car : Une politique de mise à l'échelle prédictive est utile pour anticiper la demande, mais ne résout pas la latence de démarrage des instances. L'utilisation d'une politique de maintenance d'instance pour exécuter le script user-data n'est pas une fonctionnalité standard d'Auto Scaling pour l'initialisation des instances. Définir le temps de préchauffage à 0 seconde n'est pas recommandé car cela enverrait du trafic à une instance non initialisée, augmentant la latence.