Cloud Intelligence™
Ihre Agent-as-a-Service-Rechnung ist da. Zeit, die Unit Economics zu erklären
Der Agent ist live. Die Kunden sind begeistert. Die Rechnung ist da. Ihr CFO will die Cost-to-Serve pro Tenant – und Sie starren auf eine einzige Zahl
Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.
Gemeinsam verfasst mit Matías Battaglia Romano
Sie haben ein Agent-Produkt auf Amazon Bedrock AgentCore gebaut, und irgendetwas an Ihrem Workload hat Sie von der Standard-microVM-Runtime auf Runtime Instances gebracht: GPU-Rendering, Sessions über mehrere Tage, große In-Memory-Datensätze oder die Anforderung, alles in einer abgeschotteten Umgebung zu halten.
Dann kommt die erste echte Rechnung, und jemand fragt, wie hoch Ihre Bruttomarge pro Tenant ist.
Ihr Pricing-Team braucht Kosten pro Task, Marge pro Account und Chargeback pro Kunde. Aus dem, was AWS Ihnen liefert, können Sie nichts davon ableiten.
Die Lücke bei der Kostenzuordnung
Um das im Detail zu verstehen, nehmen wir als Beispiel einen 3D-Rendering-Agenten als Service. Kunden beschreiben Szenen in natürlicher Sprache, Ihr Agent plant die Komposition (Bedrock) und rendert dann per Ray-Tracing ein fotorealistisches Bild (GPU).
Zwei Kunden.
- Architekturbüro: 15K Tokens + 12 Min. GPU-Rendering → 8,40 $/Task
- E-Commerce-Unternehmen: 2K Tokens + 18 Sek. GPU-Rendering → 0,03 $/Task
Ein 280-facher Unterschied bei der Cost-to-Serve – beim selben Produkt.
Ihre Rechnung zeigt:
Bedrock — Claude Opus 4.5: $12,400EC2 (g5.xlarge, managed): $8,600Zwei Posten. Keine Möglichkeit, Nutzung weiterzuberechnen oder die Marge pro Account zu ermitteln – und beim Sprung von 2 Tenants auf 1.000 wird es nur noch schlimmer.
AWS liefert die Bausteine. Zusammensetzen müssen Sie sie selbst.
AWS bietet granulare Bedrock-Kostenzuordnung über IAM-Principals, Multi-Tenancy-Patterns für AgentCore mit Tenant-Tags auf Session-Ebene sowie Observability-Exporte nach CloudWatch. Doch für durchgängige Kosten pro Task brauchen Sie Identitätskonfiguration, IAM-Session-Tags, aktivierte Cost-Allocation-Tags, Observability-Metrik-Exporte, CloudWatch-Logs-Insights-Abfragen und das Verknüpfen von CUR-Daten mit Ihrer Pricing-Logik.
Das ist ein ernstzunehmendes Engineering-Projekt – und eines, das Sie für immer pflegen.
Der andere Ansatz: unterhalb der Anwendung messen
Attribute installiert einen eBPF-Sensor auf Ihren AgentCore-EC2-Instanzen. Er beobachtet Bedrock-API-Aufrufe auf Kernel-Ebene und ordnet jeden dem Tenant zu, der ihn ausgelöst hat. Er sieht außerdem GPU-Compute, lokale Modell-Inferenz und Netzwerk-I/O auf der Instanz. Kein Billing- oder Attributionscode in Ihrer Anwendung. Keine SQS-Pipelines, keine DynamoDB-Tabellen. CUR-Daten werden weiterhin für den Kostenabgleich genutzt, aber die Attributionslogik – den Tenant-Kontext durch den gesamten Stack durchzureichen – übernimmt der Sensor, nicht Ihre App.
Ein Sensor, ein Dashboard: Tenant A hat 2.100 $ an Inferenz + 340 GPU-Stunden verbraucht. Tenant B 48 $ + 2 GPU-Stunden. Sie haben keine Pipeline gebaut. Der Kernel hat es beobachtet.
In diesem Beitrag deployen wir einen Agenten, der eine GPU benötigt, installieren den DoiT-Attribute-Sensor, erzeugen etwas Workload und rufen die Kosten pro Tenant über das Attribute-Dashboard und die API ab – ohne Tagging und ohne die Konfiguration einer komplexen Billing-Pipeline.
Architektur
Der Capacity Provider von AgentCore startet bei Bedarf frische Instanzen – allerdings als EC2 Managed Instances: AgentCore provisioniert und betreibt sie, Sie haben darauf nur eingeschränkte Berechtigungen. Zum Zeitpunkt der Erstellung dieses Beitrags stellen die LaunchParameters des Capacity Providers weder imageId noch userData bereit, und ein eigenes Launch Template können Sie ebenfalls nicht mitgeben. Den Sensor fest ins Image zu integrieren, ist also keine Option.
Deshalb setzen wir auf einen ereignisgesteuerten Ansatz: EventBridge erkennt, wenn eine AgentCore-Instanz in den Status running wechselt, und triggert eine Lambda-Funktion, die auf SSM-Konnektivität wartet und den Sensor anschließend per SSM Run Command remote installiert.
Hinweis: Der Sensor beginnt mit der Beobachtung, sobald er installiert ist – nicht, wenn die Instanz bootet. EventBridge löst bei running aus, die Lambda-Funktion wartet auf SSM-Konnektivität, dann installiert Run Command den Sensor – in unseren Tests insgesamt rund 50 Sekunden. In der Praxis war die Agent-Runtime erst bereit, Requests anzunehmen, nachdem der Sensor bereits installiert war – es blieb also kein Traffic ohne Zuordnung.
Ereignisgesteuertes Sensor-Deployment: EventBridge erkennt neue AgentCore-Instanzen, Lambda wartet auf SSM und installiert den Sensor anschließend per Run Command.
Der Agent akzeptiert einen x-tenant-id-HTTP-Header – die Geschäftskennung, die Ihre Plattform ohnehin nutzt, um gerenderte Ergebnisse in den Storage des richtigen Tenants zu leiten und die Zugriffskontrolle pro Tenant durchzusetzen. Der Attribute-Sensor erfasst genau diesen Header auf OS-Ebene und ordnet damit Compute- und AI-Kosten dem verursachenden Tenant zu.
Der Agent: Strands SDK + Blender auf GPU
Der 3D-Rendering-Agent basiert auf dem Strands Agents SDK und wird über BedrockAgentCoreApp deployt.
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)Den vollständigen Quellcode des Agenten sowie die Terraform-Templates finden Sie in diesem Repo.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Deployment: ein einziges Terraform Apply
Der komplette Stack – Capacity Provider, Agent-Runtime, Auto-Deploy-Pipeline für den Sensor – wird mit einem einzigen terraform apply ausgerollt. Konfigurieren Sie Ihre 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 daysAnschließend:
cd terraformterraform initterraform applyKostenzuordnung pro Tenant testen
Das Repo enthält ein Multi-Tenant-Testskript (agent-3d-render/scripts/tenant_test.py), das Render-Prompts von zwei verschiedenen Tenants gegen dieselbe Agent-Runtime schickt – mit echten x-tenant-id-HTTP-Headern:
AGENT_RUNTIME_ARN=arn:aws:bedrock-agentcore:us-west-2:ACCOUNT:runtime/NAME \ python3 agent-3d-render/scripts/tenant_test.pyDas Skript sendet mehrere Render-Requests als zwei Tenants, jeweils mit unterschiedlichen Szenen-Prompts:
=== 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-gamestudioDas Ergebnis: Kostentransparenz pro Tenant
Vier Renderings, zwei Tenants. So viel hat es gekostet, jeden der beiden zu bedienen:
Kostenzuordnung pro Tenant über den x-tenant-id-Header – ohne Cost-Allocation-Tags und ohne Billing-Code.
Der Drill-down in einen Tenant zeigt die Kostenaufschlüsselung nach Ressourcentyp.
Attributionsdaten pro Tenant über die API abrufen
Dashboards sind für Menschen. Wenn Sie ein Billing-System anbinden, brauchen Sie die Daten programmatisch:
curl -s -H "Authorization: Bearer $ATTRIBUTE_TOKEN" \ "https://api.app.attrb.io/api/v1/identifiers/daily/<date>"Jetzt loslegen
Das vollständige Repo – Terraform, Agent-Code, Testskripte – ist Open Source. Klonen, Attribute-Token setzen, terraform apply – und Sie haben Kostentransparenz pro Tenant, bevor die nächste Rechnung eintrifft.
Wenn Sie mit dem Testen fertig sind: alles wieder abbauen. Die obige Konfiguration begrenzt Sessions auf 24 Stunden, AgentCore erlaubt aber bis zu 14 Tage – und eine vergessene GPU-Instanz ist ein teures Souvenir:
terraform destroyHäufig gestellte Fragen
Was bedeutet Kostenzuordnung in Bedrock AgentCore?
Kostenzuordnung in Bedrock AgentCore bedeutet, Bedrock-Inferenzkosten und GPU-Compute auf Runtime Instances dem konkreten Tenant, Kunden oder Workload zuzuordnen, der sie verursacht hat. Die Abrechnung von AgentCore zeigt nur aggregierte Posten für Bedrock und EC2, keine Aufschlüsselung pro Tenant – die Zuordnung erfordert daher entweder die nativen Tagging-Tools von AWS oder eine separate Beobachtungsschicht.
Kann man auf AgentCore Runtime Instances ein eigenes AMI oder Launch Template verwenden?
Nein. Der Capacity Provider von AgentCore verwaltet die zugrunde liegenden EC2-Instanzen direkt, und zum Zeitpunkt der Erstellung dieses Beitrags bietet seine LaunchParameters-API weder ein imageId- noch ein userData-Feld und akzeptiert kein eigenes Launch Template. Jede Software, die auf der Instanz laufen soll – einschließlich eines Sensors für die Kostenzuordnung –, muss installiert werden, nachdem die Instanz den Status running erreicht hat, statt von vornherein im Image enthalten zu sein.
Wie ordnet man AWS-Bedrock-Kosten ohne Cost-Allocation-Tags einzelnen Tenants zu?
Ein auf der Instanz installierter eBPF-Sensor kann Bedrock-API-Aufrufe, GPU-Compute und Netzwerk-I/O auf Kernel-Ebene beobachten – unabhängig davon, welches Tagging oder Logging Ihr Anwendungscode betreibt. Wenn Ihr Agent bereits eine Tenant-Kennung übergibt, etwa einen x-tenant-id-Header, kann der Sensor genau diese Kennung erfassen und die beobachteten Kosten direkt zuordnen – ohne IAM-Session-Tags oder CUR-basierte Abgleichs-Pipelines.
Worin unterscheidet sich die native Bedrock-Kostenzuordnung von AWS von einem eBPF-Sensor-Ansatz?
Der native Weg von AWS nutzt IAM-Principal-Tagging, Tenant-Tags auf Session-Ebene und Cost-and-Usage-Report-Daten, die Sie mit eigener Pricing-Logik verknüpfen. Das ist eine echte Lösung, aber ein Engineering-Projekt, das Sie dauerhaft pflegen. Ein eBPF-Sensor beobachtet dieselben Signale von außerhalb Ihrer Anwendung – die Attributionslogik steckt im Sensor und nicht in Code, den Sie bei jeder Änderung am Agenten mitpflegen müssen.
Wie stark variieren die GPU-Kosten pro Tenant beim selben Agenten?
Sie können selbst auf identischer Infrastruktur um Größenordnungen variieren. Im Rendering-Beispiel dieses Beitrags kostete der Task eines Tenants 8,40 $ aufgrund eines 12-minütigen GPU-Renderings, während der Task eines anderen Tenants mit einem 18-Sekunden-Rendering 0,03 $ kostete – ein 280-facher Unterschied, der allein aus dem Nutzungsmuster resultiert, nicht aus dem Pricing.
Wenn Sie Agenten auf AgentCore betreiben und sehen möchten, wie Attribute in Ihrer eigenen Umgebung aussieht, buchen Sie eine Demo.
