Aurora ou RDS pour Postgres / MySQL en production — quand la prime se justifie

Ce guide compare Amazon Aurora et Amazon RDS (Relational Database Service) pour les équipes qui exploitent une base de données Postgres ou MySQL en production sur AWS. Les deux font tourner du vrai Postgres ou du vrai MySQL, mais Aurora remplace la couche de stockage par un système distribué et le facture plus cher à l’heure. La question qui revient sans cesse, c’est de savoir si la base de production devrait migrer, et si cette prime achète quelque chose dont vous avez vraiment besoin. Aurora la mérite quand la bascule (le passage à une base de relève quand la principale tombe) doit se faire en quelques secondes, ou quand plusieurs répliques de lecture (des copies qui répondent aux requêtes en lecture seule) portent du vrai trafic. RDS fait très bien le travail pour une charge stable et bien ajustée, et les vérifications plus bas vous permettent de trancher avec vos propres chiffres de bascule, de retard et d’I/O de stockage.

Ce qui se passe

Aurora et RDS partagent la ligne d’engine — les deux exécutent du vrai Postgres ou du vrai MySQL — mais la couche stockage sous-jacente est différente, et cette différence détermine la plupart des propriétés opérationnelles.

Architecture RDS. Une seule instance writer avec un volume EBS attaché. Multi-AZ ajoute une instance standby avec une réplication synchrone bloc-à-bloc via la couche de stockage (pas la réplication Postgres / MySQL). Le basculement permute le endpoint DNS vers le standby. Les read replicas utilisent la réplication native de l’engine (streaming Postgres, binlog MySQL). Le stockage est provisionné (vous choisissez une taille), avec auto-scaling disponible jusqu’à une limite.

Architecture Aurora. Le cluster a un writer et optionnellement jusqu’à 15 instances reader. En dessous, le volume de cluster Aurora — un système de stockage distribué qui garde six copies des données sur trois AZ, avec écritures par quorum (4 sur 6) et lectures par quorum (3 sur 6). Le writer émet des enregistrements de redo log vers la couche stockage, pas des pages de données complètes. Les readers interrogent le même volume partagé ; ils ne rejouent pas de binlog. Le basculement promeut un reader, ce qui est rapide parce que le reader voit déjà le même stockage. Le stockage est facturé au GB utilisé, sans provisioning.

Les conséquences opérationnelles découlent de ces architectures :

Le modèle de stockage Aurora est la différence architecturale qui pilote la proposition de valeur. Parce que les readers voient le même volume physique que le writer, ajouter un reader est une action purement compute — pas de restore complet, pas de temps de chauffage à attendre que le replica rattrape. La même propriété rend le basculement rapide : le reader promu n’a rien à rejouer, il commence simplement à accepter des écritures contre une couche de stockage qu’il lisait déjà.

Les différences par engine importent. Aurora Postgres traîne d’une ou deux versions majeures derrière Postgres standard pour les nouvelles fonctionnalités, mais offre des fonctionnalités Aurora-spécifiques comme Babelfish (protocole TDS pour clients SQL Server), Global Database, parallel query, et un patch de version mineure plus rapide. Aurora MySQL diverge davantage de MySQL upstream — le niveau de compatibilité MySQL 8.0 est la piste actuelle, avec des extensions Aurora-spécifiques et quelques lacunes. Si l’application dépend d’une fonctionnalité Postgres 17 qu’Aurora n’a pas encore intégrée, Aurora n’est pas une option en ce moment.

Aurora Serverless v2 change le profil de coût pour les charges variables. Le cluster met à l’échelle des ACU (Aurora Capacity Units) automatiquement de minimum à maximum, par incréments d’une demi-ACU, sans avoir besoin de couper les connexions. Une charge qui dort la nuit et explose en heures de bureau peut tourner à 1 ACU hors-heures et 16 ACU au pic. Bémol : Serverless v2 facture toujours par ACU-heure à un tarif plus élevé qu’Aurora provisionné, donc une charge qui tourne près du pic la majeure partie de la journée dépense plus en Serverless v2 qu’en provisionné.

Comment vérifier

Deux questions décident la plupart des migrations Aurora-versus-RDS.

Le budget de basculement est-il serré ? Si l’application tolère 60–90 secondes d’indisponibilité en écriture pendant un basculement Multi-AZ, RDS suffit. Si le SLA exige une récupération sous 30 secondes, le basculement plus rapide d’Aurora est matériel. Mesurez le temps de basculement réel sur le RDS existant :

# Forcer un basculement durant une fenêtre de maintenance et mesurer
aws rds reboot-db-instance \
  --db-instance-identifier prod-db-1 \
  --force-failover

Surveillez CloudWatch DatabaseConnections et le taux d’erreur de l’application autour du redémarrage. La fenêtre de la première erreur à la récupération propre est le vrai budget de basculement.

La charge a-t-elle besoin de mise à l’échelle des lectures qui retarde de moins d’une seconde ? Une charge de reporting qui tourne contre un read replica RDS, voit des retards entre 1 et 10 secondes et tolère des données obsolètes, n’a pas besoin d’Aurora. Une charge de reporting qui tourne contre un read replica et a besoin de données quasi temps-réel — typiquement parce que l’application lit-ses-propres-écritures depuis un endpoint différent — bénéficie des readers à retard milliseconde d’Aurora.

Vérifiez le retard read replica sur le RDS existant :

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=prod-db-1-replica \
  --start-time $(date -u -v-7d +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 60 \
  --statistics Maximum \
  --query 'Datapoints[].Maximum' \
  --output text | sort -n | tail -5

Si le pire cas sur une semaine est de 30+ secondes, l’application le tolère (Aurora n’achète rien sur la fraîcheur des lectures) ou non (la réplication plus serrée d’Aurora apporte une valeur réelle).

Vérifiez le profil de coût des I/O stockage sur le RDS actuel. Aurora facture par million d’I/O. Les charges avec I/O très lourd (gros scans séquentiels, updates full-table, opérations vacuum fréquentes) peuvent payer plus de stockage sur Aurora que sur RDS avec gp3 IOPS provisionnés :

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name ReadIOPS \
  --dimensions Name=DBInstanceIdentifier,Value=prod-db-1 \
  --start-time $(date -u -v-30d +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --statistics Sum \
  --query 'Datapoints[].Sum' \
  --output text | paste -sd+ - | bc

Le total d’I/O sur 30 jours, multiplié par le tarif Aurora par million d’I/O dans la région cible, donne la prime de stockage I/O. Pour les charges OLTP (petits I/O aléatoires, mostly buffered) le coût est modeste. Pour des charges analytiques sur la base OLTP, ça peut être la ligne dominante.

La correction

Choisissez Aurora quand au moins deux conditions sont vraies :

• Le temps de basculement fait partie du SLA. La récupération sous 30 secondes est une exigence affirmée, pas un souhait.
• La mise à l’échelle des lectures fait partie de l’architecture. L’application utilise plusieurs read replicas et le retard compte.
• Le stockage est variable. La base croît vite ou rétrécit, et sur-provisionner EBS coûte cher.
• Aurora Global Database est dans la feuille de route. Les read replicas inter-régions avec retard sous-seconde sont Aurora-only.
• La charge est en rafales. Aurora Serverless v2 colle à un pattern pic-journalier / idle-hors-heures.

Choisissez RDS quand :

• La charge est en régime permanent et bien tunée sur une taille d’instance connue.
• L’exigence de version Postgres est plus récente que ce qu’Aurora propose.
• Le calcul du coût I/O sort défavorable sur Aurora.
• Des temps de basculement Multi-AZ de 30–90 secondes sont acceptables.
• L’équipe a un budget serré et la prime Aurora ne se justifie pas par la valeur.

Trois choses qui tournent mal dans les migrations Aurora :

Sous-estimer la ligne per-I/O. Une équipe qui tournait sur RDS avec des IOPS provisionnés a budgété Aurora à compute + storage et a oublié les frais per-I/O. La ligne per-I/O pour une charge OLTP lourde peut représenter 30–50% de la ligne stockage sur Aurora. Utilisez le calcul I/O ci-dessus pour prévoir.

Traiter Aurora comme du drop-in Postgres. Certaines extensions Postgres ne sont pas disponibles sur Aurora ; certains paramètres de configuration sont gérés par Aurora et non tunables côté utilisateur. Faites tourner l’application contre un cluster Aurora de staging avant de vous engager — la revue de la liste d’extensions et du parameter group prend une journée et économise une semaine de débogage post-migration.

Ignorer le rythme de version d’engine. Aurora prend les nouvelles versions majeures de Postgres 6–12 mois après upstream. Un plan de migration qui dépend d’une fonctionnalité Postgres sortie le mois dernier face à la feuille de route Aurora va caler.

La mécanique de migration pour une bascule RDS-vers-Aurora utilise le chemin aws rds restore-db-cluster-from-snapshot (pour du greenfield) ou le chemin promotion-de-replica (pour une migration in-place avec downtime faible). Le chemin read-replica : créer un read replica Aurora de l’instance RDS, le laisser rattraper, le promouvoir durant une fenêtre de maintenance. Le downtime total en écriture est typiquement 30–90 secondes — la même fenêtre qu’un basculement Multi-AZ — en supposant que l’application gère la brève bascule.

Aurora est le choix par défaut pour les nouvelles charges SaaS de production en 2026. RDS est le choix par défaut pour les charges existantes stables où le coût de migration dépasse les bénéfices opérationnels.

Stack Harbor conçoit et opère les topologies RDS / Aurora en production dans le cadre de Gestion AWS et de la couche Environnements infogérés. Si votre posture base de données se résume à « case Multi-AZ cochée + espoir », commencez par une consultation d’infrastructure.