Cloud-Broker: 30 Prozent weniger Multi-Cloud-Kosten

Ein typischer mittelständischer Maschinenbauer verteilt seine Workloads über drei Hyperscaler, ohne je den Gesamtpreis zu kennen. Ein Cloud-Broker und eine konsequente FinOps-Praxis können die Multi-Cloud-Rechnung spürbar drücken, in gut geführten Programmen in der Größenordnung von rund 30 Prozent. Dieser anonymisierte Praxisbericht bildet ein realistisches Szenario nach und zeigt, welche Hebel zählen und wo die Einsparung Arbeit statt Magie ist.

Das Wichtigste in Kürze

• Cloud-Broker schaffen Transparenz vor Verhandlung: Bevor das Unternehmen über Rabatte sprechen konnte, brauchte es eine konsolidierte Sicht auf alle drei Anbieter. Der Broker lieferte sie als zentrale Zwischenschicht für Beschaffung und Abrechnung.
• Die 30 Prozent kamen aus drei Quellen: Rightsizing ungenutzter Instanzen, Commitment-Rabatte über Reserved Instances und Savings Plans bei jedem einzelnen Anbieter sowie das Verschieben portabler Workloads dorthin, wo sie pro Leistungseinheit günstiger laufen.
• FinOps ist Betrieb, kein Projekt: Die größte Lektion war organisatorisch. Ohne ein festes Kostenmandat zwischen Finanzabteilung und Plattformteam wäre die Einsparung nach zwei Quartalen wieder verpufft.

Verwandt:Frontier-Modell per Behördenbescheid offline: Die Architektur-Lehre  /  Disaggregierte Inferenz: Warum AWS und Cerebras die GPU trennen

Was ist ein Cloud-Broker?

Was ist ein Cloud-Broker? Ein Cloud-Broker ist ein Vermittler zwischen einem Unternehmen und mehreren Cloud-Anbietern. Er bündelt Beschaffung, Abrechnung und teilweise das technische Management über AWS, Microsoft Azure, Google Cloud und kleinere Spezialanbieter hinweg. Statt mit jedem Hyperscaler einzeln zu verhandeln, läuft der Bezug über eine zentrale Schicht, die Verbräuche aggregiert, Rabatte aushandelt und eine einheitliche Kostensicht liefert.

In der DACH-Region gilt dieses Modell bislang als wenig genutzt. In vielen Mittelständlern wurden über Jahre Workloads bei dem Anbieter platziert, der gerade praktisch war, ohne dass je eine konsolidierte Rechnung entstand. Genau hier setzt der hier beschriebene Fall an: Der Maschinenbauer hatte produktive Lasten bei AWS, eine Microsoft-365-nahe Landschaft auf Azure und einige Datenanalyse-Workloads in der Google Cloud. Drei Verträge, drei Abrechnungslogiken, kein Gesamtbild.

Der Broker fungierte zunächst nicht als Sparmaschine, sondern als Übersetzer. Erst als alle Verbräuche in einer Ansicht standen, wurde sichtbar, wo Geld lag.

Der Ausgangspunkt: drei Anbieter, keine Kostenkontrolle

Vor dem Projekt lief die Cloud-Beschaffung dezentral. Einzelne Teams buchten Ressourcen nach Bedarf, niemand führte die Rechnungen zusammen. Die Finanzabteilung sah lediglich drei monatliche Sammelposten, die kontinuierlich stiegen, ohne dass jemand den Anstieg erklären konnte.

Typische Symptome einer Multi-Cloud-Landschaft ohne FinOps zeigten sich deutlich. Entwicklungsumgebungen liefen rund um die Uhr, obwohl sie nur tagsüber genutzt wurden. Datenbankinstanzen waren auf Spitzenlast dimensioniert, die nie eintrat. Snapshots und alte Volumes sammelten sich an, weil niemand für ihre Löschung zuständig war. Und über alle drei Anbieter hinweg wurde fast ausschließlich zum vollen Listenpreis bezahlt, weil keine Reserved- oder Savings-Vereinbarungen bestanden.

Die erste Inventur durch den Broker ergab, dass ein erheblicher Teil der Ausgaben auf Ressourcen entfiel, die entweder überdimensioniert oder schlicht vergessen waren. Das ist kein Sonderfall. Über Branchenstudien ist das Muster gut dokumentiert: Ungenutzte und überdimensionierte Kapazität gilt branchenweit als einer der größten Treiber von Cloud-Verschwendung.

Die drei Hebel, die wirklich zählten

Die Einsparung von rund 30 Prozent verteilte sich nicht gleichmäßig. Sie kam aus drei klar trennbaren Maßnahmen, die in dieser Reihenfolge umgesetzt wurden.

Erstens Rightsizing. Das Plattformteam glich tatsächliche Auslastung gegen gebuchte Kapazität ab und verkleinerte überdimensionierte Instanzen. Nicht genutzte Entwicklungsumgebungen bekamen automatische Abschaltzeiten außerhalb der Arbeitszeit. Verwaiste Volumes und Snapshots wurden systematisch entfernt. Dieser Schritt brachte die schnellsten Ergebnisse, weil er keine Vertragsverhandlung erforderte.

Zweitens Commitment-basierte Rabatte. Für stabile, dauerhaft laufende Workloads vereinbarte das Unternehmen Reserved Instances und Savings Plans. Solche Commitments sind anbietergebunden, sie werden also bei AWS, Azure und Google Cloud jeweils separat abgeschlossen. Der Vorteil der Broker-Schicht liegt im Einkauf: Sie bündelt das Gesamtvolumen und erreicht damit bessere Konditionen, als das Unternehmen pro Anbieter einzeln verhandeln könnte. Gegenüber dem reinen On-Demand-Bezug liegen die Nachlässe bei längerfristigen Commitments je nach Anbieter und Laufzeit deutlich im zweistelligen Prozentbereich.

Drittens Workload-Platzierung. Einige Analyse-Workloads waren weder an einen Anbieter gebunden noch latenzkritisch. Sie wanderten dorthin, wo sie pro Recheneinheit am günstigsten liefen. Das ist der anspruchsvollste Hebel, weil er Architekturarbeit verlangt und nur dort funktioniert, wo keine Datenresidenz- oder Latenzgründe dagegen sprechen.

Quelle: Eigene Darstellung des beschriebenen FinOps-Programms.

Welche Tools und Metriken den Unterschied machten

Technisch stützte sich das Programm auf eine Cost-Management-Plattform, die über den Broker bereitgestellt wurde und alle drei Anbieter normalisierte. Entscheidend war weniger das einzelne Werkzeug als die Vereinheitlichung: Erst als AWS-, Azure- und Google-Verbräuche in einer gemeinsamen Logik verglichen werden konnten, ließen sich Workloads überhaupt sinnvoll gegeneinander bewerten.

Als Steuerungsgrößen etablierte das Unternehmen einige wenige, aber konsequent verfolgte Metriken. Dazu zählten die Kosten pro Geschäftseinheit statt nur die Gesamtsumme, der Anteil der durch Commitments abgedeckten Ausgaben sowie die Quote ungenutzter Ressourcen. Diese FinOps-Kennzahlen sind in der Praxis verbreitet, weil sie Kosten an Wertschöpfung koppeln statt an reine Infrastrukturgröße.

Ein Tagging-Konzept sorgte dafür, dass jede Ressource einem Team und einem Kostenträger zugeordnet war. Ohne diese Zuordnung bleibt jede Kostenanalyse Stückwerk, weil niemand verbindlich verantwortlich ist.

Lessons Learned: Wo das Projekt fast scheiterte

Die technischen Hebel waren schnell identifiziert. Die eigentliche Hürde lag in der Organisation. Das Plattformteam konnte Empfehlungen aussprechen, hatte aber kein Mandat, sie gegen die Fachabteilungen durchzusetzen. So blieben Abschaltzeiten zunächst Theorie, weil einzelne Teams ihre Dauerläufer verteidigten.

Erst als Geschäftsleitung und Finanzabteilung dem Plattformteam ein klares Kostenmandat gaben, griffen die Maßnahmen dauerhaft. FinOps wirkt nur als dauerhafter Betriebsmodus mit klarer Verantwortung, nicht als einmaliges Aufräumen. Wird die Disziplin nicht institutionalisiert, kehrt die Verschwendung innerhalb weniger Quartale zurück, weil neue Workloads dieselben Fehler wiederholen.

Die zweite Lektion betraf den Broker selbst. Eine solche Zwischenschicht reduziert den direkten Draht zu den Hyperscalern und schafft eine Abhängigkeit. Das Unternehmen behielt deshalb bewusst das technische Know-how im Haus und nutzte den Broker für Beschaffung und Transparenz, nicht als Ersatz für eigene Cloud-Kompetenz.

Häufige Fragen

Bildquelle: KI-generiert (Juli 2026)