Choisir la bonne base managée AWS et comprendre RDS, Aurora, DynamoDB et ElastiCache !
AWS
Publié le
Karl Certa Admin systèmes & réseaux5 ans dans l'IT, passé par le support puis l'admin sys, aujourd'hui Ops. J'apprends le cloud et je pose tout au propre ici. Focus sur l'IaC & le cloud AWS SAA, prochaine étape Kubernetes LinkedIn karlcerta.fr GitHub Karl Certa
Les bases de données AWS sont des services managés (relationnels, NoSQL, cache, analytique) : AWS s’occupe du matériel, des correctifs, des sauvegardes et de la bascule, vous gardez la main sur le schéma et les requêtes.
🧭 Choisir le bon service
Le choix part de la forme des données et du type de requêtes à servir.
Reprise d’une base MySQL, PostgreSQL, Oracle ou SQL Server existante
🚀 Relationnel compatible MySQL / PostgreSQL, forte charge en lecture
Aurora
Nouveau projet relationnel conçu pour AWS
🔑 Clé-valeur / NoSQL (non relationnel) à grande échelle
DynamoDB
Paniers, profils, sessions, compteurs
⚡ Cache en mémoire
ElastiCache
Cache devant une base, sessions, classements
📄 Document compatible MongoDB
DocumentDB
Migrer une appli MongoDB sans changer le code ni les drivers
🧱 Wide-column compatible Cassandra
Keyspaces
Migrer une appli qui parle CQL (Cassandra Query Language)
🕸️ Graphe
Neptune
Détection de fraude, recommandations, graphes de connaissances
📊 Data warehouse (analytique OLAP)
Redshift
Agrégations sur des volumes de l’ordre du pétaoctet
🔍 Recherche full-text, analyse de logs
OpenSearch Service
Moteur de recherche applicatif, exploration de logs
⏱️ Séries temporelles
Timestream for InfluxDB
Métriques, capteurs, télémétrie
ACID (Atomicité, Cohérence, Isolation, Durabilité) : une transaction s’applique entièrement ou pas du tout, c’est ce qu’on attend d’une base de commandes ou de facturation.
OLTP (Online Transaction Processing) : beaucoup de petites lectures/écritures, le terrain de RDS, Aurora et DynamoDB. OLAP (Online Analytical Processing) : peu de requêtes mais très lourdes, le rôle de Redshift. Lancer des rapports OLAP sur la base OLTP de production la ralentit pour tous les utilisateurs.
Timestream for LiveAnalytics est fermé aux nouveaux clients depuis le 20 juin 2025 : AWS oriente les nouveaux projets vers Timestream for InfluxDB.
🐬 RDS : Relational Database Service
📌 Élément
📊 Valeur / limite
🧩 Moteurs supportés
IBM Db2, MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL
📖 Read Replicas
15 par instance source (quota par défaut, Oracle : 5 recommandés pour limiter le retard)
💸 Réplication dans la même région
Transfert de données non facturé, payant en cross-region
🧮 Auto scaling des Read Replicas
Non supporté : les replicas se créent et se suppriment à la main
Multi-AZ vs Read Replica
Une AZ (Availability Zone) est une zone de disponibilité isolée des pannes des autres zones de la même région. RDS propose deux déploiements Multi-AZ et les Read Replicas, qui ne répondent pas au même besoin.
📌 Critère
🔁 Multi-AZ instance
👥 Multi-AZ DB cluster
📖 Read Replica
🎯 Rôle
Haute disponibilité
Haute disponibilité et lecture
Scalabilité en lecture, reprise après sinistre
🔄 Réplication
Synchrone
Semi-synchrone (acquittée par au moins 1 reader)
Asynchrone
👀 Lisible
Non, standby passif
Oui, 2 readers
Oui, en lecture seule
🗺️ Portée
Standby dans une autre AZ
Writer + 2 readers sur 3 AZ
Même région ou autre région
⚙️ Bascule
Automatique, le DNS (Domain Name System) pointe vers le standby, en général 60 à 120 s
Automatique vers le reader le plus à jour
Manuelle : promotion en instance autonome
🧩 Moteurs
Tous (SQL Server via Database Mirroring ou Always On)
MySQL et PostgreSQL uniquement
Tous (Db2 et Oracle proposent aussi des replicas non lisibles pour la reprise après sinistre)
📝 Côté appli
Même endpoint, connexions à rouvrir après bascule
Lectures envoyées vers les readers
Endpoint dédié à cibler pour les lectures
Sauvegardes RDS
📌 Type
⚙️ Fonctionnement
📊 Conservation
🤖 Sauvegardes automatiques
Snapshot du volume pendant la fenêtre de sauvegarde, logs de transactions envoyés toutes les 5 min
0 à 35 jours (0 = désactivées)
🕐 Rétention par défaut
7 jours via la console, 1 jour via l’AWS CLI (Command Line Interface) ou l’API (Application Programming Interface)
Modifiable ensuite
⏪ PITR (Point-In-Time Recovery)
Restauration à n’importe quel instant de la période de rétention
Dernier point restaurable : environ 5 min
📸 Snapshot manuel
Déclenché à la demande, incrémental après le premier
Jusqu’à suppression, 100 par région par défaut
Une restauration (PITR ou snapshot) crée toujours une nouvelle instance : l’instance source n’est pas écrasée et l’application doit être repointée.
Supprimer une instance sans cocher Retain automated backups efface ses sauvegardes automatiques. Les snapshots manuels, eux, sont conservés.
Passer la rétention de 0 à une valeur non nulle (ou l’inverse) provoque une coupure de l’instance : à planifier.
RDS Proxy
RDS Proxy mutualise les connexions dans un pool devant la base (idéal avec Lambda ou un autoscaling agressif), peut imposer l’authentification IAM (Identity and Access Management) aux clients et n’est jamais accessible publiquement.
🌟 Aurora
Aurora est le moteur AWS compatible MySQL et PostgreSQL. Sa différence clé avec RDS : le calcul (instances) et le stockage (volume de cluster partagé) sont séparés.
📌 Critère
🐬 RDS
🌟 Aurora
💾 Stockage
Chaque instance a son volume, chaque replica reçoit une copie
Volume de cluster partagé, 6 copies sur 3 AZ, taille ajustée automatiquement
📖 Replicas de lecture
15, réplication native du moteur
15 Aurora Replicas branchées sur le même volume
🔁 Bascule
Multi-AZ instance : 60 à 120 s
Promotion d’un replica : moins de 60 s, souvent moins de 30 s
🔗 Endpoints
Un endpoint par instance
Cluster (writer), reader (répartit entre replicas), custom, instance
⏪ Rétention des sauvegardes
0 à 35 jours, désactivables
1 à 35 jours, non désactivables
🧬 Copie d’environnement
Restauration de snapshot
Clonage copy-on-write : seules les données modifiées sont copiées
Serverless et Global Database
📌 Fonction
⚙️ Fonctionnement
📊 Limites
☁️ Aurora Serverless v2
Capacité ajustée en continu par pas de 0,5 ACU (Aurora Capacity Unit, environ 2 GiB de mémoire avec processeur et réseau)
0 à 256 ACU selon la version, 0 = pause automatique
🌍 Global Database
1 région primaire en écriture, régions secondaires en lecture seule, réplication par la couche stockage
Jusqu’à 10 régions secondaires, 16 replicas par cluster secondaire, retard typique sous la seconde
🔀 Switchover / failover
Switchover : changement de région planifié sans perte de données. Failover : reprise après panne régionale
Endpoint writer global qui suit la région primaire
✍️ Write forwarding
Les clusters secondaires transmettent les écritures au primaire
Option à activer
Aurora Serverless v1 est un produit déprécié, à l’architecture différente de la v2 décrite ici.
🔑 DynamoDB
DynamoDB est une base NoSQL clé-valeur et document entièrement managée : pas d’instance à dimensionner, on crée des tables et on choisit un mode de capacité.
📌 Élément
📊 Valeur / limite
📦 Taille max d’un item
400 KB, noms d’attributs compris
🗂️ Index secondaires
5 LSI (Local Secondary Index) et 20 GSI (Global Secondary Index) par table, quotas par défaut
📖 1 RCU (Read Capacity Unit)
1 lecture fortement cohérente/s ou 2 lectures à cohérence éventuelle/s, item jusqu’à 4 KB
✏️ 1 WCU (Write Capacity Unit)
1 écriture/s, item jusqu’à 1 KB
💳 Transactions
Coût doublé : 2 RCU ou 2 WCU par opération
📄 Query / Scan
1 MB de résultat max par appel, pagination au-delà
Les unités s’arrondissent au supérieur : un item de 3 KB lu en cohérence forte consomme 1 RCU, un item de 5 KB en consomme 2. Les lectures sont à cohérence éventuelle par défaut, ce qui divise leur coût par deux.
Modes de capacité
📌 Critère
⚡ On-demand
📐 Provisioned
💳 Facturation
À la requête
À l’heure, sur la capacité provisionnée même non consommée
📈 Scaling
Automatique, rien à planifier
RCU/WCU déclarées, auto scaling optionnel (cible recommandée : 70 %)
🎯 Usage
Mode par défaut et recommandé, trafic imprévisible
Charge stable et prévisible, coût maîtrisé
🔄 Changer de mode
Vers provisioned : à tout moment
Vers on-demand : 4 fois max par 24 h glissantes
Fonctions clés
📌 Fonction
⚙️ Rôle
📊 À retenir
⚡ DAX (DynamoDB Accelerator)
Cache en mémoire compatible avec l’API DynamoDB
Latence en microsecondes, TTL (Time To Live) par défaut 5 min, 1 nœud primaire + 0 à 10 replicas, lectures fortement cohérentes jamais mises en cache
📜 Streams
Journal des modifications d’items, ou CDC (Change Data Capture), consommable par Lambda
Rétention 24 h, chaque modification apparaît une fois et dans l’ordre pour un même item
🌍 Global Tables
Réplication multi-région, chaque réplique accepte lectures et écritures
MREC (Multi-Region Eventual Consistency, défaut) : asynchrone, en général sous la seconde, « last writer wins ». MRSC (Multi-Region Strong Consistency) : synchrone, exactement 3 régions
⏳ TTL
Suppression des items expirés, attribut Number en epoch secondes
Supprimés en général sous quelques jours, sans consommer de WCU
⏪ PITR
Sauvegarde continue à activer, restauration à la seconde
Fenêtre de 1 à 35 jours, restauration dans une nouvelle table
💾 Backup on-demand
Sauvegarde complète déclenchée à la main
Conservée jusqu’à suppression explicite
Un item expiré reste visible en lecture tant que TTL ne l’a pas supprimé : filtrer sur l’attribut TTL dans les Query et Scan.
En mode MREC, les Streams sont activés d’office sur les répliques pour assurer la réplication. MRSC offre un RPO (Recovery Point Objective, perte de données maximale) de zéro, mais ne supporte ni TTL ni transactions.
Syspirit 