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 Projektpostmortems gesehen habe, als ich zugeben möchte: die unsichtbaren Kosten durch nicht optimierte Infrastruktur. Wir alle wissen, dass wir schnell aufbauen, schnell skalieren und Funktionen von gestern liefern müssen. Doch oft lassen wir in diesem Eifer eine Spur von vergessenen Ressourcen, überdimensionierten Instanzen und Diensten, die im Autopilot-Modus laufen, zurück, die Rechnungen anhäufen, denen wir kaum einen Blick zuwerfen, bevor das quartalsweise Budget-Review wie ein Haufen Steine über uns hereinbricht.
Für diesen Artikel tauche ich also tief ein in die Kostenoptimierung, aber mit einem sehr spezifischen und aktuellen Aspekt: Wie wir aufhören können, Geld für „ständig laufende“ Ressourcen auszugeben, die „nach Bedarf“ oder „ereignisgesteuert“ sein sollten. Es ist 2026, Leute. Die Tage der Serverbereitstellung auf Abruf sind vorbei. Wenn eure Cloud-Rechnung immer noch wie ein Telefonbuch aussieht, ist es an der Zeit, einzugreifen.
Der stille Killer: Immer an, wenn es Nach Bedarf sein sollte
Seien wir ehrlich. Wenn wir unter Druck sind, ein neues Tool für Agenten oder eine Verbesserung des Kundenservices herauszubringen, steht der Kostenfaktor oft hinter Funktionalität und Geschwindigkeit 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 provisionierten IOPS, die das gesamte Internet bewältigen könnte, nur damit sie während der Nebenzeiten größtenteils ungenutzt bleibt. Wir vergessen, geeignete Skalierungsrichtlinien zu konfigurieren, oder wir lassen die Dinge einfach rund um die Uhr 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 selbst gesehen. Das Team, Gott sei Dank, hatte ein fantastisches System gebaut, das den Agenten Echtzeiteinblicke in die Interaktionen mit den Kunden gab. Das war ein großer Schritt in Richtung Leistungssteigerung. Aber als die erste vollständige Cloud-Rechnung eintraf, wäre der Finanzdirektor fast ohnmächtig geworden. Sie hatten einen robusten EKS-Cluster bereitgestellt, einige hochgradierte RDS-Instanzen und eine Vielzahl von Lambda-Funktionen mit großzügigen Speicherkapazitäten, die alle ununterbrochen liefen. Der Höhepunkt? Das Dashboard wurde hauptsächlich von den Agenten während der Bürozeiten genutzt, von 9 bis 17 Uhr, von Montag bis Freitag. 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, als würde man ein Formel-1-Auto für den Einkauf einmal pro Woche im Supermarkt kaufen.
Identifizieren Sie die Schuldigen: Wo geht Ihr Geld wirklich hin
Bevor Sie irgendetwas reparieren können, müssen Sie wissen, was kaputt ist. Die meisten Cloud-Anbieter bieten Tools, um Ihre Ausgaben zu visualisieren, und Sie sollten diese unbedingt nutzen. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing-Berichte – das sind nicht nur etwas für die Finanzen. Sie sind Ihre erste Verteidigungslinie.
Die üblichen Verdächtigen
- Berechnungsinstanzen (EC2, VMs): Diese gehören oft zu den größten Schuldigen. Sind sie überdimensioniert? Läuft sie, wann sie es nicht sollte? Nutzen Sie die richtige Instanzfamilie für Ihre Arbeitslast?
- Datenbanken (RDS, Azure SQL, Cloud SQL): Wie beim Rechnen können auch Datenbanken überprovisioniert sein, sei es für IOPS, CPU oder Speicher. Viele bieten mittlerweile serverlose Optionen, die auf null oder nahezu null Kosten sinken, wenn sie inaktiv sind.
- Speicher (EBS-Volumes, nicht angeschlossene Disks): Haben Sie jemals eine Instanz gestartet, sie beendet, aber das zugehörige Speicher-Volume einfach herumliegen lassen? Das passiert öfter, als Sie denken.
- Netzwerk (Datenübertragung, NAT Gateways): Die Kosten für Datenübertragungen können Sie überraschen, insbesondere zwischen Regionen. NAT Gateways haben ebenfalls Kosten pro Stunde, selbst wenn sie nichts tun.
- Untergenutzte Dienste: Zahlen Sie für einen dedizierten Redis-Cache, der nur wenige Zugriffe pro Tag hat? Einen verwalteten Kafka-Cluster für einen Nachrichtenstrom?
Mein Kunde, dessen Analyse-Dashboard ich erwähnt habe, begann damit, seinen AWS Cost Explorer zu durchsuchen. Die größten Ausgabenposten waren, wie zu erwarten, EC2 und RDS. Sie fanden auch einige EBS-Volumes, die an beendete Instanzen angeschlossen waren, und ein NAT Gateway in einer VPC, die nicht mehr für den Produktionsverkehr genutzt wurde. Kleinere Dinge, aber das summiert sich.
Strategien, um Immer an in Nach Bedarf (oder außerhalb der Spitzenzeiten) zu verwandeln
Okay, Sie haben die Bereiche identifiziert, in denen Sie zu viel ausgeben. Kommen wir zum Spaß: Es zu reparieren. Das Ziel ist nicht nur, Geld zu sparen, sondern ein robusteres und effizienteres System zu bauen, das Ressourcen nur dann verbraucht, wenn es sie tatsächlich benötigt.
1. Planen Sie das Starten/Stoppen von Instanzen
Das ist wahrscheinlich die einfachste Frucht 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 an, um Stromversorgungszyklen für Instanzen zu planen, oder Sie können Ihre eigene Lösung mit serverlosen Funktionen erstellen.
Praktisches Beispiel: AWS EC2-Planer 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 der Lambda-Funktion (Python):
import boto3
def lambda_handler(event, context):
ec2 = boto3.client('ec2')
# Tags definieren, um 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 zu stoppen.")
# --- Ähnliche Logik zum Starten von Instanzen zu einem anderen Zeitpunkt ---
# Sie hätten eine andere Lambda/CloudWatch-Ereignis zum Starten,
# oder die Logik mit einem Tag 'start' kombinieren.
return {
'statusCode': 200,
'body': 'Planung der EC2-Instanzen abgeschlossen.'
}
Sie sollten 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 zum Starten. Dies kann die Kosten für die Berechnung für diese spezifischen Ressourcen um mehr als 70 % senken.
2. Nutzen Sie serverlose und Containerorchestrierung
Wenn Ihre Arbeitslast wirklich sporadisch oder ereignisgesteuert ist, ist serverlos Ihr bester Verbündeter. AWS Lambda, Azure Functions, Google Cloud Functions – sie gehen auf null zurück, wenn sie nicht genutzt werden, was bedeutet, dass Sie nur für die Berechnung bezahlen, wenn Ihr Code tatsächlich ausgeführt wird. Das ist ein riesiger Schritt weg vom „immer an“-Paradigma.
Für komplexere Anwendungen, die immer noch persistenten Services benötigen, aber eine schwankende Nachfrage haben, sind Containerorchestrierungsplattformen wie Kubernetes (EKS, AKS, GKE) in Kombination mit intelligenter Skalierung mächtig. Die Horizontal Pod Autoscaler (HPA) können die Größe Ihrer Anwendungs-Pods basierend auf CPU-Nutzung oder benutzerdefinierten Metriken anpassen. Die Cluster Autoscaler können sogar Knoten zu Ihrem Cluster hinzufügen oder entfernen, während sich die Nachfrage ändert.
Mein Kunde hat Teile seines Analyse-Dashboards so umgestaltet, dass Lambda verwendet wird, um bestimmte Berichte zu generieren, die nur ein paar Mal am Tag angefordert werden. 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. Dimensionieren Sie Ihre Datenbanken richtig mit Serverless oder Auto-Scaling
Datenbanken sind oft problematisch, da die Persistenz von Daten entscheidend ist. Viele moderne Datenbanken bieten jedoch serverlose oder Auto-Scaling-Optionen, die vor ein paar Jahren 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 einer ACU (Aurora Capacity Unit) bis hin zu Hunderten, und Sie zahlen nur für das, was Sie tatsächlich verwenden. Es ist nicht mehr nötig, 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 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 zahlen, ohne Kapazitätseinheiten für Lese- und Schreibvorgänge bereitzustellen. Perfekt für unvorhersehbare Verkehrsmodelle.
Das Analytik-Dashboard nutzte ursprünglich eine große RDS PostgreSQL-Instanz mit bereitgestellten IOPS. Nach der Migration zu Aurora Serverless v2 fielen die Datenbankkosten um fast 60 %, einfach weil es nicht mehr mit voller Leistung während der Nebenzeiten lief.
4. Bereinigen Sie Nicht Angeschlossene Speicher und Snapshots
Das mag grundlegend erscheinen, ist jedoch 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, besonders wenn es sich um ein Nicht-Root-Volume handelte. Gleiches gilt für Snapshots – sie häufen sich schnell an und können kostspielig werden.
Praktisches Beispiel: Finden und Löschen von Nicht Angeschlossenen EBS-Volumes (AWS CLI)
Sie können die AWS CLI verwenden, um nicht angeschlossene Volumes zu finden und zu löschen. Es ist eine gängige Bereinigungsaufgabe.
# Alle nicht angeschlossenen 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 UNREAKTIVIERBAR)
# 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 oft Umgebungen erstellen und löschen. Der Kunde entdeckte mehrere Terabyte an alten nicht angeschlossenen EBS-Volumes und Hunderte veralteter Snapshots. Deren Löschung sparte ein paar hundert Dollar bei ihrer monatlichen Rechnung – das ist zwar nicht riesig, aber jede kleine Maßnahme 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 Datenverarbeitungsgebühren. Wenn Sie mehrere NAT-Gateways in verschiedenen Verfügbarkeitszonen haben, aber nur eines aktiv genutzt wird, bezahlen Sie für Redundanzen.
- Konsolidieren Sie die NAT-Gateways : Wenn Ihre Architektur es zulässt, konsolidieren Sie auf weniger NAT-Gateways.
- VPC-Endpunkte : Um auf AWS-Services wie S3 oder DynamoDB von Ihrem VPC aus zuzugreifen, verwenden Sie VPC-Endpunkte. Der Datenverkehr verläuft privat im AWS-Netzwerk und vermeidet Kosten für die NAT-Gateways und bietet zudem mehr Sicherheit.
Wir stellten fest, dass der Kunde ein NAT-Gateway in jeder AZ hatte, obwohl seine Hauptanwendung nur in zweien lief. Sie konnten konsolidieren und dabei Einsparungen erzielen, und implementierten dann VPC-Endpunkte 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, die Kosten zu reduzieren; es geht darum, intelligenter und effizienter zu bauen, intrinsisch kostenbewusst zu sein. Hier sind einige Dinge, die Sie sofort umsetzen 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 den Finanzen überlassen. 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 Abschalten geplant werden können. Das erleichtert die Identifizierung und Automatisierung erheblich.
- Priorisieren Sie das Planen von Nicht-Produktionsumgebungen : Staging-, Dev- 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 entwickeln, insbesondere eventbasierte Microservices oder Hintergrundaufgaben, sollten Sie immer zuerst die serverless Variante in Betracht ziehen.
- Überdenken Sie Ihre Datenbankwahl : 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 : Setzen Sie automatisierte Skripte oder serverless Funktionen ein, um nicht angeschlossene Speicher-Volumes, alte Snapshots und andere verwaiste Ressourcen zu identifizieren und zu löschen.
- Schulen Sie Ihr Team : Fördern Sie eine Kultur der Kostensensibilisierung. Stellen Sie sicher, dass die Entwickler die finanziellen Auswirkungen ihrer Bereitstellungsentscheidungen verstehen. Es ist nicht mehr nur ein Betriebsproblem.
Das Stoppen von Verlusten durch “immer aktive” Ressourcen ist keine einmalige Lösung; es ist eine kontinuierliche Disziplin. Aber durch diese Änderungen werden Sie nicht nur eine beträchtliche Summe für Ihr Unternehmen sparen, sondern auch eine agilere, widerstandsfähigere und zukunftssichere Infrastruktur aufbauen. Und ehrlich gesagt, macht das Sie zu einem besseren Akteur im Technologiebereich.
Das war’s von meiner Seite für dieses Mal. Bauen Sie weiter smart, und ich sehe euch beim nächsten Mal!
🕒 Published: