À la fin de ce tutoriel, vous aurez une instance Amazon RDS (PostgreSQL ou MySQL) en ca-central-1, dans des subnets privés, avec security group restrictif, Multi-AZ expliqué, et les commandes de connexion — plus un nettoyage obligatoire (RDS coûte cher à l’heure).

Niveau : Intermédiaire · Temps estimé : 60–75 min · Versions testées : RDS 2026, PostgreSQL 16 / MySQL 8, AWS CLI v2 · Dernière vérification : 2026-09-10 · Region : ca-central-1

Slug : aws-rds-mysql-postgres · Série : AWS Solutions Architect · Mot-clé SEO : AWS RDS tutoriel

← Précédent : AMI & user-data · → Suivant : DynamoDB · Hub : Démarrer avec AWS

Prérequis

• VPC avec au moins 2 subnets privés dans 2 AZ (DB subnet group) — VPC
• EC2 ou CloudShell pour tester psql / mysql client
• Profil lab

Coût estimé : ÉLEVÉ pour un lab — même db.t4g.micro facture stockage + heures. Multi-AZ ≈ double compute + stockage ; snapshots manuels oubliés continuent de facturer après delete.
Consigne : créez → testez connexion → delete avec skip-final-snapshot dans l’heure. Activez pause/stop si dispo pour dev, sinon delete. Posez une alarme Billing CloudWatch dès le premier lab RDS.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1

Ce que nous allons construire

VPC
├── DB Subnet Group (private AZ-a + AZ-b)
├── SG lab-db : 5432/3306 depuis SG app seulement
└── RDS PostgreSQL db.t4g.micro
    ├── storage gp3 chiffré
    └── endpoint …rds.amazonaws.com

(Schéma — alt : « RDS privé Multi-AZ capable derrière SG app ».)

Étape 1 — RDS vs self-managed sur EC2

	RDS	EC2 + Postgres
Patches / backups	Gérés	À vous
Multi-AZ failover	Case à cocher	DIY
Accès OS	Non (sauf custom/EC2)	Oui
Coût ops	Plus service	Plus temps

Aurora = moteur AWS compatible MySQL/Postgres, scaling storage différent — hors lab minimal.

Étape 2 — DB subnet group

VPC_ID=$(aws ec2 describe-vpcs --filters Name=tag:Name,Values=lab-vpc 
  --query 'Vpcs[0].VpcId' --output text)
# fallback default VPC si lab-vpc absent — mais préférez subnets privés

SUB_A=subnet-aaa   # private AZ a
SUB_B=subnet-bbb   # private AZ b

aws rds create-db-subnet-group 
  --db-subnet-group-name lab-db-subnets 
  --db-subnet-group-description "lab" 
  --subnet-ids "$SUB_A" "$SUB_B"

Sans 2 AZ, Multi-AZ et même certaines créations échouent.

Étape 3 — Security Group base

SG_DB=$(aws ec2 create-security-group 
  --group-name lab-db-sg --description "RDS from app" 
  --vpc-id "$VPC_ID" --query GroupId --output text)

SG_APP=$(aws ec2 describe-security-groups 
  --filters Name=group-name,Values=lab-app-sg 
  --query 'SecurityGroups[0].GroupId' --output text)

# PostgreSQL
aws ec2 authorize-security-group-ingress --group-id "$SG_DB" 
  --protocol tcp --port 5432 --source-group "$SG_APP"
# MySQL : port 3306

Jamais 0.0.0.0/0 sur 5432/3306 en lab durable.

Security groups : bonnes pratiques RDS

Le SG de la base n’autorise que le tier applicatif (--source-group), pas un CIDR large :

• si l’IP privée de l’EC2 change, la règle reste valide ;
• audit clair (« app → DB ») vs un /16 opaque ;
• en prod, SG bastion/SSM séparé pour l’admin ponctuel.

Outbound : défaut OK sauf zero-trust strict (RDS joint KMS, CloudWatch, S3). N’ouvrez jamais 5432/3306 depuis Internet : SSM Session Manager ou bastion VPC.

aws ec2 describe-security-groups --group-ids "$SG_DB" 
  --query 'SecurityGroups[0].IpPermissions'

Étape 4 — Créer l’instance RDS (Postgres)

# Mot de passe lab UNIQUEMENT — ne pas committer ; utilisez Secrets Manager en prod
MASTER_PW='LabOnly-ChangeMe-16chars'

aws rds create-db-instance 
  --db-instance-identifier lab-pg-01 
  --db-instance-class db.t4g.micro 
  --engine postgres 
  --engine-version 16.4 
  --master-username labadmin 
  --master-user-password "$MASTER_PW" 
  --allocated-storage 20 
  --storage-type gp3 
  --storage-encrypted 
  --vpc-security-group-ids "$SG_DB" 
  --db-subnet-group-name lab-db-subnets 
  --no-publicly-accessible 
  --backup-retention-period 1 
  --no-multi-az 
  --tags Key=Name,Value=lab-pg-01

Ajustez --engine-version via aws rds describe-db-engine-versions --engine postgres.
--no-multi-az pour limiter le coût lab ; en prod web critique → Multi-AZ.

Coût Multi-AZ (à connaître avant d’activer)

Multi-AZ déploie un standby synchrone dans une autre AZ. Facturation typique :

Poste	Single-AZ (lab)	Multi-AZ
Compute (db.t4g.micro, etc.)	1× instance	~2× (primary + standby)
Stockage gp3 alloué	1×	2× (répliqué)
Failover RTO	minutes / restore	bascule DNS auto (souvent 60–120 s)

Pour un lab d’une heure, restez en Single-AZ : le double compute + stockage vide vite le budget. En prod transactionnelle, Multi-AZ est le défaut raisonnable. Activation ultérieure : modify-db-instance --multi-az (fenêtre de maintenance, bref impact possible).

Attendez available (souvent 5–15 min) :

aws rds describe-db-instances --db-instance-identifier lab-pg-01 
  --query 'DBInstances[0].{Status:DBInstanceStatus,Endpoint:Endpoint}'

Étape 5 — Connexion test

Depuis une EC2 dans SG_APP (même VPC) :

sudo dnf install -y postgresql15
psql "host=ENDPOINT port=5432 dbname=postgres user=labadmin sslmode=require"

MySQL équivalent : --engine mysql, port 3306, client mysql.

Paramètres : rds.force_ssl / groupes de paramètres — aperçu SA : Parameter groups vs Option groups (MySQL).

Étape 6 — Backups, Multi-AZ, Read Replica (théorie)

Feature	Rôle
Automated backups	Point-in-time recovery (rétention N jours)
Manual snapshot	Avant changement risqué
Multi-AZ	Standby synchrone autre AZ (failover)
Read replica	Lecture scale (async) ; promo possible
Storage autoscaling	Évite « storage full »

Failover Multi-AZ ≠ scaling lecture : le endpoint writer reste, DNS bascule.

Backups automatiques et snapshots (détail utile)

Avec --backup-retention-period 1 (lab), RDS offre le point-in-time recovery (PITR) sur 1 jour : restauration à la seconde près vers un nouvel identifiant. En prod, 7 jours est un minimum courant ; le stockage de backup au-delà de l’allocation (≈ taille de l’instance) est facturé.

• Automated backup : snapshot quotidien + logs de transactions ; fenêtre BackupWindow hors pics métier.
• Manual snapshot : persiste jusqu’à delete explicite — facture même après suppression de l’instance.
• --skip-final-snapshot au delete lab : évite un snapshot orphelin ; en prod, préférez un final snapshot nommé.

aws rds create-db-snapshot 
  --db-instance-identifier lab-pg-01 
  --db-snapshot-identifier lab-pg-01-pre-change

PITR : restore-db-instance-to-point-in-time (--restore-time ISO8601) crée une nouvelle instance — rebranchez SG, subnet group et endpoint côté appli.

Étape 7 — Vérification

aws rds describe-db-instances --db-instance-identifier lab-pg-01 
  --query 'DBInstances[0].{Class:DBInstanceClass,Eng:Engine,Pub:PubliclyAccessible,Enc:StorageEncrypted,Multi:MultiAZ}'

Checklist : available · PubliclyAccessible=false · encrypted · SG depuis app only · connexion SSL OK · plan de delete prêt.

Stop vs delete (instances compatibles)

Certaines classes permettent stop temporaire (pas de compute, stockage toujours facturé). Ce n’est pas un substitut au delete de fin de lab : le stockage + snapshots restent. Pour zéro surprise : delete-db-instance.

Nettoyage (critique)

aws rds delete-db-instance 
  --db-instance-identifier lab-pg-01 
  --skip-final-snapshot 
  --delete-automated-backups

# attendre deleted, puis :
aws rds delete-db-subnet-group --db-subnet-group-name lab-db-subnets
aws ec2 delete-security-group --group-id "$SG_DB"

Vérifiez qu’il ne reste aucune instance RDS ni snapshot manuel oublié.

Erreurs fréquentes

Symptôme	Cause	Correction
Create fail subnet group	1 AZ only	2 subnets / 2 AZ
Timeout connexion	SG / public access / mauvais subnet	SG source app ; privately accessible + bastion/SSM
Facture élevée	Instance oubliée	Delete + alarmes billing
Password rejected	Complexité	8+ car. mixed

Maintenance windows & upgrades

RDS applique patches dans une fenêtre de maintenance. Minor upgrades peuvent être auto ; major = planifié (rupture possible). En Multi-AZ, le failover réduit le downtime visible mais ne dispense pas de tester l’appli.

Storage : gp3 vs io1/io2

Pour un lab, gp3 20 Go suffit. Les workloads OLTP intenses peuvent exiger IOPS provisionnés (io2). Autoscaling storage évite l’état storage-full qui rend l’instance read-only.

Secrets Manager (prod)

En production : rotation automatique du master secret, pas de mot de passe en clair dans le shell history. Pour le lab, variable d’environnement jetable suffit si vous nettoyez l’historique.

Enhanced Monitoring & Performance Insights

Options payantes pour métriques OS et analyse SQL. En lab, CloudWatch basique suffit ; pour l’examen, sachez que Performance Insights aide à trouver les waits SQL sans accès OS.

Parameter groups (aperçu lab)

Les DB parameter groups contrôlent max_connections, shared_buffers, rds.force_ssl, etc. Le groupe default.postgres16 est en lecture seule : pour forcer SSL ou tuner, créez un custom parameter group, associez-le (modify-db-instance), et acceptez un éventuel reboot.

aws rds create-db-parameter-group 
  --db-parameter-group-name lab-pg16-params 
  --db-parameter-group-family postgres16 
  --description "lab force ssl"
# aws rds modify-db-parameter-group --db-parameter-group-name lab-pg16-params 
#   --parameters "ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=pending-reboot"

En lab court, le défaut suffit ; retenez pour l’examen : Parameter group (moteur) ≠ Option group (MySQL : audit, memcached…).

Lab bonus (5–8 min) — endpoint + modify storage

Quand le statut est available :

EP=$(aws rds describe-db-instances --db-instance-identifier lab-pg-01 
  --query 'DBInstances[0].Endpoint.Address' --output text)
echo "Endpoint: $EP"
# Exemple d’évolution (fenêtre / reboot possible) — à éviter si vous delete tout de suite :
# aws rds modify-db-instance --db-instance-identifier lab-pg-01 
#   --allocated-storage 30 --apply-immediately
aws rds describe-db-instances --db-instance-identifier lab-pg-01 
  --query 'DBInstances[0].{AZ:AvailabilityZone,Subnets:DBSubnetGroup.Subnets[*].SubnetAvailabilityZone.Name}'

Objectif : confirmer endpoint DNS *.rds.amazonaws.com, AZ, et que le subnet group couvre ≥ 2 AZ. Puis enchaînez le nettoyage — ne laissez pas un modify inutilisé facturer plus longtemps.

Scénario examen classique

« Une application e-commerce critique doit survivre à la perte d’une AZ ; les lectures reporting peuvent tolérer un léger retard. » → RDS Multi-AZ pour la HA du writer + Read Replica (async) pour le reporting — pas confondre replica et standby Multi-AZ. Si la question exige scale lecture quasi illimité + storage auto : envisager Aurora. Accès Internet direct à la base = anti-pattern → privée + bastion/SSM.

Checklist lab anti-facture RDS

1. Minuteur dès create-db-instance (même db.t4g.micro + 20 Go gp3 = coût réel).
2. Tags Name + DeleteAfter ; alarme Billing CloudWatch avant le lab.
3. --no-multi-az + retention 1 jour en lab ; pas de Read Replica « pour tester ».
4. Delete : --skip-final-snapshot --delete-automated-backups puis subnet group + SG.
5. Vérifier qu’aucun snapshot manuel lab-pg-* ne traîne (facture Go-mois).

Quiz (5 questions)

1. Multi-AZ RDS sert surtout à : – A. Doubler le débit lecture automatiquement
– B. Haute dispo (standby autre AZ)
– C. Remplacer les backups

2. Une base lab devrait être : – A. 0.0.0.0/0 sur 5432
– B. Privée, SG depuis le tier app
– C. Forcément Aurora Global

3. Après un lab RDS, la première action : – A. Laisser tourner pour Warm Standby
– B. Delete (skip final snapshot en lab)
– C. Activer Public access

4. Un DB subnet group RDS exige en pratique : – A. Un seul subnet public
– B. Des subnets dans au moins 2 AZ
– C. Un Transit Gateway obligatoire

5. Un Read Replica RDS sert surtout à : – A. Remplacer les automated backups
– B. Scaler les lectures (réplication async)
– C. Ouvrir la base sur Internet

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

Pour aller plus loin

• Amazon RDS
• Multi-AZ
• Security groups
• Parameter groups
• Read replicas

Maillage série AWS (P1)

← Précédent	AMI & user-data
→ Suivant	DynamoDB bases
Aussi	VPC · SG

---

Meta publication (SEO)

• Title SEO : AWS RDS MySQL/PostgreSQL : lab privé (2026)
• Meta description : Créez RDS PostgreSQL en subnets privés, SG restrictif, backups et nettoyage anti-facture. ca-central-1.
• Focus keyword : AWS RDS tutoriel
• Image mise en avant : assets/web/devopelastichayway/cover-aws-rds-mysql-postgres-1200x630.webp (Visuels AWS — WebP 1200×630)
• Catégorie : AWS · Niveau : Intermédiaire