Cloud-Kosten wachsen leise. Erst fällt es niemandem auf, dann ist die Rechnung ein Tagesordnungspunkt. Ich finde die Stellen an denen Ihr Budget versickert, beziffere jede Maßnahme mit Aufwand und Risiko und setze sie um. Was nicht messbar spart, mache ich nicht.
Die Analyse ist ein abgeschlossenes Ein- bis Zwei-Wochen-Mandat mit Bericht. Die Umsetzung danach nach Aufwand oder für klar abgegrenzte Pakete zum Festpreis.
Remote aus Deutschland. Direkt mit mir, ohne Agentur dazwischen.
AWS macht es leicht Ressourcen anzulegen und schwer sie wiederzufinden. Ein Proof of Concept von vor zwei Jahren läuft noch. Eine Staging-Umgebung läuft nachts und am Wochenende durch. Ein Datenbank-Cluster wurde für einen Peak dimensioniert der nie kam.
Das Unangenehme daran: Kosten sind ein Architektur-Symptom. Wer nur Instanzgrößen anpasst spart einmalig. Wer versteht warum eine Architektur teuer ist spart dauerhaft. Cross-AZ-Traffic, NAT-Gateway-Durchsatz, ungebremste Log-Ingestion. Die teuersten Posten stehen selten dort wo man sie vermutet.
Typische SymptomeIch arbeite mit dem Cost & Usage Report, nicht mit der Übersichtsseite der Konsole. Kosten werden nach Service, Umgebung, Team und Workload aufgeschlüsselt. Am Ende wissen Sie welcher Euro wofür ausgegeben wird. Das ist die Voraussetzung für jede weitere Entscheidung.
Compute und Datenbanken auf die tatsächliche Last anpassen statt auf die Last die vor drei Jahren erwartet wurde. Nicht-produktive Umgebungen laufen nur wenn jemand sie braucht. Unspektakulär und meistens der schnellste zweistellige Prozentsatz.
Savings Plans und Reserved Instances sind ein Hebel und eine Falle. Ich rechne auf Basis Ihres tatsächlichen Baseline-Verbrauchs, empfehle Laufzeit und Abdeckungsgrad bewusst konservativ und richte eine Überwachung ein die vor dem Auslaufen warnt.
S3-Lifecycle-Regeln, Intelligent-Tiering, Aufräumen verwaister Snapshots und EBS-Volumes. Dazu die unsichtbaren Posten: Cross-AZ-Traffic, NAT-Gateways, Log-Retention. Hier liegt das Geld das in keiner Instanzliste auftaucht.
Ein Tagging-Konzept das in Terraform erzwungen wird, Budgets mit Alarmen pro Team und ein monatlicher Report der auch ohne mich funktioniert. Kostenoptimierung ist keine Aktion, sondern eine Gewohnheit.
Jede Maßnahme bekommt eine Zahl, vorher und nachher. Was sich nicht messen lässt, wird nicht empfohlen.
Monatliche Rechnung, Aufbau der Accounts, größte Schmerzpunkte. Danach wissen Sie, ob sich eine Analyse lohnt.
Auswertung von CUR und Nutzungsdaten. Ergebnis: Maßnahmenliste mit Potenzial, Aufwand und Risiko je Position.
Alles ohne Architekturänderung wird zuerst umgesetzt: Rightsizing, Scheduling, Storage-Lifecycle, Commitments.
Danach die Posten, die einen Eingriff in die Architektur brauchen, jeweils mit vorheriger Rechnung, ob er sich lohnt.
Jede Position lässt sich einem Team, einer Umgebung und einem Workload zuordnen. Diskussionen über Kosten werden zu Diskussionen über Prioritäten.
Quick Wins zuerst, Architekturänderungen danach. Jede Maßnahme mit gemessenem Vorher-Nachher statt geschätztem Potenzial.
Budget-Alarme und Anomalie-Erkennung melden Abweichungen wenn sie entstehen, nicht am fünften des Folgemonats.
Das hängt vom Reifegrad ab. Bei Setups die noch nie systematisch geprüft wurden liegen zweistellige Prozentsätze meist ohne Architekturänderung drin. Rightsizing, abgeschaltete Nicht-Produktivumgebungen, Storage-Lifecycle, passende Commitments. Eine belastbare Zahl nenne ich nach der Analyse auf Basis Ihrer Daten, nicht auf Basis eines Branchendurchschnitts.
Nein, das ist die Bedingung. Jede Maßnahme wird gegen Lastprofil und Latenzbudget geprüft, Änderungen an produktivem Compute laufen über Staging und werden nach dem Rollout gemessen. Wo eine Einsparung Verfügbarkeit oder Latenz kosten würde, wird sie nicht empfohlen, sondern als bewusste Entscheidung mit Zahlen vorgelegt.
Für einen typischen Account-Verbund ein bis zwei Wochen bis zur priorisierten Maßnahmenliste. Erste Quick Wins lassen sich oft schon während der Analyse umsetzen, weil sie weder Architekturänderung noch Deployment brauchen.
Für den Einstieg nicht. Der Cost & Usage Report plus Athena liefert alles was für eine belastbare Analyse nötig ist. Ein Tool lohnt sich, wenn viele Teams dauerhaft eigene Kostenverantwortung tragen sollen. Das ist eine Folgeentscheidung, kein Startpunkt.
Auf Wunsch als kleines wiederkehrendes Mandat: monatlicher Report, Prüfung von Anomalien und Commitments. Der Regelfall ist aber, dass ich Governance und Reporting so aufsetze, dass Ihr Team es ohne mich weiterführt.
Die Infrastruktur hinter produktiven KI-Systemen: MCP-Server, sichere Tool-Anbindung, LLM-Integration mit Zugriffsschutz und Kostenkontrolle.
Mehr erfahrenManuelle Abläufe durch echte Systeme ersetzen: angebunden an Ihre Bestandssysteme, mit Berechtigungen und Protokoll statt Tool-Kette.
Mehr erfahrenVom eigenen Rechenzentrum oder aus einer anderen Cloud nach AWS, mit Kostenmodell vor dem Umzug und Rollback-Pfad für jeden Schritt.
Mehr erfahrenGewachsene Systeme schrittweise modernisieren: Strangler-Fig statt Rewrite, laufender Betrieb unangetastet, jeder Schritt umkehrbar.
Mehr erfahrenBackends für SaaS und Plattformen, die unter echter Last halten: in Go und PHP 8, event-getrieben, mit Mandantentrennung und Wiederanlauf im Entwurf.
Mehr erfahren