Amazon DEA-C01: Stockage des données et architecture de lac 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.

Ce domaine couvre la manière dont les services de stockage et les moteurs de base de données AWS prennent en charge l’ingestion de données à grande échelle, l’archivage durable, les performances des requêtes et la gouvernance sécurisée dans les plateformes de données modernes. Les ingénieurs de données doivent trouver un équilibre entre le coût, la latence d’accès, la durabilité et le contrôle d’accès affiné lors de l’intégration de services tels que S3, Lake Formation, Redshift et DynamoDB dans les pipelines. La compréhension des compromis entre les classes de stockage, de l’automatisation du cycle de vie, du stockage géré par rapport au stockage local et des schémas de partitionnement permet d’éviter les surprises en matière de performances et de coûts en production.

Classes de stockage et politiques de cycle de vie Amazon S3

S3 propose plusieurs classes de stockage et contrôles de cycle de vie pour optimiser les coûts et les modèles d’accès. Configurez la classe de stockage lors du chargement (console ou CLI :

undefined

) ou utilisez des règles de cycle de vie de compartiment (

undefined

). Intelligent-Tiering déplace automatiquement les objets entre les niveaux d’accès fréquent et peu fréquent et entraîne de légers frais de surveillance ; activez-le pour les modèles d’accès inconnus ou changeants. Utilisez les règles de cycle de vie pour faire passer les objets à GLACIER ou DEEP_ARCHIVE pour une conservation à long terme et pour faire expirer/supprimer les anciennes versions.

Critères de décision et compromis :

Intelligent-Tiering : faible charge opérationnelle pour un accès variable, frais de surveillance mensuels par objet ; idéal lorsque le modèle d’accès est imprévisible.
Glacier vs Glacier Deep Archive : Glacier offre des options de récupération standard et accélérée plus rapides avec un coût de stockage plus élevé ; Deep Archive est le moins cher pour une conservation de plusieurs années avec des temps de récupération standard/en masse (en heures).
Standard-IA vs Intelligent-Tiering : Standard-IA a une facturation minimale de 30 jours et des frais de récupération — à éviter pour les données fréquemment consultées ou les objets à courte durée de vie.

Notes opérationnelles :

Activez le versioning (

undefined

) et le verrouillage d’objet (

undefined

) pour l’immuabilité ; l’activation de MFA Delete nécessite des opérations CLI spéciales et le compte propriétaire du compartiment avec MFA.

Les transitions de cycle de vie s’appliquent aux versions d’objets et peuvent être limitées par préfixe/balises ; utilisez abort-incomplete-multipart-upload pour éviter les fuites de stockage.

Conception de data lake avec S3 et Lake Formation

Concevez un data lake avec S3 comme magasin d’objets central et Lake Formation pour le contrôle d’accès centralisé et le catalogage. Enregistrez les emplacements S3 en tant que ressources Lake Formation, configurez un AWS Glue Data Catalog et utilisez les autorisations Lake Formation pour les bases de données/tables (

undefined

). Lake Formation peut appliquer des contrôles affinés : au niveau de la colonne, au niveau de la ligne (expressions de filtre) et masquage au niveau de la cellule à l’aide de LF-tags et de filtres de données appliqués aux requêtes Glue/Athena.

Principaux schémas de configuration et de gouvernance :

Enregistrer l’emplacement : utilisez la console Lake Formation pour enregistrer

undefined

et attachez un rôle IAM qui permet à Lake Formation d’explorer/lire.

Politiques affinées : définissez des LF-tags et attachez-les aux tables/colonnes ; accordez des autorisations avec une liste de colonnes (column-list) pour restreindre les colonnes, et utilisez des expressions de filtre de ligne (row-filter) pour limiter les lignes renvoyées pour un principal.
N’oubliez pas que les autorisations Lake Formation peuvent remplacer ou bloquer les autorisations IAM S3 pour l’accès Glue/Athena — accordez à la fois l’accès au niveau de Lake Formation et de S3 si nécessaire.

Points de décision :

Utilisez Lake Formation lorsque vous avez besoin d’un catalogage centralisé, de LF-tags et d’une application de politiques affinées sur plusieurs moteurs d’analyse.
Pour un contrôle d’accès simple ou l’accès à des outils externes, envisagez les politiques de compartiment S3 et IAM, mais soyez prudent : les moteurs d’analyse régis par Lake Formation peuvent ignorer les autorisations IAM seules.

Architecture et stockage Amazon Redshift

Redshift sépare le calcul (compute) et le stockage géré sur les nœuds RA3 par opposition aux nœuds DS2 basés sur des SSD locaux. Les nœuds RA3 utilisent le Redshift Managed Storage (RMS) où les données résident sur Amazon S3 géré par le cluster ; choisissez RA3 pour un stockage évolutif avec des performances de requête constantes et la possibilité de payer le calcul séparément. Les nœuds DS2 stockent les données sur des disques locaux à l’instance, ce qui nécessite un dimensionnement et un redimensionnement minutieux lorsque les données augmentent.

Détails de configuration et opérationnels :

Créez un cluster RA3 via la console ou la CLI :

undefined

Commande COPY : doit s’exécuter sur un cluster auquel est attaché un rôle IAM accordant un accès en lecture à S3. Attachez le rôle lors de la création du cluster ou modifiez le cluster pour ajouter des rôles IAM ; l’ARN du rôle (

undefined

) est référencé dans la commande COPY en tant que credentials

undefined

Surveillez les files d’attente WLM, l’accélération des requêtes courtes (short query acceleration), le nettoyage automatique (automatic vacuuming), et utilisez SORT/ENCODE pour optimiser le stockage et les performances.

Comparaison (RA3 vs DS2) :

RA3 : stockage découplé, hiérarchisation automatique des données vers S3 (data tiering), gestion du stockage réduite, idéal pour les ensembles de données en croissance.
DS2 : stockage SSD local, latence plus faible pour les données locales mais capacité limitée et plus difficile à faire évoluer.

DynamoDB et sélection de bases de données spécialisées

Choisissez DynamoDB pour les charges de travail clé-valeur et de documents à grande échelle nécessitant une latence de l’ordre de la milliseconde (single-digit). La conception de la table repose sur la sélection de la clé de partition (et de la clé de tri optionnelle) : utilisez des clés à haute cardinalité et bien distribuées pour éviter les partitions surchargées (hot partitions). Pour les clés séquentielles ou basées sur des horodatages, implémentez un préfixage aléatoire (sharding) ou utilisez des UUID pour répartir les écritures. Utilisez la capacité à la demande pour éviter le provisionnement, mais envisagez la capacité provisionnée avec autoscaling pour les charges de travail prévisibles et pour tirer parti de la capacité adaptative sur les partitions surchargées.

Notes de configuration pratiques :

CLI de création de table :

undefined

Utilisez les GSI pour les modèles d’accès alternatifs, activez le TTL pour l’expiration automatique, et utilisez DynamoDB Streams + Lambda pour les modèles de capture de données modifiées (change-data-capture).
Pour la mise en cache des charges de travail à forte lecture, ajoutez DAX ; pour les requêtes complexes ou les besoins relationnels, choisissez Aurora ou Redshift Spectrum en fonction de la complexité des requêtes et des besoins en cohérence.

Critères de décision pour la sélection du moteur :

Utilisez DynamoDB pour les modèles d’accès prévisibles sur une seule table et une mise à l’échelle massive avec une faible latence.
Utilisez Redshift pour l’analytique complexe et l’OLAP à grande échelle.
Utilisez Aurora pour les charges de travail relationnelles transactionnelles.

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

Utiliser S3 Standard-IA pour des données fréquemment consultées — Standard-IA a une facturation minimale de 30 jours ; utilisez Standard ou Intelligent-Tiering pour les objets à courte durée de vie ou fréquemment consultés.
Oublier que les autorisations Lake Formation prévalent sur les autorisations IAM S3 pour Glue/Athena — accordez à la fois l’accès Lake Formation et S3 lors de l’utilisation de Glue/Athena et vérifiez les autorisations effectives dans la console Lake Formation.
La commande Redshift COPY nécessite un rôle IAM attaché au cluster, pas seulement des autorisations utilisateur — attachez un rôle IAM avec accès à S3 au cluster et référencez son ARN dans les opérations COPY.
Partitions surchargées (hot partitions) dans DynamoDB à cause de clés séquentielles — évitez les clés monotones ; utilisez des clés hachées, des préfixes aléatoires ou des UUID et envisagez la capacité à la demande ou provisionnée avec autoscaling.
Activer S3 Object Lock et MFA Delete de manière incorrecte — Object Lock nécessite l’activation du versioning et des autorisations appropriées ; MFA Delete ne peut être activé/désactivé qu’en utilisant la CLI avec MFA et a des exigences strictes concernant le propriétaire du compartiment.
Transitions de cycle de vie incorrectes sans tester les coûts et les délais de récupération — testez les flux de travail de récupération pour les classes Glacier afin d’éviter des latences et des frais de récupération inattendus.

Problème pratique : Scénario d’utilisation

Acme Media doit stocker 50 To de vidéos brutes ingérées, fournir aux analystes un accès par requête aux métadonnées transformées, et appliquer un accès au niveau des lignes et des colonnes pour différentes unités commerciales tout en minimisant les coûts de stockage.

Ingérer les vidéos brutes dans S3 en utilisant le chargement partitionné (multipart upload), étiqueter les objets par date d’ingestion et par jeu de données, utiliser Intelligent-Tiering pour les modèles d’accès initiaux inconnus.
Configurer des règles de cycle de vie pour faire passer les médias vers GLACIER ou DEEP_ARCHIVE après une période de rétention configurable (s’assurer d’un alignement de plus de 30 jours pour Standard-IA si cette classe est envisagée).
Enregistrer les emplacements S3 dans Lake Formation, créer des crawlers Glue pour peupler le Data Catalog, et accorder des autorisations au niveau des lignes et des colonnes basées sur les étiquettes LF aux unités commerciales.
Stocker les métadonnées organisées dans Redshift RA3 pour l’analytique ; attacher un rôle IAM au cluster pour les opérations COPY depuis S3 et utiliser les opérations VACUUM/ANALYZE pendant les fenêtres de maintenance.
Utiliser DynamoDB avec des clés UUID hachées pour une table de consultation à haut débit des manifestes vidéo et activer la capacité à la demande pour absorber les pics de trafic.

Justification : Cette approche isole les coûts de stockage à froid avec les classes Glacier, utilise Intelligent-Tiering pour les modèles d’accès inconnus, applique Lake Formation pour un contrôle d’accès sécurisé et granulaire sur les moteurs d’analytique, et sélectionne RA3 pour un stockage analytique évolutif tandis que DynamoDB gère les consultations opérationnelles à faible latence.

← Ingestion et collecte des données · Tous les domaines · Catalogage des données et gestion des métadonnées →

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