Cloud Intelligence™
La fattura del Suo Agent-as-a-Service è arrivata. Ora tocca spiegare la unit economics
L'agente è in produzione. I clienti lo adorano. La fattura è arrivata. Il CFO vuole il cost-to-serve per tenant — e Lei ha davanti un solo numero
Questa pagina è disponibile anche in English, Deutsch, Español, Français, 日本語 e Português.
Scritto in collaborazione con Matías Battaglia Romano
Ha costruito un prodotto ad agenti su Amazon Bedrock AgentCore, e qualcosa nel workload L'ha spinta ad abbandonare il runtime microVM predefinito in favore delle Runtime Instances: rendering GPU, sessioni che durano giorni, grandi dataset in memoria o la necessità di mantenere tutto in un walled garden.
Poi arriva la prima vera fattura e qualcuno chiede quale sia il vostro margine lordo per tenant.
Il Suo team di pricing ha bisogno del costo per task, del margine per account e del chargeback per cliente. Con ciò che AWS Le fornisce, non può produrre nessuno di questi dati.
Il gap nell'attribuzione dei costi
Per capire meglio, prendiamo come esempio un agente di rendering 3D erogato as a service. I clienti descrivono le scene in linguaggio naturale, l'agente ragiona sulla composizione (Bedrock) e poi genera un'immagine fotorealistica in ray-tracing (GPU).
Due clienti.
- Studio di architettura: 15K token + 12 min di rendering GPU → 8,40 $/task
- Azienda e-commerce: 2K token + 18 sec di rendering GPU → 0,03 $/task
Un divario di 280x nel cost-to-serve, sullo stesso prodotto.
La Sua fattura mostra:
Bedrock — Claude Opus 4.5: $12,400EC2 (g5.xlarge, managed): $8,600Due voci. Nessun modo di riaddebitare i consumi o calcolare il margine per account — e la situazione non fa che peggiorare passando da 2 tenant a 1.000.
AWS Le fornisce i pezzi. L'assemblaggio tocca a Lei.
AWS offre l'attribuzione granulare dei costi Bedrock tramite principal IAM, pattern di multi-tenancy per AgentCore con tag tenant a livello di sessione ed export di Observability verso CloudWatch. Ma per un cost-per-task end-to-end servono configurazione delle identità, tag di sessione IAM, attivazione dei cost allocation tag, export delle metriche di Observability, query CloudWatch Logs Insights e l'integrazione dei dati CUR con la logica di pricing.
Si tratta di un progetto ingegneristico impegnativo — e di un progetto da mantenere per sempre.
La risposta alternativa: misurare dal basso
Attribute installa un sensore eBPF sulle istanze EC2 di AgentCore. Osserva le chiamate API a Bedrock a livello di kernel e associa ciascuna al tenant che l'ha generata. Vede inoltre il compute GPU, l'inferenza dei modelli locali e l'I/O di rete su quell'istanza. Nessun codice di billing o di attribuzione nella Sua applicazione. Nessuna pipeline SQS né tabelle DynamoDB. I dati CUR vengono comunque utilizzati per la riconciliazione dei costi, ma la logica di attribuzione — propagare il contesto del tenant lungo tutto lo stack — è gestita dal sensore, non dalla Sua app.
Un sensore, una dashboard: il Tenant A ha consumato 2.100 $ di inferenza + 340 ore GPU. Il Tenant B ha consumato 48 $ + 2 ore GPU. Lei non ha costruito nessuna pipeline. Lo ha osservato il kernel.
In questo post effettueremo il deploy di un agente che richiede GPU, installeremo il sensore DoiT Attribute, genereremo un po' di workload e recupereremo i costi per tenant dalla dashboard e dall'API di Attribute — senza tagging e senza configurare una complessa pipeline di billing.
Architettura
Il capacity provider di AgentCore avvia nuove istanze on demand, ma si tratta di istanze EC2 gestite — è AgentCore a effettuarne il provisioning e la gestione operativa, e Lei dispone solo di permessi limitati su di esse. Al momento della stesura di questo articolo, i LaunchParameters del capacity provider non espongono né imageId né userData, e non è possibile fornire un launch template personalizzato. Non si può integrare il sensore nell'immagine.
Adottiamo quindi un approccio event-driven: EventBridge rileva quando un'istanza AgentCore entra nello stato running, attiva una Lambda che attende la connettività SSM e poi installa il sensore da remoto tramite SSM Run Command.
Nota: il sensore inizia a osservare quando viene installato, non all'avvio dell'istanza. EventBridge si attiva su running, la Lambda attende la connettività SSM e poi Run Command installa il sensore — circa 50 secondi end-to-end nei nostri test. In pratica, il runtime dell'agente non era pronto ad accettare richieste finché il sensore non era già installato, quindi nessun traffico è rimasto senza attribuzione.
Deployment event-driven del sensore: EventBridge rileva le nuove istanze AgentCore, la Lambda attende SSM e poi installa il sensore tramite Run Command.
L'agente accetta un header HTTP x-tenant-id — l'identificativo di business che la Sua piattaforma già utilizza per indirizzare gli output renderizzati verso lo storage del tenant corretto e applicare il controllo degli accessi per tenant. Il sensore Attribute cattura questo stesso header a livello di sistema operativo e lo usa per attribuire i costi di compute e AI al tenant di origine.
L'agente: Strands SDK + Blender su GPU
L'agente di rendering 3D è costruito con lo Strands Agents SDK e distribuito tramite 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)Il codice sorgente completo dell'agente e i template Terraform sono disponibili in questo repository.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Deployment: un unico Terraform Apply
L'intero stack — capacity provider, runtime dell'agente, pipeline di auto-deploy del sensore — si distribuisce con un singolo terraform apply. Configuri il Suo 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 daysPoi:
cd terraformterraform initterraform applyTestare l'attribuzione dei costi per tenant
Il repository include uno script di test multi-tenant (agent-3d-render/scripts/tenant_test.py) che invia prompt di rendering da due tenant diversi verso lo stesso runtime dell'agente, usando veri header HTTP x-tenant-id:
AGENT_RUNTIME_ARN=arn:aws:bedrock-agentcore:us-west-2:ACCOUNT:runtime/NAME \ python3 agent-3d-render/scripts/tenant_test.pyLo script invia più richieste di rendering come due tenant, ciascuno con prompt di scena diversi:
=== 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-gamestudioIl risultato: visibilità dei costi per tenant
Quattro rendering, due tenant. Ecco quanto è costato servire ciascuno dei due:
Attribuzione dei costi per tenant a partire dall'header x-tenant-id — senza cost allocation tag né codice di billing.
Il drill-down su un tenant mostra la ripartizione dei costi per tipo di risorsa.
Ottenere i dati di attribuzione dei costi per tenant dall'API
Le dashboard sono pensate per le persone. Se deve alimentare un sistema di billing, questi dati Le servono in forma programmatica:
curl -s -H "Authorization: Bearer $ATTRIBUTE_TOKEN" \ "https://api.app.attrb.io/api/v1/identifiers/daily/<date>"Come iniziare
Il repository completo — Terraform, codice dell'agente, script di test — è open source. Lo cloni, imposti il Suo token Attribute, esegua terraform apply e avrà visibilità dei costi per tenant prima dell'arrivo della prossima fattura.
Al termine dei test, smantelli tutto. La configurazione qui sopra limita le sessioni a 24 ore, ma AgentCore consente fino a 14 giorni — e un'istanza GPU dimenticata è un souvenir costoso:
terraform destroyDomande frequenti
Che cos'è l'attribuzione dei costi in Bedrock AgentCore?
L'attribuzione dei costi in Bedrock AgentCore significa ricondurre la spesa di inferenza Bedrock e il compute GPU sulle Runtime Instances al tenant, cliente o workload specifico che li ha generati. La fatturazione nativa di AgentCore mostra voci aggregate per Bedrock ed EC2, non una ripartizione per tenant, quindi l'attribuzione richiede gli strumenti di tagging nativi di AWS oppure un livello di osservazione separato.
È possibile installare un'AMI personalizzata o un launch template sulle Runtime Instances di AgentCore?
No. Il capacity provider di AgentCore gestisce direttamente le istanze EC2 sottostanti e, al momento della stesura di questo articolo, la sua API LaunchParameters non espone né imageId né il campo userData, e non accetta un launch template personalizzato. Qualsiasi software che debba essere eseguito sull'istanza, compreso un sensore di attribuzione dei costi, va installato dopo che l'istanza ha raggiunto lo stato running, anziché essere integrato nell'immagine al lancio.
Come si attribuiscono i costi di AWS Bedrock per tenant senza cost allocation tag?
Un sensore eBPF installato sull'istanza può osservare le chiamate API a Bedrock, il compute GPU e l'I/O di rete a livello di kernel, indipendentemente da qualsiasi tagging o logging effettuato dal codice applicativo. Se l'agente passa già un identificativo del tenant, come un header x-tenant-id, il sensore può catturare quello stesso identificativo e attribuirgli direttamente la spesa osservata, senza tag di sessione IAM né pipeline di riconciliazione basate sul CUR.
Qual è la differenza tra l'attribuzione nativa dei costi Bedrock di AWS e l'approccio con sensore eBPF?
Il percorso nativo di AWS utilizza il tagging dei principal IAM, tag tenant a livello di sessione e i dati del Cost and Usage Report combinati con la propria logica di pricing. È una soluzione reale, ma è un progetto ingegneristico da mantenere a tempo indeterminato. Un sensore eBPF osserva gli stessi segnali dall'esterno dell'applicazione, quindi la logica di attribuzione risiede nel sensore anziché in codice da aggiornare continuamente man mano che l'agente cambia.
Quanto può variare il costo GPU per tenant sullo stesso agente?
Può variare di ordini di grandezza anche su infrastruttura identica. Nell'esempio di rendering di questo post, il task di un tenant è costato 8,40 $ a causa di un rendering GPU di 12 minuti, mentre il task di un altro tenant è costato 0,03 $ con un rendering di 18 secondi: una differenza di 280x determinata interamente dal pattern di utilizzo e non dal pricing.
Se esegue agenti su AgentCore e vuole vedere come si presenta Attribute nel Suo ambiente, prenoti una demo.
