Amazon SAA-C03: Analytique, Data Lake, ML et charges de travail spécialisées — Guide d'étude

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fait partie du AWS SAA-C03 — Guide d’étude complet. 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.

Fondations du Lac de Données : Lake Formation et le Glue Data Catalog

Le centre de gravité de l’analytique sur AWS est le AWS Glue Data Catalog — un métastore compatible avec le métastore Hive que Athena, Redshift Spectrum, EMR et Glue ETL consomment tous. Toutes les définitions de table, partitions, types de colonnes et configurations SerDe y résident, et chaque moteur en aval s’y connecte pour lire. Si deux chemins d’ingestion (par exemple, un crawler Glue et une instruction manuelle CREATE EXTERNAL TABLE) sont en désaccord sur le schéma du même préfixe S3, les requêtes retournent silencieusement des résultats incorrects ou échouent. Le pattern correct consiste à désigner une seule autorité par table : soit le crawler est propriétaire du schéma, soit votre job ETL écrit via glueContext.write_dynamic_frame.from_catalog, mais jamais les deux sans une stratégie de fusion. Lorsque l’ETL par lots, la conversion Parquet de Firehose et le DDL manuel écrivent tous dans la même table, la dérive du catalogue (catalog drift) est le tueur silencieux. Imposez un seul propriétaire par table, utilisez le Glue Schema Registry pour les producteurs de flux (streaming), et exécutez les crawlers en mode LOG (et non UPDATE_IN_DATABASE) sur les tables appartenant aux jobs ETL afin qu’ils fassent remonter la dérive sans écraser les schémas gérés.

AWS Lake Formation se positionne au-dessus du Data Catalog et remplace le modèle de politiques IAM/bucket S3 à granularité grossière par une couche de permissions de type base de données. Au lieu d’accorder s3:GetObject sur un préfixe, vous exécutez GRANT SELECT ON customers.orders TO role/AnalystRole, et Lake Formation fournit de manière transparente des informations d’identification éphémères lorsque Athena ou Redshift Spectrum accède aux objets sous-jacents. Sa véritable valeur réside dans l’autorisation à granularité fine : filtrage au niveau des colonnes, sécurité au niveau des lignes via des filtres de données, et contrôle d’accès basé sur des tags (LF-Tags) qui s’adapte à des milliers de tables. Une plateforme de vente au détail avec des PII dans une table customers peut accorder aux analystes l’accès à customer_id, region, signup_date tout en bloquant email et ssn — appliqué au moment de la requête, sans nécessiter la prolifération de vues.

La configuration canonique pour un lac de données gouverné :

1. Register S3 locations with Lake Formation (removes IAMAllowedPrincipals default).
2. Create databases and let Glue crawlers populate tables.
3. Define LF-Tags (e.g., Classification=PII, Domain=Sales).
4. Grant tag-based permissions to IAM principals.
5. Point Athena/Redshift/QuickSight at the catalog — permissions flow through.

Les blueprints Lake Formation sont des modèles de workflow préconfigurés qui assemblent des crawlers, des jobs et des déclencheurs pour ingérer des données depuis des sources JDBC ou S3 dans un lac de données géré — réduisant ce qui nécessiterait des dizaines de ressources Glue configurées manuellement à un flux piloté par un assistant.

Une erreur fréquente est de tenter d’appliquer des restrictions au niveau des colonnes uniquement dans QuickSight. QuickSight dispose d’une sécurité au niveau des lignes et des colonnes liée aux jeux de données, mais cela ne protège que la surface QuickSight — toute personne ayant un accès direct à Athena ou S3 peut le contourner. Le contrôle au niveau des colonnes doit être appliqué à la couche de données (permissions Lake Formation, ou séparation physique des colonnes pendant l’ETL), et QuickSight hérite de cette posture via son rôle IAM.

Athena : SQL Serverless sur S3

Athena est un moteur Presto/Trino serverless, avec paiement à la requête, qui lit les données directement depuis Amazon S3. Aucun cluster à provisionner, aucune étape d’ETL requise avant d’interroger les données, et aucun coût en période d’inactivité — vous ne payez que pour les octets scannés (généralement 5 $/To). Cela fait d’Athena le choix canonique pour l’analyse ad-hoc de fichiers déjà présents dans S3, qu’il s’agisse de logs d’application JSON, d’exports CSV ou de tables de faits Parquet. Athena a besoin d’un schéma et d’une structure de partitionnement, qui résident dans le Glue Data Catalog.

Puisqu’Athena facture au téraoctet scanné, le format de stockage a un impact démesuré sur le coût et la latence. Les deux leviers sont le format et le partitionnement :

• Les formats colonnes (Parquet, ORC) permettent à Athena d’élaguer (prune) les colonnes et les groupes de lignes. Une requête comme SELECT sum(amount) FROM orders WHERE region='us-east-1' sur du Parquet ne lit que les deux colonnes référencées ; sur du CSV, il lit chaque octet de chaque ligne.
• Le partitionnement sur des colonnes à haute sélectivité (par ex., dt=2024-03-11/) réduit un scan de table complet à une lecture ciblée. Sur des logs de plusieurs téraoctets (CloudFront, ALB, VPC Flow Logs), c’est la différence entre une requête à 0,15 $ et une requête à 30 $.

Convertir du JSON ou CSV brut en Parquet partitionné et compressé avec Snappy est presque toujours le premier levier de coût à actionner. Combiné avec le LIMIT pushdown, Athena répond à la plupart des besoins d’analytique sur S3 avec zéro infrastructure.

Un pattern rentable pour une table de “relevés” (readings) stockée en Parquet partitionné :

CREATE EXTERNAL TABLE readings (
  station_id string,
  reading_ts timestamp,
  temp_c    double
)
PARTITIONED BY (dt string)
STORED AS PARQUET
LOCATION 's3://weather-lake/readings/'
TBLPROPERTIES ('has_encrypted_data'='true');

SELECT station_id, AVG(temp_c) OVER (
         PARTITION BY station_id
         ORDER BY reading_ts
         ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS moving_avg
FROM readings
WHERE dt = '2024-03-11';

Ignorer le crawler est une erreur courante. Sans entrée dans le catalogue, vous devez soit écrire manuellement du DDL CREATE EXTERNAL TABLE (fragile à mesure que les schémas évoluent), soit utiliser des astuces de “schema-on-read” qui scannent chaque fichier. Pire encore, sans MSCK REPAIR TABLE ou la projection de partitions (partition projection), Athena scanne l’intégralité du préfixe à chaque requête. Les crawlers Glue détectent les nouvelles partitions de manière planifiée et mettent à jour le catalogue de façon atomique.

Athena sur des données S3 chiffrées. Athena prend en charge SSE-S3, SSE-KMS et CSE-KMS, mais uniquement si l’appelant dispose des permissions KMS appropriées et si le workgroup ou le client est configuré pour le mode de chiffrement utilisé. Pour CSE-KMS, le fichier est chiffré côté client avant l’upload ; le principal IAM qui exécute la requête a besoin des permissions kms:Decrypt et kms:GenerateDataKey sur la CMK, et la politique de la clé doit accorder la réciprocité. Un mode d’échec courant : charger du Parquet chiffré avec CSE-KMS, n’accorder au rôle Athena que des permissions de lecture S3, puis obtenir des erreurs opaques AccessDenied ou HIVE_CANNOT_OPEN_SPLIT — l’objet est lisible mais le texte chiffré (ciphertext) ne peut pas être déchiffré. Une autre erreur fréquente consiste à enregistrer la table avec le mauvais mode de chiffrement (SSE-KMS dans les propriétés de la table alors que les objets ont été écrits avec CSE-KMS) ; Athena tente un déchiffrement côté serveur lors de l’appel GetObject et la charge utile (payload) revient sous forme de texte chiffré brut qui échoue aux vérifications des “magic numbers” de Parquet.

Les requêtes fédérées Athena vous permettent de joindre des données S3 avec des bases de données opérationnelles (DynamoDB, RDS) sans déplacer les données. Réservez Athena pour l’analytique ad-hoc orientée lecture ; utilisez les jobs Glue pour la mise en forme planifiée des zones de données gérées (curated zones).

Crawlers Glue, tâches ETL et signets de tâche

Les crawlers Glue analysent les chemins S3, infèrent le schéma (y compris les clés de partition à partir de la structure des répertoires comme year=2024/month=01/), et enregistrent ou mettent à jour les tables dans le catalogue. Ils sont la réponse low-code à la problématique : « nous déposons des fichiers dans S3, rendez-les requêtables ». Planifiez un crawler toutes les heures sur un bucket d’atterrissage (landing bucket) et Athena verra immédiatement les nouvelles partitions.

aws glue create-crawler \
  --name logs-crawler \
  --role AWSGlueServiceRole-Logs \
  --database-name analytics_db \
  --targets '{"S3Targets":[{"Path":"s3://acme-logs/app/"}]}' \
  --schedule "cron(0 * * * ? *)"

Les tâches ETL Glue (Spark, shell Python ou Ray) gèrent la partie transformation. Glue est serverless — vous payez par DPU-heure avec un minimum d’une minute — et le runtime met à l’échelle les workers automatiquement. Le modèle dominant est : entrée en CSV/JSON, sortie en Parquet partitionné :

import sys
from awsglue.context import GlueContext
from pyspark.context import SparkContext

glueContext = GlueContext(SparkContext.getOrCreate())
df = glueContext.create_dynamic_frame.from_catalog(
    database="raw", table_name="reports_csv")
glueContext.write_dynamic_frame.from_options(
    frame=df,
    connection_type="s3",
    connection_options={"path": "s3://curated/reports/",
                        "partitionKeys": ["report_date"]},
    format="parquet",
    format_options={"compression": "snappy"})

La fonctionnalité opérationnelle essentielle est le signet de tâche (job bookmark) : Glue conserve un état sur les fichiers ou partitions qu’il a déjà traités, de sorte que les exécutions suivantes ne lisent que les nouvelles données. Oublier d’activer les signets signifie que chaque exécution retraitera l’ensemble du jeu de données depuis le début, augmentant le coût et la durée d’exécution de manière linéaire et produisant souvent des doublons en sortie. Les signets sont activés par tâche et doivent être associés à des options de source qui les prennent en charge (les sources S3 via le lecteur DynamicFrame de Glue le font ; les lectures Spark arbitraires ne le font pas). Les signets nécessitent un argument transformation_ctx sur chaque source et un encadrement par job.init(...) / job.commit() :

job = Job(glueContext)
job.init(args['JOB_NAME'], args)   # bookmark state loaded

datasource = glueContext.create_dynamic_frame.from_catalog(
    database="analytics_db",
    table_name="app_logs",
    transformation_ctx="datasource"   # required for bookmarking
)
# ... transforms ...
job.commit()                          # bookmark state persisted

Pour une simple conversion de format sans logique, l’option la moins coûteuse en effort est souvent un crawler Glue sur les données brutes, plus une tâche Glue créée dans l’éditeur visuel (ou une recette DataBrew) — aucun code Spark n’est requis. Les clusters EMR personnalisés ou les convertisseurs Lambda ajoutent une surcharge opérationnelle que le modèle serverless de Glue élimine.

Une tâche quotidienne typique qui nettoie les données S3 et charge Redshift Serverless :

# Glue 4.0 PySpark: S3 raw -> curated -> Redshift Serverless
df = glueContext.create_dynamic_frame.from_catalog(
        database="raw", table_name="orders").toDF()
df = df.filter("order_status <> 'CANCELLED'") \
       .withColumn("order_date", to_date("order_ts"))

glueContext.write_dynamic_frame.from_jdbc_conf(
    frame       = DynamicFrame.fromDF(df, glueContext, "out"),
    catalog_connection = "redshift-serverless-conn",
    connection_options = {"dbtable": "fact_orders", "database": "analytics"},
    redshift_tmp_dir   = "s3://stg/redshift-tmp/")

Configurations de sécurité Glue et ETL multi-locataire

Les crawlers et les tâches Glue nécessitent la même prise en compte du chiffrement qu’Athena. Les configurations de sécurité Glue sont des ensembles nommés spécifiant comment les cibles S3, les journaux CloudWatch et les signets de tâche sont chiffrés — y compris le CSE-KMS avec une CMK spécifique. Une tâche associée à une configuration de sécurité déchiffre de manière transparente les entrées chiffrées en CSE-KMS et chiffre les sorties de la même manière, à condition que le rôle IAM de la tâche dispose des autorisations KMS sur les clés référencées.

Pour un ETL multi-locataire — une plateforme SaaS traitant les données de chaque client avec la CMK de ce client — le modèle correct est une configuration de sécurité par client (ou un paramètre de tâche sélectionnant la CMK) plus un rôle IAM limité à cette CMK. Faire passer tous les clients par une seule tâche avec une seule clé partagée va à l’encontre de la garantie d’isolation que le CSE-KMS est censé fournir.

Une discipline connexe : les tables analytiques de production ne devraient pas être la cible directe de tâches Glue ou de notebooks exploratoires. Exportez un instantané (snapshot) vers un préfixe S3 « analytics » et pointez Athena ou Spark sur la copie. Exécuter des transformations expérimentales sur la table de production risque de réécrire des partitions, de corrompre les signets et de provoquer des contentions de verrous, tout en brouillant la frontière d’audit entre les données opérationnelles et les dérivés analytiques.

AWS Glue DataBrew

DataBrew est le pendant low-code de Glue pour les utilisateurs qui ne peuvent ou ne devraient pas écrire de code Spark. Il offre une interface de type tableur avec plus de 250 transformations prédéfinies (imputation, masquage de PII, regroupement des valeurs aberrantes, analyse de dates). Ses différenciateurs sont les recettes partagées (shared recipes) — des artefacts JSON versionnés que vous pouvez publier et réappliquer à travers les projets — et la visualisation du lignage des données (data lineage) qui trace les colonnes depuis les jeux de données source, à travers les recettes et les tâches, jusqu’aux emplacements de sortie. Choisissez DataBrew lorsque les analystes sont responsables de la logique de transformation ; choisissez Glue Studio/scripts lorsque les ingénieurs en sont responsables et que le pipeline nécessite du code personnalisé, du streaming ou des jointures complexes.

Amazon EMR : Traitement par lots distribué et rôles d’exécution

Amazon EMR est une plateforme de clusters gérés exécutant Spark, Hadoop, Hive, Presto, HBase et Flink. Son créneau idéal concerne les charges de travail par lots ou interactives, volumineuses et parallélisables, qui lisent des jeux de données S3 à l’échelle du pétaoctet et les joignent à un autre système de référence (souvent Redshift) pour les enrichir. EMR peut exécuter des clusters transitoires (démarrer, exécuter, terminer) ou de longue durée, et peut combiner des instances On-Demand, Spot et réservées via les flottes d’instances (instance fleets).

Un modèle canonique : une tâche Spark lit du Parquet depuis S3, récupère les tables de dimension de Redshift via UNLOAD-to-S3, les joint à travers les exécuteurs, et réécrit la sortie enrichie sur S3 :

# Spark on EMR: enrich S3 events with Redshift dimensions
df_events = spark.read.parquet("s3://raw/events/dt=2024-11-01/")
df_dims = (spark.read
    .format("io.github.spark_redshift_community.spark.redshift")
    .option("url", "jdbc:redshift://cluster:5439/analytics")
    .option("dbtable", "public.customer_dim")
    .option("tempdir", "s3://staging/redshift-unload/")
    .load())

enriched = df_events.join(df_dims, "customer_id", "left")
enriched.write.mode("overwrite").partitionBy("region").parquet("s3://curated/events/")

EMR l’emporte ici car Spark distribue la jointure sur des dizaines de nœuds et le passage par S3 évite un goulot d’étranglement JDBC à thread unique. Le piège est de se tourner systématiquement vers EMR dès que des données S3 doivent être requêtées. Pour du SQL ad-hoc sur des dizaines ou des centaines de gigaoctets, le provisionnement et le réglage d’un cluster Spark représentent une pure surcharge opérationnelle : dimensionnement du cluster, configuration de YARN, autoscaling, rotation des logs, application de correctifs. EMR ne se justifie que lorsque le volume, le code personnalisé ou la flexibilité du moteur d’exécution le légitiment.

Rôles d’exécution EMR. Historiquement, toutes les étapes (steps) sur un cluster héritaient du profil d’instance EC2 — un rôle unique attaché aux nœuds sous-jacents — ce qui signifiait que chaque équipe partageant un cluster disposait de l’union de toutes les permissions dont chaque équipe avait besoin. Les rôles d’exécution résolvent ce problème : lorsqu’un utilisateur soumet une étape, il passe l’argument --execution-role-arn, et EMR assume ce rôle pour la durée de l’étape. L’équipe A peut être restreinte à s3://team-a/*, l’équipe B à s3://team-b/*. Le profil d’instance devient un rôle de bootstrap minimal qui ne fait que récupérer les artefacts du cluster.

Les rôles d’exécution sont également le mécanisme permettant de bloquer l’accès à l’IMDS. Lorsqu’ils sont activés (EMR 6.7+ avec Spark/Hive sur YARN), le code utilisateur ne peut pas atteindre le service de métadonnées d’instance — y compris IMDSv2 — car la plateforme intercepte ces appels. Cela ferme la voie d’escalade où une tâche pourrait autrement appeler http://169.254.169.254/latest/api/token et assumer le puissant profil d’instance EC2.

aws emr create-cluster \
  --release-label emr-6.15.0 \
  --applications Name=Spark Name=Hive \
  --security-configuration team-isolation-sc \
  --service-role EMR_DefaultRole \
  --ec2-attributes InstanceProfile=EMR_EC2_MinimalRole,...

aws emr add-steps --cluster-id j-XXXX \
  --steps Type=Spark,Name="TeamA-ETL",\
ActionOnFailure=CONTINUE,\
Jar=command-runner.jar,\
Args=[spark-submit,s3://team-a/jobs/etl.py] \
  --execution-role-arn arn:aws:iam::111122223333:role/TeamA-EMRRuntime

La configuration de sécurité est ce qui permet l’application des rôles d’exécution et le blocage de l’IMDS. Sans elle, supposer que les charges de travail EMR « utilisent automatiquement des rôles à moindre privilège » est faux — par défaut, elles partagent le profil d’instance et l’IMDS est accessible depuis le code utilisateur.

Amazon Redshift et Redshift ML

Redshift est un entrepôt de données MPP (Massively Parallel Processing) en colonnes pour les charges de travail analytiques soutenues nécessitant des tableaux de bord avec des temps de réponse inférieurs à la seconde, des jointures complexes sur des milliards de lignes et une latence constante sous une charge d’utilisateurs BI simultanés. Les nœuds RA3 découplent la puissance de calcul du stockage géré ; Redshift Serverless facture en RPU-secondes par rapport à une capacité de base configurée, s’adapte à la charge et se met en pause lorsqu’il est inactif, éliminant le problème traditionnel du dimensionnement des clusters.

Redshift participe aux pipelines analytiques dans deux modes d’enrichissement :

• En tant que source : Spark sur EMR extrait les dimensions via UNLOAD vers S3, ou Glue lit via l’API de données Redshift.
• En tant que cible : Firehose ou une tâche Glue copie (COPY) les données enrichies.

Redshift Spectrum étend cela en permettant à Redshift SQL d’interroger S3 directement via le Glue Data Catalog — le même catalogue qu’utilise Athena — ce qui rend possible le modèle lake-house. Idéal lorsque vous disposez déjà d’un cluster Redshift et que vous souhaitez joindre des faits de l’entrepôt à un historique froid sur S3 sans déplacer les données.

Les chargements par lots utilisent COPY depuis S3, parallélisés sur les nœuds de calcul ; les fichiers doivent être divisés en morceaux de taille à peu près égale (un multiple du nombre de slices) pour le parallélisme :

COPY events FROM 's3://acme-lake/events/dt=2024-05-12/'
IAM_ROLE 'arn:aws:iam::111:role/RedshiftLoader'
FORMAT AS PARQUET;

L’ingestion en streaming passe généralement par Firehose (COPY mis en mémoire tampon) pour une livraison sans opérations (zero-ops).

Redshift ML permet aux utilisateurs SQL de créer, entraîner et invoquer des modèles via CREATE MODEL :

CREATE MODEL churn_predictor
FROM (SELECT tenure, plan, monthly_spend, churned FROM customers)
TARGET churned
FUNCTION predict_churn
IAM_ROLE default
SETTINGS (S3_BUCKET 'redshift-ml-artifacts');

SELECT customer_id, predict_churn(tenure, plan, monthly_spend)
FROM customers_current;

En coulisses, Redshift exporte le jeu de données d’entraînement vers S3, invoque SageMaker Autopilot (ou un algorithme spécifié comme XGBoost), et importe le modèle compilé pour l’inférence au sein de la base de données. C’est puissant lorsque les analystes travaillent déjà en SQL, mais ce n’est pas un remplacement pour une plateforme de ML complète : le mouvement des données vers S3 et le calcul d’entraînement de SageMaker sont facturés séparément, les grands jeux de données d’entraînement peuvent générer des frais de sortie (egress) et d’exécution d’Autopilot significatifs, et il n’y a pas de workflow intégré pour les magasins de caractéristiques (feature stores), le suivi d’expériences ou le déploiement A/B. Considérez Redshift ML comme une inférence démocratisée sur les données Redshift, et non comme un outil d’entraînement à usage général.

Choisir entre Athena et Redshift

Ingestion en streaming : Kinesis Data Streams, Firehose et MSK

Les trois services de streaming AWS résolvent des problèmes qui se chevauchent avec des garanties matériellement différentes :

Kinesis Data Streams utilise des shards (ou le mode à la demande) ; les enregistrements avec la même clé de partition arrivent sur le même shard et sont consommés dans l’ordre. Les consommateurs utilisent le classique GetRecords ou l’Enhanced Fan-Out (2 Mo/s dédiés par consommateur). Une fonction Lambda attachée comme source d’événement est invoquée avec des lots par shard, préservant l’ordre. C’est le bon choix lorsque la logique en aval n’est pas triviale, lorsque plusieurs consommateurs indépendants doivent rejouer l’historique, ou lorsque les volumes de clickstream sont énormes — par exemple, un site générant 30 To/jour ferait transiter les données par KDS puis Firehose pour atterrir dans S3 pour une analyse avec Athena/Spectrum.

Kinesis Data Firehose est une livraison gérée de type « fire-and-forget » : il met en mémoire tampon par taille ou par temps (ex: 5 Mo / 300 secondes), invoque optionnellement une Lambda pour la transformation, convertit optionnellement le JSON en Parquet/ORC en utilisant le schéma d’une table Glue, et écrit vers S3, Redshift (via S3 + COPY), OpenSearch, ou Splunk. Activer la conversion Parquet dans Firehose est le moyen le plus simple de faire atterrir des données de streaming dans un format optimisé pour les requêtes sans une tâche Glue en aval :

Firehose delivery stream → 
  Record transformation: Lambda (optional, for enrichment) →
  Format conversion: enabled, schema from Glue table "events.raw" →
  Destination: s3://lake/events/ partitioned by !{timestamp:yyyy/MM/dd}

Firehose n’a pas de garantie d’ordonnancement de bout en bout, ne peut pas supporter plusieurs consommateurs rejouables, et ses destinations sont des récepteurs fixes. Choisir Firehose lorsque le besoin est de « traiter chaque enregistrement dans l’ordre » ou d’avoir « plusieurs consommateurs indépendants » est une erreur sur les deux points. De même, s’attendre à ce que Firehose seul effectue des transformations complexes est un piège — son seul point d’accroche pour la transformation est une Lambda invoquée par lot mis en tampon. Tout ce qui implique un enrichissement externe, une agrégation sur plusieurs enregistrements ou un routage conditionnel doit se trouver dans cette Lambda ou être déplacé en amont vers Managed Service for Apache Flink.

Amazon MSK est une version gérée d’Apache Kafka. Choisissez-le lorsque vous avez déjà des producteurs/consommateurs Kafka, que vous avez besoin de fonctionnalités spécifiques à Kafka (sujets compactés, transactions, Kafka Streams, Connect), ou que vous exigez un débit au-delà de ce que Kinesis basé sur les shards peut confortablement fournir.

Utiliser SQS ou EventBridge comme chemin d’ingestion analytique est une erreur : SQS n’est pas ordonné par flux et ne permet pas la relecture ; EventBridge est optimisé pour le routage d’événements, pas pour une ingestion soutenue de plusieurs Mo/s.

Recherche en temps réel : KDS + Firehose + OpenSearch + QuickSight

Le remplacement canonique d’une pile Elasticsearch+Logstash sur site (on-premises) est :

Firehose met en mémoire tampon les enregistrements du flux et les livre directement à un domaine OpenSearch, gérant les nouvelles tentatives, la sauvegarde sur S3 et la transformation Lambda optionnelle. OpenSearch Dashboards est intégré et gratuit avec le domaine et convient aux opérateurs qui surveillent les flux en temps réel. QuickSight complète cette solution pour l’analytique destinée aux utilisateurs métier — il interroge directement Athena, Redshift, RDS et OpenSearch, et son moteur en colonnes en mémoire SPICE met en cache les jeux de données traités pour des performances de tableau de bord en quelques subsecondes.

Une répartition typique est la suivante : OpenSearch Dashboards pour les opérateurs ; QuickSight pour les dirigeants qui consultent des jeux de données agrégés et préparés provenant du lac de données Athena/Glue. Les deux doivent se voir accorder un accès en lecture IAM et, le cas échéant, l’autorisation KMS Decrypt sur les CMK protégeant le stockage sous-jacent — sinon, la couche de visualisation affiche des panneaux vides avec des erreurs de permission enfouies dans les journaux de requêtes.

Contrôle d’accès dans QuickSight

QuickSight construit des jeux de données (requêtes logiques plus champs calculés et sécurité au niveau des lignes), puis des analyses basées sur ces jeux de données, et publie enfin des tableaux de bord (vues partageables en lecture seule). Le contrôle d’accès est organisé en couches et doit être appliqué à la bonne couche. Le piège est d’accorder un accès large au niveau du tableau de bord — en le partageant avec un groupe à l’échelle de l’organisation alors que seul un sous-ensemble devrait voir les données sous-jacentes.

Le moindre privilège dans QuickSight signifie :

• Partager le jeu de données uniquement avec les utilisateurs/groupes qui en ont besoin.
• Appliquer la sécurité au niveau des lignes via un jeu de données de permissions qui filtre les lignes par nom d’utilisateur ou groupe.
• Appliquer la sécurité au niveau des colonnes pour masquer les champs sensibles.
• Partager les tableaux de bord avec des utilisateurs, des groupes spécifiques ou (pour l’analytique embarquée) des espaces de noms (namespaces).

Rendre un tableau de bord public ou le partager à l’échelle du compte contourne l’intention des contrôles au niveau du jeu de données, car les visualiseurs du tableau de bord héritent d’un accès en lecture aux données visualisées, quelles que soient les permissions sur la source sous-jacente. N’oubliez pas que la sécurité au niveau des colonnes de QuickSight ne protège que la surface QuickSight ; toute personne ayant un accès direct à Athena ou S3 la contourne, donc les contrôles sensibles doivent être placés dans Lake Formation ou l’ETL, et non uniquement dans QuickSight.

Les rôles QuickSight — Admin, Author, Reader — contrôlent ce qu’un utilisateur peut faire, ce qui est distinct des permissions de partage qui contrôlent ce qu’il peut voir. Un Reader consomme à un coût par session inférieur à celui d’une licence Author, donc les populations de visualiseurs devraient être des Readers par défaut, et l’accès devrait être accordé via l’appartenance à un groupe plutôt que par une attribution individuelle.

Amazon Neptune pour les charges de travail de graphes

Neptune est une base de données de graphes gérée qui prend en charge le modèle de graphe de propriétés (Gremlin, openCypher) et RDF (SPARQL). Elle est spécialement conçue pour les données hautement connectées — relations sociales, réseaux de fraude, graphes de connaissances, moteurs de recommandation — où les jointures récursives dans une base de données relationnelle deviennent prohibitives. Une plateforme sociale avec des utilisateurs, des abonnements (follows), des mentions “j’aime” (likes) et des publications se mappe naturellement sur des sommets et des arêtes, et Neptune répond aux parcours à plusieurs sauts (“les amis des amis qui ont aimé X”) en quelques millisecondes.

Neptune Streams expose un journal chronologique ordonné de chaque mutation du graphe. Une fonction Lambda ou une application interrogeant le flux peut réagir aux changements — recalculer des recommandations, mettre à jour un index de recherche, déclencher des alertes de fraude — sans un pipeline de capture de données de changement (change-data-capture) sur mesure. Reproduire cela sur Aurora ou DynamoDB nécessite un parcours de graphe au niveau de l’application ainsi qu’une infrastructure CDC distincte. Lorsque l’énoncé du problème inclut à la fois “analyser les relations” et “surveiller les changements”, Neptune avec Streams est la solution la plus directe.

SageMaker : ML personnalisé de bout en bout

SageMaker couvre le cycle de vie complet : notebooks Studio, tâches d’entraînement gérées (avec prise en charge des instances Spot), Model Registry, points de terminaison en temps réel et sans serveur (serverless), transformation par lots (batch), et Pipelines pour le MLOps. Un flux de travail typique consiste à téléverser les données d’entraînement sur S3, à lancer une tâche d’entraînement en spécifiant un algorithme intégré ou un conteneur personnalisé, et SageMaker provisionne des instances éphémères, diffuse les journaux vers CloudWatch et réécrit l’artefact du modèle sur S3. Le déploiement se fait par un seul appel d’API :

from sagemaker.estimator import Estimator
est = Estimator(image_uri=xgb_image, role=role,
                instance_count=2, instance_type="ml.m5.xlarge",
                output_path="s3://models/xgb/")
est.fit({"train": "s3://data/train/", "validation": "s3://data/val/"})
predictor = est.deploy(initial_instance_count=1, instance_type="ml.m5.large")

Pas de Kubernetes, de pilote GPU ou de serveur de modèle à gérer. Pour les équipes dont l’exigence est de “entraîner et exposer un modèle”, SageMaker est presque toujours la solution la moins lourde par rapport à une inférence maison sur ECS/EC2.

Les Savings Plans pour SageMaker engagent à une dépense en dollars par heure sur les composants éligibles (Studio, entraînement, traitement, inférence en temps réel) pour 1 ou 3 ans, offrant jusqu’à 64 % de réduction par rapport au tarif à la demande. Ils sont flexibles en termes de famille d’instances, de taille, de région et de composant — mais ne couvrent pas Ground Truth, le stockage ou le transfert de données. Utilisez les Savings Plans lorsque l’utilisation de base du ML est prévisible ; laissez l’entraînement en rafale sur des instances Spot pour cumuler les économies.

Services d’IA managés et ML personnalisé

Amazon Rekognition (images/vidéo : détection d’objets et de scènes, analyse faciale, modération), Textract (OCR plus extraction de formulaires et de tableaux) et Comprehend (NLP : reconnaissance d’entités, analyse de sentiments, détection de PII, classification personnalisée) exposent des modèles pré-entraînés via des API simples. La commande DetectEntities de Comprehend renvoie des entités typées, y compris une catégorie COMMERCIAL_ITEM — parfaite pour extraire les noms d’ingrédients d’un texte de recette et alimenter une recherche DynamoDB, sans données d’entraînement, sans hébergement et avec une tarification au paiement à l’usage :

aws comprehend detect-entities \
    --language-code en \
    --text "Combine 2 cups flour, 1 tsp salt, and 3 eggs..."

Le mode d’échec courant est la sur-ingénierie — mettre en place des tâches d’entraînement SageMaker, étiqueter des données avec Ground Truth et héberger des points de terminaison (endpoints) alors qu’un service managé couvre déjà le besoin pour une fraction du coût opérationnel. Le ML personnalisé ne se justifie que lorsque la précision sur des données spécifiques au domaine est matériellement plus élevée, lorsque les types d’entités requis ne correspondent pas au schéma managé (Comprehend Custom Classification/Entity Recognition reste moins cher que SageMaker brut), ou lorsque les contraintes de latence et de résidence des données exigent un modèle privé.

Stockage et réseau HPC : FSx for Lustre et EFA

Les charges de travail HPC fortement couplées — CFD, dynamique moléculaire, imagerie sismique, entraînement à grande échelle — ont deux exigences non négociables : une communication inter-nœuds à très faible latence et un stockage partagé à haut débit.

Elastic Fabric Adapter (EFA) est une interface réseau disponible sur des familles EC2 spécifiques (hpc7a, hpc6id, c6in, p4d/p5, etc.). Elle contourne la pile TCP/IP du noyau en utilisant le contournement de l’OS (OS-bypass) Libfabric, permettant à MPI et NCCL d’atteindre des latences de l’ordre de la microseconde sur des centaines de nœuds. EFA nécessite que les instances se trouvent dans la même zone de disponibilité (Availability Zone) et, pour une bande passante maximale, dans un groupe de placement en cluster (cluster placement group).

FSx for Lustre est un système de fichiers parallèle managé offrant un débit de plusieurs centaines de Go/s et une latence inférieure à la milliseconde. Il s’intègre nativement avec S3 : un système de fichiers FSx peut être lié à un bucket afin que les objets apparaissent comme des fichiers POSIX, et les résultats écrits sur Lustre peuvent être réexportés vers S3. Les déploiements SSD persistants conviennent aux espaces de travail temporaires (scratch) de longue durée ; Scratch2 est moins cher pour les données de tâches éphémères.

Le mauvais pattern est d’utiliser EFS pour le HPC. EFS est basé sur NFS, optimisé pour de nombreux petits clients effectuant des E/S de fichiers à usage général ; il ne peut pas soutenir le débit agrégé ou les IOPS de métadonnées nécessaires à une tâche MPI de 500 nœuds, et sa conception multi-AZ ajoute de la latence. L’utilisation de l’ENA standard au lieu de l’EFA plafonne MPI aux latences TCP, multipliant par plusieurs fois les temps d’exécution riches en opérations allreduce. La bonne association est des instances compatibles EFA dans un groupe de placement en cluster montant un système de fichiers FSx for Lustre, avec S3 comme stockage froid durable lié au système de fichiers.

← Bases de données et mise en cache · Tous les domaines · Intégration d’applications →

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

Parcourir Amazon →