Hosting-Kosten vor dem Launch realistisch berechnen

Beginne mit einer Lastannahme, nicht mit einem Tarif

„Unsere Anwendung kostet 20 Euro im Monat“ ist keine Schätzung, solange Nutzer, Requests, Daten und Betriebszeit fehlen. Beschreibe zuerst drei Szenarien: einen ruhigen Monat, den erwarteten Betrieb und eine realistische Spitze nach Launch oder Kampagne.

Für jedes Szenario notierst du aktive Nutzer, Requests, durchschnittliche Antwortgröße, Hintergrundjobs, gespeicherte Daten, tägliche Builds und benötigte Verfügbarkeit. Die Zahlen müssen nicht perfekt sein; sie müssen sichtbar und veränderbar sein.

Compute ist nur die erste Zeile

Berechne Webprozesse und Worker getrennt. Ein API-Dienst kann rund um die Uhr laufen, während ein Import-Worker nur einige Stunden benötigt. Berücksichtige Mindestinstanzen, Vorschauumgebungen und Staging. Zwei kleine dauerhaft laufende Dienste können mehr kosten als ein größerer Dienst, der mehrere Prozesse sinnvoll bündelt.

Prüfe, ob Preise pro reservierter Kapazität oder tatsächlicher Nutzung gelten. Autoscaling senkt keine Kosten, wenn die Mindestanzahl bereits den ganzen Monat läuft. Bei mehreren Prozessen zählt außerdem der Speicher pro Prozess; ein geladenes Modell oder großer Cache wird häufig vervielfacht.

Daten haben drei verschiedene Preise

Eine Datei verursacht Speicher, Requests und ausgehenden Transfer. Schätze diese Komponenten getrennt. Ein öffentliches Bild, das oft ohne Cache ausgeliefert wird, kann mehr Transferkosten als Speicherkosten erzeugen.

Für die Datenbank zählen Größe, Compute, I/O, Backups, Wiederherstellung und mögliche Replikate. Verbindungen sind eine Kapazitätsgrenze, auch wenn sie nicht einzeln berechnet werden. Eine zu kleine Datenbank kann durch langsame Requests zusätzliche Webinstanzen auslösen.

Builds, Logs und feste Ressourcen

Häufige Deployments verbrauchen Build-Minuten und Artefaktspeicher. Logs wachsen mit Traffic und Fehlern; lege Aufbewahrung und Filter fest, statt alles unbegrenzt zu speichern. Rechne Domains, Zertifikate, feste IP-Adressen, Support und Monitoring hinzu, wenn sie nicht im Paket enthalten sind.

Backups sind kein optionaler Rabattposten. Ein billiger Dienst ohne getestete Wiederherstellung verlagert Kosten in den nächsten Vorfall. Messe Restore-Zeit und berücksichtige eine Kopie außerhalb der primären Fehlergrenze.

Kosten pro Ergebnis statt pro Server

Teile die Gesamtkosten durch eine Geschäftsgröße: aktive Kunden, abgeschlossene Bestellungen oder erfolgreich verarbeitete Dokumente. Das FinOps Framework zu Unit Economics beschreibt genau diese Verbindung zwischen Gesamtkosten und einer messbaren Produkteinheit. So wird sichtbar, ob Wachstum wirtschaftlich bleibt. Ergänze einen Warnwert und ein hartes Limit für variable Nutzung, ohne die Produktion überraschend abzuschalten.

Vergleiche Plattformen mit demselben kleinen Referenzdienst. Nutze identische Regionen, Datenmengen, Backups und Supportannahmen. Notiere auch Engineering-Zeit für Updates, Sicherheit, Bereitschaft und Recovery. Ein Managed Service darf teurer aussehen und insgesamt günstiger sein, wenn er wiederkehrende Arbeit zuverlässig entfernt.

Eine Rechnung, die nach dem Launch besser wird

Speichere Annahmen und tatsächliche Monatswerte nebeneinander. Ersetze Schätzungen durch Messdaten, erkläre Abweichungen und aktualisiere die drei Szenarien. Das Ziel ist keine einmalig perfekte Zahl, sondern ein Modell, das früh zeigt, welcher Nutzungsfaktor die nächste Rechnung verändert.

Häufige Fragen

Welche Hosting-Kosten werden häufig vergessen?

Ausgehender Transfer, Logs, Build-Minuten, Backups, feste Adressen, Mindestinstanzen und der Betriebsaufwand fehlen oft in der ersten Rechnung.

Wie viele Szenarien sollte eine Schätzung enthalten?

Mindestens einen ruhigen Monat, einen erwarteten Monat und eine Lastspitze, jeweils mit denselben nachvollziehbaren Annahmen.

Ist der günstigste Compute-Tarif immer die beste Wahl?

Nein. Eine niedrige Instanzgebühr kann durch Transfer, Datenprodukte oder zusätzliche Betriebsarbeit deutlich teurer werden.