Peut-on utiliser DynamoDB en dehors d'AWS ?

Oui. DynamoDB est joignable de partout en HTTPS — ton code n'a pas besoin de tourner sur AWS. Toute application disposant d'identifiants AWS peut appeler l'endpoint régional via un SDK ou une requête signée, qu'elle tourne sur ton portable, sur un serveur on-premises ou sur un autre cloud. Seule la base de données vit dans AWS.

Comment fonctionne l'accès

DynamoDB est une API, pas un socket que tu héberges : les clients parlent à un endpoint HTTPS régional avec des requêtes signées par des identifiants AWS et autorisées via IAM. Les SDK AWS (JavaScript, Python, Java, Go et d'autres), la CLI et la console utilisent tous cette même API publique — aucun d'eux ne se soucie de l'endroit où il s'exécute.

Tu peux le constater avec curl et sans le moindre compte AWS. Poste un corps ListTables vide sur l'endpoint d'une Région et il répond :

{
  "__type": "com.amazon.coral.service#MissingAuthenticationTokenException",
  "message": "Request is missing Authentication Token"
}

Une requête rejetée, mais une requête que le service a acceptée, analysée et à laquelle il a répondu depuis un portable qui n'est pas sur AWS. Ajoute une signature SigV4 et le même appel réussit.

Ce que le réseau te coûte

L'endpoint est joignable de partout ; la latence, elle, n'est pas la même de partout. Nous l'avons mesurée depuis une connexion domestique en Espagne le 2026-07-28 : dix posts ListTables non signés par Région sur une connexion HTTPS réutilisée, en lisant le time_starttransfer de curl.

Région	Première requête (TCP + TLS)	Médiane à chaud
`eu-central-1` (Francfort)	232 ms	50 ms
`eu-west-1` (Irlande)	204 ms	59 ms
`us-east-1` (N. Virginie)	456 ms	118 ms
`us-west-2` (Oregon)	577 ms	182 ms
`sa-east-1` (São Paulo)	743 ms	247 ms
`ap-northeast-1` (Tokyo)	905 ms	263 ms

Une machine, un jour, une route : lis donc les rapports plutôt que les millisecondes absolues.

DynamoDB répond en quelques millisecondes côté serveur. De l'Espagne à Tokyo, le réseau ajoute environ 250 ms par-dessus, soit 25 à 50 fois le travail que fait la base de données. Une boucle de lecture qui paraît instantanée à l'intérieur de la Région devient la chose la plus lente de ton programme à l'extérieur.

La première requête coûte trois à quatre fois une requête à chaud, entièrement en établissement TCP et TLS. Les processus longue durée le paient une fois. Un processus court — un cron, un script CLI, une fonction qui crée un client neuf à chaque invocation — le paie à chaque fois. Réutilise le client.

Ce qui change d'autre en dehors d'AWS

Le transfert de données — le trafic qui quitte AWS est soumis à des frais de transfert, et le quota gratuit est partagé, pas par service : "AWS customers receive 100 GB of free data transfer out to the internet free each month, aggregated across all AWS Services and Regions (except China and GovCloud)."
Les identifiants — du code hors d'AWS ne peut pas utiliser de rôles d'instance : tu géreras donc explicitement des clés d'accès ou des identifiants fédérés.

Développer sans AWS du tout

Pour développer, tu n'as même pas besoin d'un compte AWS : DynamoDB Local exécute l'API sur ta propre machine, hors ligne et gratuitement. Quand tu es prêt, tu changes l'endpoint et le même code vise le service web.

Aller plus loin

Les clients de bureau en sont la preuve quotidienne : DynoTable tourne sur ton Mac ou ton PC — entièrement en dehors d'AWS — et se connecte aussi bien aux Régions AWS qu'aux endpoints locaux. Construis les requêtes qu'il envoie avec l'expression builder.

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.

Latence mesurée le 2026-07-28 depuis une connexion résidentielle en Espagne, dix requêtes par Région sur une connexion réutilisée. Tes chiffres seront différents ; c'est l'écart entre Régions qui compte.