Hallo zusammen, hier ist Jules Martin, zurück auf agntmax.com. Ich hoffe, es geht euch allen gut. Heute möchte ich über etwas sprechen, was mich in letzter Zeit beschäftigt, etwas, das ich in mehr Gesprächen und Projekt-Post-Mortems gesehen habe, als ich zugeben möchte: der unsichtbare Kostenunzugs von nicht optimierter Infrastruktur. Wir alle wissen, dass wir schnell bauen, schnell skalieren und Features von gestern ausliefern müssen. Aber oft, in dieser Eile, hinterlassen wir eine Spur von vergessenen Ressourcen, überdimensionierten Instanzen und Diensten, die im Autopilot-Modus laufen und Rechnungen anhäufen, die wir kaum anschauen, bevor das quartalsmäßige Budget-Review wie ein Stein auf uns fällt.
Also, für diesen Artikel tauche ich kopfüber in die Kostenoptimierung ein, aber mit einem sehr spezifischen und zeitgerechten Blickwinkel: wie man aufhört, Geld für „ständig eingeschaltete“ Ressourcen zu verlieren, die „nach Bedarf“ oder „ereignisgesteuert“ sein sollten. Es ist 2026, Leute. Die Zeiten, in denen man Server nach Bedarf bereitstellt, sind vorbei. Wenn eure Cloud-Rechnung immer noch wie ein Telefonbuch aussieht, ist es Zeit zu handeln.
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 Kundenservices herauszubringen, rückt die Kostenfrage 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 das komplette Internet bedienen könnte, nur damit sie während der Ruhezeiten hauptsächlich ungenutzt bleibt. Wir vergessen, geeignete Skalierungsrichtlinien zu konfigurieren oder lassen einfach alles 24/7 laufen, weil es, nun ja, einfacher ist, sich nicht darum kümmern zu müssen.
Ich habe das vor einigen Monaten mit dem neuen internen Analyse-Dashboard eines Kunden mit eigenen Augen gesehen. Das Team, Gott segne sie, hatte ein fantastisches System gebaut, das Agenten Echtzeitansichten über die Interaktionen mit Kunden bot. Es war ein großer Erfolg für die Performance. Aber als die erste vollständige Cloud-Rechnung kam, hätte der Finanzdirektor fast einen Herzinfarkt bekommen. Sie hatten ein robustes EKS-Cluster, ein paar High-End RDS-Instanzen und eine Menge Lambda-Funktionen mit großzügigen Speicherkapazitäten provisioniert, 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. Draußen war es eine Geisterstadt.
Sie zahlten für eine Unternehmenskapazität für ein System, das effektiv 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 Täter: Wo geht wirklich euer Geld 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 müsst sie unbedingt nutzen. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing Reports – das sind nicht nur für die Finanzen. 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 es nicht sollten? Verwendet ihr die richtige Instanzfamilie für eure Workload?
- Datenbanken (RDS, Azure SQL, Cloud SQL): Wie bei der Berechnung können Datenbanken für IOPS, CPU oder Speicher überprovisioniert sein. Viele bieten mittlerweile serverlose Optionen, die auf null oder fast null Kosten sinken, wenn sie inaktiv sind.
- Speicher (EBS-Volumes, nicht angeschlossene Festplatten): Habt ihr jemals eine Instanz gestartet, sie beendet, aber das zugehörige Speichervolumen herumliegen lassen? Das passiert häufiger, als ihr denkt.
- Netzwerk (Datenübertragung, NAT Gateways): Die Kosten für die Datenübertragung können euch überraschen, besonders zwischen Regionen. NAT Gateways haben auch 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? Ein verwaltetes Kafka-Cluster für einen Nachrichtenstrom?
Mein Kunde aus der Geschichte des Analyse-Dashboards begann damit, seinen AWS Cost Explorer zu betrachten. Die größten Ausgabenposten waren, wie zu erwarten, EC2 und RDS. Sie fanden auch einige EBS-Volumes, die an beendete Instanzen angeschlossen waren, sowie ein NAT Gateway in einer VPC, die nicht mehr für den Produktionstraffik genutzt wurde. Kleine Dinge, aber es summiert sich.
Strategien, um Immer Eingeschaltet in Nach Bedarf (oder Nebenzeiten) zu verwandeln
Okay, ihr habt die Bereiche identifiziert, in denen ihr zu viel ausgebt. Lassen wir uns zum Spaßteil über: das Reparieren. Das Ziel ist nicht nur, Geld zu sparen, sondern ein widerstandsfähigeres und effizienteres System zu schaffen, das Ressourcen nur dann verbraucht, wenn es sie wirklich benötigt.
1. Planen von Start/Stopp für Instanzen
Das ist wahrscheinlich die einfachste Frucht 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 Betriebszyklen für Instanzen zu planen, 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 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 für die Lambda-Funktion (Python):
import boto3
def lambda_handler(event, context):
ec2 = boto3.client('ec2')
# Tags definieren, um die Instanzen zu identifizieren, die gestoppt/startet werden sollen
# Zum Beispiel 'Schedule': 'business-hours'
# Alle laufenden Instanzen mit dem Tag 'Schedule', das auf 'business-hours' gesetzt ist, 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"Stopping instances: {stop_instance_ids}")
ec2.stop_instances(InstanceIds=stop_instance_ids)
else:
print("No instances to stop.")
# --- Ähnliche Logik für das Starten von Instanzen zu einem anderen Zeitpunkt ---
# Ihr hättet eine andere Lambda/CloudWatch-Event, um zu starten,
# oder die Logik mit einem Tag 'start' kombinieren.
return {
'statusCode': 200,
'body': 'EC2 instances scheduling completed.'
}
Ihr solltet zwei CloudWatch-Eventregeln einrichten: eine, um diese Lambda zu triggern, sagen wir, um 18:00 UTC, um die Instanzen zu stoppen, und eine andere um 7:00 UTC, um sie zu starten. Das allein kann die Compute-Kosten für diese spezifischen Ressourcen um mehr als 70 % senken.
2. Setzt auf Serverless und Container-Orchestrierung
Wenn eure Workload wirklich sporadisch oder ereignisgesteuert ist, ist serverlos euer bester Freund. AWS Lambda, Azure Functions, Google Cloud Functions – sie reduzieren sich auf null, wenn sie nicht verwendet werden, was bedeutet, dass ihr nur für das Rechnen bezahlt, wenn euer Code wirklich läuft. Das ist ein riesiger Wandel vom „immer eingeschaltet“-Paradigma.
Für komplexere Anwendungen, die immer noch persistente Dienste benötigen, aber eine schwankende Nachfrage haben, sind Container-Orchestrierungsplattformen wie Kubernetes (EKS, AKS, GKE) in Kombination mit intelligentem Scaling mächtig. Die Horizontal Pod Autoscaler (HPA) können die Größe eurer Anwendungs-Pods basierend auf der CPU-Nutzung oder benutzerdefinierten Metriken variieren. Die Cluster Autoscaler können sogar Knoten zu eurem Cluster hinzufügen oder entfernen, während sich die Nachfrage verändert.
Mein Kunde hat Teile seines Analyse-Dashboards umgebaut, um Lambda zu verwenden, um einige Berichte zu generieren, 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 signifikant.
3. Dimensioniert eure Datenbanken korrekt mit Serverless oder Auto-Scaling
Datenbanken sind oft problematisch, da die Datenpersistenz kritisch ist. Viele moderne Datenbanken bieten jedoch serverlose oder Auto-Scaling-Optionen, die vor einigen Jahren nicht weit verbreitet waren.
- AWS Aurora Serverless v2 : Das ist eine bedeutende Ä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 verwenden. Keine Notwendigkeit mehr, Spitzenkapazitäten vorzuhalten, während Sie die meiste Zeit mit Basislast arbeiten.
- Azure SQL Database Serverless : Ähnlich wie Aurora Serverless passt es sich automatisch an die Rechenkapazität an und pausiert, wenn es inaktiv ist, was signifikante Einsparungen für intermittierende Arbeitslasten realisiert.
- DynamoDB On-Demand : Für NoSQL-Arbeitslasten bedeutet der On-Demand-Kapazitätsmodus von DynamoDB, dass Sie pro Anfrage zahlen, ohne Kapazitätseinheiten für Lese-/Schreibvorgänge bereitzustellen. Perfekt für unvorhersehbare Verkehrsmuster.
Das Analyse-Dashboard verwendete ursprünglich eine große RDS PostgreSQL-Instanz mit bereitgestellten IOPS. Nach der Migration zu Aurora Serverless v2 sanken ihre Datenbankkosten um fast 60 %, einfach weil sie nicht mehr rund um die Uhr im vollen Betrieb waren.
4. Bereinigen Sie Nicht-Angegliederte Speicher und Snapshots
Das mag grundlegende erscheinen, ist aber eine ständige Quelle von Geldverschwendung. Wenn Sie eine EC2-Instanz beenden, wird ihr zugehöriges EBS-Volume nicht immer standardmäßig gelöscht, besonders wenn es sich um ein Nicht-Wurzelvolumen handelt. Das gilt auch für Snapshots – sie sammeln sich schnell an und können teuer werden.
Praktisches Beispiel: Finden und Löschen von Nicht-Angegliederten EBS-Volumes (AWS CLI)
Sie können die AWS CLI verwenden, um nicht angegliederte Volumes zu finden und zu löschen. Das ist eine gängige Bereinigungsaufgabe.
# Alle nicht angegliederten 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 (ACHTUNG, 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 angegliederter EBS-Volumes und Hunderte von veralteten Snapshots. Das Löschen dieser Ressourcen sparte mehrere Hundert Dollar auf ihrer monatlichen Rechnung – das ist zwar nicht riesig, aber jede kleine Geste zählt.
5. Optimieren Sie die Netzwerk Kosten
NAT-Gateways sind fantastisch, um Instanzen in privaten Subnetzen den Zugang zum Internet zu ermöglichen, aber sie verursachen stündliche Gebühren und Kosten für die Datenverarbeitung. Wenn Sie mehrere NAT-Gateways in verschiedenen Verfügbarkeitszonen haben, aber nur eines aktiv verwendet wird, zahlen Sie für redundante Gateways.
- Konsolidieren Sie die 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, verwenden Sie VPC-Endpunkte. Der Datenverkehr erfolgt privat innerhalb des AWS-Netzwerks, wodurch die Kosten für NAT-Gateways vermieden und eine bessere Sicherheit gewährleistet wird.
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 VPC-Endpunkte für den Zugriff auf S3, was die Verarbeitungskosten über das NAT-Gateway senkte.
Maßnahmen für Ihren nächsten Sprint
Es geht nicht nur um Kostensenkung; es geht darum, intelligentere und effektivere Systeme zu schaffen, die intrinsisch kostenbewusst sind. Hier sind einige Dinge, die Sie ab heute tun können:
- Überprüfen Sie regelmäßig Ihre Cloud-Rechnung : Machen Sie es sich zur Gewohnheit. Nutzen Sie die Kostenmanagement-Tools Ihres Cloud-Anbieters. Überlassen Sie es nicht nur der Finanzabteilung. Verstehen Sie, wohin jeder Dollar fließt.
- Taggen Sie alles : Dies ist nicht verhandelbar. Taggen Sie die Ressourcen nach Projekt, Eigentümer, Umgebung (dev, staging, prod) und ob sie für das Herunterfahren geplant werden können. Dies erleichtert die Identifizierung und Automatisierung erheblich.
- Priorisieren Sie das Herunterfahren für Nicht-Produktionsumgebungen : Staging-, Dev- und QA-Umgebungen sind ideale Kandidaten für geplante Abschaltungen außerhalb der Bürozeiten. Das ist in der Regel der einfachste und schnellste Gewinn.
- Bewerten Sie Serverless für neue Arbeitslasten : Wenn Sie etwas Neues bauen, insbesondere eventbasierte Mikrodienste oder Hintergrundaufgaben, ziehen Sie immer zuerst Serverless in Betracht.
- Überdenken Sie Ihre Datenbankwahl : Wenn Sie Datenbanken haben, die 24/7 mit sehr variablen Arbeitslasten laufen, prüfen Sie serverless oder autoskalierende Optionen für Ihre spezifische Datenbanktechnologie.
- Automatisieren Sie die Bereinigung : Implementieren Sie automatisierte Skripte oder serverless Funktionen, um nicht angegliederte Speicher, alte Snapshots und andere verwaiste Ressourcen zu identifizieren und zu löschen.
- Bildung Ihres Teams : Fördern Sie eine Kultur des Kostenbewusstseins. Stellen Sie sicher, dass die Entwickler die finanziellen Auswirkungen ihrer Bereitstellungsauswahl verstehen. Es ist nicht mehr nur ein Betriebsproblem.
Das Stoppen von Verlusten durch „immer aktive“ Ressourcen ist keine einmalige Lösung; es ist eine fortlaufende Disziplin. Aber durch diese Veränderungen werden Sie nicht nur eine beträchtliche Summe Geld für Ihr Unternehmen einsparen, sondern auch eine agilere, widerstandsfähigere und zukunftssichere Infrastruktur aufbauen. Und ganz ehrlich, das macht Sie zu einem besseren Akteur im Technologiebereich.
Das war’s für mich dieses Mal. Machen Sie weiter mit dem klugen Bau, und wir sehen uns beim nächsten Mal!
🕒 Published: