Hallo zusammen, Jules Martin hier, zurück auf agntmax.com. Ich hoffe, es geht euch allen gut. Heute möchte ich über etwas sprechen, was mir in letzter Zeit zu schaffen macht, etwas, das in mehr Gesprächen und Projekt-Post-Mortems aufgetaucht ist, als ich zugeben möchte: die unsichtbaren Kosten für nicht optimierte Infrastruktur. Wir alle wissen, dass man schnell bauen, zügig skalieren und Funktionen gestern bereitstellen muss. Aber oft, in diesem Eifer, hinterlassen wir eine Spur von vergessenen Ressourcen, überdimensionierten Instanzen und Diensten, die im Leerlauf laufen und Rechnungen anhäufen, auf die wir kaum einen Blick werfen, bevor die vierteljährliche Budgetüberprüfung wie ein Schicksalsschlag zukommt.
Also, in diesem Artikel tauche ich kopfüber in die Kostenoptimierung ein, aber aus einer sehr spezifischen und zeitgerechten Perspektive: wie man aufhört, Geld für “immer eingeschaltete” Ressourcen zu verschwenden, die “nach Bedarf” oder “ereignisgesteuert” sein sollten. Es ist 2026, Leute. Die Zeiten, in denen Serversysteme auf Abruf bereitgestellt werden, sind vorbei. Wenn eure Cloud-Rechnung immer noch wie ein Telefonbuch aussieht, ist es Zeit, einzugreifen.
Der Stille Killer: Immer Eingeschaltet, Wenn Es Nach Bedarf Sein Sollte
Seien wir realistisch. Wenn wir unter Druck stehen, ein neues Tool für die Agenten oder eine Verbesserung des Kundenservice herauszubringen, tritt der Kostenfaktor oft hinter Funktionalität und Schnelligkeit zurück. Wir provisionieren eine EC2-Instanz, die “groß genug” ist, vielleicht sogar “ein bisschen größer, nur für den Fall.” Wir starten eine Datenbank mit bereitgestellten IOPS, die das gesamte Internet bewältigen könnte, nur damit sie während der Nebenzeiten hauptsächlich ungenutzt bleibt. Wir vergessen, geeignete Skalierungspolitiken einzurichten, oder wir lassen einfach alles 24/7 laufen, weil es, naja, einfacher ist, als sich darum zu kümmern.
Ich habe das mit eigenen Augen vor einigen Monaten gesehen, als ich das neue interne Analyse-Dashboard eines Kunden betrachtet habe. Das Team, gottlob, hatte ein fantastisches System aufgebaut, das Agenten Echtzeiteinblicke in die Interaktionen mit den Kunden gab. Das war ein großer Erfolg für die Leistung. Aber als die erste vollständige Cloud-Rechnung eintraf, wäre der Finanzdirektor fast in Ohnmacht gefallen. Sie hatten ein robustes EKS-Cluster, einige hochwertige RDS-Instanzen und eine Vielzahl von Lambda-Funktionen mit großzügigen Speicherzuweisungen bereitgestellt, die alle ununterbrochen liefen. Der Clou? Das Dashboard wurde hauptsächlich von den Agenten während der Bürozeiten, von 9 bis 17 Uhr, von Montag bis Freitag, genutzt. Außerhalb dieser Zeiten war es eine Geisterstadt.
Sie zahlten für Unternehmensniveau-Kapazitäten für ein System, das tatsächlich 70 % der Woche inaktiv war. Es ist, als würde man ein Formel-1-Auto kaufen, um einmal pro Woche zum Supermarkt zu fahren.
Identifiziert die Schuldigen: Wo Geht Euer Geld Wirklich Hin
Bevor ihr irgendetwas reparieren könnt, müsst ihr wissen, was kaputt ist. Die meisten Cloud-Anbieter bieten Tools an, um euch zu helfen, eure Ausgaben zu visualisieren, und ihr solltet diese unbedingt nutzen. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing Reports – das sind nicht nur etwas für die Finanzen. Sie sind eure erste Verteidigungslinie.
Die Gewöhnlichen Verdächtigen
- Berechnungsinstanzen (EC2, VMs): Das sind oft die größten Schuldigen. Sind sie überdimensioniert? Laufen sie, wenn sie es nicht sollten? Nutzt ihr die richtige Instanzfamilie für eure Arbeitslast?
- Datenbanken (RDS, Azure SQL, Cloud SQL): Wie beim Rechnen können auch Datenbanken für IOPS, CPU oder Speicher überprovisioniert sein. Viele bieten mittlerweile serverlose Optionen an, die auf null oder fast null heruntergefahren werden, wenn sie inaktiv sind.
- Speicher (EBS-Volumes, nicht angehängte Festplatten): Habt ihr jemals eine Instanz gestartet, sie beendet, aber das zugehörige Speichervolumen herumliegen lassen? Das passiert häufiger, als ihr denkt.
- Netzwerkkosten (Datenübertragung, NAT-Gateways): Die Kosten für die Datenübertragung können euch überraschen, insbesondere zwischen Regionen. NAT-Gateways haben ebenfalls Kosten pro Stunde, selbst wenn sie nichts tun.
- Untergenutzte Dienste: Zahlt ihr für einen dedizierten Redis-Cache, der nur ein paar Zugriffe pro Tag hat? Einen verwalteten Kafka-Cluster für einen Nachrichtenschwund?
Mein Kunde aus der Geschichte des Analyse-Dashboards begann damit, seinen AWS Cost Explorer zu überprüfen. Die größten Ausgabenposten waren, wie zu erwarten, EC2 und RDS. Sie fanden auch einige EBS-Volumes, die an beendete Instanzen angehängt waren, und ein NAT-Gateway in einer VPC, die nicht mehr für den Produktionsverkehr genutzt wurde. Kleinigkeiten, aber das summiert sich.
Strategien, Um Immer Eingeschaltet in Nach Bedarf (oder Niedriglast) Zu Verwandeln
Okay, ihr habt die Bereiche identifiziert, in denen ihr zu viel ausgebt. Kommen wir zum spaßigen Teil: das Reparieren. Das Ziel ist nicht nur, Geld zu sparen, sondern ein resistenteres und effizienteres System zu schaffen, das nur dann Ressourcen verbraucht, wenn es wirklich nötig ist.
1. Plant das Starten/Stoppen von Instanzen
Das ist wahrscheinlich die am leichtesten umzusetzende Maßnahme für viele Anwendungen. Wenn eure internen Tools oder Staging-Umgebungen nur während der Bürozeiten genutzt werden, gibt es keinen Grund, dass sie 24/7 laufen. Die meisten Cloud-Anbieter ermöglichen native Möglichkeiten zur Planung von Instanz-Energiezyklen, oder ihr könnt eure eigene Lösung mit serverlosen Funktionen erstellen.
Praktisches Beispiel: AWS EC2 Scheduler mit Lambda
Ihr könnt eine einfache Lambda-Funktion erstellen, die von CloudWatch-Ereignissen (CRON-Ausdrücke) ausgelöst wird, um EC2-Instanzen basierend auf Tags zu stoppen und zu starten. Hier ist eine vereinfachte Version des Lambda-Funktionscodes (Python):
import boto3
def lambda_handler(event, context):
ec2 = boto3.client('ec2')
# Definiert Tags, um die zu stoppenden/startenden Instanzen zu kennzeichnen
# Zum Beispiel, 'Schedule': 'business-hours'
# Holt alle laufenden Instanzen mit dem Tag 'Schedule', der auf 'business-hours' gesetzt ist
running_instances = ec2.describe_instances(
Filters=[
{'Name': 'instance-state-name', 'Values': ['running']},
{'Name': 'tag:Schedule', 'Values': ['business-hours']}
]
)
stop_instance_ids = []
for reservation in running_instances['Reservations']:
for instance in reservation['Instances']:
stop_instance_ids.append(instance['InstanceId'])
if stop_instance_ids:
print(f"Stoppen der Instanzen: {stop_instance_ids}")
ec2.stop_instances(InstanceIds=stop_instance_ids)
else:
print("Keine Instanz zum Stoppen.")
# --- Ähnliche Logik, um Instanzen zu einem anderen Zeitpunkt zu starten ---
# Ihr hättet ein weiteres Lambda/CloudWatch-Ereignis, um zu starten,
# oder kombiniert die Logik mit einem Tag 'start'.
return {
'statusCode': 200,
'body': 'Planung der EC2-Instanzen abgeschlossen.'
}
Ihr solltet zwei CloudWatch-Ereignisregeln einrichten: eine, um dieses Lambda beispielsweise um 18 Uhr UTC zum Stoppen der Instanzen auszulösen, und eine andere um 7 Uhr UTC, um sie zu starten. Das allein kann die Kosten für Berechnungen um mehr als 70 % für diese spezifischen Ressourcen senken.
2. Nutzt Serverlos und Container-Orchestrierung
Wenn eure Arbeitslast wirklich sporadisch oder ereignisgesteuert ist, ist serverlos euer bester Verbündeter. AWS Lambda, Azure Functions, Google Cloud Functions – sie sinken auf null, wenn sie nicht verwendet werden, was bedeutet, dass ihr nur für die Rechenleistung zahlt, wenn euer Code tatsächlich läuft. Das ist ein riesiger Wandel vom „immer eingeschaltet“-Paradigma.
Für komplexere Anwendungen, die weiterhin persistente Dienste benötigen, aber schwankende Nachfrage haben, sind Container-Orchestrierungsplattformen wie Kubernetes (EKS, AKS, GKE) in Kombination mit intelligenter Skalierung leistungsstark. Die Horizontal Pod Autoscalers (HPA) können die Größe eurer Anwendungs-Pods basierend auf der CPU-Auslastung oder benutzerdefinierten Metriken variieren. Die Cluster Autoscaler können sogar Knoten eures Clusters hinzufügen oder entfernen, während sich die Nachfrage ändert.
Mein Kunde hat Teile seines Analyse-Dashboards so umgestaltet, dass Lambda verwendet wird, um einige Berichte zu erzeugen, die nur ein paar Mal am Tag angefordert wurden. Anstelle einer dedizierten EC2-Instanz, die einen Cron-Job ausführt, wurde eine Lambda-Funktion durch ein S3-Ereignis (neue hochgeladene Dateien) oder eine API Gateway-Anfrage ausgelöst. Die Einsparungen waren sofort und erheblich.
3. Dimensioniert Richtig Eure Datenbanken Mit Serverlos oder Auto-Skalierung
Datenbanken sind oft problematisch, da die Persistenz von Daten entscheidend ist. Viele moderne Datenbanken bieten jedoch serverlose oder auto-scalierbare Optionen an, die vor einigen Jahren noch nicht weit verbreitet waren.
- AWS Aurora Serverless v2 : Das ist eine bedeutende Veränderung. Es passt die Kapazität je nach tatsächlicher Nutzung an, von Bruchteilen eines ACU (Aurora Capacity Unit) bis hin zu Hunderten, und Sie zahlen nur für das, was Sie verwenden. Es ist nicht mehr nötig, für eine Spitzenkapazität vorzusehen, während Sie die meiste Zeit in Basislast arbeiten.
- Azure SQL Database Serverless : Ähnlich wie Aurora Serverless passt es sich automatisch an die Rechenkapazität an und wird inaktive, wodurch erhebliche Einsparungen bei intermittierenden Arbeitslasten erzielt werden.
- DynamoDB On-Demand : Für NoSQL-Arbeitslasten bedeutet der On-Demand-Kapazitätsmodus von DynamoDB, dass Sie pro Abfrage zahlen, ohne Lese-/Schreibkapazitätseinheiten provisionieren zu müssen. Ideal für unvorhersehbare Verkehrsmuster.
Das Analytics-Dashboard verwendete ursprünglich eine große RDS PostgreSQL-Instanz mit provisionierten IOPS. Nach der Migration zu Aurora Serverless v2 sanken ihre Datenbankkosten um fast 60 %, einfach weil sie während der Nebensaison nicht mehr mit voller Kapazität lief.
4. Bereinigen Sie Nicht Angefügte Speicher und Snapshots
Das mag grundlegend erscheinen, ist aber eine ständige Quelle für Geldverschwendung. Wenn Sie eine EC2-Instanz beenden, wird ihr zugehöriges EBS-Volume nicht immer standardmäßig gelöscht, insbesondere wenn es sich um ein Nicht-Stamm-Volume handelte. Dasselbe gilt für die Snapshots – sie häufen sich schnell an und können teuer werden.
Praktisches Beispiel: Finden und Löschen von Nicht Angefügten EBS-Volumes (AWS CLI)
Sie können die AWS CLI verwenden, um nicht angefügte Volumes zu finden und zu löschen. Das ist eine übliche Reinigungsaufgabe.
# Alle nicht angefügten Volumes auflisten
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,CreateTime]' --output table
# Um ein bestimmtes Volume zu löschen (VORSICHT, DAS IST IRREVERSIBEL)
# Ersetzen Sie 'vol-xxxxxxxxxxxxxxxxx' durch die tatsächliche Volume-ID
# aws ec2 delete-volume --volume-id vol-xxxxxxxxxxxxxxxxx
Automatisieren Sie dies mit einer geplanten Lambda-Funktion, wenn Sie häufig Umgebungen erstellen und löschen. Der Kunde entdeckte mehrere Terabyte alter nicht angefügter EBS-Volumes und Hunderte veralteter Snapshots. Das Löschen sparte einige Hundert Dollar auf ihrer monatlichen Rechnung – nicht riesig, aber jede kleine Geste zählt.
5. Netzwerkkosten Optimieren
Die NAT-Gateways sind fantastisch, um Instanzen in privaten Subnetzen den Zugriff auf das Internet zu ermöglichen, verursachen jedoch stündliche Gebühren und Datenverarbeitungsgebühren. Wenn Sie mehrere NAT-Gateways in verschiedenen Verfügbarkeitszonen haben, aber nur eines aktiv genutzt wird, zahlen Sie für Redundanzen.
- Konsolidieren Sie die NAT-Gateways : Wenn Ihre Architektur es erlaubt, konsolidieren Sie auf weniger NAT-Gateways.
- VPC-Endpunkte : Um auf AWS-Dienste wie S3 oder DynamoDB von Ihrem VPC aus zuzugreifen, verwenden Sie VPC-Endpunkte. Der Datenverkehr verläuft privat innerhalb des AWS-Netzwerks, was die Kosten der NAT-Gateways vermeidet und eine bessere Sicherheit bietet.
Wir haben festgestellt, dass der Kunde ein NAT-Gateway in jeder AZ hatte, obwohl seine Hauptanwendung nur in zweien lief. Sie konnten konsolidieren und dadurch Einsparungen erzielen und implementierten dann anschließend VPC-Endpunkte für den Zugriff auf S3, was die Datenverarbeitungskosten über das NAT-Gateway senkte.
Maßnahmen für Ihren nächsten Sprint
Es geht nicht nur darum, die Kosten zu senken; es geht darum, intelligentere und effizientere Systeme zu bauen, die intrinsisch kostenbewusst sind. Hier sind einige Dinge, die Sie noch heute beginnen können:
- Überprüfen Sie regelmäßig Ihre Cloud-Rechnung : Machen Sie es sich zur Gewohnheit. Verwenden Sie die Kostenmanagement-Tools Ihres Cloud-Anbieters. Überlassen Sie es nicht nur den Finanzen. Verstehen Sie, wohin jeder Dollar fließt.
- Taggen Sie alles : Dies ist nicht verhandelbar. Taggen Sie die Ressourcen nach Projekt, Eigentümer, Umgebung (Entwicklung, Staging, Produktion) und ob sie für das Herunterfahren geplant werden können. Dadurch wird die Identifizierung und Automatisierung erheblich erleichtert.
- Priorisieren Sie das Planen für nicht-produktive Umgebungen : Staging-, Entwicklungs- und QA-Umgebungen sind ideale Kandidaten für geplante Abschaltungen außerhalb der Bürozeiten. Das ist normalerweise die einfachste und schnellste Einsparung.
- Bewerten Sie Serverless für neue Arbeitslasten : Wenn Sie etwas Neues erstellen, insbesondere ereignisbasierte Mikrodienste oder Hintergrundaufgaben, ziehen Sie immer erst Serverless in Betracht.
- Bewerten Sie Ihre Datenbankwahl neu : Wenn Sie Datenbanken haben, die rund um die Uhr mit sehr variablen Arbeitslasten laufen, prüfen Sie serverless oder auto-scaling Optionen für Ihre spezifische Datenbanktechnologie.
- Automatisieren Sie die Bereinigung : Implementieren Sie automatisierte Skripte oder serverless Funktionen, um unangebundene Speicher-Volumes, alte Snapshots und andere verwaiste Ressourcen zu identifizieren und zu löschen.
- Bildung für Ihr Team : Fördern Sie eine Kultur des Kostenbewusstseins. Stellen Sie sicher, dass die Entwickler die finanziellen Auswirkungen ihrer Provisionsentscheidungen verstehen. Es ist nicht mehr nur ein Betriebsproblem.
Das Stoppen von Verlusten durch „ständig aktive“ Ressourcen ist keine einmalige Lösung; es ist eine fortlaufende Disziplin. Aber durch die Umsetzung dieser Veränderungen sparen Sie nicht nur eine beträchtliche Menge Geld für Ihr Unternehmen, sondern bauen auch eine agilere, widerstandsfähigere und zukunftsfähige Infrastruktur auf. Und ganz ehrlich, das macht Sie zu einem besseren Akteur im Technologiebereich.
Das war’s für mich diesmal. Machen Sie weiter, klug zu bauen, und ich sehe Sie beim nächsten Mal!
🕒 Published: