3.3 - Améliorer la performance, le coût et la résilience des charges existantes

1. Une API dynamique derrière un ALB a des utilisateurs mondiaux qui se plaignent de latence, et l'origine est saturée de requêtes identiques répétées. Quel changement améliore la latence et soulage l'origine ?

• Placer Amazon CloudFront devant l'ALB avec mise en cache et terminaison TLS à la périphérie (bonne réponse)
• Remplacer l'ALB par un Network Load Balancer pour réduire la latence par requête au niveau mondial
• Activer le cross-zone load balancing sur l'ALB dans toutes les zones de disponibilité
• Augmenter le timeout d'inactivité et relever les limites de connexion par nœud de l'ALB

CloudFront termine le TLS et sert les réponses cacheables depuis des points de présence proches des utilisateurs, réduisant la latence et protégeant l'origine des requêtes répétées. NLB, cross-zone et réglage de timeout ne mettent pas en cache ni ne rapprochent le contenu des utilisateurs mondiaux.

2. Un site mondial sert des images et du CSS statiques directement depuis un Application Load Balancer, et les utilisateurs éloignés de la Région se plaignent de lenteurs. Quelle est l'amélioration la plus simple ?

• Placer Amazon CloudFront devant, en mettant en cache les assets statiques aux edge locations (bonne réponse)
• Déployer des piles ALB identiques dans dix Régions et laisser les utilisateurs en choisir une
• Agrandir l'ALB et ses instances cibles pour servir plus de requêtes par seconde
• Stocker les assets sur un volume EBS au niveau d'IOPS provisionnées le plus élevé

CloudFront met en cache le contenu statique aux edge locations proches des utilisateurs, réduisant la latence et déchargeant l'origine avec un minimum de changement. Le choix multi-Région manuel pèse sur les utilisateurs, agrandir l'ALB ne corrige pas la latence liée à la distance, et plus d'IOPS EBS traite le débit disque, pas le délai géographique.

3. Un service de catalogue produits à forte lecture frappe sa base RDS avec les mêmes requêtes coûteuses des milliers de fois par seconde, saturant le CPU. L'équipe veut réduire les lectures répétées avec un minimum de code. Quelle option convient ?

• Déplacer l'intégralité de la table catalogue produits dans une table globale DynamoDB répartie sur plusieurs Régions
• Passer l'instance RDS à la plus grande classe et ajouter des IOPS provisionnées
• Ajouter un cache ElastiCache devant la base pour les résultats de requêtes chauds (bonne réponse)
• Activer les sauvegardes RDS automatiques plus souvent pour réduire la pression

ElastiCache stocke en mémoire les résultats chauds pour que les lectures répétées viennent du cache, réduisant fortement le CPU de la base avec une petite couche ajoutée à l'app. Une migration DynamoDB complète est une grosse refonte, agrandir RDS ne fait que repousser la saturation à coût plus élevé, et des sauvegardes plus fréquentes ajoutent de la charge.

4. Un backend de jeu TCP sensible à la latence tourne dans deux Régions derrière des Network Load Balancers, mais les joueurs sont routés par DNS et atterrissent souvent sur une Région lointaine peu performante. Qu'est-ce qui améliore le routage vers l'endpoint sain le plus proche ?

• Baisser le TTL des enregistrements Route 53 pour que les clients rafraîchissent le DNS plus souvent
• Placer une distribution CloudFront devant les deux Network Load Balancers
• Utiliser AWS Global Accelerator avec les deux NLB comme endpoints derrière des IP anycast (bonne réponse)
• Ajouter plus de nœuds NLB dans chaque Région pour augmenter la capacité de connexions

Global Accelerator fournit des IP anycast statiques et route chaque connexion via le backbone AWS vers l'endpoint sain le plus proche, idéal pour du trafic TCP/UDP sensible à la latence avec bascule rapide. Un TTL bas n'accélère que le rafraîchissement DNS, CloudFront vise le cache HTTP pas le TCP de jeu, et plus de nœuds NLB ne corrigent pas le routage géographique.

5. Une fonction de reporting exécute de lourdes requêtes analytiques en lecture seule sur l'instance RDS MySQL primaire, ralentissant les écritures transactionnelles des utilisateurs. L'équipe veut décharger les rapports sans toucher au chemin d'écriture. Que doivent-ils ajouter ?

• Une seconde instance primaire pour répartir les écritures également entre les deux bases
• Un réplica de lecture RDS et pointer les requêtes de reporting vers son endpoint (bonne réponse)
• Un volume de stockage plus grand à IOPS élevées attaché à l'instance primaire
• Un snapshot cross-Région restauré chaque matin pour la charge de reporting

Un réplica de lecture RDS prend une copie asynchrone du primaire ; pointer les requêtes de reporting vers son endpoint décharge les lectures lourdes pour que le primaire serve les écritures librement. RDS a un seul writer donc un second primaire n'existe pas ainsi, plus d'IOPS n'isole pas la charge de lecture, et un snapshot quotidien donne des données périmées.

6. Un service Java sans état lié au CPU tourne sur des instances x86 On-Demand, coûteux et seulement moyennement rapide. L'équipe peut reconstruire l'image conteneur et veut un meilleur rapport prix-performance sans réécrire l'application. Que doivent-ils évaluer en premier ?

• Déplacer tout le service vers la toute plus grande famille d'instances x86 optimisée pour la mémoire actuellement disponible
• Reconstruire pour des instances Graviton (arm64) afin d'améliorer le rapport prix-performance CPU (bonne réponse)
• Exécuter le service uniquement en Spot pour réduire le coût horaire de calcul au minimum
• Attacher des accélérateurs GPU aux instances pour accélérer le traitement lié au CPU

Les instances Graviton (arm64) offrent généralement un meilleur rapport prix-performance pour des charges liées au CPU et sans état, et comme le conteneur peut être reconstruit pour arm64 l'application reste inchangée. Les familles optimisées mémoire n'aident pas le travail CPU, le Spot vise le prix pas la performance ni la stabilité, et les GPU n'accélèrent pas du code CPU général.