Der Cost Allocation Gap: Warum ein Großteil Ihres Azure-Spends keinem Kunden zugeordnet ist

Wenn Sie gefragt werden, was ein bestimmter Kunde in Azure kostet, und die ehrliche Antwort "das wissen wir nicht genau" lautet — sind Sie nicht allein. Der Cost Allocation Gap ist in Multi-Tenant-SaaS die Regel, nicht die Ausnahme.

Der Cost Allocation Gap beschreibt den Anteil Ihres Cloud-Spends, der keiner Kostenstelle, keinem Kunden und keinem Produkt eindeutig zugeordnet werden kann. Er ist nicht das Ergebnis von Nachlässigkeit — er ist die strukturelle Folge davon, wie moderne SaaS-Architekturen gebaut werden.

Wie der Gap entsteht

In einer klassischen IT-Umgebung mit dedizierter Infrastruktur pro Abteilung ist Cost Allocation simpel: Eine Ressourcengruppe gehört einem Team, fertig. Moderne SaaS-Architekturen sind aus guten Gründen anders gebaut — geteilte Datenbanken, geteilte Compute-Ressourcen, geteilte Function Apps, die Hunderte oder Tausende von Tenants gleichzeitig bedienen. Genau diese Effizienz, die Skalierung günstig macht, ist der Grund, warum klassisches Tagging an seine Grenzen stößt.

Wenn 100 Kunden auf derselben Function App laufen, hilft eine Resource-Group-Tag-Strategie nicht weiter. Die Ressource lässt sich nicht aufteilen, ohne zusätzliche Logik einzuführen, die misst, welcher Tenant welchen Anteil verursacht hat.

Die drei häufigsten Ursachen im Detail

1. Geteilte Infrastruktur ohne Verbrauchsmessung

Shared Compute, Shared Storage und Shared Datenbanken sind aus Kostensicht günstig — aus Allocation-Sicht ein blinder Fleck. Ohne anwendungsseitiges Metering bleibt nur eine grobe Schätzung über Anzahl der Tenants, die die tatsächliche Lastverteilung ignoriert.

2. Fehlende oder inkonsistente Tagging-Policy

Selbst wenn Ressourcen grundsätzlich einem Kunden zuordenbar wären, scheitert die Allocation oft an der Praxis: Tags werden bei der Erstellung vergessen, unterschiedlich benannt, oder bei Infrastructure-as-Code-Deployments nicht durchgesetzt. Eine Policy ohne technische Governance — etwa über Azure Policy Definitions — bleibt eine Empfehlung, keine Regel.

3. Historisch gewachsene Ressourcen ohne Rollout

Eine neue Tagging-Strategie gilt meist nur für neu erstellte Ressourcen. Der Bestand an Altressourcen — oft der größte Kostenblock — bleibt unberührt, wenn kein expliziter Rollout auf bestehende Infrastruktur erfolgt. Das ist in der Praxis oft der größte Hebel und gleichzeitig der am häufigsten übersprungene Schritt.

Warum der Gap teurer ist, als er aussieht

Ein hoher Allocation Gap hat drei direkte Folgen, die über reine Reporting-Unschärfe hinausgehen:

• Falsche Pricing-Entscheidungen: Ohne Cost per Customer wissen Sie nicht, welche Kundensegmente tatsächlich profitabel sind und welche subventioniert werden.
• Verzögerte Reaktion auf Anomalien: Ein Kostensprung in einer geteilten Ressource lässt sich nicht auf seine Ursache zurückführen, wenn die Allocation fehlt — die Anomalie wird spät oder gar nicht erkannt.
• Board- und CFO-Vertrauen: Wiederkehrende "Wir wissen es nicht genau"-Antworten auf Kostenfragen untergraben die Position von Engineering-Leadership gegenüber Finance.

Wie sich der Gap systematisch schließen lässt

Die Reihenfolge ist entscheidend — die meisten internen Versuche scheitern, weil sie diese Reihenfolge umdrehen:

1. Status-Quo messen. Bevor irgendetwas implementiert wird: Wie hoch ist die aktuelle Tagging-Coverage? Welche Top-Ressourcen tragen keine verwertbaren Tags?
2. Tagging Policy Design. Verbindliche Naming Conventions, die sowohl Engineering als auch Finance verstehen und nutzen können.
3. Technische Governance. Azure Policy Definitions, die nicht-konforme Ressourcen sichtbar machen — direkt im Azure Portal, nicht nur in einem nachträglichen Report.
4. Rollout auf Bestandsressourcen. Der unbequeme, aber wirkungsvollste Schritt. Ohne ihn bleibt der Großteil des historischen Spends weiterhin unzugeordnet.
5. Proxy-Metriken für geteilte Ressourcen. Wo direkte Zuordnung nicht möglich ist, schließen verbrauchsbasierte Näherungswerte die Lücke, bis Metering verfügbar ist.

Nächster Schritt

An dieser Stelle stellt sich häufig die Frage, ob ein FinOps-Tool das Problem nicht einfach automatisch löst. Die ehrliche Antwort — und warum sie meist "nein" lautet — ist Thema des nächsten Artikels.