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-Postmortems gesehen habe, als ich zugeben möchte: die unsichtbare Belastung durch nicht optimierte Infrastrukturkosten. Wir alle wissen, dass wir schnell bauen, schnell wachsen und Funktionen von gestern liefern müssen. Aber oft lassen wir in dieser Eile eine Spur von vergessenen Ressourcen, überdimensionierten Instanzen und Diensten, die im Leerlauf laufen, zurück, und sammeln Rechnungen an, die wir kaum einen Blick darauf werfen, bevor die vierteljährliche Haushaltsüberprüfung wie ein Schlaghammer auf uns niedergeht.
Für diesen Artikel gehe ich kopfüber in die Kosteneffizienz, aber mit einem sehr spezifischen und aktuellen Ansatz: wie man aufhört, Geld für „immer eingeschaltete“ Ressourcen auszugeben, die „nach Bedarf“ oder „ereignisgesteuert“ sein sollten. Wir sind im Jahr 2026, Leute. Die Zeiten, in denen Server nach dem „All-you-can-eat“-Prinzip bereitgestellt werden, sind vorbei. Wenn eure Cloud-Rechnung immer noch wie ein Telefonbuch aussieht, ist es Zeit, einzugreifen.
Der stille Mörder: Immer eingeschaltet, wenn es nach Bedarf sein sollte
Sehen wir der Realität ins Auge. Wenn wir unter Druck stehen, ein neues Tool für Agenten oder eine Verbesserung des Kundenservices bereitzustellen, rückt der Preis in der Regel an zweiter Stelle hinter 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 gesamte Internet bewältigen könnte, nur um festzustellen, dass sie während der schwachen Stunden größtenteils ungenutzt bleibt. Wir vergessen, geeignete Skalierungsrichtlinien zu konfigurieren, oder lassen einfach alles rund um die Uhr laufen, weil es na ja, einfacher ist, sich keine Gedanken darüber zu machen.
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 aufgebaut, das Agenten Echtzeit-Einblicke in die Interaktionen mit Kunden bot. Es war ein riesiger Sieg 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 hochklassige RDS-Instanzen und eine Vielzahl von Lambda-Funktionen mit großzügigen Speicherzuweisungen provisioning, 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, von Montag bis Freitag, genutzt. Außerhalb dieser Zeiten war es eine Geisterstadt.
Sie zahlten für Unternehmenskapazität für ein System, das tatsächlich 70 % der Woche inaktiv war. Es ist wie der Kauf eines Formel-1-Wagens, um einmal pro Woche zum Supermarkt zu fahren.
Identifizieren Sie die Schuldigen: Wo fließt Ihr Geld wirklich hin
Bevor Sie irgendetwas reparieren können, müssen Sie wissen, was kaputt ist. Die meisten Cloud-Anbieter bieten Tools an, um Ihnen zu helfen, Ihre Ausgaben zu visualisieren, und Sie müssen diese unbedingt nutzen. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing reports – die sind nicht nur für die Finanzen. Sie sind Ihre 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? Verwenden Sie die richtige Instanzfamilie für Ihre Arbeitslast?
- Datenbanken (RDS, Azure SQL, Cloud SQL): Wie bei Recheninstanzen können Datenbanken für IOPS, CPU oder Arbeitsspeicher überprovisioniert sein. Viele bieten mittlerweile serverlose Optionen, die auf null oder nahezu null Kosten sinken, wenn sie inaktiv sind.
- Speicher (EBS-Volumes, nicht angehängte Festplatten): Haben Sie jemals eine Instanz gestartet, sie beendet, aber das zugehörige Speichervolumen einfach herumliegen lassen? Das passiert häufiger, als Sie denken.
- Netzwerk (Datenübertragung, NAT-Gateways): Die Kosten für die Datenübertragung können Sie überraschen, insbesondere zwischen Regionen. NAT-Gateways haben ebenfalls Kosten pro Stunde, selbst wenn sie nichts tun.
- Untergenutzte Dienste: Bezahlen Sie 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 mit dem Analyse-Dashboard begann mit der Überprüfung seines AWS Cost Explorer. Die größten Ausgaben 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. Kleine Dinge, aber das summiert sich.
Strategien, um Immer Eingeschaltet in Nach Bedarf (oder außerhalb der Spitzenzeiten) umzuwandeln
Okay, Sie haben die Bereiche identifiziert, in denen Sie zu viel ausgeben. Lassen Sie uns zum spaßigen Teil übergehen: dies zu beheben. Das Ziel ist nicht nur, Geld zu sparen, sondern ein resilientes und effizientes System aufzubauen, das Ressourcen nur dann verbraucht, wenn es sie tatsächlich benötigt.
1. Planen Sie das Starten/Stoppen von Instanzen
Dies ist wahrscheinlich der einfachste Faktor für viele Anwendungen. Wenn Ihre internen Tools oder Ihre Staging-Umgebungen nur während der Bürozeiten genutzt werden, gibt es keinen Grund, dass sie rund um die Uhr laufen. Die meisten Cloud-Anbieter bieten native Möglichkeiten, um den Stromzyklus von Instanzen zu planen, oder Sie können Ihre eigene Lösung mit serverlosen Funktionen erstellen.
Praktisches Beispiel: AWS EC2 Scheduler mit Lambda
Sie können 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')
# Definieren Sie Tags, um die zu stoppenden/startenden Instanzen zu identifizieren
# 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"Stoppen der 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 ---
# Sie hätten ein anderes Lambda/CloudWatch-Ereignis zum Starten,
# oder Sie kombinieren die Logik mit einem Tag 'start'.
return {
'statusCode': 200,
'body': 'Planung der EC2-Instanzen abgeschlossen.'
}
Sie sollten zwei CloudWatch-Ereignisregeln einrichten: eine, um diese Lambda zu einem Zeitpunkt, 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 speziellen Ressourcen um mehr als 70 % senken.
2. Setzen Sie auf Serverless und Container-Orchestrierung
Wenn Ihre Arbeitslast wirklich sporadisch oder ereignisgesteuert ist, ist serverless Ihr bester Verbündeter. AWS Lambda, Azure Functions, Google Cloud Functions – sie kosten nichts, wenn sie nicht genutzt werden, was bedeutet, dass Sie nur für die Rechenleistung bezahlen, wenn Ihr Code tatsächlich ausgeführt wird. Das ist eine riesige Veränderung gegenüber dem „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 Autoscaler (HPA) können die Größe Ihrer Anwendungs-Pods basierend auf der CPU-Nutzung oder benutzerdefinierten Metriken variieren. Die Cluster Autoscaler können sogar Knoten aus Ihrem Cluster hinzufügen oder entfernen, während sich die Nachfrage ändert.
Mein Kunde hat Teile seines Analyse-Dashboards so refaktoriert, dass Lambda verwendet wird, um bestimmte Berichte zu generieren, die nur einige Male pro 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-Anforderung ausgelöst. Die Einsparungen waren sofort und signifikant.
3. Dimensionieren Sie Ihre Datenbanken korrekt mit Serverless oder Auto-Scaling
Datenbanken sind oft problematisch, da die Persistenz von Daten kritisch ist. Viele moderne Datenbanken bieten jedoch serverlose Optionen oder Auto-Scaling, 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 nutzen. Kein Bedarf mehr, für eine Spitzenkapazität vorzusehen, während Sie die meiste Zeit mit Grundlast arbeiten.
- Azure SQL Database Serverless : Ähnlich wie Aurora Serverless passt es sich automatisch an die Rechenkapazität an und geht in den Pausen-Modus, wenn es inaktiv ist, was erhebliche Einsparungen für intermittierende Workloads bedeutet.
- DynamoDB On-Demand : Für NoSQL-Workloads bedeutet der On-Demand-Kapazitätsmodus von DynamoDB, dass Sie pro Anfrage zahlen, ohne Einheiten für Lese-/Schreibkapazität bereitstellen zu müssen. Perfekt für unvorhersehbare Verkehrsmodelle.
Das Analytics-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 auf Hochtouren liefen.
4. Bereinigen Sie Unbenutzte Speicher und Snapshots
Das mag einfach 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 handelte. Gleiches gilt für die 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 sie zu löschen. Dies ist eine gängige Bereinigungsaufgabe.
# 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 (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 stellte mehrere Terabyte alter unbenutzter EBS-Volumes und Hunderte von obsoleten Snapshots fest. Ihr Löschen hat einige Hundert Dollar bei ihrer Monatsrechnung gespart – das ist nicht riesig, aber jede kleine Geste zählt.
5. Netzwerk Kosten Optimieren
NAT-Gateways sind fantastisch, um Instanzen in privaten Subnetzen den Zugang zum Internet zu ermöglichen, aber sie verursachen stündliche Gebühren und Gebühren für die Datenverarbeitung. 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-Endpunkte: Verwenden Sie VPC-Endpunkte, um auf AWS-Dienste wie S3 oder DynamoDB von Ihrem VPC aus zuzugreifen. Der Verkehr läuft privat im AWS-Netzwerk, vermeidet Kosten von NAT-Gateways und bietet bessere Sicherheit.
Wir haben festgestellt, dass der Kunde ein NAT-Gateway in jeder AZ hatte, obwohl seine Hauptanwendung nur in zwei lief. Sie konnten konsolidieren und dadurch Einsparungen erzielen, dann implementierten sie VPC-Endpunkte für den Zugriff auf S3, was die Datenverarbeitungskosten über das NAT-Gateway senkte.
Zu Ergreifende Maßnahmen Für Ihren Nächsten Sprint
Es geht nicht nur um Kostensenkung; es geht darum, intelligentere und effizientere Systeme zu bauen, die intrinsisch kostensensibel sind. Hier ist, was Sie sofort tun können:
- Überprüfen Sie Regelmäßig Ihre Cloud-Rechnung: Machen Sie es sich zur Gewohnheit. Nutzen Sie die Kostemanagement-Tools Ihres Cloud-Anbieters. Überlassen Sie es nicht nur der Finanzabteilung. Verstehen Sie, wo jeder Dollar hingeht.
- Taggen Sie Alles: Das ist unverhandelbar. Taggen Sie Ressourcen nach Projekt, Eigentümer, Umgebung (dev, staging, prod) und ob sie für das Abschalten geplant werden können. Dies erleichtert erheblich die Identifikation und Automatisierung.
- Priorisieren Sie das Planen 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 Workloads: Wenn Sie etwas Neues bauen, insbesondere ereignisbasierte Mikrodienste oder Hintergrundaufgaben, sollten Sie immer zuerst serverless in Betracht ziehen.
- Überdenken Sie Ihre Datenbankentscheidungen: Wenn Sie Datenbanken haben, die 24/7 mit sehr variierenden Lasten laufen, prüfen Sie serverless oder autoscalierbare Optionen für Ihre spezifische Datenbanktechnologie.
- Automatisieren Sie die Bereinigung: Implementieren Sie automatisierte Skripte oder serverless Funktionen, um unbenutzte Speichervolumes, 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 Provisionierungsentscheidungen verstehen. Es ist nicht mehr nur ein Betriebsproblem.
Das Stoppen von Verlusten durch „immer aktive“ Ressourcen ist keine kurzfristige Lösung; es ist eine kontinuierliche Disziplin. Aber indem Sie diese Änderungen vornehmen, sparen Sie nicht nur einen erheblichen Geldbetrag für Ihr Unternehmen, sondern bauen auch eine agilere, resiliente und zukunftssichere Infrastruktur auf. Und ehrlich gesagt, macht das 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: