Cloud Intelligence™
Llegó tu factura de Agent-as-a-Service. Ahora explica los unit economics
Lanzaste el agente. A tus clientes les encanta. Llegó la factura. Tu CFO quiere el costo de servir a cada tenant, y tú solo ves un número
Esta página también está disponible en English, Deutsch, Français, Italiano, 日本語 y Português.
Coescrito con Matías Battaglia Romano
Construiste un producto de agentes sobre Amazon Bedrock AgentCore, y algo en el workload te sacó del runtime microVM por defecto y te llevó a las Runtime Instances: renderizado en GPU, sesiones que duran días, grandes datasets en memoria o el requisito de mantener todo en un entorno cerrado.
Entonces llega la primera factura real y alguien pregunta cuál es tu margen bruto por tenant.
Tu equipo de pricing necesita el costo por tarea, el margen por cuenta y el chargeback por cliente. Con lo que AWS te da, no puedes obtener nada de eso.
La brecha en la atribución de costos
Para entenderlo en detalle, tomemos como ejemplo un agente de renderizado 3D como servicio. Los clientes describen escenas en lenguaje natural, tu agente razona sobre la composición (Bedrock) y luego genera una imagen fotorrealista por ray tracing (GPU).
Dos clientes.
- Estudio de arquitectura: 15K tokens + 12 min de render en GPU → $8.40/tarea
- Empresa de e-commerce: 2K tokens + 18 seg de render en GPU → $0.03/tarea
Una diferencia de 280x en lo que cuesta atender a cada cliente, con el mismo producto.
Tu factura muestra:
Bedrock — Claude Opus 4.5: $12,400EC2 (g5.xlarge, managed): $8,600Dos líneas. Sin forma de hacer chargeback del uso ni de calcular el margen por cuenta, y esto solo empeora al pasar de 2 tenants a 1,000.
AWS te da las piezas. Armarlas es cosa tuya.
AWS ofrece atribución granular de costos en Bedrock mediante IAM principals, patrones de multi-tenancy en AgentCore con etiquetas de tenant a nivel de sesión y exportaciones de Observability a CloudWatch. Pero para obtener el costo por tarea de extremo a extremo necesitas configurar identidades, IAM session tags, activar cost allocation tags, exportar métricas de Observability, consultas en CloudWatch Logs Insights y cruzar los datos del CUR con tu lógica de precios.
Es un proyecto de ingeniería considerable, y uno que mantienes para siempre.
Un enfoque distinto: medir desde abajo
Attribute despliega un sensor eBPF en tus instancias EC2 de AgentCore. Observa las llamadas a la API de Bedrock a nivel del kernel y asigna cada una al tenant que la originó. También ve el cómputo en GPU, la inferencia de modelos locales y el I/O de red en esa instancia. Sin código de facturación ni de atribución en tu aplicación. Sin pipelines de SQS ni tablas de DynamoDB. Sigue usando los datos del CUR para la conciliación de costos, pero la lógica de atribución —propagar el contexto del tenant a través del stack— corre por cuenta del sensor, no de tu app.
Un sensor, un dashboard: el Tenant A consumió $2,100 en inferencia + 340 horas de GPU. El Tenant B consumió $48 + 2 horas de GPU. No construiste ningún pipeline. El kernel lo observó.
En este post vamos a desplegar un agente que requiere GPU, instalar el sensor de DoiT Attribute, generar algo de workload y consultar los costos por tenant desde el dashboard y la API de Attribute, sin etiquetar nada ni configurar un pipeline de facturación complejo.
Arquitectura
El capacity provider de AgentCore levanta instancias nuevas bajo demanda, pero se trata de instancias administradas de EC2: AgentCore las aprovisiona y las opera, y tú tienes permisos restringidos sobre ellas. Al momento de escribir esto, los LaunchParameters del capacity provider no exponen imageId ni userData, y no puedes usar tu propio launch template. No hay forma de incluir el sensor en la imagen.
Así que usamos un enfoque orientado a eventos: EventBridge detecta cuando una instancia de AgentCore entra en estado running, dispara una Lambda que espera la conectividad de SSM y luego instala el sensor de forma remota vía SSM Run Command.
Nota: el sensor empieza a observar cuando se instala, no cuando la instancia arranca. EventBridge se dispara con el estado running, la Lambda espera la conectividad de SSM y luego Run Command instala el sensor: unos 50 segundos de extremo a extremo en nuestras pruebas. En la práctica, el runtime del agente no estuvo listo para aceptar solicitudes hasta después de que el sensor ya estaba instalado, así que ningún tráfico quedó sin atribuir.
Despliegue del sensor orientado a eventos: EventBridge detecta las nuevas instancias de AgentCore, la Lambda espera a SSM y luego instala el sensor vía Run Command.
El agente acepta un encabezado HTTP x-tenant-id: el identificador de negocio que tu plataforma ya usa para enrutar los renders al almacenamiento del tenant correcto y aplicar el control de acceso por tenant. El sensor de Attribute captura ese mismo encabezado a nivel del sistema operativo y lo usa para atribuir los costos de cómputo e IA al tenant que los originó.
El agente: Strands SDK + Blender en GPU
El agente de renderizado 3D está construido con el Strands Agents SDK y se despliega mediante 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)El código fuente completo del agente, junto con las plantillas de Terraform, está disponible en este repo.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Despliegue: un solo Terraform Apply
Todo el stack —capacity provider, runtime del agente, pipeline de auto-despliegue del sensor— se despliega con un solo terraform apply. Configura tu 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 daysLuego:
cd terraformterraform initterraform applyProbar la atribución de costos por tenant
El repo incluye un script de prueba multi-tenant (agent-3d-render/scripts/tenant_test.py) que envía prompts de renderizado de dos tenants distintos contra el mismo runtime del agente, usando encabezados HTTP x-tenant-id reales:
AGENT_RUNTIME_ARN=arn:aws:bedrock-agentcore:us-west-2:ACCOUNT:runtime/NAME \ python3 agent-3d-render/scripts/tenant_test.pyEsto envía varias solicitudes de render como dos tenants, cada uno con prompts de escenas diferentes:
=== 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-gamestudioEl resultado: visibilidad de costos por tenant
Cuatro renders, dos tenants. Esto es lo que costó atender a cada uno:
Atribución de costos por tenant a partir del encabezado x-tenant-id; sin cost allocation tags ni código de facturación.
Al entrar al detalle de un tenant se ve el desglose de costos por tipo de recurso.
Cómo obtener los datos de atribución de costos por tenant desde la API
Los dashboards son para humanos. Si vas a alimentar un sistema de facturación, querrás esto de forma programática:
curl -s -H "Authorization: Bearer $ATTRIBUTE_TOKEN" \ "https://api.app.attrb.io/api/v1/identifiers/daily/<date>"Comienza ahora
El repo completo —Terraform, código del agente, scripts de prueba— es open source. Clónalo, configura tu token de Attribute, ejecuta terraform apply y tendrás visibilidad de costos por tenant antes de que llegue tu próxima factura.
Cuando termines de probar, destruye todo. La configuración anterior limita las sesiones a 24 horas, pero AgentCore permite hasta 14 días, y una instancia GPU olvidada es un recuerdo caro:
terraform destroyPreguntas frecuentes
¿Qué es la atribución de costos en Bedrock AgentCore?
La atribución de costos en Bedrock AgentCore consiste en vincular el gasto de inferencia de Bedrock y el cómputo en GPU de las Runtime Instances con el tenant, cliente o workload específico que lo generó. La facturación propia de AgentCore muestra líneas agregadas para Bedrock y EC2, no un desglose por tenant, por lo que la atribución requiere las herramientas de etiquetado nativas de AWS o una capa de observación aparte.
¿Se puede instalar una AMI personalizada o un launch template en las Runtime Instances de AgentCore?
No. El capacity provider de AgentCore administra directamente las instancias EC2 subyacentes y, al momento de escribir esto, su API de LaunchParameters no expone imageId ni userData, y no acepta un launch template personalizado. Cualquier software que deba ejecutarse en la instancia, incluido un sensor de atribución de costos, tiene que instalarse después de que la instancia alcanza el estado running, en lugar de incluirse en la imagen al arrancar.
¿Cómo se atribuyen los costos de AWS Bedrock por tenant sin cost allocation tags?
Un sensor eBPF desplegado en la instancia puede observar las llamadas a la API de Bedrock, el cómputo en GPU y el I/O de red a nivel del kernel, independientemente de cualquier etiquetado o logging que haga el código de tu aplicación. Si tu agente ya pasa un identificador de tenant, como un encabezado x-tenant-id, el sensor puede capturar ese mismo identificador y atribuirle directamente el gasto observado, sin IAM session tags ni pipelines de conciliación basados en el CUR.
¿Cuál es la diferencia entre la atribución nativa de costos de Bedrock en AWS y un enfoque con sensor eBPF?
La vía nativa de AWS usa etiquetado de IAM principals, etiquetas de tenant a nivel de sesión y datos del Cost and Usage Report cruzados con tu propia lógica de precios. Es una solución real, pero es un proyecto de ingeniería que mantienes indefinidamente. Un sensor eBPF observa las mismas señales desde fuera de tu aplicación, de modo que la lógica de atribución vive en el sensor y no en código que tienes que actualizar cada vez que tu agente cambia.
¿Cuánto varía el costo de GPU por tenant en el mismo agente?
Puede variar en órdenes de magnitud incluso sobre infraestructura idéntica. En el ejemplo de renderizado de este post, la tarea de un tenant costó $8.40 debido a un render en GPU de 12 minutos, mientras que la de otro costó $0.03 con un render de 18 segundos: una diferencia de 280x explicada únicamente por el patrón de uso y no por los precios.
Si ejecutas agentes en AgentCore y quieres ver cómo funciona Attribute en tu propio entorno, agenda una demo.
