Agentic Ventures Wiki

phase-1-discover

4 Min. Lesezeit

Phase 1 — Discover

Ziel: Hypothesen-Liste aus caller-inventar.md mit echten CloudTrail-Daten abgleichen. Top-3-Caller identifizieren. Kein Schreiben an Infrastruktur.

Aufwand: ~1h

Vorbedingung: keine.

Nachbedingung: caller-inventar.md Abschnitt „Bestaetigte Caller (nach Phase 1)” gefuellt mit Top-3.

Schritte

1.1 CloudTrail-Lookup Bedrock-Events 12.-15.05.

CloudTrail loggt jeden bedrock-runtime:InvokeModel mit Source-Principal (IAM-Role) + User-Agent. Damit ueber den Burst-Zeitraum:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=bedrock-runtime.amazonaws.com \
  --start-time 2026-05-12T00:00:00Z \
  --end-time 2026-05-16T00:00:00Z \
  --max-results 50 \
  --profile av-production --region eu-central-1

Aggregiere die Events nach userIdentity.sessionContext.sessionIssuer.userName (= IAM-Role/User-Name). Pro Role: Count + Modell.

Alternative falls die Event-Logs zu gross sind: Athena auf CloudTrail-S3-Bucket setzen (wenn CloudTrail-Trail dort schreibt) — eine SQL-Query reicht. Aber erst CLI versuchen.

1.2 Cost-Explorer pro USAGE_TYPE und Linked-Account

aws ce get-cost-and-usage \
  --time-period Start=2026-05-12,End=2026-05-16 \
  --granularity DAILY \
  --metrics UnblendedCost UsageQuantity \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Claude Sonnet 4.6 (Amazon Bedrock Edition)"]}}' \
  --group-by Type=DIMENSION,Key=LINKED_ACCOUNT \
  --profile av-production --region us-east-1

Bestaetigt: passiert das im av-production-Account oder in einem Sub-Account?

1.3 IAM-Role → Caller-Mapping

Pro IAM-Role aus 1.1 nachschauen: welcher Caller laeuft unter dieser Role?

  • ECS-Task-Roles → ECS-Service-Beschreibung (welcher Container ist das? Open-WebUI? mcp-whatsapp-Sidecar?)
  • Lambda-Execution-Roles → Lambda-Function-Name → Agent in agents-platform
  • User-Roles (marvin@av-production) → manueller Test-Call?
aws iam get-role --role-name <role-name> --profile av-production
aws ecs list-services --cluster av-production --profile av-production
aws lambda list-functions --profile av-production --region eu-central-1 \
  --query 'Functions[].{Name:FunctionName, Role:Role}'

1.4 Container-Logs-Snapshot

Fuer den Top-Caller (vermutlich Open-WebUI): aktuelle CloudWatch-Logs vom 12.-15.05. snapshoten in S3 oder lokal — wir wollen in Phase 2 den durchschnittlichen System-Prompt-Token-Count messen koennen.

aws logs filter-log-events \
  --log-group-name /ecs/open-webui-vf \
  --start-time $(date -u -j -f "%Y-%m-%d" 2026-05-13 +%s)000 \
  --end-time $(date -u -j -f "%Y-%m-%d" 2026-05-16 +%s)000 \
  --profile av-production --region eu-central-1 \
  --max-items 200 > /tmp/open-webui-burst.log

Wenn das Log-Group anders heisst, mit aws logs describe-log-groups finden.

1.5 Ergebnisse in caller-inventar.md eintragen

Tabelle „Bestaetigte Caller” fuellen: pro Caller die echte Call-Anzahl im Burst + Anteil an der $42.77. Top-3 markieren.

Definition of Done

  • CloudTrail-Lookup gemacht, Caller-Liste je IAM-Role
  • Cost-Explorer-LINKED_ACCOUNT bestaetigt
  • IAM-Roles → Caller-Namen gemappt
  • Open-WebUI Burst-Logs lokal/S3
  • caller-inventar.md Abschnitt „Bestaetigte Caller” ausgefuellt, Top-3 markiert

Output dieser Phase

Konkrete Antwort auf: „wer hat in 4 Tagen 12.3M Input-Tokens an Sonnet 4.6 geschickt?” Inkl. ungefaehrer Verteilung. Damit ist klar wo Phase 5 ansetzen muss.

Findings (durchgefuehrt 2026-05-17)

Phase 1 ist abgeschlossen, ohne dass die im Plan vorgesehenen Schritte 1:1 alle moeglich waren. Hier was passiert ist:

Was funktioniert hat

  • Cost-Explorer LINKED_ACCOUNT (1.2): alles passiert in av-production (Account 425924867359). Kein Sub-Account beteiligt.
  • ECS- und Lambda-Inventar (1.3): vollstaendige Liste der laufenden Bedrock-faehigen Services / Functions in eu-central-1 und Cross-Region-Check (us-east-1 / us-west-2 leer fuer Bedrock-relevante Lambdas).
  • CloudWatch AWS/Bedrock-Metrics (Bonus, nicht im Original-Plan): liefert Per-Modell, Per-Tag und Per-Stunde Aufschluesselung von Invocations, InputTokenCount, OutputTokenCount. Reichte um Top-3-Caller via Korrelation zu identifizieren.

Was nicht funktioniert hat

  • CloudTrail-Lookup bedrock-runtime:InvokeModel (1.1) war leer: InvokeModel ist ein CloudTrail Data-Event, nicht Management-Event. Der bestehende Trail av-mgmt-trail (Org-Trail, eu-central-1, Management-only) loggt das nicht. Loesung fuer Zukunft: in Phase 4 Bedrock Model-Invocation-Logging aktivieren — das ist die spezifischere und billigere Loesung als CloudTrail-Data-Events.
  • Container-Logs-Snapshot Open-WebUI (1.4) nicht durchgefuehrt — wurde in Phase 1 nicht mehr noetig, weil CloudWatch-Metrics + Cluster-Inventar Top-3 schon klar machen. Wandert in Phase 2 (Baseline) wenn Token-Counts gemessen werden.

Hauptbefunde (Details in caller-inventar.md)

  1. Top-3-Caller: open-webui-vf, inference-service-prod (a-icking-rebuild), Beleg-Pipeline + Receptionist-Brain Lambdas
  2. 1M-Context-Beta wurde benutzt — bestaetigt durch eigene CloudWatch-Dimension. Das ist die teuerste Variante von Sonnet 4.6.
  3. 475k Tokens pro Call am 13.05. spaet — abnormal hoch, vermutlich Eval-Run oder Agent-Loop ohne History-Truncation
  4. Prompt-Caching = 0 Hits — Cache-Tokens-Metrics existieren aber sind leer fuer Sonnet 4.6
  5. Haiku-zu-Sonnet-Switch um 14.05. — Haiku-Usage brach ein, Sonnet stieg. Vermutlich Beleg-Klassifikations-Test
  6. Cohere Embed v4 doppelt in der Modell-Liste (mit + ohne EU-Prefix) — Konsolidierungs-Kandidat

Definition of Done

  • CloudTrail-Lookup gemacht (war leer, Befund dokumentiert)
  • Cost-Explorer-LINKED_ACCOUNT bestaetigt
  • IAM-Roles → Caller-Namen gemappt (ueber ECS-Service-Liste + Lambda-Liste)
  • Open-WebUI Burst-Logs lokal/S3 — verschoben nach Phase 2
  • caller-inventar.md Abschnitt „Bestaetigte Caller” ausgefuellt, Top-3 markiert
  • CloudWatch-Metrics-Drilldown 13.05. Stunden-Histogramm

Phase 1 done. Phase 2 (Baseline) kann starten.

Graphansicht

Backlinks