Ein Application Inference Profile ist ein getaggter Wrapper um eine Modell-ARN, und er ist das Einzige, was zwischen Ihnen und einer Bedrock-Rechnung steht, die eine einzige Zahl für das ganze Unternehmen nennt. Sie erstellen ein Profil, das auf ein Modell zeigt, hängen Kostenzuordnungs-Tags an und rufen die Profil-ARN statt der Modell-ID auf. Die Tags werden bis zu Cost Explorer und dem Cost and Usage Report mitgeführt. Das ist der gesamte Mechanismus, und er dauert einen Nachmittag.

Der Nachmittag ist nicht das Problem. Das Problem ist, dass ein Tagging-Schema eine organisatorische Verpflichtung ist, und die meisten Teams wählen eines in zehn Minuten und leben zwei Jahre damit. Die API ist daher zwanzig Minuten dieses Beitrags wert, und das Tag-Design den Rest.

Das Problem, das es löst

Ohne Profile taucht Bedrock-Nutzung als Bedrock-Nutzung auf. Sie erhalten Ausgaben nach Modell und nach Region, was Ihnen sagt, dass Claude Sonnet letzten Monat viel gekostet hat, aber nichts darüber, welche Ihrer neun Anwendungen das verursacht hat. Der Standardbericht kann die einzige Frage nicht beantworten, die das Finanzteam je stellt: aus wessen Budget das kommt. Über die breitere Form dieses Problems habe ich in Your LLM Bill Is an Observability Problem geschrieben. Profile sind die spezifische Kontrolle für die Zuordnungshälfte.

Wie es funktioniert

Erstellen Sie ein Profil, das auf ein Foundation Model oder ein systemdefiniertes Cross-Region-Profil zeigt, mit Tags:

aws bedrock create-inference-profile \
  --inference-profile-name "support-assistant-prod" \
  --model-source copyFrom=arn:aws:bedrock:eu-central-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0 \
  --tags key=team,value=support key=app,value=assistant key=env,value=prod

Rufen Sie dann überall dort die Profil-ARN auf, wo Sie eine Modell-ID übergeben haben:

response = client.converse(
    modelId="arn:aws:bedrock:eu-central-1:123456789012:application-inference-profile/abc123",
    messages=messages,
)

Drei operative Details, die leicht übersehen werden:

  • Profile sind modellspezifisch. Ein Profil umschließt ein Modell. Sechs Apps mal vier Modelle sind vierundzwanzig Profile. Diese Multiplikation ist der Grund, warum Ihr Tag-Design wichtiger ist, als es aussieht: Sie benennen keine Ressource, Sie definieren ein Raster.
  • Tags sind nicht rückwirkend. Das Aktivieren eines Kostenzuordnungs-Tags in der Billing-Konsole taggt Ausgaben ab diesem Zeitpunkt. Für nichts, was Sie letzten Monat getan haben, gibt es nachträglich eine Beschriftung. Aktivieren Sie die Tag-Keys, bevor Sie die Daten brauchen, nicht wenn jemand danach fragt.
  • Die Granularität ist täglich, pro Nutzungstyp. Profile geben Ihnen abgerechnete Dollarbeträge in Cost Explorer und CUR auf Tagesebene. Sie geben Ihnen keine Kosten pro Request. Wenn Sie Ökonomie pro Request wollen, ist das anwendungsseitiges Token-Logging, ein anderes System mit einem anderen Owner.

Das Tag-Schema entwerfen

Die Falle besteht darin, zu taggen, was leicht zu sehen ist, statt das, worauf jemand reagieren kann. Jeder Tag-Key sollte eine Frage beantworten, die eine echte Person in einem echten Meeting stellt.

Vier Keys tragen die meisten Organisationen:

  • team: Wer zahlt. Passen Sie das genau an Ihre bestehende Kostenstellen-Taxonomie an. Wenn das Finanzteam es cc-4471 nennt, erfinden Sie nicht platform-eng; Sie verbringen sonst das nächste Jahr damit, eine Übersetzungstabelle zu pflegen, der niemand vertraut.
  • app: Welcher Workload. Die Einheit, die Sie tatsächlich abschalten würden.
  • env: prod, staging, dev. Das ist der, der sich am schnellsten auszahlt, denn die erste wirklich überraschende Zahl in den meisten Bedrock-Rechnungen ist, wie viel Dev kostet.
  • feature: optional, für Apps, bei denen ein Feature die Ausgaben dominieren kann. Sparsam einsetzen. Jeder zusätzliche Key vervielfacht Ihre Profilanzahl.

Bewusst nicht auf der Liste: Tags pro Nutzer. Erstellen Sie kein Profil pro Nutzer. Sie stoßen an Ressourcenlimits, und der Wartungsaufwand ist unbegrenzt. Für Zuordnung auf Identitätsebene unterstützt Bedrock IAM-Principal-basierte Kostenzuordnung, die Ausgaben der aufrufenden Identität zuordnet, ohne ein Profil pro Person. Nutzen Sie Profile für die Granularität von Team und App, und IAM-Principal-Zuordnung, wenn Sie wissen müssen, welcher Mensch oder welche Service-Rolle den Ausschlag verursacht hat. Sie ergänzen sich.

Machen Sie es strukturell

Ein Tagging-Schema, das von Disziplin abhängt, verfällt. Zwei Kontrollen sorgen dafür, dass es hält.

Erstens: Erstellen Sie Profile in Ihrer IaC, direkt neben der App, die sie nutzt, und ziehen Sie Tag-Werte aus denselben Variablen, die auch die übrigen Ressourcen dieser App taggen. Ein Profil, das von Hand in der Konsole erstellt wurde, ist ein Profil, das für immer mit test getaggt bleibt.

Zweitens: Schließen Sie den direkten Pfad. Sobald Profile existieren, erzeugt eine App, die eine rohe Modell-ID aufruft, ungetaggte Ausgaben, und ungetaggte Ausgaben sind genau die Position, die niemand beansprucht. Eine IAM-Policy, die bedrock:InvokeModel und bedrock:Converse auf Foundation-Model-ARNs verweigert, während sie auf Application-Inference-Profile-ARNs erlaubt, macht den getaggten Pfad zum einzigen Pfad. Das ist derselbe Instinkt wie das Zuschneiden einer Rolle auf eine Aufgabe, und ich wiederhole das Argument aus IAM for LLM Apps: Least Privilege When the Caller Is a Model nicht, sondern merke nur an, dass es genauso für Ihre Rechnung wie für Ihren Wirkungsradius gilt.

Tun Sie das am ersten Tag. Eine Deny-Policy nachträglich auf sechs Apps aufzusetzen, die bereits Modell-IDs aufrufen, ist eine Migration mit angehängtem Change-Freeze.

Was Sie bekommen, und was Ihnen weiterhin fehlt

Nach einem Monat getaggter Daten können Sie Cost Explorer nach team gruppieren und die Aufteilung sehen, nach env=dev filtern und den Batch-Job finden, den jemand laufen ließ, und CUR nach Kosten pro App pro Tag abfragen und auf ein Dashboard neben dem Request-Volumen setzen. Auch Anomalieerkennung wird nützlich, denn ein Budget-Alert für eine App ist Signal, wo ein Alert für die gesamten Bedrock-Ausgaben Rauschen ist.

Was Ihnen weiterhin fehlt: Kosten pro Request, Kosten pro Kunde in einer Multi-Tenant-App und jede Vorstellung davon, ob sich die Ausgabe gelohnt hat. Ersteres ist Token-Logging. Zweiteres braucht Tenant-Kontext, den das Abrechnungssystem nie sieht, weshalb Multi-Tenant-Zuordnung ein Anwendungsproblem bleibt. Drittens ist überhaupt keine Abrechnungsfrage. Profile sagen Ihnen, wohin das Geld ging. Sie haben keine Meinung dazu, ob es sich lohnen sollte.

Die Quintessenz

Application Inference Profiles verwandeln eine nicht zuordenbare Bedrock-Rechnung in Zeilen pro Team und pro App, für den Preis, eine Modell-ARN zu umhüllen. Aktivieren Sie die Tag-Keys, bevor Sie die Historie brauchen, halten Sie das Schema auf wenige Keys begrenzt, die zu Ihrer tatsächlichen Budgetierung passen, erstellen Sie Profile in IaC, und verweigern Sie den ungetaggten Pfad mit IAM, damit die Zuordnung nicht davon abhängt, dass jemand daran denkt. Die API ist ein Nachmittag. Das Tag-Design überlebt die Menschen, die es gewählt haben.

Weiterlesen

Die allgemeine Kostenzuordnungsdisziplin, aus der das entlehnt ist, Tagging-Strategie über einen gesamten AWS-Bestand, findet sich in den Field Notes auf ercan.cloud. Der Hub ist unter ercanermis.com.