Hallo zusammen, Jules Martin hier, zurück auf agntmax.com. Ich hoffe, es geht euch allen gut. Heute möchte ich über etwas sprechen, das mich in letzter Zeit beschäftigt, etwas, das ich in mehr Gesprächen und Projekt-Post-Mortems gesehen habe, als ich zugeben möchte: die unsichtbaren Kosten von nicht optimierten Infrastrukturressourcen. Wir wissen alle, dass wir schnell aufbauen, schnell skalieren und Funktionen von gestern bereitstellen müssen. Aber oft lassen wir in dieser Eile eine Spur von vergessenen Ressourcen, überdimensionierten Instanzen und im Standby-Modus laufenden Diensten zurück, die Rechnungen anhäufen, die wir kaum einen Blick darauf werfen, bevor die quartalsweise Budgetüberprüfung wie ein Schaufel voller Ziegelsteine niederprallt.
Für diesen Artikel gehe ich ganz tief in die Kostenoptimierung, jedoch mit einem sehr spezifischen und zeitgemäßen Fokus: Wie wir aufhören können, Geld für “immer laufende” Ressourcen auszugeben, die “on-demand” oder “ereignisgesteuert” sein sollten. Es ist das Jahr 2026, Leute. Die Tage, an denen man Server nach Belieben bereitstellt, sind vorbei. Wenn eure Cloud-Rechnung aussieht wie ein Telefonbuch, ist es Zeit, einzugreifen.
Der stille Killer: Immer eingeschaltet, wenn es on-demand sein sollte
Seien wir realistisch. Wenn wir unter Druck stehen, ein neues Tool für Agenten oder eine Verbesserung des Kundenservices herauszubringen, geraten die Kosten oft in den Hintergrund im Vergleich zu Funktionalität und Schnelligkeit. 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 provisionierten IOPS, die den gesamten Internetverkehr bewältigen könnte, nur damit sie während der Nebenzeiten größtenteils ungenutzt bleibt. Wir vergessen, angemessene Skalierungsrichtlinien zu konfigurieren, oder wir lassen die Dinge einfach 24/7 laufen, weil es, nun ja, einfacher ist, als sich darum zu kümmern.
Ich habe das vor einigen Monaten mit dem neuen internen Analyse-Dashboard eines Kunden gesehen. Das Team, Gott segne sie, hatte ein fantastisches System aufgebaut, das den Agenten Echtzeit-Einblicke in die Interaktionen mit den Kunden gab. Es war ein riesiger Gewinn für die Performance. Aber als die erste vollständige Cloud-Rechnung ankam, wäre der Finanzdirektor fast in Ohnmacht gefallen. Sie hatten ein robustes EKS-Cluster, einige High-End-RDS-Instanzen und eine Vielzahl von Lambda-Funktionen mit großzügigen Speicherzuweisungen provisioniert, die alle durchgehend liefen. Der Clou? Das Dashboard wurde hauptsächlich von den Agenten während der Bürozeiten verwendet, von 9 bis 17 Uhr, von Montag bis Freitag. Draußen war es eine Geisterstadt.
Sie zahlten für eine Unternehmenskapazität für ein System, das 70 % der Woche tatsächlich inaktiv war. Es ist wie der Kauf eines Formel-1-Autos, um einmal pro Woche zum Supermarkt zu fahren.
Identifiziert die Schuldigen: Wohin fließt euer Geld wirklich
Bevor ihr irgendetwas reparieren könnt, müsst ihr wissen, was kaputt ist. Die meisten Cloud-Anbieter bieten Tools an, mit denen ihr eure Ausgaben visualisieren könnt, und ihr solltet sie unbedingt nutzen. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing-Berichte – das sind nicht nur Finanztools. Sie sind eure erste Verteidigungslinie.
Die üblichen Verdächtigen
- Recheninstanzen (EC2, VMs): Diese sind oft die größten Übeltäter. Sind sie überdimensioniert? Laufen sie, wenn sie das nicht sollten? Verwendet ihr die richtige Instanzfamilie für eure Workload?
- 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 nahezu Null sinken, wenn sie inaktiv sind.
- Speicher (EBS-Volumes, nicht angeschlossene Festplatten): Habt ihr jemals eine Instanz gestartet, diese beendet, aber das zugehörige Speicher-Volume herumliegen lassen? Das passiert häufiger, als ihr denkt.
- Netzwerk (Datentransfer, NAT Gateways): Die Kosten für Datentransfer können euch überraschen, besonders 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 einige Zugriffe pro Tag hat? Ein verwaltetes Kafka-Cluster für eine Nachrichtenschlange?
Mein Kunde aus der Geschichte des Analyse-Dashboards begann mit der Überprüfung seines AWS Cost Explorer. Die größten Ausgabenposten waren erwartungsgemäß 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 Produktionsverkehr verwendet wurde. Kleine Dinge, aber es summiert sich.
Strategien zur Umwandlung von Immer-Beleuchtet in On-Demand (oder außerhalb der Spitzenzeiten)
Okay, ihr habt die Bereiche identifiziert, in denen ihr zu viel ausgebt. Kommen wir zum Spaßteil: das Reparieren. Das Ziel ist nicht nur, Geld zu sparen, sondern ein widerstandsfähigeres und effizienteres System zu bauen, das Ressourcen nur dann verbraucht, wenn es wirklich nötig ist.
1. Planung des Startens/Stoppen von Instanzen
Das ist wahrscheinlich die einfachste Möglichkeit 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 bieten native Möglichkeiten, um Stromzyklen für Instanzen zu planen, oder ihr könnt eure eigene Lösung mit serverlosen Funktionen erstellen.
Praxisbeispiel: AWS EC2 Scheduler mit Lambda
Ihr könnt eine einfache Lambda-Funktion erstellen, die durch CloudWatch-Ereignisse (CRON-Ausdrücke) ausgelöst wird, um EC2-Instanzen basierend auf Tags zu stoppen und zu starten. Hier ist eine vereinfachte Version des Codes der Lambda-Funktion (Python):
import boto3
def lambda_handler(event, context):
ec2 = boto3.client('ec2')
# Tags festlegen, um die Instanzen zum Stoppen/Starten zu identifizieren
# Zum Beispiel, 'Schedule': 'business-hours'
# Alle laufenden Instanzen mit dem Tag 'Schedule' auf 'business-hours' abrufen
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"Stoppe die Instanzen: {stop_instance_ids}")
ec2.stop_instances(InstanceIds=stop_instance_ids)
else:
print("Keine Instanz zum Stoppen.")
# --- Ähnliche Logik zum Starten der Instanzen zu einem anderen Zeitpunkt ---
# Ihr hättet eine andere Lambda/CloudWatch-Ereignis zum Starten,
# oder die Logik mit einem Tag 'start' kombinieren.
return {
'statusCode': 200,
'body': 'Planung der EC2-Instanzen abgeschlossen.'
}
Ihr solltet zwei CloudWatch-Ereignisregeln einrichten: eine, um diese Lambda, sagen wir, 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 Rechenkosten für diese spezifischen Ressourcen um über 70 % senken.
2. Nutzt Serverless und Containerorchestrierung
Wenn eure Workload wirklich sporadisch oder ereignisgesteuert ist, ist serverless euer bester Ally. AWS Lambda, Azure Functions, Google Cloud Functions – sie gehen auf Null, wenn sie nicht verwendet werden, was bedeutet, dass ihr nur für die Rechenleistung zahlt, wenn euer Code tatsächlich ausgeführt wird. Das ist ein riesiger Wandel im Vergleich zum “immer eingeschaltet”-Paradigma.
Für komplexere Anwendungen, die immer noch persistente Dienste benötigen, aber eine schwankende Nachfrage haben, sind Containerorchestrierungsplattformen wie Kubernetes (EKS, AKS, GKE), kombiniert mit intelligenter Skalierung, mächtig. Horizontal Pod Autoscalers (HPA) können die Größe eurer Anwendungspods basierend auf der CPU-Auslastung oder benutzerdefinierten Metriken variieren. Cluster Autoscalers können sogar Knoten zu eurem Cluster hinzufügen oder daraus entfernen, je nach Nachfrage.
Mein Kunde hat Teile seines Analyse-Dashboards umgebaut, um Lambda zur Erzeugung bestimmter Berichte zu verwenden, 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 eure Datenbanken richtig mit Serverless oder Auto-Scaling
Datenbanken sind oft problematisch, weil die Persistenz von Daten kritisch ist. Viele moderne Datenbanken bieten jedoch serverlose oder Auto-Scaling-Optionen an, die vor einigen Jahren nicht weit verbreitet waren.
- AWS Aurora Serverless v2 : Das ist eine erhebliche Änderung. Es passt die Kapazität basierend auf der tatsächlichen Nutzung an, von Bruchteilen einer ACU (Aurora Capacity Unit) bis hin zu Hunderten, und Sie zahlen nur für das, was Sie nutzen. Kein Bedarf mehr, Spitzenkapazitäten bereitzustellen, während Sie die meiste Zeit mit Basislast arbeiten.
- Azure SQL Database Serverless : Ähnlich wie Aurora Serverless passt es sich automatisch an die Rechenleistung an und pausiert, wenn es inaktiv ist, was erhebliche Einsparungen für intermittierende Arbeitslasten ermöglicht.
- DynamoDB On-Demand : Für NoSQL-Arbeitslasten bedeutet der On-Demand-Kapazitätsmodus von DynamoDB, dass Sie pro Anfrage bezahlen, ohne Lese-/Schreibkapazitätseinheiten bereitstellen zu müssen. Perfekt für unvorhersehbare Verkehrsmuster.
Das Analytics-Dashboard verwendete ursprünglich eine große RDS PostgreSQL-Instanz mit bereitgestellten IOPS. Nach der Migration zu Aurora Serverless v2 sind ihre Datenbankkosten um fast 60 % gesunken, einfach weil es während der Nebensaison nicht mehr auf Volldampf lief.
4. Bereinigen Sie Unbenutzte 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-Root-Volume handelt. Das Gleiche gilt für Snapshots – sie häufen sich schnell an und können teuer werden.
Praktisches Beispiel: Finden und Löschen von Unbenutzten EBS-Volumes (AWS CLI)
Sie können die AWS CLI verwenden, um unbenutzte Volumes zu finden und zu löschen. Es ist eine gängige Reinigungsaufgabe.
# Alle unbenutzten Volumes auflisten
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,CreateTime]' --output table
# Um ein spezifisches Volume zu löschen (SEHR VORSICHTIG, 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 geplannten Lambda-Funktion, wenn Sie häufig Umgebungen erstellen und löschen. Der Kunde entdeckte mehrere Terabyte an alten unbenutzten EBS-Volumes und Hunderte von veralteten Snapshots. Das Löschen hat einige Hundert Dollar auf ihrer monatlichen Rechnung gespart – das ist zwar nicht riesig, aber jede kleine Geste zählt.
5. Netzwerk Kosten Optimieren
NAT Gateways sind fantastisch, um Instanzen in privaten Subnetzen den Zugriff auf das Internet zu ermöglichen, aber sie verursachen 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 redundante Gateways.
- Konsolidieren Sie NAT Gateways : Wenn Ihre Architektur es zulässt, konsolidieren Sie auf weniger NAT Gateways.
- VPC Endpunkte : Um auf AWS-Dienste wie S3 oder DynamoDB von Ihrem VPC aus zuzugreifen, nutzen Sie VPC Endpunkte. Der Verkehr verläuft privat innerhalb des AWS-Netzwerks, vermeidet die Kosten der NAT Gateways und bietet eine bessere Sicherheit.
Wir stellten fest, dass der Kunde ein NAT Gateway in jeder AZ hatte, obwohl seine Hauptanwendung nur in zweien funktionierte. Sie konnten konsolidieren und darüber Einsparungen erzielen und implementierten dann VPC Endpunkte für den Zugriff auf S3, was die Datenverarbeitungskosten über das NAT Gateway reduzierte.
Maßnahmen für Ihren nächsten Sprint
Es geht nicht nur darum, 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. Nutzen Sie die Kostenmanagement-Tools Ihres Cloud-Anbieters. Lassen Sie es nicht nur an die Finanzabteilung. Verstehen Sie, wo jeder Dollar hingeht.
- Taggen Sie alles : Dies ist nicht verhandelbar. Taggen Sie Ressourcen nach Projekt, Eigentümer, Umgebung (dev, staging, prod) und ob sie für das Herunterfahren geplant werden können. Das erleichtert die Identifizierung und Automatisierung erheblich.
- Priorisieren Sie das Planen für Nicht-Produktionsumgebungen : Staging-, Entwicklungs- und QA-Umgebungen sind ideale Kandidaten für geplante Abschaltungen außerhalb der Bürozeiten. Das ist in der Regel die einfachste und schnellste Einsparung.
- Bewerten Sie Serverless für neue Arbeitslasten : Wenn Sie etwas Neues bauen, insbesondere ereignisbasierte Mikrodienste oder Hintergrundaufgaben, ziehen Sie Serverless immer zuerst in Betracht.
- Überprüfen Sie Ihre Datenbankentscheidungen : Wenn Sie Datenbanken haben, die 24/7 mit stark variierenden Lasten 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 unbenutzte Speicher-Volumes, alte Snapshots und andere verwaiste Ressourcen zu identifizieren und zu löschen.
- Bildung Ihrer Teams : Fördern Sie eine Kultur des Kostenbewusstseins. Stellen Sie sicher, dass die Entwickler die finanziellen Auswirkungen ihrer Bereitstellungsentscheidungen verstehen. Es ist nicht mehr nur ein Thema für die Betriebsabteilung.
Das Stoppen von Verlusten durch „immer aktive“ Ressourcen ist keine einmalige Lösung; es ist eine fortlaufende Disziplin. Aber durch diese Änderungen werden Sie nicht nur eine erhebliche Geldsumme für Ihr Unternehmen einsparen, sondern auch eine agilere, widerstandsfähigere und zukunftsfähige Infrastruktur aufbauen. Und ehrlich gesagt macht es Sie zu einem besseren Akteur im Technologiebereich.
Das war’s für diesmal. Bauen Sie weiterhin intelligent, und ich sehe Sie beim nächsten Mal!
🕒 Published: