Amazon DVA-C02: Bases de données et Mise en cache (RDS, Aurora, ElastiCache, Timestream, Proxy) — Guide d'étude

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Fait partie du AWS Developer Associate DVA-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.

RDS et Aurora : conception, mise à l’échelle et chiffrement

La conception de bases de données relationnelles sur RDS ou Aurora commence par l’arbitrage, en fonction de la charge de travail, entre une instance RDS provisionnée en nœud unique et le stockage distribué d’Aurora. Choisissez Aurora lorsque vous avez besoin d’une haute scalabilité en lecture et d’un basculement rapide : les réplicas Aurora partagent le volume du cluster, ce qui rend la promotion rapide, tandis que les réplicas en lecture RDS MySQL/Postgres utilisent une réplication asynchrone basée sur les binlogs et peuvent subir un décalage. Pour la mise à l’échelle des lectures, ajoutez des réplicas en lecture et dirigez le trafic de lecture de l’application vers eux ; utilisez les points de terminaison de lecture (reader endpoints) dans Aurora pour répartir automatiquement la charge entre les réplicas. Pour les écritures, la mise à l’échelle verticale (classe d’instance) et une conception soignée du schéma et des index sont essentielles. Activez toujours le chiffrement au repos avec une CMK KMS au moment de la création — l’activation ultérieure du chiffrement nécessite un snapshot et une restauration vers une nouvelle instance chiffrée ; c’est un piège courant. Pour la protection en transit, imposez des connexions TLS/SSL (RDS fournit des lots d’autorités de certification). Pour les informations d’identification, privilégiez AWS Secrets Manager avec la rotation automatique en utilisant le modèle Lambda de rotation RDS intégré ; récupérez les secrets par programmation avec

undefined

dans les SDK. Envisagez l’authentification de base de données IAM pour supprimer les mots de passe statiques : générez un jeton via

undefined

(SDK) ou

undefined

, puis connectez-vous avec un jeton à durée de vie limitée. Instrumentez avec Performance Insights, Enhanced Monitoring et CloudWatch ; utilisez les journaux des requêtes lentes et EXPLAIN pour identifier les points chauds.

Groupement de connexions, RDS Proxy et patterns serverless

Les fonctions serverless et les applications à forte consommation de connexions épuisent fréquemment les limites de connexion à la base de données. Le pattern simple dans Node.js consiste à placer un pool

undefined

dans la portée globale de la Lambda et à le réutiliser entre les invocations, mais cela ne résout pas le problème de la mise à l’échelle concurrente massive. RDS Proxy est la solution managée : créez le proxy avec

undefined

, associez-le aux secrets de Secrets Manager et aux instances RDS/Aurora cibles, et utilisez le point de terminaison du proxy depuis votre application. RDS Proxy gère le multiplexage des connexions, l’intégration de l’authentification IAM et le basculement. Pour Aurora Serverless ou lorsque vous préférez les appels de type HTTP, utilisez l’API de données RDS (RDS Data API) :

undefined

permet aux Lambdas d’exécuter du SQL sans connexions TCP persistantes. Un piège courant est de mélanger l’API de données avec des clusters provisionnés — l’API de données est conçue pour les clusters serverless et a une sémantique de latence et de transaction différente. Sachez également que RDS Proxy introduit un délai d’expiration du pool de connexions et un

undefined

; ajustez le délai d’expiration du client inactif et l’emprunt de connexion pour les pics d’activité des Lambdas. Utilisez

undefined

pour les informations d’identification et effectuez la rotation avec

undefined

ou activez la rotation automatique dans la console/SDK.

Stratégies de mise en cache : ElastiCache, DAX et conception de cache

Les choix de mise en cache dépendent de la source de données et des modèles d’accès. Pour DynamoDB, DAX fournit une latence de lecture de l’ordre de la microseconde et une intégration SDK transparente via

undefined

qui encapsule

undefined

; il est idéal pour les charges de travail à forte lecture et à cohérence éventuelle (eventually consistent). Pour la mise en cache relationnelle ou de paires clé-valeur arbitraires, utilisez ElastiCache Redis pour ses structures de données avancées, sa persistance (snapshots AOF/RDB), sa réplication et son partitionnement en mode cluster (sharding), ou Memcached pour une mise en cache simple et scalable horizontalement. Implémentez le pattern cache-aside pour les lectures, et les patterns write-through/write-behind uniquement lorsque c’est acceptable en termes de cohérence et de complexité. La conception des clés est essentielle : préfixez les clés par application et par version, utilisez des TTL pertinents et évitez la cardinalité non bornée. Gérez les « cache stampedes » (ruées sur le cache) avec des patterns de verrouillage et de rafraîchissement (

undefined

ou Redlock) ou un rafraîchissement anticipé probabiliste du TTL. Configurez Redis en multi-AZ avec basculement automatique ; créez des groupes de réplication avec basculement automatique et snapshots via

undefined

. Les pièges courants incluent des caches obsolètes après des écritures, la non-invalidation lors des changements de schéma et l’attente d’une cohérence absolue. Surveillez le taux de succès du cache (hit ratio) et les métriques d’éviction dans CloudWatch, et mettez à l’échelle les types de nœuds ou les partitions du cluster (shards) lorsque la mémoire ou le CPU devient un goulot d’étranglement.

Séries temporelles avec Timestream et modèles de réplicas en lecture

Amazon Timestream est spécialement conçu pour les séries temporelles : ingérez les données en utilisant l’API WriteRecords du SDK avec des appels WriteRecords groupés et interrogez-les avec TimestreamQuery.query(sql). Concevez votre schéma d’enregistrement avec des dimensions de faible cardinalité et utilisez des enregistrements multi-mesures pour réduire l’amplification d’écriture. Configurez des règles de rétention en mémoire et sur stockage magnétique par table pour conserver les données récentes « à chaud » (hot) et stocker les données plus anciennes à moindre coût ; l’ajustement de la rétention est essentiel car la taille de la rétention du niveau mémoire affecte le coût et les performances des requêtes. Pour l’analytique, utilisez des requêtes spécifiques aux séries temporelles (time_bin ou bin) et appliquez des filtres en amont (push down) sur les dimensions pour minimiser les données analysées. Lors de l’intégration de séries temporelles avec des bases de données relationnelles, déchargez les données historiques immuables vers Timestream et servez les métadonnées « chaudes » (hot) depuis RDS/Aurora avec ElastiCache. Pour la mise à l’échelle en lecture des bases relationnelles, ajoutez des réplicas en lecture (read replicas) et routez le trafic en lecture seule ; pour Aurora, utilisez les points de terminaison de lecture (reader endpoints) et examinez le décalage de réplication (CloudWatch ReplicaLag) avant de router les lectures critiques. Un piège courant pour les développeurs est une cardinalité élevée dans Timestream ou des clés de cache produites par requête, ce qui fait exploser le stockage et nuit aux performances. Utilisez le traitement par lots (batching) pour les écritures et des pipelines d’ingestion asynchrones (Kinesis, Firehose) pour lisser les pics de charge et éviter le throttling.

Problème pratique : Scénario d’utilisation

Scénario : NovaShop exploite une plateforme de e-commerce multi-régions sur AWS, utilisant Aurora MySQL pour les commandes dans us-east-1, avec des API basées sur Lambda et un catalogue client mondial dans DynamoDB. Les développeurs utilisent le CI/CD dans un seul compte AWS et stockent les informations d’identification de la base de données dans Secrets Manager.

Défi : Pendant les pics de ventes, les fonctions Lambda épuisent les connexions à la base de données et le catalogue nécessite des lectures en microsecondes ; les développeurs doivent préserver la sécurité avec des informations d’identification renouvelées (rotated) et une latence minimale pour les lectures de produits.

Approche recommandée :

Créez un RDS Proxy pour le cluster Aurora en utilisant CreateDBProxy, liez l’ARN du secret de Secrets Manager et configurez l’authentification IAM ; mettez à jour Lambda pour utiliser le point de terminaison du proxy et SecretsManager.getSecretValue() pour les informations d’identification.
Pour le catalogue, déployez un cluster Amazon DAX et basculez le client DynamoDB vers AmazonDaxClient({endpoints}) qui encapsule (wraps) le DocumentClient de DynamoDB pour des lectures en microsecondes.
Activez la rotation automatique de Secrets Manager pour le secret Aurora en utilisant le modèle Lambda de rotation RDS (rotate-secret ou à configurer via la console) et assurez-vous que le rôle IAM de Lambda peut appeler secretsmanager:GetSecretValue.
Ajoutez un cluster ElastiCache for Redis (en mode cluster) pour la mise en cache des sessions et implémentez le modèle cache-aside avec des TTL et un verrou de rafraîchissement SETNX pour éviter les ruées (stampedes).

Justification : L’utilisation de RDS Proxy prévient les tempêtes de connexions dues à la mise à l’échelle de Lambda, tandis que IAM/Secrets Manager protège les informations d’identification avec une rotation automatisée ; DAX fournit des lectures DynamoDB en microsecondes et ElastiCache gère la mise en cache transitoire des sessions/lectures, s’alignant sur les meilleures pratiques de mise à l’échelle sans serveur (serverless) et de sécurité.

← Stockage · Tous les domaines · Messagerie →

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