AWS Certified Data Engineer Associate
Dernière révision : mai 2026
Une référence concise des modèles d'architecture évalués par l'examen DEA-C01. Lisez de haut en bas ou sautez à une section.
Choisir un service Kinesis pour l'ingestion en continu.
Traitement contrôlé par le consommateur en moins d'une seconde → Kinesis Data Streams. Livraison entièrement gérée vers S3/Redshift/OpenSearch avec conversion de format optionnelle → Kinesis Data Firehose.
Pourquoi: KDS conserve les enregistrements (24h–365j) et prend en charge plusieurs consommateurs. Firehose n'a pas de relecture ; il échange la relecture contre une livraison sans opérations.
Le flux atteint des erreurs ProvisionedThroughputExceeded pendant les pics.
Redimensionner les shards (Reshard). Chaque shard prend en charge 1 Mo/s ou 1 000 enregistrements/s en ingestion, 2 Mo/s en sortie. Utiliser des clés de partition uniformes ; activer l'Enhanced Fan-Out pour >2 Mo/s par consommateur.
Pourquoi: Les clés de partition "chaudes" concentrent le trafic sur un seul shard. Les clés aléatoires ou basées sur le hachage répartissent la charge.
La charge de travail de streaming est irrégulière et imprévisible ; le redimensionnement manuel des shards (resharding) est une difficulté opérationnelle.
Kinesis Data Streams en mode capacité à la demande. S'adapte automatiquement jusqu'à 200 Mo/s par défaut ; paiement au volume de données.
Plusieurs consommateurs lisant le même flux atteignent la limite de lecture de 2 Mo/s/shard.
Enhanced Fan-Out. Chaque consommateur obtient 2 Mo/s/shard dédiés via SubscribeToShard basé sur HTTP/2 en mode push.
Maximiser le débit d'ingestion depuis l'application côté producteur.
Kinesis Producer Library (KPL) avec agrégation + collection. Regroupe plusieurs enregistrements utilisateur en un seul enregistrement Kinesis jusqu'à 1 Mo ; réduit le coût des opérations PUT.
Pourquoi: Un PutRecord unique est limité en débit et coûteux à 50k événements/s. KPL agrège côté client.
Déposer un flux de clics JSON dans S3 au format Parquet, partitionné par heure d'événement.
Firehose avec conversion de format d'enregistrement (JSON → Parquet) utilisant une table Glue Data Catalog + partitionnement dynamique sur l'horodatage de l'événement.
Pourquoi: Parquet + partitionnement réduit considérablement le coût de scan d'Athena. Le partitionnement dynamique évite une étape ETL distincte.
Certains enregistrements échouent lors de la transformation ou de la livraison Firehose ; il faut les capturer pour relecture.
Configurer une sauvegarde S3 avec `AllData` ou `FailedDataOnly`. Les enregistrements échoués sont déposés au préfixe configuré avec les métadonnées d'erreur.
Assurer aucune perte de données dans MSK si un AZ de broker échoue.
Facteur de réplication ≥ 3 sur 3 AZ et `min.insync.replicas=2` avec `acks=all` du producteur. Activer le Multi-AZ via KRaft sans ZooKeeper ou un placement de broker sur 3 AZ.
Diffuser des données de MSK vers S3, OpenSearch ou RDS sans gérer un cluster Kafka Connect.
MSK Connect avec un connecteur géré (Confluent S3 Sink, Debezium pour CDC). Met à l'échelle automatiquement les workers par WCU.
Un topic stocke la dernière version d'un enregistrement par clé ; les anciennes versions peuvent être supprimées.
Définir `cleanup.policy=compact` pour le topic. Kafka conserve la valeur la plus récente pour chaque clé ; les enregistrements plus anciens avec la même clé sont éligibles à la compaction.
Transfert hebdomadaire récurrent de 10 To d'un NFS sur site vers S3 via Direct Connect.
AWS DataSync avec agent sur site + tâche planifiée. Vérifie l'intégrité des données, prend en charge les transferts incrémentiels, en parallèle.
Pourquoi: DataSync est plus rapide que aws-cli sync et gère nativement la limitation de bande passante, les tentatives et la vérification.
Extraire des données des API SaaS (Salesforce, ServiceNow, Zendesk) vers S3 selon un calendrier.
AWS AppFlow. Connecteurs gérés, OAuth pris en charge, déclenché par calendrier ou événement, écrit du Parquet vers S3.
Répliquer les changements en cours d'un SQL Server sur site vers Aurora MySQL avec un temps d'arrêt minimal.
AWS DMS avec tâche de chargement complet + CDC. Utiliser Schema Conversion Tool (SCT) pour la conversion de schémas/code hétérogènes avant DMS.
L'instance de réplication DMS échoue — la réplication est interrompue.
Activer le Multi-AZ sur l'instance de réplication. Standby synchrone dans une autre AZ ; basculement automatique.
Besoin d'analyses en quasi temps réel sur les données OLTP Aurora sans pipeline ETL.
Intégration Aurora zero-ETL vers Redshift. Réplication continue des données Aurora vers Redshift ; les requêtes voient les nouvelles données en quelques secondes.
Pourquoi: Élimine les pipelines DMS / Glue / CDC personnalisés pour le cas d'utilisation OLTP vers entrepôt de données.
Déplacer 100 To d'archives historiques d'un site sur site vers S3 ; bande passante limitée.
AWS Snowball Edge Storage Optimized. Dispositif physique expédié sur site ; copier les données ; renvoyer.
Le JSON source contient des tableaux imbriqués ; l'analyse relationnelle en aval nécessite des lignes aplaties.
Transformation `Relationalize` de Glue PySpark (ou `explode()` dans DataFrame) qui aplatit les tableaux imbriqués en lignes/tables séparées.
Glue Crawler déduit des types ambigus (`choice<int,string>`) à partir de données CSV désordonnées.
Appliquer la transformation `ResolveChoice` — convertir en type spécifique ou projeter en struct. Ou corriger à la source en imposant un schéma.
Le job Glue ETL s'exécute toutes les heures sur des données S3 croissantes ; besoin de traiter uniquement les nouveaux fichiers.
Activer les signets de job Glue (Glue job bookmarks). Glue suit les fichiers/partitions traités et les ignore lors des réexécutions.
Pourquoi: Évite le retraitement de l'ensemble des données. Requis pour les pipelines ETL incrémentiels.
Le job Glue Spark échoue avec une erreur OutOfMemoryError sur le pilote lors de grandes agrégations.
Passer aux workers G.2X ou G.4X (plus de mémoire pilote) ou activer les prédicats push-down `--enable-glue-datacatalog` pour réduire les données mélangées.
Exécuter un Spark Structured Streaming continu sur une source Kinesis avec une infrastructure gérée.
Job ETL de streaming AWS Glue. Spark Structured Streaming en arrière-plan ; point de contrôle vers S3.
Un analyste commercial doit nettoyer et transformer des données sans écrire de code.
AWS Glue DataBrew. Transformations visuelles basées sur des recettes (plus de 250), profilage, lignage. Sortie vers S3, Redshift, RDS.
Exécuter un job Glue ETL uniquement après que le Crawler ait mis à jour avec succès le Data Catalog.
Workflow Glue avec déclencheurs conditionnels. Succès du Crawler → déclenchement du job ETL. Échec → ignorer / alerte.
Le Crawler déduit toutes les colonnes CSV comme `string` — nécessite des types date et nombre.
Ajouter un classificateur Glue personnalisé (modèle Grok ou indice de colonne) avant le crawling. Alternativement, pré-écrire une ligne d'en-tête avec des types explicites.
Plusieurs producteurs/consommateurs sur Kafka ont besoin d'une évolution de schéma sans se perturber mutuellement.
AWS Glue Schema Registry avec des règles de compatibilité (BACKWARD/FORWARD/FULL). Les producteurs enregistrent le schéma ; les consommateurs récupèrent + valident.
Choisir entre EMR et Glue pour l'ETL Spark.
Spark personnalisé de longue durée avec un réglage approfondi, plusieurs frameworks (Hive, Presto, Flink) → EMR. ETL serverless à paiement par tâche avec intégration Glue Data Catalog → Glue. Spark irrégulier/imprévisible → EMR Serverless.
Jobs Spark/Hive intermittents ; souhaite zéro opération de cluster et pas de calcul inactif.
EMR Serverless. Pools de capacité pré-initialisés pour des démarrages à faible latence ; mise à l'échelle par job ; paiement par heure vCPU.
Combiner des nœuds de cœur à la demande + des nœuds de tâche Spot pour un EMR optimisé en termes de coûts.
Instance Fleets avec capacité cible par type. Flotte de cœur à la demande pour la stabilité HDFS ; flotte de tâche Spot avec des types d'instances diversifiés.
Standardiser sur Kubernetes ; souhaite que les jobs EMR Spark partagent le cluster avec d'autres charges de travail.
EMR sur EKS. Spark s'exécute en tant que pods sur un cluster EKS existant ; partage d'infrastructure et de rôles IAM via IRSA.
Streaming avec état avec agrégations par fenêtre et sémantique "exactement une fois".
Kinesis Data Analytics pour Apache Flink. Runtime Flink géré ; points de contrôle vers S3 ; mise à l'échelle automatique.
Transformation légère par enregistrement sur un flux Kinesis (<1 ms chacun).
Lambda avec Event Source Mapping sur KDS. Ajuster `BatchSize`, `MaximumBatchingWindowInSeconds` et `ParallelizationFactor`.
Pourquoi: Lambda est moins cher que KCL/Glue Streaming pour les petites tâches par enregistrement.
Une étape de Step Functions échoue occasionnellement en raison d'une limitation transitoire ; réessayer puis alerter.
Ajouter un bloc `Retry` avec `ErrorEquals: ["Lambda.ThrottlingException", "States.TaskFailed"]`, `IntervalSeconds`, `MaxAttempts`, `BackoffRate=2`. Plus `Catch` vers un état de notification.
Traiter 500 000 fichiers JSON en parallèle via une transformation Lambda.
État Map distribué de Step Functions avec `MaxConcurrency` et ItemReader depuis S3. Répartition sur des milliers d'invocations Lambda parallèles.
DAG complexe avec des dépendances inter-services (Glue + Redshift COPY + Lambda + e-mail) et des exigences de lignage.
Amazon MWAA (Managed Workflows for Apache Airflow). Opérateurs Airflow natifs pour les services AWS ; synchronisation de DAG pilotée par Git.
Besoin de revenir en arrière sur les changements de DAG si un déploiement provoque des échecs.
Stocker les DAG dans un bucket S3 versionné + synchronisation via le versionnement S3. Ou maintenir le dépôt de DAG dans Git avec un environnement par branche + synchronisation S3 via CI.
Données brutes "chaudes" pendant 30 jours, accès occasionnel pendant les 90 jours suivants, archive pendant 7 ans.
Cycle de vie S3 : 0–30 jours Standard, transition à 30 jours vers Standard-IA, transition à 120 jours vers Glacier Flexible Retrieval, expiration après 7 ans.
Modèles d'accès imprévisibles ; la politique de cycle de vie manuelle est un mauvais choix.
S3 Intelligent-Tiering. Déplace automatiquement les objets entre Frequent / Infrequent / Archive Instant Access / Archive / Deep Archive en fonction du modèle d'accès. Frais de surveillance par objet ; pas de frais de récupération dans Frequent/IA.
Les requêtes Athena sur le data lake sont lentes ; la partition contient des milliers de fichiers JSON de 1-5 Ko.
Compacter les petits fichiers via un job Glue/EMR en fichiers Parquet d'environ 256 Mo. Utiliser Iceberg `OPTIMIZE` ou la compaction Hudi pour les formats de table gérés.
Pourquoi: Les frais généraux par fichier d'Athena/Spark sont dominants avec de petits fichiers. Le point idéal est ~128–512 Mo Parquet.
Un seul bucket ; plusieurs équipes ont besoin de modèles d'accès différents, délimités par préfixe.
S3 Access Points — point d'accès nommé par équipe avec sa propre politique liée à un préfixe. Plus simple qu'une seule politique de bucket géante.
Différents consommateurs ont besoin de vues différentes du même objet S3 (PII masquées, résumées).
S3 Object Lambda Access Point. Une requête GET invoque une fonction Lambda qui transforme l'objet à la volée ; le consommateur voit la vue transformée.
Besoin de transactions ACID, d'évolution de schéma et de voyage dans le temps sur un data lake S3.
Tables Apache Iceberg (Glue Catalog + stockage S3). Commits atomiques, MERGE/UPDATE/DELETE, isolation de snapshot, évolution de partition.
Pourquoi: S3 de style Hive en mode ajout seulement ne prend pas en charge les mises à jour au niveau des lignes. Iceberg/Hudi/Delta résolvent ce problème.
Plusieurs rédacteurs et lecteurs sur une table de data lake ; besoin de cohérence transactionnelle et de contrôle d'accès au niveau des lignes.
Tables gouvernées Lake Formation (basées sur Iceberg) avec des LF-Tags pour les permissions.
Athena, Redshift Spectrum, EMR et Glue ETL ont tous besoin d'un magasin de métadonnées partagé.
AWS Glue Data Catalog. Un seul metastore compatible Hive consommé par chaque service d'analyse.
Le cluster Redshift doit mettre à l'échelle le stockage indépendamment du calcul.
Nœuds RA3 avec stockage géré (RMS). Stockage basé sur S3 ; le calcul s'adapte séparément. Requis pour AQUA, Concurrency Scaling, Federated Queries.
Une requête Redshift filtre fréquemment par `created_at` ; les analyses complètes de table sont lentes.
Définir une clé de tri sur `created_at` (ou une clé de tri composée incluant `created_at`). Redshift utilise des cartes de zones pour ignorer des blocs pendant l'analyse.
Jointures fréquentes entre `orders` et `order_items` ; les mélanges de requêtes (query shuffles) entraînent une lenteur.
Utiliser la même DISTKEY (`order_id`) sur les deux tables. Les lignes co-localisées évitent le mélange réseau (network shuffle) pendant la jointure.
Pourquoi: La distribution KEY co-localise les lignes de jointure sur le même nœud de calcul.
Charger 32 fichiers CSV gzip (~1 Go chacun) dans un cluster Redshift à 4 nœuds est lent.
COPY en parallèle à partir d'un seul manifeste. Viser #fichiers = multiple du nombre de slices (slices = nœuds × vCPU). 4 nœuds ra3.xlplus = 8 slices → 32 fichiers = 4 par slice.
Joindre 5 To de données Parquet "froides" dans S3 avec des tables de faits Redshift "chaudes" ; ne veut pas les charger.
Redshift Spectrum. Tables externes dans Glue Catalog ; les requêtes lisent S3 directement avec le calcul Redshift.
Les requêtes de l'équipe de reporting pendant les pics ralentissent les charges de travail ETL ; les deux s'exécutent sur le même cluster.
Activer le Concurrency Scaling sur la file d'attente WLM pertinente. Redshift achemine de manière transparente les requêtes en excès vers les clusters mis à l'échelle.
La requête de tableau de bord joint et agrège de manière répétée 3 grandes tables ; la latence est élevée.
Vue matérialisée avec rafraîchissement automatique. Redshift maintient le résultat pré-calculé ; la requête lit les données matérialisées.
Charge de travail analytique intermittente ; le cluster provisionné reste inactif.
Amazon Redshift Serverless. Provisionne et met à l'échelle automatiquement les RPU par charge de travail ; paiement par heure RPU. Zéro opérations.
Besoin de joindre des données Redshift avec des données Aurora MySQL en direct sans ETL.
Redshift Federated Queries. CRÉER un SCHÉMA EXTERNE pointant vers Aurora ; les requêtes poussent les prédicats sur la connexion RDS en direct.
Le tableau de bord joint les commandes + clients + produits à chaque rendu ; le schéma en étoile est trop lent.
Dénormaliser en une table de faits large ou une vue matérialisée. Les charges de travail BI privilégient les jointures au moment de la lecture résolues au moment de l'écriture.
S3 partitionne par `année/mois/jour/heure` ; `MSCK REPAIR TABLE` prend plus de 30 min.
Activer la projection de partition Athena (pas d'entrées de partition Glue Catalog). Définir les types et plages de clés de partition dans les propriétés de table.
Pourquoi: Athena calcule les emplacements de partition au moment de la requête à partir des règles de projection — pas de MSCK, pas de limitation de l'API Glue.
Convertir les résultats de requête Athena en Parquet, partitionnés, en une seule opération.
CREATE TABLE AS SELECT (CTAS) avec `format=PARQUET`, `partitioned_by=ARRAY['region']`, `external_location` défini sur le préfixe S3 cible.
Le même modèle de requête s'exécute avec différentes valeurs de paramètres tout au long de la journée.
Requêtes préparées Athena : `PREPARE`, `EXECUTE` avec des valeurs de paramètres. Évite le ré-parsing et offre une paramétrisation propre.
Lectures de dispositifs IoT ; besoin (1) de toutes les lectures pour un appareil dans une fenêtre de temps, (2) de la dernière lecture par appareil.
PK = `device_id`, SK = `timestamp`. GSI avec PK = `device_id`, SK = `timestamp` inversé (ou utiliser Query avec `ScanIndexForward=false LIMIT 1`).
La table de sessions croît sans limite ; les anciennes sessions peuvent être supprimées après 7 jours.
Activer le TTL DynamoDB sur un attribut d'époque `expires_at`. DynamoDB supprime les éléments expirés sans frais (dans les ~48h).
Données de capteurs IoT : requêtes "chaudes" sur les 7 derniers jours, requêtes occasionnelles sur 2 ans.
Amazon Timestream. Stockage en mémoire pour les données récentes (requêtes rapides) ; auto-tiering vers le stockage magnétique pour l'historique.
Stockage compatible Cassandra pour des séries temporelles à forte écriture avec une rétention de 90 jours.
Amazon Keyspaces avec TTL sur les lignes. Compatible avec Cassandra CQL ; capacité serverless, pas de gestion de cluster.
Le coût de stockage OpenSearch augmente ; les anciens index sont rarement interrogés.
Les politiques ISM d'OpenSearch hiérarchisent les données : hot → UltraWarm (soutenu par S3) → Cold. Le niveau Cold est détaché mais consultable à la demande.
Valider que la sortie ETL a ≥1 000 lignes et un taux de nullité de colonne <2% avant la consommation en aval.
Règles de qualité des données AWS Glue (DQDL) : `RowCount >= 1000`, `Completeness "col" > 0.98`. Le pipeline s'arrête en cas d'échec de la règle.
Framework de qualité des données personnalisé basé sur Spark sur EMR ; besoin de vérifications statistiques au niveau des colonnes.
Bibliothèque AWS Deequ sur Spark. Définir des contraintes (`isComplete`, `hasMin`, `isContainedIn`) ; Deequ s'exécute comme un job Spark et émet des métriques.
Les analystes doivent découvrir, demander l'accès et comprendre le lignage des produits de données à travers les comptes.
Amazon DataZone. Catalogue de données avec glossaire métier, workflows d'accès, lignage ; s'étend à Lake Formation, Redshift, RDS.
Lambda émet des métriques de traitement par enregistrement ; les coûts de CloudWatch PutMetricData sont élevés.
CloudWatch Embedded Metric Format (EMF). Journaliser le JSON dans le schéma EMF ; CloudWatch extrait les métriques des journaux sans coût par PutMetricData.
Trouver tous les jobs Glue dont la durée a dépassé 1 heure au cours des 7 derniers jours.
Requête CloudWatch Logs Insights : `fields @timestamp, @message | filter @message like /JobRunDuration/ | parse @message "duration=*" as d | filter d > 3600`.
Le job Glue est lent ; besoin de savoir s'il est sous-approvisionné ou s'il a un mélange de données asymétrique (skewed shuffle).
Activer les métriques et l'observabilité des jobs Glue. CloudWatch affiche l'utilisation maximale de DPU, l'utilisation des exécuteurs, la lecture/écriture de mélange par étape.
Les tailles des jobs Glue Spark varient d'un facteur 10 d'une exécution à l'autre ; sur-provisionné pour de petites entrées.
Activer l'auto scaling de Glue (Glue 3.0+). Les workers sont ajoutés/supprimés pendant l'exécution en fonction du parallélisme des étapes.
Athena scanne 5 To pour répondre à des requêtes qui ne concernent qu'un jour de données ; coût trop élevé.
Partitioner par date et s'assurer que la clause WHERE utilise les clés de partition. Valider avec `EXPLAIN` montrant l'élagage de partition (partition pruning).
Les requêtes Athena sur le data lake JSON sont lentes et coûteuses.
Convertir en Parquet (colonnaire) ou ORC. Lit uniquement les colonnes nécessaires ; la compression native réduit à la fois le coût et le temps de scan.
Optimisation des coûts du cluster EMR sans risque de perte de données.
Nœuds de cœur en On-Demand (hébergent HDFS / shuffle). Nœuds de tâche en Spot via Instance Fleets avec des types d'instances diversifiés.
Le cluster Redshift fonctionne 24h/24 et 7j/7 ; la tarification à la demande est coûteuse.
Nœuds réservés Redshift (1 an ou 3 ans, paiement initial intégral/partiel/nul). Jusqu'à ~75% de réduction par rapport à la demande pour les charges de travail stables.
Choisir entre Athena, Redshift et EMR pour 500 Go quotidiens / 50 requêtes.
Ad-hoc, peu fréquent → Athena (par To scanné). Tableaux de bord BI prévisibles → Redshift (RA3 + Nœuds Réservés). Spark personnalisé lourd → EMR.
Pourquoi: Athena facture par données scannées ; Redshift facture par heure de cluster ; EMR par heure d'instance. Adapter la facturation au modèle d'accès.
Un job Glue est déclenché plusieurs fois simultanément ; veut limiter à une seule exécution à la fois.
Définir `MaxConcurrentRuns=1` pour le job Glue. Les déclenchements ultérieurs attendent ; élimine la corruption d'état concurrent.
Les tentatives de Glue ETL produisent des lignes de sortie dupliquées dans la cible S3.
Idempotence : écrire vers un préfixe temporaire par exécution, puis renommer atomiquement via S3 multipart `CompleteMultipartUpload` ou utiliser Iceberg/Hudi MERGE pour les upserts.
Une mauvaise exécution ETL a écrit des lignes corrompues dans Aurora MySQL ; récupérer à un point dans le temps d'il y a quelques minutes.
Aurora Backtrack (compatible MySQL uniquement). Remonte le cluster à un temps cible sans restaurer à partir d'un snapshot.
Le pipeline a écrasé des objets S3 corrects avec des données corrompues.
Versionnement de bucket S3 + restauration de version précédente. Combiner avec MFA Delete pour empêcher l'expiration accidentelle de version.
Automatiser la création, la rétention et la copie inter-régions de snapshots EBS pour la reprise après sinistre.
Amazon Data Lifecycle Manager (DLM) avec politique par tag : planification, rétention, copie inter-régions.
Les consommateurs MSK prennent du retard par rapport aux producteurs ; besoin de détecter et d'alerter.
Métriques CloudWatch `MaxOffsetLag` par groupe de consommateurs. Alarme si > seuil ; augmenter le nombre de consommateurs ou le parallélisme de partition.
Le consommateur Kinesis prend du retard ; veut détecter.
Métriques CloudWatch `GetRecords.IteratorAgeMilliseconds`. Une alarme > 60s signifie généralement que les consommateurs sont sous-provisionnés.
Identifier les requêtes Redshift les plus lentes de la dernière heure pour le réglage.
Interroger `SVL_QLOG` / `STL_QUERY` / `SYS_QUERY_HISTORY` pour les entrées avec le temps écoulé le plus long ; utiliser `SVL_QUERY_REPORT` pour une répartition par étape.
Les équipes commerciales ne devraient voir que les lignes correspondant à leurs régions attribuées dans le data lake partagé.
Sécurité au niveau des lignes de Lake Formation via un filtre de données : `region IN ('NA', 'EU')` par principal IAM. Table unique ; vue filtrée par principal.
Table de santé — les analystes ne doivent pas voir les colonnes SSN et de diagnostic.
Permissions au niveau des colonnes de Lake Formation : GRANT SELECT sur la table SAUF (`ssn`, `diagnosis_code`).
Plusieurs équipes + plusieurs tables ; les autorisations par table sont difficiles à maintenir.
LF-Tags de Lake Formation. Tagger les tables/colonnes ; accorder des permissions basées sur les tags aux principaux. L'ajout d'une nouvelle table nécessite juste le bon tag.
Le compte A possède le data lake ; les analystes du compte B ont besoin d'un accès en lecture à des tables spécifiques.
Partage inter-comptes Lake Formation via RAM. Le compte A accorde des permissions au principal/compte IAM du compte B ; B y accède via Athena/Redshift Spectrum.
Sécurité au niveau des lignes à l'intérieur de Redshift (pas Lake Formation).
Politiques RLS natives de Redshift : `CREATE RLS POLICY` avec un prédicat référençant le contexte de session (`current_user`, `session_role`). Attacher la politique à la table.
La conformité exige une clé gérée par le client (CMK) avec piste d'audit pour le chiffrement Redshift.
Cluster Redshift chiffré avec une clé KMS gérée par le client. Rotation de clé activée ; CloudTrail capture chaque opération de déchiffrement contre la CMK.
Chiffrer les entrées/sorties des jobs Glue ETL avec une clé gérée par l'entreprise.
Configuration de sécurité Glue avec CMK pour S3 + CloudWatch Logs + Signets de job. Rôle Glue accordé `kms:Decrypt`/`Encrypt` sur la clé.
Découvrir et classifier les PII (noms, SSN, e-mails) présents dans le data lake S3.
Amazon Macie. Découverte de données sensibles basée sur le ML sur S3 ; produit des découvertes avec l'emplacement de l'objet et le type de PII.
Auditer chaque opération S3 GetObject / PutObject dans le bucket du data lake.
Événements de données CloudTrail pour le bucket. CloudTrail enregistre par défaut uniquement les événements de gestion ; les événements de données doivent être activés explicitement.
Pourquoi: Les événements de données sont facturés par événement ; limiter au bucket sensible uniquement pour contrôler les coûts.
Besoin de qui/quand/IP pour chaque accès S3 ; les événements de données CloudTrail sont trop coûteux.
Journalisation d'accès serveur S3. Gratuit ; les journaux sont livrés à un bucket de journalisation séparé ; moins de détails que CloudTrail mais couvre le demandeur + IP + chemin.
Empêcher que tout bucket du compte ne soit accidentellement rendu public, même si une politique de bucket le permet.
S3 Block Public Access au niveau du compte. Annule toute politique au niveau du bucket ; appliqué comme une mesure de protection.
Redshift dans un VPC doit lire depuis S3 sans passer par l'internet public.
S3 Gateway Endpoint dans la table de routage du sous-réseau Redshift. Le trafic est acheminé via le backbone AWS ; pas de NAT, pas d'IGW.
Le job Glue ETL doit accéder à RDS dans un sous-réseau privé ET appeler les API Glue Data Catalog.
Connexion Glue sur le VPC RDS + Interface VPC Endpoints pour `glue.amazonaws.com` + S3 Gateway Endpoint.
Glue ETL a besoin d'un accès en lecture S3, écriture Redshift, lecture Secrets Manager.
Rôle d'exécution Glue unique avec des politiques de moindre privilège : `s3:GetObject` sur le préfixe source, `redshift-data:ExecuteStatement`, `secretsmanager:GetSecretValue` sur l'ARN du secret spécifique.
Détecter les modèles d'accès aux données inhabituels — téléchargement important par un utilisateur IAM sans accès préalable au data lake.
GuardDuty S3 Protection. Références comportementales par principal IAM ; découvertes sur les volumes/modèles d'accès anormaux.
La conformité exige une rétention WORM (écrire une fois, lire plusieurs fois) sur les données financières pendant 7 ans.
S3 Object Lock avec mode Conformité + période de rétention de 7 ans. Même l'utilisateur root ne peut pas supprimer ; conforme SEC 17a-4 / FINRA.
Collecte continue de preuves de conformité pour les audits HIPAA / SOC 2.
AWS Audit Manager avec des frameworks pré-construits. Collecte automatiquement des preuves de CloudTrail, Config, Security Hub ; produit des rapports prêts pour l'audit.
