Hallo zusammen, Jules Martin hier, zurück auf agntmax.com. Ich hoffe, es geht euch allen gut. Heute möchte ich über etwas sprechen, was mich in letzter Zeit beschäftigt, etwas, das ich in mehr Gesprächen und Projekt-Podcasts gesehen habe, als ich zugeben möchte: die unsichtbaren Kosten von nicht optimierter Infrastruktur. Wir alle wissen, dass wir schnell bauen, schnell skalieren und Funktionen gestern bereitstellen müssen. Aber oft hinterlassen wir in diesem Eifer eine Spur von vergessenen Ressourcen, überdimensionierten Instanzen und Diensten, die im Autopilot-Modus laufen, und sammeln Rechnungen an, die wir kaum einen Blick werfen, bevor die vierteljährliche Budgetüberprüfung wie ein Schock kommt.
Für diesen Artikel tauche ich kopfüber in die Kostenoptimierung ein, aber mit einem sehr spezifischen und zeitgerechten Blickwinkel: wie man aufhört, Geld für „immer eingeschaltete“ Ressourcen auszugeben, die „on-demand“ oder „ereignisgesteuert“ sein sollten. Wir sind im Jahr 2026, Leute. Die Tage von der Bereitstellung nach Bedarf für Server sind vorbei. Wenn eure Cloud-Rechnung immer noch wie ein Telefonbuch aussieht, wird es Zeit, einzugreifen.
Der stille Killer: Immer eingeschaltet, 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 bereitzustellen, rückt der Preis oft in den Hintergrund gegenüber der Funktionalität und 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 provisionierten IOPS, die das gesamte Internet bewältigen könnte, nur damit sie hauptsächlich in den Stoßzeiten ungenutzt bleibt. Wir vergessen, angemessene Skalierungsrichtlinien zu konfigurieren, oder wir lassen die Dinge einfach 24/7 laufen, weil es nun einmal einfacher ist, sich nicht darum zu kümmern.
Ich habe das vor ein paar Monaten mit dem neuen internen Analyse-Dashboard eines Kunden gesehen. Das Team, Gott segne sie, hatte ein fantastisches System aufgebaut, das den Agenten Echtzeit-Einblicke in die Interaktionen mit Kunden bot. Es war ein riesiger Sieg für die Leistung. Doch als die erste vollständige Cloud-Rechnung eintraf, hätte der Finanzdirektor fast einen Herzinfarkt bekommen. Sie hatten einen robusten EKS-Cluster, einige hochwertige RDS-Instanzen und eine Vielzahl von Lambda-Funktionen mit großzügigen Arbeitsspeicherzuweisungen bereitgestellt, die alle ununterbrochen liefen. Das Beste daran? Das Dashboard wurde hauptsächlich von den Agenten während der Bürozeiten genutzt, von 9 bis 17 Uhr, von Montag bis Freitag. Davor war es eine Geisterstadt.
Sie zahlten für Unternehmenskapazität für ein System, das effektiv 70 % der Woche inaktiv war. Es ist wie das Kaufen eines Formel-1-Autos, um einmal die Woche zum Supermarkt zu fahren.
Identifizieren Sie die Übeltäter: 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, die Ihnen helfen, Ihre Ausgaben zu visualisieren, und Sie sollten sie dringend nutzen. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing Reports – diese sind nicht nur für die Finanzen. Sie sind Ihre erste Verteidigungslinie.
Die üblichen Verdächtigen
- Berechnungsinstanzen (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 der Berechnung können Datenbanken für IOPS, CPU oder Arbeitsspeicher überprovisioniert sein. Viele bieten mittlerweile serverlose Optionen, die auf null oder nahezu null Kosten sinken, während sie inaktiv sind.
- Speicher (EBS-Volumes, unverbundene Festplatten): Haben Sie jemals eine Instanz gestartet, sie beendet, aber das zugehörige Speicher-Volume liegen gelassen? Das passiert häufiger, als Sie denken.
- Netzwerken (Datenübertragung, NAT-Gateways): Die Kosten für Datenübertragung können Sie überraschen, besonders zwischen Regionen. NAT-Gateways haben auch einen Stundensatz, selbst wenn sie nichts tun.
- Untergenutzte Dienste: Zahlen Sie für einen dedizierten Redis-Cache, der nur ein paar Zugriffe pro Tag hat? Ein verwalteter Kafka-Cluster für eine Nachrichtenübermittlung?
Mein Kunde mit der Analyse-Dashboard-Geschichte begann damit, seinen AWS Cost Explorer zu überprüfen. Die größten Ausgabenpositionen 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. Kleinigkeiten, aber das summiert sich.
Strategien, um Immer Eingeschaltet zu On-Demand (oder Außerhalb der Spitzenzeiten) zu verwandeln
Okay, Sie haben die Bereiche identifiziert, in denen Sie zu viel ausgeben. Lassen Sie uns zum unterhaltsamen Teil übergehen: das zu beheben. Das Ziel ist nicht nur, Geld zu sparen, sondern ein widerstandsfähigeres und effizienteres System aufzubauen, 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, warum sie 24/7 laufen sollten. Die meisten Cloud-Anbieter bieten native Möglichkeiten, die Stromversorgung 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 Codes der Lambda-Funktion (Python):
import boto3
def lambda_handler(event, context):
ec2 = boto3.client('ec2')
# Tags festlegen, um die Instanzen zu identifizieren, die gestoppt/getart 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"Stoppe die Instanzen: {stop_instance_ids}")
ec2.stop_instances(InstanceIds=stop_instance_ids)
else:
print("Keine Instanz zu stoppen.")
# --- Ähnliche Logik für das Starten von Instanzen zu einem anderen Zeitpunkt ---
# Sie könnten eine andere Lambda/CloudWatch-Ereignis zum Starten haben,
# oder die Logik mit einem 'start'-Tag kombinieren.
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 stoppen, und eine andere um 7 Uhr UTC, um sie zu starten. Dies allein kann die Rechenkosten für diese spezifischen Ressourcen um mehr als 70 % senken.
2. Setzen Sie auf Serverlos und Container-Orchestrierung
Wenn Ihre Arbeitslast wirklich sporadisch oder ereignisgesteuert ist, ist serverlos Ihr bester Verbündeter. AWS Lambda, Azure Functions, Google Cloud Functions – sie reduzieren sich auf null, wenn sie nicht genutzt werden, was bedeutet, dass Sie nur für die Berechnung zahlen, wenn Ihr Code tatsächlich ausgeführt wird. Das ist ein enormer Wandel vom „immer eingeschaltet“-Paradigma.
Für komplexere Anwendungen, die immer noch persistent Dienste benötigen, aber schwankende Nachfrage haben, sind Container-Orchestrierungsplattformen wie Kubernetes (EKS, AKS, GKE) in Kombination mit intelligentem Scaling sehr leistungsstark. Die Horizontal Pod Autoscaler (HPA) können die Größe Ihrer Anwendungs-Pods basierend auf der CPU-Nutzung oder benutzerdefinierten Metriken anpassen. Die Cluster Autoscaler können sogar Knoten zu Ihrem Cluster hinzufügen oder entfernen, je nach Nachfrage.
Mein Kunde hat Teile seines Analyse-Dashboards so refaktoriert, dass Lambda genutzt wird, 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 signifikant.
3. Dimensionieren Sie Ihre Datenbanken korrekt mit Serverlos oder Auto-Scaling
Datenbanken sind oft problematisch, da die Persistenz von Daten entscheidend ist. Viele moderne Datenbanken bieten jedoch serverlose oder auto-scaling Optionen an, die vor einigen Jahren nicht weit verbreitet waren.
- AWS Aurora Serverless v2 : Das ist eine wesentliche Veränderung. Es passt die Kapazität entsprechend 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 verwenden. Sie müssen keine Spitzenkapazitäten vorsehen, 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 für intermittierende Workloads erhebliche Einsparungen bringt.
- DynamoDB On-Demand : Für NoSQL-Workloads bedeutet der On-Demand-Kapazitätsmodus von DynamoDB, dass Sie pro Anfrage bezahlen, ohne Kapazitätseinheiten für Lese-/Schreibvorgänge 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 es während der Nebenzeiten nicht mehr konstant lief.
4. Bereinigen Sie Unverbundene Speicher und Snapshots
Es mag grundlegend erscheinen, aber es ist eine ständige Quelle für 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-Wurzelvolumen handelte. Gleiches gilt für Snapshots – sie häufen sich schnell an und können teuer werden.
Praktisches Beispiel: Finden und Löschen von Unverbundenen EBS-Volumes (AWS CLI)
Sie können die AWS CLI verwenden, um unverbundene Volumes zu finden und zu löschen. Das ist eine gängige Bereinigungsaufgabe.
# Listet alle unverbundenen Volumes auf
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 UNRÜCKGÄNGIG)
# 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 entdeckte mehrere Terabyte alter unverbundener EBS-Volumes und Hunderte veralteter Snapshots. Das Löschen dieser brachte einige Hundert Dollar auf ihrer Monatsrechnung ein – es ist nicht viel, aber jeder kleine Schritt zählt.
5. Optimieren Sie die Netzwerkkosten
NAT-Gateways sind großartig, um Instanzen in privaten Subnetzen den Zugang zum Internet zu ermöglichen, bringen jedoch stündliche Gebühren und Datenverarbeitungsgebühren mit sich. Wenn Sie mehrere NAT-Gateways in verschiedenen Verfügbarkeitszonen haben, aber nur eines aktiv genutzt wird, zahlen Sie für redundante Gateways.
- Fassen Sie die NAT-Gateways zusammen : 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 verläuft privat innerhalb des AWS-Netzwerks, wodurch Kosten für 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 betrieb. Sie konnten konsolidieren und dadurch Einsparungen erzielen und implementierten dann VPC-Endpunkte für den Zugriff auf S3, was die Kosten für die Datenverarbeitung ü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 zu bauen, die intrinsisch kostenbewusst sind. Hier sind einige Dinge, die Sie noch heute tun können:
- Überprüfen Sie regelmäßig Ihre Cloud-Rechnung : Machen Sie es zu einer Gewohnheit. Verwenden Sie die Kostenmanagement-Tools Ihres Cloud-Anbieters. Überlassen Sie es nicht nur den Finanzen. Verstehen Sie, wohin jeder Dollar geht.
- Taggen Sie alles : Das ist nicht verhandelbar. Taggen Sie Ressourcen nach Projekt, Eigentümer, 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 : Die Staging-, Entwicklungs- und QA-Umgebungen sind ideale Kandidaten für die geplante Abschaltung außerhalb der Bürozeiten. Dies ist in der Regel die einfachste und schnellste Einsparung.
- Bewerten Sie Serverless für neue Workloads : Wenn Sie etwas Neues bauen, insbesondere eventbasierte Mikrodienste oder Hintergrundjobs, sollten Sie immer zuerst Serverless in Betracht ziehen.
- Überdenken Sie Ihre Datenbankwahl : Wenn Sie Datenbanken haben, die rund um die Uhr mit sehr variablen Lasten laufen, prüfen Sie serverlose oder auto-skalierende 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.
- Bildung Ihrer Teams : Fördern Sie eine Kostenbewusstseinskultur. Stellen Sie sicher, dass die Entwickler die finanziellen Implikationen ihrer Bereitstellungsentscheidungen verstehen. Es ist nicht mehr nur ein Problem der IT-Abteilung.
Das Stoppen von Verlusten durch „immer aktive“ Ressourcen ist keine einmalige Lösung; es ist eine kontinuierliche Disziplin. Aber durch diese Veränderungen sparen Sie nicht nur einen bedeutenden Geldbetrag für Ihr Unternehmen, sondern bauen auch eine agilere, widerstandsfähigere und zukunftsfähige Infrastruktur auf. Und ganz ehrlich, das macht Sie zu einem besseren Akteur im Technologiebereich.
Das war’s für diesmal. Weiterhin intelligent bauen, und ich sehe Sie beim nächsten Mal!
🕒 Published: