DynamoDB Modes de Capacité : Provisionné vs On-Demand — Quel Choix Pour Votre Application ?

Vous venez de concevoir votre première table DynamoDB et la question du mode de capacité vous bloque : choisir Provisionné sans connaître votre trafic, c'est risquer le throttling à la première montée en charge — choisir On-Demand sans comprendre son modèle de coût, c'est potentiellement payer dix fois plus que nécessaire. Ce choix est l'une des premières décisions d'architecture DynamoDB qui coûte cher quand elle est mal posée.

TL;DR — Comparaison des Modes de Capacité DynamoDB

CritèreProvisionnéOn-Demand
Modèle de facturationPar RCU/WCU réservés à l'heurePar requête consommée (rRCU/rWCU)
Trafic adaptéPrévisible et stableImprévisible ou sporadique
Risque de throttlingOui, si trafic dépasse les unités provisionnéesTrès faible (AWS absorbe les pics)
Auto ScalingDisponible (réactif, pas instantané)Natif et transparent
Coût à fort volumeMoins cher si utilisation > 80%Plus cher à volume élevé constant
Changement de mode autoriséUne fois toutes les 24 heures
Phase idéaleProduction stable, trafic connuDéveloppement, lancement, trafic erratique

Comment Fonctionne la Capacité DynamoDB

DynamoDB distribue vos données sur des partitions internes. Chaque partition a une capacité de traitement allouée, exprimée en RCU (Read Capacity Units) et WCU (Write Capacity Units). Une RCU correspond à une lecture fortement cohérente de 4 Ko, une WCU à une écriture de 1 Ko. Ces unités sont la monnaie d'échange entre votre application et le moteur de stockage.

Le mode de capacité détermine comment ces unités sont allouées et facturées. En mode Provisionné, vous déclarez à l'avance combien d'unités vous réservez par seconde. En mode On-Demand, vous ne déclarez rien — AWS adapte la capacité à la demande observée et vous facture à l'unité consommée.

graph LR App["Application"] --> Router["Routeur DynamoDB"] Router --> P1["Partition 1"] Router --> P2["Partition 2"] Router --> P3["Partition N"] P1 --> ModeP["Mode Provisionné
RCU/WCU fixes"] P1 --> ModeOD["Mode On-Demand
Capacité adaptative"] ModeP --> Throttle["Throttling si dépassement"] ModeOD --> Scale["AWS absorbe le pic"]
  1. Application : émet des requêtes de lecture et d'écriture vers DynamoDB.
  2. Routeur DynamoDB : distribue les requêtes sur les partitions selon la clé de partition.
  3. Mode Provisionné : chaque partition dispose d'un quota RCU/WCU fixe. Si le trafic dépasse ce quota, les requêtes sont throttlées (ProvisionedThroughputExceededException).
  4. Mode On-Demand : AWS ajuste dynamiquement la capacité allouée. Les requêtes ne sont pas throttlées sauf en cas de montée en charge extrêmement brutale dépassant le double du pic précédent sur une courte fenêtre.

Mode Provisionné — Contrôle et Économies au Prix de la Prévision

En mode Provisionné, vous définissez explicitement le nombre de RCU et WCU par seconde pour votre table. Si votre application consomme plus que ce seuil, DynamoDB retourne une erreur de throttling. C'est le mode historique de DynamoDB, et il reste le plus économique quand le trafic est stable et prévisible.

Auto Scaling en Mode Provisionné

L'Auto Scaling DynamoDB ajuste les RCU/WCU provisionnés en fonction de l'utilisation observée, selon une cible d'utilisation que vous définissez (par exemple, 70% d'utilisation). Mais attention : cet ajustement est réactif. Il y a un délai entre la détection du pic et l'application de la nouvelle capacité. Un pic brutal et court peut donc provoquer du throttling même avec l'Auto Scaling activé.

# Créer une table en mode Provisionné avec Auto Scaling
aws dynamodb create-table \
  --table-name ma-table-prod \
  --attribute-definitions AttributeName=PK,AttributeType=S \
  --key-schema AttributeName=PK,KeyType=HASH \
  --billing-mode PROVISIONED \
  --provisioned-throughput ReadCapacityUnits=100,WriteCapacityUnits=50 \
  --region us-east-1

# Activer l'Auto Scaling en lecture sur la table
aws application-autoscaling register-scalable-target \
  --service-namespace dynamodb \
  --resource-id table/ma-table-prod \
  --scalable-dimension dynamodb:table:ReadCapacityUnits \
  --min-capacity 10 \
  --max-capacity 500 \
  --region us-east-1

# Définir la politique de scaling (cible d'utilisation à 70%)
aws application-autoscaling put-scaling-policy \
  --service-namespace dynamodb \
  --resource-id table/ma-table-prod \
  --scalable-dimension dynamodb:table:ReadCapacityUnits \
  --policy-name ReadScalingPolicy \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration \
    'TargetValue=70.0,PredefinedMetricSpecification={PredefinedMetricType=DynamoDBReadCapacityUtilization}' \
  --region us-east-1

Quand le Mode Provisionné est le Bon Choix

  • Trafic stable avec des variations progressives (pas de pics soudains).
  • Volume élevé et constant — le coût par unité est significativement inférieur à On-Demand.
  • Vous pouvez anticiper les besoins via des métriques historiques CloudWatch.
  • Workloads batch planifiés avec des fenêtres de traitement connues.

Mode On-Demand — Simplicité et Résilience aux Pics

En mode On-Demand, vous ne provisionnez rien. DynamoDB adapte automatiquement la capacité à votre trafic réel. Vous êtes facturé par unité de requête consommée (rRCU pour les lectures, rWCU pour les écritures) plutôt que par capacité réservée. C'est le mode naturel pour les phases d'incertitude.

# Créer une table en mode On-Demand
aws dynamodb create-table \
  --table-name ma-table-dev \
  --attribute-definitions AttributeName=PK,AttributeType=S \
  --key-schema AttributeName=PK,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --region us-east-1

# Basculer une table existante en On-Demand
aws dynamodb update-table \
  --table-name ma-table-prod \
  --billing-mode PAY_PER_REQUEST \
  --region us-east-1

# Vérifier le mode de facturation actuel
aws dynamodb describe-table \
  --table-name ma-table-prod \
  --query 'Table.BillingModeSummary' \
  --region us-east-1

La Limite des 24 Heures Entre Changements de Mode

AWS autorise le changement de mode de capacité une fois toutes les 24 heures. Si vous basculez de Provisionné à On-Demand à 14h, vous ne pourrez pas revenir en Provisionné avant 14h le lendemain. Planifiez vos migrations en conséquence — notamment si vous anticipez un événement de trafic élevé.

# Vérifier quand le dernier changement de mode a eu lieu
aws dynamodb describe-table \
  --table-name ma-table-prod \
  --query 'Table.BillingModeSummary.LastUpdateToPayPerRequestDateTime' \
  --region us-east-1

Quand le Mode On-Demand est le Bon Choix

  • Phase de développement ou de lancement — trafic inconnu.
  • Applications avec des pics imprévisibles et rares (événements, campagnes marketing).
  • Trafic très faible ou sporadique — payer à la requête est moins cher que réserver des unités inutilisées.
  • Vous voulez zéro gestion opérationnelle de la capacité.

Guide de Décision — Quel Mode Choisir ?

graph TD Start(["Nouveau projet DynamoDB"]) --> Q1{"Trafic prévisible et stable ?"} Q1 -->|Oui| Q2{"Volume élevé et constant ?"} Q1 -->|Non| OD["On-Demand"] Q2 -->|Oui| PROV["Provisionné + Auto Scaling"] Q2 -->|Non| Q3{"Pics brutaux fréquents ?"} Q3 -->|Oui| OD Q3 -->|Non| PROV OD --> Note1["Observer 2-4 semaines puis réévaluer"] PROV --> Note2["Calibrer sur métriques CloudWatch historiques"]
  1. Trafic connu ? — Si vous avez des métriques historiques ou un profil de charge stable, le mode Provisionné avec Auto Scaling est économiquement supérieur.
  2. Trafic inconnu ou erratique ? — Démarrez en On-Demand. Observez vos métriques CloudWatch pendant 2 à 4 semaines, puis évaluez si le passage en Provisionné est justifié.
  3. Pics brutaux fréquents ? — On-Demand absorbe mieux les montées en charge instantanées que l'Auto Scaling Provisionné.
  4. Volume élevé constant ? — Au-delà d'un certain seuil d'utilisation, le mode Provisionné est moins coûteux. Comparez les coûts via le calculateur AWS.

Le Piège des Hot Partitions — Valable dans les Deux Modes

Beaucoup d'équipes basculent en On-Demand après avoir subi du throttling en mode Provisionné, convaincues que le problème vient du mode de capacité. Dans la moitié des cas, le vrai problème est une hot partition — une partition qui reçoit une proportion disproportionnée du trafic à cause d'une mauvaise clé de partition.

Imaginez un parking de 10 niveaux où 90% des voitures veulent toujours le niveau 1. Peu importe combien de places totales vous ajoutez, le niveau 1 reste saturé. C'est exactement ce qui se passe avec une hot partition DynamoDB.
graph TD Traffic["Trafic Total de la Table
100% des requêtes"] --> PA["Partition A
clé : user_123"] Traffic --> PB["Partition B
clé : product_456"] Traffic --> PC["Partition C
clé : order_789"] PA --> PA_load["90% du trafic ici → Throttling / Latence élevée"] PB --> PB_load["5% du trafic"] PC --> PC_load["5% du trafic"] style PA fill:#ff6b6b,color:#fff style PA_load fill:#ff4444,color:#fff style PB fill:#51cf66,color:#fff style PC fill:#51cf66,color:#fff
  1. Partition A (clé 'user_123') : reçoit 90% du trafic total. Même en On-Demand, cette partition peut atteindre ses limites internes si le trafic est extrêmement concentré.
  2. Partitions B et C : quasi-inutilisées malgré une capacité totale suffisante.
  3. Résultat : throttling ou latence élevée sur la Partition A, même si la capacité globale de la table est largement suffisante.

Le symptôme classique : vous voyez du throttling sur CloudWatch (ConsumedWriteCapacityUnits bien en dessous des unités provisionnées), mais des erreurs ProvisionedThroughputExceededException persistent. C'est une hot partition, pas un problème de capacité globale.

# Détecter les métriques de throttling par table
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name WriteThrottleEvents \
  --dimensions Name=TableName,Value=ma-table-prod \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 3600 \
  --statistics Sum \
  --region us-east-1

Si WriteThrottleEvents est non nul alors que votre consommation globale est faible, le problème est la distribution des clés — pas le mode de capacité. Revoir votre modèle de données est la seule vraie solution.

Surveiller et Optimiser Après le Déploiement

Quel que soit le mode choisi, instrumentez votre table dès le premier jour. Les métriques CloudWatch DynamoDB sont votre principal outil de diagnostic.

# Vérifier la consommation de capacité en lecture sur les dernières 24h
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name ConsumedReadCapacityUnits \
  --dimensions Name=TableName,Value=ma-table-prod \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 3600 \
  --statistics Sum Average \
  --region us-east-1

# Vérifier les événements de throttling en écriture
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name WriteThrottleEvents \
  --dimensions Name=TableName,Value=ma-table-prod \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 3600 \
  --statistics Sum \
  --region us-east-1

Politique IAM Minimale pour la Surveillance

🔽 Afficher la politique IAM de surveillance DynamoDB 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DynamoDBDescribeTable",
      "Effect": "Allow",
      "Action": [
        "dynamodb:DescribeTable",
        "dynamodb:DescribeLimits"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/ma-table-prod"
    },
    {
      "Sid": "CloudWatchDynamoDBMetrics",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:ListMetrics"
      ],
      "Resource": "*"
    }
  ]
}

Notez que cloudwatch:GetMetricStatistics et cloudwatch:ListMetrics ne supportent pas les restrictions au niveau de la ressource — "Resource": "*" est requis pour ces actions.

Stratégie Recommandée : Démarrer en On-Demand, Migrer si Nécessaire

Pour une application dont le trafic est inconnu, la stratégie la plus sûre est de démarrer en On-Demand et d'observer. Après 2 à 4 semaines de production, vous aurez des données CloudWatch réelles sur votre consommation de RCU et WCU. Si votre utilisation est stable et élevée, comparez le coût mensuel On-Demand avec le coût d'un mode Provisionné calibré sur vos métriques.

graph LR S1["1. Lancement On-Demand"] --> S2["2. Observation CloudWatch 2-4 sem."] S2 --> S3{"Consommation stable et élevée ?"} S3 -->|Oui| S4["3. Analyse coût Provisionné vs On-Demand"] S3 -->|Non| S5["Rester en On-Demand"] S4 --> S6{"Provisionné moins cher ?"} S6 -->|Oui| S7["4. Migrer en Provisionné + Auto Scaling"] S6 -->|Non| S5 S7 --> S8["5. Surveiller WriteThrottleEvents"]
  1. Lancement en On-Demand : aucune configuration de capacité requise, zéro risque de throttling au démarrage.
  2. Observation CloudWatch : collectez 2 à 4 semaines de métriques de consommation réelle.
  3. Analyse de coût : si la consommation est stable et élevée, calculez le coût équivalent en mode Provisionné.
  4. Migration si pertinent : basculez en Provisionné avec Auto Scaling, en respectant la contrainte de 24 heures entre changements de mode.
  5. Surveillance continue : maintenez des alarmes CloudWatch sur WriteThrottleEvents et ReadThrottleEvents.

Conclusion et Prochaines Étapes — Modes de Capacité DynamoDB

Si vous ne connaissez pas encore vos patterns de trafic, démarrez en On-Demand. Ce n'est pas le mode le moins cher à fort volume, mais c'est le mode le plus sûr pour éviter le throttling et collecter des données réelles avant de vous engager sur une capacité provisionnée. Une fois votre trafic stabilisé et mesuré, réévaluez avec des chiffres concrets.

Le vrai piège n'est pas le choix du mode — c'est de négliger la conception de la clé de partition. Un mauvais modèle de données crée des hot partitions qui throttlent indépendamment du mode de capacité choisi.

Glossaire — Termes Clés DynamoDB

TermeDéfinition
RCU (Read Capacity Unit)Unité de capacité de lecture : une lecture fortement cohérente de 4 Ko par seconde, ou deux lectures éventuellement cohérentes de 4 Ko.
WCU (Write Capacity Unit)Unité de capacité d'écriture : une écriture de 1 Ko par seconde.
ThrottlingRejet de requêtes par DynamoDB quand la capacité provisionnée est dépassée. Retourne ProvisionedThroughputExceededException.
Hot PartitionPartition DynamoDB recevant une proportion disproportionnée du trafic, causant du throttling localisé indépendamment de la capacité globale.
Auto Scaling DynamoDBMécanisme d'ajustement automatique des RCU/WCU provisionnés basé sur l'utilisation observée, via Application Auto Scaling. Réactif, non instantané.

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Groupes IAM AWS : Pourquoi Attacher les Politiques aux Groupes Plutôt qu'aux Utilisateurs

Vous venez d'intégrer trois nouveaux développeurs dans votre équipe. Vous créez leurs utilisateurs IAM, puis vous commencez à attacher les politiques une par une à chaque compte — et c'est là que le problème commence. Six mois plus tard, un développeur change de rôle, et personne ne sait exactement quelles permissions il possède ni pourquoi. TL;DR — Groupes IAM vs. Politiques Directes Critère Politiques directes sur l'utilisateur Politiques via Groupe IAM Auditabilité Difficile — chaque utilisateur est une île Claire — une politique, un groupe, N utilisateurs Gestion à l'échelle O(N) opérations pour N utilisateurs O(1) — modifier le groupe suffit Risque d'erreur Élevé — oubli fréquent lors des offboardings Faible — retirer l'utilisateur du groupe suffit Conformité (moindre...
Lire la suite

LSI vs GSI dans DynamoDB : choisir le bon index secondaire

Vous avez modélisé votre table DynamoDB autour d'une clé de partition, puis le jour où un nouveau cas d'usage apparaît — filtrer les commandes par statut, rechercher les utilisateurs par email — vous réalisez que la clé primaire ne suffit plus. C'est exactement là que les index secondaires entrent en jeu, et le choix entre un LSI et un GSI a des conséquences directes sur la cohérence des lectures, la capacité de la table et les contraintes de conception. TL;DR — LSI vs GSI dans DynamoDB Critère LSI (Local Secondary Index) GSI (Global Secondary Index) Clé de partition Identique à la table de base N'importe quel attribut Clé de tri Attribut différent de la table N'importe quel attribut (optionnel) Création Uniquement à la création de la table À tout moment Cohérence des lectures Fortement cohérente possible Éventuellement cohérente uniquement Capacité Partagée avec la table de base ...
Lire la suite

NAT Gateway vs NAT Instance : Quelle solution choisir pour vos instances privées ?

Vous venez de déployer vos premières instances EC2 dans un sous-réseau privé et vous réalisez qu'elles ne peuvent pas télécharger les mises à jour système — aucune route vers internet. La question qui suit est systématique : faut-il provisionner un NAT Gateway managé ou lancer une instance EC2 configurée comme NAT Instance ? Ce choix impacte directement la disponibilité, les coûts opérationnels et la charge de maintenance de votre infrastructure. TL;DR — NAT Gateway vs NAT Instance Critère NAT Gateway NAT Instance Gestion Entièrement managé par AWS Vous gérez l'OS, les patches, la HA Disponibilité Haute disponibilité dans une AZ Dépend de votre configuration Bande passante Scalabilité automatique jusqu'aux limites du service Limitée par le type d'instance EC2 Modèle de coût ...
Lire la suite