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.