Amazon SAA-C03: Bases de données et mise en cache — 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.

Amazon RDS : Moteurs relationnels gérés

Amazon RDS fournit six moteurs gérés — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server et Amazon Aurora (compatible MySQL et PostgreSQL) — faisant abstraction de l’application des correctifs, des sauvegardes, de la topologie de réplication et du basculement. Le choix du moteur détermine les licences, la sémantique des sauvegardes et la disponibilité des fonctionnalités : Oracle et SQL Server présentent des distinctions entre BYOL (Bring Your Own License) et Licence Incluse, SQL Server prend en charge jusqu’à cinq réplicas en lecture via la réplication native, et les réplicas en lecture Oracle nécessitent l’Enterprise Edition avec Active Data Guard.

Les deux fonctionnalités RDS les plus utilisées pour la disponibilité et la mise à l’échelle — et les deux plus fréquemment confondues — sont les déploiements Multi-AZ et les réplicas en lecture. Elles sont orthogonales, complémentaires et non interchangeables.

Le Multi-AZ provisionne un réplica de secours synchrone dans une deuxième zone de disponibilité. Chaque écriture est validée à la fois sur l’instance principale et sur l’instance de secours avant d’être acquittée, offrant un RPO (Recovery Point Objective) effectivement nul et un RTO (Recovery Time Objective) de 60 à 120 secondes lors d’un basculement automatique. L’instance de secours n’accepte aucun trafic — elle existe uniquement pour le basculement. Lorsque l’instance principale tombe en panne, qu’une zone de disponibilité est défaillante ou qu’une maintenance nécessite un redémarrage, RDS bascule le CNAME DNS vers l’instance de secours et les applications se reconnectent de manière transparente via le même point de terminaison. Le Multi-AZ est la solution la plus simple pour corriger un point de défaillance unique dans une seule zone de disponibilité : c’est une simple option de configuration, qui ne nécessite aucune modification du schéma ou de l’application, et qui préserve le point de terminaison. Le plus récent déploiement de cluster Multi-AZ est une topologie à trois nœuds (un nœud d’écriture, deux nœuds de secours lisibles) utilisant une réplication semi-synchrone avec une latence de validation d’environ une seconde, offrant ainsi une haute disponibilité ainsi qu’une répartition de charge de lecture limitée.

Les réplicas en lecture utilisent la réplication asynchrone native du moteur (binlog MySQL, streaming WAL PostgreSQL). Ils sont l’outil approprié pour la mise à l’échelle en lecture — requêtes analytiques, tableaux de bord de reporting, SELECT ad-hoc — qui, autrement, affameraient les charges de travail OLTP sur l’instance principale. Le scénario canonique : une base de données de traitement des commandes qui expire (timeout) parce que les employés exécutent de longs rapports de fin de mois. L’ajout d’un réplica en lecture et la redirection de l’outil de reporting vers son point de terminaison isolent la charge analytique sans avoir à augmenter la taille de l’instance principale. Les réplicas en lecture peuvent être inter-régionaux et peuvent être promus manuellement en bases de données autonomes, mais la promotion n’est jamais automatique et toutes les transactions qui n’ont pas encore été répliquées au moment de la défaillance sont perdues.

Deux pièges reviennent fréquemment dans ce domaine. Premièrement, considérer les réplicas en lecture comme une solution de haute disponibilité est une erreur pour plusieurs raisons : les réplicas sont asynchrones (perte de données potentielle), n’ont pas de promotion automatique, le point de terminaison change lors de la promotion, et les transactions en cours disparaissent. Si une architecture promet « zéro perte de données » et désigne un réplica en lecture comme cible de basculement, cette promesse est fausse. Deuxièmement, provisionner du Multi-AZ pour servir le trafic de lecture est un gaspillage d’argent car l’instance de secours n’est pas lisible dans la topologie standard. Le Multi-AZ résout la disponibilité ; les réplicas en lecture résolvent la mise à l’échelle en lecture ; on a souvent besoin des deux.

Les réplicas en lecture ne font rien non plus pour la mise à l’échelle en écriture — chaque écriture atteint toujours l’instance principale et les réplicas doivent la rejouer. Pour la mise à l’échelle en écriture, on utilise le sharding, on migre vers Aurora (stockage découplé), ou on repense l’architecture en direction de DynamoDB.

Dimensionner correctement les réplicas en lecture

Un réplica n’a pas besoin d’avoir la même classe d’instance que l’instance principale. L’instance principale gère la charge d’écriture complète plus les lectures ; un réplica ne gère que les lectures qui lui sont adressées. Une instance principale db.r6i.4xlarge associée à un réplica db.r6i.large pour une tâche de reporting nocturne est tout à fait raisonnable — à condition que le réplica puisse suivre les E/S de réplication. La méthodologie est la suivante : mesurer l’utilisation réelle du CPU, de la mémoire et le retard de réplication (replica lag) du réplica, puis le dimensionner en fonction de cette charge de travail. La seule mise en garde : si vous avez l’intention de promouvoir un réplica pour qu’il devienne l’instance principale lors d’un plan de reprise d’activité (DR), il doit être dimensionné pour gérer la charge d’écriture. Les réplicas sous-dimensionnés ne sont pas des cibles de promotion.

Déploiements Blue/Green et stockage

Les déploiements Blue/Green RDS créent une copie de pré-production (green) complète de l’environnement de production, qui reste synchronisée via la réplication logique. Vous mettez à niveau la version du moteur, modifiez les groupes de paramètres ou altérez les schémas sur l’environnement green, vous le testez, et vous basculez en moins d’une minute avec un renommage automatique du point de terminaison. Cela élimine le risque classique d’une mise à niveau sur place où l’échec d’une mise à niveau de version majeure force une restauration à partir d’un snapshot.

La sélection du stockage est aussi importante que la classe d’instance pour les charges de travail OLTP intensives en écriture. La taxonomie gp3/io2 :

L’amélioration de gp3 par rapport à gp2 est le découplage des IOPS de la taille — vous n’avez plus besoin de sur-provisionner la capacité pour obtenir des performances. Choisissez io2 lorsque les IOPS soutenus dépassent le plafond de gp3 ou lorsqu’une durabilité de 99,999 % est requise. Multi-Attach permet à un seul volume io2 de s’attacher à un maximum de 16 instances Nitro, mais le système de fichiers ou l’application doit être compatible avec les clusters ; ce n’est pas un substitut à la réplication. Un piège pouvant causer une panne latente : provisionner un stockage fixe sans activer le storage autoscaling ou sans une alarme CloudWatch sur la métrique FreeStorageSpace. Lorsque l’espace libre atteint zéro, RDS passe à l’état storage-full et rejette les écritures.

Amazon Aurora : Architecture et points de terminaison

Aurora réimplémente la couche de stockage sous-jacente à MySQL et PostgreSQL sous la forme d’un volume distribué, structuré en journal, répliqué six fois sur trois zones de disponibilité (AZ). Les nœuds de calcul sont sans état (stateless) par rapport au stockage, de sorte qu’un réplica Aurora lit à partir du même volume sous-jacent que l’instance d’écriture plutôt que de rejouer un journal. Le décalage de réplication (replication lag) est généralement de 10 à 20 ms, contre plusieurs secondes pour les réplicas RDS standard, et un cluster prend en charge jusqu’à 15 réplicas qui peuvent être promus en instance d’écriture en environ 30 secondes.

Aurora expose quatre types de points de terminaison :

Les points de terminaison personnalisés sont importants lorsque les réplicas sont hétérogènes. Si trois des six réplicas sont de type db.r6g.8xlarge pour le reporting analytique tandis que les autres servent les lectures OLTP, le point de terminaison de lecture général acheminera occasionnellement le reporting vers des nœuds plus petits, nuisant à la prévisibilité. Un point de terminaison personnalisé limité aux seuls grands réplicas offre une isolation déterministe de la charge de travail :

aws rds create-db-cluster-endpoint \
  --db-cluster-identifier prod-aurora \
  --db-cluster-endpoint-identifier reporting \
  --endpoint-type READER \
  --static-members reporting-node-1 reporting-node-2 reporting-node-3

Notez que le TTL DNS des points de terminaison Aurora est de 5 secondes ; mettre en cache les chaînes de connexion plus longtemps compromet le comportement de basculement (failover).

Aurora Auto Scaling ajoute et supprime des réplicas en lecture (readers) en fonction de métriques cibles de CPU ou de connexions, ce qui est la réponse canonique pour les charges de travail imprévisibles et à forte lecture qui doivent rester hautement disponibles :

TargetTrackingScalingPolicyConfiguration:
  PredefinedMetricSpecification:
    PredefinedMetricType: RDSReaderAverageCPUUtilization
  TargetValue: 60.0
  ScaleInCooldown: 300
  ScaleOutCooldown: 60

Lorsque les réplicas en lecture RDS MySQL ne peuvent pas maintenir un décalage de réplication inférieur à une seconde en période de pointe, la solution simple (low-code) est de migrer vers Aurora MySQL — les chaînes de connexion changent à peine, et la réplication au niveau du stockage élimine le décalage.

Aurora Serverless v2 et clonage

Aurora Serverless v2 met à l’échelle la capacité de calcul verticalement par unités de capacité Aurora (ACU, 2 Gio de mémoire chacune) en une demi-seconde environ, sans déconnecter les sessions. Il convient aux charges de travail variables avec une empreinte mémoire de base connue — par exemple, une migration d’un MySQL sur site (on-prem) qui consomme toujours au moins 2 Gio. Définissez un minimum de 1 ACU et un maximum de 32 ACU, et le cluster s’adaptera sans administration. Aurora provisionné reste préférable lorsque la charge est stable et prévisible, car Serverless v2 entraîne un surcoût par ACU.

Le clonage Aurora crée un nouveau cluster qui partage les pages de stockage de la source via le mécanisme de copie sur écriture (copy-on-write). Les clones apparaissent en quelques secondes et ne coûtent rien jusqu’à ce que les données divergent, ce qui les rend idéaux pour les environnements de pré-production (staging), les migrations risquées, ou pour permettre aux analystes de solliciter intensivement une copie de la production. Une restauration à partir d’un instantané (snapshot) réhydrate physiquement les données et peut prendre des heures ; le clonage l’emporte lorsque la vitesse est essentielle.

Aurora Global Database

Aurora Global Database étend un cluster à un maximum de cinq régions secondaires en utilisant une infrastructure de réplication dédiée au niveau de la couche de stockage — et non l’envoi de journaux binaires (binlog). Le décalage de réplication typique est inférieur à une seconde, le RPO est inférieur à une seconde, et le basculement géré (managed failover) promeut une région secondaire en moins d’une minute.

Deux sémantiques critiques : les régions secondaires sont en lecture seule en fonctionnement normal, et Global Database est conçu pour la reprise après sinistre (DR) à faible RPO et les lectures à distance à faible latence, et non pour une architecture multi-maître actif-actif. Supposer qu’une base de données globale « gère automatiquement les écritures dans la région secondaire » est faux — les écritures y nécessitent un basculement géré explicite ou une opération de détachement et promotion. Pour une exigence spécifiée de RPO de 5 minutes / RTO de 20 minutes entre les régions avec une surcharge opérationnelle minimale, Global Database est la réponse canonique.

RDS Proxy et gestion des connexions

Les charges de travail sans serveur (serverless) et hautement concurrentes aggravent un problème classique : les tempêtes de connexions (connection storms). Une fonction Lambda qui atteint 3 000 exécutions simultanées ouvre 3 000 sockets, dépassant la limite max_connections et provoquant des défaillances en cascade — précisément au moment où le système est sous charge. Les pools de connexions au sein de la fonction n’aident pas, car chaque environnement d’exécution simultanée est isolé.

RDS Proxy se place entre les clients et la base de données, maintenant un pool de connexions pré-établies (warm pool) et multiplexant les sessions client sur celles-ci. Il résout deux problèmes :

1. Tempêtes de connexions. Des milliers de sessions client sont multiplexées sur un petit pool de connexions côté base de données.
2. Temps de basculement. Le proxy maintient les connexions client ouvertes pendant qu’il rétablit le lien avec la base de données, réduisant le temps de basculement perçu jusqu’à 66 % et éliminant le rétablissement TCP/TLS et la re-résolution DNS côté client.

Il s’intègre avec IAM et Secrets Manager pour la gestion des informations d’identification, supprimant ainsi les secrets codés en dur du code de l’application.

DBProxy:
  Type: AWS::RDS::DBProxy
  Properties:
    EngineFamily: POSTGRESQL
    RequireTLS: true
    IdleClientTimeout: 1800
    Auth:
      - AuthScheme: SECRETS
        SecretArn: !Ref DBSecret
        IAMAuth: REQUIRED

Les applications se connectent au point de terminaison du proxy, et non au point de terminaison du cluster. Toute architecture Lambda-vers-RDS ou à forte sollicitation (high-fan-out) devrait utiliser RDS Proxy, sauf raison spécifique de ne pas le faire. Exécuter votre propre gestionnaire de pool (PgBouncer, ProxySQL) sur EC2 est possible, mais cela ajoute la surcharge opérationnelle que le proxy vise justement à éliminer.

DynamoDB : Modes de capacité

DynamoDB est une base de données clé-valeur/document gérée offrant une latence de quelques millisecondes à n’importe quelle échelle, partitionnée horizontalement par une clé de hachage. Elle propose deux modes de capacité :

Le mode à la demande est radicalement plus simple, mais coûte environ 6 à 7 fois plus cher par requête qu’une capacité provisionnée bien utilisée. Pour un traitement par lots nocturne de 4 heures à 500 WCU, le mode à la demande est nettement plus coûteux — le mode provisionné avec une mise à l’échelle planifiée ou une capacité réservée est bien moins cher. Inversement, utiliser le mode provisionné pour une charge de travail imprévisible lors d’un lancement public entraînera du throttling. Pour les charges de travail stables avec une variance modérée, le mode provisionné avec l’auto-scaling avec suivi de cible autour de 70 % d’utilisation est significativement moins cher que le mode à la demande — souvent de 50 à 70 % :

TargetTrackingScalingPolicyConfiguration:
  TargetValue: 70.0
  PredefinedMetricSpecification:
    PredefinedMetricType: DynamoDBReadCapacityUtilization
  ScaleInCooldown: 60
  ScaleOutCooldown: 60

Vous pouvez changer de mode une fois toutes les 24 heures. Supposer que le mode à la demande est universellement moins cher est une erreur coûteuse ; tout comme supposer que le mode provisionné est toujours adapté à un trafic avec des pics.

DynamoDB : Cohérence, Streams et Global Tables

Les lectures sont par défaut à cohérence à terme (peuvent retourner des données obsolètes datant de ~1 seconde, coûtent 0,5 RCU). Définir ConsistentRead=true renvoie la dernière valeur validée (commit) pour le double du coût. Les lectures fortement cohérentes ne sont pas prises en charge via les index secondaires globaux ou via DAX — ces chemins retournent toujours des données avec une cohérence à terme.

DynamoDB Streams capture les modifications au niveau des éléments sous la forme d’un journal ordonné conservé pendant 24 heures, déclenchant des fonctions Lambda pour le traitement en aval (indexation pour la recherche, notifications, dénormalisation entre tables) sans avoir à effectuer de polling.

Global Tables s’appuie sur Streams pour fournir une réplication multi-active et multi-région avec une résolution de conflits de type « le dernier rédacteur l’emporte » (last-writer-wins). C’est la bonne solution lorsque les lectures et les écritures doivent être locales dans plusieurs régions. Cependant, elles doublent approximativement les coûts de stockage et d’écriture — chaque écriture consomme une WCU dans chaque région répliquée — et affaiblissent la cohérence entre les régions. Le piège est d’activer Global Tables alors qu’une seule région suffit aux exigences de disponibilité : DynamoDB dans une seule région est déjà répliqué sur trois zones de disponibilité (AZ) avec une disponibilité de 99,99 %. Une haute disponibilité (HA) mono-région et rentable consiste en une table mono-région avec PITR activé et, si souhaité, une capacité provisionnée avec auto-scaling.

La restauration à un instant dans le passé (PITR) fournit des sauvegardes continues avec une granularité de restauration à la seconde près pour les 35 derniers jours, avec une surcharge négligeable. Activez-la sur toute table de production — elle répond aux exigences RPO typiques de quelques minutes plutôt que de quelques heures. Pour une rétention plus longue (conservation à des fins réglementaires), intégrez AWS Backup pour des sauvegardes planifiées, gérées par cycle de vie et copiables entre régions.

TTL vous permet de spécifier un attribut contenant une date d’expiration au format epoch Unix ; DynamoDB supprime de manière asynchrone les éléments expirés sans frais, ce qui est idéal pour les magasins de sessions, les jetons éphémères ou les caches d’événements. Les suppressions TTL passent par Streams pour l’archivage en aval :

TTLSpecification:
  AttributeName: expireAt
  Enabled: true

Pour l’analytique, l’export vers S3 produit un instantané (snapshot) à un instant T lisible par Athena, Redshift Spectrum ou EMR sans consommer la capacité de la table — un pattern bien meilleur que de scanner la table.

DAX : DynamoDB Accelerator

DAX est un cache en mémoire de type write-through (écriture directe) entièrement géré, spécifiquement pour DynamoDB, offrant une latence de lecture de l’ordre de la microseconde par rapport à la latence de base de quelques millisecondes de DynamoDB. Sa caractéristique distinctive est sa compatibilité API : le client DAX est un remplacement direct du client SDK de DynamoDB, de sorte que les applications l’adoptent en modifiant la configuration du point de terminaison plutôt qu’en réécrivant la logique des requêtes :

import amazondax
dax = amazondax.AmazonDaxClient(
    endpoint_url='dax://cluster.abc.dax-clusters.us-east-1.amazonaws.com')
table = dax.Table('Products')
resp = table.get_item(Key={'sku': '1234'})  # microsecond hit path

DAX maintient deux caches : un cache d’éléments pour les résultats de GetItem/BatchGetItem et un cache de requêtes pour les résultats de Query/Scan. Les écritures sont de type write-through — DAX agit comme un proxy vers DynamoDB et met à jour son cache d’éléments en cas de succès — mais le cache de requêtes repose sur un TTL, de sorte que les résultats des requêtes peuvent devenir obsolètes même pour des éléments fraîchement écrits.

Deux contraintes sont importantes. Premièrement, DAX n’accélère que les lectures à cohérence à terme ; les lectures fortement cohérentes contournent le cache. Deuxièmement, d’autres processus d’écriture qui contournent DAX provoquent l’obsolescence des données. Pour une page de détails de produit consultée des millions de fois par jour, DAX est l’accélérateur avec le moins de surcharge opérationnelle — pas de code d’invalidation de cache, pas de gestion de cluster séparée. ElastiCache devant DynamoDB fonctionnerait, mais nécessiterait une logique de type cache-aside que DAX rend superflue.

ElastiCache : Redis et Memcached

ElastiCache fournit un accès aux données en mémoire inférieur à la milliseconde en tant que service géré exécutant Redis ou Memcached. Le choix du moteur est dicté par les fonctionnalités :

• Memcached — un pur cache clé-valeur multithread avec partitionnement horizontal (sharding), sans persistance, sans réplication, sans pub/sub. À n’utiliser que pour la mise en cache éphémère où la perte de l’intégralité du cache est acceptable.
• Redis — prend en charge la réplication, le Multi-AZ avec basculement automatique, le mode cluster pour le sharding, la persistance, le pub/sub, les ensembles triés, les transactions et le chiffrement en transit et au repos. Requis pour tout ce qui doit être durable ou qui nécessite des types de données complexes.

Deux modèles canoniques prédominent.

Magasin de sessions centralisé. Lorsqu’un ALB répartit le trafic sur des instances EC2 ou ECS sans état (stateless), le stockage de session local impose des sessions persistantes (sticky sessions), ce qui déséquilibre la charge et provoque des défaillances lors des réductions d’échelle (scale-in), des déploiements et des pannes d’AZ. L’externalisation des sessions vers Redis permet à n’importe quelle instance de traiter n’importe quelle requête, et les sessions survivent aux pannes d’hôte :

import redis, json
r = redis.Redis(host='sessions.abc123.ng.0001.use1.cache.amazonaws.com',
                port=6379, ssl=True)

def save_session(sid, data, ttl=1800):
    r.setex(f"sess:{sid}", ttl, json.dumps(data))

Déchargement en lecture pour les requêtes coûteuses — classements (ensembles triés Redis via ZADD/ZREVRANGE), recherches de catalogue, agrégations. Les stratégies de mise en cache doivent correspondre aux besoins de cohérence :

• Lazy loading (cache-aside) : l’application lit le cache ; en cas d’échec (miss), elle lit la base de données et remplit le cache avec un TTL. Simple, mais les échecs à froid (cold misses) sont pénalisants et les données peuvent être obsolètes.
• Write-through : l’application écrit dans le cache et dans la base de données au cours de la même opération. Le cache reste à jour, mais les écritures sont plus lentes et les données inutilisées occupent toujours de la mémoire.
• Write-back (write-behind) : les écritures sont d’abord effectuées dans le cache, puis vidées (flushed) de manière asynchrone vers la base de données. Écritures les plus rapides, mais une défaillance du cache entraîne une perte de données.

data = r.get(f"product:{sku}")
if data is None:
    data = db.query("SELECT * FROM products WHERE sku=%s", sku)
    r.setex(f"product:{sku}", 300, serialize(data))

S’appuyer sur une couche de cache sans stratégie d’invalidation — TTL, DEL explicite lors d’une mise à jour, ou write-through — produit des lectures de données obsolètes (stale reads). Le mode de défaillance est silencieux : l’application semble correcte jusqu’à ce que les utilisateurs remarquent une divergence. La mise en cache est aussi souvent le moyen le moins cher de faire évoluer les lectures au-delà de ce que les réplicas en lecture (read replicas) peuvent confortablement supporter et protège la base de données primaire lors des pics de trafic.

Contrairement à DAX, ElastiCache est agnostique du moteur — vous êtes propriétaire de la logique d’invalidation — c’est pourquoi DAX l’emporte en termes de simplicité opérationnelle lorsque la base de données sous-jacente est DynamoDB.

Migration : DMS et SCT

AWS Database Migration Service (DMS) réplique les données entre des moteurs homogènes (Oracle→Oracle, MySQL→Aurora MySQL) ou hétérogènes (Oracle→Aurora PostgreSQL, SQL Server→RDS MySQL, on-prem→DynamoDB). Une tâche DMS comporte trois phases :

1. Full load (chargement complet) — copie en masse des lignes existantes.
2. CDC (Change Data Capture) — suit le journal des transactions de la source et applique les changements en continu.
3. Full load + CDC — le modèle courant pour une interruption minimale : la source reste en ligne, DMS maintient la cible synchronisée, le basculement (cutover) est un simple changement de DNS.

aws dms create-replication-task \
  --replication-task-identifier ora-to-aurora \
  --source-endpoint-arn $SRC --target-endpoint-arn $TGT \
  --migration-type full-load-and-cdc \
  --table-mappings file://mappings.json \
  --replication-instance-arn $RI

DMS Serverless élimine le besoin de dimensionner et de gérer des instances de réplication — la capacité est provisionnée automatiquement en fonction de la charge de travail, ce qui convient aux CDC variables ou de longue durée. Les moteurs sources doivent avoir la journalisation supplémentaire (supplemental logging pour Oracle) ou la journalisation binaire au format ROW (MySQL) activée. Pour les initialisations de très grand volume, DMS s’intègre avec Snowball Edge pour les chargements hors ligne.

DMS déplace les données, pas le schéma. Pour les migrations hétérogènes, vous l’associez à l’AWS Schema Conversion Tool (SCT), qui convertit les procédures stockées, les vues, les déclencheurs (triggers), les séquences et les types spécifiques au dialecte — par exemple, Oracle PL/SQL en PostgreSQL PL/pgSQL, ou T-SQL en Aurora MySQL. SCT produit un rapport d’évaluation signalant les objets nécessitant une retouche manuelle (généralement 5 à 20 % pour les bases de code complexes). Lancer DMS seul pour une migration inter-moteurs est une erreur courante : bien que DMS puisse créer des tables cibles rudimentaires, il ne traduit pas correctement les procédures ou les types propriétaires. Pour les migrations homogènes, SCT n’est pas nécessaire — les outils natifs (mysqldump, pg_dump, RMAN) complétés par le CDC de DMS suffisent.

Le modèle complet pour une migration inter-moteurs :

1. SCT: convert schema, apply to target RDS/Aurora
2. DMS full-load task: bulk copy existing data
3. DMS CDC task: capture ongoing changes from source
4. Cutover: stop writes at source, wait for CDC lag = 0, redirect app

Sauvegardes et restauration à un instant T (Point-in-Time Recovery)

Les sauvegardes automatisées de RDS combinent des snapshots quotidiens avec des sauvegardes des journaux de transactions toutes les 5 minutes, permettant une restauration à un instant T (PITR) à la seconde près dans la fenêtre de rétention (1 à 35 jours, 7 par défaut). La restauration crée une nouvelle instance — vous ne pouvez pas restaurer sur place — les points de terminaison de l’application ou les CNAME doivent donc être mis à jour. Les snapshots manuels persistent au-delà de la période de rétention et survivent à la suppression de l’instance (sous réserve du paramètre de snapshot final), peuvent être copiés entre régions pour la reprise après sinistre (DR), et peuvent être partagés entre comptes.

Fast Snapshot Restore (FSR) pour les snapshots basés sur EBS élimine la pénalité de chargement différé (lazy-load), donnant aux volumes restaurés leurs performances maximales immédiatement — utile pour démarrer rapidement plusieurs environnements à partir d’un seul snapshot. Le clonage Aurora contourne complètement les snapshots pour les copies au sein d’une même région. Le PITR de DynamoDB est une fonctionnalité parallèle qui doit être activée par table et qui produit une nouvelle table lors de la restauration.

Bases de données spécialisées (Purpose-Built)

Choisir un moteur spécialisé lorsque les modèles d’accès l’exigent évite une réarchitecture coûteuse. Amazon Neptune est une base de données de graphes gérée prenant en charge Gremlin, openCypher et SPARQL — appropriée lorsque les requêtes parcourent des relations (réseaux de fraude, graphes sociaux, graphes de connaissances) où des jointures récursives dans un moteur relationnel seraient prohibitivement coûteuses. Amazon QLDB est un grand livre (ledger) immuable et vérifiable par cryptographie avec un journal en ajout seul (append-only), adapté aux systèmes d’enregistrement nécessitant un audit infalsifiable — provenance de la chaîne d’approvisionnement, transactions financières, registres administratifs. DynamoDB est le choix par défaut pour un accès clé-valeur ou document en quelques millisecondes à n’importe quelle échelle, en utilisant des modèles tels que la conception à table unique (single-table design), les clés de tri composites pour l’accès hiérarchique, et les GSI pour les chemins d’accès alternatifs. Forcer ces charges de travail dans RDS crée des contentions de verrous (écritures de grand livre), une complexité des requêtes (parcours de graphe), ou des plafonds de scalabilité (clé-valeur à haut débit) — chacun étant bien plus coûteux à corriger ultérieurement que de choisir correctement dès la conception.

Résumé des pièges

• Les réplicas en lecture pour la haute disponibilité. Asynchrones, pas de promotion automatique, le point de terminaison change lors de la promotion, perte des transactions en cours. Multi-AZ est la solution pour la haute disponibilité.
• Le Multi-AZ pour la mise à l’échelle en lecture. L’instance de secours n’est pas lisible dans une configuration RDS Multi-AZ standard. Utilisez des réplicas en lecture ou des réplicas Aurora.
• Production en Single-AZ. Aucune cible de basculement ; perte de disponibilité lors de tout événement d’AZ ou de redémarrage d’instance. Le Multi-AZ coûte environ le double pour un saut qualitatif en matière de disponibilité.
• Réplica dimensionné par défaut à l’identique du primaire. Les réplicas nécessitent souvent beaucoup moins de ressources ; dimensionnez-les en fonction de la charge de travail mesurée, sauf si le réplica est une cible de promotion.
• DynamoDB On-demand toujours moins cher. Le coût par requête est environ 6 à 7 fois plus élevé ; le mode provisionné + auto-scaling est plus avantageux pour les charges de travail stables.
• Global Tables pour des besoins mono-région. Double le coût et affaiblit la cohérence sans avantage, sauf si la proximité des utilisateurs multi-régions ou un plan de reprise d’activité (DR) est requis.
• Les bases secondaires d’une Aurora Global Database servent les écritures. Elles sont en lecture seule jusqu’à ce qu’un basculement géré les promeuve.
• Lambda → RDS sans RDS Proxy. Une tempête de connexions épuise max_connections ; les pools de connexions au sein de la fonction n’aident pas entre les environnements d’exécution concurrents.
• DMS seul pour une migration hétérogène. Déplace les données, mais pas le schéma. À associer avec SCT.
• Stockage RDS fixe sans autoscaling ni alarmes FreeStorageSpace. Panne latente — l’état storage-full rejette les écritures.
• Mise en cache sans stratégie d’invalidation. Désuétude silencieuse des données. Les TTL, le write-through ou l’invalidation explicite sont non négociables.
• Lectures fortement cohérentes via DAX ou des GSI. Ces deux chemins ne fournissent que des données à cohérence éventuelle.

← Distribution de contenu · Tous les domaines · Analytique →

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

Parcourir Amazon →