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, das mich in letzter Zeit beschäftigt, etwas, das ich in mehr Gesprächen und Projekt-Nachbesprechungen gesehen habe, als ich zugeben möchte: die unsichtbaren Kosten für nicht optimierte Infrastruktur. Wir alle wissen, dass wir schnell bauen, schnell skalieren und Funktionen schon gestern liefern müssen. Aber oft, in dieser Eile, hinterlassen wir eine Spur von vergessenen Ressourcen, überdimensionierten Instanzen und Dienstleistungen, die auf Autopilot laufen, und sammeln Rechnungen, denen wir kaum einen Blick schenken, bevor das quartalsweise Budget-Review wie ein Schlechtwetterbericht auf uns einprasselt.
Für diesen Artikel tauche ich tief ein in die Kosteneinsparung, aber mit einem sehr spezifischen und zeitgerechten Ansatz: wie man aufhört, Geld für “ständig laufende” Ressourcen auszugeben, die “nach Bedarf” oder “ereignisgesteuert” sein sollten. Wir sind im Jahr 2026, Leute. Die Tage, an denen Server nach Belieben bereitgestellt wurden, sind vorbei. Wenn eure Cloud-Rechnung noch wie ein Telefonbuch aussieht, ist es Zeit zu handeln.
Der Silent Killer: Immer Eingeschaltet, Wenn Es Nachfrage Sein Sollte
Seien wir realistisch. Wenn wir unter Druck stehen, ein neues Tool für 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 wenig 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 Off-Peak-Zeiten größtenteils ungenutzt bleibt. Wir vergessen, passende Skalierungsrichtlinien zu konfigurieren, oder wir lassen einfach alles 24/7 laufen, weil es nun einmal einfacher ist, sich darum nicht zu kümmern.
Vor einigen Monaten habe ich dies mit den neuen internen Analyse-Dashboard eines Kunden mit eigenen Augen gesehen. Das Team, Gott segne sie, hatte ein fantastisches System entwickelt, das den Agenten Echtzeit-Übersichten über die Interaktionen mit den Kunden bot. Es war ein großer Gewinn für die Leistung. Aber als die erste volle Cloud-Rechnung eintraf, hätte der Finanzdirektor fast einen Herzinfarkt gehabt. Sie hatten einen robusten EKS-Cluster, einige hochrangige RDS-Instanzen und eine Vielzahl von Lambda-Funktionen mit großzügigen Speicherkapazitäten bereitgestellt, die alle ununterbrochen liefen. Der Höhepunkt? Das Dashboard wurde hauptsächlich von den Agenten während der Bürozeiten von 9 bis 17 Uhr, Montag bis Freitag, genutzt. Draußen war es eine Geisterstadt.
Sie zahlten für Unternehmenskapazitäten für ein System, das tatsächlich 70 % der Woche inaktiv war. Das ist so, 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 etwas reparieren könnt, müsst ihr wissen, was kaputt ist. Die meisten Cloud-Anbieter bieten Tools an, die euch helfen, eure Ausgaben zu visualisieren, und ihr solltet sie unbedingt nutzen. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing Reports – das sind nicht nur für die Finanzen. Das ist eure erste Verteidigungslinie.
Die Gewöhnlichen Verdächtigen
- Recheninstanzen (EC2, VMs): Das sind oft die größten Schuldigen. Sind sie überdimensioniert? Laufen sie, wenn sie es nicht sollten? Verwendet ihr die richtige Instanzfamilie für eure Arbeitslast?
- Datenbanken (RDS, Azure SQL, Cloud SQL): Wie bei den Recheninstanzen können auch Datenbanken für die IOPS, CPU oder den Speicher überprovisioniert sein. Viele bieten jetzt serverlose Optionen, die auf null oder nahezu 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 den Datentransfer können euch überraschen, besonders zwischen Regionen. NAT Gateways haben auch eine stündliche Gebühr, selbst wenn sie nichts tun.
- Untergenutzte Dienste: Zahlt ihr für einen dedizierten Redis-Cache, der nur ein paar Zugriffe pro Tag hat? Ein verwalteter Kafka-Cluster für einen Nachrichtenstrom?
Mein Kunde aus der Geschichte des Analyse-Dashboards begann, indem er seinen AWS Cost Explorer ansah. Die größten Kostenstellen waren, wie zu erwarten, EC2 und RDS. Sie fanden auch ein paar EBS-Volumes, die an beendete Instanzen angehängt waren, und eine NAT Gateway in einem VPC, die nicht mehr für den Produktionsverkehr verwendet wurde. Kleinere Dinge, aber das summiert sich.
Strategien, um Immer Eingeschaltet in Nach Bedarf (oder Off-Peak) zu Verwandeln
Okay, ihr habt die Bereiche identifiziert, in denen ihr zu viel ausgebt. Kommen wir zum spaßigen Teil: das zu reparieren. Das Ziel ist nicht nur, Geld zu sparen, sondern ein widerstandsfähigeres und effizienteres System aufzubauen, das Ressourcen nur dann verbraucht, wenn sie tatsächlich benötigt werden.
1. Plant das Starten/Stoppen von Instanzen
Das ist wahrscheinlich die einfachste 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, warum sie 24/7 laufen sollten. Die meisten Cloud-Anbieter bieten native Möglichkeiten, um die Stromversorgung von Instanzen zu planen, oder ihr könnt eure eigene Lösung mit serverlosen Funktionen erstellen.
Praktisches Beispiel: AWS EC2-Planer 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')
# Definiert Tags, um die Instanzen zu identifizieren, die gestoppt/starten werden sollen
# Zum Beispiel, 'Schedule': 'business-hours'
# Holt alle laufenden Instanzen mit dem Tag 'Schedule' gesetzt auf 'business-hours'
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 von Instanzen zu einem anderen Zeitpunkt ---
# Ihr hättet eine andere Lambda/CloudWatch-Ereignis zum Starten,
# oder kombiniert die Logik mit einem 'start'-Tag.
return {
'statusCode': 200,
'body': 'Planung der EC2-Instanzen abgeschlossen.'
}
Ihr solltet zwei CloudWatch-Ereignisregeln einrichten: eine, um dieses Lambda beispielsweise um 18 Uhr UTC zu starten, um die Instanzen zu stoppen, und eine andere um 7 Uhr UTC, um sie zu starten. Das allein kann die Rechenkosten für diese spezifischen Ressourcen um mehr als 70 % 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 laufen auf null, wenn sie nicht genutzt werden, was bedeutet, dass ihr nur für die Rechenleistung zahlt, wenn euer Code tatsächlich ausgeführt wird. Das ist ein gewaltiger Unterschied zum “immer eingeschaltet”-Paradigma.
Für komplexere Anwendungen, die immer noch persistenten Dienste benötigen, aber schwankende Nachfrage haben, sind Plattformen zur Container-Orchestrierung wie Kubernetes (EKS, AKS, GKE) zusammen mit intelligenter Skalierung mächtig. Die Horizontal Pod Autoscalers (HPA) können die Größe eurer Anwendungs-Pods basierend auf CPU-Nutzung oder benutzerdefinierten Metriken variieren. Die Cluster Autoscalers können sogar Knoten zu eurem Cluster hinzufügen oder entfernen, während sich die Nachfrage ändert.
Mein Kunde hat Teile seines Analyse-Dashboards refaktoriert, um Lambda für die Erstellung bestimmter Berichte zu verwenden, die nur ein paar Mal am Tag angefordert wurden. Anstatt eine dedizierte EC2-Instanz zu haben, die einen Cron-Job ausführt, wurde eine Lambda-Funktion durch ein S3-Ereignis (neue hochgeladene Dateien) oder eine API Gateway-Anforderung ausgelöst. Die Einsparungen waren sofort und signifikant.
3. Dimensioniert Eure Datenbanken Richtig mit Serverlos oder Auto-Skalierung
Datenbanken sind oft problematisch, da die Datenspeicherung kritisch ist. Viele moderne Datenbanken bieten jedoch serverlose oder auto-skalierende 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 basierend auf der tatsächlichen Nutzung an, von Bruchteilen eines ACU (Aurora Capacity Unit) bis hin zu Hunderten, und Sie zahlen nur für das, was Sie nutzen. Kein Bedarf mehr, Spitzenauslastungen zu provisionieren, 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 wird in den Ruhezustand versetzt, wenn es nicht aktiv ist, was erhebliche Einsparungen bei intermittierenden Workloads ermöglicht.
- DynamoDB On-Demand : Für NoSQL-Workloads bedeutet der On-Demand-Kapazitätsmodus von DynamoDB, dass Sie pro Anfrage zahlen, ohne Kapazitätseinheiten für Lese-/Schreibvorgänge provisionieren zu müssen. Perfekt für unvorhersehbare Verkehrsmodelle.
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 nicht mehr im Vollbetrieb während der Ruhezeiten lief.
4. Bereinigen Sie Unbenutzte Speicher und Snapshots
Das mag grundlegend erscheinen, ist aber eine ständige Quelle der 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 sammeln 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 Bereinigungsaufgabe.
# Auflisten aller unbenutzten Volumes
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,CreateTime]' --output table
# Um ein spezifisches 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 zeitgesteuerten Lambda-Funktion, wenn Sie häufig Umgebungen erstellen und löschen. Der Kunde entdeckte mehrere Terabyte alter unbenutzter EBS-Volumes und Hunderte von veralteten Snapshots. Das Löschen ermöglichte Einsparungen von mehreren Hundert Dollar bei ihrer monatlichen Rechnung – das ist nicht viel, aber jede kleine Geste zählt.
5. Optimieren Sie die Netzwerkkosten
Die NAT Gateways sind großartig, 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 redundante Gateways.
- Konsolidieren Sie die NAT Gateways : Wenn Ihre Architektur es zulässt, konsolidieren Sie auf weniger NAT Gateways.
- VPC-Endpoints : Um auf AWS-Dienste wie S3 oder DynamoDB von Ihrem VPC aus zuzugreifen, verwenden Sie VPC-Endpoints. Der Datenverkehr fließt privat innerhalb des AWS-Netzwerks, wodurch die Kosten für NAT Gateways vermieden und eine bessere Sicherheit geboten 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 so Kosten einsparen, und implementierten anschließend VPC-Endpoints für den Zugriff auf S3, was die Kosten für die Datenverarbeitung über das NAT Gateway senkte.
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 ist, was Sie bereits heute tun 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 Ressourcen nach Projekt, Verantwortlichem, Umgebung (dev, staging, prod) und ob sie für das Herunterfahren geplant werden können. Das erleichtert die Identifikation 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 sind in der Regel die einfachsten und schnellsten Einsparungen.
- Bewerten Sie Serverless für Neue Workloads : Wenn Sie etwas Neues bauen, insbesondere ereignisbasierte Mikrodienste oder Hintergrundaufgaben, ziehen Sie immer zuerst Serverless in Betracht.
- Überdenken Sie Ihre Datenbankwahl : Wenn Sie Datenbanken haben, die 24/7 mit stark variablen Lasten laufen, prüfen Sie Serverless- oder Auto-Scaling-Optionen für Ihre spezifische Datenbanktechnologie.
- Automatisieren Sie die Bereinigung : Setzen Sie automatisierte Skripte oder serverlose Funktionen ein, um unbenutzte Speicher-Volumes, alte Snapshots und andere verwaiste Ressourcen zu identifizieren und zu löschen.
- Bildung Ihrer Mannschaft : Fördern Sie eine Kultur des Kostenbewusstseins. Stellen Sie sicher, dass die Entwickler die finanziellen Auswirkungen ihrer Provisionierungsentscheidungen verstehen. Es ist nicht mehr nur ein Operations-Thema.
Die Verluste durch „immer aktive“ Ressourcen zu stoppen, ist keine einmalige Lösung; es ist eine fortlaufende Disziplin. Aber durch diese Veränderungen werden Sie nicht nur erhebliche Geldbeträge für Ihr Unternehmen sparen, sondern auch eine agilere, widerstandsfähigere und zukunftssichere Infrastruktur aufbauen. Und ganz ehrlich, das macht Sie zu einem besseren Akteur im Technologiebereich.
Das ist alles von mir für diesmal. Machen Sie weiter intelligent zu bauen, und ich sehe Sie beim nächsten Mal!
🕒 Published: