Cloud-Kostensteuerung für SaaS: Kosten pro Mandant kennen, begrenzen und senken

Dieser Leitfaden richtet sich an SaaS-Gründer, CTOs und Engineering Leads, deren Cloud-Kosten schneller wachsen als die Umsätze, oder die ein Preismodell festlegen möchten, ohne zu wissen, was ein Mandant kostet. Unser Leitfaden zur SaaS-Plattform-Entwicklung fasst die Cost-Habits in wenigen Zeilen zusammen; diese Seite macht daraus umsetzbare Steuerungsmaßnahmen.

Inhalt dieses Leitfadens

• Warum SaaS-Cloud-Kosten eigene Steuerungsmaßnahmen benötigen
• Erst alle Kosten zuordnen
• Kosten pro Mandant: drei Methoden zur Zuordnung
• Leitplanken, die Ausgaben frühzeitig erkennen
• Hebel zur Kostensenkung
• KI-Kosten pro Mandant
• Ein operativer Rhythmus
• Alternativen: Wer die Steuerungsmaßnahmen betreibt
• Praxisbeispiele: SaaS-Produkte, die Netbase entwickelt und betreibt
• Welche Leistungsnachweise vorliegen und welche nicht
• Grenzen dieses Leitfadens
• Häufig gestellte Fragen
• Nächster Schritt

Warum SaaS-Cloud-Kosten eigene Steuerungsmaßnahmen benötigen

In einem SaaS-Unternehmen sind Cloud-Ausgaben Teil der Herstellungskosten: Jeder neue Kunde erhöht sie. Drei Faktoren erschweren die Steuerung mit einem herkömmlichen IT-Budget.

• Gemeinsam genutzte Ressourcen verbergen die Mandantenkosten. Eine geteilte Datenbank oder ein gemeinsamer Cluster bedient Hunderte von Kunden, und die Rechnung zeigt nicht, wer was verbraucht hat. Microsofts Leitfaden für Mehrinstanzenlösungen benennt dies als zentrale Schwierigkeit: Die meisten Dienste schlüsseln die Nutzung nicht nach der eigenen Definition eines Mandanten auf.
• Die Rechnung wird durch Nutzung getrieben, nicht durch Mitarbeiterzahl. Ein einzelner Kunde, der einen großen Datensatz importiert oder umfangreiche Reports ausführt, kann die monatlichen Gesamtkosten verschieben.
• KI-Funktionen verursachen Kosten pro Aufruf. Model-Aufrufe und Token werden nutzungsbasiert abgerechnet, sodass ein einzelnes Feature die Marge eines Plans verändern kann – ohne jede Infrastrukturänderung.

Die Unit-Economics-Capability der FinOps Foundation beschreibt das Ziel: Technologieausgaben durch Kennzahlen wie Kosten pro Kunde mit dem Geschäftswert verbinden. Für ein SaaS-Produkt bedeutet das Kosten pro Mandant, pro Plan und pro Kerntransaktion.

Erst alle Kosten zuordnen

Steuerungsmaßnahmen sind nur so gut wie die Kostenzuordnung, auf der sie beruhen. Vor jeder Einsparung:

• Umgebungen nach Account oder Projekt trennen. Produktion, Staging und Entwicklung erhalten jeweils einen eigenen Account oder ein eigenes Projekt, damit sich ein vergessener Test-Cluster nicht in den Produktionskosten versteckt.
• Jede Ressource taggen. Umgebung, Dienst, Eigentümer und – bei dedizierten Ressourcen – Mandant. Tags sollten per Infrastructure as Code durchgesetzt werden, nicht per Konvention.
• Einen Eigentümer für nicht getaggte und gemeinsame Kosten benennen. Netzwerk, Logging, Support-Pläne und Datentransfer tragen selten ein Mandanten-Tag; sie werden nach einer dokumentierten Regel zugeordnet, nicht nach Schätzung.
• Nutzungsereignisse pro Mandant aufzeichnen. Dieselben Ereignisse, die die Abrechnung speisen, speisen auch die Kostenzuordnung. Ein SaaS-Produkt, das sie ab dem ersten Release ausgibt, wie in unserem SaaS-MVP-Architekturleitfaden empfohlen, kann Kostenfragen später beantworten.

Kosten pro Mandant: drei Methoden zur Zuordnung

Die meisten Produkte kombinieren diese Methoden: direkte Zuordnung für große Mandanten in einem dedizierten Tier, ein gemessener Anteil für den geteilten Tier und eine Schätzung für den verbleibenden Overhead. Microsofts Leitfaden empfiehlt, ein Indikativmaß von Zeit zu Zeit gegen einen gemessenen Basiswert zu prüfen, da ein Mandant mit umfangreichen Reports weitaus mehr Rechenleistung verbrauchen kann, als sein Speicherbedarf vermuten lässt. Der AWS SaaS Lens behandelt die Kosten pro Mandant aus demselben Grund als Teil seines Cost-Optimization-Pillars. Wie das Mandantenmodell selbst die Kosten beeinflusst, wird in Multi-Tenant-SaaS-Architektur behandelt.

Leitplanken, die Ausgaben frühzeitig erkennen

Die Kostenzuordnung zeigt, wohin das Geld geflossen ist; Leitplanken warnen vor der Rechnung.

• Budgets mit Meldungen pro Account, Dienst und Team. Die Google Cloud-Dokumentation stellt klar, dass ein reines Meldungsbudget keine Ausgaben begrenzt – ein Budget ist eine Warnung, keine Bremse.
• Anomalieerkennung. AWS Cost Anomaly Detection nutzt zum Beispiel maschinelles Lernen, um ungewöhnliche Ausgaben nach Dienst, Account, Region oder Nutzungstyp zu markieren. Meldungen sollten an den Channel des verantwortlichen Teams weitergeleitet werden, nicht an ein Finance-Postfach, das niemand liest.
• Mandantenlimits im Produkt durchsetzen. Plan-Entitlements begrenzen Speicher, Seats, API-Aufrufe und KI-Nutzung, sodass ein einzelner Mandant die Marge eines Plans nicht aufzehren kann. Dies ist die einzige Leitplanke, die wirkt, bevor Kosten entstehen.
• Automatisches Abschalten außerhalb der Produktion. Entwicklungs- und Testumgebungen werden außerhalb der Arbeitszeiten gestoppt, sofern nicht ausdrücklich widersprochen wird.

Hebel zur Kostensenkung

Die Hebel sollten in dieser Risikoreihenfolge angewendet werden: zuerst Verschwendung beseitigen, dann Ressourcen anpassen, dann committen. Ein Rabatt auf Kapazität, die nicht benötigt wird, ist weiterhin Verschwendung.

Alternativen: Wer die Steuerungsmaßnahmen betreibt

Unabhängig vom gewählten Ansatz muss das Produkt selbst Nutzungsdaten pro Mandant ausgeben; kein externes Tool kann diese später rekonstruieren. Netbase JSC implementiert diese Steuerungsmaßnahmen über Cloud-Plattform-Engineering und SaaS-Entwicklung und führt monatliche sowie quartalsweise Cost-Reviews im Rahmen von Managed Cloud Services durch. Die meisten Netbase-Projekte werden auf Festpreis-Basis nach einer Discovery-Phase abgewickelt.

Praxisbeispiele: SaaS-Produkte, die Netbase entwickelt und betreibt

• Cloodo Workspace. Ein mandantenfähiger digitaler Arbeitsplatz, den Netbase als Netbase Business Division entwickelt hat und betreibt, mit CRM-, HRM-, Cloud-ERP- und KI-Modulen in einem Produkt. Siehe den Cloodo-Eintrag.
• Cloud-ERP für einen US-Kunden (nicht genannt). Ein mandantenfähiges Cloud-ERP auf AWS, das Netbase seit 2020 als Offshore-Entwicklungs- und Managing-Partner betreut, bei dem jedes Kundenunternehmen in einem eigenen Workspace auf gemeinsamer Infrastruktur arbeitet. Siehe den Cloud-ERP-Eintrag.
• Printcart. Das Web-to-Print-SaaS der Netbase Business Divisions, das viele Händler über eine gemeinsame Plattform bedient. Siehe den Printcart-Eintrag.

Netbase JSC arbeitet auf AWS, Google Cloud, DigitalOcean und Cloudflare; es wird kein Cloud-Partner-Status beansprucht.

Welche Leistungsnachweise vorliegen und welche nicht

• Was vorliegt. Die oben genannten Einträge beschreiben mandantenfähige Produkte, die Netbase auf gemeinsamer Infrastruktur entwickelt und betreibt – genau der Kontext, für den diese Steuerungsmaßnahmen konzipiert sind.
• Was nicht vorliegt. Kein Netbase-Eintrag veröffentlicht eine Cloud-Rechnung, eine Einsparung, Kosten pro Mandant oder eine Marge – weder für eigene Produkte noch für Kundenprojekte. Nichts auf dieser Seite wird als gemessenes Kostenergebnis dargestellt.

Grenzen dieses Leitfadens

• Provider-Funktionen werden aus der jeweiligen Dokumentation zum Abrufdatum zitiert; Namen, Limits und Preise können sich ändern.
• Die Zuordnungsmethoden liefern Schätzwerte; die erforderliche Genauigkeit hängt vom eigenen Preismodell ab.
• Der Sicherheitsaspekt der Kostensteuerung – z. B. wer Ressourcen erstellen und Budgets ändern darf – folgt denselben rollenbasierten Zugangsregeln und MFA-Anforderungen wie jeder andere Admin-Zugang.

Nächster Schritt

Teilen Sie Ihre aktuelle Cloud-Kostenstruktur, Ihre Pläne und Ihre größten Mandanten mit uns, und wir vereinbaren ein Solution-Review, um Kostenzuordnung, Leitplanken und einen Review-Rhythmus einzurichten. Sie können auch mehr über Cloud-Plattform-Engineering erfahren oder weitere Netbase-Insights erkunden.

Verwandte Leistungen und Lösungen