Cloud Intelligence™
Reports, denen Finance wirklich vertraut
Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.
About Devorah Klartag
Marketing director. 15+ years turning marketing vision into infrastructure that actually scales - GTM, demand gen, ops, and the AI-powered systems that keep the whole thing moving. At Attribute, I built the marketing function from the ground up and hit top-3 AI search rankings on competitive FinOps queries in ChatGPT, Perplexity, and Claude.
Previously: senior growth and marketing ops at D-ID (led the self-service studio launch that hit #1 Product of the Day on Product Hunt and landed coverage in TechCrunch, Fast Company, and Forbes), digital marketing at CyberProof, and $7M campaigns at McCann Tech for NICE and Amdocs. Earlier, hospitality marketing across NYC restaurants and cruise lines.
Ex-New Yorker in Tel Aviv. Still misses the bagels most.
My personal pageSie haben Monate damit verbracht, Reports und Dashboards aufzubauen. Kosten pro Team, Kosten pro Workload, Chargeback pro Geschäftsbereich. Für die Engineers sieht alles richtig aus. Dann sitzt Finance im Review und fragt: "Können Sie diese Zahlen belegen?"
Es ist kompliziert. Ihre Tools zerlegen Billing-Exporte, arbeiten mit Regel-Engines und einer Tag-Abdeckung, die zu 70 % vollständig ist. Das ist nicht belastbar genug für Geschäftsentscheidungen, Forecasts und Prognosen.
PerfectScale™ for Kubernetes
Ready to optimize?
Get your free Kubernetes savings analysis
Warum die Zahlen nicht standhalten
FinOps-Tools wurden dafür gebaut, die Abrechnungsdatei Ihres Cloud-Anbieters einzulesen, sie mit Regeln und Tags aufzuschlüsseln und das Ergebnis in einem Dashboard anzuzeigen.
Finance und Geschäftsführung stellen Fragen aus einem anderen Blickwinkel. Was kostet es, Kunde X zu bedienen? Welches unserer Produkte ist margenpositiv? Die meisten FinOps-Tools liefern eine Antwort. Nur die wenigsten liefern eine prüfbare.
Was "Schrott" wirklich bedeutet
Wenn ein Stakeholder einen Kostenreport als "Schrott" bezeichnet, reagiert er entweder auf Zahlen, die nicht zu dem passen, was er sicher weiß – oder er kann nicht nachvollziehen, wie die Zahlen zustande gekommen sind.
In der Praxis läuft es meist auf drei Dinge hinaus:
Regeln, die einmal sinnvoll waren, aber veraltet sind.
Ihre Allokationsregeln wurden vor 18 Monaten aufgesetzt. Drei Migrationen und zwei Produkt-Rebrandings später verweisen die Regeln noch immer auf Services und Labels, die längst nicht mehr das bedeuten, was sie einmal bedeuteten. Die Zahlen wirken im Dashboard konsistent, weil die Regeln konsistent laufen. Niemand hat geprüft, ob die Regeln noch stimmen. Alle sind davon ausgegangen, dass jemand anderes für das Aufräumen zuständig ist.
Tags, die nie vollständige Abdeckung erreicht haben.
Tag-basierte Attribution erfasst nur getaggte Ressourcen. Die 30 %, die das Engineering nie getaggt hat, fallen entweder unter den Tisch oder werden über einen synthetischen Schlüssel verteilt. Wenn Finance fragt, was im nicht zugeordneten Topf steckt, lautet die ehrliche Antwort: ein erheblicher Teil der tatsächlichen Ausgaben. AI-Inference verschärft das Problem – die meisten Teams haben noch gar nicht herausgefunden, wie sie Modellaufrufe überhaupt taggen sollen, geschweige denn nach Feature oder Kunde.
Veraltete Daten im Modell. Alte Accounts, stillgelegte Services, ausgelaufene Verträge – aber die historischen Daten stecken noch im Modell.
Das Problem mit der Produkt-P&L
Das Vertrauensproblem verschärft sich, wenn FinOps-Teams versuchen, die eigentliche Frage von Finance zu beantworten: nicht "Was kostet dieser Workload?", sondern "Was kostet dieses Produkt – pro Region, pro Kundensegment?"
Diese Frage erfordert mehr als Kostendaten. Ein Kunde, der drei Produkte in fünf Regionen betreibt, interessiert sich nicht dafür, welcher Kubernetes-Namespace die Ausgaben verantwortet. Ihn interessiert, ob der Kunde profitabel ist. Dafür muss man wissen, welcher Workload welches Produkt bedient, welche Kunden welche Workloads nutzen und wie sich gemeinsam genutzte Infrastruktur auf all das verteilt. Standard-FinOps-Tools können das mit genügend Tagging und Regelwerk näherungsweise abbilden. Aber Näherungswerte halten nicht stand, wenn ein VP nach der zugrunde liegenden Methodik fragt.
Was Finance wirklich will, ist Cost-to-Serve auf Kunden- und Produktebene, inklusive fixer und variabler Komponenten, inklusive Drittanbieter-SaaS-Ausgaben wie Snowflake oder Twilio – in einem Format, das sich vor dem Board verteidigen lässt. Pricing-Teams brauchen das, um Margen festzulegen. Finance braucht es für das COGS-Reporting. Produktverantwortliche brauchen es, um zu wissen, welche Features die Marge nach unten ziehen.
Die meisten Cloud-Kostentools sind sehr gut darin, die Frage "Warum ist unsere AWS-Rechnung gestiegen?" zu beantworten. Sie wurden nie dafür entwickelt, die Frage "Verdient dieses Produkt Geld?" zu beantworten.
Dasselbe Problem trifft jetzt über die AI-Ausgaben ein – nur schneller. LLM-Inference-Kosten verhalten sich nicht wie EC2. Sie sind Request-getrieben, kundenspezifisch und wachsen schnell. Ein Billing-Export sagt Ihnen, was Bedrock oder OpenAI Ihnen letzten Monat berechnet hat. Er sagt Ihnen nicht, welches Produktfeature die Kosten verursacht hat, welches Kundensegment sie verbraucht hat oder ob die Unit Economics bei Skalierung aufgehen. Token-Volumen, Modellwahl, Prompt-Länge – nichts davon lässt sich einer Abrechnungsposition zuordnen. Finance beginnt, nach AI-COGS genauso zu fragen wie nach Cloud-COGS. Die Datenlücke ist identisch. Es steht mehr auf dem Spiel, weil sich die Kosten schneller entwickeln.
Your cloud bill shouldn't be a mystery
Optimization, automation, expertise. In one platform.
Das Problem mit der Rekonstruktion der Realität
Jedes Tool, das auf Billing-Exporten basiert, hat dieselbe strukturelle Einschränkung. Die Abrechnungsdatei sagt Ihnen, was Ihnen berechnet wurde. Sie sagt Ihnen nicht, warum – und auch nicht, welche Kunden die Kosten verursacht haben oder wie sich gemeinsam genutzte Ressourcen tatsächlich auf die Nutzer verteilen.
Attribute liest das laufende System statt der Abrechnungsdatei. Ein ultraleichter eBPF-Sensor auf Ihrer Compute-Infrastruktur beobachtet anhand von Laufzeitdaten auf Netzwerkebene, welche Workloads mit welchen Datenbanken und Services kommunizieren. Die Kostenzuordnung folgt dem tatsächlichen Verhalten, nicht Regeln über erwartetes Verhalten.
Am deutlichsten zeigt sich der Unterschied, wenn ein Stakeholder fragt, wie Sie auf eine Zahl gekommen sind. Bei Billing-basierter Attribution verfolgen Sie die Zahl über eine Kette aus Regeln und Annahmen zurück. Bei Runtime Attribution verfolgen Sie sie zurück bis zur beobachteten Netzwerkaktivität.
So sieht das in der Praxis aus
Nehmen wir die Kostentransparenz pro Team, eine der häufigsten FinOps-Anforderungen. Mit einem Tagging-basierten Tool sehen Sie Teamkosten nur so gut, wie es Ihre Tag-Abdeckung und Label-Hygiene zulassen. Gemeinsam genutzte Namespaces sind ein Problem. Services, die das Engineering letzte Woche deployt und noch nicht getaggt hat, sind unsichtbar.
Der Sensor von Attribute erfasst neue Workloads automatisch, weil er beobachtet, wie sie in der Infrastruktur kommunizieren, statt darauf zu warten, dass jemand sie labelt. Wenn Ihr Team "verrechenbare Kosten pro Team" ausweisen muss, liefert der Runtime-Ansatz eine Zahl, die Sie belegen können – weil sie widerspiegelt, was tatsächlich läuft.
Dasselbe Prinzip gilt auf Kundenebene. Wenn Sie wissen müssen, was es tatsächlich kostet, einen bestimmten Kunden zu bedienen – inklusive fixer Infrastruktur, variabler Compute-Kosten und SaaS-Tools –, kommen Sie mit einem Billing-Export ohne erheblichen manuellen Mapping-Aufwand nicht ans Ziel. Attribute baut dieses Mapping aus dem auf, was es beobachtet: welche Kunden-Workloads welche Services nutzen, in welchem Umfang, zu welchen Kosten. Wenn Kunden nach Produktkosten pro Region oder nach Produktprofitabilität über verschiedene Servicetypen hinweg fragen, gibt es darauf eine echte Antwort statt einer Schätzung.
Das gilt auch für AI-Kosten. Der Sensor von Attribute liest Aufrufe auf Netzwerkebene: welcher Service den Aufruf getätigt hat, welcher Kunden-Workload ihn ausgelöst hat und was er gekostet hat. Das ist die Zahl, mit der ein Pricing-Team entscheiden kann, ob es Inference-Kosten selbst trägt oder weitergibt.
Attribute hilft FinOps- und Finance-Teams zu verstehen, wofür Cloud- und SaaS-Ausgaben tatsächlich anfallen – mit Runtime Attribution statt manueller Tags und Billing-Exporten.
Warum scheitern Cloud-Kostenreports im Finance-Review?
Die meisten FinOps-Tools erstellen Reports aus Billing-Exporten, Allokationsregeln und Tags. Regeln veralten. Die Tag-Abdeckung ist selten vollständig. Wenn Finance fragt, wie eine Zahl zustande gekommen ist, führt die ehrliche Antwort auf eine Kette von Annahmen zurück, nicht auf beobachtete Daten. Genau das ist die Lücke.
Was ist Runtime Cost Attribution?
Runtime Attribution bedeutet, dass Kosten dem tatsächlichen Systemverhalten folgen statt Regeln über erwartetes Verhalten. Attribute setzt einen eBPF-Sensor ein, der auf Laufzeitebene beobachtet, welche Workloads mit welchen Services kommunizieren. Jede Kostenposition lässt sich auf beobachtete Netzwerkaktivität zurückführen – nicht auf eine Tagging-Entscheidung von vor 18 Monaten.
Was passiert mit nicht getaggten Ausgaben?
Bei Tagging-basierten Tools fallen nicht getaggte Ressourcen entweder unter den Tisch oder werden über einen synthetischen Schlüssel verteilt. Der Sensor von Attribute erfasst Workloads unabhängig davon, ob sie gelabelt wurden, weil er beobachtet, wie sie in der Infrastruktur kommunizieren. Neue Services, die letzte Woche deployt wurden, sind sofort sichtbar.
Kann Attribute Cost-to-Serve pro Kunde ausweisen?
Ja. Attribute ordnet Cloud- und SaaS-Ausgaben einzelnen Endkunden zu, indem es beobachtet, welche Kunden-Workloads welche Services nutzen, in welchem Umfang und zu welchen Kosten. Das ergibt echte Cost-to-Serve, inklusive fixer Infrastruktur, variabler Compute-Kosten und Drittanbieter-Tools wie Snowflake oder Twilio.
Was ist mit AI- und LLM-Inference-Kosten?
Inference-Kosten erscheinen in Billing-Exporten nicht mit ausreichendem Detailgrad, um nützlich zu sein. Der Sensor von Attribute liest Modellaufrufe auf Netzwerkebene und ordnet jede Anfrage dem Service, dem Kunden und dem Feature zu, die sie ausgelöst haben. Das ist die Zahl, die Pricing-Teams brauchen, um Margen für AI-Features festzulegen.
Worin unterscheidet sich das von CloudZero oder Apptio?
Diese Tools arbeiten mit Billing-Exporten und setzen Tagging voraus, bevor sie aussagekräftige Daten zeigen. Attribute liest stattdessen das laufende System. Kein Tagging nötig, keine Regelpflege – und die Methodik hält stand, wenn ein Stakeholder fragt, wie Sie auf eine Zahl gekommen sind.
