Amazon CLF-C02: Services de base de données essentiels — Guide d'étude

By Laurynas Brazys · 28 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

Fait partie du AWS Cloud Practitioner CLF-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 relationnelles gérées : Amazon RDS et Amazon Aurora

Amazon RDS fournit des moteurs relationnels entièrement gérés (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle) avec des sauvegardes automatisées, le Multi‑AZ pour la haute disponibilité, des réplicas en lecture (read replicas) pour la mise à l’échelle, et une restauration basée sur des snapshots. Aurora est un moteur spécialement conçu, compatible avec MySQL et PostgreSQL, qui sépare la couche de calcul (compute) d’une couche de stockage distribuée et tolérante aux pannes pour offrir un débit plus élevé, une récupération rapide après incident, et des fonctionnalités comme le backtrack et Global Database pour la réplication inter-régions. Les modèles de tarification incluent les instances à la demande (On-Demand) pour une capacité flexible, les instances réservées (Reserved Instances) ou les Savings Plans pour des économies prévisibles, et des modèles de capacité serverless ou avec mise à l’échelle automatique pour Aurora Serverless afin d’aligner les coûts sur les charges de travail variables. Les décisions d’architecture clés dépendent du profil de lecture/écriture, des exigences de latence et de la tolérance opérationnelle : choisissez RDS lorsque la compatibilité et les besoins en licences sont prédominants, et Aurora lorsque vous avez besoin de performances plus élevées, d’une mise à l’échelle automatique du stockage ou de lectures globales. Les pièges courants pour les praticiens sont le sous-provisionnement des IOPS pour les charges de travail à forte écriture, l’oubli d’activer le Multi‑AZ pour la production, la conservation des identifiants maîtres par défaut, et le fait de ne pas tester la restauration à un instant T (point-in-time recovery). Pour la conformité, activez le chiffrement au repos (encryption at rest) avec AWS KMS, imposez TLS pour le chiffrement en transit (in-transit encryption), et validez que les sauvegardes automatisées et les snapshots respectent les objectifs de rétention et de reprise après sinistre (DR) inter-régions.

Bases de données NoSQL, de mise en cache et de graphes : DynamoDB, ElastiCache, Amazon Neptune

Pour les charges de travail de type clé-valeur et document à très grande échelle, Amazon DynamoDB offre une latence de l’ordre de quelques millisecondes, un partitionnement automatique et deux modes de capacité : provisionnée (avec mise à l’échelle automatique) et à la demande (on-demand) pour un trafic imprévisible. Des fonctionnalités comme DynamoDB Streams, les tables globales (global tables) et la restauration à un instant T (PITR) prennent en charge la réplication, la capture des changements de données (change data capture) et les sauvegardes. Un écueil courant est une mauvaise conception de la clé de partition qui crée des partitions “chaudes” (hot partitions) et du throttling ; modélisez d’abord les schémas d’accès aux données. Pour les charges de travail en mémoire à faible latence, utilisez ElastiCache : Redis offre la persistance, le clustering et le pub/sub, tandis que Memcached est un système de cache simple et multithread. Utilisez DAX pour les charges de travail DynamoDB à forte lecture nécessitant une mise en cache de l’ordre de la microseconde. Pour les requêtes de graphes centrées sur les relations, Amazon Neptune est une base de données de graphes entièrement gérée qui prend en charge Gremlin et SPARQL. Décisions de tarification : DynamoDB on-demand est simple mais plus coûteux pour un trafic élevé et constant ; le mode provisionné avec mise à l’échelle automatique et la capacité réservée (Reserved Capacity) peuvent être beaucoup moins chers. Le dimensionnement du cache, les politiques d’éviction et les choix de persistance dans ElastiCache affectent le coût et la récupération. Évaluez la durabilité, les modèles de cohérence et la complexité opérationnelle lors du choix entre les bases de données NoSQL gérées, les caches en mémoire et les bases de données de graphes.

DynamoDB vs RDS/Aurora : DynamoDB pour une mise à l’échelle massive, un schéma flexible, une conception à table unique ; RDS/Aurora pour les requêtes SQL complexes, les transactions et l’intégrité relationnelle.
ElastiCache (Redis) vs DAX : Redis pour les charges de travail en mémoire à usage général et la persistance ; DAX est un cache en lecture spécifique à DynamoDB avec une intégration côté client.
Neptune : À utiliser lorsque les parcours et l’analyse de graphes sont au cœur de l’application.

Analyses et architectures de lac de données : Amazon Redshift, Athena et choix de stockage S3

Amazon Redshift est un entrepôt de données (data warehouse) en colonnes, à l’échelle du pétaoctet, optimisé pour les requêtes analytiques complexes et une forte simultanéité (concurrency). Le Redshift moderne (nœuds RA3) découple le calcul (compute) et le stockage géré, vous permettant de mettre à l’échelle le calcul indépendamment et de réduire les coûts en utilisant S3 comme stockage géré ; Redshift Spectrum interroge directement les données dans S3 pour l’intégration avec le lac de données. Pour les requêtes SQL ad-hoc sur des fichiers, Amazon Athena fournit une solution d’analyse serverless, avec paiement à la requête (facturée par To de données scannées) et est idéale pour les fichiers CSV/Parquet/JSON sur S3 ; l’optimisation des formats et de la compression réduit considérablement les coûts. S3 propose plusieurs classes de stockage : pour les schémas d’accès inconnus, S3 Intelligent‑Tiering déplace automatiquement les objets entre les niveaux d’accès pour minimiser les coûts sans frais de récupération ; pour les archives à long terme, envisagez S3 Glacier ou Glacier Deep Archive où une latence et des frais de récupération s’appliquent. Les compromis de coût incluent le stockage par rapport au calcul : compressez, partitionnez et utilisez des formats en colonnes pour réduire les volumes de données scannées ; envisagez la mise à l’échelle de la simultanéité (concurrency scaling) de Redshift et la gestion des charges de travail (workload management) pour des performances prévisibles. Pour les charges de travail de machine learning liées à l’analytique, un entraînement intensif peut nécessiter des familles d’instances EC2 avec GPU (séries P ou G), mais la plupart des charges de travail de bases de données analytiques reposent sur un CPU optimisé et une exécution en colonnes plutôt que sur des GPU.

Migration, sauvegarde, sécurité et bonnes pratiques opérationnelles

La migration et la protection des bases de données nécessitent la bonne combinaison de services et de politiques. AWS Database Migration Service (DMS) gère les migrations homogènes et hétérogènes avec un temps d’arrêt minimal ; le Schema Conversion Tool aide à convertir les schémas de base de données lors du passage d’un type de moteur à un autre. Pour les sauvegardes et la protection basée sur des politiques, utilisez les fonctionnalités natives des moteurs (sauvegardes et snapshots automatisés RDS, DynamoDB PITR) ainsi qu’AWS Backup pour des politiques de sauvegarde centralisées et inter-services, et des copies inter-comptes ou inter-régions. La sécurité doit inclure des politiques IAM de moindre privilège, le chiffrement en transit (TLS) et au repos (KMS), ainsi que des contrôles réseau : les groupes de sécurité sont des pare-feux avec état (stateful) au niveau de l’hôte que vous attachez aux instances, tandis que les ACL réseau sont des filtres sans état (stateless) au niveau du sous-réseau — les deux sont complémentaires mais ont un comportement différent. Dans le cadre de la responsabilité partagée, AWS gère l’infrastructure cloud, tandis que les clients gèrent les données, IAM, les correctifs au niveau du système d’exploitation sur les instances autogérées, et la rotation des clés pour les secrets et les informations d’identification d’accès. L’automatisation opérationnelle à l’aide de CloudFormation, de l’AWS CLI ou des SDK permet un provisionnement d’environnement reproductible ; les pièges courants sont de s’appuyer sur le compte racine, de laisser en place des politiques IAM trop permissives, de négliger la rotation des clés et de ne pas effectuer de surveillance à l’aide de CloudWatch, VPC Flow Logs ou AWS Config. Pour les transferts de données volumineux, envisagez AWS Snowball ou DataSync pour déplacer des téraoctets/pétaoctets de manière sécurisée avec chiffrement en transit et validation de l’intégrité.

Problème pratique : Scénario d’utilisation

Scénario : AcmeRetail exploite une plateforme de e-commerce saisonnière avec une base de données OLTP MySQL sur site et de volumineux fichiers CSV de ventes historiques sur un partage NFS sur site. Leur compte AWS dispose d’un VPC avec des sous-réseaux privés et une Transit Gateway vers leur centre de données. Ils doivent migrer la base de données transactionnelle avec un temps d’arrêt minimal et rendre les données historiques interrogeables pour la BI.

Défi : Déplacer la base de données de production avec un temps d’arrêt quasi nul, permettre des analyses évolutives sur les CSV historiques, et garantir les sauvegardes, le chiffrement et l’accès selon le principe de moindre privilège.

Approche recommandée :

Utiliser AWS Database Migration Service (DMS) avec le Schema Conversion Tool si nécessaire pour migrer MySQL vers Amazon Aurora (compatible MySQL), en configurant la réplication continue pour minimiser le temps d’arrêt.
Transférer les CSV historiques vers Amazon S3 à l’aide d’AWS DataSync ou Snowball (pour les très grands volumes), les stocker dans S3 en utilisant Intelligent‑Tiering, et les convertir en Parquet avec un ETL AWS Glue pour l’efficacité des requêtes.
Provisionner Amazon Redshift (RA3) ou utiliser Amazon Athena sur les données S3 (Parquet) pour les requêtes BI ; utiliser Redshift Spectrum si vous combinez des requêtes sur l’entrepôt de données (warehouse) et le lac de données (lake).
Mettre en œuvre des sauvegardes automatisées (sauvegardes et snapshots automatisés RDS), activer le chiffrement avec des clés KMS, restreindre l’accès avec des rôles IAM et des groupes de sécurité de moindre privilège, et centraliser les politiques de sauvegarde avec AWS Backup.

Justification : La réplication continue de DMS permet une migration avec un temps d’arrêt quasi nul pour les systèmes transactionnels ; S3 + Parquet + Athena/Redshift minimise les coûts d’analyse et la taille des données scannées ; KMS, les sauvegardes et l’IAM de moindre privilège s’alignent sur la responsabilité partagée et les bonnes pratiques opérationnelles en matière de disponibilité, de sécurité et de contrôle des coûts.

← Services de stockage essentiels · Tous les domaines · Réseau et distribution de contenu →

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