Le guide d'ingénierie pour optimiser les coûts d'Amazon Bedrock

On-demand vs provisioned throughput, batch inference, choix du modèle et token caching — chiffres concrets à l'appui.

TL;DR — Cinq stratégies qui se cumulent jusqu'à 60-80 % d'économies sur Bedrock :

1. Batch inference pour les workloads asynchrones → 50 % de remise, aucun impact sur la qualité
2. Prompt caching pour les contextes récurrents → 90 % de réduction sur les input tokens mis en cache
3. Routage de modèles (modèles bon marché pour les tâches simples) → 40 à 70 % de réduction des coûts
4. Benchmarking + LLM-as-a-judge pour valider qu'un modèle moins cher reste à la hauteur
5. Observabilité (OTel + DoiT GenAI Intelligence) pour détecter les dérives et pérenniser les économies

Ce playbook nous a permis de faire passer un client de 40 000 $/mois à 18 000 $. Détails ci-dessous.

Je dirige l'équipe d'ingénierie APAC chez DoiT. Le trimestre dernier, un client du secteur des services financiers m'a demandé d'auditer ses dépenses Bedrock. Claude Sonnet servait à tout — classification de tickets, extraction de documents, chat orienté client — et la facture mensuelle avait discrètement franchi la barre des 40 000 $. Deux semaines plus tard, elle était redescendue à 18 000 $ sans la moindre concession sur la qualité.

Voici ce playbook. Si vous pilotez les coûts Bedrock d'une équipe d'ingénierie ou de data, ce sont les leviers qui pèsent vraiment sur la facture.

Les exemples clients de cet article sont des composites issus de schémas observés sur plusieurs missions — il ne s'agit pas d'études de cas individuelles.

Comprendre les deux modèles de tarification

Bedrock propose deux modèles de tarification, et j'ai vu des erreurs coûteuses dans les deux sens. (Pour une analyse détaillée du fonctionnement de la tarification Bedrock — coûts de fine-tuning, estimation des tokens et stratégies de tagging compris — consultez le guide CloudOps de Josh Palmer sur la tarification Bedrock. Cet article se concentre sur les décisions d'ingénierie qui réduisent la facture.)

Tarification on-demand

Vous payez au token — input et output, tarifés séparément. Aucun engagement, aucun minimum.

À privilégier quand votre usage est en pics, que vous êtes encore en phase d'expérimentation, ou que vos dépenses mensuelles restent en deçà du point de bascule (voir plus bas).

Le piège classique : les output tokens coûtent généralement 3 à 5 fois plus cher que les input tokens. Vous vous souvenez du client en services financiers ? Il estimait ses coûts uniquement à partir du prix des input tokens et sous-évaluait sa facture réelle d'un facteur 3. Une tâche qui consomme 1 000 input tokens mais en génère 2 000 en sortie est dominée par le coût d'output. Modélisez toujours les deux côtés.

Provisioned throughput

Vous achetez des model units à l'heure (ou avec des engagements de 1 ou 6 mois). Une model unit est l'unité de capacité réservée de Bedrock — voyez-la comme une voie d'autoroute que vous payez à l'heure, que vous l'utilisiez ou non.

À privilégier quand vos workloads sont soutenus et prévisibles, que votre utilisation dépasse durablement le seuil de bascule et que vous avez besoin d'une latence garantie.

L'an dernier, j'ai accompagné une entreprise de médias dont le provisioned throughput tournait à 15 % d'utilisation. Ils l'avaient activé pour un test de charge, oublié de revenir en arrière, et l'argent partait en fumée depuis trois mois quand quelqu'un s'en est aperçu. Le passage en on-demand n'a tenu qu'à une ligne de configuration et leur a fait économiser des milliers de dollars dès le premier jour. Le provisioned throughput sous-utilisé est l'erreur la plus coûteuse sur Bedrock, sans hésitation.

Trouver le point de bascule

Coût mensuel on-demand = (input_tokens × prix_input) + (output_tokens × prix_output)
Coût mensuel provisioned = model_units × tarif_horaire × 730 heures

Pour la plupart des modèles, le provisioned devient plus économique autour de 60 à 70 % d'utilisation soutenue d'une model unit. Le mot soutenue est lourd de sens — ne vous fiez pas à l'usage de pointe. Un trafic qui plafonne autour de 70 % toute la journée avec quelques petits pics est un bon candidat ; un trafic qui végète à 10 % et grimpe à 100 % cinq minutes par heure ne l'est pas.

Batch inference : la remise de 50 % qu'on néglige

C'est probablement mon sujet préféré avec les clients, parce que la réaction est toujours la même : Attends, on peut juste… payer la moitié ?

Oui. Bedrock tarife les batch tokens à environ 50 % du prix on-demand pour les modèles compatibles. Mêmes modèles, même qualité, moitié prix. (À l'heure où nous écrivons — vérifiez la page de tarification avant d'engager une roadmap sur ce chiffre.) Le compromis : un SLA de 24 heures sans streaming — vos jobs entrent dans une file d'attente et s'exécutent de manière asynchrone.

Tout workload qui n'exige pas une réponse en temps réel est candidat. Catégorisation de tickets de support, traitement de corpus documentaires pour le RAG, génération de descriptions produits, exécution de suites d'évaluation, extraction de données structurées à partir de documents non structurés. J'estime que 30 à 40 % des workloads Bedrock de la plupart des équipes pourraient passer en batch sans aucun impact côté utilisateur.

Voici à quoi cela ressemble concrètement. Prenez 10 000 requêtes avec en moyenne 500 input tokens et 200 output tokens chacune, sur Claude Sonnet (tarif on-demand en ap-southeast-2) :

26,25 $ d'économisés sur un seul batch. Avec des pipelines quotidiens, on parle de plusieurs milliers de dollars par mois. Et l'implémentation se résume à des fichiers JSONL dans S3 — c'est de la plomberie, pas une refonte d'architecture.

Le choix du modèle comme stratégie de coût

Choisir le bon modèle est une décision de coût avec une variance d'un facteur 10 à 60. La plupart des équipes optent par défaut pour quelque chose de plus cher que nécessaire, parce qu'elles l'ont retenu pendant le prototypage et n'ont jamais reconsidéré la décision.

L'architecture en tiers

Les déploiements Bedrock les plus économiques que j'ai vus reposent sur une logique de tiers :

• Tier 1 (Haiku, Mistral 7B, Llama 3 8B) — classification, routage, extraction, Q&A simples. Une fraction de centime par requête. Doit absorber 60 à 80 % de votre trafic.
• Tier 2 (Sonnet, Mistral Large, Llama 3 70B) — raisonnement complexe, génération nuancée. 5 à 10 fois moins cher que le tier supérieur.
• Tier 3 (Opus, Claude 3.5 Sonnet) — uniquement les tâches les plus exigeantes. Tarif premium, réservé aux travaux qui le justifient vraiment.

Le pattern Router

Bedrock propose une solution intégrée, mais uniquement pour le routage intra-famille. Intelligent Prompt Routing vous offre un endpoint serverless unique qui aiguille les requêtes entre modèles d'une même famille selon la complexité du prompt. Vous indiquez l'ARN d'une famille de modèles (par exemple Anthropic Claude), et Bedrock décide si chaque requête part vers Haiku ou Sonnet. AWS annonce jusqu'à 30 % de réduction des coûts — d'après ce que j'observe chez les clients, c'est un ordre de grandeur réaliste. Aucun code custom, vous remplacez simplement votre model ID par l'ARN du prompt router.

Pour le routage inter-familles (Haiku pour la classification, Mistral pour l'extraction, Sonnet pour le raisonnement complexe), il faut construire vous-même. Et honnêtement, c'est ce que font la plupart des équipes en production. Aucun framework mature sur étagère ne résout ce problème assez bien pour qu'on puisse le recommander sans réserves.

Trois patterns qui fonctionnent, classés grossièrement par maturité :

La classification basée sur des règles est le point de départ de la plupart des équipes — et beaucoup s'y arrêtent. Écrivez 5 à 10 règles à partir de signaux structurels — mots-clés du type de tâche, longueur de l'input, format de sortie attendu, profondeur de la conversation. Pas de ML, pas de dépendances, déployable en une journée. Gère correctement 70 à 80 % des décisions de routage. Quelques centaines de lignes de logique conditionnelle suffisent.

Le cascading basé sur la confiance est le pattern au meilleur ROI que j'aie vu. Envoyez chaque requête au modèle le moins cher en premier. Inspectez la réponse pour repérer un langage évasif, une sortie mal formée ou des champs requis manquants. En cas d'échec, escaladez au tier suivant. Comptez environ une latence supplémentaire d'un appel modèle sur les 5 à 15 % de requêtes escaladées. Une équipe que j'ai accompagnée — une plateforme e-commerce qui traite des requêtes produits — est ainsi passée de 38 000 $/mois à 15 000 $/mois. Son taux d'escalade n'était que de 8 %. Le classifieur n'a pas besoin d'être parfait ; il doit juste avoir raison assez souvent pour que l'escalade absorbe les exceptions. Si votre taux d'escalade dépasse 25 à 30 %, corrigez le classifieur.

L'hybride règles + classifieur ML est l'étape suivante. Une fois que vous disposez de quelques semaines de trafic en production avec des résultats labellisés, entraînez un petit classifieur (DistilBERT ou régression logistique sur TF-IDF) qui ajoute moins de 5 ms de latence. Le classifieur lui-même n'ajoute que quelques millisecondes ; le vrai coût, c'est la discipline d'ingénierie pour labelliser les données et réentraîner périodiquement. Les équipes qui le font font typiquement passer leur précision de routage de ~78 % à ~91 %.

J'ai sérieusement examiné les frameworks existants. RouteLLM, de l'équipe LMSys, s'appuie sur la recherche mais reste fondamentalement un routeur à deux modèles entraîné sur des données de chat généralistes — pour des workloads Bedrock spécifiques à un domaine, il faudrait le réentraîner. LiteLLM est excellent côté infrastructure (API unifiée, fallbacks, retries) mais son routage relève du load balancing, pas de la sélection de modèle basée sur la qualité. Aucun n'est une solution clé en main pour le problème inter-familles.

Commencez par Intelligent Prompt Routing. Quand vous aurez la preuve que le routage inter-familles permet des économies significatives, construisez un classifieur basé sur des règles. C'est prévisible, débogable, et les équipes que j'accompagne sur cette voie rapportent systématiquement 40 à 70 % de réduction des coûts.

Benchmarker la qualité du modèle face à son coût

Ne partez pas du principe qu'il vous faut le modèle le plus cher. Exécutez vos vraies tâches sur plusieurs modèles et mesurez la précision sur votre cas d'usage spécifique, le coût par tâche (et non par token), et la latence.

Nous avons fait l'exercice avec le client en services financiers. Sa tâche de classification de tickets atteignait 94 % de précision sur Haiku contre 97 % sur Sonnet — pour 1/15ᵉ du coût. Cet écart de 3 % n'avait aucune importance pour leur cas d'usage. Les chiffres varieront pour le vôtre, mais le schéma est constant : benchmarkez avant de vous engager.

Automatiser l'évaluation de la qualité avec LLM-as-a-judge

Pour la classification ou l'extraction, vous pouvez valider la qualité de manière programmatique. Mais pour la génération ouverte — résumés, explications, réponses clients — le scoring impliquait traditionnellement des relecteurs humains. Cela ne passe pas à l'échelle.

Bedrock propose une réponse intégrée : LLM-as-a-judge model evaluation. Vous fournissez un jeu de données de prompts (avec ou sans réponses de référence), choisissez un modèle évaluateur, et Bedrock fait passer les sorties du modèle candidat devant le juge sur des métriques comme l'exactitude, la complétude, l'utilité, la cohérence, la pertinence et la sécurité. Cela tourne comme un job géré — vous récupérez les scores par prompt et les agrégats, stockés dans S3.

L'objectif est de prouver qu'un modèle 5 à 15 fois moins cher par token est suffisamment bon avant de basculer du vrai trafic. Préparez un fichier JSONL avec vos prompts représentatifs, lancez le même job d'évaluation sur Haiku, Sonnet et tout autre modèle envisagé, puis comparez les scores côte à côte. AWS a publié un tutoriel avec exemples de code ainsi qu'un notebook Jupyter compagnon sur GitHub.

Quelques leçons tirées de l'utilisation de cet outil avec des clients.

Utilisez le même modèle évaluateur sur l'ensemble des comparaisons — si vous jugez la sortie de Haiku avec un modèle et celle de Sonnet avec un autre, vous mesurez les écarts entre évaluateurs, pas entre modèles.

Incluez vos vrais prompts de production, pas des benchmarks génériques. MT-Bench convient pour un sanity check, mais vos prompts de classification de tickets se comporteront différemment de questions-réponses académiques.

L'évaluation elle-même coûte de l'argent (le modèle juge traite chaque sortie), donc commencez avec 200 à 500 prompts représentatifs plutôt qu'avec tout votre dataset. C'est généralement suffisant pour voir si le modèle bon marché est clairement moins bon, clairement à la hauteur, ou à creuser davantage.

Les réponses de référence (ground truth) sont optionnelles mais précieuses — pour les tâches dont vous connaissez les sorties attendues, les métriques de fidélité et d'exactitude prennent tout leur sens.

benchmark_bedrock.py capture le coût et la latence ; LLM-as-a-judge note la qualité. Lancez les deux et vous avez la vue complète coût-qualité sans relecture manuelle.

Prompt caching : 90 % d'économies sur les contextes récurrents

Je suis surpris du peu d'équipes qui l'activent. Les input tokens mis en cache sont facturés 90 % moins cher que le tarif standard.

Lorsque vous envoyez une requête avec le caching activé, Bedrock stocke le préfixe de votre prompt. Les requêtes suivantes qui partagent ce préfixe touchent le cache. Les hits sur le cache coûtent environ 10 % du tarif normal. Les écritures dans le cache (première requête) coûtent légèrement plus cher, donc cela ne fait économiser de l'argent que si vous réutilisez le même préfixe plusieurs fois — mais avec un system prompt ou des few-shot examples, le retour sur investissement est immédiat.

Les cas où ça brille : system prompts de plus de 1 500 tokens, few-shot examples statiques, contexte documentaire partagé dans les applications RAG, historique de conversations multi-tours.

Le calcul est saisissant. Un system prompt de 2 000 tokens avec 10 000 requêtes/jour sur Claude Sonnet :

53 $/jour. Plus de 1 500 $/mois. Sur le seul system prompt. J'ai déroulé ce calcul avec un client le mois dernier et il a activé le caching avant la fin de notre appel.

Quelques pièges à garder en tête :

• La longueur minimale du préfixe cacheable varie selon le modèle (typiquement 1 024 à 2 048 tokens)
• Correspondance exacte du préfixe — les espaces et l'ordre comptent
• TTL / expiration après inactivité (votre cache se refroidit si le trafic chute)
• Tous les modèles ne supportent pas encore le caching — vérifiez la documentation à jour

Construire un framework de benchmarking

Vos décisions d'optimisation doivent être pilotées par des données issues de vos vrais workloads. Voici ce que mon équipe recommande.

Pour chaque modèle et configuration testés, capturez : coût par tâche, nombre de tokens input/output, latence (time to first token et durée totale) et un score de qualité spécifique à la tâche.

La marche à suivre : choisissez 3 à 5 tâches représentatives de votre mix de workloads, créez 100 à 500 exemples de test par tâche avec des sorties de référence, exécutez chaque tâche sur chaque modèle candidat, calculez le coût par tâche (et non par token — les modèles tokenisent différemment), et tracez le coût en fonction de la qualité pour repérer le point d'inflexion. Même un nuage de points approximatif suffit — vous cherchez même qualité, beaucoup moins cher ou qualité légèrement inférieure, drastiquement moins cher.

J'ai préparé un script Python (benchmark_bedrock.py) qui automatise tout ça — il exécute des prompts sur plusieurs modèles Bedrock, enregistre le nombre de tokens et la latence, produit un CSV et affiche les statistiques de synthèse. Forkez-le, adaptez-le à vos workloads.

Pour interpréter les résultats, cherchez les modèles où la qualité plafonne (Haiku à 93 % vs Sonnet à 95 % — ces 2 % valent-ils 10x ?), les valeurs aberrantes en latence, les écarts d'efficacité tokenisation (un modèle moins cher au token mais 2x plus verbeux n'est pas réellement moins cher), et les candidats au batch.

Visibilité unifiée des coûts GenAI avec DoiT GenAI Intelligence

La plupart des équipes que j'accompagne ne tournent pas qu'avec Bedrock. Elles utilisent OpenAI pour certains workloads, Anthropic en direct pour d'autres, peut-être Vertex AI dans un projet GCP. Les données de coût finissent éparpillées sur quatre consoles aux dimensions incompatibles.

Nous avons construit GenAI Intelligence pour résoudre ce problème. L'outil consolide les données de coût et d'usage IA de Bedrock, Vertex AI, Azure ML, Databricks, Anthropic et OpenAI dans une vue unique normalisée. Vos dépenses Bedrock apparaissent à côté de tout le reste. Aucun ETL custom.

Pour Bedrock, la valeur réside dans les labels normalisés. Model / Model Family suit le coût par modèle entre fournisseurs. Usage Type ventile les dépenses input vs output tokens — la séparation que la plupart des équipes sous-estiment. Cached indique si les opérations ont utilisé des tokens en cache, ce qui permet de mesurer le ROI du caching à partir des données de facturation. GenAI Spend signale tous les coûts d'IA générative quel que soit le fournisseur, pour un suivi budgétaire global.

Vous pouvez poser des questions du type Combien les tokens en cache sur Claude Sonnet nous ont-ils fait économiser le mois dernier ? ou Quelle est la répartition de nos dépenses entre Haiku et Sonnet pour la classification de tickets ? — entre fournisseurs, dans un seul endroit.

Le dashboard est livré avec des rapports prédéfinis : dépenses par fournisseur (mensuelles), coût par famille de modèles (quotidien sur les 14 derniers jours — détecte rapidement les pics), répartition des tokens par modèle (30 jours) et utilisation horaire des tokens par fournisseur (2 derniers jours — utile pour corréler avec les déploiements). Comme les données GenAI alimentent notre moteur Cloud Analytics, vous bénéficiez aussi de budgets, allocations, détection d'anomalies et prévisions sur vos dépenses IA.

Imaginons que vous utilisiez Haiku pour la classification et Sonnet pour le raisonnement, avec le caching activé sur les deux :

Le taux de cache hit de Haiku est solide (60 % des tokens en cache). Celui de Sonnet est faible (40 %). Corriger le caching de Sonnet pourrait économiser des centaines de dollars par mois — et vous l'avez repéré sans écrire la moindre requête CloudWatch.

Pour démarrer : connectez votre compte AWS à DoiT, allez dans Dashboards → GenAI Intelligence, et vos données Bedrock se peuplent automatiquement. Aucune instrumentation nécessaire côté Bedrock.

Observabilité avec OpenTelemetry

Le benchmarking vous donne un instantané à un moment donné. Les workloads en production dérivent — les prompts changent, les patterns de trafic évoluent, de nouveaux modèles sortent. GenAI Intelligence couvre la facturation dans la visibilité continue. Pour l'instrumentation au niveau applicatif — latence, décisions de routage, cache hits par requête — je recommande OpenTelemetry.

Les conventions sémantiques GenAI font que tout backend compatible OTel (Grafana, Datadog, Honeycomb) comprendra vos spans. Encapsulez chaque invocation Bedrock dans un span avec ces attributs :

• gen_ai.system — "aws.bedrock"
• gen_ai.request.model — l'ID du modèle
• gen_ai.usage.input_tokens / output_tokens — issus des métadonnées de réponse
• gen_ai.usage.cost — calculé à partir de votre table de tarification
• task.type — le nom de la tâche au niveau applicatif

Ce que vous obtenez : tendances coût-par-tâche dans le temps (détecte la dérive de prompt avant qu'elle n'impacte votre facture), validation du routage de modèles (le Tier 1 d'un client gérait 40 % du trafic au lieu des 70 % attendus — un bug qui coûtait 800 $/mois en plus), et monitoring du taux de cache hit (détecter les chutes en quelques heures, et non en fin de cycle de facturation).

Vous obtenez aussi les données pour les corréler avec ModelUnitUtilization de CloudWatch dans vos décisions de provisioned throughput.

Instrumentation minimale :

from opentelemetry import trace

tracer = trace.get_tracer("bedrock-client")

def invoke_with_telemetry(client, model_id, prompt, max_tokens, task_type="unknown"):
    with tracer.start_as_current_span("bedrock.invoke") as span:
        span.set_attribute("gen_ai.system", "aws.bedrock")
        span.set_attribute("gen_ai.request.model", model_id)
        span.set_attribute("gen_ai.request.max_tokens", max_tokens)
        span.set_attribute("task.type", task_type)

        resp = client.invoke_model(modelId=model_id, body=body, contentType="application/json")
        data = json.loads(resp["body"].read())

        in_tok = data["usage"]["input_tokens"]
        out_tok = data["usage"]["output_tokens"]
        span.set_attribute("gen_ai.usage.input_tokens", in_tok)
        span.set_attribute("gen_ai.usage.output_tokens", out_tok)

        return data

À partir de là, construisez quatre panneaux — coût quotidien par modèle, coût par tâche par modèle, taux de cache hit, latence p50/p95 — et passez-les en revue chaque semaine.

Pièges courants

Les erreurs que je rencontre le plus souvent, grossièrement classées par ordre de gaspillage financier :

Surveillez l'utilisation du provisioned throughput chaque semaine. Sous 50 % de manière soutenue ? Repassez en on-demand. Cette entreprise de médias gaspillait plus en capacité provisioned inutilisée que ce qu'elle dépensait en inférence réelle.

Modélisez et plafonnez les output tokens. Les output tokens coûtent 3 à 5 fois plus cher que les input. Une équipe a réduit ses coûts d'output de 40 % juste en ajoutant réponds en JSON, sans explications à ses prompts d'extraction.

Passez en batch tout ce qui n'a pas besoin d'une latence inférieure à 24 h. 50 % de remise. Aucun compromis sur la qualité.

Ne laissez pas Sonnet s'imposer par défaut. L'utiliser pour tout parce qu'il marchait pendant le prototypage est la forme de surdépense la plus courante que je vois.

Activez le caching partout où vous réutilisez des prompts. System prompt statique ou few-shot examples ? Quelques minutes de travail, économies immédiates.

Mesurez par tâche, pas par token. Un modèle moins cher au token mais qui produit une sortie plus verbeuse peut coûter plus cher par tâche. Benchmarkez au niveau de la tâche.

Tout mettre bout à bout

Le parcours d'optimisation que je propose à la plupart des équipes :

1. Batch inference — basculer les workloads asynchrones. 50 % d'économies immédiates, aucun impact sur la qualité.
2. Prompt caching — activer pour les contextes récurrents. Quelques minutes de travail.
3. Benchmarker des modèles alternatifs — vous découvrirez probablement que 60 à 80 % de votre workload tourne très bien sur le Tier 1.
4. Routage de modèles — construire un classifieur. Commencez par des règles.
5. Provisioned throughput — uniquement après que les étapes ci-dessus sont stabilisées et votre usage prévisible.

Ces leviers se cumulent. Le client en services financiers évoqué en intro ? Il a réalisé les étapes 1 à 4 en six semaines. Le batch inference a fait économiser 22 %. Le caching, 18 %. Le routage de modèles, 25 % supplémentaires. Total : passage de 40 000 $ à 18 000 $.

Ce n'est pas un projet ponctuel pour autant. Le paysage Bedrock évolue en permanence. Quand Claude 3.5 Haiku est sorti, il était nettement meilleur que Claude 3 Haiku au même tarif environ — les équipes qui avaient codé en dur des model IDs ont raté la mise à niveau pendant des mois. AWS a ajusté la tarification Bedrock à plusieurs reprises sans grand tapage. Et votre workload lui-même dérive : les prompts s'allongent, de nouveaux types de tâches apparaissent, les ratios de trafic évoluent.

Ce qui fonctionne : une revue trimestrielle légère. Refaites tourner vos benchmarks face à tout nouveau modèle (un après-midi suffit avec le script de benchmarking). Utilisez LLM-as-a-judge pour valider que la qualité n'a pas régressé. Vérifiez vos dashboards OTel pour repérer les dérives de routage — le Tier 1 absorbe-t-il toujours le pourcentage de trafic attendu ? Votre taux de cache hit a-t-il bougé ?

Si vous êtes chez DoiT, GenAI Intelligence vous montrera des tendances de coût-par-modèle qui rendent évident tout changement. Une fois la première revue effectuée, l'exercice complet ne prend qu'une demi-journée.

L'entreprise de médias mentionnée plus haut a découvert lors d'une de ces revues qu'un changement de prompt avait silencieusement fait chuter son taux de cache hit de 94 % à 61 % — 2 000 $/mois supplémentaires que personne n'avait remarqués.

Si vous êtes sur Bedrock aujourd'hui et voulez un second regard sur votre facture, c'est avec plaisir — surtout si vous êtes en APAC. Et si vous êtes déjà client DoiT, vous avez le dashboard GenAI Intelligence — utilisez-le comme point de départ pour cette revue trimestrielle.

Le script de benchmarking évoqué dans cet article est disponible à l'adresse https://github.com/p-obrien/bedrock-cost-model-blog. Lancez-le sur vos propres workloads pour générer les données nécessaires à des décisions éclairées.