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-Pflegegesprächen gesehen habe, als ich zugeben möchte: der unsichtbare Abzug der Kosten für nicht optimierte Infrastruktur. Wir alle wissen, dass wir schnell bauen, schnell skalieren und Funktionen gestern bereitstellen müssen. Aber oft lassen wir in dieser Eile eine Spur vergessener Ressourcen, überdimensionierter Instanzen und im Leerlauf laufender Dienste zurück, die Rechnungen anhäufen, auf die wir kaum einen Blick werfen, bevor das Quartalsbudget-Review wie ein Schicksalsschlag auf uns niedergeht.
Für diesen Artikel werde ich mich ganz der Kostenoptimierung widmen, aber mit einem sehr spezifischen und zeitgerechten Ansatz: wie man aufhört, Geld für „immer aktive“ Ressourcen auszugeben, die „on demand“ oder „ereignisgesteuert“ sein sollten. Wir sind im Jahr 2026, Leute. Die Zeiten, in denen wir Server nach Bedarf bereitstellen, sind vorbei. Wenn eure Cloud-Rechnung immer noch wie ein Telefonbuch aussieht, ist es Zeit, einzugreifen.
Der stille Killer: Immer aktiv, wenn es “on demand” sein sollte
Seien wir realistisch. Wenn wir unter Druck stehen, ein neues Tool für Agenten oder eine Verbesserung des Kundenservices zu entwickeln, tritt die Kostenfrage meist in den Hintergrund hinter die Funktionalität und die Geschwindigkeit. 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 bereitgestellten IOPS, die das gesamte Internet bewältigen könnte, nur damit sie größtenteils in den Nebenzeiten ungenutzt bleibt. Wir vergessen, angemessene Skalierungsrichtlinien einzustellen, oder wir lassen einfach alles rund um die Uhr laufen, weil es nun mal einfacher ist, als sich darum zu kümmern.
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 Echtzeiteinblicke in die Interaktionen mit Kunden bot. Das war ein großer Sieg 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 bereitgestellt, einige hochwertige 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, von 9 bis 17 Uhr, von Montag bis Freitag genutzt. Daran außerhalb dieser Zeiten war es eine Geisterstadt.
Sie bezahlten für eine Unternehmenskapazität für ein System, das effektiv 70 % der Woche inaktiv war. Das ist, als würde man ein Formel-1-Auto kaufen, um einmal pro Woche zum Supermarkt zu fahren.
Die Täter identifizieren: Wo geht Ihr Geld wirklich hin
Bevor Sie etwas 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 sollten sie unbedingt nutzen. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing Reports – das sind nicht nur Finanztools. Sie sind Ihre erste Verteidigungslinie.
Die üblichen Verdächtigen
- Berechnungsinstanzen (EC2, VMs): Dies 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 der Berechnung können Datenbanken für IOPS, CPU oder Speicher überprovisioniert sein. Viele bieten inzwischen serverlose Optionen, die bei Inaktivität auf null oder fast null zurückgehen.
- Speicher (EBS-Volumes, nicht angeschlossene Festplatten): Haben Sie schon einmal eine Instanz gestartet, sie beendet, aber das damit verbundene Speichervolumen herumliegen lassen? Das kommt häufiger vor, als man denkt.
- Netzwerk (Datenübertragung, NAT Gateways): Die Kosten für die Datenübertragung können Sie überraschen, vor allem zwischen Regionen. NAT Gateways haben ebenfalls Kosten pro Stunde, auch wenn sie nichts tun.
- Untergenutzte Dienste: Bezahlen 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 Analyse-Dashboard hatte mit seinem AWS Cost Explorer begonnen. Die größten Ausgabenposten waren, wie zu erwarten, EC2 und RDS. Sie fanden auch einige EBS-Volumes, die an abgeschlossenen Instanzen hingen, und ein NAT Gateway in einer VPC, die nicht mehr für Produktionsverkehr verwendet wurde. Kleine Dinge, aber das summiert sich.
Strategien, um Immer aktiv in On Demand (oder Nebensaison) zu verwandeln
Okay, Sie haben die Bereiche identifiziert, in denen Sie zu viel ausgeben. Kommen wir zum spannenden Teil: das zu beheben. Das Ziel ist nicht nur, Geld zu sparen, sondern ein widerstandsfähigeres und effizienteres System zu schaffen, das Ressourcen nur dann benötigt, wenn es wirklich nötig ist.
1. Planen Sie das Starten/Stoppen von Instanzen
Das ist wahrscheinlich die einfachste Lösung für viele Anwendungen. Wenn Ihre internen Werkzeuge oder Ihre Staging-Umgebungen nur während der Bürozeiten verwendet werden, gibt es keinen Grund, warum sie 24/7 laufen sollten. Die meisten Cloud-Anbieter bieten native Möglichkeiten zur Planung von Instanz-Stromzyklen an, 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 für die Lambda-Funktion (Python):
import boto3
def lambda_handler(event, context):
ec2 = boto3.client('ec2')
# Tags definieren, um die zu stoppenden/startenden Instanzen zu identifizieren
# Zum Beispiel, 'Schedule': 'business-hours'
# Alle laufenden Instanzen mit dem Tag 'Schedule', der auf 'business-hours' eingestellt 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 weiteres Lambda/CloudWatch-Ereignis zum Starten,
# oder eine Kombination der Logik mit einem Tag 'start'.
return {
'statusCode': 200,
'body': 'Planung der EC2-Instanzen abgeschlossen.'
}
Sie sollten zwei CloudWatch-Ereignisregeln einrichten: eine zum Auslösen dieser Lambda, sagen wir, um 18 Uhr UTC zum Stoppen der Instanzen und eine weitere um 7 Uhr UTC zum Starten. Das allein kann die Rechenkosten um mehr als 70 % für diese spezifischen Ressourcen senken.
2. Setzen Sie auf serverlos und Container-Orchestrierung
Wenn Ihre Arbeitslast wirklich sporadisch oder ereignisgesteuert ist, dann ist serverlos Ihr bester Verbündeter. AWS Lambda, Azure Functions, Google Cloud Functions – sie reduzieren sich auf null, wenn sie nicht verwendet werden, was bedeutet, dass Sie nur für die Berechnung bezahlen, wenn Ihr Code tatsächlich ausgeführt wird. Das ist eine enorme Veränderung im Vergleich zu dem „immer aktiven“ Paradigma.
Für komplexere Anwendungen, die immer noch anhaltende Dienste benötigen, aber schwankende Nachfrage haben, sind Container-Orchestrierungsplattformen wie Kubernetes (EKS, AKS, GKE) in Kombination mit intelligenter Skalierung leistungsstark. Die Horizontal Pod Autoscalers (HPA) können die Größe Ihrer Anwendungs-Pods basierend auf der CPU-Nutzung oder benutzerdefinierten Metriken variieren. Cluster Autoscalers können sogar Knoten zu Ihrem Cluster hinzufügen oder entfernen, während sich die Nachfrage ändert.
Mein Kunde hat Teile seines Analyse-Dashboards umgestaltet, um Lambda zu verwenden, um einige Berichte zu generieren, die nur ein paar Mal am Tag benötigt 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 serverlos oder auto-skalierend
Datenbanken sind oft problematisch, da die Datenspeicherung kritisch ist. Viele moderne Datenbanken bieten jedoch serverlose oder auto-skalierende Optionen, die vor ein paar Jahren nicht weit verbreitet waren.
- AWS Aurora Serverless v2 : Das ist eine signifikante Ä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 man bezahlt nur für das, was man nutzt. Man muss nicht mehr für eine Spitzenkapazität bereitstellen, während man die meiste Zeit auf Basislast läuft.
- Azure SQL Database Serverless : Ähnlich wie Aurora Serverless passt es sich automatisch der 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 man pro Anfrage zahlt, ohne dass man Lese-/Schreibkapazitätseinheiten bereitstellen muss. Ideal für unvorhersehbare Verkehrsmodelle.
Das Analytik-Dashboard verwendete ursprünglich eine große RDS PostgreSQL-Instanz mit bereitgestellten IOPS. Nach der Migration zu Aurora Serverless v2 fielen ihre Datenbankkosten um nahezu 60 %, einfach weil sie nicht mehr ständig mit voller Leistung während der Nebennutzungszeiten lief.
4. Bereinigen Sie Unverbundene Speichermedien und Snapshots
Das mag grundlegend erscheinen, ist jedoch eine ständige Quelle der Geldverschwendung. Wenn Sie eine EC2-Instanz beenden, wird ihr zugehöriges EBS-Volumen nicht immer standardmäßig gelöscht, insbesondere wenn es sich um ein Nicht-Stammvolumen handelt. Das gleiche gilt für Snapshots – sie sammeln sich schnell an und können teuer werden.
Praktisches Beispiel: Finden und Löschen von Unverbundenen EBS-Volumina (AWS CLI)
Sie können die AWS CLI nutzen, um unverbundene Volumina zu finden und zu löschen. Dies ist eine gängige Reinigungsaufgabe.
# Alle unverbundenen Volumina auflisten
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,CreateTime]' --output table
# Um ein bestimmtes Volumen zu löschen (VORSICHT, DAS IST UNUMKEHRBAR)
# Ersetzen Sie 'vol-xxxxxxxxxxxxxxxxx' durch die tatsächliche Volumen-ID
# aws ec2 delete-volume --volume-id vol-xxxxxxxxxxxxxxxxx
Automatisieren Sie dies mit einer programmierten Lambda-Funktion, wenn Sie oft Umgebungen erstellen und löschen. Der Kunde entdeckte mehrere Terabyte alter unverbundener EBS-Volumina und Hunderte veralteter Snapshots. Ihr Löschen führte zu Einsparungen von mehreren hundert Dollar auf ihrer monatlichen Rechnung – kein riesiger Betrag, aber jede kleine Aktion zählt.
5. Optimieren Sie die Netzwerk Kosten
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 genutzt wird, zahlen Sie für redundante.
- Konsolidieren Sie 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 fließt privat innerhalb des AWS-Netzwerks, was die Kosten für NAT-Gateways vermeidet und eine bessere Sicherheit bietet.
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 setzten dann VPC-Endpunkte für den Zugriff auf S3 um, was die Datenverarbeitungskosten über das NAT-Gateway senkte.
Maßnahmen für Ihren nächsten Sprint
Es geht nicht nur um Kostenreduzierung; es geht darum, intelligentere und effizientere Systeme zu bauen, die intrinsisch kostenbewusst sind. Hier sind einige Dinge, die Sie noch heute anfangen können zu tun:
- Überprüfen Sie regelmäßig Ihre Cloud-Rechnung : Machen Sie es sich zur Gewohnheit. Nutzen Sie die Kostenmanagement-Tools Ihres Cloud-Anbieters. Schieben Sie es nicht nur auf die Finanzen. Verstehen Sie, wo jeder Dollar hingeht.
- Taggen Sie alles : Das 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-Produktiv-Umgebungen : Staging-, Entwicklungs- und QA-Umgebungen sind ideale Kandidaten für geplante Stillstände außerhalb der Bürozeiten. Dies ist in der Regel die einfachste und schnellste Einsparung.
- Bewerten Sie Serverless für neue Arbeitslasten : Wenn Sie etwas Neues aufbauen, insbesondere ereignisgesteuerte Mikrodienste oder Hintergrundaufgaben, ziehen Sie stets Serverless in Betracht.
- Überdenken Sie Ihre Datenbankentscheidungen : Wenn Sie Datenbanken haben, die 24/7 mit sehr variablen Lasten laufen, prüfen Sie die serverlosen oder Auto-Scaling-Optionen für Ihre spezifische Datenbanktechnologie.
- Automatisieren Sie die Bereinigung : Implementieren Sie automatisierte Skripte oder serverlose Funktionen, um unverbundene Speicher, alte Snapshots und andere verwaiste Ressourcen zu identifizieren und zu löschen.
- Schulen Sie Ihr Team : Fördern Sie eine Kultur des Kostenbewusstseins. Stellen Sie sicher, dass die Entwickler die finanziellen Auswirkungen ihrer Provisionierungsentscheidungen verstehen. Dies 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 mit diesen Veränderungen werden Sie nicht nur eine erhebliche Menge Geld für Ihr Unternehmen sparen, sondern auch eine agilere, resilientere und zukunftsbereite Infrastruktur aufbauen. Und ganz ehrlich, das macht Sie zu einem besseren Akteur im Technologiebereich.
Das war’s für dieses Mal. Bauen Sie weiterhin intelligent, und ich freue mich auf das nächste Mal!
🕒 Published: