Utiliser AWS Bedrock avec Cursor (BYOK)

AWS Bedrock BYOK in Cursor

Bring Your Own Key (BYOK) vous permet de pointer Cursor vers un fournisseur de modèles que vous payez déjà au lieu du routage de modèles intégré de Cursor. AWS Bedrock est l'un des choix les plus courants car il héberge Anthropic Claude et d'autres modèles de pointe derrière un compte AWS que vous contrôlez déjà. Ce guide passe en revue ce qu'est BYOK, pourquoi Bedrock en particulier, comment le configurer dans Cursor, comment fonctionnent la facturation et le contrôle des coûts, et comment corriger les erreurs que vous êtes le plus susceptible de rencontrer, y compris la déroutante « Invalid signature in thinking block is bound to a different conversation ».

Qu'est-ce que BYOK et quand l'utiliser

BYOK signifie que vous fournissez vos propres identifiants de fournisseur, et le fournisseur vous facture directement les tokens que vous consommez. Dans Cursor, le modèle s'exécute toujours via l'interface et les fonctionnalités de Cursor, mais la requête d'inférence va vers votre compte au lieu de celui de Cursor.

Vous voulez généralement BYOK lorsque :

Vous avez déjà un engagement de dépenses cloud. Si votre organisation a un engagement AWS ou une remise entreprise, router le trafic de modèles via Bedrock utilise ces dépenses au lieu d'ajouter une nouvelle ligne budgétaire.
La conformité exige une frontière spécifique. Bedrock garde les données à l'intérieur de votre compte et de votre région AWS, ce qui simplifie la résidence des données et la revue de sécurité.
L'approvisionnement préfère un seul fournisseur. Acheter via AWS est souvent plus simple que d'ajouter un fournisseur d'IA distinct à un contrat.

BYOK n'est pas toujours moins cher. La tarification incluse et à l'usage de Cursor peut battre Bedrock pour de petites équipes, et vous assumez vous-même la gestion des quotas. Choisissez BYOK pour le contrôle et la conformité, pas seulement pour le prix.

BYOK est par fournisseur de modèles, pas par discussion

Dans Cursor, vous activez les fournisseurs dans Settings > Models. Une fois Bedrock activé et vos identifiants enregistrés, les ID de modèles Bedrock que vous avez sélectionnés deviennent sélectionnables partout où vous choisissez des modèles. Vous n'êtes pas verrouillé sur Bedrock pour les autres modèles.

BYOK vs le routage intégré de Cursor

Il est utile de voir les deux voies côte à côte avant de vous engager.

Dimension	Modèles intégrés de Cursor	BYOK avec Bedrock
Facturation	Cursor vous facture	AWS vous facture directement
Identifiants	Gérés par Cursor	Vous fournissez et faites tourner les clés AWS
Quota	Géré par Cursor	Vous gérez les quotas par modèle
Conformité	La frontière de Cursor	Votre compte et région AWS
Effort de configuration	Nul	IAM, accès aux modèles, config du fournisseur
Liste de modèles	Sélectionnée par Cursor	Ce que votre région expose

Si vous êtes un développeur solo optimisant pour la vitesse, restez sur le routage intégré. Si vous êtes dans une organisation où la facture AWS, la région et la politique IAM doivent toutes être les vôtres, BYOK est la bonne réponse.

Pourquoi AWS Bedrock

Bedrock est une couche d'inférence hébergée, pas un modèle en soi. Il expose Anthropic Claude, Amazon Nova, Meta Llama, Mistral et d'autres via une seule API AWS. Cette API unique est la raison pour laquelle il est attractif pour un usage en entreprise.

Conformité et gouvernance. Les requêtes et les données restent dans votre compte et région AWS, sous vos contrôles et journaux d'audit existants.
Dépenses AWS existantes. L'utilisation des modèles apparaît sur votre facture AWS et peut être couverte par des engagements existants.
Résidence des données. Vous choisissez la région, ce qui compte lorsque les réglementations exigent que les données restent dans un pays.
Approvisionnement en entreprise. AWS est déjà un fournisseur approuvé dans la plupart des grandes organisations.

Les compromis sont l'image miroir : vous possédez le quota, la configuration IAM et le dépannage.

Prérequis

Avant de configurer Cursor, mettez en place les éléments suivants du côté AWS.

Compte AWS et accès aux modèles

Vous avez besoin d'un compte AWS avec la facturation activée. Dans la console Bedrock, l'accès aux modèles est opt-in par modèle, donc vous devez explicitement demander l'accès aux modèles Anthropic Claude que vous comptez utiliser. Certains modèles sont accordés automatiquement ; d'autres nécessitent une étape d'acceptation ou un court formulaire de cas d'usage.

Permissions IAM

Créez un utilisateur ou un rôle IAM pour Cursor avec les permissions les plus restreintes qui fonctionnent encore. Au minimum, Cursor doit invoquer les modèles et les lister.

Permission IAM	Pourquoi Cursor en a besoin
`bedrock:InvokeModel`	Envoie une requête non-streaming à un modèle
`bedrock:InvokeModelWithResponseStream`	Envoie une requête streaming, ce que l'interface de chat utilise
`bedrock:ListFoundationModels`	Remplit le sélecteur de modèles et valide les ID de modèles

Pour les modèles Claude sur Bedrock, vous avez aussi généralement besoin de bedrock:InvokeModel limité aux ARN de modèles ou, plus simplement, aux profils d'inférence de la région. Gardez la politique limitée et évitez d'attacher de larges politiques d'admin.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CursorBedrockInvoke",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-v1:0",
        "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-sonnet-4-5-v1:0"
      ]
    },
    {
      "Sid": "CursorBedrockList",
      "Effect": "Allow",
      "Action": "bedrock:ListFoundationModels",
      "Resource": "*"
    }
  ]
}

Attachez cette politique à un utilisateur ou rôle IAM dédié pour Cursor plutôt que de réutiliser une identité admin existante. Si votre organisation utilise des identifiants de courte durée, assumez un rôle et rafraîchissez le token de session périodiquement au lieu de créer une clé statique.

Vérifier l'accès avant de configurer Cursor

Prouvez d'abord que les identifiants fonctionnent depuis la ligne de commande. Si l'appel échoue ici, il échouera aussi dans Cursor, et vous vous serez épargné un aller-retour déroutant.

# Confirm the configured identity is the one you expect
aws sts get-caller-identity

# List the models your region exposes
aws bedrock list-foundation-models \
  --region us-east-1 \
  --query "modelSummaries[?contains(modelId, 'anthropic')].[modelId]" \
  --output table

Si le listage fonctionne mais l'invocation échoue, le problème est l'accès aux modèles ou l'ID de modèle spécifique, pas les identifiants.

Choix de la région

Choisissez une région où le modèle que vous voulez est disponible et où vos données sont autorisées à résider. L'inférence inter-régions est prise en charge pour certains modèles via un préfixe de profil d'inférence, donc vous n'êtes pas forcément limité à une seule région.

Configurer Bedrock dans Cursor

Cursor expose les fournisseurs BYOK dans les paramètres Models. Le flux a la même forme pour chaque fournisseur.

Ouvrez Cursor Settings > Models.
Trouvez le fournisseur AWS Bedrock et activez-le.
Saisissez votre ID de clé d'accès AWS, votre clé d'accès secrète et la région.
Choisissez les ID de modèles que vous voulez voir visibles dans le sélecteur.
Enregistrez et revenez à une discussion, puis sélectionnez un modèle Bedrock.

Champs d'identifiants

Cursor a besoin d'une configuration qualifiée par région. Un bloc de fournisseur Bedrock ressemble à peu près à ceci :

{
  "provider": "bedrock",
  "aws_access_key_id": "AKIAIOSFODNN7EXAMPLE",
  "aws_secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "aws_region": "us-east-1",
  "models": [
    "anthropic.claude-sonnet-4-5-v1:0",
    "anthropic.claude-3-5-haiku-v1:0"
  ]
}

Préférez la clé d'accès IAM de longue durée en dernier recours pour une machine de développeur. Pour une équipe, utilisez une session temporaire ou un rôle assumé afin que les clés ne soient pas stockées en clair sur le disque.

ID de modèles et inférence inter-régions

Les ID de modèles Bedrock suivent une forme prévisible : fournisseur, famille, version. Certains modèles nécessitent un préfixe de profil d'inférence, qui route la requête entre régions pour la disponibilité et le débit.

# Direct model IDs (region-scoped)
anthropic.claude-sonnet-4-5-v1:0
anthropic.claude-3-5-haiku-v1:0

# Cross-region inference profile IDs (note the region prefix)
us.anthropic.claude-sonnet-4-5-v1:0
eu.anthropic.claude-sonnet-4-5-v1:0
apac.anthropic.claude-sonnet-4-5-v1:0

Si un modèle renvoie une erreur d'accès même si vous l'avez activé, l'ID de modèle est presque toujours la cause : vérifiez s'il a besoin du préfixe us. ou eu. pour la région que vous avez choisie.

Les clés d'accès sont des secrets

Ne collez pas les clés d'accès dans une discussion, un fichier de règles ou une capture d'écran partagée. Stockez-les là où Cursor stocke les identifiants de fournisseur, et faites tourner toute clé que vous soupçonnez avoir été exposée. Les clés d'exemple ci-dessus sont les espaces réservés de la documentation publique d'AWS, pas de vrais identifiants.

Vérifier la connexion dans Cursor

Après avoir enregistré la configuration du fournisseur, confirmez le câblage avec un prompt trivial plutôt qu'une vraie tâche, afin qu'une défaillance soit sans ambiguïté.

Ouvrez une nouvelle discussion et sélectionnez l'un de vos ID de modèles Bedrock dans le sélecteur de modèles.
Demandez quelque chose de petit, comme « réponds avec le mot ready ».
Si la réponse revient, les identifiants, la région et l'ID de modèle sont tous corrects.
Si cela échoue, relancez le test d'invocation CLI ci-dessous et comparez le texte de l'erreur avec ce que Cursor affiche.

# Invoke the model directly so you can see the raw error text
aws bedrock-runtime invoke-model \
  --model-id anthropic.claude-sonnet-4-5-v1:0 \
  --region us-east-1 \
  --body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":16,"messages":[{"role":"user","content":"reply with the word ready"}]}' \
  --cli-binary-format raw-in-base64-out \
  /tmp/out.json && cat /tmp/out.json

Conserver une commande CLI fonctionnelle pour chaque modèle que vous utilisez transforme les messages d'erreur de Cursor d'ambigus en décodables, car vous savez déjà à quoi ressemble une invocation réussie.

Facturation et contrôle des coûts

Avec BYOK, AWS vous facture les tokens, pas Cursor. Cela change votre façon de budgétiser et de surveiller.

Tarification des modèles

Bedrock facture par token d'entrée et de sortie, et le tarif dépend du modèle. Les tokens d'entrée sont généralement moins chers que les tokens de sortie, et les modèles à long contexte coûtent plus par token que les petits.

Famille de modèles	Coût d'entrée relatif	Coût de sortie relatif	Notes
Classe Claude Sonnet	Moyen	Moyen	Défaut solide pour le codage général
Classe Claude Haiku	Bas	Bas	Rapide, peu cher, bon pour les petites modifications
Classe Claude Opus	Élevé	Élevé	Meilleur raisonnement, coût le plus élevé
Amazon Nova	Bas	Bas	Alternatives rentables

Allocation et surveillance des coûts

Étiquetez votre utilisation de Bedrock pour qu'elle soit attribuable, et surveillez les métriques plutôt que la facture.

# Enable cost allocation tags on the resources that call Bedrock
aws resourcegroupstaggingapi tag-resources \
  --resource-arn-list arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-sonnet-4-5-v1:0 \
  --tags Project=cursor-byok Team=platform

Dans CloudWatch, suivez les métriques d'invocation Bedrock et définissez une alarme de facturation pour qu'un agent emballé ne dépense pas discrètement votre budget mensuel pendant la nuit.

# Quick cost sanity check: list recent Bedrock usage with Cost Explorer
aws ce get-cost-and-usage \
  --time-period Start=2026-10-01,End=2026-10-20 \
  --granularity DAILY \
  --metrics BlendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Bedrock"]}}'

Réduire le coût des tokens

BYOK met le compteur de tokens entre vos mains, donc quelques habitudes paient rapidement :

Dimensionnez correctement le modèle. Utilisez un modèle de classe Haiku pour les petites modifications et réservez le modèle de classe Opus au raisonnement vraiment difficile.
Gardez le contexte resserré. Une fenêtre de contexte gonflée est le plus grand coût caché ; démarrez une nouvelle discussion quand le fil dérive.
Regroupez les petites modifications. Plusieurs prompts minuscules coûtent plus qu'un prompt bien délimité couvrant les mêmes changements.
Allégez les règles. Chaque règle toujours appliquée représente des tokens envoyés à chaque requête, donc gardez .cursor/rules léger.
Surveillez la première semaine. Consultez Cost Explorer quotidiennement la première semaine, puis chaque semaine, afin d'apprendre votre vraie référence avant qu'elle ne vous surprenne.

Corriger l'erreur « Invalid signature in thinking block »

C'est l'erreur Bedrock la plus déroutante dans Cursor car elle ressemble à un problème de clé d'API mais est presque toujours un problème d'état de conversation. Le message complet se lit :

Invalid `signature` in `thinking` block is bound to a different conversation

Cause racine

La réflexion étendue de Claude produit des blocs de raisonnement chiffrés qui portent une signature liée à la conversation et au tour exacts où ils ont été créés. Lorsque ces blocs sont rejoués dans une nouvelle requête, le contenu signé ne correspond plus et le fournisseur rejette toute la requête. Cela se produit lorsque :

un bloc de réflexion étendue d'un tour antérieur est renvoyé dans un tour ultérieur,
un proxy ou une passerelle met en cache et rejoue le corps de la requête,
l'état de la conversation est obsolète ou dupliqué, par exemple après un changement de modèle en cours de fil.

Corrections

Procédez dans cet ordre :

Démarrez une nouvelle discussion. La signature est liée à la conversation, donc une nouvelle discussion est la réinitialisation fiable.
Désactivez la réflexion étendue pour le modèle pendant que vous déboguez, puis réactivez-la une fois le flux propre.
Mettez Cursor à jour. La gestion des signatures pour les blocs de réflexion a été corrigée dans les versions récentes ; un client obsolète est une cause courante.
Supprimez les proxys ou passerelles intermédiaires qui pourraient mettre en cache ou réécrire les corps de requête entre Cursor et Bedrock.
Abaissez la température et raccourcissez le fil afin que moins de blocs de réflexion s'accumulent dans le contexte.

Nouvelle discussion d'abord, tout le reste ensuite

Quatre-vingt-dix pour cent du temps, démarrer une nouvelle discussion résout immédiatement l'erreur de signature. Si elle se reproduit dans une toute nouvelle discussion, alors examinez les proxys et la version du client.

Erreurs de limitation et resource_exhausted

Bedrock applique des quotas de débit par compte et par modèle. Lorsque vous les dépassez, vous obtenez une erreur de limitation ou resource_exhausted plutôt qu'un échec propre.

ResourceNotFoundException / ServiceQuotaExceededException:
You have exceeded the rate of requests allowed for this model.

C'est un problème de quota, pas un problème d'identifiants. Deux corrections :

Répartissez la charge entre les modèles ou les régions. Les profils d'inférence inter-régions existent précisément pour mutualiser la capacité.
Demandez une augmentation de quota dans la console AWS Service Quotas pour le modèle Bedrock que vous utilisez.

# List the Bedrock service quotas you can request increases for
aws service-quotas list-service-quotas \
  --service-code bedrock \
  --query "Quotas[?contains(QuotaName, 'Claude')].[QuotaName,QuotaCode,Value]" \
  --output table

L'erreur disparaît généralement d'elle-même une fois le trafic en rafale retombé, mais si elle est chronique, la demande de quota est la solution.

Erreurs d'accès, de région et de proxy

Accès refusé lorsque l'accès aux modèles n'est pas accordé

AccessDeniedException: You don't have access to the model with the specified model ID

Deux causes dominent ici :

L'accès aux modèles n'a jamais été accordé dans la console Bedrock. Ouvrez la console et demandez l'accès à ce modèle Anthropic spécifique.
La politique IAM est trop restrictive ou l'ID de modèle est erroné. Confirmez que la politique accorde bedrock:InvokeModelWithResponseStream et que la chaîne d'ID de modèle correspond à un modèle que vous avez réellement activé.

Mauvaise région

Si la région configurée dans Cursor n'héberge pas le modèle, ou si l'ID de modèle nécessite un préfixe inter-régions, les requêtes échouent même si la clé est valide. Confirmez que la région dans Cursor correspond à la région de la console où vous avez activé l'accès aux modèles.

Échecs de streaming derrière des proxys d'entreprise

Le streaming est le défaut pour le chat. Les proxys d'entreprise et les pare-feu qui inspectent TLS cassent souvent les réponses text/event-stream, ce qui se manifeste par un chat qui bloque ou renvoie une réponse partielle.

Mettez en liste blanche les points de terminaison régionaux Bedrock (par exemple bedrock-runtime.us-east-1.amazonaws.com).
Assurez-vous que le proxy ne met pas en tampon les réponses en streaming ; recherchez un réglage « streaming » ou « chunked transfer ».
Si le proxy est inévitable, confirmez si Cursor peut le contourner pour l'hôte Bedrock.

Référence rapide de dépannage

Symptôme	Cause probable	Solution
Invalid `signature` in `thinking` block	Blocs de réflexion rejoués entre conversations	Démarrez une nouvelle discussion, désactivez la réflexion étendue, mettez Cursor à jour
`resource_exhausted` / limitation	Quota par modèle dépassé	Répartissez entre régions, demandez une augmentation de quota
`AccessDeniedException`	Accès aux modèles non accordé ou politique trop restrictive	Activez le modèle dans la console, élargissez la politique IAM
Modèle introuvable / pas d'accès dans une région	Mauvaise région ou préfixe de profil d'inférence manquant	Faites correspondre la région, utilisez le préfixe `us.` / `eu.`
Le chat bloque sans sortie de flux	Proxy mettant en tampon `text/event-stream`	Mettez en liste blanche les points de terminaison Bedrock, désactivez la mise en tampon du proxy
Sélecteur de modèles vide	`bedrock:ListFoundationModels` manquant	Ajoutez la permission, réenregistrez les identifiants
Erreur d'authentification après rotation de clé	Identifiants obsolètes enregistrés dans Cursor	Ressaisissez la clé d'accès et le secret dans les paramètres Models
Fonctionne en local, échoue en CI	Région ou profil non transmis dans le pipeline	Définissez la région et le profil dans l'environnement CI

Une fois le flux stable, gardez une courte note de votre région, de vos ID de modèles et de vos limites de quota à côté de la configuration du fournisseur. Quand une erreur apparaît six mois plus tard, cette note transforme une enquête de deux heures en une correction de deux minutes.

Qu'est-ce que BYOK et quand l'utiliser​

BYOK vs le routage intégré de Cursor​

Pourquoi AWS Bedrock​

Prérequis​

Compte AWS et accès aux modèles​

Permissions IAM​

Vérifier l'accès avant de configurer Cursor​

Choix de la région​

Configurer Bedrock dans Cursor​

Champs d'identifiants​

ID de modèles et inférence inter-régions​

Vérifier la connexion dans Cursor​

Facturation et contrôle des coûts​

Tarification des modèles​

Allocation et surveillance des coûts​

Réduire le coût des tokens​

Corriger l'erreur « Invalid signature in thinking block »​

Cause racine​

Corrections​

Erreurs de limitation et resource_exhausted​

Erreurs d'accès, de région et de proxy​

Accès refusé lorsque l'accès aux modèles n'est pas accordé​

Mauvaise région​

Échecs de streaming derrière des proxys d'entreprise​

Référence rapide de dépannage​