Cloud-Kostensteuerung für SaaS: wissen, begrenzen und senken, was jeder Mandant kostet

Dieser Leitfaden richtet sich an SaaS-Gründer, CTOs und Engineering Leads, deren Cloud-Rechnung schneller wächst als der Umsatz oder die dabei sind, einen Plan zu bepreisen, ohne zu wissen, was ein Mandant im Betrieb kostet. Unser Leitfaden zum SaaS-Platform-Engineering fasst die wichtigsten Kostengewohnheiten in wenigen Zeilen zusammen; diese Seite verwandelt sie in funktionierende Steuerungsmechanismen.

In diesem Leitfaden

• Warum SaaS-Cloud-Kosten eigene Steuerungsmechanismen brauchen
• Zunächst jede Ausgabe zuordnen
• Kosten pro Mandant: drei Methoden der Zuordnung
• Leitplanken, die Ausgaben frühzeitig erkennen
• Hebel, die die Rechnung senken
• KI-Kosten pro Mandant
• Ein operativer Rhythmus
• Alternativen: wer die Steuerungsmechanismen betreibt
• Praxisbeispiele: SaaS-Produkte, die Netbase baut und betreibt
• Was an Liefernachweisen vorliegt und was nicht
• Grenzen dieses Leitfadens
• Häufig gestellte Fragen
• Nächster Schritt

Warum SaaS-Cloud-Kosten eigene Steuerungsmechanismen brauchen

In einem SaaS-Unternehmen sind Cloud-Ausgaben Teil der Herstellungskosten: Jeder neue Kunde erhöht sie. Drei Faktoren machen es schwierig, sie mit einem gewöhnlichen IT-Budget zu managen.

• Gemeinsam genutzte Ressourcen verbergen die Kosten eines Mandanten. Eine gemeinsame Datenbank oder ein gemeinsamer Cluster bedient Hunderte von Kunden, und die Rechnung zeigt nicht, wer was verbraucht hat. Microsofts Leitfaden für Mehrbenutzer-Szenarien nennt dies die zentrale Schwierigkeit: Die meisten Dienste schlüsseln die Nutzung nicht nach der eigenen Definition eines Mandanten auf.
• Nutzung, nicht Mitarbeiterzahl, treibt die Rechnung. Ein einzelner Kunde, der einen großen Datensatz importiert oder aufwendige Berichte ausführt, kann die Monatssumme verschieben.
• KI-Funktionen haben einen Preis pro Aufruf. Modellaufrufe und Tokens werden pro Nutzung abgerechnet, sodass eine einzige Funktion die Marge eines Plans verschieben kann, ohne dass sich die Infrastruktur ändert.

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

Zunächst jede Ausgabe zuordnen

Steuerungsmechanismen sind nur so gut wie die ihnen zugrundeliegende Zuordnung. Vor jeder Einsparung:

• Umgebungen nach Konto oder Projekt trennen. Produktion, Staging und Entwicklung erhalten jeweils ein eigenes Konto oder Projekt, damit ein vergessener Test-Cluster nicht in den Produktionsausgaben versteckt bleibt.
• Jede Ressource taggen. Umgebung, Service, Verantwortlicher und – bei dedizierten Ressourcen – Mandant. Tags in Infrastructure-as-Code durchsetzen, nicht per Konvention.
• Einen Verantwortlichen für nicht getaggte und gemeinsame Kosten benennen. Netzwerk, Logging, Support-Pläne und Datentransfer tragen selten ein Mandanten-Tag; sie nach einer dokumentierten Regel zuordnen, nicht per Schätzung.
• Nutzungsereignisse pro Mandant führen. Dieselben Ereignisse, die die Abrechnung speisen, speisen auch die Kostenzuordnung. Ein SaaS-Produkt, das sie ab dem ersten Release ausgibt, wie in unserem Leitfaden zur SaaS-MVP-Architektur empfohlen, kann Kostenfragen später beantworten.

Kosten pro Mandant: drei Methoden der Zuordnung

Die meisten Produkte kombinieren sie: direkte Zuordnung für große Mandanten in einem dedizierten Tier, ein gemessener Anteil für den gemeinsamen Tier und eine Schätzung für den verbleibenden Overhead. Microsofts Leitfaden empfiehlt, ein indikatatives Maß von Zeit zu Zeit gegen eine gemessene Baseline zu prüfen, da ein Mandant, der aufwendige Berichte ausführt, deutlich mehr Rechenleistung nutzen kann, als sein Speichervolumen vermuten lässt. Der AWS SaaS Lens behandelt Kosten pro Mandant aus demselben Grund als Teil seines Cost-Optimization-Pillar. Wie das Mandantenmodell selbst die Kosten beeinflusst, ist in Multi-Tenant-SaaS-Architektur behandelt.

Leitplanken, die Ausgaben frühzeitig erkennen

Die Zuordnung zeigt, wohin das Geld geflossen ist; Leitplanken informieren Sie vor der Rechnung.

• Budgets mit Alerts pro Konto, Service und Team. Die Dokumentation von Google Cloud stellt ausdrücklich klar, dass ein reines Alert-Budget die Ausgaben nicht deckelt – ein Budget ist also eine Warnung, keine Bremse.
• Anomalieerkennung. AWS Cost Anomaly Detection beispielsweise nutzt maschinelles Lernen, um ungewöhnliche Ausgaben nach Service, Konto, Region oder Nutzungstyp zu kennzeichnen. Alerts an den Kanal des zuständigen Teams routen, nicht in ein Finanz-Postfach, das niemand liest.
• Mandanten-Limits, die im Produkt durchgesetzt werden. Plan-Berechtigungen begrenzen Speicher, Plätze, API-Aufrufe und KI-Nutzung, sodass ein einzelner Mandant die Marge eines Plans nicht aufzehren kann. Dies ist die einzige Leitplanke, die wirkt, bevor die Kosten entstehen.
• Automatisches Abschalten außerhalb der Produktion. Entwicklungs- und Testumgebungen stoppen außerhalb der Arbeitszeiten, sofern nicht ausdrücklich widersprochen wird.

Hebel, die die Rechnung senken

Hebel in dieser Risikoreihenfolge anwenden: zuerst Verschwendung beseitigen, dann Rightsizing durchführen, dann Commitments eingehen. Ein Rabatt auf Kapazität, die nicht benötigt wird, ist immer noch Verschwendung.

Alternativen: wer die Steuerungsmechanismen betreibt

Unabhängig vom gewählten Weg muss das Produkt selbst Nutzung pro Mandant ausgeben; kein externes Tool kann dies später rekonstruieren. Netbase baut diese Steuerungsmechanismen im Rahmen von Cloud Platform Engineering und SaaS-Entwicklung und führt monatliche und quartalsweise Kostenreviews als Teil von Managed Cloud Services durch. Die meisten Projekte von Netbase werden auf Festpreisbasis nach einer Discovery-Phase abgewickelt.

Praxisbeispiele: SaaS-Produkte, die Netbase baut und betreibt

• Cloodo Workspace. Ein mandantenfähiger digitaler Arbeitsplatz, den Netbase als Netbase Business Division gebaut 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 namentlich genannt). Ein mandantenfähiges Cloud-ERP auf AWS, das Netbase seit 2020 als Offshore-Entwicklungs- und Managing-Partner weiterentwickelt, bei dem jedes Kundenunternehmen in einem eigenen Workspace auf gemeinsamer Infrastruktur arbeitet. Siehe den Cloud-ERP-Eintrag.
• Printcart. Die Web-to-Print-SaaS der Netbase Business Divisions, die viele Händler von einer Plattform aus bedient. Siehe den Printcart-Eintrag.

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

Was an Liefernachweisen vorliegt und was nicht

• Was vorliegt. Die obigen Einträge beschreiben mandantenfähige Produkte, die Netbase auf gemeinsamer Infrastruktur baut und betreibt – das ist der Kontext, für den diese Steuerungsmechanismen geschrieben 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 Kunden. Nichts auf dieser Seite wird als gemessenes Kostenergebnis angeboten.

Grenzen dieses Leitfadens

• Provider-Funktionen werden aus deren eigener Dokumentation zum Zugriffsdatum zitiert; Namen, Limits und Preise können sich ändern.
• Die Zuordnungsmethoden liefern Schätzungen, und die richtige Genauigkeit hängt vom eigenen Preismodell ab.
• Die Sicherheitsseite der Kostensteuerung – etwa wer Ressourcen erstellen und Budgets ändern darf – folgt denselben rollenbasierten Zugriffsregeln und MFA-Regeln wie jeder andere Admin-Zugang.

Nächster Schritt

Teilen Sie uns Ihre aktuelle Cloud-Rechnungsstruktur, Ihre Pläne und Ihre größten Mandanten mit, und wir vereinbaren ein Lösungsreview, um Zuordnung, Leitplanken und einen Review-Rhythmus einzurichten. Sie können auch Cloud Platform Engineering ansehen oder weitere Netbase Insights erkunden.

Verwandte Leistungen und Lösungen