DynamoDB peut-il monter en charge automatiquement ?
Oui. L'auto-scaling DynamoDB s'appuie sur Application Auto Scaling pour ajuster la capacité de lecture et d'écriture provisionnée vers un taux d'utilisation cible (réglable de 20 à 90 %, souvent 70 %), à l'intérieur de bornes min/max que tu définis. Autre voie : le mode de capacité à la demande, qui suit le trafic instantanément sans aucune configuration. Les deux gardent les tables réactives face à une charge changeante, sans planification manuelle de capacité.
Auto-scaling en capacité provisionnée
Tu crées une politique de scaling par table (et par index secondaire global) qui définit :
- un taux d'utilisation cible (pourcentage de la capacité provisionnée à viser),
- les unités de capacité minimale et maximale, et
- si le scaling porte sur les lectures, les écritures ou les deux.
Des alarmes CloudWatch déclenchent Application Auto Scaling pour augmenter ou réduire la capacité à mesure que la consommation franchit la cible.
Mode à la demande
La capacité à la demande supprime complètement la planification : DynamoDB ajuste le débit à ton trafic tout seul — en absorbant instantanément jusqu'au double de ton précédent pic de trafic — et te facture à la requête. C'est un bon choix quand le trafic est en pics ou difficile à prévoir.
Lequel choisir
Le mode provisionné avec auto-scaling coûte généralement moins cher quand le trafic est stable et bien connu ; le mode à la demande est plus simple et préférable pour un trafic inconnu ou en pics.
Là où le taux d'utilisation cible cesse d'être rentable
Le taux d'utilisation cible est un curseur de prix, et il a un plancher sous lequel l'auto-scaling perd d'emblée face au mode à la demande.
Dans us-east-1, une unité de capacité d'écriture coûte 0,00065 $ de l'heure : en réserver une pour un mois revient donc à 0,4745 $ et achète 2 628 000 écritures. Soit 0,00000018 $ par écriture, contre 0,000000625 $ à la demande — la capacité provisionnée est donc 3,46 fois moins chère quand chaque unité réservée est utilisée. Inverse le rapport et tu obtiens le point d'équilibre : le provisionné cesse d'être rentable en dessous de 28,9 % d'utilisation moyenne. Les lectures aboutissent aux mêmes 28,9 %, ce qui fait de ce chiffre une propriété du modèle tarifaire plutôt que d'un tarif particulier.
Pour 1 000 écritures par seconde soutenues sur des éléments de 1 Ko, chiffrées avec le calculateur de tarifs :
| Réglage de capacité | Provisionné | Mensuel |
|---|---|---|
| Cible 90 % | 1 112 WCU | 527,64 $ |
| Cible 70 % | 1 429 WCU | 678,06 $ |
| Cible 50 % | 2 000 WCU | 949,00 $ |
| Cible 20 % | 5 000 WCU | 2 372,50 $ |
| À la demande | aucun | 1 642,50 $ |
Les deux dernières lignes portent la leçon. Une cible de 20 %, la plus basse qu'AWS accepte, réserve cinq fois ton trafic et coûte 44 % de plus que payer à la requête pour un travail identique. Chaque ligne ci-dessus suppose que l'auto-scaling épingle la capacité exactement sur la cible : traite-les donc comme des cas idéaux, car le trafic réel vagabonde et l'algorithme le suit en retard, ce qui tire l'utilisation réalisée sous ce que tu as configuré.
Ce que le curseur achète
La montée et la descente en charge sont délibérément asymétriques, et c'est cette asymétrie que paie la marge. AWS documente une montée déclenchée après que la capacité consommée dépasse la cible pendant deux minutes consécutives, et une descente après 15 points de données consécutifs en dessous. L'appel UpdateTable qui suit prend plusieurs minutes de plus, et tout ce qui dépasse l'ancien plafond est throttlé pendant ce temps.
Les baisses sont rationnées elles aussi. Tu commences chaque journée UTC avec quatre et tu en gagnes une par heure, sans jamais en détenir plus de quatre, ce qui te plafonne à 27 par jour et par table. Les index secondaires globaux ont leur propre quota.
Une cible haute économise donc de l'argent réel et dépense le tampon qui couvre ces minutes. Le mode à la demande coûte plus cher par requête et supprime entièrement l'arbitrage.
Aller plus loin
Compare-les dans capacité à la demande vs provisionnée et estime le coût avec le calculateur de tarifs. Télécharge DynoTable pour lire la taille d'une table et ses estimations d'éléments dans Stats de table.
Références
- Managing throughput capacity automatically with DynamoDB auto scaling — Amazon DynamoDB Developer Guide
- DynamoDB on-demand capacity mode — Amazon DynamoDB Developer Guide
- DynamoDB provisioned capacity mode — Amazon DynamoDB Developer Guide
- Quotas in Amazon DynamoDB — Amazon DynamoDB Developer Guide — le quota de baisses, revérifié le 2026-07-28.
Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.
Point d'équilibre calculé le 2026-07-28 avec notre propre calculateur de tarifs, sur les tarifs us-east-1 qu'il synchronise depuis l'AWS Price List API. Les délais de scaling et le quota de baisses ont été relus dans la documentation AWS liée ci-dessus à la même date.