AWS Solutions Architect — Conception d’architectures économiques : 60 questions d'entraînement

Step 1: Analyser caractéristiques des jobs batch. Les jobs de longue durée, tolérants aux interruptions (si on peut relancer ou reprendre), bénéficient grandement de Spot; la planification hors-pointe permet de profiter de capacités Spot disponibles et d'horaires moins chers.

Step 2: Déterminer la stratégie d'achat et le mix d'instances. Combinez Savings Plans Compute pour couvrir le baseline persistant (si une partie de l'usage est régulière) et utilisez des pools Spot via EMR avec stratégie d'instance mixte (instance fleets ou managed scaling) pour réduire le coût du nœud de calcul. Utiliser des points de contrôle (checkpoints) permet de reprendre les jobs si Spot est interrompu.

Step 3: Implémenter orchestration et surveillance. Planifier via AWS Batch ou EMR Steps, activer instance fleets/Spot with fallback on On-Demand pour garantir la fenêtre de traitement, monitorer via CloudWatch et Budgets pour éviter dépassements. Trap: Penser que Reserved Instances Standard sont toujours la meilleure option pour EMR — elles offrent des remises mais manquent de flexibilité pour des clusters dynamiques et peuvent entraîner du gaspillage si les types d'instances changent. Pourquoi chaque réponse échoue ou réussit : 1 (Correct) — Scheduling hors pointe + Spot + Savings Plans pour baseline est un compromis efficace coût/fiabilité; Spot réduit coûts et Savings Plans fournit économie sur consommation persistante. 2 (Incorrect) — Utiliser uniquement des RIs standard est rigide : EMR clusters varient en taille et types d'instances; RIs standard risquent de sous-utilisation ou d'incompatibilité si on change de famille, et empêchent l'exploitation maximale des Spot. 3 (Correct mais contextuel) — On-Demand uniquement diminue la complexité opérationnelle et évite interruptions; si la fenêtre de traitement est étendue et l'entreprise peut réduire la fréquence de reporting, cela peut être acceptable mais potentiellement plus coûteux. 4 (Incorrect) — Migrer entièrement vers Lambda n'est généralement pas viable pour de longues tâches batch ou pour des opérations nécessitant des nœuds de calcul persistants/GRANDES mémoire/CPU ; Lambda a des limites d'exécution et n'est pas optimisé pour de gros jobs analytiques. Considérations coûts/performance/sécurité/résilience : Spot et Savings Plans réduisent coûts mais requièrent design tolérant aux interruptions, checkpointing et fallback On-Demand pour respecter les SLA de traitement.

Step 1: Comprendre les contraintes du système. Il s'agit d'une base RDS de production nécessitant haute disponibilité (Multi‑AZ) et une longévité sur plusieurs années. L'équipe veut aussi la possibilité de changer les familles d'instances pour tests ou optimisation future.

Step 2: Evaluer les options d'achat applicables à RDS. RDS supporte les Reserved DB Instances (DB RIs). Les DB RIs Standard offrent souvent la remise la plus importante pour un engagement donné, mais sont plus rigides. Les DB RIs Convertible permettent de modifier la configuration (p.ex. changer de famille d'instance ou passage entre tailles) en échange d'une flexibilité accrue; elles conviennent donc quand on prévoit d'évoluer sur la durée. Savings Plans ne s'appliquent pas aux instances RDS (ils ciblent EC2, Fargate, Lambda), donc un Compute Savings Plan ne réduira pas la facture RDS. Spot n'est pas adapté aux bases de données relationnelles de production car les interruptions entraîneraient une perte de service ou une complexité de reprise inacceptable.

Step 3: Recommandation opérationnelle. Acheter des Convertible DB RIs avec l'option Multi‑AZ activée offre un bon compromis: réduction des coûts sur le long terme tout en conservant la capacité de changer la famille d'instances au besoin. Surveiller l'utilisation pour ajuster la taille de l'engagement et préférer Convertible si la flexibilité est requise. Trap: Une erreur commune est d'essayer d'appliquer les mêmes stratégies d'optimisation que pour EC2 (Savings Plans) à RDS. RDS a son propre modèle de RI et les Savings Plans ne s'y appliquent pas. Why each wrong answer fails: - Acheter des Reserved DB Instances Standard 3 ans et ne pas utiliser Multi‑AZ: Retirer Multi‑AZ viole l'exigence de haute disponibilité; en outre, Standard RIs sont moins flexibles pour changer de famille d'instances et donc incompatibles avec le besoin de tests ultérieurs. - Souscrire à un Compute Savings Plan: Les Compute Savings Plans ne couvrent pas RDS; ils s'appliquent à EC2, Fargate et Lambda. Ils ne réduiront pas la facture RDS. - Exécuter la base de données sur instances Spot EC2: Les Spot Instances peuvent être interrompues à court terme, ce qui est inacceptable pour une base de données de production nécessitant haute disponibilité. La complexité et le risque opérationnel rendent cette option inappropriée. En résumé, les Convertible Reserved DB Instances avec Multi‑AZ respectent à la fois l'exigence de disponibilité et la nécessité de flexibilité pour tester différentes familles d'instances à l'avenir.

Step 1: Identifier les contraintes — base de données critique sur EC2, usage prévisible (donc candidat pour engagement) mais nécessité potentielle de changer la taille/famille d’instance dans le futur pour ajuster les performances.

Step 2: Comparer les options coût/flexibilité — Standard RIs offrent souvent les remises les plus élevées mais sont moins flexibles pour changer de famille ou d’attributs; Convertible RIs offrent une flexibilité d’échange (changer famille, OS, tenancy) en conservant la valeur résiduelle de l’engagement, au prix d’une remise parfois moindre; Compute Savings Plans sont très flexibles pour l’ensemble du compute mais n’affectent pas d’autres aspects comme si l’environnement nécessite RIs spécifiques (et ne garantit pas la capacité réservée); migrer vers RDS change l’architecture et peut être approprié mais peut nécessiter refactoring, tests et coûts de migration.

Step 3: Recommandation opérationnelle — pour une base de données sur EC2 avec besoin de pouvoir changer la famille d’instances plus tard, les Convertible RIs sont le meilleur compromis: elles réduisent le coût comparé à On‑Demand et permettent d’échanger l’engagement à mesure que les exigences évoluent. Si la migration vers RDS est planifiée et justifiée par les opérations et coûts totaux, alors l’option RDS peut être considérée, mais elle impose un projet de migration. Trap: Beaucoup de candidats pensent que Savings Plans (Compute) sont automatiquement supérieurs; pourtant, pour un serveur de base de données critique et long‑cours sur EC2, un RI convertible donne une garantie d’engagement spécifique à l’instance tout en conservant flexibilité de conversion, ce qui peut être plus adapté selon l’usage. Why each wrong answer fails: - Acheter des Reserved Instances Standard 3 ans pour l’instance actuelle: bien que très économique si la configuration reste immuable, un Standard RI est moins flexible si vous devez changer de famille ou d’attributs; il peut mener à des incompatibilités et du gaspillage si la charge évolue. - Souscrire un Compute Savings Plan couvrant le montant horaire actuel: un Compute Savings Plan est très flexible pour des charges compute variées et offre d’excellentes remises, mais il n’est pas toujours la meilleure option lorsqu’un serveur spécifique nécessite une réservation dédiée (RIs peuvent être mieux alignés si on veut privilégier une instance particulière) et il ne fournit pas la capacité réservée; de plus, si l’instance a des caractéristiques spécifiques (par ex. tenancy, OS) un RI convertible peut mieux couvrir ces besoins. - Migrer vers RDS et utiliser RDS Reserved Instances: migration vers RDS apporte des opérations managées et éventuellement économies, mais elle implique effort, compatibilité, tests et potentiels coûts de migration; si la contrainte est simplement réduire le coût tout en gardant flexibilité d’instance, un RI convertible est une solution moins disruptive. Conclusion: Les Convertible RIs offrent une réduction à long terme et la possibilité d’adapter l’engagement aux changements d’instance, ce qui est pertinent pour une base de données critique sur EC2 susceptible d’évoluer.

Step 1: Evaluer le profil de consommation et la flexibilité. Vous avez un baseline régulier (usage prévisible) et des pics occasionnels. La priorité est réduction des coûts tout en respectant les fenêtres de traitement et sans perte de données. Un Savings Plan Compute (ou un Engagement équivalent sur 1-3 ans) vous permet d’obtenir une remise significative sur toute consommation EC2/Compute indépendamment de la famille d’instances, de la taille et de la zone, ce qui convient à un baseline qui peut évoluer.

Step 2: Gérer les pics avec des options à bas coût tolérantes aux interruptions. Les Spot Instances fournissent le prix le plus bas pour EC2 mais peuvent être interrompues. Pour des jobs non critiques et bien architecturés (checkpointing, redémarrage, tâches atomiques ou répartition fine), Spot est idéal pour absorber les pics à faible coût. En combinant Savings Plans pour le baseline et Spot pour les pics, on obtient le meilleur compromis coût/performance.

Step 3: Implémenter résilience opérationnelle et contrôle des coûts. Concevez vos jobs pour faire des checkpoints fréquents vers S3/EBS, utilisez des stratégies d’Auto Scaling ou Spot Fleet pour regagner capacité automatiquement, et surveillez les interruptions Spot pour rerouter ou relancer les tâches incomplètes. Le Savings Plan réduit la facture sur le baseline même si des Spot/On-Demand sont utilisés pour la surcharge. Trap: Une erreur courante est de penser que l’achat de Reserved Instances Standard 1 an est toujours meilleur ; elles offrent des économies mais sont rigides (famille/zone/OS selon le scope) et peuvent être sous-optimales si vous devez changer fréquemment de type d’instance. De plus, exécuter 100% en On-Demand garantit l’absence d’interruption mais coûte bien plus sans tirer parti des économies possibles. Pourquoi chaque mauvaise réponse échoue: - Acheter des Reserved Instances Standard 1 an pour tous les serveurs: Bien qu’elles puissent réduire le coût pour des instances très stables, elles manquent de flexibilité (surtout si vous avez besoin de changer la famille ou dimensionner différemment durant la période) ; en outre, acheter des RIs pour « tous » les serveurs peut conduire à du gaspillage pendant les évolutions de l’architecture. Un Savings Plan Compute offre une meilleure flexibilité en couvrant plusieurs familles et tailles. - Exécuter 100% en On-Demand: C’est simple et sans interruption, mais c’est la solution la plus coûteuse. Elle ignore les possibilités d’économie importantes offertes par les Savings Plans et les Spots, et va contre l’objectif de minimiser les coûts. Conclusion pratique: Coupler un Savings Plan Compute pour couvrir la consommation régulière et utiliser des Spot Instances pour absorber les pics (avec checkpointing et reprise) fournit un équilibre optimal entre coût, performance et résilience pour un cluster de traitement par lots non critique.

Step 1: Définir les contraintes opérationnelles. La couche web est stateless (bonne propriété pour utiliser des instances éphémères), sensible aux coûts et peut tolérer interruptions ponctuelles mais doit conserver des temps de réponse moyens corrects — cela implique une stratégie qui maximise l’utilisation de Spot tout en offrant un filet de secours pour éviter une dégradation prolongée.

Step 2: Choisir l’architecture et les mécanismes de tolérance. Une Auto Scaling Group avec MixedInstancesPolicy vous permet de combiner différents types d’instances (familles/tailles) et des stratégies d’achat (Spot + On-Demand). Vous pouvez configurer la politique pour préférer Spot mais garder une proportion minimale d’On-Demand pour la stabilité. L’allocation capacity-optimized pour Spot réduit la probabilité d’interruption en ciblant pools Spot offrant la capacité la plus abondante. Configurer un fallback automatique vers On-Demand permet de maintenir la capacité et la latence si Spot n’est plus disponible.

Step 3: Implémenter le monitoring et la gestion des incidents. Surveillez la latence et la santé via CloudWatch/ALB health checks, définissez des politiques d’Auto Scaling basées sur la latence et le throughput, et testez les scénarios d’interruption Spot. Assurez-vous que les images AMI et le démarrage rapide des instances réduisent le temps de remplacement. Trap: Penser que l’utilisation exclusive de Spot est suffisante pour une couche web en production. Sans stratégie de secours, les interruptions Spot peuvent causer des pics de latence ou des erreurs utilisateur. De même, acheter Standard RIs pour minimiser le coût est inefficace lorsque la flexibilité multi-famille et la tolérance aux interruptions sont souhaitées. Pourquoi chaque mauvaise réponse échoue: - Déployer uniquement des Instances Spot sans stratégie de secours: Bien que très économique, cela expose la couche web à des interruptions qui, si fréquentes, vont causer une dégradation visible du service. Sans fallback On-Demand ou proportion minimale garantie d’On-Demand, la SLA utilisateur peut être rompue. - Acheter des Reserved Instances Standard pour minimiser le coût au maximum: Les RIs réduisent le coût mais n’offrent pas l’élasticité multi-pool ni la meilleure optimisation de coût pour un profil très variable ; elles ne tirent pas avantage de la profondeur de réduction des Spot et manquent de la flexibilité d’un MixedInstancesPolicy qui peut combiner Spot et On-Demand dynamiquement. Conclusion pratique: Utilisez un Auto Scaling Group en MixedInstancesPolicy (Spot + On-Demand) avec allocation capacity-optimized pour Spot et un mécanisme de fallback vers On-Demand pour garantir continuité et latence acceptable tout en maximisant les économies.

Step 1: Identifier le profil de consommation — la charge a un socle permanent (prévisible) mais nécessite aussi de la flexibilité pour absorber des pics et potentiellement changer de types d'instances ou régions. Le bon compromis doit réduire le coût du socle tout en gardant la capacité de migrer ou ajuster l'infrastructure.

Step 2: Comparer les modèles de tarification — On‑Demand offre la plus grande flexibilité mais sans réduction de coût significative; Reserved Instances (Standard) donnent de fortes économies mais verrouillent la famille d'instances, le type et (selon l'option) la région; Convertible RIs offrent une certaine flexibilité mais sont plus contraignantes et complexes à gérer; Savings Plans Compute appliquent une réduction en échange d'un engagement horaire de dépense (USD/heure) et s'appliquent automatiquement à l'utilisation EC2, Fargate et Lambda, permettant de changer de famille d'instances ou OS sans perdre le bénéfice.

Step 3: Choisir la solution la plus économique et opérationnelle — pour une entreprise souhaitant économies durables et flexibilité, les Savings Plans Compute sont généralement préférés : ils offrent une réduction proche des RIs tout en couvrant différentes familles et systèmes d'exploitation, simplifiant la gestion et limitant le risque de surcharge financière en cas de modifications d'architecture. Trap: L'idée reçue souvent testée est que les Reserved Instances Standard sont toujours la meilleure option pour réduire les coûts — elles offrent de fortes remises mais peuvent enfermer l'entreprise dans une famille d'instances, ce qui augmente le coût total si l'architecture évolue. Pourquoi chaque mauvaise réponse échoue: - Instances à la demande (On‑Demand): échoue car, bien que flexibles, elles n'apportent pas de réduction pour un socle permanent ; le coût à long terme est plus élevé pour une charge prévisible. - Réservations Standard sur 3 ans: bien qu'offrant des remises élevées, elles limitent la capacité à changer de famille d'instances ou de région sans pénalités (sauf échange limité) et peuvent conduire à un surcoût si vous devez migrer l'instance pour des raisons d'optimisation. - Réservations Convertibles sur 1 an: offrent plus de flexibilité que les Standard mais généralement avec des économies moindres et une complexité de conversion ; elles sont utiles si vous êtes certain de modifier la configuration, mais pour un socle permanent + pics, les Savings Plans Compute donnent une solution plus simple et couvrent aussi d'autres compute services. Conclusion: Savings Plans Compute équilibre réduction de coûts, simplicité opérationnelle et flexibilité — ce qui correspond précisément au besoin décrit.

Step 1: Compréhension du contexte — application multi‑AZ, besoin stable et prévisible d’une capacité minimale (baseline), mêmes familles d’instances et région unique. Cela signifie que l’on peut prévoir et réserver un volume constant de capacité qui sera utilisé la majeure partie du temps.

Step 2: Évaluer les options de réservation — pour un besoin fixe et très prévisible sur une même famille et région, les Reserved Instances (RIs) standards (ou RIs régionales avec scope approprié) offrent parmi les remises les plus élevées. Les RIs régionales peuvent s’appliquer à n’importe quelle AZ dans la même région, donnant de la flexibilité multi‑AZ. Les Compute Savings Plans offrent de la flexibilité et couvrent plus de services mais si la capacité est strictement dans la même famille et région, un RI standard peut fournir la meilleure économie. Spot n’est pas adapté pour la capacité baseline de production critique. On‑Demand reste le plus coûteux.

Step 3: Recommandation opérationnelle — acheter des RIs standard pour la capacité baseline (scope régional pour garder la flexibilité multi‑AZ), et compléter avec On‑Demand ou Auto Scaling pour gérer les pics. Monitorer l’utilisation avec Cost Explorer pour s’assurer que les RIs correspondent bien à la consommation et rebalancer à la fin de la période si nécessaire. Trap: Confusion fréquente — penser que Savings Plans sont toujours meilleurs; alors que Savings Plans sont très utiles pour des charges hétérogènes, si la charge est fixe dans la même famille et région, un RI standard régional peut offrir de meilleures économies. De même, croire qu’un RI réserve une instance physique spécifique est erroné: un RI régional agit comme un descompte qui s’applique au matching de consommation. Why each wrong answer fails: - Ne rien changer et rester sur On‑Demand: option la plus flexible mais la plus coûteuse; pas adaptée à une charge stable et prévisible où des engagements permettraient de réduire significativement le coût. - Souscrire un Compute Savings Plan couvrant le coût total actuel: bien que flexible, un Compute Savings Plan peut être moins optimal que un RI standard quand tout l’usage est concentré dans une seule famille et région; un RI standard régional donne souvent une remise supérieure pour ce cas précis. - Utiliser exclusivement des Instances Spot pour tous les serveurs: trop risqué pour la baseline de production; Spot est sujet à interruptions et n’est pas recommandé pour la capacité minimale nécessaire à maintenir la disponibilité. Conclusion: Pour une capacité baseline stable et prévisible au sein d’une même famille/région, des Reserved Instances standard (scope régional) fournissent le meilleur compromis coût/fiabilité pour réduire les coûts tout en conservant la possibilité d’exploiter plusieurs AZ.

Step 1: Détection des anomalies et définition des seuils. Pour une surveillance proactive, il faut à la fois un service qui détecte automatiquement des anomalies statistiques (p.ex. des hausses inhabituelles) et un mécanisme qui transforme ces signaux en actions de contrôle. AWS Cost Anomaly Detection utilise des modèles ML pour repérer des dérives de coûts par compte, service, ou tag.

Step 2: Automatisation des réponses. AWS Budgets permet de définir des budgets et d'envoyer des notifications mais aussi d'intégrer des Budget Actions (par ex. appliquer une politique IAM, lancer une SNS/Lambda) pour appliquer des mesures correctives (restreindre permissions, déclencher des workflows d'arrêt/mise en pause). Pour arrêter des instances automatiquement on peut combiner une notification Budget -> SNS -> Lambda qui exécute des actions via IAM.

Step 3: Orchestration opérationnelle. Mettre en place Cost Anomaly Detection pour recevoir alertes en quasi temps réel, configurer Budgets avec seuils pragmatiques et Budget Actions, intégrer les notifications avec des runbooks automatisés (Lambda, Systems Manager) pour arrêter/mettre en pause des environnements non critiques, et monitorer via CloudWatch / Dashboard pour l'équipe finance/ops. Trap: penser que Cost Explorer seul suffit est une erreur. Cost Explorer est excellent pour l'analyse rétroactive et la visualisation, mais il ne fournit pas nativement d'actions automatiques ou de détection ML d'anomalies en temps réel. Trusted Advisor donne des recommandations mais ne est pas un système de détection d'anomalies de coûts en production ni d'exécution d'actions automatiques. Why each wrong answer fails: - Configurer AWS Cost Anomaly Detection pour détecter des écarts anormaux et alerter l'équipe: CORRECT PARTIE (option retenue). C'est conçu pour la détection proactive d'anomalies. - Utiliser AWS Budgets avec des Budget Actions pour appliquer automatiquement des changements (ex. attacher une politique IAM, arrêter des instances via Lambda): CORRECT PARTIE (option retenue). Budgets + actions/notifications permet l'automatisation en réponse aux dépassements. - S'appuyer uniquement sur Cost Explorer et des rapports mensuels pour détecter les anomalies: incorrect. Cost Explorer est utile pour l'analyse historique et le reporting, mais n'offre pas la détection ML d'anomalies ni l'automatisation d'actions en temps quasi réel. Des rapports mensuels peuvent arriver trop tard pour limiter une dérive de coût significative. - Activer Trusted Advisor et attendre les recommandations pour réduire automatiquement les coûts: incorrect. Trusted Advisor propose recommandations (sous-utilisation, droitsizing, etc.) mais il ne détecte pas automatiquement les anomalies de facturation ni n'exécute d'actions automatiques pour arrêter des ressources. Il est utile pour l'optimisation mais pas comme mécanisme d'alerte/action en temps réel. Conclusion: combiner Cost Anomaly Detection pour la détection et AWS Budgets (avec Budget Actions et intégration Lambda/SNS) pour l'automatisation fournit une solution robuste pour surveiller et contrôler les dépenses en entreprise.

Step 1: Analyser les exigences — jobs parallélisables, tolérants aux interruptions mais avec contrainte temporelle (fenêtre de 6h). L’objectif est minimiser le coût tout en maximisant la probabilité de terminer dans la fenêtre.

Step 2: Évaluer les mécanismes de fiabilité et coût — Spot est très économique mais sujet aux interruptions; On‑Demand est fiable mais couteux; Reserved Instances réduisent le coût mais exigent engagement et prévision de capacité; une architecture mixte (Auto Scaling mixed instances) permet d’utiliser Spot pour la majorité de la capacité et de basculer automatiquement sur On‑Demand pour maintenir la capacité minimale nécessaire si le Spot est revendu, ce qui réduit le risque de ne pas terminer avant la deadline.

Step 3: Recommandation opérationnelle — déployer un Auto Scaling Group avec MixedInstancesPolicy et Instance Weighting, configurer la proportion cible (par ex. 70–80% Spot, 20–30% On‑Demand) et utiliser une stratégie allocation favorisant la capacité (capacity-optimized). Mettre en place checkpointing des tâches et un gestionnaire de file d’attente (SQS + ECS/Batch) pour relancer automatiquement les tâches interrompues et mesurer le taux d’achèvement pour ajuster la proportion. Trap: Error fréquent — penser que Spot seul suffit si les tâches sont tolérantes aux interruptions. Même tolérante, la contrainte temporelle change le calcul: un taux d’interruption élevé peut empêcher l’achèvement dans la fenêtre. Le mix Spot+On‑Demand réduit le risque tout en conservant la majeure partie de l’économie. Why each wrong answer fails: - Exécuter exclusivement sur Instances Spot avec allocation standard et relancer les tâches après interruption: bien que moins cher, cela augmente fortement le risque de dépassement de la fenêtre; l’allocation standard n’optimise pas la probabilité de capacité disponible et relancer après interruption consomme du temps de traitement supplémentaire. - Achat de Reserved Instances pour couvrir toute la capacité nécessaire la nuit: RIs requièrent un engagement financier et sont adaptés si la capacité nocturne est strictement prédictible et constante; elles manquent de flexibilité pour des variations majeures et imposent des coûts fixes même quand la capacité n’est pas utilisée. - Exécuter sur Instances On‑Demand compte tenu des contraintes temporelles: solution la plus sûre mais la plus coûteuse — ne minimise pas les coûts et n’est pas nécessaire si un design mixte permet de garantir la fenêtre à moindre coût. En bref: Mixed Instances (Spot + On‑Demand fallback) avec stratégie capacity-optimized et checkpointing fournit le meilleur compromis coût-fiabilité pour des batchs soumis à une fenêtre temporelle.

Step 1: Analyser les motifs de charge. Les applications transactionnelles avec pics/spasmes bénéficient d’un modèle de capacité élastique ; les lectures fréquentes et répétitives doivent être servies depuis un cache pour réduire coût et latence.

Step 2: Choisir des services adaptés. Aurora Serverless v2 offre une granularité d’échelle qui ajuste la capacité en fonction du trafic sans nécessiter de provisionnement manuel d’instances dédiées (idéal pour charges variables). Compléter par ElastiCache (Redis ou Memcached) permet de desservir les lectures à haute fréquence depuis la mémoire, réduisant les IOPS et la latence sur la base relationnelle.

Step 3: Implémenter et optimiser. Mettre en place des patterns cache (expiration, invalidation, cache aside), monitorer les hit ratios et régler la configuration Serverless pour le scaling minimal et maximal. Surveiller coûts de cache vs économies sur la base et ajuster réservations/engagements éventuels pour Aurora si usage stable apparaît. Trap: Croire que simplement augmenter la taille de l’instance gère les pics sans coût additionnel de complexité. Monter en instance fixe augmente les coûts permanents et n’offre pas nécessairement d’économie quand la charge est variable ; cela peut mener à sur‑paiement en périodes creuses. Why each wrong answer fails: - Migrer vers Aurora Serverless v2 (correct): permet un dimensionnement fin et facturation à la capacité réellement utilisée, avantageux pour trafic variable sans compromettre la compatibilité SQL et les performances. - Augmenter la taille de l’instance (mauvaise réponse): résout peut‑être un pic ponctuel mais augmente le coût permanent et ne fournit pas d’élasticité dynamique ; ce n’est pas optimal pour des pics intermittents. - Déployer ElastiCache (correct): réduit la charge de lecture sur la base relationnelle, améliore la latence et diminue les coûts opérationnels en réduisant I/O et besoin de scaling DB. - Arrêter la base de données pendant les périodes creuses (mauvaise réponse): pour une base transactionnelle active cela n’est pas viable car vous perdez disponibilité et risquez des interruptions de service ; certaines bases managées ne peuvent pas être simplement arrêtées sans impacts significatifs sur l’application ou les données.

Step 1: Déterminer le profil de charge et les priorités — Le parc est stable et prévisible, l’entreprise est prête à s’engager 3 ans et n’a pas besoin de changer fréquemment la famille d’instances. L’objectif principal est de maximiser la réduction de coût.

Step 2: Comparer les options de rabais/d’engagement — Les Compute Savings Plans offrent une flexibilité (s’appliquent à diverses familles, régions et tailles) et de bonnes économies, mais pour une charge très stable et un engagement long, les Standard RIs 3 ans All Upfront délivrent souvent le plus grand pourcentage de réduction par rapport à On-Demand. Les Convertible RIs (option 3) offrent flexibilité d’échange mais souvent avec un taux de réduction inférieur à des Standard RIs. Spot Instances (option 4) peuvent être extrêmement bon marché mais sont interruptibles et ne conviennent pas à une infrastructure web devant rester disponible en permanence ; recréer un fleet permanent sur Spot sans redondance complexe entraînera un risque de disponibilité et n’est pas une garantie pour une réduction soutenue.

Step 3: Choix opérationnel et compromis — Pour une ferme de serveurs web qui doit être disponible et stable, acheter des Standard RIs 3 ans en All Upfront permet de verrouiller le meilleur tarif à durée longue, minimisant le coût de possession. Le compromis est la moindre flexibilité : toute migration hors de la taille/famille ciblée peut laisser une partie du RI sous-utilisée si le scope n’est pas régional. Pour diminuer ce risque, l’entreprise peut opter pour Regional Standard RIs qui donnent un peu plus de flexibilité dans la taille au sein d’une même famille. Trap: Certains pensent que Savings Plans sont toujours supérieurs ; pourtant pour les engagements très stables et quand on peut accepter l’immobilisation sur un type spécifique, les Standard RIs 3 ans All Upfront peuvent donner la remise la plus forte. Pourquoi chaque mauvaise réponse échoue: - Compute Savings Plan 1 an: Offre flexibilité mais un engagement d’un an donne généralement moins de réduction qu’un engagement de 3 ans ; il est donc moins avantageux pour maximiser l’économie sur 3 ans. - Convertible Reserved Instances 3 ans, paiement All Upfront: Bien que convertibles, elles ont typiquement des remises inférieures aux Standard RIs car la flexibilité a un coût ; si l’entreprise n’a pas besoin de flexibilité, ce n’est pas optimal. - Spot Instances provisionnées en permanence via Spot Fleet: Les Spot Instances sont interruptibles et ne conviennent pas à des serveurs web nécessitant une haute disponibilité sans architecture de tolérance aux interruptions complexe. Elles ne garantissent pas une réduction soutenue pour un service toujours disponible. En synthèse: pour un usage stable et prévisible où la flexibilité n’est pas requise, les Standard Reserved Instances sur 3 ans All Upfront offrent généralement la remise la plus élevée.

Step 1: Évaluer le trajet des données. Les sorties vers Internet depuis S3 et les transferts entre régions ou via NAT génèrent des coûts importants. La mise en cache en périphérie et l’accès direct à S3 depuis des instances EC2 sans sortir vers Internet sont deux leviers efficaces.

Step 2: Mettre en œuvre des optimisations réseau. CloudFront met en cache le contenu dans un réseau global de points de présence, ce qui réduit les egress depuis S3 et améliore la latence utilisateur ; il offre aussi des remises sur le trafic sortant à grande échelle. Pour le trafic intra‑régional depuis EC2, un S3 Gateway VPC Endpoint permet aux instances d’accéder à S3 via le réseau AWS sans passer par une NAT Gateway, économisant ainsi les coûts de NAT et le coût d’Internet egress.

Step 3: Mesurer et ajuster. Après déploiement, surveiller les rapports CloudFront (hit ratio), vérifier la réduction des transferts sortants S3 et valider que les endpoints VPC conduisent bien le trafic interne. Ajuster TTLs CloudFront et les politiques de cache selon les patterns de mise à jour des objets. Trap: Penser que la réplication inter‑région réduit les coûts d’e‑gress. En fait, la réplication multiplie le stockage et génère du trafic de réplication entre régions ; elle est utile pour DR/latence régionale mais pas comme stratégie primaire de réduction des coûts. Why each wrong answer fails: - Déployer CloudFront devant S3 (correct): réduit egress S3, améliore latence mondiale et peut réduire coûts grâce aux tarifs CDN et au caching efficace. - Configurer un NAT Gateway centralisé (mauvaise réponse): NAT Gateways facturent par heure et par Go transféré et deviennent rapidement coûteux; elles n’optimisent pas le trafic vers S3 si un VPC Endpoint aurait évité la NAT. - Activer un endpoint de passerelle VPC (S3 Gateway Endpoint) (correct): permet l’accès privé et gratuit (pas de charge NAT) entre EC2 et S3 dans la même région, économisant les coûts et améliorant la sécurité. - Activer la réplication inter‑région S3 (mauvaise réponse): augmente le stockage et génère coûts de transfert entre régions ; utile pour DR/copie locale mais pas pour réduire coûts d’e‑gress global.