Oui, DynamoDB est serverless : aucune instance à dimensionner, aucune version de moteur à faire évoluer, aucune fenêtre de maintenance, aucun basculement à configurer, et une table sans trafic ne vous demande rien pour rester en vie. Mais serverless décrit le modèle d'exploitation, pas automatiquement le modèle de facturation. DynamoDB propose deux modes de capacité, et un seul facture à la requête. Prenez l'autre sans y réfléchir et vous payez du débit réservé toutes les heures du mois, sur une base que tout le monde dans la pièce appelle encore serverless.
Que fait réellement AWS à votre place ?
La couche de stockage, entièrement. Chaque élément est écrit sur un stockage répliqué dans trois zones de disponibilité de la région, et la réplication, le basculement entre copies, le découpage des partitions quand la table grossit et les correctifs de tout ce qui se trouve dessous se passent sans fenêtre de maintenance, sans choix de version et sans validation de votre part. Aucun réplica de lecture à promouvoir, aucune mise à jour mineure à planifier à minuit.
Le chemin d'accès est tout aussi silencieux. Une table n'a pas d'endpoint à placer dans un VPC ni de limite de connexions à saturer : vous appelez une API HTTPS signée avec des identifiants IAM, et le service décide quelle machine répond. La documentation sur le fonctionnement interne décrit le partitionnement sous-jacent, et mérite d'être lue justement parce que vous n'y touchez jamais. Ce qui reste à vous, c'est tout ce qui se trouve au-dessus de l'API.
| Sujet | Géré par AWS | Reste à votre charge |
|---|---|---|
| Serveurs et correctifs | Tout : ni instance, ni OS, ni version de moteur | Rien |
| Disponibilité | Réplication sur trois zones de disponibilité, bascule automatique | Région unique ou tables globales, et politique de sauvegarde |
| Montée en charge du stockage | Les partitions se découpent et grandissent avec la table | Taille des éléments, attributs superflus, durée de conservation |
| Débit | Absorbe le trafic dans les limites de table et de partition | Le mode de capacité, et les valeurs si vous choisissez provisionné |
| Modèle de données | Rien | Clé de partition, clé de tri, index, schémas d'accès |
| Coût | Rien | Tout : mode, nombre d'index, taille des éléments, cohérence de lecture |
DynamoDB est-il facturé à l'usage ?
En mode on-demand, oui. Vous payez les unités de requête de lecture et d'écriture réellement consommées, plus le stockage : une table que personne ne sollicite ne coûte que son stockage, et un week-end calme se lit comme une ligne calme sur la facture. C'est la forme de facturation que les gens imaginent quand ils disent serverless, et la raison pour laquelle on-demand est le choix par défaut raisonnable d'une table neuve.
En mode provisionné, non. Vous déclarez des unités de capacité de lecture et d'écriture par seconde, et vous les payez à l'heure, que les requêtes arrivent ou non. L'auto scaling déplace ces valeurs dans une plage que vous fixez, mais il réagit à des métriques publiées et non à la requête en cours : un pic brutal peut donc être throttlé pendant que la capacité rattrape. La capacité réservée abaisse le tarif contre un engagement de durée, ce qui est la chose la moins serverless du service. La documentation des modes de capacité détaille les règles de bascule, et la page de tarification porte les chiffres du jour.
| Dimension | On-demand | Provisionné |
|---|---|---|
| Unité de facturation | Unité de requête consommée, plus stockage | Unité de capacité réservée par heure, plus stockage |
| Coût à vide | Stockage seul | La capacité réservée en entier, tout le mois |
| Comportement en pic | Absorbé, dans les limites de table et de compte | Throttlé jusqu'à ce que l'auto scaling suive |
| Travail de planification | Aucun | Dimensionnement, alarmes, plages d'auto scaling, revue régulière |
| Engagement | Aucun | Capacité réservée sur une durée, pour obtenir le tarif bas |
| Quand il gagne | Tables neuves, trafic en pics, moyenne faible, charge inconnue | Utilisation stable, mesurée, élevée et prévisible |
Que gardez-vous à votre charge ?
Le modèle de données, et il pèse plus lourd que le mode. La clé de partition décide de la répartition du trafic : une clé à faible cardinalité, ou un gros locataire parmi des petits, concentre les requêtes sur une seule partition et produit un throttling qui ressemble à une panne du service alors que c'est une faute de modélisation. AWS publie des recommandations de conception de clé de partition parce que c'est l'erreur la plus fréquente.
Trois autres lignes restent de votre côté. Chaque index secondaire global est une seconde copie des attributs projetés, avec son propre stockage et son propre débit : le nombre d'index est une décision de coût déguisée en décision de requête. Les lectures fortement cohérentes consomment plus de capacité que les lectures à cohérence éventuelle, ce qui fait de la cohérence un arbitrage budgétaire. Enfin, la taille des éléments pousse directement le coût de lecture : l'habitude de ranger un gros bloc de données dans un élément se paie à chaque lecture de cet élément.
Vos tables sont-elles serverless en exploitation seulement, ou aussi sur la facture ? Décrivez votre système : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →Le single-table design est-il obligatoire ?
Non, ce n'est pas un droit d'entrée. Le single-table design est une optimisation au bénéfice précis : surcharger un même espace de clés permet à une seule requête de ramener une commande et ses lignes ensemble, là où un modèle éclaté multiplie les allers-retours qu'une jointure relationnelle aurait évités. La documentation de conception NoSQL part de cette idée, et elle a ses raisons.
Le prix à payer, c'est la lisibilité. La table cesse de se décrire elle-même : les clés deviennent opaques, la console illisible, et le schéma vit désormais dans le code applicatif, où un nouvel arrivant doit le reconstituer. Les tables on-demand ne facturent que ce qu'elles stockent et servent : répartir les entités sur plusieurs tables n'ajoute aucune ligne fixe à la facture. Pour un service avec quelques entités et aucune requête inter-entités sur le chemin chaud, des tables séparées évoluent plus facilement et ne coûtent rien de plus. Décidez sur les schémas d'accès, pas sur l'orthodoxie.
Comment DynamoDB se marie-t-il avec Lambda ?
Sans pool de connexions, et c'est tout l'intérêt. DynamoDB est une API HTTPS authentifiée par IAM : mille environnements d'exécution Lambda simultanés sont simplement mille appelants indépendants. Aucun plafond de connexions à atteindre, aucun proxy à faire tourner, aucun placement VPC à rater. C'est la différence structurelle avec PostgreSQL sur RDS, où la concurrence Lambda se transforme en pression sur les connexions et où RDS Proxy cesse d'être optionnel. Nous détaillons cette comparaison dans notre guide DynamoDB ou RDS pour un backend serverless.
// Créé une fois par environnement d'exécution, réutilisé entre invocations.
// Aucun pool à dimensionner, aucune connexion à ouvrir, aucun proxy devant.
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, GetCommand } from "@aws-sdk/lib-dynamodb";
const ddb = DynamoDBDocumentClient.from(
new DynamoDBClient({ maxAttempts: 3 }),
);
export const handler = async (event: { orderId: string }) => {
const { Item } = await ddb.send(
new GetCommand({
TableName: process.env.TABLE_NAME,
Key: { pk: "ORDER#" + event.orderId, sk: "META" },
}),
);
return Item ?? null;
};Deux habitudes comptent ici. Construisez le client hors du handler, pour que le SDK réutilise la connexion HTTPS sous-jacente entre les invocations du même environnement au lieu de repayer la poignée de main à chaque fois. Et fixez explicitement les réessais et les délais d'attente, parce que le throttling est une condition normale de ce service et non une urgence : le comportement par défaut mérite d'être une décision, pas un hasard.
Quand DynamoDB cesse-t-il d'être la bonne base serverless ?
Quand vous ne savez pas nommer les requêtes à l'avance. DynamoDB répond aux schémas d'accès pour lesquels vous avez conçu des clés, vite et à n'importe quelle échelle ; il n'a pas de jointure, pas de filtre libre sur toute la table qui ne dégénère pas en scan, pas de requête d'agrégation. Un produit où les analystes posent une question nouvelle chaque semaine n'est pas un défi de modélisation, c'est le mauvais moteur.
Les réponses habituelles sont ennuyeuses et justes. Gardez un moteur relationnel pour l'ensemble de requêtes que vous ne savez pas prévoir, en pesant les formes de coût comme dans notre comparaison des coûts Aurora Serverless, RDS et DynamoDB. Pour le reporting, utilisez l'export natif vers Amazon S3 et interrogez la copie avec Athena, pour que l'analytique n'atterrisse jamais sur le chemin chaud. Pour la recherche plein texte et à facettes, diffusez les changements vers un moteur de recherche. Faire tourner DynamoDB sur le chemin d'écriture et autre chose sur le chemin de lecture est une architecture normale, pas un aveu d'échec.
La règle de décision
DynamoDB est serverless en exploitation pour tout le monde, et serverless en facturation uniquement en mode on-demand. Tout le reste est un choix que vous faites et que vous payez.
- Des schémas d'accès que vous savez lister aujourd'hui : DynamoDB convient. Un ensemble de requêtes qui bouge sans cesse : moteur relationnel.
- Démarrez chaque nouvelle table en mode on-demand, le seul qui facture comme le mot le laisse entendre.
- Ne passez en provisionné qu'après un mois de métriques réelles montrant une utilisation stable et prévisible, et chiffrez l'engagement avant de le prendre.
- Vérifiez la cardinalité de la clé de partition et l'absence d'un locataire qui écrase les autres, avant la mise en production plutôt que pendant l'incident.
- Comptez vos index secondaires globaux : chacun est une copie supplémentaire des données, avec son stockage et son débit.
- Envoyez le reporting et l'analytique vers un export S3, jamais vers la table de production.
- Depuis Lambda : client hors du handler, réessais explicites, pas de pool, pas de VPC, IAM pour l'authentification.
Si le choix entre les deux modes de capacité est en réalité une question sur votre courbe de trafic, c'est exactement le travail : nos guides de décision AWS partent de la courbe, pas du nom du service.