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-Post-Mortems gesehen habe, als ich zugeben möchte: die unsichtbaren Kosten durch nicht optimierte Infrastruktur. Wir alle wissen, dass wir schnell bauen, schnell skalieren und Funktionen von gestern ausliefern müssen. Doch oft lassen wir in diesem Eifer eine Spur von vergessenen Ressourcen, überdimensionierten Instanzen und Services zurück, die im Autopilotmodus laufen und Rechnungen anhäufen, die wir kaum beachten, bevor die vierteljährliche Budgetüberprüfung wie ein Schlag niedergeht.
Für diesen Artikel tauche ich also kopfüber in die Kostensenkung ein, aber mit einem sehr spezifischen und passenden Blickwinkel: wie man aufhört, Geld für „ständig eingeschaltete“ Ressourcen auszugeben, die „nach Bedarf“ oder „ereignisgesteuert“ sein sollten. Wir sind im Jahr 2026, Leute. Die Tage, an denen Server auf Abruf bereitgestellt werden, sind vorbei. Wenn eure Cloud-Rechnung noch wie ein Telefonbuch aussieht, ist es Zeit zu handeln.
Der stille Killer: Immer eingeschaltet, wenn es nach Bedarf sein sollte
Seien wir realistisch. Wenn wir unter Druck stehen, ein neues Tool für die Agenten oder eine Verbesserung des Kundenservices herauszubringen, steht der Kostenfaktor oft im Hintergrund im Vergleich zur Funktionalität und Schnelligkeit. Wir provisionieren eine EC2-Instanz, die „groß genug“ ist, vielleicht sogar „ein bisschen größer für alle Fälle“. Wir starten eine Datenbank mit provisionierten IOPS, die den gesamten Internetverkehr bewältigen könnte, nur damit sie während der Ruhezeiten hauptsächlich ungenutzt bleibt. Wir vergessen, geeignete Skalierungsrichtlinien einzurichten, oder wir lassen einfach alles 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 Analyse-Dashboard eines Kunden mit eigenen Augen gesehen. Das Team, Gott segne sie, hatte ein fantastisches System aufgebaut, das den Agenten Echtzeit-Überblicke über die Interaktionen mit den Kunden gab. Es war ein riesiger Erfolg für die Performance. Aber als die erste vollständige Cloud-Rechnung eintraf, lief der Finanzdirektor fast Amok. Sie hatten einen robusten EKS-Cluster, ein paar Premium-RDS-Instanzen und eine Vielzahl von Lambda-Funktionen mit großzügigen Speicherkapazitäten provisioniert, die rund um die Uhr 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 Enterprise-Kapazitä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.
Identifiziert die Schuldigen: Wo geht wirklich euer Geld hin
Bevor ihr etwas reparieren könnt, müsst ihr wissen, was kaputt ist. Die meisten Cloud-Anbieter bieten Tools an, die euch helfen, eure Ausgaben zu visualisieren, und ihr müsst sie unbedingt nutzen. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing Reports – das sind nicht nur Sachen für die Finanzen. Sie sind eure erste Verteidigungslinie.
Die üblichen Verdächtigen
- Recheninstanzen (EC2, VMs): Dies sind oft die größten Übeltäter. Sind sie überdimensioniert? Laufen sie, wenn sie es nicht sollten? Verwendet ihr die richtige Instanzenfamilie für eure Workload?
- Datenbanken (RDS, Azure SQL, Cloud SQL): Wie bei der Berechnung können auch Datenbanken für IOPS, CPU oder Speicher überprovisioniert sein. Viele bieten inzwischen serverlose Optionen, die auf null oder nahezu null Kosten sinken, wenn sie inaktiv sind.
- Speicher (EBS-Volumes, nicht angehängte Disks): Habt ihr schon einmal eine Instanz gestartet, sie beendet, aber das zugehörige Speichervolumen einfach liegen gelassen? Das passiert öfter, als ihr denkt.
- Netzwerk (Datenübertragung, NAT Gateways): Die Kosten für Datenübertragungen können euch überraschen, insbesondere zwischen Regionen. NAT Gateways verursachen auch Kosten pro Stunde, selbst wenn sie nichts tun.
- Untergenutzte Services: Zahlt ihr für einen dedizierten Redis-Cache, der nur wenige Zugriffe pro Tag hat? Ein verwalteter Kafka-Cluster für einen Nachrichtenstrom?
Mein Kunde aus der Geschichte mit dem Analyse-Dashboard begann damit, seinen AWS Cost Explorer zu betrachten. Die größten Ausgabenpositionen waren, vorhersehbar, EC2 und RDS. Sie fanden auch ein paar EBS-Volumes, die an beendete Instanzen angehängt waren, und eine NAT Gateway in einer VPC, die nicht mehr für den Produktionsverkehr genutzt wurde. Kleinere Dinge, aber das summiert sich.
Strategien zur Umwandlung von Immer Eingeschaltet in Nach Bedarf (oder außerhalb der Spitzenzeiten)
Okay, ihr habt die Bereiche identifiziert, in denen ihr zu viel ausgebt. Kommen wir zum spaßigen Teil: das Reparieren. Das Ziel ist nicht nur, Geld zu sparen, sondern ein widerstandsfähigeres und effizienteres System zu bauen, das Ressourcen nur dann verbraucht, wenn es diese auch tatsächlich benötigt.
1. Plant das Starten/Stoppen der Instanzen
Das ist wahrscheinlich die einfachste Maßnahme für viele Anwendungen. Wenn eure internen Tools oder Staging-Umgebungen nur während der Bürozeiten genutzt werden, gibt es keinen Grund, dass sie 24/7 laufen. Die meisten Cloud-Anbieter bieten native Möglichkeiten, um die Stromzyklen der Instanzen zu planen, oder ihr könnt eure eigene Lösung mit serverlosen Funktionen erstellen.
Praktisches Beispiel: AWS EC2-Planer mit Lambda
Ihr könnt 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 zu stoppenden/startenden Instanzen 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 Instanzen zu stoppen.")
# --- Ähnliche Logik zum Starten von Instanzen zu einem späteren Zeitpunkt ---
# Ihr hättet eine andere Lambda/CloudWatch-Event zum Starten,
# oder kombiniert die Logik mit einem 'start'-Tag.
return {
'statusCode': 200,
'body': 'Planung der EC2-Instanzen abgeschlossen.'
}
Ihr solltet zwei CloudWatch-Ereignisregeln einrichten: eine, um diese Lambda auszuschalten, sagen wir mal, um 18 Uhr UTC, um die Instanzen zu stoppen, und eine andere um 7 Uhr UTC, um sie zu starten. Das kann bereits die Rechenkosten für diese spezifischen Ressourcen um mehr als 70 % senken.
2. Setzt auf Serverlosigkeit und Container-Orchestrierung
Wenn eure Workload wirklich sporadisch oder ereignisgesteuert ist, ist serverlos euer bester Verbündeter. AWS Lambda, Azure Functions, Google Cloud Functions – sie sinken auf null, wenn sie nicht genutzt werden, was bedeutet, dass ihr nur für das Rechnen zahlt, wenn euer Code tatsächlich ausgeführt wird. Das ist ein riesiger Wechsel vom „immer eingeschaltet“-Paradigma.
Für komplexere Anwendungen, die weiterhin persistente Services benötigen, aber eine schwankende Nachfrage haben, sind Container-Orchestrierungsplattformen wie Kubernetes (EKS, AKS, GKE) in Kombination mit intelligenter Skalierung sehr leistungsstark. Die Horizontal Pod Autoscalers (HPA) können die Größe eurer Anwendungspods basierend auf der CPU-Nutzung oder benutzerdefinierten Metriken variieren. Die Cluster Autoscalers können sogar Knoten zu eurem 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 pro Tag angefordert wurden. Anstelle einer dedizierten EC2-Instanz, die einen Cron-Job ausführt, wurde eine Lambda-Funktion durch ein S3-Ereignis (neue Dateien hochgeladen) oder eine API-Gateway-Anfrage ausgelöst. Die Einsparungen waren sofort und erheblich.
3. Dimensioniert eure Datenbanken richtig mit Serverlosigkeit oder Auto-Scaling
Datenbanken sind oft problematisch, da die Persistenz der Daten entscheidend ist. Allerdings bieten viele moderne Datenbanken serverlose oder Auto-Scaling-Optionen, die vor einigen Jahren noch 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 Hunderte, und Sie zahlen nur für das, was Sie tatsächlich verwenden. Es ist nicht mehr nötig, Spitzenkapazitäten zu provisionieren, während Sie die meiste Zeit unter Last laufen.
- Azure SQL Database Serverless : Ähnlich wie Aurora Serverless passt es sich automatisch an die Berechnungskapazität an und pausiert, wenn es inaktiv ist, wodurch erhebliche Einsparungen bei intermittierenden Workloads erzielt werden.
- DynamoDB On-Demand : Für NoSQL-Workloads bedeutet der On-Demand-Kapazitätsmodus von DynamoDB, dass Sie pro Anfrage bezahlen, ohne Leistungs- und Schreibkapazitäts-Einheiten provisionieren zu müssen. Optimal für unvorhersehbare Verkehrsmodelle.
Das Analytik-Dashboard verwendete ursprünglich eine leistungsstarke RDS PostgreSQL-Instanz mit provisionierten IOPS. Nach der Migration zu Aurora Serverless v2 sanken ihre Datenbankkosten um fast 60 %, einfach weil sie nicht mehr überlastet liefen, während der Stoßzeiten.
4. Bereinigen Sie ungenutzte Speicher 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 handelt. Das gleiche gilt für Snapshots – sie häufen sich schnell an und können teuer werden.
Praktisches Beispiel: Finden und Löschen von ungenutzten EBS-Volumes (AWS CLI)
Sie können die AWS CLI verwenden, um ungenutzte Volumes zu finden und zu löschen. Es ist eine häufige Reinigungsaufgabe.
# Alle ungenutzten 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, ES 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 entdeckte mehrere Terabytes alter ungenutzter EBS-Volumes und Hunderte veralteter Snapshots. Deren Löschung führte zu Einsparungen von mehreren hundert Dollar bei ihrer monatlichen Rechnung – das ist zwar nicht viel, aber jeder kleine Beitrag zählt.
5. Optimieren Sie die Netzwerk Kosten
NAT-Gateways sind großartig, um Instanzen in privaten Subnetzen den Zugang zum Internet zu ermöglichen, aber sie verursachen stündliche Gebühren und Datenverarbeitungskosten. 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-Endpoints : Um auf AWS-Dienste wie S3 oder DynamoDB von Ihrem VPC aus zuzugreifen, verwenden Sie VPC-Endpoints. Der Datenverkehr fließt privat innerhalb des AWS-Netzwerks, wodurch die Kosten der NAT-Gateways vermieden werden und eine bessere Sicherheit gewährleistet ist.
Wir haben festgestellt, dass der Kunde ein NAT-Gateway in jeder AZ hatte, obwohl seine Hauptanwendung nur in zweien lief. Sie konnten konsolidieren und so Einsparungen erzielen und haben anschließend VPC-Endpoints für den Zugriff auf S3 implementiert, wodurch die Kosten für die Datenverarbeitung über das NAT-Gateway gesenkt wurden.
Maßnahmen für Ihren nächsten Sprint
Es geht nicht nur um Kostensenkung; es geht darum, intelligentere und effizientere Systeme zu schaffen, die intrinsisch kostensensibel sind. Hier sind einige Dinge, die Sie noch heute tun können:
- Überprüfen Sie regelmäßig Ihre Cloud-Rechnung : Machen Sie es sich zur Gewohnheit. Nutzen Sie die Cost-Management-Tools Ihres Cloud-Anbieters. Geben Sie es nicht nur den Finanzen weiter. Verstehen Sie, wo jeder Dollar hingeht.
- Taggen Sie alles : Dies ist nicht verhandelbar. Taggen Sie die Ressourcen nach Projekt, Eigentümer, Umgebung (dev, staging, prod) und ob sie für eine Stilllegung geplant werden können. Das erleichtert erheblich die Identifizierung und Automatisierung.
- Priorisieren Sie die Planung für nicht-produktive Umgebungen : Staging-, Dev- und QA-Umgebungen eignen sich ideal für geplante Stilllegungen 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 entwickeln, insbesondere ereignisbasierte Mikrodienste oder Hintergrundaufgaben, ziehen Sie immer zuerst serverless in Betracht.
- Bewerten Sie Ihre Datenbankentscheidungen neu : 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 Reinigung : Implementieren Sie automatisierte Skripte oder serverless Funktionen, um ungenutzte Speichervolumes, alte Snapshots und andere verwaiste Ressourcen zu identifizieren und zu löschen.
- Schulen Sie Ihr Team : Fördern Sie eine Kostenbewusstseinskultur. Stellen Sie sicher, dass die Entwickler die finanziellen Auswirkungen ihrer Provisionierungsentscheidungen verstehen. Es ist nicht mehr nur ein Betriebsproblem.
Die Verschwendung durch “Immer aktiv”-Ressourcen zu stoppen, ist keine einmalige Lösung; es ist eine fortlaufende Disziplin. Aber indem Sie diese Änderungen vornehmen, sparen Sie nicht nur einen erheblichen Geldbetrag für Ihr Unternehmen, sondern bauen auch eine agilere, widerstandsfähigere und zukunftssichere Infrastruktur auf. Und ehrlich gesagt, macht es Sie zu einem besseren Akteur im Technologiebereich.
Das war’s für diesmal. Machen Sie weiter und bauen Sie intelligent, und ich sehe Sie beim nächsten Mal wieder!
🕒 Published: