Cloud Intelligence™
A fatura do seu Agent-as-a-Service chegou. Agora explique os unit economics
Você lançou o agente. Os clientes adoraram. A fatura chegou. Seu CFO quer o custo para atender cada tenant — e você está diante de um único número
Esta página também está disponível em English, Deutsch, Español, Français, Italiano e 日本語.
Escrito em coautoria com Matías Battaglia Romano
Você construiu um produto de agente no Amazon Bedrock AgentCore, e algo no workload tirou você do runtime padrão de microVMs e levou às Runtime Instances: renderização em GPU, sessões que rodam por dias, grandes datasets em memória ou a exigência de manter tudo em um ambiente fechado (walled garden).
Então a primeira fatura de verdade chega e alguém pergunta qual é a sua margem bruta por tenant.
Seu time de precificação precisa de custo por tarefa, margem por conta e chargeback por cliente. Com o que a AWS fornece, você não consegue produzir nada disso.
A lacuna na atribuição de custos
Para entender em detalhes, vamos usar o exemplo de um agente de renderização 3D oferecido como serviço. Os clientes descrevem cenas em linguagem natural, o agente raciocina sobre a composição (Bedrock) e depois faz o ray-tracing de uma imagem fotorrealista (GPU).
Dois clientes.
- Escritório de arquitetura: 15 mil tokens + 12 min de renderização em GPU → US$ 8,40/tarefa
- Empresa de e-commerce: 2 mil tokens + 18 s de renderização em GPU → US$ 0,03/tarefa
Uma diferença de 280x no custo para atender, com o mesmo produto.
Sua fatura mostra:
Bedrock — Claude Opus 4.5: $12,400EC2 (g5.xlarge, managed): $8,600Duas linhas. Nenhuma forma de fazer chargeback do uso ou calcular a margem por conta — e a situação só piora ao passar de 2 para 1.000 tenants.
A AWS entrega as peças. Montar é com você.
A AWS oferece atribuição granular de custos do Bedrock via IAM principals, padrões de multi-tenancy do AgentCore com tags de tenant em nível de sessão e exportações de Observability para o CloudWatch. Mas chegar ao custo por tarefa de ponta a ponta exige configuração de identidade, tags de sessão do IAM, ativação de tags de alocação de custos, exportação de métricas de Observability, consultas no CloudWatch Logs Insights e costurar dados do CUR com lógica de precificação.
Isso é um projeto de engenharia de verdade — e um que você mantém para sempre.
A resposta diferente: medir por baixo
O Attribute implanta um sensor eBPF nas suas instâncias EC2 do AgentCore. Ele observa as chamadas à API do Bedrock no nível do kernel e mapeia cada uma ao tenant que a disparou. Também enxerga a computação em GPU, a inferência de modelos locais e o I/O de rede naquela instância. Nada de código de billing ou de atribuição na sua aplicação. Nada de pipelines de SQS ou tabelas do DynamoDB. Ele continua usando dados do CUR para reconciliação de custos, mas a lógica de atribuição — propagar o contexto do tenant por toda a stack — fica por conta do sensor, não do seu app.
Um sensor, um dashboard: o Tenant A consumiu US$ 2.100 em inferência + 340 horas de GPU. O Tenant B consumiu US$ 48 + 2 horas de GPU. Você não construiu pipeline nenhum. O kernel observou tudo.
Neste post, vamos fazer o deploy de um agente que exige GPU, instalar o sensor DoiT Attribute, gerar workload e buscar os custos por tenant no dashboard e na API do Attribute — sem tagging e sem configurar um pipeline de billing complexo.
Arquitetura
O capacity provider do AgentCore sobe instâncias novas sob demanda, mas elas são instâncias gerenciadas do EC2 — o AgentCore as provisiona e opera, e você tem permissões restritas sobre elas. No momento em que este texto foi escrito, o LaunchParameters do capacity provider não expõe imageId nem userData, e você não pode fornecer seu próprio launch template. Não dá para embutir o sensor na imagem.
Por isso, usamos uma abordagem orientada a eventos: o EventBridge detecta quando uma instância do AgentCore entra no estado running, aciona uma Lambda que aguarda a conectividade do SSM e, então, instala o sensor remotamente via SSM Run Command.
Observação: o sensor começa a observar quando é instalado, não quando a instância inicializa. O EventBridge dispara no estado running, a Lambda aguarda a conectividade do SSM e, então, o Run Command instala o sensor — cerca de 50 segundos de ponta a ponta nos nossos testes. Na prática, o runtime do agente só ficou pronto para aceitar requisições depois que o sensor já estava instalado, então nenhum tráfego ficou sem atribuição.
Deploy do sensor orientado a eventos: o EventBridge detecta novas instâncias do AgentCore, a Lambda aguarda o SSM e depois instala o sensor via Run Command.
O agente aceita um header HTTP x-tenant-id — o identificador de negócio que sua plataforma já usa para direcionar os outputs renderizados ao storage do tenant correto e aplicar o controle de acesso por tenant. O sensor do Attribute captura esse mesmo header no nível do sistema operacional e o usa para atribuir os custos de computação e IA ao tenant de origem.
O agente: Strands SDK + Blender em GPU
O agente de renderização 3D foi construído com o Strands Agents SDK e implantado 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)O código-fonte completo do agente e os templates Terraform estão disponíveis neste repositório.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Deploy: um único Terraform Apply
A stack inteira — capacity provider, runtime do agente, pipeline de auto-deploy do sensor — sobe com um único terraform apply. Configure seu 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 daysDepois:
cd terraformterraform initterraform applyTestando a atribuição de custos por tenant
O repositório inclui um script de teste multi-tenant (agent-3d-render/scripts/tenant_test.py) que envia prompts de renderização de dois tenants diferentes contra o mesmo runtime do agente, usando headers HTTP x-tenant-id reais:
AGENT_RUNTIME_ARN=arn:aws:bedrock-agentcore:us-west-2:ACCOUNT:runtime/NAME \ python3 agent-3d-render/scripts/tenant_test.pyIsso envia várias requisições de renderização como dois tenants, cada um com prompts de cena 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-gamestudioO resultado: visibilidade de custo por tenant
Quatro renderizações, dois tenants. Veja quanto custou atender cada um deles:
Atribuição de custo por tenant a partir do header x-tenant-id — sem tags de alocação de custos nem código de billing.
Ao detalhar um tenant, você vê a divisão de custos por tipo de recurso.
Obtendo os dados de atribuição de custos por tenant pela API
Dashboards são para humanos. Se você alimenta um sistema de billing, vai querer isso de forma programática:
curl -s -H "Authorization: Bearer $ATTRIBUTE_TOKEN" \ "https://api.app.attrb.io/api/v1/identifiers/daily/<date>"Comece agora
O repositório completo — Terraform, código do agente, scripts de teste — é open source. Clone, configure seu token do Attribute, rode terraform apply e você terá visibilidade de custo por tenant antes da próxima fatura chegar.
Quando terminar os testes, derrube tudo. A configuração acima limita as sessões a 24 horas, mas o AgentCore permite até 14 dias — e uma instância de GPU esquecida é uma lembrança cara:
terraform destroyPerguntas frequentes
O que é atribuição de custos no Bedrock AgentCore?
Atribuição de custos no Bedrock AgentCore significa vincular o gasto de inferência do Bedrock e a computação em GPU nas Runtime Instances ao tenant, cliente ou workload específico que os gerou. O billing do próprio AgentCore mostra itens agregados para Bedrock e EC2, não um detalhamento por tenant, então a atribuição exige as ferramentas nativas de tagging da AWS ou uma camada de observação separada.
É possível instalar uma AMI personalizada ou um launch template nas Runtime Instances do AgentCore?
Não. O capacity provider do AgentCore gerencia diretamente as instâncias EC2 subjacentes e, no momento em que este texto foi escrito, sua API LaunchParameters não expõe os campos imageId nem userData, e não aceita um launch template personalizado. Qualquer software que precise rodar na instância, incluindo um sensor de atribuição de custos, precisa ser instalado depois que a instância atinge o estado running, em vez de ser embutido na imagem no lançamento.
Como atribuir custos do AWS Bedrock por tenant sem tags de alocação de custos?
Um sensor eBPF implantado na instância consegue observar chamadas à API do Bedrock, computação em GPU e I/O de rede no nível do kernel, independentemente de qualquer tagging ou logging feito pelo código da sua aplicação. Se o seu agente já passa um identificador de tenant, como um header x-tenant-id, o sensor pode capturar esse mesmo identificador e atribuir o gasto observado diretamente a ele, sem tags de sessão do IAM nem pipelines de reconciliação baseados no CUR.
Qual a diferença entre a atribuição de custos nativa do Bedrock na AWS e a abordagem com sensor eBPF?
O caminho nativo da AWS usa tagging de IAM principals, tags de tenant em nível de sessão e dados do Cost and Usage Report costurados com a sua própria lógica de precificação. É uma solução real, mas é um projeto de engenharia que você mantém indefinidamente. Um sensor eBPF observa os mesmos sinais de fora da sua aplicação, então a lógica de atribuição fica no sensor, e não em código que você precisa continuar atualizando conforme o agente muda.
Quanto o custo de GPU varia por tenant no mesmo agente?
Pode variar em ordens de magnitude mesmo em infraestrutura idêntica. No exemplo de renderização deste post, a tarefa de um tenant custou US$ 8,40 por conta de uma renderização de 12 minutos em GPU, enquanto a tarefa de outro tenant custou US$ 0,03 com uma renderização de 18 segundos — uma diferença de 280x causada inteiramente pelo padrão de uso, e não pelo preço.
Se você roda agentes no AgentCore e quer ver como o Attribute funciona no seu próprio ambiente, agende uma demo.
