Amazon DEA-C01: Optimisation des coûts pour les charges de travail de données — Guide d'étude

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Fait partie du Amazon Data Engineer Associate DEA-C01 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

L’optimisation des coûts pour les charges de travail de données garantit que les pipelines de stockage, de calcul et de traitement des données apportent de la valeur sans dépenses excessives. Les ingénieurs de données doivent équilibrer les performances des requêtes, la durabilité des données et la disponibilité par rapport à des modèles de tarification qui varient selon le service et le modèle d’utilisation. Ce domaine exige une connaissance des classes de stockage et des politiques de cycle de vie, des contrôles au niveau des requêtes et des clusters, de la capacité Spot et réservée, ainsi que des compromis entre le serverless et le provisionné.

Optimisation des coûts de stockage S3

S3 Intelligent-Tiering est la classe de stockage recommandée par défaut pour les jeux de données avec des modèles d’accès imprévisibles : activez Intelligent-Tiering via la console ou l’AWS CLI lorsque la fréquence d’accès aux objets ne peut pas être prévue de manière fiable. Configurez Intelligent-Tiering en tenant compte des frais de surveillance/automatisation (il y a de faibles frais de surveillance mensuels par objet) et du nombre minimum de jours approprié pour les transitions automatiques de niveau (30 jours pour les niveaux d’accès fréquent à peu fréquent). Utilisez des balises d’objet et des règles de cycle de vie pour exclure les petits objets à forte sollicitation pour lesquels les frais de surveillance dépasseraient les économies réalisées.

Utilisez ces modèles opérationnels pour réduire les dépenses S3 :

Exécutez S3 Storage Class Analysis (console > Management > Analytics ou

undefined

) pour identifier les modèles d’accès au niveau des préfixes/balises avant de créer des règles de cycle de vie.

Convertissez les grands jeux de données historiques vers des classes d’archivage (Glacier Flexible Retrieval ou Glacier Deep Archive) à l’aide de transitions de cycle de vie ; définissez le calendrier des transitions pour correspondre aux SLA métier et éviter les récupérations fréquentes de type Expedited.
Consolidez de nombreux petits objets (problème des petits fichiers) en objets plus volumineux (fichiers conteneurs Parquet) pour les charges de travail analytiques afin de réduire les coûts par requête et par GET.

Critères de décision :

Utilisez Intelligent-Tiering pour les jeux de données à accès modéré et imprévisible où les délais de récupération sont flexibles.
Utilisez Standard-IA ou One Zone-IA pour les données rarement consultées mais nécessitant une récupération rapide avec des extractions prévisibles.
Utilisez Glacier Standard/Bulk/Deep Archive pour la conservation à long terme où les récupérations sont rares et peuvent tolérer une latence de quelques minutes à plusieurs heures ; préférez les récupérations de type Bulk/Standard à Expedited pour éviter des frais élevés.

Gestion des coûts d’Athena et de Redshift

Les coûts d’Athena sont proportionnels au volume de données analysées (bytes scanned). Appliquez des contrôles de groupe de travail (console ou

undefined

) pour mettre en œuvre des limites de données analysées par requête et des budgets mensuels par groupe de travail ; activez « Enforce workgroup settings » pour que les requêtes dépassant la limite de données par requête échouent au lieu de s’exécuter. Réduisez le volume de données analysées en convertissant les fichiers source en formats colonnaires compressés (Parquet/ORC), en partitionnant par date ou par colonnes de filtre courantes, en appliquant le predicate pushdown et en utilisant CTAS ou CREATE TABLE AS pour matérialiser des jeux de données optimisés. Utilisez la réutilisation des résultats de requêtes et l’isolation des charges de travail dans des groupes de travail distincts pour éviter les fuites de coûts entre équipes.

Les décisions de coût pour Redshift dépendent de la prévisibilité de la charge de travail et des choix de stockage. Pour une utilisation de calcul de data warehouse stable et prévisible, achetez des Nœuds Réservés (engagement d’un ou trois ans, options de paiement partiel/total initial) pour bénéficier de remises par rapport au modèle à la demande. Pour les charges de travail variables :

Utilisez Redshift Serverless ou des nœuds RA3 avec stockage managé pour découpler le calcul et le stockage.
Utilisez le Concurrency Scaling avec parcimonie (il entraîne des frais supplémentaires mais fournit une mise à l’échelle automatique) et surveillez les crédits.

Points de comparaison :

Nœuds Réservés : idéal pour les clusters à état stable et à long terme ; nécessite un engagement mais offre une remise significative.
À la demande : flexible pour les projets imprévisibles ou à court terme ; coût horaire plus élevé.
Serverless/RA3 avec Spectrum : déplacez le stockage vers S3 et ne payez pour le calcul que lorsqu’il est actif afin d’éviter d’importants engagements réservés.

Stratégies de coût pour Glue et EMR

AWS Glue fournit un ETL serverless avec plusieurs leviers de coût. Pour les tâches batch qui ne sont pas sensibles à la latence, utilisez l’exécution flexible de Glue (tâches Glue Flex) qui peut réduire les coûts jusqu’à environ 34 % par rapport à l’exécution standard de Glue. Configurez les paramètres des tâches Glue dans Glue Studio ou la CLI (

undefined

) pour sélectionner le type de worker et le nombre maximum de DPU, définissez un plafond de DPU maximum raisonnable pour empêcher l’auto-scaling illimité, et utilisez les signets de tâche (job bookmarks) pour éviter un retraitement complet. Pour les charges de travail interactives ou sensibles à la latence, choisissez les types de workers (Standard/G.1X/G.2X) et ajustez le parallélisme de manière responsable.

La réduction des coûts EMR repose sur l’utilisation d’Instances Spot pour les nœuds de tâches (task nodes) tout en conservant les nœuds maîtres (master) et principaux (core) en mode À la demande (configurez des flottes d’instances ou des groupes d’instances dans la console ou via

undefined

). Utilisez Spot uniquement pour les nœuds de tâches, sélectionnez la stratégie d’allocation optimisée pour la capacité (capacity-optimized), et définissez un prix d’enchère/maximum approprié si vous utilisez Spot avec enchères. Protégez l’état du cluster et la résilience des tâches en :

Stockant les données persistantes dans S3 (utilisez EMRFS) plutôt que dans HDFS lorsque vous utilisez des nœuds de tâches Spot.
Utilisant des tentatives automatiques et des flux de travail basés sur des étapes (steps) pour gérer les interruptions Spot.
Employant EMR Managed Scaling pour dimensionner correctement les clusters ; surveillez les politiques de mise à l’échelle pour éviter l’oscillation.

Critères de décision :

Utilisez Glue Flex pour l’ETL de faible priorité, sensible aux coûts, avec une tolérance pour un démarrage plus long ; limitez le nombre maximum de DPU.
Utilisez EMR avec des nœuds de tâches Spot pour les traitements transitoires importants (par ex., batch nocturne), mais conservez les nœuds master/core en mode À la demande ou utilisez des Instance Fleets avec une allocation mixte.

Capacité réservée et Savings Plans pour les services de données

La capacité réservée et les Savings Plans s’appliquent différemment selon les services de données. Pour les services basés sur EC2 (EMR, HBase autogéré, Hadoop personnalisé), utilisez les EC2 Savings Plans ou les Instances Réservées pour couvrir les dépenses de calcul ; sélectionnez des options régionales ou zonales en fonction des besoins de mobilité. Redshift prend en charge l’achat de nœuds réservés pour les clusters provisionnés afin de réduire les coûts horaires pour les charges de travail de data warehouse prévisibles. Les services serverless (Glue, Athena) n’ont pas de réservation de ressources ; optimisez plutôt par la planification des charges de travail et les changements de format de données.

Guide d’achat pratique :

Achetez des Nœuds Réservés Redshift pour les charges de travail de data warehouse en régime permanent avec une utilisation connue (évaluez les durées de 1 an ou 3 ans, et les options de paiement total/partiel/aucun paiement initial).
Utilisez les EC2 Savings Plans pour couvrir les dépenses prévisibles d’EMR/EC2 sur plusieurs familles d’instances ; les Savings Plans offrent de la flexibilité en cas de changement de famille d’instance ou de région.
N’achetez pas de réservations pour les services serverless ; optimisez plutôt les modèles d’utilisation, la planification et l’organisation des données.

Pièges courants et critères de décision

Athena analyse la table entière sans partitionnement — partitionnez toujours les grandes tables de séries temporelles par date ou par d’autres colonnes à haute cardinalité fréquemment filtrées et convertissez-les en Parquet/ORC pour minimiser les octets analysés.
L’auto-scaling des DPU de Glue peut sur-provisionner — définissez un plafond maximal de DPU dans la configuration de la tâche (console ou

undefined

) et choisissez des types de workers appropriés pour garder des coûts prévisibles.

Frais de récupération S3 Glacier — évitez la récupération accélérée (Expedited) sauf si c’est critique pour l’entreprise ; planifiez des récupérations Standard ou en masse (Bulk) et définissez des transitions de cycle de vie avec des SLAs réalistes.
Les nœuds master et core d’EMR ne devraient pas utiliser d’instances Spot — configurez les nœuds master/core en tant qu’instances à la demande (On-Demand) et n’assignez des instances Spot qu’aux nœuds de tâches (task nodes) en évitant ou en répliquant l’état HDFS.
De nombreux petits objets S3 gonflent les coûts des requêtes et ralentissent les analyses — compactez les petits fichiers en fichiers colonnes plus volumineux lors de l’ingestion.
Une dépendance excessive à la mise à l’échelle de la simultanéité (concurrency scaling) ou à l’auto-scaling non géré peut augmenter les frais horaires — surveillez les métriques de mise à l’échelle, fixez des limites et utilisez la capacité réservée lorsque les charges de travail sont prévisibles.

Problème pratique : Réduction des coûts de l’ETL nocturne d’Acme Analytics

Acme Analytics exécute un ETL nocturne et des analyses ad-hoc quotidiennes ; les dépenses cloud mensuelles ont grimpé en flèche en raison de l’augmentation du stockage S3 brut et des heures Redshift à la demande. L’entreprise a besoin d’une réduction de 35 % sans impacter les SLAs nocturnes.

Exécutez S3 Storage Class Analysis et appliquez des règles de cycle de vie pour déplacer les fichiers bruts froids de plus de 90 jours vers Glacier Flexible Retrieval (planifiez des récupérations en masse/Standard).
Convertissez les CSV bruts en Parquet partitionné et compressé et compactez les petits fichiers ; stockez les jeux de données optimisés sous des préfixes distincts pour Athena/Redshift Spectrum.
Créez des groupes de travail (workgroups) Athena avec des limites de données analysées par requête et appliquez les paramètres des groupes de travail ; activez la réutilisation des résultats de requête et définissez un budget mensuel par groupe de travail.
Migrez l’ETL par lots vers des tâches Glue Flex pour les transformations non urgentes, définissez des plafonds de DPU maximaux et planifiez-les pendant les heures creuses ; conservez une flotte Glue standard plus petite pour les tâches urgentes.
Redimensionnez (Right-size) Redshift : achetez des Nœuds Réservés sur 1 an pour le calcul de base stable, déplacez les données historiques vers S3 et utilisez Spectrum pour les requêtes peu fréquentes, et n’activez la mise à l’échelle de la simultanéité (concurrency scaling) qu’avec une surveillance.

Justification : La stratégie combine l’optimisation du format des données et du cycle de vie (réduisant les coûts de stockage et d’analyse), l’exécution serverless à moindre coût pour les tâches flexibles (Glue Flex), la gouvernance des requêtes (groupes de travail Athena) et la capacité réservée pour le calcul soutenu afin de maximiser les remises tout en préservant la disponibilité et la performance.

← Surveillance et dépannage des pipelines de données · Tous les domaines · Qualité →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →