Mit den eigenen Zahlen reden

Wie alles begann

Am Anfang stand eine einfache Frage: Wie machen wir die AWS-Kostendaten so verfügbar, dass man im Alltag wirklich mit ihnen arbeitet? Der AWS Cost Explorer ist dafür ganz ordentlich, allerdings lebt er davon, dass man aktiv nachschaut und sich durchklickt. Cost Alerts sind ebenfalls wichtig, doch sie funktionieren eher als Störungstrigger, der anschlägt, wenn etwas aus dem Ruder läuft, und weniger als ein Werkzeug, mit dem man täglich denkt.

Die moderne Arbeitswelt findet dagegen zu einem großen Teil im LLM-Chat statt, sodass es verlockend klingt, die eigenen Kostendaten genau dort verfügbar zu haben, weil man dann einfach fragen kann, statt ein weiteres Tool zu öffnen. Es ergibt allerdings keinen Sinn, ein LLM mehrere Megabyte oder gar Gigabyte an strukturierten Daten durchforsten zu lassen, weil das unnötig Token verschlingt, langsam wird und dazu führt, dass das Modell nur noch schätzt, obwohl man exakte Zahlen braucht.

Daher war es naheliegend, den Spieß umzudrehen und nicht die Rohdaten ins Modell zu kippen, sondern einen MCP-Server mit deterministischen Funktionen zu bauen, der über eine DuckDB auf die Billing-Daten zugreift. Das LLM formuliert die Frage und liefert den Kontext, während die eigentliche Rechnung in der Datenbank passiert, sodass die Antwort sprachlich flüssig und zugleich zahlenmäßig exakt bleibt, ohne dass man ein Dashboard oder eine schwere Datenplattform braucht. Damit war die grobe Zielvorstellung schnell skizziert: AWS Data Export schreibt die Abrechnungsdaten nach S3, eine DuckDB liest sie von dort, ein MCP-Server macht sie abfragbar, und ein paar generische Tools reichen dem LLM, um loszulegen.

Konkret legt man dafür in AWS einen Data Export an, wählt das FOCUS-1.2-Format, Parquet als Dateiformat und einen täglichen Export, der nach S3 geschrieben wird. Damit ist die Grundlage gelegt: eine saubere, standardisierte Kostenbasis, auf die sich alles Weitere stützt.

Das Ergebnis dieser ersten Phase ist die folgende Architektur, die bewusst schlank bleibt und ohne exotische Bausteine auskommt, weil genau das sie tragfähig macht:

Damit steht die Kostenbasis. Sie ist der Anfang einer Entwicklung, die in weiteren Phasen zu einer produktübergreifenden, verlässlichen Sicht wächst.

Mit den ersten Zahlen arbeiten

Als die Basis stand, ging es zunächst darum, mit den neuen Erkenntnissen zu arbeiten. Die Fragestellungen waren dabei die üblichen, die man vorher auch im Cost Explorer hatte: Kosten pro Service und Region, Veränderungen über die Zeit und die Frage, wie konsistent eigentlich getaggt wird. Genau hier wurde schnell etwas sichtbar, das vorher niemandem aufgefallen war.

Obwohl wir eine vermeintlich saubere Abdeckung durch Infrastructure as Code hatten, steckten in den Tag-Werten Tippfehler, und diverse Ressourcen entsprachen nicht den Tagging-Standards. Der erste Schritt bestand deshalb darin, diese Dinge nachzuarbeiten und zu bereinigen, damit die Auswertungen überhaupt auf einer verlässlichen Grundlage stehen.

An dieser Stelle bot es sich außerdem an, den MCP-Server um eine Alias-Logik zu erweitern, damit die historischen Daten trotzdem vergleichbar bleiben und die verschiedenen Typo-Werte zu einem einzigen Wert zusammengeführt werden. Weil Tagging-Änderungen in AWS nicht rückwirkend greifen, war diese Lösung überraschend angenehm, und es entstand ein gutes Gefühl, zu wissen, dass die Datenbasis mit jedem Schritt ein Stück besser wird.

Da eines der Tags das jeweilige Produkt bezeichnete, ergab sich fast von selbst die Frage, welche Produkte es eigentlich gibt. Zuerst wurde daraus direkt ein weiteres MCP-Tool, das die Produkte aus den Tags ableitet. Diese Idee haben wir allerdings wieder verworfen, weil ein anderer Weg deutlich besser trug.

Statt die Produkte aus den Tags zu erraten, haben wir eine eigene products.json angelegt, die für jedes SaaS-Produkt, das in AWS betrieben wird, die relevanten Angaben festlegt. Dort steht, welche Tag-Werte zu einem Produkt gehören, inklusive bekannter Tippfehler, dazu eine Beschreibung, der Lebenszyklus und das monatliche Budget. Damit wird die Zuordnung explizit und nachvollziehbar, statt implizit im Tag-Wirrwarr zu verschwinden.

"invoice-radar": {
  "tag_values": ["invoice-radar", "invoice-radr"],
  "description": "Invoice Radar SaaS",
  "lifecycle": "production",
  "budget_monthly": 35
}

Danach hieß es erst einmal wieder, mit den Daten zu arbeiten und weiterzuschauen, was sie hergeben. Schnell entstanden die ersten Skills, etwa ein Cost Report und eine Anomalie-Erkennung, damit man wiederholt denselben Report sehen konnte, ohne ihn jedes Mal neu zusammenzustellen. Das war praktisch, fühlte sich aber wie eine billige Kopie eines Dashboards an, und genau dieses Gefühl war der Grund, zur nächsten Stufe weiterzugehen.

Erwartungen festlegen: KPIs

Was an KPIs oft falsch verstanden wird, ist ihre Natur: Ein KPI ist immer ein Bereich, nie eine einzelne konkrete Zahl. Erst wenn klar ist, welcher Wert erwartet wird, ab wann es riskant wird und ab wann sich eine Chance auftut, bekommt eine Kennzahl eine Bedeutung, an der man Entscheidungen ausrichten kann. Wie man KPIs richtig aufsetzt, vertiefen wir in einem eigenen Artikel.

Also haben wir den MCP-Server um eine KPI-Logik erweitert und pro Produkt festgelegt, wo die Erwartungen liegen. Ein KPI besteht dabei aus einer deterministischen Abfrage und einem Zielkorridor mit Schwellen für Risiko und Chance, und weil sich Erwartungen über die Zeit ändern, ist er zusätzlich versioniert.

"cost_per_product_invoice_radar": {
  "name": "Invoice Radar Monthly Cost",
  "description": "Projected monthly cost for the Invoice Radar product",
  "sql": "SELECT ROUND(SUM(BilledCost) / COUNT(DISTINCT CAST(ChargePeriodStart AS DATE)) * 30, 2) as value FROM data WHERE Tags->>'billing' = 'invoice-radar' AND ChargeCategory != 'Tax' AND BilledCost > 0",
  "unit": "USD/month",
  "category": "budget",
  "versions": {
    "2026-06": {
      "target_operator": "<=",
      "target_value": 35,
      "risk_value": 50,
      "opportunity_value": 15,
      "reason": "Initial: ECS+CloudFront+Route53 baseline ~$18"
    }
  }
}

So verankert liefert der MCP-Server nicht mehr nur Zahlen, sondern eine Einordnung: Er kann sagen, ob ein Produkt im erwarteten Korridor liegt, sich einem Risiko nähert oder eine Chance zeigt. Damit war der Schritt vom bloßen Report zur bewertbaren Aussage getan.

Damit das LLM diesen Zahlen nicht nur vertrauen soll, sondern auch kann, liefert der MCP-Server zu jeder Antwort einen Provenance-Block mit. Dieser beschreibt, woher die Erkenntnisse stammen, und macht die Herkunft überprüfbar, statt sie im Verborgenen zu lassen.

Der Block hält fest, aus welcher Quelle die Daten kommen, welchen Zeitraum sie abdecken und wie aktuell der jüngste Datenpunkt ist. Er nennt die angewandten Filter und die Projektionsmethode, sodass eine hochgerechnete Monatszahl nachvollziehbar wird. Zusätzlich bildet er über die einbezogenen Config-Dateien, also den Produktkatalog und die KPI-Definitionen, einen kurzen Hash, mit dem sich Änderungen an den Verträgen zwischen zwei Läufen erkennen lassen. Ist der jüngste Datenpunkt zu alt, ergänzt er eine Warnung.

"provenance": {
  "source": { "app": "aws-focus", "bucket": "…", "prefix": "…", "format": "parquet" },
  "period_start": "2026-08-01",
  "period_end": "2026-08-31",
  "latest_data_date": "2026-08-31",
  "filters": ["ChargeCategory != 'Tax'", "BilledCost > 0"],
  "projection_method": "linear_monthly_projection_30_days",
  "contract_version": "local",
  "contract_hash": "a1b2c3d4e5f6a7b8",
  "contract_files": ["products.json", "kpis.json"],
  "warnings": ["Latest source data is 5 days old."]
}

Der praktische Nutzen liegt auf der Hand: Der LLM-Client kann die Datenherkunft prüfen, veraltete Ergebnisse über die Warnungen und das jüngste Datum erkennen und in jeder Auswertung sauber ausweisen, dass die Zahlen über den Analytics-MCP erhoben wurden. Aus einer Antwort, der man glauben muss, wird eine Antwort, die man nachprüfen kann.

Weitere Quellen anbinden: GSC und GitLab

Die Produkte leben nicht nur in der AWS-Rechnung, sondern zu einem großen Teil auch im Netz, weshalb der nächste Schritt war, die Google Search Console anzubinden. Ein Data Export nach S3 wie bei den Billing-Daten ergab hier keinen Sinn, weil die API-Anfragen kostenlos sind und sich direkt abfragen lassen. Also haben wir den MCP-Server um GSC-Daten erweitert, statt einen weiteren Umweg über Speicher zu bauen.

Damit ließ sich plötzlich etwas tun, das vorher nicht möglich war: Google-Search-Metriken und Kosten-Metriken für dasselbe Produkt nebeneinanderlegen und kreuzen. Die Frage, ob ein Produkt seine Kosten mit entsprechender Sichtbarkeit rechtfertigt, wurde damit beantwortbar, weil beide Seiten aus derselben Basis kommen.

An dieser Stelle zahlte sich eine frühere Entscheidung erneut aus. Die AWS-Billing-Daten sind mindestens einen Tag verzögert verfügbar, die GSC-Daten eher drei Tage. Diese Latenz ist Teil der Config und damit auch Teil der Provenance, sodass das LLM fehlende Werte für die jüngsten Tage problemlos einordnen kann, anstatt sie als plötzlichen Einbruch misszuverstehen.

Wenn die Anbindung der Search Console so gut funktionierte, lag es nahe, auch GitLab einzubeziehen. Damit wurde sichtbar, welche Produkt-Repositories besonders aktiv sind, welche Merge Requests liegen bleiben und wie schnell sie überhaupt verarbeitet werden. Ebenso lässt sich verfolgen, ob es Bug-Reports gibt und wann bestimmte Dinge behoben wurden.

Der eigentliche Reiz entsteht wieder aus der Verknüpfung. Wenn ein Bug behoben oder ein Feature ausgeliefert wurde, kann man fragen, ob sich das in den GSC-Zahlen niederschlägt oder die Kosten verändert. So wird aus den drei Quellen, den Kosten, der Sichtbarkeit und der Entwicklungsaktivität, ein zusammenhängendes Bild eines Produkts statt dreier getrennter Sichten.

Den Kreis schließen: die Produktnutzung selbst

Was uns zur nächsten Phase bringt, nämlich die eigenen SaaS-Produkte besser zu verstehen. Kosten, Sichtbarkeit und Entwicklungsaktivität sagen viel, aber sie sagen nichts darüber, was in den Produkten selbst passiert. Uns interessierte, welche Funktionen wie oft genutzt werden und welche Erwartungshaltung es an die Häufigkeit der Produktnutzung und an die einzelnen wichtigen Funktionen gibt.

Deshalb haben wir die Produkte um einen anonymisierten Statistik-Export erweitert, der seine Daten auf einem S3-Bucket ablegt, der wiederum über DuckDB und den MCP-Server abfragbar gemacht wurde. Hier ergab der Weg über S3 anders als bei der Search Console durchaus Sinn, weil die Nutzungsdaten aus den Anwendungen selbst kommen und dort programmatisch geschrieben werden.

Damit schließt sich der Kreis, und man hat eine 360-Grad-Ansicht auf ein Produkt: was es kostet, wie sichtbar es ist, wie aktiv daran entwickelt wird und wie es tatsächlich genutzt wird. Alle vier Blickwinkel stammen aus derselben abfragbaren Basis und lassen sich beliebig kreuzen.

Und was passiert dadurch? Es beeinflusst Entscheidungen. Welche Features werden angepasst oder neu gebaut, braucht es einen neuen Blogpost, sind die Kosten im Griff, muss an der Profitabilität etwas getan werden. Aus einer Ansammlung von Zahlen wird eine Grundlage, an der sich konkrete Schritte ausrichten lassen.

Das Ganze geschieht in natürlicher Sprache, bei der man selten dieselbe Frage zweimal stellt, sondern auf dem aufbaut, was man selbst bereits weiß, herausgefunden oder abgeleitet hat. Es ist kein statisches Dashboard, das immer dieselben Kacheln zeigt, sondern eine lebendige Datenbasis, mit der man ein Gespräch führt. Und weil diese Daten keine Vanity-Metriken sind, sondern Zahlen, die Entscheidungen beeinflussen, lohnt sich der Weg dorthin.

Was das für dich heißt

Der Weg begann mit einer einzigen Quelle, den AWS-Kosten, und wuchs Phase für Phase zu einer 360-Grad-Sicht, die Kosten, Sichtbarkeit, Entwicklungsaktivität und tatsächliche Nutzung eines Produkts zusammenführt. Entscheidend war dabei nicht ein besonderes Werkzeug, sondern die Reihenfolge: erst eine saubere, standardisierte Basis, dann die Bereinigung und Zusammenführung der Daten, dann Erwartungen in Form von KPIs, und erst darauf aufbauend weitere Quellen.

Für dich heißt das, dass der erste Schritt kleiner ist, als er wirkt. Man braucht keine schwere Datenplattform und kein weiteres Dashboard, sondern eine verlässliche Datenbasis, die ein LLM über deterministische Funktionen abfragt, sodass die Antworten sprachlich flüssig und zahlenmäßig exakt bleiben. Weil jede Antwort ihre Herkunft mitliefert, kann man den Zahlen nicht nur glauben, sondern sie nachprüfen.

Der eigentliche Unterschied zeigt sich im Alltag. Statt statischer Kacheln führt man ein Gespräch mit den eigenen Daten, bei dem man selten dieselbe Frage zweimal stellt, sondern auf dem aufbaut, was man bereits weiß. Und weil es dabei nicht um Vanity-Metriken geht, sondern um Zahlen, die Entscheidungen tragen, verändert sich, wie im Unternehmen entschieden wird. Ob es gerade akut um Kosten brennt oder um die grundsätzliche Ausrichtung geht, wir ordnen das gerne gemeinsam mit dir ein.