Amazon SAP-C02: Bases de données et analytique — Guide d'étude

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Fait partie du AWS Solutions Architect Professional SAP-C02 — 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.

Bases de données transactionnelles, modèles de mise à l’échelle et mise en cache

Le choix entre Amazon RDS (MySQL/PostgreSQL/Oracle/SQL Server), Amazon Aurora et Amazon DynamoDB commence par le profil de la charge de travail (workload) : un schéma relationnel strict et des transactions complexes favorisent RDS/Aurora ; une mise à l’échelle massive, des recherches en quelques millisecondes et un schéma flexible favorisent DynamoDB. Aurora offre un débit élevé avec un stockage distribué, une mise à l’échelle automatique des réplicas, un basculement rapide (fast failover), Global Database pour les lectures inter-régions et une reprise après sinistre (disaster recovery) à plus faible latence. RDS Multi-AZ fournit une réplication synchrone pour la disponibilité mais pas pour la mise à l’échelle en lecture ; les réplicas en lecture (read replicas) (RDS/Aurora) gèrent les charges de travail à forte composante de lecture. Pour la mise en cache clé-valeur et une latence de l’ordre de la microseconde, ElastiCache (Redis ou Memcached) réduit la charge sur la base de données ; MemoryDB for Redis ajoute la durabilité et une persistance compatible Redis là où les données doivent être hautement disponibles et récupérables. Les pièges courants incluent la sous-estimation des limites de connexion (nombre maximal de connexions MySQL), la non-utilisation du regroupement de connexions (connection pooling) (Lambda/conteneurs créant de nombreuses connexions), les partitions surchargées (hot partitions) dans DynamoDB dues à une mauvaise conception des clés, et la négligence de l’éviction/conception du cache menant à des données périmées (stale data). Les compromis décisionnels s’articulent souvent autour du coût par rapport à la performance et à la résilience : les instances Aurora/RDS de grande taille provisionnées coûtent plus cher mais réduisent la latence et simplifient les transactions, tandis que DynamoDB avec une capacité à la demande ou en mise à l’échelle automatique peut réduire les opérations mais nécessite une planification minutieuse du schéma et de la capacité. Le chiffrement, les sauvegardes automatisées, la restauration à un instant dans le passé (PITR) et les modèles de réplication inter-régions doivent être choisis en fonction des objectifs RPO/RTO.

Lac de données (Data Lake), ETL et moteurs de requêtes analytiques

S3 est le lac de données durable canonique ; la conception doit s’articuler autour du partitionnement, des formats colonnes (Parquet/ORC), de la compression et du compactage pour permettre des requêtes rentables. AWS Glue et AWS Glue Data Catalog fournissent un ETL serverless, la découverte de schémas et la création de catalogues ; Lake Formation ajoute un contrôle d’accès centralisé, des autorisations granulaires et le partage entre comptes pour des lacs de données gouvernés. Pour l’analytique interactive, Amazon Athena interroge directement les données S3 (serverless, paiement à la requête), tandis qu’Amazon Redshift (support RA3/Iceberg) fournit un entrepôt de données MPP (Massively Parallel Processing) géré et performant pour la BI complexe et les jointures. Utilisez Redshift Spectrum pour interroger les données S3 depuis Redshift sans avoir à tout ingérer. Kinesis Data Firehose est un chemin d’ingestion géré pour acheminer les événements de streaming vers S3 ou Redshift. Les pièges d’architecture courants incluent un trop grand nombre de petits fichiers provoquant une surcharge (overhead) élevée pour Athena/Redshift, des clés de partition mal choisies qui créent des déséquilibres (skews), et l’oubli de compacter ou de convertir les données en formats colonnes. Les compromis se situent entre la latence et le coût : Athena a un faible coût opérationnel pour les requêtes ad-hoc ; Redshift offre des performances soutenues plus élevées pour un coût provisionné plus important. La gouvernance des données et le lignage (lineage) via Glue/Lake Formation sont essentiels pour la conformité et la propriété partagée entre plusieurs équipes.

Streaming, traitement en temps réel et recherche

L’ingestion et le traitement en temps réel utilisent Kinesis Data Streams (débit basé sur les partitions (shards) et garanties d’ordre), Kinesis Data Firehose (livraison gérée vers des destinations (sinks)), Kinesis Data Analytics (traitement SQL/Apache Flink), ou Amazon MSK pour les besoins compatibles avec Kafka. Choisissez Kinesis pour une intégration serverless simple et native à AWS ; choisissez MSK lorsque les clients dépendent de l’outillage de l’écosystème Kafka. La sémantique de livraison « au moins une fois » (at-least-once), les limites de partitions (shards), le parallélisme des consommateurs et le provisionnement d’un nombre adéquat de partitions sont des écueils opérationnels courants. Pour la recherche rapide en aval et l’observabilité, Amazon OpenSearch Service fournit l’indexation, la recherche en quasi-temps réel et des tableaux de bord Kibana intégrés ; la gestion du cycle de vie des index et les niveaux de stockage tiède/froid (warm/cold tiers) réduisent le coût pour les données plus anciennes. Utilisez Kinesis + Lambda ou Kinesis + KDA pour enrichir/transformer les événements avant de les persister dans OpenSearch ou S3. Intégrez l’idempotence et la déduplication dans l’architecture des consommateurs, car les nouvelles tentatives (retries) ou les relectures (replays) provoquent des doublons. Les critères de décision équilibrent le débit et la latence : Kinesis avec de nombreuses partitions (shards) supporte un débit élevé mais augmente le coût et la gestion ; Firehose allège la charge des consommateurs mais offre une transformation moins flexible.

Migration, réplication, gouvernance et résilience opérationnelle

Database Migration Service (AWS DMS) et le Schema Conversion Tool (SCT) sont les principaux outils de migration pour les déplacements homogènes et hétérogènes, permettant la capture continue des données modifiées (CDC). Les modèles de migration incluent le rehost (lift-and-shift), le replatform (par ex., migrer vers Aurora) et le refactor vers DynamoDB ou serverless le cas échéant. Utilisez DMS avec une validation avant et après la migration, la copie de tables en parallèle et une gestion attentive des LOB/LOBLOB. La réplication entre comptes et entre régions nécessite un accès aux clés KMS, le VPC peering ou un Transit Gateway, et la planification de la bande passante réseau ; les Global Databases et les réplicas en lecture sont des alternatives lorsque des lectures à faible latence entre régions sont nécessaires. La gouvernance et la sécurité doivent inclure Lake Formation pour le partage de données, le principe du moindre privilège IAM, des politiques de ressources pour les snapshots S3 et RDS, et des VPC endpoints/PrivateLink pour éviter la sortie de trafic public. Les pièges opérationnels incluent une surveillance insuffisante (retard de réplication non détecté), le non-test du basculement/des runbooks, et les coûts de sortie de données (egress) cachés lors des transferts en masse. La stratégie de sauvegarde, de restauration à un instant T (PITR) et de récupération automatisée jouent un rôle dans les compromis RTO/RPO ; combinez la réplication pour la disponibilité avec des sauvegardes régulières pour la rétention à long terme et la conformité.

Problème pratique : Scénario de cas d’usage

Scénario : Acme Retail exploite une plateforme e-commerce dans une AWS Organization multi-comptes avec des charges de travail de production dans us-east-1 et europe-west-1. Ils stockent les parcours de navigation (clickstreams) et les événements transactionnels dans S3 et exploitent une base de données OLTP sur site qui doit être migrée vers AWS avec un temps d’arrêt minimal.

Défi : Migrer la base de données OLTP vers une cible hautement disponible, évolutive en lecture et inter-régions, tout en construisant un lac de données analytique gouverné sur S3 avec une capacité d’ingestion et de requêtage en temps réel.

Approche recommandée :

1. Utiliser AWS DMS avec SCT pour la conversion de schéma et configurer une CDC continue depuis la base de données sur site vers Amazon Aurora (Global Database) dans us-east-1 avec un réplica en lecture Aurora dans europe-west-1.
2. Ingérer les événements de parcours de navigation et transactionnels via Amazon Kinesis Data Streams et Firehose ; mettre en mémoire tampon et livrer les événements bruts à S3 au format Parquet, partitionnés par date et par région.
3. Cataloguer les données S3 avec AWS Glue, appliquer le contrôle d’accès via Lake Formation, et effectuer des ETL avec des jobs Glue (ou Glue Studio) pour produire des jeux de données organisés (curated) ; les exposer aux analystes via Amazon Athena et Redshift Spectrum.
4. Ajouter ElastiCache (Redis) pour la mise en cache à haute lecture des données de produits et de session fréquemment consultées (hot data) ; instrumenter la surveillance de bout en bout avec CloudWatch, activer la surveillance améliorée (Enhanced Monitoring) sur Aurora, et valider le basculement avec des runbooks.

Justification : Cette approche minimise le temps d’arrêt en utilisant la CDC de DMS, fournit des lectures globales à faible latence via Aurora Global Database, établit un lac de données S3 gouverné pour l’agilité analytique, et réduit la charge sur les systèmes OLTP grâce à la mise en cache et à l’ingestion en streaming découplée, conformément aux meilleures pratiques d’entreprise en matière de résilience et de performance.

← Stockage et gestion des données · Tous les domaines · Migration et modernisation →

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

Parcourir Amazon →