Amazon RDS & Bases de Données — Cheat Sheet Cloud Practitioner
Les bases de données AWS couvrent deux grandes familles à l’examen de certification AWS Cloud Practitioner CLF-C02 : les bases relationnelles gérées (RDS, Aurora) et les bases NoSQL/cache (DynamoDB, ElastiCache, DocumentDB…).
Vue d’ensemble — services de bases de données AWS
| Service | Type | Cas d’usage principal | Modèle de gestion |
| Amazon RDS | Relationnel (SQL) | Applications web, ERP, CRM, apps transactionnelles | Entièrement managé — pas d’accès SSH |
| Amazon Aurora | Relationnel (SQL) cloud-native | Apps haute performance, très haute disponibilité | Entièrement managé — propriétaire AWS |
| Amazon DynamoDB | NoSQL — clé-valeur / document | Apps mobile, gaming, IoT, sessions web, faible latence | Serverless — entièrement managé |
| Amazon ElastiCache | Cache en mémoire (Redis / Memcached) | Accélérer les lectures BDD, sessions, leaderboards | Entièrement managé |
| Amazon Redshift | Data warehouse (SQL analytique) | Analyses complexes sur de gros volumes de données | Entièrement managé — OLAP |
| Amazon DocumentDB | NoSQL document (compatible MongoDB) | Applications utilisant MongoDB — migration vers AWS | Entièrement managé |
| Amazon Neptune | Graphe | Réseaux sociaux, détection de fraude, graphes de connaissance | Entièrement managé |
1. Amazon RDS — Relational Database Service
RDS est un service de bases de données relationnelles entièrement managé. AWS s’occupe du provisionnement, des patches OS, des sauvegardes et de la haute disponibilité — vous vous concentrez sur vos données.
Moteurs de bases de données supportés
| Moteur | Notes pour l’examen |
| Amazon Aurora | Propriétaire AWS — performances supérieures, voir section dédiée |
| PostgreSQL | Open-source — compatible Aurora PostgreSQL |
| MySQL | Open-source — compatible Aurora MySQL |
| MariaDB | Fork de MySQL — open-source |
| Oracle | Base de données commerciale — licence BYOL ou incluse |
| Microsoft SQL Server | Base de données Microsoft — licence incluse ou BYOL |
| IBM DB2 | Ajouté récemment à la liste des moteurs supportés |
Fonctionnalités managées par AWS (vous n’avez pas à gérer)
| Fonctionnalité | Description |
| Provisionnement automatique | Déploiement de l’infrastructure serveur en quelques minutes |
| Patches OS et moteur | AWS applique automatiquement les correctifs de sécurité et de version |
| Sauvegardes automatiques (PITR) | Point-In-Time Recovery — restaurer à n’importe quel moment dans la période de rétention (1 à 35 jours) |
| Surveillance | Tableaux de bord CloudWatch intégrés — CPU, connexions, latence, I/O |
| Stockage automatique | Amazon EBS géré par AWS — chiffrement activable |
| Multi-AZ | Réplication automatique vers une AZ secondaire — failover automatique |
| Read Replicas | Copies de lecture scalables — jusqu’à 15 répliques |
| Pas d’accès SSH sur RDS : Contrairement à une instance EC2 avec une base de données auto-gérée, vous ne pouvez pas vous connecter en SSH à l’instance sous-jacente d’une base RDS. C’est AWS qui gère le serveur. Vous accédez uniquement à la base de données via le port standard du moteur (MySQL : 3306, PostgreSQL : 5432…). |
2. Read Replicas vs Multi-AZ — la distinction fondamentale
C’est le sujet le plus testé au CLF-C02 sur RDS. Les deux mécanismes semblent similaires mais ont des objectifs complètement différents.
| Critère | Read Replicas | Multi-AZ |
| Objectif principal | Performance — augmenter la capacité de lecture | Haute disponibilité — tolérance aux pannes |
| Rôle de la copie | Active — accessible en lecture par les applications | Passive — standby, jamais accessible en lecture normale |
| Type de réplication | Asynchrone — légère latence possible | Synchrone — données identiques en permanence |
| Failover automatique | Non — le basculement est manuel | Oui — AWS bascule automatiquement en cas de panne |
| Accès aux copies | Oui — les applications lisent dessus via un endpoint dédié | Non — la base standby n’est pas accessible tant que tout va bien |
| Nombre de copies | Jusqu’à 15 répliques de lecture | 1 base de secours dans une autre AZ |
| Portée géographique | Même région ou autre région (Cross-Region Read Replica) | Même région — autre AZ |
| Écritures | Uniquement sur la base principale — les RR sont lecture seule | Sur la principale — synchronisé en temps réel vers le standby |
| Cas d’usage typique | Distribuer la charge des rapports, analytics, dashboards | Garantir la continuité en cas de panne de l’AZ ou de l’instance |
| Mémo examen — Read Replica vs Multi-AZ : Si la question parle de performances de lecture, de distribuer la charge, de réduire la latence → Read Replica. Si la question parle de haute disponibilité, de continuité de service, de panne, de failover automatique → Multi-AZ. Les deux peuvent être combinés : une base Multi-AZ avec des Read Replicas dessus. |
Déploiement Multi-Régions
Les Read Replicas peuvent être créées dans des régions différentes (Cross-Region Read Replicas) pour deux objectifs complémentaires.
| Objectif | Description | Limitation |
| Réduction de latence | Les applications dans une région distante lisent depuis un réplica local — latence proche de zéro | Les écritures doivent toujours aller vers la base principale — pas de réplica d’écriture |
| Disaster Recovery inter-région | En cas de catastrophe régionale, promouvoir le réplica distant comme nouvelle base principale | Coût de transfert de données inter-régions pour la réplication |
3. Amazon Aurora — la base de données cloud-native AWS
Aurora est la base de données relationnelle propriétaire d’AWS, conçue spécifiquement pour le cloud. Elle est compatible MySQL et PostgreSQL mais avec une architecture fondamentalement différente.
| Propriété | Amazon RDS (MySQL/PostgreSQL) | Amazon Aurora |
| Performance | Référence | 5x plus rapide que MySQL RDS · 3x plus rapide que PostgreSQL RDS |
| Compatibilité | MySQL, PostgreSQL, Oracle, SQL Server, MariaDB, DB2 | MySQL et PostgreSQL uniquement (mais architecture propriétaire) |
| Architecture stockage | EBS attaché à l’instance | Stockage distribué sur 6 copies dans 3 AZ — séparé du calcul |
| Stockage | Provisionné manuellement (jusqu’à 64 TB sur gp3) | Auto-extensible par incréments de 10 Go — jusqu’à 128 To sans action manuelle |
| Réplication | Multi-AZ optionnel (1 standby) | 6 copies de données dans 3 AZ par défaut — intégré |
| Read Replicas | Jusqu’à 15 | Jusqu’à 15 Aurora Replicas — failover automatique parmi les replicas |
| Coût | Référence | Environ 20% plus cher que RDS — justifié par les performances |
| Sauvegardes | Automatiques — stockées dans S3 | Continues — stockées dans S3, restauration à la seconde |
| Failover | Multi-AZ : 1-2 min | Aurora : < 30 secondes — les replicas peuvent prendre le relais |
Aurora Serverless
Aurora Serverless est une configuration d’Aurora qui ajuste automatiquement la capacité de calcul selon la demande — parfait pour les charges imprévisibles.
| Propriété | Détail |
| Scaling | Automatique selon la charge — de 0 à des centaines d’unités de capacité (ACU) |
| Pause automatique | La base se met en veille si inactif — redémarre en quelques secondes sur la prochaine requête |
| Facturation | À la seconde selon les ACU consommées — pas de facturation pour l’instance en veille |
| Cas d’usage | Développement/test, charges imprévisibles ou intermittentes, nouvelles applications sans historique de charge |
| Limitations | Légèrement plus lent à démarrer après pause. Certaines fonctionnalités avancées non disponibles vs Aurora provisionné |
| Aurora vs RDS — quand choisir quoi : RDS = choix standard pour MySQL, PostgreSQL, Oracle, SQL Server, MariaDB, IBM DB2. Aurora = quand vous avez besoin de performances supérieures, d’une haute disponibilité native (6 copies dans 3 AZ), et que vous êtes sur MySQL ou PostgreSQL uniquement. Aurora Serverless = charges imprévisibles ou intermittentes, environnements dev/test où vous voulez payer uniquement quand la base est utilisée. |
4. Amazon ElastiCache — cache en mémoire
ElastiCache est un service de cache en mémoire managé. Il stocke les résultats de requêtes fréquentes en RAM pour les servir en microsecondes — sans interroger la base de données à chaque fois.
| Propriété | Redis (recommandé) | Memcached |
| Persistance | Oui — snapshots et AOF (Append Only File) | Non — données perdues au redémarrage |
| Structures de données | Avancées : listes, sets, hashes, sorted sets, streams | Simples : clé-valeur uniquement |
| Réplication | Oui — Multi-AZ avec failover automatique | Non — pas de réplication native |
| Clustering | Oui — cluster mode pour sharding horizontal | Oui — multithreading natif |
| Cas d’usage | Sessions, leaderboards, pub/sub, file d’attente, compteurs temps réel | Cache simple, haute performance, multithreaded |
| Recommendation AWS | Préféré pour la plupart des cas d’usage | Workloads nécessitant un pur cache multithreading |
Patterns d’utilisation d’ElastiCache
• Cache de lecture (Lazy Loading) : L’application vérifie d’abord le cache. Si la donnée est là (cache hit) → retour immédiat. Sinon (cache miss) → lecture BDD, stockage en cache, retour.
• Cache d’écriture (Write-Through) : Chaque écriture en BDD met aussi à jour le cache — cache toujours cohérent avec la BDD.
• Gestion des sessions utilisateurs : Stocker les sessions web en Redis au lieu de la BDD — performance drastiquement améliorée, scalable sur plusieurs EC2.
| Quand ElastiCache est la bonne réponse : Si la question mentionne une base de données surchargée par des requêtes répétitives, une latence de lecture trop élevée, ou le besoin de servir des milliers de requêtes identiques par seconde → ElastiCache. C’est toujours une couche devant la base de données, jamais un remplacement. |
5. Amazon DynamoDB — NoSQL serverless
DynamoDB est la base de données NoSQL serverless d’AWS. Pas de serveur à gérer, scaling automatique, latence en millisecondes à n’importe quelle échelle.
| Propriété | Détail |
| Type | NoSQL — clé-valeur et document (JSON) |
| Modèle de gestion | Serverless — pas de provisionnement de capacité requis (mode On-Demand) |
| Performance | Latence en millisecondes à l’échelle de milliards d’éléments |
| Scaling | Automatique — gère des milliers de requêtes par seconde sans intervention |
| Haute disponibilité | Réplication multi-AZ automatique — durabilité 99,999999999% |
| Schéma | Flexible — pas de schéma fixe (sauf la clé primaire) |
| Transactions | Supportées — ACID via DynamoDB Transactions |
| Cas d’usage | Mobile, gaming, IoT, sessions web, catalogue produits, profils utilisateurs, temps réel |
| DynamoDB Accelerator (DAX) | Cache en mémoire natif pour DynamoDB — latence microseconde (au lieu de ms) |
| DynamoDB Streams | Capture les changements en temps réel — déclenche Lambda pour event-driven architectures |
| RDS vs DynamoDB — quand choisir quoi : RDS = données structurées avec schéma fixe, relations entre tables, requêtes SQL complexes, applications transactionnelles classiques. DynamoDB = données non structurées ou semi-structurées, schéma variable, besoin de scalabilité massive et latence ultra-faible, pas de SQL complexe nécessaire. L’examen teste souvent ce choix : si la question mentionne SQL, relations, transactions → RDS. Si elle mentionne scalabilité massive, IoT, mobile, serverless, millions de requêtes → DynamoDB. |
6. Autres services de bases de données AWS
| Service | Type | Cas d’usage | À retenir pour l’examen |
| Amazon Redshift | Data Warehouse (OLAP) | Analyses complexes sur des téraoctets/pétaoctets de données | Pas pour le transactionnel (OLTP) — pour l’analytique uniquement. Basé sur PostgreSQL. |
| Amazon DocumentDB | NoSQL document (MongoDB-compatible) | Applications MongoDB existantes à migrer vers AWS | Compatible MongoDB — mais service propriétaire AWS, pas MongoDB réel |
| Amazon Neptune | Graphe | Réseaux sociaux, moteurs de recommandation, détection de fraude | La seule base de données graphe managée d’AWS |
| Amazon QLDB | Ledger (immuable) | Journal de transactions immuable et vérifiable — traçabilité bancaire | Données immuables avec historique complet et vérifiable cryptographiquement |
| Amazon Timestream | Séries temporelles | Données IoT, métriques, logs avec dimension temporelle | Optimisée pour les données horodatées — plus rapide et moins cher que RDS pour ce cas |
| AWS Database Migration Service (DMS) | Service de migration | Migrer des bases de données vers AWS avec interruption minimale | Supporte homogène (MySQL→RDS MySQL) et hétérogène (Oracle→Aurora) |
7. Scénarios CLF-C02 — bases de données
| Scénario examen | Bonne réponse | Pourquoi |
| Application web avec des requêtes SQL complexes et des transactions — base relationnelle | Amazon RDS (MySQL ou PostgreSQL) | RDS = base relationnelle SQL managée — standard pour les apps web |
| Même application avec des performances 5x supérieures nécessaires | Amazon Aurora | Aurora MySQL/PostgreSQL = performances nettement supérieures à RDS standard |
| Base de données RDS qui tombe en panne — reprise automatique sans perte de données | Multi-AZ activé sur RDS | Failover automatique vers le standby en cas de panne — sans intervention manuelle |
| Rapports analytiques lourds qui ralentissent la base de production | Read Replica dédiée aux lectures analytics | Décharge la base principale — le réplica absorbe les requêtes de lecture lourdes |
| Application avec charge imprévisible — base de données sans serveur | Aurora Serverless | Scale automatique, facturation à la seconde, pause si inactif |
| Application mobile avec des millions d’utilisateurs — latence < 10ms, schéma variable | Amazon DynamoDB | NoSQL serverless — scale automatique, latence ms, pas de schéma fixe |
| Les requêtes répétitives surchargent RDS — améliorer les performances sans modifier l’architecture | Amazon ElastiCache (Redis) | Cache en mémoire devant RDS — les requêtes fréquentes ne touchent plus la BDD |
| Analyse de données sur des années d’historique — requêtes SQL analytiques sur pétaoctets | Amazon Redshift | Data warehouse OLAP — optimisé pour l’analytique, pas pour le transactionnel |
| Migration d’une base Oracle on-premises vers Amazon Aurora PostgreSQL | AWS Database Migration Service (DMS) | DMS gère les migrations hétérogènes avec interruption minimale |
| Application NoSQL utilisant MongoDB — migrer vers AWS sans réécrire l’application | Amazon DocumentDB | Compatible MongoDB API — migration sans réécriture du code applicatif |
| Registre de transactions bancaires — chaque opération doit être immuable et vérifiable | Amazon QLDB | Ledger immuable avec historique cryptographiquement vérifiable |
| Capteurs IoT envoyant des métriques horodatées en continu | Amazon Timestream | Optimisée séries temporelles — stockage et requêtes bien plus efficaces que RDS pour ce cas |
| Connecter plusieurs instances EC2 à la même base de données | Amazon RDS — accessible via endpoint depuis toutes les instances du VPC | RDS expose un endpoint réseau — accessible depuis toutes les instances autorisées via Security Group |
| Quelle fonctionnalité protège contre la perte de données en cas de panne AZ ? | Multi-AZ (pas Read Replica) | Read Replica = performances. Multi-AZ = haute disponibilité et protection contre les pannes. |
| Les 3 règles d’or bases de données au CLF-C02 : (1) Read Replica = plus de performance en lecture (asynchrone, accessible). Multi-AZ = plus de disponibilité (synchrone, standby passif). (2) RDS = SQL relationnel classique. Aurora = SQL haute performance cloud-native. DynamoDB = NoSQL serverless ultra-scalable. ElastiCache = cache en mémoire devant une BDD. (3) Redshift = OLAP analytique sur gros volumes. DocumentDB = MongoDB. Neptune = graphe. Timestream = séries temporelles. QLDB = immuable et vérifiable. |
| Préparez votre certification AWS Cloud Practitioner avec notre Cours complet CLF-C02 en français · Vidéos · Quiz · Cas pratiques · Accès à vie Accéder au cours CLF-C02 sur LeCloudFacile.com |
Sources et références
AWS — Amazon RDS Documentation — moteurs, Multi-AZ, Read Replicas, sauvegardes
AWS — Amazon Aurora Documentation — architecture, Serverless, Global Database
AWS — Amazon DynamoDB Documentation — NoSQL serverless, DAX, Streams
AWS — Amazon ElastiCache Documentation — Redis vs Memcached
AWS — Amazon Redshift Documentation — data warehouse OLAP
