Cloud Intelligence™
Votre facture Agent-as-a-Service est arrivée. À vous d'expliquer les unit economics
Vous avez lancé l'agent. Vos clients l'adorent. La facture est tombée. Votre CFO veut le coût de service par tenant — et vous n'avez qu'un seul chiffre sous les yeux
Cette page est également disponible en English, Deutsch, Español, Italiano, 日本語 et Português.
Co-rédigé avec Matías Battaglia Romano
Vous avez construit un produit basé sur un agent avec Amazon Bedrock AgentCore, et quelque chose dans votre workload vous a fait quitter le runtime microVM par défaut pour les Runtime Instances : rendu GPU, sessions qui durent plusieurs jours, jeux de données volumineux en mémoire, ou l'obligation de tout garder dans un environnement cloisonné.
Puis la première vraie facture arrive et quelqu'un demande quelle est votre marge brute par tenant.
Votre équipe pricing a besoin du coût par tâche, de la marge par compte et de la refacturation par client. Impossible de les produire à partir de ce qu'AWS vous fournit.
L'angle mort de l'attribution des coûts
Pour bien comprendre, prenons l'exemple d'un agent de rendu 3D proposé en tant que service. Les clients décrivent des scènes en langage naturel, votre agent raisonne sur la composition (Bedrock), puis génère une image photoréaliste par ray tracing (GPU).
Deux clients.
- Cabinet d'architecture : 15 K tokens + 12 min de rendu GPU → 8,40 $/tâche
- Entreprise e-commerce : 2 K tokens + 18 s de rendu GPU → 0,03 $/tâche
Un écart de 1 à 280 sur le coût de service, pour un même produit.
Votre facture affiche :
Bedrock — Claude Opus 4.5: $12,400EC2 (g5.xlarge, managed): $8,600Deux lignes. Impossible de refacturer l'usage ou de calculer la marge par compte — et la situation ne fait qu'empirer en passant de 2 à 1 000 tenants.
AWS fournit les briques. À vous de les assembler.
AWS propose une attribution granulaire des coûts Bedrock via les principals IAM, des patterns de multi-tenancy AgentCore avec des tags tenant au niveau session, et des exports d'Observability vers CloudWatch. Mais obtenir un coût par tâche de bout en bout exige la configuration des identités, des tags de session IAM, l'activation des tags d'allocation de coûts, l'export des métriques d'Observability, des requêtes CloudWatch Logs Insights, et l'assemblage des données CUR avec votre logique de tarification.
C'est un vrai projet d'ingénierie — et un projet que vous maintiendrez indéfiniment.
Une autre approche : mesurer depuis les couches basses
Attribute déploie un capteur eBPF sur vos instances EC2 AgentCore. Il observe les appels d'API Bedrock au niveau du noyau et associe chacun d'eux au tenant qui l'a déclenché. Il voit aussi le calcul GPU, l'inférence de modèles locaux et les I/O réseau sur cette instance. Aucun code de facturation ou d'attribution dans votre application. Pas de pipelines SQS ni de tables DynamoDB. Il s'appuie toujours sur les données CUR pour la réconciliation des coûts, mais la logique d'attribution — propager le contexte tenant à travers la stack — est prise en charge par le capteur, pas par votre application.
Un capteur, un dashboard : le tenant A a consommé 2 100 $ d'inférence + 340 heures GPU. Le tenant B, 48 $ + 2 heures GPU. Vous n'avez pas construit de pipeline. C'est le noyau qui a tout observé.
Dans cet article, nous allons déployer un agent nécessitant un GPU, installer le capteur DoiT Attribute, générer un peu de charge, puis récupérer les coûts par tenant depuis le dashboard et l'API Attribute — sans tagging ni pipeline de facturation complexe à configurer.
Architecture
Le capacity provider d'AgentCore lance des instances à la demande, mais il s'agit d'instances EC2 managées — AgentCore les provisionne et les opère, et vous ne disposez que de permissions restreintes. À l'heure où nous écrivons ces lignes, les LaunchParameters du capacity provider n'exposent ni imageId ni userData, et vous ne pouvez pas fournir votre propre launch template. Impossible donc d'intégrer le capteur dans l'image.
Nous adoptons donc une approche événementielle : EventBridge détecte le passage d'une instance AgentCore à l'état running, déclenche une Lambda qui attend la connectivité SSM, puis installe le capteur à distance via SSM Run Command.
Remarque : le capteur commence à observer au moment de son installation, pas au démarrage de l'instance. EventBridge se déclenche sur running, la Lambda attend la connectivité SSM, puis Run Command installe le capteur — environ 50 secondes de bout en bout lors de nos tests. En pratique, le runtime de l'agent n'était pas prêt à accepter des requêtes avant que le capteur ne soit déjà installé : aucun trafic n'est donc resté non attribué.
Déploiement événementiel du capteur : EventBridge détecte les nouvelles instances AgentCore, la Lambda attend SSM, puis installe le capteur via Run Command.
L'agent accepte un en-tête HTTP x-tenant-id — l'identifiant métier que votre plateforme utilise déjà pour router les rendus vers le stockage du bon tenant et appliquer le contrôle d'accès par tenant. Le capteur Attribute capture ce même en-tête au niveau de l'OS et s'en sert pour attribuer les coûts de calcul et d'IA au tenant d'origine.
L'agent : Strands SDK + Blender sur GPU
L'agent de rendu 3D est construit avec le Strands Agents SDK et déployé via BedrockAgentCoreApp.
app = BedrockAgentCoreApp(debug=True)
@tooldef generate_scene_description(prompt: str) -> str: """Return a structured scene graph (objects, materials, lighting, camera).""" ...
@tooldef render_scene(scene_graph_json: str) -> str: """Execute Blender Cycles GPU ray-trace render via subprocess.""" ...
@app.entrypointdef invoke(payload: dict, context: RequestContext): tenant_id = get_tenant_id_from_headers(context.request_headers) prompt = payload.get("prompt")
agent = Agent( model=BedrockModel(model_id="us.anthropic.claude-opus-4-5-20251101-v1:0"), tools=[generate_scene_description, render_scene], ) agent(prompt)Le code source complet de l'agent, ainsi que les templates Terraform, sont disponibles dans ce repo.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Déploiement : un seul terraform apply
L'ensemble de la stack — capacity provider, runtime de l'agent, pipeline d'auto-déploiement du capteur — se déploie avec un seul terraform apply. Configurez votre terraform.tfvars :
aws_region = "us-west-2"agent_source_dir = "../agent-3d-render"agent_s3_bucket = "your-bucket-name"allowed_instance_types = ["g5.xlarge", "g5.2xlarge"]ebs_volume_size = 100sensor_token = "your-attribute-token" # from Attribute dashboardsensor_workload_name = "3d-render-agent"session_max_duration = 86400 # 24 hours; AgentCore allows up to 14 daysPuis :
cd terraformterraform initterraform applyTester l'attribution des coûts par tenant
Le repo inclut un script de test multi-tenant (agent-3d-render/scripts/tenant_test.py) qui envoie des prompts de rendu depuis deux tenants différents vers le même runtime d'agent, avec de vrais en-têtes HTTP x-tenant-id :
AGENT_RUNTIME_ARN=arn:aws:bedrock-agentcore:us-west-2:ACCOUNT:runtime/NAME \ python3 agent-3d-render/scripts/tenant_test.pyLe script envoie plusieurs requêtes de rendu au nom de deux tenants, chacun avec des prompts de scène différents :
=== TENANT: acme-architects ===--- request 1/2: Design a futuristic glass skyscraper at sunset with dramatic orange lightingOK (142.3s) tenant_id_echoed=acme-architects--- request 2/2: A luxury sports car showroom with reflective marble floors and spotlightsOK (87.1s) tenant_id_echoed=acme-architects
=== TENANT: globex-gamestudio ===--- request 1/2: A fantasy castle on a cliff with dragons flying overhead in stormy weatherOK (98.7s) tenant_id_echoed=globex-gamestudio--- request 2/2: A cyberpunk city street at night with neon signs and rain reflectionsOK (112.4s) tenant_id_echoed=globex-gamestudioLe résultat : une visibilité des coûts par tenant
Quatre rendus, deux tenants. Voici ce qu'il a coûté de servir chacun d'eux :
Attribution des coûts par tenant à partir de l'en-tête x-tenant-id — sans tags d'allocation de coûts ni code de facturation.
Le détail d'un tenant montre la ventilation des coûts par type de ressource.
Récupérer les données d'attribution des coûts par tenant via l'API
Les dashboards sont faits pour les humains. Si vous alimentez un système de facturation, vous voudrez récupérer ces données par programmation :
curl -s -H "Authorization: Bearer $ATTRIBUTE_TOKEN" \ "https://api.app.attrb.io/api/v1/identifiers/daily/<date>"Lancez-vous
Le repo complet — Terraform, code de l'agent, scripts de test — est open source. Clonez-le, renseignez votre token Attribute, lancez terraform apply, et vous aurez une visibilité des coûts par tenant avant l'arrivée de votre prochaine facture.
Une fois vos tests terminés, détruisez la stack. La configuration ci-dessus limite les sessions à 24 heures, mais AgentCore autorise jusqu'à 14 jours — et une instance GPU oubliée est un souvenir qui coûte cher :
terraform destroyQuestions fréquentes
Qu'est-ce que l'attribution des coûts dans Bedrock AgentCore ?
L'attribution des coûts dans Bedrock AgentCore consiste à rattacher les dépenses d'inférence Bedrock et le calcul GPU sur les Runtime Instances au tenant, au client ou au workload qui les a générés. La facturation d'AgentCore affiche des lignes agrégées pour Bedrock et EC2, sans ventilation par tenant, si bien que l'attribution nécessite soit les outils natifs de tagging d'AWS, soit une couche d'observation distincte.
Peut-on installer une AMI personnalisée ou un launch template sur les Runtime Instances AgentCore ?
Non. Le capacity provider d'AgentCore gère directement les instances EC2 sous-jacentes et, à l'heure où nous écrivons ces lignes, son API LaunchParameters n'expose ni champ imageId ni champ userData, et n'accepte pas de launch template personnalisé. Tout logiciel devant s'exécuter sur l'instance, y compris un capteur d'attribution des coûts, doit être installé après le passage de l'instance à l'état running, plutôt qu'intégré à l'image au lancement.
Comment attribuer les coûts AWS Bedrock par tenant sans tags d'allocation de coûts ?
Un capteur eBPF déployé sur l'instance peut observer les appels d'API Bedrock, le calcul GPU et les I/O réseau au niveau du noyau, indépendamment de tout tagging ou logging effectué par votre code applicatif. Si votre agent transmet déjà un identifiant de tenant, comme un en-tête x-tenant-id, le capteur peut capturer ce même identifiant et lui attribuer directement les dépenses observées, sans tags de session IAM ni pipelines de réconciliation basés sur le CUR.
Quelle est la différence entre l'attribution native des coûts Bedrock d'AWS et l'approche par capteur eBPF ?
La voie native d'AWS repose sur le tagging des principals IAM, des tags tenant au niveau session et les données du Cost and Usage Report assemblées avec votre propre logique de tarification. C'est une vraie solution, mais c'est un projet d'ingénierie que vous maintenez indéfiniment. Un capteur eBPF observe les mêmes signaux depuis l'extérieur de votre application : la logique d'attribution vit dans le capteur plutôt que dans du code à mettre à jour à chaque évolution de votre agent.
À quel point le coût GPU varie-t-il d'un tenant à l'autre sur un même agent ?
Il peut varier de plusieurs ordres de grandeur, même sur une infrastructure identique. Dans l'exemple de rendu de cet article, une tâche d'un tenant a coûté 8,40 $ en raison d'un rendu GPU de 12 minutes, tandis qu'une tâche d'un autre tenant a coûté 0,03 $ avec un rendu de 18 secondes — un écart de 1 à 280 dû uniquement au profil d'usage et non à la tarification.
Si vous exécutez des agents sur AgentCore et souhaitez voir ce que donne Attribute dans votre propre environnement, réservez une démo.
