Die Cloud sollte günstig und elastisch sein. Elastisch — meistens ja. Günstig — kommt darauf an, vor allem wenn niemand die Rechnung öfter als einmal im Quartal ansieht.
In einem typischen KMU wachsen die Cloud-Kosten leise. Jemand hat für ein Wochenende eine Test-VM gestartet, jemand anderes das Backup-Kontingent erhöht, jemand ein „Test”-Abo abgeschlossen — und zwei Jahre später zahlen Sie für drei parallele Entwicklerkonten, an die sich niemand erinnert. Das ist nicht die Schuld der Cloud. Das ist das Abrechnungsmodell — Sie zahlen für das, was Sie laufen ließen, nicht für das, was Sie tatsächlich benutzt haben.
FinOps klingt nach einem Buzzword für Konzerne mit zehnköpfigem Optimierungsteam. Im KMU ist es viel einfacher: Einmal im Monat beantwortet eine Person drei Fragen und schaltet ab, was keinen Sinn ergibt. Im Folgenden zerlegen wir das in seine Bestandteile.
Beginnen Sie damit, die Rechnung anzusehen
Klingt trivial, aber in der Hälfte der Firmen, in die wir kommen, sieht nur die Buchhalterin die Cloud-Rechnung — und sie bucht sie als Kosten, ohne einschätzen zu können, ob 6 000 PLN viel oder wenig sind. Der Inhaber merkt, dass etwas nicht stimmt, wenn die Jahresrechnung 40% über dem Plan liegt.
Der erste Schritt: Die letzten 6-12 Monate in eine Tabelle werfen und den Trend sehen. Sie brauchen kein FinOps-Werkzeug für 2 000 PLN pro Monat. Excel plus CSV-Export aus dem Billing-Portal (Azure Cost Management, AWS Cost Explorer, Microsoft 365 Admin Center, Google-Workspace-Panel) reicht.
- Erfassen Sie die Kosten des letzten Jahres — Monat für Monat, Anbieter für Anbieter.
- Teilen Sie in Kategorien: Compute (VMs, Dienste), Storage (Disks, Backups), Lizenzen (M365, Copilot, per-User-SaaS), Netzwerk und ausgehender Traffic.
- Markieren Sie Monate mit einem Sprung von +20% gegenüber dem Vormonat. Notieren Sie, was in der Firma passiert ist.
- Bestimmen Sie eine Person, die für diese Tabelle verantwortlich ist — am besten IT oder Controlling, nicht „alle”.
Dieser eine Schritt — die Rechnung an einer Stelle sehen — löst meist 20-30% des Problems. Vergessene Dinge werden sichtbar.
Ein konkretes Beispiel
Bei einem unserer Kunden — ein 24-köpfiges Ingenieurbüro auf Microsoft 365 und Azure — wuchs die monatliche Azure-Rechnung innerhalb von acht Monaten von 900 PLN auf 6 400 PLN. Niemand bemerkte es, weil die Rechnung automatisch von einer Firmenkarte abgebucht wurde und in der Buchhaltung landete.
Zwei Stunden im Portal ergaben:
- Eine Windows-Server-Test-VM, ein Jahr zuvor „für eine Woche” gestartet, lief 24/7. Kosten: 2 100 PLN pro Monat.
- Zwei 512-GB-Premium-SSDs waren an Maschinen angehängt, die es nicht mehr gab. 380 PLN pro Monat allein für die Disks.
- Backups waren auf 1,8 TB angewachsen — niemand hatte eine Aufbewahrungsfrist gesetzt, Versionen aus 2023 waren noch dabei. 470 PLN pro Monat.
- Zwei Entwicklerkonten, übriggeblieben nach dem Weggang eines Programmierers, verbrauchten M365-E3- und Visual-Studio-Enterprise-Lizenzen. Zusammen: 620 PLN pro Monat.
Das Abschalten und Aufräumen dauerte einen Tag. Die Rechnung sank auf 2 100 PLN pro Monat — 4 300 PLN Einsparung pro Monat, 51 600 PLN im Jahr. Die Firma stellte dafür einen weiteren Konstrukteur ein.
Das ist kein Ausnahmefall. Das ist der Regelfall. In der Cloud bleiben die Steine auf der Baustelle liegen — man sieht sie nur von der Straße nicht.
Drei Fragen für den monatlichen Review
Sie brauchen keinen 40-Folien-FinOps-Prozess. Sie brauchen einen wiederkehrenden Kalendereintrag — „Cloud-Review”, einmal pro Monat, 60 Minuten, IT und Finanzen im Raum. In diesem Termin beantworten Sie drei Fragen.
Ist etwas um mehr als 15% gegenüber dem Vormonat gestiegen? Wenn ja, finden Sie eine konkrete Ursache. Nicht „allgemeines Wachstum”. Konkret: eine neue VM, eine neue Integration, ein neuer Nutzer, ein neues Data Warehouse. Wenn Sie es nicht wissen, heißt das: niemand weiß es — und dieses Wissen muss aufgebaut werden.
Gibt es Ressourcen, die niemand nutzt? VMs, Disks, Snapshots, Workspaces, Nutzerkonten von Menschen, die vor drei Monaten gegangen sind. Azure und AWS bieten einfache Berichte für „unattached resources” und „idle VMs”. Ausführen und abschalten, was geht. Das ist keine Investition — das ist Aufräumen.
Zahlen wir irgendwo zu viel? 8-vCPU-Instanzen dort, wo 2 reichen würden. Premium-SSD unter Archivdateien. Eine M365-E5-Lizenz für jemanden, der nur E-Mail nutzt. Dreijahres-Reservierungen für Workloads, die es nächstes Jahr vielleicht nicht mehr gibt — oder keine Reservierungen für Workloads, die es sicher geben wird. Bei Defaults bleiben ist die teuerste Form von Trägheit.
Setzen Sie Alarme, bevor Sie sie löschen müssen
Alle drei großen Anbieter (Azure, AWS, Google Cloud) bieten kostenlose Budget-Alarme. Sie sind in 15 Minuten eingerichtet. Meist macht es niemand, „weil bisher nicht nötig”. Nötig wird es genau einmal — in dem Monat, in dem jemand versehentlich eine GPU-Instanz für 400 PLN pro Tag startet.
Das Minimum, das wir bei jedem Kunden konfigurieren:
- Alarm bei 80% und 100% des Monatsbudgets — E-Mail an Inhaber und IT.
- Alarm bei einem täglichen Sprung von mehr als 30% gegenüber dem 7-Tage-Schnitt — fängt „neues Spielzeug” ab.
- Alarm bei neu gestarteten GPU-, Dedicated-Host- oder High-Memory-Instanzen — sie können pro Monat mehr kosten als ein kompletter Arbeitsplatz.
Das ersetzt den monatlichen Review nicht, aber es kauft Ruhe zwischen den Reviews. Es geht darum, das Problem zu bemerken, wenn es 500 PLN kostet, nicht 15 000 PLN.
Tags und Konventionen, damit man weiß, wem was gehört
In einer 15-köpfigen Firma reicht das Gedächtnis. In einer 40-köpfigen Firma, in der jede Abteilung eigene Projekte fährt, weiß nach einem Jahr niemand mehr, wofür „vm-test-02” gedacht war. Tags (Labels auf Ressourcen) sind die Antwort.
In der Praxis reichen drei: owner (Vor- und Nachname), project oder department, environment (Produktion, Test, Dev). Jede neue Ressource ohne diese drei Tags gilt als Waise — nach 30 Tagen Abschaltkandidat. Klingt hart? Waisen bekommen das. Niemand zahlt für etwas, zu dem sich keiner bekennt.
- Definieren Sie 3 Pflicht-Tags und halten Sie es in einem Satz im internen Wiki fest.
- Fügen Sie in Azure/AWS eine Policy hinzu, die Tags bei Anlage neuer Ressourcen erzwingt.
- Einmal pro Quartal einen „untagged resources”-Bericht laufen lassen und aufräumen.
Ohne das läuft FinOps auf Raten hinaus, wem was gehört.
Fallen, in die man leicht tappt
Ein paar Dinge, die man wissen sollte, bevor man „optimiert”:
- Kaufen Sie keine 3-Jahres-Reservierungen für Projektumgebungen. Eine Reservierung bringt 30-50% Ersparnis, bindet Sie aber an eine konkrete Instanz. Gut für stabile Produktion, schlecht für „ein Projekt, das sich vielleicht entwickelt”.
- Löschen Sie Backups nicht gedankenlos, um beim Storage zu sparen. Sehen Sie sich die Aufbewahrung an, aber behalten Sie echte Kopien für einen Ransomware-Fall. 300 PLN Ersparnis pro Monat sind es nicht wert, am Tag X ohne Backup dazustehen.
- Achten Sie auf ausgehenden Traffic (Egress). Der Datentransfer aus der Cloud nach außen kann teurer sein als die Speicherung selbst. Wenn Sie täglich 500 GB von Azure ins Büro kopieren, prüfen Sie die Rechnung — der Sync-Job kann mehr kosten als der Server, den er ersetzen sollte.
- SaaS-Lizenzen sind auch Cloud. M365, Copilot, Salesforce, Slack, Asana — behandeln Sie das als ein Budget mit Azure/AWS. SaaS-Konsolidierung und Cloud-FinOps sind zwei Seiten derselben Sache.
Wie geht es weiter
Cloud-Kostenkontrolle ist kein Quartalsprojekt. Es ist eine 60-Minuten-Gewohnheit pro Monat. Eine Firma, die diese Gewohnheit hat, zahlt weniger und schläft ruhiger. Eine Firma, die sie nicht hat, erfährt es aus der Rechnung.
Wenn Sie nicht wissen, wo Sie in Ihrer Cloud anfangen sollen — zeigen Sie uns die letzten drei Rechnungen von Azure, AWS oder M365. In einer halben Stunde nennen wir Ihnen drei Stellen, an denen Sie wahrscheinlich zu viel zahlen. Ohne Verpflichtungen und ohne Folien.
Die Cloud wird nicht von selbst teurer. Sie wird teurer, wenn niemand hinsieht.