Amazon DOP-C02: Stockage, bases de données et gestion des données — Guide d'étude

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fait partie du AWS DevOps Engineer Professional DOP-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.

Vue d’ensemble

Le stockage, les bases de données et le mouvement des données sur AWS doivent être conçus pour la durabilité, la disponibilité, la rentabilité et l’automatisation. La maîtrise des classes de stockage et de la réplication S3, de la capacité et de la distribution mondiale de DynamoDB, des contrôles de configuration et des modèles de sauvegarde RDS/Aurora, de la mise en cache en mémoire, des systèmes de fichiers partagés et des services de migration de données permet de créer des systèmes fiables à faible latence, avec un comportement de récupération prévisible et des dépenses maîtrisées.

Amazon S3 : classes de stockage, cycle de vie, hiérarchisation intelligente et réplication

Les classes de stockage S3 alignent les coûts sur les modèles d’accès :

Standard : multi-AZ, faible latence, pas de frais de récupération. Par défaut pour les données à accès fréquent (hot data).
Intelligent-Tiering (S3 INT) : multi-AZ avec hiérarchisation automatique entre les niveaux d’accès Fréquent et Peu fréquent et des niveaux d’archivage optionnels. Des frais de surveillance et d’automatisation s’appliquent par objet ; les objets de moins de 128 Ko ne sont pas automatiquement hiérarchisés. Les niveaux Archive Access et Deep Archive Access sont optionnels (opt-in) avec des seuils basés sur le dernier accès ; des frais de récupération s’appliquent depuis les niveaux autres que l’accès fréquent.
Standard-IA et One Zone-IA : coût de stockage inférieur avec des frais de récupération ; facturation minimale pour 30 jours de stockage. One Zone-IA est sur une seule AZ pour les données recréables.
Glacier Instant Retrieval : accès en millisecondes avec une rentabilité d’archivage ; minimum de 90 jours.
Glacier Flexible Retrieval : récupération en quelques minutes à quelques heures, options bulk/standard/expedited ; minimum de 90 jours.
Glacier Deep Archive : récupération en quelques heures à 12 heures ; minimum de 180 jours. Choisissez le niveau le plus froid (coldest) viable en tenant compte des frais de durée de stockage minimale, des frais de récupération et des temps d’accès requis.

Les politiques de cycle de vie (Lifecycle policies) automatisent les transitions et les expirations en utilisant des filtres (préfixe, balises) pour un contrôle précis. Les actions clés incluent la transition vers les niveaux IA/Glacier après des seuils d’inactivité, la transition/expiration des versions non courantes dans les compartiments versionnés, l’expiration des marqueurs de suppression (delete markers) et l’abandon des chargements partitionnés (multipart uploads) incomplets. Le cycle de vie et le balisage d’objets (object tagging) sont cruciaux pour appliquer la rétention des données et la suppression défendable, en complément de S3 Object Lock (modes gouvernance/conformité) lorsque l’immuabilité est requise.

Intelligent-Tiering est idéal lorsque les modèles d’accès sont inconnus ou variables. Il préserve les performances (pas de délai de récupération depuis les niveaux d’accès fréquent/IA), élimine le besoin de ré-architecturer lorsque les modèles changent, et peut éventuellement archiver automatiquement vers des niveaux profonds en fonction du dernier accès, offrant ainsi le meilleur mélange d’agilité et de contrôle des coûts pour les ensembles de données à longue durée de vie avec un accès sporadique.

La réplication S3 fournit une copie durable et asynchrone des objets :

Prérequis : le versioning doit être activé sur la source et la destination. La configuration de la réplication définit le compartiment/compte/Région de destination, le filtre par préfixe/balises, la réplication des métadonnées (ACL, balises, S3 Object Lock), la classe de stockage, et si les marqueurs de suppression et les objets existants doivent être répliqués.
Same-Region Replication (SRR) : conformité/souveraineté des données, agrégation de journaux, traitement atomique entre comptes.
Cross-Region Replication (CRR) : reprise après sinistre (DR), réduction de la latence, distribution mondiale, conformité.
Objets chiffrés avec KMS : le rôle de réplication doit être autorisé à déchiffrer avec la clé KMS source et à chiffrer avec la clé KMS de destination. Spécifiez la clé KMS de la réplique dans la règle de réplication

undefined

. Pour une réplication entre comptes, mettez à jour la politique du compartiment de destination pour autoriser le rôle de réplication à écrire.

Objets existants : utilisez S3 Batch Replication pour les rattraper (backfill).
Replication Time Control (RTC) : ajoute un SLA de 15 minutes pour l’achèvement de la réplication, avec des métriques de réplication et des notifications pour surveiller les SLA. Utile pour la conformité et les RPO stricts.
Propriété et accès : lors de la réplication entre comptes, activez bucket owner preferred ou Object Ownership bucket owner enforced pour éviter la complexité des ACL et garantir que le compte de destination possède les répliques.

Bases de données sur AWS : DynamoDB, RDS et Aurora

Modes de capacité et mise à l’échelle de DynamoDB :

À la demande : aucune planification de capacité ; tarification à la requête ; idéal pour les charges de travail imprévisibles ou avec des pics et pour les nouvelles tables sans trafic connu.
Provisionné : définissez les RCU/WCU avec DynamoDB Application Auto Scaling sur une utilisation cible ; approprié pour un trafic stable ou prévisible et pour le contrôle des coûts.
Capacité adaptative : redistribue automatiquement le débit des partitions vers les clés chaudes, mais les partitions extrêmement chaudes nécessitent toujours une répartition de la charge (par ex., sharding en écriture). Les GSI ont une capacité distincte ; modélisez attentivement pour éviter la limitation (throttling).
La taille des éléments affecte la capacité : 1 WCU par écriture de 1 Ko ; 1 RCU par lecture fortement cohérente de 4 Ko ou par lecture éventuellement cohérente de 8 Ko.

Flux (Streams) DynamoDB et DAX :

Les flux (Streams) capturent les mutations au niveau des éléments avec une rétention de 24 heures. Choisissez les types de vue pour inclure les images NEW/OLD. Patrons courants : déclencheurs Lambda pour les écritures CQRS/événementielles, la synchronisation entre tables et les pistes d’audit. L’ordre est par clé de partition, et la livraison est au moins une fois (at-least-once).
DAX est un cache en mémoire géré, compatible avec l’API, pour DynamoDB qui réduit considérablement la latence en lecture. Il prend en charge les lectures éventuellement cohérentes ; les lectures fortement cohérentes doivent contourner DAX. Il propose une écriture immédiate (write-through) pour les mutations d’éléments et une invalidation basée sur le TTL. Utilisez des clusters multi-AZ pour la haute disponibilité et placez les sous-réseaux DAX à proximité des clients.

Tables globales DynamoDB :

Réplication multi-région, multi-maître utilisant des flux (streams) avec une résolution de conflit de type last-writer-wins (le dernier rédacteur l’emporte) basée sur un horodatage système. Concevez pour éviter les mises à jour concurrentes des mêmes attributs entre les régions ou implémentez une réconciliation côté application.
L’attribut TTL se réplique comme des données d’élément normales ; les suppressions pilotées par le TTL sont traitées par région et ne sont pas répliquées en tant que suppressions explicites.
Les sauvegardes et la restauration à un instant T (PITR) sont limitées à une région ; restaurez vers de nouvelles tables par région et (en option) recréez-les en tant que nouvelle table globale.

Configuration et sauvegardes d’Amazon RDS :

Les groupes de paramètres définissent les paramètres du moteur. Les paramètres statiques nécessitent un redémarrage ; les paramètres dynamiques s’appliquent immédiatement là où ils sont pris en charge. Utilisez des groupes de paramètres de base de données (DB parameter groups) pour les moteurs au niveau de l’instance et des groupes de paramètres de cluster pour Aurora.
Les groupes d’options activent des fonctionnalités natives du moteur (par ex., Oracle TDE/OEM, sauvegarde/restauration native de SQL Server, plugins MySQL/MariaDB). Les options peuvent nécessiter le redémarrage du moteur ; gérez soigneusement les fenêtres de changement.
Les sauvegardes automatisées permettent la restauration à un instant T (PITR) dans une fenêtre de rétention (jusqu’à 35 jours). Elles capturent des snapshots quotidiens et des journaux de transactions vers S3 ; les restaurations produisent de nouvelles instances.
Les snapshots manuels sont conservés jusqu’à leur suppression, sont copiables entre les régions et partageables entre les comptes (en respectant les autorisations de clé KMS pour les snapshots chiffrés). Utilisez la copie de snapshots entre régions comme base pour la reprise après sinistre (DR).

Spécificités d’Amazon Aurora :

Points de terminaison : le point de terminaison du cluster (writer) pointe toujours vers l’instance primaire pour les écritures. Le point de terminaison de lecture (reader) répartit la charge entre les réplicas. Les points de terminaison personnalisés peuvent sélectionner un sous-ensemble de lecteurs pour des pools de lecture hiérarchisés ou des charges de travail spécialisées. Dirigez toujours les écritures vers le point de terminaison d’écriture et les lectures vers le point de terminaison de lecture ou le point de terminaison personnalisé approprié pour minimiser les interruptions lors des basculements.
Serverless v2 : mise à l’échelle instantanée et à granularité fine des ACU sans redémarrage. Il s’exécute au sein d’un cluster Aurora, prend en charge les instances mixtes (serverless et provisionnées) et convient bien aux charges de travail avec des pics, au dev/test ou aux applications multi-locataires avec une demande inégale. Il préserve mieux la cohérence des connexions que la v1 grâce à une mise à l’échelle continue.
Clonage : clones rapides par copie sur écriture (copy-on-write) au sein d’une région pour le dev/test, la science des données ou la validation de changements blue/green. Les clones sont économes en espace et ne divergent que sur les pages modifiées. Vous pouvez enchaîner les clones ; supprimez-les une fois terminé pour récupérer l’espace de stockage.

Mise en cache et systèmes de fichiers partagés : ElastiCache et EFS

ElastiCache for Redis vs Memcached :

Redis : structures de données avancées, réplication, Pub/Sub, Lua, streams, géospatial, ensembles triés (sorted sets) et persistance via des snapshots ; prend en charge le basculement automatique Multi-AZ et Redis Global Datastore pour les réplicas en lecture inter-régions. Choisissez Redis lorsque vous avez besoin de types de données riches, de durabilité (restauration de snapshot) ou de haute disponibilité avec basculement.
Memcached : simple, multithread, sans réplication ni persistance ; mise à l’échelle horizontale (scale-out) via le sharding côté client ; sans état et facile à mettre à l’échelle horizontalement. Choisissez Memcached pour une mise en cache pure et éphémère avec un très haut débit et lorsque vous souhaitez contrôler le sharding au niveau du client. Mode cluster et groupes de réplication Redis :
Mode cluster désactivé : un seul shard avec une instance primaire et des réplicas ; mise à l’échelle verticale ou mise à l’échelle horizontale limitée via des réplicas en lecture.
Mode cluster activé : sharding par slot de hachage (hash-slot) sur plusieurs shards primaires, chacun avec des réplicas, permettant une mise à l’échelle horizontale quasi linéaire. Les groupes de réplication définissent la topologie primaire/réplica et le basculement Multi-AZ. Les sauvegardes se font par groupe de réplication ; testez le basculement pour valider le RTO.

Amazon EFS pour les fichiers POSIX partagés :

Cibles de montage : créez-en une dans chaque AZ du VPC pour garantir les chemins d’accès et la disponibilité intra-AZ. Les groupes de sécurité sur les cibles de montage contrôlent le trafic NFS ; utilisez l’assistant de montage EFS (mount helper) pour le chiffrement TLS en transit et l’autorisation IAM si nécessaire.
Points d’accès : appliquez un répertoire racine et une identité POSIX (UID/GID) pour les applications, permettant l’isolation multi-locataire et un montage simple avec le moindre privilège par ECS/EKS/EC2 sans avoir à coordonner la gestion des utilisateurs du système d’exploitation.
Gestion du cycle de vie et classes de stockage : EFS Standard et Standard-IA (régional, multi-AZ) et One Zone/One Zone-IA (mono-AZ). La hiérarchisation intelligente (Intelligent Tiering) déplace automatiquement les fichiers entre les classes standard et IA en fonction de la dernière heure d’accès ; vous pouvez également définir des politiques de transition explicites. Choisissez les variantes One Zone pour les données recréables ou non critiques afin de réduire les coûts. Combinez avec AWS Backup pour des politiques centralisées et des sauvegardes inter-comptes/régions.

Migration de données : DMS, Snowball et DataSync

AWS Database Migration Service (DMS) : migration en ligne avec un temps d’arrêt minimal en utilisant un chargement complet suivi d’une capture des données modifiées (CDC). Prend en charge les migrations homogènes et hétérogènes grâce à la conversion de schéma intégrée (avec AWS Schema Conversion Tool pour les conversions complexes). À utiliser pour le lift-and-shift vers RDS/Aurora, vers DynamoDB (via un mappage JSON), ou pour la réplication continue afin de décharger les lectures ou pour des basculements progressifs. Dimensionnez les instances de réplication pour les pics de taux de changement ; assurez-vous que les journaux sources (par ex., binlog/redo) conservent un historique suffisant.
AWS Snowball (Edge Storage/Compute Optimized) : transfert de données hors ligne à l’échelle du pétaoctet lorsque les réseaux sont limités/coûteux ou lorsque vous devez amorcer rapidement des jeux de données S3/EFS massifs. Chaînez plusieurs appareils pour des charges de plusieurs pétaoctets. À utiliser pour les chargements initiaux en masse, la collecte à distance/en périphérie (edge), ou la migration hors de datacenters contraints. Les données sont chiffrées de bout en bout avec KMS ; le suivi des appareils et les scellés d’inviolabilité soutiennent la chaîne de possession.
AWS DataSync : transfert en ligne accéléré pour NFS/SMB vers S3/EFS/FSx et entre les services de stockage/Régions AWS. Il gère la détection des changements incrémentiels, la parallélisation, la compression, le contrôle de la bande passante, la planification et les contrôles d’intégrité. À utiliser pour déplacer des deltas récurrents, pour des workflows hybrides, et pour remplacer des scripts rsync personnalisés par une automatisation gérée. Déployez l’agent DataSync sur site pour accéder au stockage local.

Scénario de problème pratique

Shopify doit moderniser son pipeline mondial de médias produits et ses données de catalogue tout en améliorant la résilience et la latence pour les acheteurs du monde entier. L’entreprise doit : répliquer les images de produits entre les Régions et les comptes avec un RPO strict, réduire la latence de lecture de DynamoDB en Amérique du Nord et en Europe, migrer les ressources NFS sur site avec des deltas continus, et simplifier les opérations RDS avec des sauvegardes fiables.

Mettre en œuvre S3 CRR avec Replication Time Control depuis le bucket de médias principal dans us-east-1 (compte de merchandising) vers un bucket de destination dans eu-west-1 (compte de livraison).

Pourquoi : CRR satisfait à la séparation inter-régions et inter-comptes pour le moindre privilège et la souveraineté des données. RTC fournit un SLA de réplication de 15 minutes et une surveillance pour un RPO de niveau conformité. La politique de bucket inter-comptes garantit que le rôle de réplication source peut écrire, et la spécification d’une clé KMS de destination maintient les domaines de chiffrement.

Définir des règles de réplication S3 filtrées par préfixe et par balise pour séparer les originaux, les vignettes et les journaux, et activer la réplication des marqueurs de suppression. Utiliser S3 Batch Replication pour remplir les objets hérités.

Pourquoi : Le ciblage des règles évite les coûts de réplication inutiles, et la réplication des marqueurs de suppression maintient la cohérence sémantique entre les Régions. Batch Replication comble les lacunes historiques sans scripts sur mesure.

Convertir le catalogue de produits et l’inventaire en une table globale DynamoDB entre us-east-1 et eu-west-1 ; basculer les tables en capacité à la demande et ajouter des clusters DAX par Région pour les API à forte charge de lecture.

Pourquoi : Les tables globales fournissent des écritures actif-actif avec des lectures/écritures locales à faible latence et une réplication continue. Le mode à la demande élimine le risque de planification de la capacité lors des pics de trafic. DAX réduit les latences P99 pour les lectures fréquentes, protégeant DynamoDB des accès en rafale.

Migrer la charge de travail relationnelle des commandes vers Amazon Aurora MySQL avec des points de terminaison d’écriture et de lecture ; ajouter un petit lecteur Aurora Serverless v2 pour les analyses avec des pics d’activité et activer les sauvegardes automatisées avec une politique de rétention de 14 jours.

Pourquoi : Les points de terminaison de cluster/lecteur découplent la lecture/écriture et minimisent les interruptions pendant la maintenance ou le basculement. Serverless v2 absorbe les rafales analytiques imprévisibles de manière rentable. Les sauvegardes automatisées offrent une restauration à un instant T (PITR) et des processus de restauration simplifiés.

Introduire ElastiCache for Redis (mode cluster activé) pour le stockage de session et la mise en cache de la disponibilité des produits avec Multi-AZ et des sauvegardes par snapshots ; définir des TTL alignés sur les SLA métier.

Pourquoi : Les structures de données de Redis et le basculement Multi-AZ garantissent des sessions avec état (stateful) rapides et une invalidation de cache quasi temps réel. Le mode cluster se met à l’échelle horizontalement à mesure que la taille du catalogue et le trafic augmentent.

Créer un système de fichiers EFS régional avec des cibles de montage dans chaque AZ d’application et des points d’accès pour les charges de travail qui nécessitent un stockage POSIX partagé (par ex., les processeurs de médias). Activer les transitions de cycle de vie EFS vers IA après 30 jours.

Pourquoi : EFS fournit un stockage partagé élastique et multi-AZ ; les points d’accès appliquent une isolation par application et des identités POSIX. La gestion du cycle de vie réduit automatiquement les coûts pour les ressources froides qui restent accessibles.

Migrer les bibliothèques de médias NFS sur site en utilisant AWS DataSync avec des tâches planifiées pour des synchronisations incrémentielles nocturnes vers S3 et EFS.

Pourquoi : DataSync gère la détection des changements, le parallélisme, la vérification de l’intégrité et le contrôle de la bande passante mieux qu’un script rsync ad hoc, automatisant les deltas continus avec un minimum d’opérations.

Déplacer le catalogue PostgreSQL hérité vers Aurora en utilisant AWS DMS (chargement complet plus CDC) et AWS Schema Conversion Tool si nécessaire ; basculer une fois que le retard du CDC est résorbé.

Pourquoi : DMS permet une migration quasi sans interruption de service, avec une réplication continue garantissant la parité des données lors du basculement. SCT gère les conversions spécifiques au moteur.

Amorcer plusieurs pétaoctets de médias historiques dans S3 à l’aide d’appareils Snowball Edge, puis passer à DataSync pour les incréments continus.

Pourquoi : Snowball accélère le transfert initial en masse sans saturer les liaisons WAN ; DataSync maintient les mises à jour continues après l’amorçage avec vérification et planification.

Cette architecture réduit les latences de lecture mondiales, offre des RPO de réplication prévisibles, simplifie les opérations relationnelles et les sauvegardes, centralise le stockage partagé avec des contrôles d’accès, et fournit une voie pragmatique allant de la migration hors ligne en masse à un mouvement de données incrémentiel et automatisé.

← Architectures événementielles et automatisation · Tous les domaines · Réseau et livraison de contenu →

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