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 durch nicht optimierte Infrastrukturen. Wir alle wissen, dass wir schnell entwickeln, schnell wachsen und Funktionen von gestern liefern müssen. Aber oft, in diesem Eile, lassen wir eine Spur von vergessenen Ressourcen, überdimensionierten Instanzen und im Autopilot laufenden Diensten zurück, die Rechnungen anhäuft, auf die wir kaum einen Blick werfen, bevor die vierteljährliche Haushaltsüberprüfung wie ein Schlag ins Gesicht kommt.
Für diesen Artikel tauche ich tief ein in die Kostenoptimierung, aber mit einem sehr spezifischen und aktuellen Blickwinkel: wie wir aufhören können, Geld für „immer eingeschaltete“ Ressourcen auszugeben, die „bedarfsorientiert“ oder „ereignisgesteuert“ sein sollten. Wir sind im Jahr 2026, Leute. Die Tage, an denen wir Server nach Belieben bereitstellen, sind vorbei. Wenn eure Cloud-Rechnung noch wie ein Telefonbuch aussieht, ist es an der Zeit, einzugreifen.
Der Stille Killer: Immer Eingeschaltet, Wenn Es Bedarfsorientiert Sein Soll
Sehen wir der Wahrheit ins Auge. Wenn wir unter Druck stehen, ein neues Tool für die Agenten oder eine Verbesserung des Kundenservices herauszubringen, stehen die Kosten oft im Hintergrund 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 damit sie größtenteils in den Nebenzeiten ungenutzt bleibt. Wir vergessen, geeignete Skalierungsrichtlinien zu konfigurieren, oder wir lassen einfach die Dinge 24/7 laufen, weil es nun mal einfacher ist, sich nicht darum zu kümmern.
Ich habe das vor einigen Monaten mit dem neuen internen Analytik-Dashboard eines Kunden gesehen. Das Team, Gott segne sie, hatte ein fantastisches System gebaut, das den Agenten Echtzeit-Einblicke in die Kundeninteraktionen gab. Es war ein großer Erfolg für die Leistung. Aber als die erste vollständige Cloud-Rechnung kam, hätte der Finanzdirektor einen Herzinfarkt bekommen können. Sie hatten ein robustes EKS-Cluster, einige hochwertige RDS-Instanzen und eine Vielzahl von Lambda-Funktionen mit großzügigen Speicherzuweisungen bereitgestellt, und all das lief ununterbrochen. 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äten für ein System, das effektiv 70 % der Woche inaktiv war. Es ist wie der Kauf eines Formel-1-Autos, um einmal pro Woche zum Supermarkt zu fahren.
Identifizieren Sie die Täter: Wohin Geht Ihr Geld Wirklich
Bevor Sie etwas reparieren können, müssen Sie wissen, was kaputt ist. Die meisten Cloud-Anbieter bieten Tools an, die Ihnen helfen, Ihre Ausgaben zu visualisieren, und Sie sollten diese unbedingt nutzen. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing Reports – das sind nicht nur Dinge für die Finanzen. Sie sind Ihre erste Verteidigungslinie.
Die Gewöhnlichen Verdächtigen
- Recheninstanzen (EC2, VMs): Das sind oft die größten Übeltäter. Sind sie überdimensioniert? Laufen sie, wenn sie es nicht sollten? Verwenden Sie die richtige Instanzenfamilie für Ihre Arbeitslast?
- Datenbanken (RDS, Azure SQL, Cloud SQL): Wie beim Rechnen können auch Datenbanken für IOPS, CPU oder Arbeitsspeicher überprovisioniert sein. Viele bieten jetzt serverlose Optionen an, die auf null oder fast 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 Speicher-Volume 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: Zahlen Sie 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 mit dem Analytik-Dashboard begann damit, seinen AWS Cost Explorer zu betrachten. Die größten Ausgabenposten waren, wie vorhersehbar, EC2 und RDS. Sie entdeckten 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 das summiert sich.
Strategien, um Immer Eingeschaltet in Bedarfsorientiert (oder Nebenzeiten) zu Wandeln
Okay, Sie haben die Bereiche identifiziert, in denen Sie zu viel ausgeben. Lassen Sie uns zum spaßigen Teil übergehen: das zu reparieren. Das Ziel ist nicht nur, Geld zu sparen, sondern ein widerstandsfähigeres und effizienteres System zu schaffen, das nur dann Ressourcen verbraucht, wenn es tatsächlich benötigt wird.
1. Planen Sie das Starten/Stoppen von Instanzen
Das ist wahrscheinlich die einfachste Möglichkeit für viele Anwendungen. Wenn Ihre internen Tools oder Ihre 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 Betriebszeiten von 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 Lambda-Funktionscodes (Python):
import boto3
def lambda_handler(event, context):
ec2 = boto3.client('ec2')
# Tags definieren, um die Instanzen zu identifizieren, die gestoppt/gestart werden sollen
# 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"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 weiteres Lambda/CloudWatch-Ereignis zum Starten,
# oder kombinieren Sie die Logik mit einem 'start'-Tag.
return {
'statusCode': 200,
'body': 'Planung der EC2-Instanzen abgeschlossen.'
}
Sie sollten zwei CloudWatch-Ereignisregeln einrichten: eine, um diese Lambda zu einem bestimmten Zeitpunkt, sagen wir, 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. Gehen Sie zu Serverless und Containerorchestrierung über
Wenn Ihre Arbeitslast wirklich sporadisch oder ereignisgesteuert ist, ist serverlos Ihr bester Verbündeter. AWS Lambda, Azure Functions, Google Cloud Functions – sie sinken auf null, wenn sie nicht verwendet werden, was bedeutet, dass Sie nur für die Rechenleistung bezahlen, wenn Ihr Code tatsächlich ausgeführt wird. Das ist ein enormer Unterschied zum „immer eingeschaltet“-Paradigma.
Für komplexere Anwendungen, die weiterhin persistente Dienste benötigen, aber eine schwankende Nachfrage haben, sind Container-Orchestrierungsplattformen 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 der CPU-Nutzung oder benutzerdefinierten Metriken variieren. 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 Analytik-Dashboards umgebaut, um Lambda zu nutzen, um bestimmte 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 erheblich.
3. Dimensionieren Sie Ihre Datenbanken Richtig mit Serverless oder Auto-Scaling
Datenbanken sind oft problematisch, da die Datenpersistenz kritisch ist. Allerdings bieten viele moderne Datenbanken serverlose oder Auto-Scaling-Optionen, die vor ein paar Jahren noch nicht weit verbreitet waren.
- AWS Aurora Serverless v2 : Das ist eine signifikante Veränderung. Es passt die Kapazität je nach tatsächlicher Nutzung an, von Bruchteilen eines ACU (Aurora Capacity Unit) bis hin zu Hunderten, und Sie zahlen nur für das, was Sie verwenden. Es ist nicht mehr nötig, für eine Spitzenkapazität 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 geht in den Pausenmodus, wenn es inaktiv ist, was erhebliche Einsparungen für intermittierende 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 Lesen/Schreiben provisionieren zu müssen. Perfekt für unvorhersehbare Traffic-Modelle.
Das Analytik-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 in Spitzenleistung während der Ruhezeiten lief.
4. Bereinigen Sie Nicht-Verbunde Speichermedien 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-wurzel Volume handelte. Das Gleiche gilt für Snapshots – sie sammeln sich schnell an und können kostspielig werden.
Praktisches Beispiel: Finden und Entfernen von Nicht-Verbundenen EBS-Volumes (AWS CLI)
Sie können die AWS CLI verwenden, um nicht-verbundene Volumes zu finden und zu löschen. Das ist eine gängige Reinigungsaufgabe.
# Alle nicht-verbundenen 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 IRREVERSIBEL)
# Ersetzen Sie 'vol-xxxxxxxxxxxxxxxxx' durch die ID des tatsächlichen Volumes
# 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-verbundener EBS-Volumes und hunderte veralteter Snapshots. Das Löschen dieser führte zu Einsparungen von mehreren hundert Dollar auf ihrer monatlichen Rechnung – das ist nicht viel, aber jeder kleine Beitrag zählt.
5. Netzwerkkosten 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 verwendet wird, zahlen Sie für redundante Gateways.
- NAT-Gateways konsolidieren: 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 Verkehr verläuft privat innerhalb des AWS-Netzwerks, wodurch die Kosten der NAT-Gateways vermieden werden und eine bessere Sicherheit geboten wird.
Wir haben festgestellt, dass der Kunde ein NAT-Gateway in jeder AZ hatte, obwohl seine Hauptanwendung nur in zwei funktionierte. Sie konnten konsolidieren und dadurch Einsparungen erzielen, und setzten anschließend VPC-Endpunkte für den Zugriff auf S3 ein, was die Datenverarbeitungskosten über das NAT-Gateway reduzierte.
Maßnahmen für Ihren nächsten Sprint
Es geht nicht nur darum, die Kosten zu senken; es geht darum, intelligentere und effizientere Systeme aufzubauen, 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. Geben Sie es nicht einfach nur an die Finanzabteilung weiter. Verstehen Sie, wohin jeder Dollar fließt.
- Taggen Sie alles: Dies ist nicht verhandelbar. Taggen Sie die Ressourcen nach Projekt, Besitzer, Umgebung (dev, staging, prod) und ob sie für das Stoppen geplant werden können. Das erleichtert die Identifizierung und Automatisierung enorm.
- Priorisieren Sie das Programmieren für Nicht-Produktiv-Umgebungen: Staging-, Entwicklungs- 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 Mikroservices oder Hintergrundaufgaben, sollten Sie immer zuerst Serverless in Betracht ziehen.
- Überprüfen Sie Ihre Datenbankauswahl: Wenn Sie Datenbanken haben, die 24/7 mit sehr variablen Lasten laufen, prüfen Sie die Serverless- oder Auto-Scaling-Optionen für Ihre spezifische Datenbanktechnologie.
- Automatisieren Sie die Bereinigung: Implementieren Sie automatisierte Skripte oder serverless Funktionen, um nicht-verbundene Speicher-Volumes, alte Snapshots und andere verwaiste Ressourcen zu identifizieren und zu entfernen.
- 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 einmalige Lösung; es ist eine kontinuierliche Disziplin. Aber durch diese Änderungen werden Sie nicht nur eine beträchtliche Summe Geld für Ihr Unternehmen sparen, sondern auch eine agilere, resilientere und zukunftsfähige Infrastruktur aufbauen. Und ganz ehrlich, das macht Sie zu einem besseren Akteur im Technologiebereich.
Das war’s für dieses Mal. Machen Sie weiter mit dem intelligenten Bauen, und ich sehe Sie beim nächsten Mal!
🕒 Published: