RDS provisionné facture à l'heure d'instance et récompense la charge stable, surtout avec la tarification réservée. Aurora Serverless v2 facture à l'ACU-seconde et convient à la charge variable qui n'est presque jamais totalement à l'arrêt. DynamoDB on-demand facture à la requête et gagne sur le trafic en pics à moyenne faible. Faites correspondre votre courbe de trafic au profil de coût, pas à la page marketing.
Quels sont les trois profils de coût ?
RDS provisionné facture la capacité à l'heure d'instance, qu'elle serve ou non. Aurora Serverless v2 facture à l'ACU-seconde, une Aurora Capacity Unit étant une tranche de calcul et de mémoire, entre un plancher et un plafond que vous fixez. DynamoDB on-demand facture à la requête, sans aucune notion de capacité.
Toute la comparaison découle de ces unités. Une instance à l'heure est un coût fixe avec un plafond de performance rigide. Les ACU-secondes suivent votre courbe de charge, dans des limites détaillées plus bas. La facturation à la requête suit l'usage au plus près : zéro requête, zéro coût de débit, stockage mis à part. Les tarifs bougent, les profils rarement ; nous renvoyons donc aux pages officielles de tarification Aurora et de tarification DynamoDB plutôt que de citer des chiffres qui vieilliraient mal.
Pourquoi Aurora Serverless v2 a-t-il un plancher de coût à vide ?
Parce que l'ACU minimum que vous configurez ne dort jamais par défaut. Aurora Serverless v2 redescend jusqu'à son plancher, pas jusqu'à zéro : un cluster inactif tout le week-end facture sa capacité minimale chaque seconde. Ici, serverless signifie élastique dans une plage, pas paiement à l'usage.
Ce plancher a une raison d'être : la capacité minimale garde le buffer pool chaud et absorbe les premières secondes d'un pic, le temps que la montée en charge suive. Trop bas, les premières requêtes de chaque rafale paient en latence ; trop haut, vous avez acheté une instance provisionnée avec des étapes en plus. La plage de capacité est le seul réglage que ce modèle vous demande, et la documentation sur les réglages de capacité explique comment les deux bornes interagissent avec la vitesse de montée en charge.
Qu'a changé la mise en pause à zéro en 2024 ?
Depuis fin 2024, Aurora Serverless v2 peut se mettre en pause à zéro ACU : fixez le minimum à 0 et le calcul se suspend après une période d'inactivité configurable. Le stockage reste facturé, et la première connexion après une pause attend la reprise, de l'ordre de quinze secondes, parfois plus.
Ce compromis est excellent pour le développement, la préproduction et les outils internes inactifs la majeure partie de la journée, et presque toujours mauvais pour une API de production avec un budget de latence. Le support dépend des versions de moteur et les temps de reprise varient selon la charge : vérifiez les détails dans la documentation à jour plutôt que de les supposer. L'essentiel pour le raisonnement de coût : si la pause automatique est acceptable, le plancher à vide d'Aurora tombe au seul stockage, ce qui déplace son point d'équilibre face à DynamoDB pour des données relationnelles rarement sollicitées.
Vous hésitez sur le profil de coût qui correspond vraiment à votre courbe de trafic ? Décrivez votre système : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →Quand RDS provisionné avec tarification réservée gagne-t-il ?
Quand l'utilisation est élevée et prévisible. Une instance provisionnée est la façon la moins chère d'acheter de la capacité réellement utilisée en continu, et les instances réservées la remisent davantage contre un engagement d'un ou trois ans. La charge stable est exactement ce pour quoi le profil horaire a été tarifé.
Le point d'équilibre est un ratio, pas un montant en dollars. Prenez le coût horaire des ACU que votre charge consomme en moyenne, divisez-le par le coût horaire d'une instance provisionnée à mémoire équivalente : la capacité serverless porte une prime par unité, donc au-delà d'un certain taux d'utilisation moyen l'instance provisionnée gagne, et la tarification réservée abaisse encore ce seuil. Faites le calcul avec les tarifs actuels des pages liées plus haut ; l'arithmétique des articles de blog vieillit mal, la nôtre comprise.
Quand DynamoDB on-demand gagne-t-il ?
Quand le trafic est en pics et la moyenne faible. La facturation à la requête signifie qu'une table inactive ne coûte que son stockage, et que les rafales sont absorbées sans planification de capacité. Avec un fort ratio pic sur moyenne, les deux profils relationnels imposent un choix : payer pour le pic, ou faire la queue derrière un plancher dimensionné pour la moyenne.
Deux réserves. D'abord, les tarifs on-demand ont été nettement réduits fin 2024, ce qui a déplacé le point d'équilibre en faveur de DynamoDB pour beaucoup de charges en pics ; fiez-vous à la page de tarification actuelle plutôt qu'à d'anciennes comparaisons. Ensuite, rien de tout cela ne compte si vos schémas d'accès ne rentrent pas dans le modèle de DynamoDB. Nous avons traité cette décision dans notre guide DynamoDB ou RDS pour backends serverless ; cet article suppose la question de modélisation réglée, seule la facture restant en débat.
Quel profil de coût pour quel profil de trafic ?
Le coût à vide et le comportement en pic sont les discriminants. RDS provisionné gagne sur la charge stable à forte utilisation. Aurora Serverless v2 gagne sur la charge relationnelle variable avec un vrai socle. DynamoDB on-demand gagne sur le trafic en pics à moyenne faible quand le modèle de données convient. Le tableau condense toute la comparaison en cinq lignes.
| Aurora Serverless v2 | RDS provisionné | DynamoDB on-demand | |
|---|---|---|---|
| Unité de facturation | ACU-seconde | Heure d'instance | À la requête, plus stockage |
| Coût à vide | Plancher d'ACU minimum (stockage seul si la pause automatique est acceptable) | Plein tarif de l'instance, en permanence | Stockage seul |
| Comportement en pic | Montée en charge en secondes, jusqu'au plafond d'ACU | Plafond fixe ; grandir signifie redimensionner ou ajouter des réplicas | Absorbé requête par requête, dans les limites de la table |
| Charge d'exploitation | Faible : une plage de capacité à régler | La plus élevée : dimensionnement, redimensionnements, fenêtres de maintenance | La plus faible : aucune capacité à gérer |
| Quand il gagne | Charge relationnelle variable avec un vrai socle | Utilisation stable et élevée, engagement réservé | Trafic en pics à moyenne faible qui rentre dans le modèle |
Lisez les colonnes comme des défauts, pas comme des verdicts : un hybride (un writer provisionné avec des readers serverless dans le même cluster, ou DynamoDB à côté d'un cœur relationnel) est souvent la réponse honnête.
La checklist de décision
Cinq questions avant de vous engager :
- Tracez une semaine de trafic. Courbe plate à forte utilisation : RDS provisionné, puis chiffrez l'engagement réservé.
- Courbe variable avec un socle régulier : Aurora Serverless v2, plancher dimensionné pour le socle, plafond pour le pire pic.
- Pics avec une moyenne faible, et des schémas d'accès compatibles : DynamoDB on-demand.
- Environnements inactifs (dev, préproduction, outils internes) : Aurora avec pause automatique, si une reprise à froid est acceptable.
- Quel que soit le choix, refaites le calcul de ratio avec les pages de tarification du jour, pas avec les articles de l'an dernier.
Le trafic réel est rarement aussi net que le tableau. Notre offre d'architecture AWS commence chaque mission par le tracé de votre courbe avant de nommer une base de données.