6.1 - Optimisation des coûts et des performances
L'objectif 6.1 de l'AWS SysOps Administrator couvre l'optimisation des coûts et des performances. AWS Cost Explorer analyse et prévoit les dépenses, AWS Budgets alerte et peut agir sur des seuils de coût, d'usage, de Reserved Instances ou de Savings Plans, et le Cost and Usage Report alimente Athena ou QuickSight ; les cost allocation tags et Cost Anomaly Detection identifient les causes. Trusted Advisor vérifie coût, performance, sécurité, tolérance aux pannes et limites de service, et Compute Optimizer recommande le right-sizing pour EC2, les groupes Auto Scaling, EBS et Lambda. Tu t'engages avec des Savings Plans ou des Reserved Instances pour les charges stables et utilises le Spot pour l'interruptible, tu choisis gp3 plutôt que gp2 et modifies les volumes en ligne, tu déplaces les données S3 vers la bonne classe de stockage via des règles de cycle de vie ou Intelligent-Tiering, tu supprimes les ressources inutilisées, et tu ajoutes du cache pour réduire latence et coût. Attends-toi à des mises en situation sur le bon outil ou la bonne action d'optimisation.
Analyser et prévoir les dépenses = Cost Explorer ; alerter ou agir sur un seuil = Budgets. Recommandations de right-sizing = Compute Optimizer. S'engager pour un usage stable = Savings Plans ; interruptible = Spot.
Questions d'entraînement
1. La finance demande à être notifiée par e-mail quand la facture AWS mensuelle prévue dépasse un montant fixé. Quelle combinaison native répond le plus simplement à ce besoin ?
- Une billing alarm sur EstimatedCharges reliée à un SNS topic e-mail (bonne réponse)
- Une fonction Lambda qui lit la page de facture chaque heure et l'envoie
- Une métrique personnalisée haute résolution publiée par un script maison
- Detailed monitoring activé sur l'utilisateur root du compte payeur
Une billing alarm CloudWatch sur EstimatedCharges (dans us-east-1) publiant vers un SNS topic e-mail est le chemin natif le plus simple. Lire la console via Lambda est fragile et inutile ; detailed monitoring n'a rien à voir avec la facturation.
2. Une revue des coûts trouve detailed monitoring activé sur 500 instances de dev peu utilisées. Quelle est l'implication de coût et le correctif le plus propre ?
- Facturé par instance chaque mois ; désactivez-le si 5 minutes suffisent (bonne réponse)
- Il est toujours gratuit, donc rien à changer sur ces instances de dev
- Il n'affecte que la rétention, il suffit de baisser ce paramètre à la place
- Il est facturé par appel API console, ouvrez donc moins les tableaux de bord
Detailed monitoring entraîne un coût mensuel par instance, donc sur des instances de dev peu utilisées qui n'ont pas besoin de données à 1 minute, le désactiver (retour au basic 5 minutes gratuit) réduit le coût. Il n'est pas gratuit et ne concerne pas la rétention.
3. Quel choix augmente le plus les coûts des métriques personnalisées CloudWatch pour les mêmes données sous-jacentes ?
- Publier en haute résolution (1 seconde) au lieu du standard 1 minute (bonne réponse)
- Regrouper plusieurs valeurs non liées sous un même nom de métrique partagé
- Ajouter un nom de métrique plus long et plus descriptif à la métrique
- Consulter la métrique sur un tableau de bord partagé plus souvent chaque jour
Les métriques personnalisées haute résolution coûtent plus cher que celles à résolution standard pour les mêmes données, à cause de la granularité fine d'une seconde. La longueur du nom et la fréquence de consultation ne changent pas la facturation.
4. Vous voulez provisionner la capacité juste avant la demande grâce à des cycles quotidiens et hebdomadaires appris automatiquement, en évitant le retard de démarrage à froid. Quelle option convient ?
- Predictive scaling sur l'historique (bonne réponse)
- Simple scaling avec un long cooldown
- Une capacité désirée fixe réglée sur le pic
- Des actions planifiées manuelles chaque semaine
Le predictive scaling prévoit la charge à partir de l'historique et provisionne en avance sur la courbe, réduisant le retard à froid. Fixer la capacité désirée au pic gaspille de l'argent hors pic, et les options simple ou manuelle sont réactives ou laborieuses.
5. Un Auto Scaling group utilise des Spot Instances. Quelles deux mesures réduisent l'interruption quand la capacité Spot est reprise ? (Choisissez DEUX.)
- Activer Capacity Rebalancing (bonne réponse)
- Restreindre le groupe à un unique type d'instance
- Désactiver tous les health checks
- Utiliser une mixed instances policy multi-types (bonne réponse)
Capacity Rebalancing lance proactivement un remplacement dès l'avertissement d'interruption Spot, et une mixed instances policy diversifiée élargit le pool pour amortir les reprises. Un seul type réduit le pool, et désactiver les health checks nuit à la fiabilité.
6. Vous voulez une capacité de base stable à faible coût plus une capacité d'appoint bon marché pour les pics, dans un seul Auto Scaling group. Quelle configuration convient ?
- Tout en On-Demand maintenu à la taille maximale du groupe
- Une mixed instances policy : base On-Demand plus Spot (bonne réponse)
- Tout en Spot sans base
- Des Reserved Instances scalées manuellement
Une mixed instances policy fixe une base On-Demand pour la fiabilité et comble les pics avec du Spot moins cher, équilibrant coût et résilience. Tout On-Demand coûte plus, tout Spot met la base en risque, et scaler des Reserved à la main n'est pas élastique.