Performances du calcul et du stockage

Les sujets précédents portaient sur le fait de voir un problème et d'y réagir. Celui-ci porte sur les problèmes qui ne déclenchent aucune alarme : une instance deux fois plus grande que nécessaire, un volume qui épuise ses crédits de burst à 3 heures du matin, un transfert qui utilise un cinquième de la bande passante que vous payez. Rien n'est cassé dans ces trois cas, et c'est bien pour cela qu'ils survivent pendant des mois et que l'examen leur consacre une tâche entière.

Ce que couvre ce sujet

• Les findings, finding reasons et niveaux de risque de Compute Optimizer, et la métrique que CloudWatch ne peut pas collecter sans agent
• Le modèle de crédits CPU des instances burstables de la famille T, et la différence entre les modes standard et unlimited
• Bande passante sur un flux unique et bande passante agrégée, crédits d'I/O réseau, et les compteurs d'allowance ENA qui révèlent un bridage que les moyennes CloudWatch effacent
• Les placement groups cluster, partition et spread, avec les limites et les erreurs de capacité propres à chacun
• Les types de volumes EBS et leurs modèles de provisionnement, le lien entre taille d'I/O et débit, et l'arithmétique des crédits de burst gp2
• Distinguer un volume bridé d'une instance bridée, et modifier un volume en production avec Elastic Volumes
• Les débits de requêtes S3 par préfixe, les réponses 503 Slow Down, les byte-range fetches, le multipart upload, et l'arbitrage entre Transfer Acceleration, DataSync et les appareils Snow
• Les modes de performance, les modes de débit et les politiques de cycle de vie d'EFS, plus les 4 systèmes de fichiers FSx et Mountpoint for Amazon S3

Pourquoi c'est important

La tâche 1.3 du guide d'examen SOA-C03 vous demande d'optimiser les ressources de calcul à partir des métriques de performance et des tags, d'analyser les métriques EBS et de choisir le bon type de volume, de mettre en place des stratégies de transfert S3, d'évaluer les options de stockage partagé, et de régler les instances EC2 avec leur stockage et leur réseau. Ces questions portent rarement sur des définitions. Elles vous donnent un symptôme et une série de chiffres, puis demandent quelle limite vous êtes en train d'atteindre.

Le même motif revient presque partout ici : AWS vous accorde un baseline que vous pouvez tenir indéfiniment, plus un seau de crédits pour aller au-dessus, et l'incident survient quand le seau se vide. Apprenez à reconnaître cette forme une fois, dans CPUCreditBalance, BurstBalance, EBSByteBalance%, les crédits d'I/O réseau et le BurstCreditBalance d'EFS, et une large part de ce domaine devient la même question déguisée sous des noms de services différents.