Scénarios de haute performance et d’optimisation des coûts

Scénario : La Database RDS MySQL d’un site d’actualités traite 90 % de trafic de lecture pour le contenu des articles, qui ne change au maximum qu’une fois par heure. Le CPU de la Database atteint en moyenne 80 %, les coûts augmentent et la latence est de 200 ms par requête. Solution : Ajoutez un cluster ElastiCache Redis devant RDS en utilisant le modèle de chargement paresseux (cache-aside). L’application consulte d’abord le Cache : en cas d’accès réussi au Cache, elle renvoie l’article mis en cache en moins de 1 ms. En cas d’échec, elle interroge RDS, renvoie le résultat et l’écrit dans le Cache avec un TTL d’une heure. Résultat attendu : 90 % d’accès réussis au Cache, CPU de RDS inférieur à 20 % et latence inférieure à 5 ms pour les réponses mises en cache.

Scénario : Les utilisateurs de la région Asie-Pacifique subissent des temps de chargement de 2 à 4 secondes pour une application Web hébergée sur EC2 dans us-east-1. L’application diffuse de grandes ressources statiques (images, JS, CSS). Solution : Placez une distribution CloudFront devant l’ALB. Configurez un comportement de Cache pour le chemin /static/* avec un TTL long (par exemple, 1 semaine), afin que les fichiers statiques soient mis en Cache dans les emplacements périphériques CloudFront proches des utilisateurs en Asie. Les requêtes d’API dynamiques contournent le Cache avec TTL=0. Les utilisateurs asiatiques chargent les ressources statiques depuis un emplacement périphérique de Singapour ou de Tokyo en moins de 100 ms, au lieu d’attendre les allers-retours vers us-east-1.

Scénario : Une entreprise possède 500 instances EC2, dont beaucoup ont été provisionnées il y a 3 ans avec de grands types d’instances. Sa facture AWS est élevée, mais elle ne sait pas quelles instances sont surdimensionnées. Solution : Activez AWS Compute Optimizer (gratuit, utilise 14 jours de métriques CloudWatch). Compute Optimizer analyse l’utilisation réelle du CPU, de la mémoire, du réseau et du disque de chaque instance, puis fournit des recommandations pour ajuster leur dimensionnement. Une instance t3.xlarge affichant une utilisation moyenne du CPU de 8 % se verrait recommander un redimensionnement vers t3.small. L’application des recommandations aux 500 instances réduit généralement les coûts EC2 de 20 à 40 %.

Scénario : Une entreprise de génomique exécute chaque nuit des traitements par lots qui durent 8 heures et peuvent être relancés s’ils sont interrompus. Le coût mensuel EC2 On-Demand pour ces traitements est de 10 000 $. Solution : Utilisez des instances EC2 Spot pour le parc de traitement par lots. Les instances Spot correspondent à de la capacité EC2 inutilisée, disponible avec une remise pouvant atteindre 90 %. Pour les traitements par lots tolérant les interruptions, utilisez AWS Batch, qui remet automatiquement en Queue les traitements Spot ayant échoué et utilise un parc mixte (Spot + un minimum d’instances On-Demand en secours). Économies attendues : réduction de 70 à 90 % des coûts de Compute, de 10 000 $ à 1 000–3 000 $ par mois.

Scénario : Un Leaderboard de jeu utilise DynamoDB avec un débit provisionné. Lors du lancement des jeux, le trafic est multiplié par 50 et la Table limite les requêtes. En dehors des lancements, le débit est presque nul : la capacité provisionnée est donc gaspillée. Solution : Passez DynamoDB au mode de capacité On-Demand. On-Demand s’adapte instantanément à n’importe quel débit sans planification manuelle de la capacité et facture chaque requête plutôt que chaque unité provisionnée. Vous ne payez que les requêtes que vous effectuez, sans coût de capacité inactive entre les lancements. On-Demand échange un coût légèrement supérieur par requête contre l’absence garantie de limitation des requêtes et une gestion nulle de la capacité.

Scénario : Une entreprise stocke des millions d’images générées par les utilisateurs dans S3 Standard. Les habitudes d’accès sont imprévisibles : certaines images sont consultées quotidiennement, tandis que d’autres ne le sont pas pendant plusieurs mois. L’entreprise souhaite réduire ses coûts de stockage sans gérer manuellement les politiques de cycle de vie. Solution : Utiliser S3 Intelligent-Tiering. Le service déplace automatiquement les objets entre les niveaux selon les habitudes d’accès : accès fréquent (Standard), accès peu fréquent (30 jours ou plus sans accès), accès instantané aux archives (90 jours ou plus) et accès aux archives (90 jours ou plus, sur activation volontaire). Aucun frais de récupération ne s’applique dans Intelligent-Tiering. Les frais de surveillance s’élèvent à 0,0025 $ pour 1 000 objets par mois, ce qui est négligeable pour les grands ensembles de données.

Scénario : Une jeune entreprise souhaite interroger des tables de lac de données S3. Elle exécute environ 10 requêtes ponctuelles par semaine. Un fournisseur propose Amazon Redshift avec un cluster dc2.large. Solution pour une jeune entreprise : Commencer par Amazon Athena : aucun coût d’infrastructure, vous ne payez que les données analysées (environ 5 $/TB). 10 requêtes par semaine sur des données Parquet correctement partitionnées pourraient coûter moins de 5 $ par mois. Redshift dc2.large coûte environ 180 $ par mois en fonctionnement continu. Redshift devient rentable uniquement lorsque la simultanéité des requêtes est élevée (50 requêtes ou plus par jour) ou qu’une réponse en moins d’une seconde est nécessaire. Le mot-clé « ponctuel et peu fréquent » désigne clairement Athena.

Scénario : Un serveur de base de données relationnelle nécessite 64 000 IOPS avec une faible latence constante. Le volume EBS gp3 actuel atteint sa limite d’IOPS. Solution : Passer à io2 Block Express (un type de volume EBS conçu pour les bases de données exigeant intensivement des opérations d’entrée-sortie). io2 Block Express prend en charge jusqu’à 256 000 IOPS par volume et une latence inférieure à la milliseconde. Cette solution est plus coûteuse que gp3 (0,125 $/Go + 0,065 $/IOPS provisionnée/mois), mais c’est la seule option EBS qui satisfait les exigences de 64 000 IOPS ou plus. Pour les charges de travail de base de données critiques en matière de latence, lorsque la limite de 16 000 IOPS de gp3 est insuffisante, io2 est le seul choix EBS viable.

Scénario : Une entreprise exécute en continu 20 instances EC2 r6i.4xlarge pour une application de production et ne prévoit aucune modification de ses exigences pendant 3 ans. Ses dépenses On-Demand actuelles pour ces instances s’élèvent à 80 000 $ par an. Solution : Acheter des Reserved Instances Standard de 3 ans (ou des Compute Savings Plans) avec un paiement All Upfront afin d’obtenir la remise maximale. Les Reserved Instances Standard offrent une remise pouvant atteindre 72 % par rapport au tarif On-Demand. Les instances fonctionnent 24 h/24 et 7 j/7 avec une charge prévisible : c’est le profil classique adapté aux Reserved Instances. Réduction de coût prévue : 80 000 $ × 0,72 = 22 400 $ par an, contre 80 000 $ par an en On-Demand, soit une économie de 57 600 $ par an.

Scénario : Une entreprise exécute une API REST sur une instance EC2 t3.micro coûtant 8 $ par mois. L’API reçoit 1 million de requêtes par mois, chacune nécessitant 100 ms de traitement. L’équipe demande si Lambda serait moins cher. Analyse : Tarification de Lambda : 1 000 000 de requêtes × 0,0000002 $ = 0,20 $ (coût des requêtes) + 1 000 000 × 0,1 s × 128 Mo de mémoire × tarif = environ 1,67 $ (coût de calcul), soit environ 1,87 $ par mois. Lambda est moins cher qu’EC2 pour cette API à faible trafic. Lorsque le trafic dépasse environ 40 millions de requêtes par mois, EC2 devient moins cher. Utilisez le calculateur de coûts Lambda pour déterminer le seuil de rentabilité de chaque charge de travail.

Scénario : Une API mondiale qui sert des utilisateurs en Europe, aux US et en Asie subit une latence irrégulière, car le trafic emprunte des chemins Internet imprévisibles. CloudFront a été envisagé, mais les réponses de l’API sont dynamiques et ne peuvent pas être mises en cache. Solution : Utiliser AWS Global Accelerator. Le service fournit deux adresses IP anycast statiques à l’échelle mondiale. Le trafic des utilisateurs entre dans le réseau fédérateur mondial AWS au niveau de l’emplacement périphérique AWS le plus proche, puis circule sur le réseau privé AWS jusqu’à l’origine située dans la Region cible, en évitant la portion intermédiaire encombrée de l’Internet public. Global Accelerator améliore de 20 à 60 % le temps de réponse des API dynamiques et assure un basculement instantané lorsqu’un Endpoint de Region devient défaillant.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez étudié des scénarios portant sur : le chargement différé d’ElastiCache pour réduire l’utilisation du CPU de RDS de 80 % à 20 %, les Spot Instances et AWS Batch pour réaliser 70 à 90 % d’économies sur le coût des travaux par lots, Athena pour les requêtes ponctuelles peu fréquentes, par opposition à Redshift pour l’analyse à forte simultanéité, ainsi que S3 Intelligent-Tiering pour les habitudes d’accès imprévisibles sans frais de récupération. La prochaine étape est le projet final : un mini-examen chronométré couvrant plusieurs domaines afin d’évaluer votre niveau de préparation.