Die Cloud-Rechnung sinkt,
eine benannte Ressource nach der anderen.
Mit CerteroX Cloud Management laufen sechsundzwanzig benannte Prüfungen auf zwölf Cloud- und Datenplattformen. Jeder Befund ist eine konkrete Ressource, ein Verantwortlicher, der die Änderung genehmigen kann, und ein Schwellenwert, den Sie festlegen.
Die Governance-Ebene verhindert dann, dass die Verschwendung nachwächst.
Optimierungslauf
BeispielhaftPool · engineering · letzte 24 Stunden
26 von 26 Prüfungen ausgewertet
- Instances in Stopped State for a Long Time gestoppt ≥ 14 Tage, Ressourcen weiterhin belegt
- 40
- Obsolete Snapshot Chains Root-Image deregistriert
- 7
- Kubernetes Rightsizing Requests vs. beobachtete Nutzung
- 12 ns
- Reserved Instances Opportunities stabile Nutzung seit 150 Tagen
- 18
- Verstoß gegen Tag-Korrelation Verantwortlicher gesetzt, Kostenstelle fehlt
- 3
Jeder Befund enthält
Schwellenwert · Ausschlüsse · Ausnahmen
Cloud-Verschwendung ist eine Liste von Dingen, die jemand abschalten kann.
Cloud-Rechnungen wachsen, weil niemand sieht, welche Server, Datenbanken und Speicher konkret ungenutzt sind oder wer sie abschalten darf. Kosten-Dashboards zeigen die Summe nach Service. Im Meeting ist man sich also einig, dass es Verschwendung gibt, und geht ohne Entscheidung auseinander. CerteroX macht aus der Rechnung eine Liste benannter Ressourcen, jede mit einem Verantwortlichen und einer empfohlenen Maßnahme.
- Kosten
Keine Ausgaben mehr für Dinge, die niemand nutzt.
Sechsundzwanzig Prüfungen suchen nach ungenutzten, überdimensionierten und vergessenen Ressourcen auf zwölf Cloud- und Datenplattformen, und jeder Befund sagt genau, was zu ändern ist.
- Risiko
Änderungen werden von der richtigen Person genehmigt.
Jeder Befund geht an den Verantwortlichen, der ihn genehmigen kann, innerhalb von Grenzen, die Sie festlegen. So gehen Einsparungen nie zulasten von etwas, worauf das Unternehmen angewiesen ist.
- Aufwand
Die Bereinigung muss nicht wiederholt werden.
Richtlinien überwachen auch nach dem ersten Durchgang weiter. So kehrt die Verschwendung nicht drei Monate später unbemerkt zurück, und das Team fängt nicht jedes Quartal von vorn an.
Das Problem
Jedes Kosten-Dashboard endet eine Frage vor der Entscheidung.
Eine Maßnahme braucht eine Ressource, einen Verantwortlichen und ein Datum. Kosten nach Service liefern keines der drei, und so endet das Meeting, wo es begonnen hat.
29%
der Cloud-Ausgaben sind Verschwendung, erstmals seit fünf Jahren wieder steigend
Ein Branchendurchschnitt, abgeleitet aus der Umgebung anderer. In Ihrer Umgebung kommt jeder Prozentpunkt davon mit einem Ressourcennamen.
- 01 kein Verantwortlicher, keine Maßnahme
Alle sind sich einig, dass das Rightsizing richtig ist. Niemand darf es genehmigen.
Die Instanz gehört zu einem Konto, das zu einem Team gehört, das sich letztes Jahr neu organisiert hat. Ohne Zuständigkeit bleibt der Befund im Backlog liegen, bis ihn jemand in technische Schulden umbenennt.
Zuweisungsregeln mit neun Bedingungstypen für automatische Verantwortlichkeiten Cloud Management
- 02 das Tagging-Projekt wird nie fertig
Ihr Tagging-Standard ist eine Wiki-Seite und vierzig Prozent der Ressourcen.
Die Zuordnung wartet auf ein Tagging-Programm, das nie fertig wird. Also beginnt das Showback nie, und niemand spürt die Kosten dessen, was er betreibt.
Virtuelles Tagging, unabhängig von cloud-nativen Tags berechnet Cloud Management
- 03 für Requests dimensioniert
Kubernetes ist eine Zeile auf der Rechnung und der halbe Cluster.
Nodes sind auf die Requests ausgelegt, die Entwickler deklariert haben. Der Cluster läuft bei einem Drittel dessen, was er reserviert, und die Rechnung lässt sich nicht nach Namespace aufschlüsseln.
Kubernetes-Kosten und -Auslastung nach Namespace, Node und Service Cloud Management
- 04 Die Einsparung, die zurückkam
Sie haben im März aufgeräumt. Im Juni war alles wieder da.
Nichts hatte eine Lebensdauer, kein Limit war gesetzt, und keine Richtlinie griff, als dieselbe Art von Ressource wieder auftauchte. Optimierung ohne Governance ist ein Dauerprojekt, jedes Quartal aufs Neue.
Ressourcen-TTL mit automatischer Durchsetzung des Lebenszyklus Cloud Management
- Verschwendung ist eine Liste, die Sie abarbeiten, und dann eine Richtlinie, die verhindert, dass sich die Liste neu aufbaut.
So hilft CerteroX Cloud Management
Demo buchenDrei der fünf Disziplinen.
Jedes Produkt läuft eigenständig und nutzt dasselbe Asset-Modell, daher erfordern produktübergreifende Aufgaben keinen Integrationsaufwand.
- Primär CerteroX Cloud Management Sechsundzwanzig benannte Prüfungen, ein Kostenmodell über zwölf Plattformen und Richtlinien, die greifen. Mehr erfahren
- Gilt auch für CerteroX AI Management Dieselbe Empfehlungs-Engine, angewendet auf GPU-Flotten und ML-Executors. Mehr erfahren
- Gilt auch für CerteroX ITAM Cloud-Instanzen, abgeglichen mit demselben Asset-Datensatz wie alles andere, was Sie besitzen. Mehr erfahren
Sie sehen die vollständigen technischen Details. Schalten Sie sie aus, um die Kurzfassung zu sehen.
Technische Details ausblendenVier Schritte, und nur einer davon ist, die Verschwendung zu finden.
Die meisten Tools erledigen den zweiten. Der erste entscheidet, ob überhaupt etwas umgesetzt wird, und der vierte, ob es dauerhaft behoben bleibt.
-
Zuordnen bis zum letzten pounddollareuro
Zuständigkeit kommt vor Optimierung, denn ein Befund ohne Verantwortlichen ist bedeutungslos.
- Kostenpools mit den Typen Budget, Geschäftsbereich, Team, Projekt, CI/CD oder Asset Cloud Management
- Zuweisungsregeln mit neun Bedingungstypen für automatische Verantwortlichkeiten Cloud Management
- Virtuelles Tagging, unabhängig von cloud-nativen Tags berechnet Cloud Management
- Native FOCUS-Unterstützung: die offene FinOps-Spezifikation für Kosten- und Nutzungsdaten Cloud Management
- Pool-basiertes Showback und Chargeback mit prognosebasierten Überschreitungsstatus Cloud Management
-
Verschwendung beim Namen nennen
Jeder Befund ist eine benannte Prüfung an einer benannten Ressource, mit dem Schwellenwert, der ihn ausgelöst hat. Nichts wird als „potenzielle Einsparungen identifiziert“ gemeldet.
- Verwaiste Instanzen, Images, Load Balancer, S3-Buckets und Kinesis-Streams Cloud Management
- Veraltete Images, IPs, Snapshots und Snapshot-Ketten Cloud Management
- Gestoppte, aber nicht freigegebene Instanzen und lange nicht angehängte Volumes Cloud Management
- Rightsizing von Instanzen und Erkennung nicht ausgelasteter RDS-Instanzen Cloud Management
- Kubernetes-Rightsizing und Duplikatsuche im Objektspeicher Cloud Management
- Schwellenwerte pro Prüfung, Pool-Ausschlüsse und Konto-Ausnahmen Cloud Management
-
Commitments zum richtigen Zeitpunkt eingehen
Commitment-Rabatte sind der größte einzelne Hebel und werden am leichtesten sechs Monate zu spät gekauft.
- Analyse der Abdeckung durch Reserved Instances und Savings Plans Cloud Management
- Kaufgelegenheiten für Reserved Instances und Savings Plans Cloud Management
- Möglichkeiten für Instanz-Generationswechsel und regionsübergreifende Migration Cloud Management
- Kurzlebige Instanzen als Kandidaten für Spot und Preemptible markiert Cloud Management
- VM-Energiezeitpläne für automatisches Starten und Stoppen Cloud Management
-
Den Stand halten
Das ist die Hälfte von FinOps, die die meisten Tools auslassen: Richtlinien, die greifen, bevor die Rechnung kommt.
- Ressourcen-TTL mit automatischer Durchsetzung des Lebenszyklus Cloud Management
- Gesamt- und Tageslimits für Ausgaben pro Ressource oder Pool Cloud Management
- Erkennung von Ausgabenanomalien gegenüber einem gleitenden Tagesdurchschnitt Cloud Management
- Tag-Compliance: Pflicht-Tags, verbotene Tags und Korrelationsregeln Cloud Management
- Erkennung von Anomalien bei der Ressourcenanzahl und Richtlinien für Ressourcenkontingente Cloud Management
- Verlauf von Constraint-Verstößen und Nachverfolgung erkannter Constraints Cloud Management
Lassen Sie sich jede dieser Funktionen direkt im Produkt zeigen, auf dem Bildschirm, auf dem sie stattfindet.
So sieht der Zielzustand aus.
Eine reife FinOps-Praxis erkennt man an ihren Meetings. Niemand streitet über die Summe.
- 01
Jeder Befund hat einen Namen und einen Verantwortlichen.
Abandoned Kinesis Streams, genau unter diesem Namen. Die Ressource, der Pool, zu dem sie gehört, und die Person, die die Änderung genehmigen kann, stehen in derselben Zeile.
- 02
Jede Prüfung hat ihren eigenen Schwellenwert.
Schwellenwerte, Pool-Ausschlüsse und Konto-Ausnahmen werden pro Prüfung festgelegt. So erzeugt die Disaster-Recovery-Umgebung keine Befunde mehr, ohne dass jemand die Prüfung deaktiviert, die alles andere schützt.
- 03
Die Zuordnung wartet nicht auf das Tagging.
Virtuelle Tags werden schon heute aus Konto, Region, Service, Namensmuster oder Verantwortlichem berechnet, während die Tagging-Richtlinie die echten Tags im Hintergrund nachzieht.
- 04
Die Bereinigung muss nicht wiederholt werden.
TTLs lassen die Sandbox ablaufen, Ausgabenlimits deckeln den Pool, die Anomalieerkennung erfasst den Ausschlag, und der Verstoßverlauf zeigt genau, was wann ausgelöst wurde.
- 05
Ihr Kostenmodell überdauert Ihren Anbieter.
FOCUS wird nativ eingelesen und ist direkt abfragbar, sodass das Kostenmodell ein offener Standard ist, der Ihnen gehört.
Häufig gestellte Fragen
Sie möchten eine andere Frage stellen?
Kontakt aufnehmenWir nutzen bereits die nativen Kostentools jeder Cloud. Was bringt das zusätzlich?
Native Tools sind innerhalb ihrer eigenen Grenzen hervorragend und außerhalb davon blind. Hier entsteht ein Kostenmodell über zwölf Cloud- und Datenplattformen, darunter Kubernetes, Databricks und Snowflake, mit einem Zuordnungsschema, einer Richtlinien-Engine und einem Satz an Empfehlungen. Zudem laufen die Prüfungen, die die Abrechnungskonsolen nicht durchführen: Snapshot-Ketten, verwaiste Streams, gestoppte, aber nicht freigegebene Instanzen, kurzlebige Spot-Kandidaten.
Unser Tagging ist ein Durcheinander. Müssen wir das zuerst in Ordnung bringen?
Nein. Virtuelles Tagging wird unabhängig von Cloud-nativen Tags berechnet, sodass die Zuordnung vom ersten Tag an über Konto, Region, Service, Namensmuster oder Verantwortliche funktioniert. Die Tag-Compliance-Richtlinie (Pflicht-Tags, verbotene Tags und Korrelationsregeln) bereinigt dann im Hintergrund das zugrunde liegende Durcheinander.
Wie verhindern wir, dass Entwickler das als Sparprogramm empfinden, das ihnen auferlegt wird?
Geben Sie ihnen den Pool und das Budget. Kostenpools sind typisiert als Budget, Geschäftsbereich, Team, Projekt, CI/CD oder Asset, jeweils mit eigenem Budget, eigenen Schwellenwerten und Slack-Benachrichtigungen. Gemeinsam nutzbare Umgebungen mit Buchung, SSH-Schlüsseln und CI/CD-Webhooks bedeuten: Dasselbe System, das ihnen die Kosten berechnet, stellt ihnen auch die Testumgebung bereit.
Deckt das Kubernetes wirklich ab oder nur die Nodes darunter?
Kosten und Auslastung werden nach Namespace, Node und Service aufgeschlüsselt, und Kubernetes-Rightsizing ist eine der sechsundzwanzig benannten Prüfungen, denn Cluster sind fast immer auf die deklarierten Requests ausgelegt, weit über dem, was die Pods je nutzen. Für einen Namespace gelten dieselben Pools, Budgets und Richtlinien wie für ein Abonnement.
Und die GPU-Ausgaben? Das ist unser am schnellsten wachsender Posten.
ML-Executors sind Cloud-Instanzen. Daher gelten Erkennung verwaister Ressourcen, Rightsizing, Generations-Upgrade und Spot-Migration automatisch auch für sie, und ML-/KI-Workloads können eigene Kostenpools und Budgets haben. Das ist CerteroX AI Management, auf derselben Engine.
Sehen Sie den Prüfungen bei der Arbeit zu.
Gehen Sie mit einer Liste von Namen.
Eine befüllte Cloud-Umgebung in realem Umfang, Befund für Befund durchgegangen: nach benannter Prüfung, nach Ressource, nach Verantwortlichen. Sagen Sie uns, welche Plattformen Sie betreiben und welche der sechsundzwanzig Prüfungen Sie anzweifeln würden.
Unverbindlich und ohne PDF hinter einem Formular. Alle sechsundzwanzig Prüfungen und jemand im Gespräch, der zu jeder einzelnen Rede und Antwort stehen kann.