Capacité On-Demand vs Provisionnée dans DynamoDB
DynamoDB facture le débit de deux façons. On-Demand facture à la requête — tu paies pour ce que tu utilises, avec une mise à l'échelle jusqu'à zéro. Provisionné réserve un taux fixe de lecture/écriture que tu paies que tu l'utilises ou non, à un prix par unité bien plus bas. Choisir le mauvais mode est l'un des moyens les plus faciles de trop payer.
Le journal d'audit rend le choix concret. Les écritures d'audit sont en pics et imprévisibles : calmes pendant 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. Cette forme de trafic est toute la décision.
Devrais-je utiliser la capacité On-Demand ou Provisionnée de DynamoDB ?
On-Demand facture à la requête et se met à l'échelle jusqu'à zéro, ce qui en fait le choix sûr par défaut pour un trafic en pics, nouveau ou imprévisible. Provisionné réserve un taux fixe de lecture/écriture à un prix par unité bien plus bas, et ne l'emporte que lorsqu'un trafic soutenu et régulier maintient cette réservation bien utilisée. Choisis 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 se produit.
- Provisionné = réserve un taux régulier, paie-le toujours. Bien moins cher par unité si le taux est bien utilisé ; tu assumes le coût de la capacité inutilisée.
- Un trafic en pics ou inconnu appelle On-Demand. Un trafic régulier, prévisible et à fort volume appelle Provisionné (éventuellement avec de l'auto-scaling).
- Tu peux changer de mode, mais la limite est asymétrique : Provisionné vers On-Demand est plafonné à quatre fois par 24 heures, tandis que On-Demand vers Provisionné est illimité — ce n'est pas un interrupteur par requête.
Le problème : payer pour une capacité que tu n'utilises pas
Avec la capacité Provisionnée, tu t'engages sur, disons, 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 tu en utilises un vingtième. Provisionne pour la moyenne à la place et le déluge du jour d'incident est ralenti — les écritures sont rejetées.
Une capacité fixe force donc un mauvais compromis sur un trafic en pics : trop payer en permanence, ou sous-provisionner et perdre des écritures au pire moment. On-Demand existe précisément pour supprimer ce compromis.
Comment fonctionnent les deux modes
On-Demand facture les unités de requête en lecture et en écriture que tu consommes réellement, sans capacité à configurer — il absorbe instantanément les pics jusqu'au double de ton précédent pic de trafic et se met à l'échelle jusqu'à zéro au repos. Au-delà de ce bond de 2x dans une courte fenêtre, il peut quand même ralentir pendant qu'il monte en charge. Tu paies une prime par requête pour cette élasticité.
Provisionné réserve un nombre d'unités de capacité de lecture (RCU) et d'unités de capacité d'écriture (WCU) par seconde. Le prix par unité 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 des bornes configurées — même si l'auto-scaling réagit sur plusieurs minutes, un pic soudain peut donc encore ralentir 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é Provisionnée bien utilisée, Provisionné l'emporte sur le prix ; si le trafic est en pics, en rafales ou inconnu, On-Demand l'emporte en ne facturant pas la réservation inutilisée.
Un exemple concret : la facture du journal d'audit
Le journal d'audit écrit environ 50 événements/seconde en moyenne mais monte à des milliers pendant les incidents, avec un trafic de lecture bien plus faible (exports de conformité, l'enquête occasionnelle). Chaque événement est petit — bien en dessous de 1 KB.
En Provisionné, tu devrais réserver pour la rafale (en la payant 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 une rafale jusqu'au double du pic récent est absorbée sans configuration ; tu paies exactement les écritures qui ont eu lieu.
Pour cette charge de travail, On-Demand est la bonne valeur par défaut. La règle générale : commence sur On-Demand pour toute table nouvelle ou en pics, et ne passe à Provisionné qu'une fois que le trafic est prouvé suffisamment régulier pour maintenir une réservation utilisée.
Entre 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 multi-régions complet avec l'offre gratuite appliquée, 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 cela, c'est ainsi que les tables finissent mal provisionnées.
Pour convertir un événement d'exemple en RCU/WCU qu'il consomme réellement, passe-le dans le calculateur de taille d'item. Puis ancre la décision dans ta vraie table : DynoTable fait remonter ses métadonnées — nombre et taille d'items — et te laisse inspecter des items représentatifs pour que tu puisses les dimensionner avec précision.
Pièges et étapes suivantes
- Changer de mode est limité en fréquence, et de façon asymétrique. Provisionné vers On-Demand est plafonné à quatre changements par 24 heures ; On-Demand vers Provisionné est illimité. 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 sur plusieurs minutes, donc un pic net sur Provisionné peut ralentir avant que la capacité n'augmente. Pour un trafic vraiment en rafales, On-Demand gère mieux le pic — jusqu'au double de ton précédent pic instantanément. Si tu sais qu'un pic dépassera cela (un lancement ou une promotion), configure le warm throughput sur la table à l'avance pour pré-provisionner la marge de rafale.
- Une partition surchargée ralentit quel que soit le mode. Même On-Demand a des limites par partition — des clés inégales peuvent ralentir alors que la table paraît sous-capacité. Voir les partitions surchargées.
- Les 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 les tables globales DynamoDB.
Télécharge DynoTable pour lire la taille et le nombre d'items réels de ta table avant de t'engager sur un mode de capacité.