Capacité On-Demand vs Provisioned dans DynamoDB
DynamoDB facture le débit de deux façons. En On-Demand, tu paies à la requête — tu paies ce que tu utilises, avec une mise à l'échelle jusqu'à zéro. En Provisioned, tu réserves un taux de lecture/écriture fixe que tu paies, que tu l'utilises ou non, à un prix unitaire bien plus bas. Choisir le mauvais est l'un des moyens les plus faciles de payer trop cher.
Le journal d'audit rend le choix concret. Les écritures d'audit sont en pics et imprévisibles : calmes la nuit, puis un déluge quand un client lance une opération en masse ou qu'un incident génère des milliers d'événements. C'est cette forme de trafic qui détermine toute la décision.
Dois-je utiliser la capacité On-Demand ou Provisioned dans DynamoDB ?
L'On-Demand facture à la requête et se met à l'échelle jusqu'à zéro, ce qui en fait le choix par défaut sûr pour un trafic en pics, nouveau ou imprévisible. Le Provisioned réserve un taux de lecture/écriture fixe à un prix unitaire bien plus bas, et ne l'emporte que si un trafic soutenu et régulier maintient cette réservation bien utilisée. Choisis l'On-Demand, sauf si ton volume est prouvé et prévisible.
- On-Demand = paiement à la requête, mise à l'échelle jusqu'à zéro. Aucune capacité à planifier ; tu paies un prix plus élevé par lecture/écriture mais seulement quand le trafic arrive.
- Provisioned = réserve un taux constant, paie-le en permanence. Bien moins cher à l'unité si le taux est bien utilisé ; tu absorbes le coût de la capacité inactive.
- Trafic en pics / inconnu → On-Demand. Trafic constant, prévisible, à fort volume → Provisioned (éventuellement avec auto-scaling).
- Tu peux changer de mode, mais seulement un nombre limité de fois par tranche de 24 heures — ce n'est pas un interrupteur à la requête.
Le problème : payer pour une capacité que tu n'utilises pas
Avec la capacité Provisioned, tu t'engages, disons, sur 1 000 unités d'écriture par seconde. Si le journal d'audit fait en moyenne 50 écritures/seconde mais que tu as provisionné pour le pic du jour d'incident, tu paies pour 1 000 en continu et n'en utilises qu'un vingtième. Provisionne pour la moyenne à la place et le déluge du jour d'incident est ralenti (throttling) — les écritures sont rejetées.
Donc une capacité fixe impose un mauvais compromis sur un trafic en pics : payer trop en permanence, ou sous-provisionner et perdre des écritures quand ça compte le plus. L'On-Demand existe précisément pour supprimer ce compromis.
Comment fonctionnent les deux modes
L'On-Demand facture les unités de requête de lecture et d'écriture que tu consommes réellement, sans capacité à configurer — il absorbe instantanément les pics de trafic et se met à l'échelle jusqu'à zéro quand il est inactif. Tu paies un surcoût par requête pour cette élasticité.
Le Provisioned réserve un certain nombre d'unités de capacité de lecture (RCU) et d'unités de capacité d'écriture (WCU) par seconde. Le prix unitaire est bien plus bas, mais tu paies la réservation en continu, utilisée ou non. Dépasse-la et DynamoDB ralentit, sauf si l'auto-scaling est activé pour augmenter la capacité dans les limites configurées — bien que l'auto-scaling réagisse en minutes, donc un pic soudain peut quand même provoquer du throttling avant qu'il ne rattrape.
Le point de bascule, c'est l'utilisation. Grosso modo : si ton trafic soutenu et prévisible maintient la capacité Provisioned bien utilisée, le Provisioned gagne sur le prix ; si le trafic est en pics, en rafales ou inconnu, l'On-Demand gagne en ne te facturant pas pour une réservation inactive.
Un exemple concret : la facture du journal d'audit
Le journal d'audit écrit ~50 événements/seconde en moyenne mais grimpe à des milliers pendant les incidents, avec un trafic de lecture bien plus faible (exports de conformité, l'occasionnelle investigation). Chaque événement est petit — bien en dessous de 1 Ko.
En Provisioned, tu devrais réserver pour la rafale (et la payer 24h/24) ou risquer de ralentir le déluge du jour d'incident — le pire moment pour perdre des écritures d'audit. En On-Demand, les heures calmes ne coûtent presque rien et la rafale est absorbée automatiquement ; tu paies pour exactement les écritures qui ont eu lieu.
Pour cette charge de travail, l'On-Demand est le bon défaut. La règle générale : commence en On-Demand pour toute table nouvelle ou en pics, et ne passe au Provisioned qu'une fois le trafic prouvé assez constant pour garder une réservation utilisée.
Branche tes propres chiffres — lectures/écritures par seconde, taille d'item, stockage — pour voir les deux modes côte à côte pour une région :
Pour le tableau complet multi-régions avec le free tier appliqué, utilise le calculateur de tarifs DynamoDB.
Fais-le dans DynoTable
La décision de capacité part de chiffres réels : quelle est la taille des items, combien y en a-t-il, à quelle vitesse sont-ils écrits. Deviner ces valeurs, c'est comme ça que les tables finissent mal provisionnées.
Pour convertir un événement échantillon en la RCU/WCU qu'il consomme réellement, fais-le passer par le calculateur de taille d'item. Ancre ensuite la décision dans ta vraie table : DynoTable expose ses métadonnées — nombre et taille des items — et te laisse inspecter des items représentatifs pour les dimensionner avec précision.
Pièges et étapes suivantes
- Le changement de mode est limité en fréquence. Tu peux passer d'On-Demand à Provisioned, mais seulement un nombre limité de fois par tranche de 24 heures — traite-le comme une décision réfléchie, pas un bouton que tu tournes.
- L'auto-scaling n'est pas instantané. Il réagit en minutes, donc un pic brusque en Provisioned peut provoquer du throttling avant que la capacité n'augmente. Pour un trafic réellement en rafales, l'On-Demand absorbe le pic directement.
- Une partition chaude provoque du throttling quel que soit le mode. Même l'On-Demand a des limites par partition — des clés déséquilibrées peuvent ralentir alors que la table semble sous-capacité. Voir partitions chaudes.
- Les GSI ont leur propre capacité. Chaque index est facturé séparément et peut ralentir les écritures de la table de base s'il est sous-provisionné — voir pourquoi un GSI ralentit les écritures de la table de base.
Le mode de capacité fixe ce que tu paies pour faire tourner la table dans une région. Ensuite : la répliquer entre régions avec DynamoDB Global Tables.
Télécharge DynoTable pour lire la taille réelle et le nombre d'items de ta table avant de t'engager sur un mode de capacité.