7 versteckte Warnsignale in Ihrer Cloud-Rechnung, die auf Anti-Patterns oder zu hohe Ausgaben hindeuten – und wie Sie gegensteuern können.
Wer Cloud-Kosten optimieren will, muss seine Cloud-Rechnung manchmal zwischen den Zeilen lesen.
Meist richtet sich der Blick auf die offensichtlichen Kostenausreißer – doch was ist mit den leiseren, weniger auffälligen Signalen, die sich hinter den Zahlen verbergen?
In einer aktuellen Folge unseres Cloud Masters-Podcasts haben wir drei Technical Account Manager (TAMs) von DoiT zusammengebracht. Sie zeigen sieben versteckte Warnsignale in Cloud-Rechnungen, die ihnen bei Kunden immer wieder begegnen – und erklären, was Sie stattdessen tun sollten.
Es geht hier nicht um die typischen, ins Auge springenden Kostenspitzen, sondern um dezente Hinweise darauf, dass etwas im Argen liegen könnte – etwa überhöhte Ausgaben oder ineffiziente Praktiken.
Hören Sie sich die ganze Folge unten an oder scrollen Sie weiter: Wir nehmen die Warnsignale unter die Lupe und geben Ihnen zu jedem konkrete Tipps an die Hand.
Warnsignal #1: Sie zahlen für AWS CloudTrail
Wenn Sie überhaupt für CloudTrail bezahlen, lässt sich Ihre Cloud-Rechnung mit hoher Wahrscheinlichkeit reduzieren. Der erste CloudTrail-Trail in einer Region ist kostenlos, und Ihr einziger Trail sollte auf Ebene der AWS Organization angelegt sein – denn Organization Trails werden automatisch in allen Mitgliedskonten der Organization erstellt.
Wichtig: Der neue Trail wird zusätzlich zu allen bereits in den Mitgliedskonten vorhandenen Trails angelegt. Wenn Sie also früher separate Trails in einzelnen Mitgliedskonten erstellt haben, sparen Sie bares Geld, indem Sie diese entfernen.
Legen Sie Ihren CloudTrail-Trail auf Organization-Ebene an, lässt sich Ihre Event-Logging-Strategie einheitlich über alle Konten Ihrer Organisation hinweg anwenden und durchsetzen, denn die Konfiguration des Organization Trails greift in allen Konten. Prüfen Sie deshalb, ob die Konfiguration Ihres Organization Trails auch tatsächlich der gewünschten Konfiguration für alle untergeordneten Konten entspricht.
Warnsignal #2: Speicherkosten steigen stetig, weil Data-Lifecycle-Policies fehlen
Steigen Ihre Cloud-Speicherkosten kontinuierlich, ist das oft ein Hinweis darauf, dass passende Object-Lifecycle-Policies fehlen.
Object-Lifecycle-Policies automatisieren das Verschieben von Daten in andere Speicherklassen oder das Löschen von Daten anhand vordefinierter Regeln. So passen sich die Speicherkosten an Wert und Zugriffshäufigkeit der Daten an. Sie zahlen dann nicht mehr drauf für Daten, auf die niemand sofort zugreifen muss oder die längst überholt sind.
Ohne Lifecycle-Policies sammeln sich Daten an, der Log-Speicher wuchert und es entstehen überflüssige Snapshots. Die Speicherkosten klettern – vor allem dann, wenn ältere oder selten genutzte Daten in teuren Speicherklassen liegen bleiben.
In den meisten Fällen genügt es, Objekte nach 30–90 Tagen umzuziehen oder ablaufen zu lassen. Steigende Kosten sind das deutlichste Signal, dass sich ein genauerer Blick auf den Speicher lohnt.
Warnsignal #3: Hohe GetMetricData-API-Kosten in CloudWatch
Drittanbieterdienste wie New Relic und Datadog scannen Ihre Cloud-Konten – meist die CloudWatch-Metriken – regelmäßig, um aktuelle Nutzungsdaten zu erhalten.
Vielen ist aber nicht bewusst, dass auch die API-Anfragen dieser Dienste kostenpflichtig sind. Sie tauchen in CloudWatch unter der API-SKU "GetMetricData" auf. Wer hier nicht aufpasst, zahlt am Ende eine erhebliche Summe für CloudWatch – allein wegen der GetMetricData-Aufrufe der Drittanbieter.
Behalten Sie deshalb im Blick:
- wie häufig diese API-Aufrufe erfolgen und
- welche Metriken und Daten dabei abgefragt werden.
Beispiel: Sie haben ein Dev-Konto mit vielen Ressourcen, für das hohe CloudWatch-Kosten anfallen, weil im Minutentakt API-Aufrufe erfolgen. Fragen Sie sich in solchen Fällen, ob diese Frequenz – und vielleicht auch die Granularität der Daten – wirklich nötig ist.
Häufig reicht es schon, die Drittanbieter zu bitten, Frequenz und abgefragte Metriken für bestimmte Konten oder Projekte anzupassen, um die CloudWatch-Kosten spürbar zu senken.
Warnsignal #4: Logging-Kosten machen >20 % Ihrer Cloud-Rechnung aus
Logging ist für Monitoring und Troubleshooting unverzichtbar – exzessives Logging treibt Ihre Cloud-Rechnung jedoch in die Höhe.
Ähnlich wie beim vorherigen Warnsignal zu API-Aufrufen sollten Sie sich fragen, ob Frequenz und erfasste Metriken Ihres Loggings wirklich zum Anwendungsfall passen. Wenn Sie etwa ein Dashboard mit Daten aus Logs versorgen, brauchen Sie kaum sekündliche Updates – ein Update alle fünf Minuten reicht oft völlig.
Als Faustregel gilt: Mehr als 20 % Ihrer Cloud-Rechnung sollten nicht aufs Logging entfallen. Liegen Sie darüber, ist das ein klares Signal, sich anzusehen, woraus sich diese Kosten zusammensetzen. Fragen Sie die Teams, die Ihre Logs nutzen, wofür sie diese brauchen – so finden Sie schnell heraus, wo sich Frequenz oder erfasste Metriken zurückschrauben lassen.
Werfen Sie außerdem unbedingt einen genauen Blick auf das Logging in Nicht-Produktionsumgebungen, denn diese erwirtschaften ja keine Einnahmen. Dort sind Frequenz und Metriken in der Regel nicht so umfassend nötig wie in Produktionskonten. Falls in Nicht-Produktionsumgebungen etwas kaputtgeht, lassen sich Logs einfach an- und ausschalten – anders als in der Produktion, wo Sie mehr Informationen zur Ursache brauchen.
Warnsignal #5: Entscheidungen werden nicht abgestimmt
Dieses Warnsignal lässt sich zwar nicht direkt aus Ihrer Rechnung oder einem Cost-and-Usage-Report ablesen. Doch wenn Sie Technologie- und Designentscheidungen ohne Rücksprache treffen, schlägt sich das später in Kopfschmerzen bei der Cloud-Rechnung und in Performance-Problemen nieder.
Ein sehr häufiges Beispiel: Ein Team kauft im Alleingang einen Commitment-Rabatt (z. B. einen Savings Plan), ohne die übergeordnete Strategie der Organisation oder die Anforderungen anderer Teams zu berücksichtigen. Die Tech-Abteilung will vielleicht in den nächsten zwei Jahren auf Serverless umsteigen – doch plötzlich kauft jemand einen 3-Jahres-Savings-Plan und legt das Unternehmen damit auf VMs fest.
In der Cloud gibt es keine "objektiv richtige" Entscheidung. Cloud-Entscheidungen im Alleingang führen zu Ineffizienzen und höheren Kosten. Fragen Sie sich, wie Sie sich intern mit Kolleg:innen oder anderen Teams abstimmen, um die Tragfähigkeit Ihrer Entscheidungen abzusichern. Ganz konkret kann das heißen, dass Sie Cloud-Infrastrukturentscheidungen mit der Engineering-Strategie und -Vision oder mit den relevanten RFC-/ADR-Dokumenten abgleichen.
Warnsignal #6: Sie schränken Regionen und Instance-Typen nicht über Organizational Policies ein
Mit Organizational Policies (siehe Dokumentation für Google Cloud und AWS) legen Sie fest, wie Ihre Cloud-Nutzer auf die Cloud-Ressourcen Ihres Unternehmens zugreifen, sie nutzen und verwalten dürfen.
Aus Sicht der Kostenoptimierung (und der Sicherheit) sind sie besonders wertvoll, um zu verhindern, dass jemand Dienste dort hochfährt, wo das nicht vorgesehen ist.
Konkret: Ohne Organizational Policies, die Instance-Typen und Regionen einschränken, setzen Sie Ihre Cloud-Infrastruktur Sicherheitslücken und überhöhten Ausgaben aus. Angreifer können diese fehlende Kontrolle ausnutzen, um Instances in ungenutzten Regionen zu deployen, der Erkennung zu entgehen und ihre Aktivitäten unbemerkt durchzuführen.
Beschränken Sie Instance-Typen und Regionen auf das, was Sie tatsächlich nutzen. So kann niemand – ob absichtlich oder versehentlich – etwa eine x1-Instance statt einer t4 in Südamerika hochfahren, obwohl alle Ihre Ressourcen in Europa liegen.
Mit Org Policies schützen Sie Ihre Cloud-Umgebung wirksam und holen mehr aus Ihren Ressourcen heraus.
Warnsignal #7: Übermäßige API-Aufrufe an Storage-Buckets
Häufige und unnötige API-Aufrufe an Storage-Buckets treiben die Speicherkosten in die Höhe und drücken die Performance. Dieses Warnsignal zeigt sich in ganz unterschiedlichen Konstellationen.
Ihre Anwendung(en) könnten häufig API-Aufrufe an Cloud-Storage-Buckets absetzen. Besonders problematisch ist das bei Anwendungen, die große Datenmengen erzeugen oder häufig Daten übertragen. Oder es ist ein geplanter Prozess, der mit Ihren Storage-Buckets interagiert und mit der Zeit eine erhebliche Menge an API-Aufrufen ansammelt.
Neben den Kosten sollten Sie bedenken: Häufige API-Aufrufe beeinträchtigen auch die Performance Ihrer Anwendung und können zu Verlangsamungen, Timeouts oder sogar Systemausfällen führen.
Ohne ein angemessenes Monitoring geben Sie schnell zu viel aus, ohne dass Alarmglocken läuten – bis die Rechnung kommt oder ein Service-Quota-Limit erreicht wird.
Prüfen und optimieren Sie deshalb Ihren Anwendungscode so, dass möglichst wenige API-Aufrufe pro Operation nötig sind. Setzen Sie zusätzlich Caching-Mechanismen ein, um häufig genutzte Daten im Speicher vorzuhalten und wiederholte API-Aufrufe an die Storage-Buckets zu vermeiden.
Die richtigen Fragen an Ihre Cloud-Rechnung stellen
Wir können Ihnen zwar eine Liste mit Warnsignalen an die Hand geben – die Liste der zu prüfenden Punkte ist jedoch endlos. Genau deshalb ist es langfristig entscheidend, neugierig auf Ihre Cloud-Ausgaben zu bleiben. Akzeptieren Sie nicht einfach, dass Ihre Rechnung in dieser Höhe ausfällt. Fragen Sie nach dem Warum – und dann noch einmal.
Steigen zum Beispiel die S3-Kosten, fragen Sie nach, welche/r Bucket(s) den Anstieg treiben. Dann fragen Sie, welche SKUs für den Kostenanstieg in den Buckets verantwortlich sind. Stellt sich heraus, dass es sich um Datenübertragungskosten handelt, fragen Sie sich und Ihr Team, ob dieser Anstieg für die betreffenden Buckets erwartet wurde. Vielleicht sind die Kosten aus gutem Grund gestiegen – das wissen Sie aber erst, wenn Sie nachfragen.
So entsteht mit der Zeit eine Kultur der Kostenoptimierung in Ihrem Unternehmen, in der allen bewusst ist, welchen Beitrag sie zur Cloud-Rechnung leisten – und in der sie die Befugnis spüren, etwas zu ändern.
Jedes dieser Warnsignale unterstreicht, wie wichtig geteilte Verantwortung und ein neugieriger Blick auf die Cloud-Rechnung sind. Und denken Sie daran: Optimierungspotenziale aufzudecken, darf nicht allein auf den Schultern des Head of Infrastructure oder FinOps Lead liegen. Es ist eine Reise, die von Teamarbeit lebt.