DeepSeek est disponible dans Amazon Bedrock, mais il ne s’agit ni du chat officiel DeepSeek ni d’un simple relais vers api.deepseek.com. Vous invoquez des modèles DeepSeek proposés dans l’environnement AWS, avec des identifiants, des régions, des API, une facturation et des règles de gouvernance propres à Bedrock.
Dernière vérification factuelle : 20 juillet 2026. Les modèles, régions, tarifs et modes de conservation peuvent évoluer. Vérifiez la fiche AWS du modèle et sa disponibilité effective dans votre compte avant toute mise en production.
Réponse rapide : pour une nouvelle application AWS, DeepSeek V3.2 est le point de départ le plus logique lorsqu’il est disponible dans la région autorisée. En France, si votre politique impose un traitement dans l’Union européenne, la fiche AWS liste actuellement
eu-north-1(Stockholm) pour V3.2 et V3.1, mais paseu-west-3(Paris). DeepSeek-R1 est, lui, documenté via une inférence géographique aux États-Unis. Ne choisissez donc pas le modèle avant d’avoir validé la région, le mode de conservation et le coût.
À retenir
- AWS documente actuellement DeepSeek V3.2, DeepSeek-V3.1 et DeepSeek-R1 dans Amazon Bedrock.
- DeepSeek V3.2 et V3.1 sont utilisables via les API natives Bedrock et via Chat Completions sur
bedrock-mantle. R1 utilisebedrock-runtime, pas Chat Completions dans la documentation actuelle. - Les identifiants Bedrock ne sont pas ceux de l’API directe DeepSeek. Par exemple,
deepseek.v3.2est un identifiant AWS ;deepseek-v4-flashetdeepseek-v4-proappartiennent à l’API directe DeepSeek. - Dire que « les fournisseurs n’accèdent jamais aux prompts » est trop absolu. Le résultat dépend notamment du mode effectif
none,default,provider_data_shareouinheritet des modes autorisés par le modèle. - La disponibilité dépend du modèle, de la région, du compte, des politiques IAM/SCP, des quotas et des conditions applicables. Une présence dans la documentation ne garantit pas l’accès dans tous les comptes.
Amazon Bedrock ou API DeepSeek directe : quelle option choisir ?
Les deux offres donnent accès à des modèles de la famille DeepSeek, mais elles ne sont pas interchangeables. Bedrock convient surtout aux équipes déjà organisées autour d’AWS ; l’API directe permet d’utiliser les modèles et fonctions publiés directement par DeepSeek. L’auto-hébergement répond à un troisième besoin : contrôler l’infrastructure et l’exécution d’un modèle à poids ouverts.
| Option | À choisir si… | Point de vigilance |
|---|---|---|
| DeepSeek dans Amazon Bedrock | Vous avez besoin d’IAM, de Guardrails, d’une facturation AWS, d’une région contrôlée et d’une intégration avec vos services AWS. | La sélection de modèles peut être différente ou plus ancienne que celle de l’API directe. Prix, endpoints et régions sont propres à AWS. |
| API DeepSeek directe | Vous voulez les modèles, identifiants, tarifs et fonctions proposés directement par DeepSeek. | Vous appliquez les conditions et la politique de confidentialité DeepSeek et construisez séparément votre gouvernance AWS. |
| Auto-hébergement | Vous voulez contrôler le runtime, le réseau, le matériel et la localisation de l’exécution. | Vous gérez le dimensionnement GPU, les mises à jour, la sécurité, la disponibilité et le coût d’exploitation. |
Pour approfondir cette décision, consultez aussi notre comparaison DeepSeek local ou API et notre guide de l’API DeepSeek.
Quels modèles DeepSeek sont disponibles dans Amazon Bedrock ?
La liste officielle AWS des modèles DeepSeek contient trois références au moment de cette vérification. Elles sont toutes text-to-text, mais leurs API et leur couverture régionale diffèrent.
| Modèle Bedrock | Contexte / sortie max. | API documentées | Usage conseillé |
|---|---|---|---|
| DeepSeek V3.2 | 164K / 8K tokens | Chat Completions, Invoke et Converse | Nouveau projet généraliste, code, instructions et raisonnement. |
| DeepSeek-V3.1 | 128K / 8K tokens | Chat Completions, Invoke et Converse | Application existante ou benchmark dans une région prise en charge. |
| DeepSeek-R1 | 128K / 8K tokens | Invoke et Converse | Raisonnement complexe, mathématiques, logique et code, après validation de la contrainte US. |
Ne confondez pas DeepSeek V3.2 dans Bedrock avec la génération actuellement proposée par l’API officielle DeepSeek. Le catalogue AWS suit son propre cycle de disponibilité. Une application Bedrock ne bascule pas automatiquement vers DeepSeek V4 et une application utilisant l’API directe ne peut pas réutiliser les identifiants AWS.
Model IDs et endpoints
| Modèle | Endpoint | Model ID |
|---|---|---|
| DeepSeek V3.2 | bedrock-runtime | deepseek.v3.2 |
| DeepSeek V3.2 | bedrock-mantle | deepseek.v3.2 |
| DeepSeek-V3.1 | bedrock-runtime | deepseek.v3-v1:0 |
| DeepSeek-V3.1 | bedrock-mantle | deepseek.v3.1 |
| DeepSeek-R1 | bedrock-runtime | deepseek.r1-v1:0 ou profil US us.deepseek.r1-v1:0 |
bedrock-runtime est l’endpoint natif utilisé par les opérations Invoke et Converse. bedrock-mantle expose notamment une API Chat Completions compatible avec les clients qui acceptent une base URL personnalisée. Cette compatibilité ne signifie pas que Bedrock reproduit toutes les API ni toutes les fonctions d’OpenAI.
Régions : ce qu’une équipe française doit vérifier
La région n’est pas un détail de configuration : elle détermine la disponibilité, la latence, le prix et le périmètre de traitement des données. D’après les fiches AWS consultées le 20 juillet 2026 :
- DeepSeek V3.2 et DeepSeek-V3.1 sont disponibles en mode In-Region dans plusieurs régions, dont
eu-north-1(Stockholm) eteu-west-2(Londres). - La fiche V3.2 ne liste pas
eu-west-3(Paris) et n’affiche pas de profil Geo EU ou Global pour ce modèle. - DeepSeek-R1 est documenté avec le profil géographique US
us.deepseek.r1-v1:0, routé entre des régions américaines. Il ne constitue donc pas le choix naturel pour une politique imposant un traitement dans l’Union européenne.
Résidence des données : Londres est une région européenne au sens géographique d’AWS, mais le Royaume-Uni n’est pas membre de l’Union européenne. Si votre exigence porte précisément sur l’UE, validez Stockholm et les transferts associés avec votre responsable sécurité ou DPO. Une région AWS ne suffit pas, à elle seule, à démontrer la conformité RGPD.
Consultez toujours la matrice régionale AWS et la fiche du modèle juste avant le déploiement. Les permissions, quotas et politiques de votre organisation peuvent rendre un modèle indisponible même si la région figure dans la documentation publique.
Configurer un premier appel à DeepSeek V3.2
L’exemple suivant utilise Converse avec les identifiants AWS habituels. Il vise eu-north-1, la région de Stockholm actuellement listée pour V3.2. Vérifiez d’abord que cette région et ce modèle correspondent à votre politique et à votre compte.
1. Vérifier le compte, la région et les conditions
- Ouvrez le catalogue des modèles dans la console Amazon Bedrock et sélectionnez la région cible.
- Recherchez DeepSeek V3.2 et vérifiez son statut dans votre compte.
- Lisez la licence et les conditions associées. AWS indique que l’utilisation initiale d’un modèle tiers vaut acceptation de l’EULA applicable.
- Vérifiez les politiques IAM, les SCP de l’organisation, le quota et le mode de conservation effectif.
AWS précise que les modèles DeepSeek serverless natifs ne sont pas vendus comme des produits AWS Marketplace dotés d’un product ID. Ne suivez donc pas automatiquement un tutoriel Marketplace ancien pour appeler le modèle natif. Un déploiement DeepSeek via Bedrock Marketplace ou SageMaker reste une architecture distincte, avec un endpoint et une facturation d’infrastructure propres.
2. Accorder uniquement les permissions nécessaires
Pour un appel non-streaming via Converse, l’action principale est bedrock:InvokeModel. Ajoutez bedrock:InvokeModelWithResponseStream uniquement si l’application utilise le streaming. Voici un exemple minimal à adapter à vos rôles et à votre organisation :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "arn:aws:bedrock:eu-north-1::foundation-model/deepseek.v3.2"
}
]
}En production, utilisez un rôle IAM attaché à la charge de travail plutôt qu’une clé permanente intégrée dans le code. Une SCP ou une règle IAM explicite peut aussi bloquer un modèle même si une autre policy l’autorise.
3. Installer le SDK et appeler Converse
python -m pip install --upgrade boto3import boto3
from botocore.config import Config
from botocore.exceptions import ClientError
REGION = "eu-north-1"
MODEL_ID = "deepseek.v3.2"
client = boto3.client(
"bedrock-runtime",
region_name=REGION,
config=Config(retries={"mode": "standard", "max_attempts": 5}),
)
try:
response = client.converse(
modelId=MODEL_ID,
messages=[
{
"role": "user",
"content": [
{
"text": (
"Réponds en français. Donne trois contrôles de sécurité "
"à appliquer avant de déployer une application Bedrock."
)
}
],
}
],
inferenceConfig={
"maxTokens": 500,
"temperature": 0.2,
},
)
print(response["output"]["message"]["content"][0]["text"])
except ClientError as error:
code = error.response.get("Error", {}).get("Code", "Unknown")
message = error.response.get("Error", {}).get("Message", "")
print(f"Erreur Bedrock : {code} — {message}")Ne journalisez pas le prompt complet par défaut. Enregistrez plutôt un identifiant de requête, le modèle, la région, la latence, le nombre de tokens et un code d’erreur, puis ne conservez le contenu que si votre politique l’autorise.
Option : Chat Completions avec Bedrock Mantle
V3.2 et V3.1 prennent également en charge Chat Completions via bedrock-mantle. Utilisez une clé API Amazon Bedrock, pas une clé fournie par DeepSeek, et gardez-la côté serveur.
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["BEDROCK_API_KEY"],
base_url="https://bedrock-mantle.eu-north-1.api.aws/v1",
)
response = client.chat.completions.create(
model="deepseek.v3.2",
messages=[
{
"role": "user",
"content": "Explique en français la différence entre IAM et un Guardrail Bedrock.",
}
],
)
print(response.choices[0].message.content)Cette route peut faciliter une migration depuis un client OpenAI, mais elle ne garantit pas la parité de tous les endpoints, paramètres ou outils. Testez chaque fonction réellement utilisée par votre application.
Prompts, réponses et conservation des données
La documentation générale de protection des données AWS explique que les fournisseurs n’accèdent pas aux comptes de déploiement Bedrock, aux logs Bedrock ni, dans ce cadre général, aux prompts et réponses des clients. Mais cette formulation ne doit plus être transformée en garantie absolue : Amazon Bedrock dispose désormais de modes explicites de conservation, dont un mode qui peut autoriser le partage avec le fournisseur.
| Mode | Comportement documenté par AWS | Décision pratique |
|---|---|---|
none | Zero Data Retention : AWS n’écrit pas la requête ou la réponse en stockage durable et ne la partage pas avec le fournisseur. Sur Responses, store=true est refusé. | À privilégier lorsqu’une exigence impose une rétention zéro, à condition que le modèle l’autorise. |
default | La politique propre au modèle s’applique. AWS peut conserver les données pour la sécurité ou la prévention des abus ; le fournisseur ne les reçoit pas. store=false ne garantit pas à lui seul une rétention zéro. | Lire la fiche et les conditions du modèle. Ne pas présenter ce mode comme équivalent à none. |
provider_data_share | Vous autorisez AWS à conserver et à partager les données d’inférence avec le fournisseur selon les exigences du modèle. Ce mode est requis par certains modèles, mais son activation ne signifie pas que tous les modèles partagent automatiquement leurs données. | N’activer qu’après validation sécurité, juridique et DPO. Vérifier les allowed_modes du modèle. |
inherit | Aucune règle n’est fixée à ce niveau. Le système hérite du niveau plus large ; c’est la valeur initiale des nouveaux comptes et projets. | Ne pas interpréter inherit comme « aucune conservation ». Calculer le mode effectif. |
Le mode effectif est le premier mode différent de inherit dans l’ordre suivant : projet → compte → valeur par défaut du modèle. Si ce mode n’appartient pas aux allowed_modes du modèle, le modèle apparaît comme indisponible et la requête est bloquée.
Important pour DeepSeek : ne déduisez pas les
allowed_modesde V3.2, V3.1 ou R1 à partir d’un autre fournisseur. Consultez la réponse du catalogue dans votre propre compte et la fiche AWS à jour. Le mode effectif peut aussi dépendre du projet.
Si vous utilisez une clé Bedrock Mantle, ces requêtes en lecture permettent de contrôler la configuration du compte et le statut effectif de V3.2 :
curl "https://bedrock-mantle.eu-north-1.api.aws/v1/data_retention" \
-H "x-api-key: $BEDROCK_API_KEY"
curl "https://bedrock-mantle.eu-north-1.api.aws/v1/models/deepseek.v3.2" \
-H "x-api-key: $BEDROCK_API_KEY"N’envoyez jamais la sortie de ces commandes ni une clé API dans un ticket public. Pour modifier le mode, suivez la procédure officielle de conservation des données et faites valider le changement : une modification au niveau du compte peut affecter plusieurs applications.
Sécurité et RGPD : checklist avant la production
- Cartographiez les données : excluez les secrets, mots de passe, clés API et données personnelles non nécessaires.
- Minimisez et pseudonymisez : remplacez les identifiants directs avant l’appel au modèle.
- Fixez la région : documentez pourquoi la région choisie répond à vos contraintes de résidence et de transfert.
- Contrôlez IAM et SCP : autorisez seulement les modèles et actions nécessaires, puis testez les refus attendus.
- Vérifiez la conservation : consignez le mode effectif, sa source et les
allowed_modesdu modèle. - Maîtrisez les logs : l’activation de Model Invocation Logging peut créer une copie des entrées et sorties dans vos destinations de journalisation. Définissez chiffrement, accès et durée de conservation.
- Ajoutez des Guardrails : ils complètent les contrôles applicatifs, mais ne remplacent ni l’autorisation IAM ni la validation métier.
- Gardez un humain dans la boucle : une réponse générée ne doit pas décider seule d’un sujet juridique, médical, financier, RH ou de sécurité.
- Documentez les sous-traitants et finalités : mettez à jour le registre, l’information utilisateur, les contrats et, si nécessaire, l’analyse d’impact.
Le recours à Amazon Bedrock ne rend pas automatiquement une application conforme au RGPD. AWS applique un modèle de responsabilité partagée : AWS sécurise l’infrastructure, tandis que le client reste responsable de sa configuration, de ses données, de ses accès et de la licéité du traitement. Consultez également notre guide DeepSeek est-il sûr ?.
Tarifs DeepSeek dans Amazon Bedrock
Bedrock facture l’inférence selon le modèle, la région, le service tier et le volume de tokens. Les prix ci-dessous sont ceux affichés par la page officielle Amazon Bedrock Pricing lors de la vérification. Ils ne correspondent pas aux tarifs de l’API directe DeepSeek.
| Modèle et région | Entrée / 1M tokens | Sortie / 1M tokens | Tier |
|---|---|---|---|
| V3.2 — Virginie du Nord, Ohio, Oregon | 0,62 $ | 1,85 $ | Standard |
| V3.2 — Stockholm, Mumbai, São Paulo, Jakarta, Tokyo | 0,74 $ | 2,22 $ | Standard |
| V3.2 — Sydney | 0,6386 $ | 1,9055 $ | Standard |
| V3.1 — Sydney | 0,5974 $ | 1,7304 $ | Standard |
Ne généralisez pas ce tableau. La page tarifaire AWS ne présente pas une ligne complète pour chaque combinaison modèle/région et peut différer de la model card sur certains service tiers. Pour R1, Londres, Priority ou Flex, contrôlez le prix et l’éligibilité affichés pour votre région et votre compte avant d’établir un budget.
Exemple de calcul pour Stockholm
Avec V3.2 Standard à Stockholm, 50 000 tokens d’entrée et 10 000 tokens de sortie donnent l’estimation suivante :
Entrée : 50 000 / 1 000 000 × 0,74 $ = 0,0370 $
Sortie : 10 000 / 1 000 000 × 2,22 $ = 0,0222 $
Total estimé : 0,0592 $Ce calcul ne couvre que les tokens du modèle. Ajoutez, selon l’architecture, les coûts des Guardrails, du stockage et des logs, de CloudWatch, S3, KMS, Lambda, des bases vectorielles, du transfert de données, des retries et des autres services utilisés par les agents ou le RAG.
Choisir le modèle avec un benchmark, pas avec son nom
| Contrainte prioritaire | Premier test | Pourquoi |
|---|---|---|
| Application générale dans l’UE | V3.2 dans eu-north-1 | Modèle DeepSeek Bedrock le plus récent et région actuellement listée dans l’UE. |
| Code ou instructions sur une intégration existante | Comparer V3.2 et V3.1 | La qualité, la latence et le coût réels dépendent de vos prompts et de votre région. |
| Raisonnement complexe sans exigence UE | R1 contre V3.2 | R1 est spécialisé, mais sa disponibilité AWS actuelle est orientée US. |
| Migration d’un client Chat Completions | V3.2 sur bedrock-mantle | Réduit les changements de format, sans garantir la parité fonctionnelle. |
| Exigence Zero Data Retention | Le modèle dont allowed_modes inclut none | Le nom du modèle ne suffit pas ; une politique incompatible bloque l’appel. |
Constituez un jeu de tests anonymisé représentant vos vraies tâches. Mesurez au minimum la précision, les hallucinations, le respect du format, la latence p50/p95, les tokens, le coût par tâche et le taux d’échec. Rejouez ce benchmark lors d’un changement de modèle, de région ou de prompt.
Dépannage : erreurs fréquentes
AccessDeniedException
Vérifiez bedrock:InvokeModel, l’ARN de la ressource, les SCP, les permissions boundary, la région et l’acceptation des conditions applicables. L’accès documenté comme activé par défaut ne remplace pas les autorisations de votre identité.
ValidationException ou model ID invalide
Contrôlez le couple endpoint/identifiant. V3.1 utilise deepseek.v3-v1:0 sur bedrock-runtime, mais deepseek.v3.1 sur bedrock-mantle. Pour R1, votre appel peut devoir utiliser le profil us.deepseek.r1-v1:0.
Modèle unavailable à cause de la conservation
Comparez le mode effectif du projet/compte avec les allowed_modes renvoyés pour le modèle. Ne passez pas automatiquement à provider_data_share pour débloquer l’appel : faites d’abord valider l’impact sur les données.
ThrottlingException
Appliquez un backoff exponentiel avec jitter, limitez la concurrence, observez les quotas de la région et demandez une augmentation si nécessaire. Ne relancez pas indéfiniment une requête non idempotente.
Latence ou facture anormalement élevée
Réduisez le contexte inutile et maxTokens, mesurez les retries, contrôlez la région, puis identifiez les appels secondaires d’un agent ou d’un pipeline RAG. Une seule action utilisateur peut déclencher plusieurs inférences.
FAQ sur DeepSeek et Amazon Bedrock
DeepSeek est-il officiellement disponible dans Amazon Bedrock ?
Oui. AWS liste officiellement DeepSeek V3.2, DeepSeek-V3.1 et DeepSeek-R1. La disponibilité opérationnelle doit néanmoins être vérifiée pour votre région, votre compte et vos policies.
Bedrock appelle-t-il directement l’API de DeepSeek ?
Non. Vous appelez les endpoints Amazon Bedrock avec des model IDs AWS. Il ne faut pas réutiliser une base URL, une clé API ou un identifiant de l’API directe DeepSeek.
Quel modèle choisir pour une application destinée à la France ?
Si votre analyse autorise Stockholm et exige un traitement dans l’Union européenne, commencez par évaluer V3.2 dans eu-north-1. Ne supposez pas que la région Paris est disponible : elle n’est pas listée pour V3.2 dans la fiche AWS vérifiée. Faites confirmer le choix par vos équipes sécurité et juridique.
Les prompts et réponses sont-ils envoyés à DeepSeek ?
Pas dans le cadre général décrit par AWS pour les comptes de déploiement Bedrock, et les modes none et default ne prévoient pas de partage avec le fournisseur. Mais provider_data_share autorise explicitement AWS à conserver et partager des données selon les exigences du modèle. Vérifiez donc le mode effectif et les allowed_modes au lieu de formuler une garantie absolue.
store=false garantit-il une rétention zéro ?
Non. AWS précise que certains modèles peuvent encore conserver des données pour la sécurité même avec store=false. Utilisez le mode none lorsqu’une Zero Data Retention garantie est requise et vérifiez que le modèle l’accepte.
Faut-il souscrire DeepSeek dans AWS Marketplace ?
Pas pour les modèles DeepSeek serverless natifs décrits ici : AWS indique que DeepSeek ne fait pas partie des fournisseurs vendus sous forme de produits Marketplace avec product ID. Un ancien tutoriel consacré à un modèle déployé depuis Bedrock Marketplace ou SageMaker décrit un chemin différent.
Peut-on utiliser Guardrails avec DeepSeek ?
Oui, les fiches AWS indiquent la prise en charge de Guardrails via bedrock-runtime pour les modèles DeepSeek concernés. Testez toutefois vos règles sur vos propres langues et cas d’usage ; un Guardrail ne garantit pas l’exactitude de la réponse.
Le prix est-il le même que sur l’API DeepSeek ?
Non. Bedrock et l’API directe DeepSeek ont des catalogues et grilles tarifaires distincts. Comparez le coût complet : tokens, région, journalisation, Guardrails, stockage, réseau, supervision, support et charge opérationnelle.
Sources officielles
- AWS — modèles DeepSeek dans Amazon Bedrock
- AWS — fiche DeepSeek V3.2
- AWS — fiche DeepSeek-V3.1
- AWS — fiche DeepSeek-R1
- AWS — modes de conservation des données
- AWS — protection des données et responsabilité partagée
- AWS — accès aux modèles et conditions
- AWS — tarifs Amazon Bedrock
Ce guide indépendant présente les informations techniques disponibles à la date indiquée. Il ne constitue ni une garantie de disponibilité, ni un avis juridique, ni une déclaration de conformité.
