🐘 AWS RDS (Relational Database Service)

11.2. Comparaison Coût/Performance : RDS vs Aurora

Les modèles de facturation sont fondamentalement différents, surtout sur le Stockage/I/O.

Analyse (Coût / Performance)

• Workload (Faible I/O) (ex: Blog, App Dev/Test) :
  • RDS (gp3) (Standard) est (généralement) moins cher (car les I/O sont "gratuits" (inclus)).
• Workload (Haut I/O - Écriture) (ex: API (Prod), OLTP) :
  • (RDS) Vous auriez besoin de RDS (io2) (ex: 30 000 IOPS Provisionnés) = Extrêmement cher.
  • (Aurora) Vous payez (uniquement) les I/O ($/Million) que vous consommez (Pay-per-use).
  • (Résultat) : Aurora (PaaS) est (souvent) moins cher (et plus performant) que RDS (io2) (IaaS) (pour les hautes performances).

11.3. Politiques de Réduction des Coûts (Opérationnel)

1. Arrêter les Instances (Dev/Test)

(Action) : Arrêter (StopDBInstance) les instances (Dev/Test/Staging) non-utilisées (ex: la nuit, le weekend).

• (Automatisation) : (via Script Lambda + EventBridge Scheduler (Cron)).
• (Économie) : Vous stoppez la facturation du Pilier 1 (Instance $/Heure) (le plus cher).
• (Attention) : Vous continuez (toujours) de payer le Pilier 2 (Stockage $/GB/Mois) (le disque (EBS) persiste).

2. Choisir le Bon Stockage (gp3 vs io1/io2)

(Action) : Ne jamais provisionner (sur-provisionner) io1/io2 (cher) "au cas où".

• (Bonne Pratique) : Démarrer (toujours) avec gp3 (Standard).
• (Monitorer) : Surveiller (CloudWatch (7.1)) Read/WriteLatency et DiskQueueDepth.
• (Si (et seulement si) gp3 (scalé au max (16k IOPS)) est (toujours) le goulot) -> Migrer vers io2.

3. Ajuster la Rétention des Backups

(Action) : Modifier la "Backup Retention Period" (Rétention des Backups Automatiques (PITR) (4.5)).

• (Prod) : Garder 7, 14, ou 35 jours (requis pour PITR).
• (Dev/Test) : Réduire la Rétention (ex: 1 jour). (Réduit les coûts du Pilier 4 (Stockage Backup)).
• (Si 0 jour (désactivé) -> Vous perdez le PITR (4.5) (et (MySQL) cassez les Read Replicas (4.3))).

4. "Right-Sizing" (Ajuster la Taille)

(Action) : Utiliser (CloudWatch (7.1) / Performance Insights (7.3)) pour analyser l'utilisation (CPUUtilization, FreeableMemory) sur 30 jours.

• (Sur-provisionné) : Si le CPU (Avg) est à 5% (sur 1 mois) sur une db.r6g.xlarge -> (Action) Scaler (Down) (Verticalement) vers db.r6g.large (50% moins cher).
• (Scaling Lecture (8.2)) : (Plutôt que de Scaler (Up) le Master (cher)) -> (Action) Ajouter une Read Replica (moins chère) pour décharger les SELECT (BI).

11.4. Reserved Instances (RI) & Savings Plans (SP)

Ce sont les modèles d'engagement (1 an ou 3 ans) pour les workloads (charges) stables (Production) (qui tournent 24/7).

(Gain) : Offre une réduction significative (ex: -40% à -60%) (sur le Pilier 1 (Instance $/Heure)) (par rapport au prix On-Demand (9.1)).

RDS Reserved Instances (RI) (Modèle "Legacy")

• Engagement (Rigide) : Vous réservez (ex:) 1x db.r6g.large (Famille) + PostgreSQL (Moteur) + eu-west-3 (Région) + Multi-AZ (Déploiement) ... (pendant 3 ans).
• (Avantage) : Offre (parfois) la réduction maximale.
• (Inconvénient) : Zéro flexibilité. (Si (après 1 an) vous migrez de Postgres -> Aurora, ou Paris -> Francfort, vous perdez la réduction (vous payez la RI "à vide")).

Savings Plans (SP) (Modèle Moderne)

(Recommandé) Plus flexible. Vous ne réservez pas une "instance", vous vous engagez (pendant 1/3 ans) sur un montant ($) (ex: "Je m'engage à dépenser $5.00 / heure en Compute").

• Compute Savings Plan : (Flexibilité Totale) S'applique (automatiquement) à EC2 (n'importe quelle famille/région), Fargate, ET Lambda.
• EC2 Instance Savings Plan : (Similaire RI) (Rigide) S'applique (uniquement) à 1 Famille/Région (ex: db.r6g à eu-west-3) (en échange d'une réduction (légèrement) supérieure).

11.5. Aurora Serverless v2 (Pay-per-use)

C'est le modèle de facturation (spécifique à Aurora (3.3)) conçu pour les workloads (charges) variables, imprévisibles, ou intermittents.

Facturation (Pay-per-use)

Vous n'êtes pas facturé ($/Heure) pour une "Instance" (ex: .large). Vous êtes facturé ($/ACU-Heure) (à la seconde) pour la Capacité (ACU) (CPU/RAM) que vous consommez (utilisez) réellement.

Cas d'Usage (Optimisation Coût)

(Scénario) : Instance Dev/Test (utilisée 8h/jour (Semaine), 0h/jour (Weekend)).

(RDS Standard db.r6g.large Provisionné 24/7) :

• Coût (730h/mois) : ~ $73.58 / mois (Payé 24/7, même si idle).

(Aurora Serverless v2 (Min 0.5 ACU)) :

• (Usage Actif) : 8h/j * 22j/mois * (ex: 4 ACU (Avg)) = 704 ACU-Heures
• (Idle / Nuit/WE) : 550h/mois * 0.5 ACU (Min) = 275 ACU-Heures
• (Stockage/IO (Aurora)) : ... (Coût similaire/supérieur)
• (Résultat) : Le coût "Compute" (Instance) est (drastiquement) plus bas (car il "scale down" (presque) à zéro (0.5 ACU) quand inutilisé).

(Anti-Pattern) : N'utilisez pas Serverless v2 (PPU) pour une BDD (Prod) qui tourne (en baseline) à 80% CPU 24/7. (Une instance Provisionnée (Standard) + Reserved Instance (RI) (11.4) sera (beaucoup) moins chère).

10.2. Import de Données (Bulk / Dump)

Méthodes (hors-DMS) pour l'import (initial) (Bulk Load) de données (ex: migration "offline" (avec downtime) ou initialisation d'un environnement de Dev).

1. Outils Natifs (pg_dump / mysqldump)

C'est la méthode "classique" (Client -> Serveur).

(Piège) : Vous ne pouvez pas (SSH) vous connecter à l'hôte RDS (1.1). Vous devez exécuter l'outil (pg_restore) (client) depuis une instance EC2 (Bastion/Admin) (dans le même VPC) qui, elle, a accès (Réseau/SG) à l'Endpoint RDS.

Exemple (PostgreSQL - pg_restore) :

                    # (Sur l'EC2 "Bastion")

                    # 1. (On-Prem) Dump (Structure + Données)
                    $ pg_dump -U admin -h 192.168.1.10 -Fc -f backup.dump ma_bdd

                    # 2. (Bastion) Copier 'backup.dump' (ex: via S3) sur l'EC2
                    $ aws s3 cp s3://.../backup.dump .

                    # 3. (Bastion) Restaurer (Restore) vers l'Endpoint RDS
                    $ pg_restore -v -j 8 -U postgres_admin \
                    -h mon-db.cabcdef123.eu-west-3.rds.amazonaws.com \
                    -d ma_bdd_rds \
                    backup.dump
                

2. Import (Natif) depuis S3

Méthode (PaaS) beaucoup plus rapide (performante) (car "Server-Side") pour charger (en masse) des données (.csv, .txt) (stockées sur S3) directement dans RDS (sans passer par une EC2 "goulot").

(PostgreSQL) (Extension aws_s3) :

                    -- (Nécessite IAM Role (attaché à RDS) (pour 's3:GetObject'))
                    -- (Nécessite 'CREATE EXTENSION aws_s3;')

                    -- (SQL) Lancer l'import (depuis S3)
                    SELECT aws_s3.table_import_from_s3(
                    'ma_table_users', 
                    '', 
                    '(FORMAT CSV, HEADER)',
                    'mon-bucket-import', 
                    'imports/users.csv', 
                    'eu-west-3'
                    );
                

(MySQL / Aurora) (Commande LOAD DATA) :

                    -- (Nécessite IAM Role (attaché à RDS) (pour 's3:GetObject'))

                    LOAD DATA FROM S3 's3://mon-bucket-import/imports/users.csv'
                    INTO TABLE ma_table_users
                    FIELDS TERMINATED BY ','
                    LINES TERMINATED BY '\n'
                    IGNORE 1 ROWS;
                

10.3. Migration (Upgrade) de RDS (Standard) vers Aurora

C'est le "chemin de migration" (recommandé par AWS) pour (facilement) convertir une instance RDS (Standard) (Postgres/MySQL) existante vers Amazon Aurora (plus performant (3.3), meilleur HA (4.4)).

Drop-in Compatible (Compatibilité)

Puisque Aurora (3.3) est 100% compatible (filaire) (wire-compatible) avec Postgres/MySQL, l'application (ex: Django) ne sait pas (et n'a pas besoin de savoir) qu'elle parle à Aurora (vs RDS Standard).

La migration (côté App) consiste (uniquement) à changer l'Endpoint (DNS) (HOST) (dans settings.py (5.4)) (du vieil Endpoint RDS vers le nouvel Endpoint Cluster Aurora).

Chemin de Migration (Facile - via "Read Replica")

Méthode (la plus simple) pour migrer (avec downtime minime) (ex: MySQL -> Aurora MySQL).

1. (Jour 1) (Instance RDS (MySQL) (Master) tourne (en Prod)).
2. (Jour 1) (Console RDS) Clic Droit (sur le Master RDS) -> "Create Aurora read replica".
3. (AWS) (En arrière-plan) :
   • Crée un Nouveau Cluster Aurora (vide).
   • Prend un Snapshot (interne) du Master (RDS).
   • Charge (Restore) ce Snapshot dans le Cluster Aurora.
   • Établit une Réplication (Binlog) (Asynchrone) (Source: RDS Master -> Cible: Aurora Cluster).
4. (Jour 1 -> Jour 2) (Attente) Le Cluster Aurora (Replica) "rattrape" (catches up) le Master (RDS). (Surveiller ReplicaLag (CloudWatch) -> 0).
5. (Jour 2 - 02:00 UTC) (Fenêtre de Downtime) :
   • (1) Arrêter l'Application (EC2/Lambda) (Stop Écritures).
   • (2) (Attendre ReplicaLag = 0).
   • (3) (Console RDS) Clic Droit (sur l'Aurora Replica) -> "Promote" (Promouvoir).
   • (4) (Flux) AWS "casse" la réplication. L'Aurora Replica devient un Cluster Master (R/W) indépendant.
   • (5) Changer le settings.py (App) (pour viser le nouvel Endpoint (Cluster) Aurora).
   • (6) Démarrer l'Application.
6. (Jour 2 - 02:05 UTC) (Downtime: 5 min) L'application tourne sur Aurora. (Vous pouvez (ensuite) supprimer l'ancien Master RDS).

9.2. Backups, Restore & Clonage

Point-In-Time Restore (PITR)

(La Sauvegarde la plus importante) (Activée via "Automated Backups"). Combine 1 Snapshot (quotidien) + Logs de Transaction (continus, 5 min).

Permet de restaurer (vers une NOUVELLE instance) la BDD à n'importe quelle seconde (ex: Mardi 14:32:05) (juste avant une erreur DELETE (14:32:10)). (voir 4.5)

Snapshot Copy (Cross-Region)

C'est l'action (manuelle ou automatisée (via AWS Backup)) de Copier un Snapshot (ex: snap-prod) de votre Région (ex: Paris (eu-west-3)) vers une autre Région (ex: Francfort (eu-central-1)).

(Cas d'Usage) : Disaster Recovery (DR). Si toute la Région "Paris" tombe (panne majeure), vous pouvez Restaurer (Restore) le Snapshot (copié) à "Francfort" (et redémarrer l'App là-bas).

(Chiffrement) : Lors de la "Copie", vous pouvez (re)chiffrer le Snapshot (ex: avec une Clé KMS (de la Région Francfort)).

Cloner un Cluster Aurora (Fast Clone)

C'est une fonctionnalité (spécifique à Aurora (3.3)) extrêmement rapide (quelques minutes) (pour créer un environnement de Test/Dev).

(Flux) : "Cloner" le Cluster Prod (10 TB) -> Clone-Dev.

(Technologie) : Copy-on-Write (CoW). Aurora (grâce à son stockage partagé (4.4)) ne copie pas les 10 TB (ce qui prendrait des heures). Il crée (instantanément) un "pointeur" (métadonnée) (Clone-Dev) qui lit les (mêmes) données que Prod. (Il ne "copie" (écrit) que les blocs qui sont modifiés (UPDATE) par l'équipe Dev).

9.3. Automatisation DevOps (Infrastructure as Code - IaC)

(Bonne Pratique n°1) : Ne jamais créer (cliquer) une BDD (Prod) manuellement (via la Console). Toujours la définir (provisionner) via du Code (IaC) (pour la Reproductibilité, l'Audit (Git), et l'Automatisation).

Le Piège (IaC) : Le "Master Password" (Secret)

(Anti-Pattern) : Ne jamais "hardcoder" (écrire en dur) le mot de passe (master_password = "Password123!") dans votre code Terraform/CDK (qui est dans Git).

(Bonne Pratique) :

1. (IaC) 1. Créer (via IaC) un Secret (aws_secretsmanager_secret) (vide) (ou (Terraform) générer (random_password) et stocker).
2. (IaC) 2. Créer l'Instance RDS (aws_db_instance) en (passant) (référençant) l'ARN du Secret (manage_master_user_password=true, master_user_secret_arn=...).
3. (Résultat) : RDS (service) (via IAM) va générer (lui-même) un mot de passe (complexe) et le stocker (automatiquement) (écrire) dans Secrets Manager. (Le mot de passe n'apparaît jamais (en clair) dans le .tfstate ou le code).

9.4. Intégration CI/CD (Migrations de Schéma)

L'IaC (9.3) gère l'Infrastructure (Le "Serveur" RDS). La CI/CD (DevOps) gère le Code Applicatif (Django/Rails).

(Le Piège) : Comment (automatiser) la Migration de Schéma (BDD) (ex: ALTER TABLE users ADD COLUMN phone_number VARCHAR(20);) lors d'un déploiement (Blue/Green) ?

Outils de Migration (Alembic, Flyway...)

Vous (Développeur) n'écrivez jamais de ALTER TABLE (SQL) "à la main" (en Prod). Vous utilisez un outil de migration (versionné) :

• Python (Django/Flask) : Alembic (SQLAlchemy) (ou django manage.py migrate).
• Java (Spring Boot) : Flyway (SQL) ou Liquibase (XML/SQL).
• Node.js (Sequelize) : Sequelize-CLI.

(Ces outils "versionnent" (v1.sql, v2.sql...) les changements (schéma) et gèrent (via une table _migrations) "quels" changements ont (déjà) été appliqués (ou non)).

Exemple (Pipeline CI/CD) (ex: GitHub Actions, CodePipeline)

                    (Push (Git) -> 'main')
                    |
                    (1. CI: Build & Test)
                    |
                    (2. Deploy: AWS CodeDeploy (Blue/Green))
                    |
                    v
                    (Phase "BeforeAllowTraffic" (Avant de basculer le trafic))
                    |
                    v
                    [ 🔥 Tâche (Lambda / CodeBuild / EC2) ]
                    (
                    - Se connecte à l'Endpoint RDS (Master)
                    - Exécute l'outil de migration :
                    - "flyway:migrate" (ou "alembic upgrade head")
                    )
                    |
                    (Phase "AllowTraffic" (Bascule))
                    |
                    v
                    (Trafic (ALB) -> (Nouvelle Flotte EC2 (v2)) (qui utilise le schéma (v2)))
                

Déploiements Blue/Green (RDS)

RDS (Postgres/MySQL/Aurora) (récemment) supporte (nativement) les Déploiements Blue/Green (similaires à CodeDeploy (10.4)) pour les mises à jour (Majeures/Mineures) (9.1) ou les changements de Schéma (riskys).

• (RDS) Crée un "Clone" (Green) (Standby logique) de votre BDD (Blue) (via Réplication).
• (Vous) Appliquez (testez) vos migrations (DDL) (ex: ALTER TABLE) (riskys) uniquement sur Green (Blue (Prod) tourne toujours).
• (Vous) (Si OK) Clic "Switchover" -> RDS (bascule le DNS) (Prod -> Green) (Downtime < 1 min).

8.2. Scalabilité Horizontale (Scale-Out) (Lecture)

C'est l'action d'ajouter (horizontalement) plus d'instances (copies) (au lieu de "grossir" (verticalement) 1 instance).

(Important) : C'est une scalabilité (presque) exclusivement pour la LECTURE (SELECT). (Le "Master" (Écriture) reste 1 goulot unique).

1. Read Replicas (Réplicas en Lecture) (RDS Standard)

C'est la méthode de scaling (manuelle) pour PostgreSQL, MySQL, MariaDB.

• Action : (Console) Clic "Create Read Replica" (sur le Master).
• Réplication : ASYNCHRONE (via Binlog (MySQL) / WAL (Postgres)).
• (Piège) : "Replication Lag" (Retard). Les données (SELECT) lues sur la Read Replica (RR) peuvent être (légèrement) obsolètes (ex: 50ms de retard) par rapport au Master (Écriture).
• Usage : L'Application (Code) doit être "consciente" :
  • Écritures (INSERT, UPDATE) -> Endpoint Master.
  • Lectures (SELECT) (non-critiques, BI, Analytics) -> Endpoint Read Replica.

2. Aurora Reader Cluster (Aurora)

C'est la méthode (supérieure) de scaling pour Amazon Aurora.

• Action : "Add Reader" (Ajouter un lecteur) (jusqu'à 15 "Readers").
• Réplication : Quasi-Instantanée (ms). Les "Readers" et le "Writer" partagent le même Volume de Stockage (distribué) (4.4). (Pas de "Replication Lag" (disque)).
• Usage (Automatique) : Aurora fournit 1 Endpoint (DNS) "Reader" (...-ro-...rds.amazonaws.com).
  • (L'Application (ex: BI) vise cet unique Endpoint "Reader").
  • (Aurora) (DNS Round-Robin) Load Balance (répartit) (automatiquement) les connexions (SELECT) sur tous les "Readers" (RR1, RR2, RR3...) disponibles.

8.3. Aurora Serverless v2 (Scalabilité "Micro-Second")

C'est un mode de déploiement (pour Aurora (3.3)) qui rend la Scalabilité Verticale (8.1) (CPU/RAM) instantanée, granulaire, et automatique.

Architecture (Sans Capacité Fixe)

Vous ne provisionnez pas une "Instance" (db.r6g.large). Vous provisionnez une Plage (Range) de "Capacité" (ACU = Aurora Capacity Unit ≈ 2GB RAM).

Exemple (Configuration) :

• Min ACU: 0.5 (1GB RAM)
• Max ACU: 32 (64GB RAM)

Flux (Automatique, "Micro-second" scaling)

1. (Nuit, 03:00) (Idle) L'application (Dev/Test) ne reçoit aucune requête.
   • (Aurora) Scale Down (Automatique) à 0.5 ACU (Coût minimum).
2. (Matin, 09:01:00) (Pic) 500 utilisateurs (Django) se connectent. La charge (AAS) (7.3) monte.
   • (Aurora) Scale Up (Instantané) (ex: 0.5 -> 8 ACU) (sans downtime, sans reboot) pour gérer le pic.
3. (Matin, 09:05:00) (Calme) La charge redescend.
   • (Aurora) Scale Down (Instantané) (ex: 8 -> 2 ACU).

Cas d'Usage (Charges Variables)

Idéal pour remplacer les instances db.t... (Burstable) (6.1).

• Environnements (Dev / Staging) : (Ne payez (presque) rien la nuit et le weekend).
• Applications (SaaS Multi-Tenant) : (La charge est imprévisible).
• APIs (Spiky) : (Trafic très "variable" (pics)).

(Inconvénient) : (Si charge constante 24/7) (ex: 8 ACU 24/7) -> Serverless v2 est (souvent) plus cher qu'une instance Provisionnée (ex: db.r6g.large) (surtout si l'instance est "Réservée" (RI/SP)).

8.4. Sharding / Partitionnement (Côté Application)

C'est la stratégie de scalabilité "ultime" (et la plus complexe). C'est (généralement) la seule façon de scaler (horizontalement) l'ÉCRITURE (INSERT / UPDATE).

Le Goulot d'Étranglement (Écriture)

(Problème) : Vous avez (scalé verticalement) l'instance Master (Writer) la plus grosse (ex: db.r6g.32xlarge). Les Read Replicas (8.2) (Lecture) sont OK. Mais le Master (Écriture) est saturé (100% CPU/IO) par les INSERT/UPDATE.

(Solution) : Le Sharding (Partitionnement Horizontal).

Architecture (Logique Applicative)

Le "Sharding" n'est pas une fonctionnalité RDS (sauf Aurora (complexe)). C'est une logique (complexe) que vous (Développeur) devez implémenter dans votre application (ex: Django).

Vous "partitionnez" (shardez) les données (ex: par UserID, TenantID, Region) sur plusieurs BDDs (Masters) indépendantes.

                    (Client App)
                    |
                    (Code Django / "DB Router")
                    |
                    (IF user_id % 2 == 0) (Pair)
                    |
                    v
                    [ 🐘 Cluster RDS 1 (Shard 0) ] (Master R/W)
                    (Contient 50% des users (Pairs))

                    (IF user_id % 2 == 1) (Impair)
                    |
                    v
                    [ 🐘 Cluster RDS 2 (Shard 1) ] (Master R/W)
                    (Contient 50% des users (Impairs))
                

Inconvénients (Complexité Extrême)

• (Logique App) : L'application doit savoir (logique de "routage") sur quel "Shard" (BDD) elle doit écrire/lire.
• (Perte d'Intégrité) : Vous perdez les JOINs (Jointures) (entre Shard 0 et Shard 1). Vous perdez les Transactions (ACID) (entre Shards). Vous perdez les Clés Étrangères (Foreign Keys) (globales).
• (Re-Sharding) : (Si Shard 1 est plein) Ajouter un 3ème Shard (et "re-balancer" (ré-équilibrer) les données) est une opération (manuelle) extrêmement complexe (downtime).

(Conclusion) : C'est une solution de "dernier recours" (utilisée par ex: Uber, Slack) (pour scalabilité massive), à n'utiliser qu'après avoir épuisé (8.1, 8.2, 8.3) et (6.4) (optimisation SQL).

7.2. Enhanced Monitoring (Niveau OS)

C'est le monitoring optionnel (Opt-in, payant) qui mesure l'OS (Système d'Exploitation) sous-jacent (Linux/Windows). Il fournit une granularité haute résolution (jusqu'à 1 seconde).

(Fonctionnement) : AWS installe un Agent (sur l'hôte RDS) qui envoie les métriques (JSON) (très détaillées) vers CloudWatch Logs.

Il répond à : "Le CPU (7.1) est à 90%. Quel process (OS) est le coupable ?"

Métriques Clés (OS-level)

• processList (Liste des Processus) : (Le "Top" / "Htop") Affiche (ex: toutes les 5 sec) le PID, %CPU, %MEM de chaque process (ex: postgres: vacuum, postgres: select..., rds-agent).
• loadAverageMinute (Load Avg) : (load_1, load_5, load_15) (La "vraie" charge CPU (file d'attente run queue)).
• cpuUtilization (Détaillé) : (nice, system, user, wait (%iowait -> % CPU en attente du Disque (I/O) (Goulot Disque))).
• memory (Détaillé) : (active, free, buffers, cached) (Détail de l'utilisation RAM (OS Page Cache)).

7.3. Performance Insights (PI) (Niveau BDD/SQL)

C'est l'outil de monitoring (PaaS) le plus puissant (gratuit 7 jours, payant (rétention longue)). Il se concentre uniquement sur la performance (Charge) de la BDD (le moteur SQL).

Il répond à : "Ma BDD est lente. Quelle requête SQL (Query) est la coupable, et Pourquoi (Wait Event) ?".

Analyse Temps Réel (Dashboard PI)

• 1. Database Load (AAS) : (Le Graphique Principal)
  • AAS (Average Active Sessions) : Le nombre (moyen) de connexions "Actives" (soit sur le CPU, soit en Attente (Wait)).
  • Max vCPU (Ligne Pointillée) : Votre limite (capacité) CPU (Instance).
  • (Diagnostic) : Si la barre (AAS) dépasse (constamment) la ligne (Max vCPU) -> Votre BDD est en surcharge (Goulot).
• 2. Wait Events (Attentes) : (La "Couleur" de la barre AAS)
  • CPU (Vert) : Normal. La requête utilise le CPU (Calcul).
  • IO:DataFileRead (Bleu) : Attente I/O (Disque). (Symptôme : SELECT lent, Index manquant (6.4)).
  • IO:XactSync (Bleu Ciel) : Attente I/O (Disque). (Symptôme : COMMIT (Écriture) lent (Goulot Disque/EBS (6.2))).
  • Lock:transactionid (Rouge) : Attente (Verrouillage). (Symptôme : 2 requêtes (UPDATE) se "battent" (bloquent) pour la même ligne).
• 3. Top SQL (Requêtes Lourdes) : (La "Liste" en bas)
  • Classe (par "Charge AAS") les requêtes SQL exactes (SELECT * FROM users WHERE email=...) qui causent la charge (Wait Events) (ci-dessus).

(Flux de Diagnostic) : 1. Voir AAS > Max vCPU. 2. Voir "Couleur" = Bleu (IO:DataFileRead). 3. Voir "Top SQL" = SELECT * FROM users WHERE email=.... 4. (Conclusion) : "La requête (Top SQL) est lente (AAS) car elle attend le disque (Wait IO)". 5. (Action) : "Ajouter un Index (CREATE INDEX) sur la colonne email".

7.4. Logs Moteur (Error, Slow, Audit)

(Important) : Vous n'avez pas accès (SSH) aux fichiers de logs (/var/log/...) sur l'instance RDS.

(Solution) : Vous devez (via la Console RDS) "Publier (Exporter)" les logs (de votre choix) vers Amazon CloudWatch Logs (pour consultation, alerte (Filtres), et archivage (vers S3)).

6.2. Tuning du Stockage (EBS)

Le stockage (Disque) est (après la RAM) le goulot d'étranglement (bottleneck) n°1 des BDD (Workloads "I/O-Bound").

SSD gp3 vs io2 Block Express

• gp3 (SSD - General Purpose 3) :
  • (Le Standard) (99% des workloads).
  • Baseline (Garantie) : 3 000 IOPS & 125 MB/s (Throughput).
  • (Avantage Clé) : Vous pouvez scaler (augmenter) les IOPS (jusqu'à 16 000) et/ou le Throughput (jusqu'à 1000 MB/s) indépendamment de la Taille (GB) (facturation séparée).
• io2 Block Express (SSD - Provisioned IOPS) :
  • (Usage Critique) BDD OLTP (SAP HANA, Oracle) nécessitant une latence sub-milliseconde et/ou des IOPS extrêmes (garantis) (ex: 20 000, 40 000, max 256 000 IOPS).
  • (Coût) : Très cher (facturé au $/GB + $/IOPS-provisionné).

IOPS (Workload OLTP) vs Throughput (Workload OLAP)

• (Workload OLTP) (ex: API, Django, INSERT/UPDATE) :
  • (Nature) : Petites lectures/écritures (8KB/16KB) aléatoires.
  • (Goulot) : Limité par les IOPS (Opérations/seconde).
  • (Monitoring) : Surveiller Read/WriteIOPS (CloudWatch) et Disk Queue Depth (6.6).
• (Workload OLAP) (ex: Analytics, BI, SELECT COUNT(*) sur 1 Milliard lignes) :
  • (Nature) : Grosses lectures (1MB+) séquentielles (Full Table Scan).
  • (Goulot) : Limité par le Throughput (Débit, MB/s).
  • (Monitoring) : Surveiller Read/WriteThroughput (CloudWatch).

6.3. Cache & Mémoire (Le "Saint Graal" de la Performance BDD)

La stratégie de performance n°1 est d'éviter le disque (lent). Pour cela, la BDD utilise la RAM (mémoire) (rapide) pour "cacher" (mettre en cache) les données et les index les plus fréquemment utilisés (le "Working Set").

(Objectif) : Avoir un Cache Hit Ratio (6.6) (Taux de T_ouche Cache) de > 99%.

Tuning (Parameter Groups)

6.4. Indexation & Optimisation de Requêtes (SQL)

(La Cause n°1 de Lenteur Applicative) : L'instance (6.1) est énorme (.xlarge), le disque (6.2) est rapide (io2), mais l'application est lente.

(Cause) : Une requête SQL (mal écrite) ou (le plus souvent) un Index (Index) manquant.

Flux de Diagnostic (Trouver le coupable)

1. 1. Activer les "Slow Query Logs" (Logs de requêtes lentes) (5.5) :
   • (MySQL) long_query_time = 1 (1 sec) + log_queries_not_using_indexes = 1 (Tuer les "Full Scans").
   • (Postgres) log_min_duration_statement = 500 (500 ms).
   • (Alternative) Utiliser Performance Insights (AAS) (qui est un "Slow Log" visuel (temps-réel)).
2. 2. Identifier (Identifier) la requête lente :
   • (Logs) SELECT * FROM users WHERE email = 'test@example.com'; (Durée: 30 000 ms).
3. 3. Analyser (EXPLAIN) le Plan d'Exécution :
   • (psql) EXPLAIN ANALYZE SELECT * FROM users WHERE email = ...
4. 4. Lire le Plan (Rechercher les "Scans Séquentiels") :
   • (Résultat) -> Seq Scan on users (cost=0.00..50000.00 rows=1 width=...)
   • (Diagnostic) : Seq Scan (Scan Séquentiel) = "Full Table Scan". La BDD lit 100% de la table (des millions de lignes) (I/O Disque massif) car il n'y a pas d'index sur email.
5. 5. Corriger (CREATE INDEX) :
   • (psql) CREATE INDEX idx_users_email ON users (email);
   • (Nouveau Plan) : -> Index Scan using idx_users_email on users (cost=0.42..8.44 rows=1 ...) (Durée: 2 ms).

6.5. Parameter Groups & Option Groups

Puisque vous n'avez pas accès (SSH) au serveur (OS), vous ne pouvez pas éditer les fichiers (postgresql.conf, my.cnf) (locaux).

Vous (devez) gérer ces configurations (Moteur) via des Parameter Groups (PG) (managés) (via Console/API).

Parameter Groups (PG) (Le ".conf")

• default.postgres15 (PG par Défaut) : (Non-modifiable) Optimisé "générique".
• mon-app-prod-pg (PG Custom) : (Bonne Pratique)
  1. Créer 1 PG "Custom" (basé sur le "Défaut").
  2. Modifier (Tuner) les paramètres (ex: shared_buffers (6.3), log_min_duration_statement (6.4), work_mem (sort/hash), max_connections).
  3. Attacher (Modify) ce PG (Custom) à l'instance RDS.
• (Statique vs Dynamique) : Certains paramètres (ex: shared_buffers) sont "Statiques" (Static) et nécessitent un Reboot (Redémarrage) de l'instance RDS (à appliquer durant la Fenêtre de Maintenance). D'autres (ex: log_min_duration_statement) sont "Dynamiques" (Dynamic) (appliqués "à chaud" (live)).

Option Groups (Les "Plugins")

C'est (similaire) mais utilisé pour activer des "fonctionnalités" (plugins, extensions) majeures (non-incluses par défaut).

• PostgreSQL : (Moins utilisé) (Les extensions (ex: PostGIS) sont gérées via le Parameter Group (shared_preload_libraries)).
• MySQL/MariaDB : (ex: Activer l'audit MARIADB_AUDIT_PLUGIN).
• Oracle/SQL Server : (Très utilisé) (ex: Activer TDE (Transparent Data Encryption), SQLSERVER_AUDIT, NATIVE_NETWORK_ENCRYPTION).

6.6. Monitoring I/O (Métriques Clés de Performance)

Comment savoir si votre BDD est "saturée" (goulot d'étranglement) ? Vous devez corréler les métriques (CloudWatch) (l'Effet) avec l'analyse (Performance Insights) (la Cause).

Métriques de Saturation (L'Effet / Le Symptôme)

5.2. Connexion Réseau (VPC & Security Groups)

C'est la couche de sécurité Réseau (L3/L4). Comment la BDD est-elle isolée ?

No Public Access (Bonne Pratique n°1)

Une BDD RDS ne doit jamais être publique. Lors de la création (Configuration "Connectivity"), Public Access doit toujours être sur No.

Placement (Subnets Privés)

La BDD doit "vivre" dans votre VPC (isolée), dans un "DB Subnet Group". Ce groupe doit contenir (uniquement) des Subnets Privés (ou "Isolés") (càd : des Subnets dont la Route Table n'a PAS de route vers un Internet Gateway (IGW)).

Security Groups (SG) Stricts (Le Vrai Pare-feu)

Le Security Group (SG) est le pare-feu (Stateful) attaché à l'ENI (Instance) de RDS. C'est lui qui contrôle le Data Plane (qui peut parler au Port 5432 ?).

(Mauvais) : Allow TCP/5432 (Postgres) (Source: 0.0.0.0/0 (Public)) -> (Faille de sécurité massive).

(Moyen) : Allow TCP/5432 (Source: 10.0.1.0/24 (CIDR du Subnet App)) -> (OK, mais trop permissif).

(Meilleur - Least Privilege) : Allow TCP/5432 (Source: sg-app-server (L'ID du SG de l'App EC2/Lambda)).

5.3. Encryption (Chiffrement At-Rest & In-Transit)

Encryption at-Rest (Chiffrement au Repos)

C'est le chiffrement du disque (Volume EBS) sous-jacent (où les fichiers de données (.dat) sont stockés). C'est une case à cocher ("Enable Encryption") lors de la création de la BDD.

• (Obligatoire) : Vous ne pouvez pas chiffrer une BDD (non-chiffrée) existante. (Il faut Snapshot -> Copy Snapshot (en chiffrant) -> Restore).
• (Clé) : Utilise AWS KMS (Key Management Service).
  • Clé (Défaut) : aws/rds (Clé managée par AWS, gratuite, pas d'audit).
  • Clé (CMK) : (Recommandé) Votre propre Customer Managed Key (Clé gérée par le client). (Permet l'audit (CloudTrail), la rotation, et la gestion (IAM Policy) de qui peut "utiliser" (chiffrer/déchiffrer) les backups).
• (Périmètre) : Chiffre le volume (EBS), les Read Replicas (automatiquement), et les Snapshots (automatiquement).

Encryption in-Transit (Chiffrement en Transit)

C'est le chiffrement (SSL/TLS) de la connexion (réseau) entre votre Application (ex: Django) et l'Endpoint (Serveur) RDS.

• (Serveur) : RDS (le service) gère (automatiquement) l'installation et la rotation des certificats SSL (publics) sur l'instance BDD.
• (Client) : C'est la responsabilité de l'Application (Client) de forcer (require) et de vérifier (verify) la connexion SSL.

(Exemple psql (Postgres) / settings.py (Django)) :

                    # (Django DATABASES 'OPTIONS')
                    'OPTIONS': {
                    'sslmode': 'verify-full',  # (Force SSL + Vérifie le Certificat (CA))
                    'sslrootcert': '/path/to/aws-rds-ca-bundle.pem' # (Chemin du Bundle CA (Trust) d'AWS)
                    }

                    # (psql CLI)
                    $ psql "... host=... user=... sslmode=verify-full"
                

5.4. Secrets Manager & Parameter Store

(Le Problème) : Où stocker le mot de passe (Master User) de la BDD (Data Plane) ?

(Anti-Pattern) : "Hardcoder" (écrire en dur) le mot de passe dans le code (settings.py), dans un .env (sur l'EC2), ou dans les Variables d'Environnement (Lambda) (visibles en clair dans la console).

La Solution : AWS Secrets Manager

Secrets Manager est un service (PaaS) dédié au stockage (chiffré via KMS) et à la rotation (automatique) des secrets (ex: Mots de passe BDD, Clés API).

Flux (Application Django/EC2/Lambda)

1. (Admin) (Secrets Manager) Vous créez un "Secret" (ex: prod/rds/main-db) (stocke {"username":"admin", "password":"Password123", "host":"...rds..."}).
2. (Admin) (IAM) Vous donnez (via un IAM Role) à votre EC2/Lambda (l'application) la permission secretsmanager:GetSecretValue (sur l'ARN du secret).
3. (Application) (Au démarrage / settings.py) L'application (Boto3) appelle (API) Secrets Manager (GetSecretValue) (via son IAM Role, sans clés d'accès).
4. (Application) Récupère le JSON (mot de passe) en mémoire (RAM) et l'utilise pour se connecter à RDS.

Rotation Automatique (La "Magie")

C'est la fonctionnalité clé de Secrets Manager (vs SSM Parameter Store (Simple)).

• (Config) Vous activez la Rotation (Automatique) (ex: tous les 30 jours).
• (Flux) (Tous les 30 jours) Secrets Manager (via une Lambda (interne) de rotation) :
  1. Se connecte à RDS (avec l'ancien mot de passe).
  2. Change le mot de passe (ALTER USER ... PASSWORD ...).
  3. Stocke (met à jour) le nouveau mot de passe dans le "Secret".

(Résultat) : Le mot de passe (BDD) est changé (automatiquement) tous les 30 jours, sans intervention humaine et sans redéployer l'application (l'application (3) récupère le nouveau mot de passe au prochain (re)démarrage).

5.5. Audit & Logs (Moteur BDD)

(Important) : RDS (PaaS) ne vous donne pas accès (SSH) aux fichiers de logs (ex: /var/log/postgresql/postgresql.log) sur le disque.

(Solution) : Vous devez "Exporter (Publier)" ces logs (via une case à cocher) vers Amazon CloudWatch Logs (pour consultation, analyse (Logs Insights), et archivage (vers S3)).

Logs Open Source (PostgreSQL / MySQL)

Vous (Admin) contrôlez "ce qui est loggué" via le DB Parameter Group (le postgresql.conf / my.cnf managé).

• PostgreSQL Logs :
  • (Exporter) Activer postgresql.log (Export vers /aws/rds/instance/.../postgresql).
  • (Tuning) log_min_duration_statement = 500 (Bonne Pratique : Logguer toutes les requêtes SQL (SELECT, UPDATE...) qui prennent plus de 500 ms (pour trouver les requêtes lentes)).
• MySQL / MariaDB Logs :
  • (Exporter) Activer slow_query_log, error_log, general_log.
  • (Tuning) long_query_time = 1 (Logguer les requêtes > 1 seconde).
  • (Tuning) log_queries_not_using_indexes = 1 (Bonne Pratique : Logguer les requêtes (lentes) qui font des "Full Table Scans" (Index manquant)).

Audit Logging (Commercial / Avancé)

Pour les moteurs commerciaux (ou compliance stricte).

• Oracle / SQL Server : RDS supporte (via "Options Groups") l'Audit Natif (ex: "SQL Server Audit"). (Ex: "Auditer (logguer) tous les SELECT, DELETE sur la table COMPTA.SALAIRES").
• PostgreSQL (Audit) : (Alternative) Activer l'extension pgaudit (via Parameter Group).
• (Tous ces logs (détaillés) sont (aussi) exportés vers CloudWatch Logs).

4.2. Multi-AZ with 2 Readable Standbys (Cluster)

C'est une nouvelle architecture (moderne) (disponible pour Postgres/MySQL sur les instances (ex: db.r6i, db.r6g)) qui combine HA (3 AZs) et Scaling en Lecture (similaire à Aurora).

Architecture

• Composants : 1 Master (Primaire) (Actif, R/W) (AZ-A) + 2 Standby (Secondaires) (Actifs, Read-Only) (AZ-B et AZ-C).
• AZs : Déploiement (obligatoire) sur 3 Availability Zones.
• Stockage : Utilise (généralement) io1/io2 (local SSD (Instance Store) pour le "redo log").

Avantages vs Multi-AZ (Classique)

• Performance I/O (Écriture) : Les "commits" (COMMIT) sont plus rapides (jusqu'à 2x) car la réplication (tx log) est optimisée (le Master n'attend qu'1 seul Standby (quorum), pas les deux).
• Performance (Lecture) : Les 2 Standby sont actifs (Read-Only). (Contrairement au Standby "classique" (4.1) qui est passif). Vous pouvez (via un "Reader Endpoint") décharger les SELECT sur ces 2 Standby (similaire aux Read Replicas (4.3)).
• Failover (Basculement) : Le basculement (Failover) est (généralement) plus rapide (souvent < 35 secondes).

4.3. Read Replicas (Réplicas en Lecture)

C'est la fonctionnalité (manuelle) pour le Scaling en Lecture (Performance). Ce n'est PAS (par défaut) une solution de Haute Disponibilité (HA).

Architecture (Asynchrone)

• Composants : 1 Master (R/W) -> (jusqu'à 15) Read Replicas (RR) (Read-Only).
• Réplication : ASYNCHRONE. (Utilise la réplication native (Binlog (MySQL) / WAL (Postgres))).
• (Le Piège - "Replication Lag") : L'écriture (COMMIT) sur le Master (R/W) est (immédiate). La donnée peut prendre (ex:) 50ms à 10 secondes (ou plus) pour arriver (être répliquée) sur la Read Replica (R/O).

Cas d'Usage (Scaling en Lecture)

Problème : Mon Master (db.r6g.large) (100% CPU) est saturé par les SELECT (lourds) de mon équipe "BI / Analytics".

Solution :

1. Créer 1 Read Replica (db.r6g.large).
2. (L'App (Prod) continue de viser le Master).
3. (L'équipe BI) Vise (via son outil, ex: Metabase) l'Endpoint (DNS) (séparé) de la Read Replica.
4. (Résultat) : Les SELECT (lourds) sont déchargés sur la RR. Le Master (CPU 20%) respire.

Failover Manuel (DR)

Si le Master (db-master) meurt (panne non-Multi-AZ) :

• (Action Manuelle) Vous pouvez "Promouvoir" (Promote) la Read Replica (db-rr).
• (Résultat) La RR (db-rr) est "cassée" (détachée) du Master (mort) et devient une nouvelle instance Master (R/W) (avec un nouvel Endpoint).
• (Risque) Vous perdez les données (COMMITs) qui étaient "en vol" (dans le "Replication Lag") (non-encore répliquées).

4.4. Amazon Aurora (Haute Disponibilité)

Aurora (3.3) utilise une architecture (Cloud-Native) fondamentalement différente (stockage partagé), ce qui change (améliore) radicalement la HA.

Stockage Distribué (6 Copies / 3 AZ)

Le Stockage (Volume) (PaaS) est partagé. Il n'est pas attaché (EBS) à une instance.

• Architecture (Storage) : 1 Volume (ex: 128TB), qui écrit (automatiquement) 6 copies de vos données (blocs), réparties sur 3 AZs (2 copies / AZ).
• Tolérance (Écriture) : A besoin d'un Quorum "4 sur 6" (Write Quorum). (Peut survivre à la perte totale d'1 AZ (2 copies) + 1 autre nœud (1 copie) et continuer d'écrire).
• Auto-Healing (Auto-Réparation) : Si le stockage (dans l'AZ-A) est corrompu (bit rot), Aurora (automatiquement) le répare (auto-heal) en utilisant les copies (saines) (AZ-B, AZ-C).

Instant Failover (Basculement Instantané)

Dans un Cluster Aurora, vous avez 1 "Compute" (Instance) Writer (Master) et (jusqu'à 15) "Compute" (Instances) Readers (Replicas). (Tous lisent/écrivent sur le même Volume (partagé)).

• Scénario : (Panne) L'instance Writer (Master) (Compute) (AZ-A) tombe (panne EC2).
• (1) Détection : Aurora détecte (immédiat).
• (2) Promotion : Aurora promeut (immédiat) une Read Replica (ex: AZ-B) au rang de Writer (elle a déjà accès au stockage partagé).

(Downtime) : < 10 secondes (parfois < 5 sec). (Pas d'attente DNS (4.1) si vous utilisez le Reader Endpoint (2.3) (qui détecte la promotion), ou le RDS Proxy (qui gère le failover)).

4.5. Backups Automatiques & Point-In-Time Restore (PITR)

C'est la fonctionnalité de Durabilité (Humaine) (protection contre DELETE FROM users; (erreur humaine)).

1. Backups Automatiques (Snapshots)

• (Activé par Défaut) (Rétention : 1 à 35 jours (ex: 7 jours)).
• Fenêtre (Backup Window) : (Ex: 02:00-02:30 UTC) AWS prend 1 Snapshot (EBS) (sauvegarde complète/incrémentale) du volume (disque), 1x / jour.

2. Point-In-Time Restore (PITR) (Restauration à la Seconde)

Pour permettre le PITR (restauration "entre" les snapshots), RDS (en plus des snapshots) capture (continuellement) les Logs de Transaction (WAL (Postgres) / Binlog (MySQL)) et les envoie (toutes les 5 min) vers S3 (stockage interne).

Flux (Restauration)

(Scénario) : Mardi 14:32:10 -> DELETE FROM users; (Erreur).

1. (Admin) Console RDS -> "Restore to point in time".
2. (Admin) Choisit "Custom". Date/Heure : Mardi 14:32:05 (5 secondes avant le DELETE).
3. (Admin) Donne un Nouveau Nom (ex: ma-bdd-restored).
4. (Flux AWS) :
   • (AWS) 1. Récupère le dernier Snapshot (celui de 02:00 UTC).
   • (AWS) 2. Crée une nouvelle BDD (-restored) (état 02:00).
   • (AWS) 3. "Rejoue" (Replay) (en accéléré) les Logs de Transaction (stockés sur S3) (de 02:00:00 à 14:32:05).

(Résultat) : Une nouvelle instance BDD (avec un nouvel Endpoint) est créée, contenant les données exactes à 14:32:05.

Snapshots Manuels

(Action : Clic "Take Snapshot"). C'est un backup (manuel) (ex: snap-avant-migration) qui est conservé (Retained) (et facturé) même si vous supprimez l'instance RDS (contrairement aux Backups Auto (qui sont supprimés)).

3.2. MySQL & MariaDB (sur RDS)

(Populaire/Legacy) Le moteur "open source" (LAMP) le plus déployé au monde (ex: WordPress, Drupal, Magento). MariaDB est son "fork" (dérivé) communautaire (100% compatible).

Avantages & Limites

• (Avantage) : Extrêmement mature, rapide (pour les lectures simples/indexées), et (très) large écosystème.
• (Avantage) : Plus simple (pour les débutants) que PostgreSQL.
• (Limite) : Moins "riche" en fonctionnalités avancées (le support JSON (natif) est moins performant que JSONB, pas de DDL transactionnel...).

Réplication (Binlog)

La réplication (pour les Read Replicas, ou pour répliquer (en externe) vers une EC2/On-Prem) est basée sur le binlog (Binary Log).

• (Backups) : RDS doit avoir les Backups Automatiques (activés) (Rétention > 0 jours) pour activer le binlog (requis pour les Read Replicas).
• (Accès) : RDS (via Parameter Group) vous donne accès (contrôle) au format du binlog (binlog_format = ROW (recommandé), STATEMENT, MIXED).

Tuning (Innodb Buffer Pool)

Le paramètre (Parameter Group) le plus critique (performance) pour MySQL (Moteur InnoDB) est innodb_buffer_pool_size.

C'est la RAM (Cache) allouée au moteur (pour garder les index et les données "chaudes" en mémoire). RDS (par défaut) le règle (intelligemment) à (environ) 75% de la RAM (totale) de l'Instance (db.r6g.large = 16GB RAM -> Buffer Pool ≈ 12GB).

3.3. Amazon Aurora (Cloud-Native)

(Recommandé par AWS) Aurora n'est pas un nouveau moteur. C'est une architecture (PaaS) "Cloud-Native" qui est compatible (Frontend) avec PostgreSQL ou MySQL, mais qui utilise un Moteur de Stockage (Backend) custom (propriétaire AWS).

Stockage Distribué (La "Magie")

C'est la différence clé. (RDS Standard = 1 Instance + 1 Disque EBS). (Aurora = 1 Instance + 1 Volume "virtuel" (Storage Layer)).

• Stockage (PaaS) : Le volume (stockage) est séparé du calcul (instance).
• Réplication (6x) : Vos données (Data) sont copiées (répliquées) 6 fois, sur 3 AZs (2 copies par AZ). (Tolérance : Survit à la perte de 1 AZ + 1 autre nœud).
• (Vitesse) : Les "Writes" (Écritures) sont (plus) rapides (que RDS) car Aurora n'écrit que les "Logs" (Log-Structured Storage) (pas de "checkpoints" / "double write buffer" comme MySQL/Postgres).

(Marketing) : AWS annonce : 5x plus rapide que MySQL (standard) / 3x plus rapide que PostgreSQL (standard).

Haute Disponibilité (Failover)

• (RDS Standard) : 1 Master (Active) + 1 Standby (Passive, Synchrone). (Failover = 30-60 sec).
• (Aurora) : 1 Master (Active, Écriture) + 15 Read Replicas (Actives, Lecture) (partagent le même stockage).
• (Failover) : Si le Master (Écriture) tombe, Aurora promeut (en < 10 secondes) une Read Replica (au choix) en nouveau Master. (Failover quasi-instantané).

Aurora Serverless v2

Une version (moderne) d'Aurora qui auto-scale (automatiquement) le Compute (CPU/RAM) à la volée (sans downtime), en fonction de la charge (AAS).

• (Config) : Vous définissez une plage (ex: Min 0.5 ACU (1GB) -> Max 16 ACU (32GB)).
• (Flux) : (Nuit, 0% charge) -> Aurora "scale down" à 0.5 ACU (Coût minime). (Matin, 9h) -> (Pic de charge) -> Aurora "scale up" (immédiat) à 16 ACU.
• (Usage) : Idéal pour Dev/Test, ou applications "imprévisibles" (spiky).

3.4. Oracle (sur RDS)

(Usage : Migration "Lift & Shift") Permet de migrer des BDD (Oracle) "legacy" (On-Premise) vers AWS (en mode PaaS).

Éditions Supportées

• Oracle Database Enterprise Edition (EE) : (Haut de gamme, toutes options).
• Oracle Database Standard Edition 2 (SE2) : (Standard).
• (RDS ne supporte pas "Express Edition" (XE) (Gratuit)).

Options de Licence (Le Piège)

C'est le point le plus complexe (et le plus cher) d'Oracle sur AWS.

3.5. Microsoft SQL Server (sur RDS)

(Usage : Migration "Lift & Shift") Permet de migrer des BDD (MS SQL) "legacy" (On-Premise) (ex: applications .NET, SharePoint) vers AWS (en mode PaaS).

Éditions Supportées

• SQL Server Express Edition : (Gratuit, limité 10GB / 1 vCPU / 1GB RAM). (OK pour Dev/Test).
• SQL Server Web Edition : (Moins cher) (Uniquement "License Included").
• SQL Server Standard Edition : (Standard).
• SQL Server Enterprise Edition : (Haut de gamme).

Options de Licence (Plus simple qu'Oracle)

• 1. License Included (LI) : (Défaut / Recommandé) AWS fournit la licence (intégrée au coût $/Heure de l'instance). Vous payez ce que vous consommez.
• 2. BYOL (Bring Your Own License) : (Si vous avez des licences (On-Prem) avec "Software Assurance" (SA) (Mobilité de Licence)). Vous ne payez (à AWS) que le coût "Instance" (Compute). (Peut (contrairement à Oracle) s'exécuter sur du matériel "Shared" (Défaut), pas besoin (obligatoire) de "Dedicated Host").

Fonctionnalités Spécifiques

• Multi-AZ : RDS (SQL Server) utilise la technologie "Database Mirroring (DBM)" (Legacy) ou "Always On Availability Groups (AGs)" (Moderne/Enterprise) pour gérer la réplication (Synchrone) Multi-AZ.
• Authentification : Supporte "Windows Authentication" (Kerberos) (via intégration avec AWS Managed Microsoft AD).

2.2. Stockage (EBS)

C'est la couche "Disque Dur" (persistante) de votre BDD. RDS utilise des volumes EBS (Elastic Block Store) (stockage réseau).

Types de Stockage (SSD vs HDD)

Storage Autoscaling

C'est une option (case à cocher) à la création (ou modification) de l'instance.

(Problème) : Votre BDD (100GB) se remplit (INSERT massifs). Elle atteint 100% (Full). RDS passe (automatiquement) la BDD en mode storage-full (Lecture Seule). L'application plante (INSERT échouent).

(Solution) : Activer Storage Autoscaling (ex: Max 1000 GB).

• (AWS) Monitore la métrique FreeStorageSpace.
• (AWS) Si l'espace libre est (trop bas) -> Augmente (automatiquement) le disque (ex: +10%) sans downtime.

(Attention) : Le Storage Autoscaling ne scale que vers le HAUT (UP). Il ne réduit (DOWN) jamais la taille du disque (vous devez le faire manuellement via Snapshot/Restore).

2.3. Endpoints RDS (Le "Hostname" DNS)

Vous ne vous connectez jamais à une BDD RDS via son IP Privée (car elle change lors d'un Failover, Restore, ou Stop/Start). Vous utilisez toujours l'Endpoint (Hostname DNS) (géré par AWS via Route 53).

1. Endpoint Principal (Instance / Cluster)

C'est l'Endpoint (DNS) principal. Il pointe toujours vers l'instance Master (Écriture / Write).

                    # (Exemple : Endpoint Principal / "Cluster Endpoint")
                    mon-db-prod.cluster-cabcdef123.eu-west-3.rds.amazonaws.com
                

(Multi-AZ Endpoint) : C'est CE MEME endpoint ! Si vous êtes en Multi-AZ (HA) et que l'instance Master (AZ-A) tombe en panne :

1. RDS (automatiquement) "promeut" le Standby (AZ-B) en nouveau Master.
2. RDS (automatiquement) met à jour (bascule) ce DNS (mon-db-prod.cluster...) pour qu'il pointe vers l'IP privée (AZ-B) du nouveau Master.
3. (L'application (Django) n'a rien à changer, elle continue de viser le même Hostname).

2. Reader Endpoint (Endpoint Lecture) (Aurora Uniquement)

Si vous utilisez AWS Aurora (et que vous avez créé 1 Master + 3 Read Replicas) :

                    # (Exemple : Endpoint Lecture (Read Replica))
                    mon-db-prod.cluster-ro-cabcdef123.eu-west-3.rds.amazonaws.com
                

Cet endpoint (DNS) (-ro-) spécial répartit (load balance) (en mode DNS Round-Robin) automatiquement les connexions (SELECT) entre toutes les Read Replicas (saines) (RR1, RR2, RR3).

3. Custom Endpoints (Aurora Uniquement)

Permet (sur Aurora) de créer vos propres endpoints (ex: analytics-endpoint) et de choisir (manuellement) quelles instances (ex: "uniquement RR2 et RR3") répondent à ce DNS. (Utile pour isoler les workloads BI (lourds) sur des Replicas spécifiques).

2.4. Réseau & Accessibilité (VPC)

Aucun Accès Public (Règle d'Or)

(Bonne Pratique n°1) : Une base de données (RDS) ne doit JAMAIS être accessible depuis Internet. Lors de la création, le paramètre Public Access doit toujours être sur No.

Une BDD n'a que une IP Privée.

Placement dans un VPC

L'instance RDS doit "vivre" dans votre VPC (isolée).

• Subnets Privés Recommandés : (Isolation maximale) La BDD doit être placée dans des Subnets Privés (ou "Isolés") (càd : des Subnets dont la Route Table n'a PAS de route vers un Internet Gateway (IGW)).
• DB Subnet Group : Vous ne "choisissez" pas 1 Subnet, vous "assignez" un DB Subnet Group (ex: db-subnet-group-private).
• (Règle HA) : Ce "Subnet Group" doit contenir (au minimum) 2 Subnets Privés, situés dans 2 Availability Zones (AZ) différentes (ex: private-a (eu-west-3a) et private-b (eu-west-3b)).
  • (Raison : Pour que le "Multi-AZ Failover" (2.3) puisse (physiquement) démarrer le Standby dans l'autre Datacenter (AZ-B)).

Filtrage (SG & NACL)

• NACL (Niveau Subnet) : (Stateless) Laisser (par défaut) (Allow All).
• Security Group (SG) (Niveau Instance) : (Stateful) C'est le vrai pare-feu (le seul à configurer).
  • (Mauvais) : Allow TCP/5432 (Postgres) (Source: 0.0.0.0/0) -> (DANGEREUX).
  • (Moyen) : Allow TCP/5432 (Source: 10.0.1.0/24 (CIDR du Subnet App)) -> (OK, mais trop permissif).
  • (Meilleur) : Allow TCP/5432 (Source: sg-app-server (L'ID du SG de l'App EC2/Lambda)).

1.2. Pourquoi choisir RDS ? (Avantages)

1. Gain de Temps (Ops) - "Undifferentiated Heavy Lifting"

L'avantage n°1 est l'économie de temps (et d'argent) sur les opérations (Ops) à faible valeur ajoutée ("undifferentiated heavy lifting").

Au lieu que vos DBAs (Administrateurs BDD) passent 80% de leur temps à gérer les patchs, les pannes de disque, les backups (infra), ils passent 100% de leur temps à optimiser ce qui compte : le schéma (design tables), l'indexation, et le tuning (optimisation) des requêtes SQL lentes (via Performance Insights).

2. Sécurité Intégrée (Dès le Jour 1)

• Isolation (VPC) : (Bonne Pratique) La BDD est (doit être) lancée dans un Subnet Privé (isolée d'Internet), protégée par des Security Groups (pare-feu).
• Chiffrement (Encryption at-Rest) : (Facile) Cochez "Enable Encryption". RDS utilise AWS KMS (votre clé ou une clé AWS) pour chiffrer (automatiquement) le disque (EBS) et les backups.
• Chiffrement (In-Transit) : (Automatique) Force l'utilisation de SSL/TLS (psql ... sslmode=verify-full) pour les connexions.
• Authentification (IAM) : (Moderne) Supporte l'IAM DB Authentication (connexion via Token IAM temporaire, sans mot de passe).

3. Haute Disponibilité (HA) & Scalabilité Simplifiées

• Haute Disponibilité (Multi-AZ) : (Une case à cocher) RDS crée (automatiquement) un "Standby" (clone) synchrone dans une autre AZ (Datacenter). En cas de panne (Master), RDS bascule (failover) (automatiquement, en 30-60s) sur le Standby (qui devient Master).
• Scalabilité Verticale (Vertical Scaling) : (Changement de Taille) Changer une db.m5.large -> db.m5.xlarge (plus de CPU/RAM) (se fait (généralement) avec un court reboot (downtime minime) lors de la fenêtre de maintenance).
• Scalabilité Horizontale (Horizontal Scaling) : (Lecture) Créer (en quelques clics) des Read Replicas (Réplicas en lecture) (copies asynchrones) pour décharger le Master des requêtes SELECT (BI, Analytics).

1.3. Les Moteurs (Engines) Supportés

RDS supporte les moteurs relationnels (SQL) Open Source et Commerciaux.

1.4. Place de RDS dans l’Écosystème AWS

RDS est une "brique" (PaaS) centrale qui "vit" (presque toujours) dans votre VPC et interagit avec de nombreux services de sécurité, de monitoring et de calcul.

Interactions (Flux de Données & Gestion)

• VPC (Réseau) : (Fondation) RDS est lancé DANS votre VPC. Il "vit" (pour la sécurité) dans un DB Subnet Group (un ensemble de Subnets Privés).
• EC2 / Lambda (Calcul) : (Consommateurs) Vos applications (EC2/Lambda) (dans le même VPC) se connectent à l'Endpoint (DNS) privé de RDS (ex: ...rds.amazonaws.com) (via son Security Group).
• IAM (Sécurité) : (Permissions) Gère qui (Admin) a le droit de CreateDBInstance, DeleteDBInstance. Gère qui (App) peut s'authentifier (via IAM DB Authentication).
• KMS (Chiffrement) : (Sécurité) RDS utilise KMS pour chiffrer (at-rest) (AES-256) le volume EBS sous-jacent (le "disque") et les Snapshots (Backups).
• CloudWatch (Monitoring) : (Observabilité) RDS envoie (pousse) (automatiquement) toutes ses métriques (CPUUtilization, FreeableMemory, DatabaseConnections...) à CloudWatch (pour Graphes & Alarmes).
• AWS Backup / S3 (Sauvegarde) : RDS gère (automatiquement) les Snapshots (via AWS Backup / EBS Snapshots) et envoie (automatiquement) les Logs de Transaction (PITR) vers S3 (stockage interne managé).
• Secrets Manager (Secrets) : (Bonne Pratique) Stocke (de manière sécurisée/chiffrée) le Master Username/Password de RDS, et gère la rotation (changement) automatique du mot de passe.

2. Mauvaise Pratique (Hardcodé dans settings.py)

Ne jamais mettre de mots de passe (secrets) dans le code (Git).

                    # (NE PAS FAIRE)
                    # mon_app/settings.py

                    DATABASES = {
                    'default': {
                    'ENGINE': 'django.db.backends.postgresql',
                    'NAME': 'ma_bdd_prod',
                    'USER': 'postgres_admin',
                    'PASSWORD': 'Password12345!', # (FAILLE DE SÉCURITÉ)
                    'HOST': 'mon-app-prod.abcdef123.eu-west-3.rds.amazonaws.com', # (Endpoint RDS)
                    'PORT': '5432',
                    }
                    }
                

3. Bonne Pratique (AWS Secrets Manager + IAM Role)

Flux : 1. Stocker les secrets (JSON) dans "Secrets Manager". 2. Donner un IAM Role (à l'EC2/Lambda) pour lire ce secret. 3. Le code (Boto3) récupère le secret au démarrage (runtime).

Pré-requis : pip install boto3

                    # (BONNE PRATIQUE)
                    # mon_app/settings.py
                    import boto3
                    import json

                    # 1. Récupérer le nom du Secret (via Variable d'Environnement)
                    SECRET_ID = os.environ.get('DB_SECRET_ARN') # (ex: "arn:aws:secrets...")

                    # 2. (Boto3) Appeler l'API AWS
                    client = boto3.client('secretsmanager', region_name='eu-west-3')
                    response = client.get_secret_value(SecretId=SECRET_ID)
                    secret = json.loads(response['SecretString'])

                    # 3. (Django) Utiliser les secrets (récupérés)
                    DATABASES = {
                    'default': {
                    'ENGINE': 'django.db.backends.postgresql',
                    'NAME': secret.get('dbname'),
                    'USER': secret.get('username'),
                    'PASSWORD': secret.get('password'), # (Jamais stocké dans Git)
                    'HOST': secret.get('host'), # (Endpoint RDS)
                    'PORT': secret.get('port'),
                    }
                    }
                

Résultat : Zéro secret dans le code. 100% sécurisé (via IAM Role).

Suivi du "Bloat" (Ballonnement) et VACUUM

Quand vous faites un UPDATE ou DELETE sur Postgres, l'ancienne ligne n'est pas supprimée, elle est marquée "morte" (dead tuple). Le VACUUM est le "nettoyeur de M." (garbage collector) qui libère cet espace.

Si autovacuum est trop lent (ou bloqué), la table "gonfle" (Bloat), et les SELECT deviennent lents (car ils doivent lire des millions de lignes "mortes").

Outils de diagnostic :

• Enhanced Monitoring (4.2) : Permet de voir (via processList) si les process autovacuum worker sont actifs et s'ils consomment du CPU/IO.
• Performance Insights (4.3) : Permet de voir si autovacuum est en attente (Wait Event) à cause d'un Lock (verrou) posé par une autre session.

Requêtes SQL Utiles (via psql)

Pour un diagnostic avancé, connectez-vous (via psql, DBeaver, etc.) en tant que postgres (Master User) et lancez ces requêtes.

1. Voir les requêtes longues / bloquantes (pg_stat_activity)

                    SELECT 
                    pid, 
                    age(clock_timestamp(), query_start) AS duration, 
                    state, 
                    wait_event, 
                    query 
                    FROM pg_stat_activity 
                    WHERE state != 'idle' AND query NOT LIKE '%pg_stat_activity%'
                    ORDER BY duration DESC 
                    LIMIT 10;
                

2. Estimer le "Bloat" (Dead Tuples)

                    SELECT 
                    relname AS table_name, 
                    n_live_tup, 
                    n_dead_tup, 
                    (n_dead_tup * 100 / (n_live_tup + n_dead_tup)) AS dead_percent
                    FROM pg_stat_user_tables 
                    WHERE (n_live_tup + n_dead_tup) > 0
                    ORDER BY dead_percent DESC
                    LIMIT 10;
                

Stratégies d'Optimisation (FinOps)

• Reserved Instances (RI) : (Pour la Prod) S'engager (1 ou 3 ans) sur une instance (ex: db.r6g.large) pour une réduction de -30% à -60% (vs On-Demand).
• Graviton (ARM) : (Pour la Prod) Utiliser des instances db.r6g (Graviton/ARM) au lieu de db.r5 (Intel/x86). (Meilleur rapport prix/performance).
• Stop/Start (Dev/Test) : (Pour Dev/Test) Scripter (Lambda/EventBridge) l'arrêt (StopDBInstance) des BDD de Dev le soir (19h) et le weekend. (Le stockage (Pilier 2) continue d'être facturé, mais le Calcul (Pilier 1) est stoppé).
• Aurora Serverless v2 (7.2) : (Pour Dev/Test) Utiliser Serverless v2 qui "scale-to-zero" (presque) quand inutilisé (pay-per-second).
• S3 Bucket Key (4.3) : (Pour SSE-KMS) Activer cette option pour réduire drastiquement les coûts d'appels à l'API KMS.