Hallo zusammen, hier ist Jules Martin, zurück von agntmax.com. Ich hoffe, euch geht es 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 unsichtbare Belastung durch unoptimierte Infrastrukturkosten. Wir wissen alle, dass wir schnell bauen, rasch skalieren und Funktionen von gestern liefern müssen. Aber oft hinterlassen wir in diesem Wettlauf eine Spur aus vergessenen Ressourcen, überdimensionierten Instanzen und Diensten, die im Autopilot-Modus laufen und Rechnungen anhäufen, auf die wir kaum einen Blick werfen, bis die vierteljährliche Budgetüberprüfung wie ein Schlag ins Gesicht trifft.
Für dieses Stück tauche ich kopfüber in Kostenoptimierung ein, aber mit einem ganz bestimmten, zeitgemäßen Fokus: wie man aufhört, Geld für “immer laufende” Ressourcen zu verschwenden, die “nach Bedarf” oder “ereignisgesteuert” sein sollten. Es ist 2026, Leute. Die Zeiten der ‘Set and Forget’-Serverbereitstellung sind lange vorbei. Wenn eure Cloud-Rechnung immer noch wie ein Telefonbuch aussieht, ist es Zeit für eine Intervention.
Der stille Killer: Immer-Laufend, wenn es nach Bedarf sein sollte
Seien wir ehrlich. Wenn wir unter Druck stehen, ein neues agentenorientiertes Tool oder eine Verbesserung des Kundenservices auszuliefern, hat die Kosteneffektivität oft nicht die höchste Priorität im Vergleich zu Funktionalität und Geschwindigkeit. Wir richten eine EC2-Instanz ein, 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 um festzustellen, dass sie während der Nebensaison weitgehend ungenutzt bleibt. Wir vergessen, angemessene Skalierungspolitiken einzurichten, oder lassen einfach alles 24/7 laufen, denn, naja, das ist einfacher, als darüber nachzudenken.
Vor einigen Monaten habe ich das aus erster Hand bei einem neuen internen Analyse-Dashboard eines Kunden gesehen. Das Team, die Guten, hatte ein fantastisches System aufgebaut, das den Agenten Echtzeiteinblicke in Kundeninteraktionen gab. Es war ein großer Erfolg für die Leistung. Aber als die erste vollständige Cloud-Rechnung eintrudelte, hatte der CFO fast einen Herzinfarkt. Sie hatten ein kräftiges EKS-Cluster, ein paar hochmoderne RDS-Instanzen und eine ganze Reihe von Lambda-Funktionen mit großzügigen Speicherkapazitäten bereitgestellt, die nonstop liefen. Der Clou? Das Dashboard wurde hauptsächlich von den Agenten während der Geschäftszeiten genutzt, von 9 bis 17 Uhr, Montag bis Freitag. Außerhalb dieser Zeiten war es eine Geisterstadt.
Sie zahlten für eine Unternehmenslösung für ein System, das effektiv 70% der Woche untätig war. Das ist so, als würde man ein Formel-1-Auto kaufen, um einmal pro Woche zum Supermarkt zu fahren.
Die Schuldigen identifizieren: Wohin fließt Ihr Geld wirklich?
Bevor du etwas reparieren kannst, musst du wissen, was kaputt ist. Die meisten Cloud-Anbieter bieten Werkzeuge an, um deine Ausgaben zu visualisieren, und du musst sie unbedingt nutzen. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing-Berichte – das sind nicht nur für die Finanzabteilung. Sie sind deine erste Verteidigungslinie.
Die üblichen Verdächtigen
- Compute-Instanzen (EC2, VMs): Diese sind oft die größten Übeltäter. Sind sie überdimensioniert? Laufen sie, wenn sie nicht sollten? Verwendest du die richtige Instanzfamilie für deine Arbeitslast?
- Datenbanken (RDS, Azure SQL, Cloud SQL): Ähnlich wie bei Compute können Datenbanken für IOPS, CPU oder Speicher übermäßig bereitgestellt sein. Viele bieten jetzt serverlose Optionen an, die auf null oder nahezu null Kosten skalieren, wenn sie untätig sind.
- Speicher (EBS-Volumes, nicht angeschlossene Laufwerke): Hast du jemals eine Instanz gestartet, sie beendet, aber das zugehörige Speichervolumen weiterhin herumliegen lassen? Das passiert häufiger als du denkst.
- Netzwerk (Datenübertragung, NAT-Gateways): Datenübertragungskosten können sich heimlich erhöhen, besonders über Regionen hinweg. NAT-Gateways haben auch eine stündliche Gebühr, selbst wenn sie nichts tun.
- Unterausgelastete Dienste: Zählst du dafür, dass du für einen dedizierten Redis-Cache zahlst, der nur ein paar Zugriffe pro Tag erhält? Ein verwalteter Kafka-Cluster für einen Strom von Nachrichten?
Mein Kunde aus der Analyse-Dashboard-Geschichte begann damit, seinen AWS Cost Explorer zu betrachten. Die größten Posten 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, das nicht mehr aktiv für Produktionsverkehr genutzt wurde. Kleine Dinge, aber sie summieren sich.
Strategien, um Immer-Laufend in Nach Bedarf (oder außerhalb der Spitzenzeiten) zu verwandeln
Okay, du hast also die Bereiche identifiziert, in denen du zu viel ausgibst. Jetzt kommt der spaßige Teil: Es zu beheben. Das Ziel ist nicht nur, Geld zu sparen, sondern ein widerstandsfähigeres, effizienteres System zu schaffen, das nur dann Ressourcen verbraucht, wenn es diese wirklich benötigt.
1. Planung von Instanzstart/-stopp
Das ist wahrscheinlich das am einfachsten umzusetzen für viele Anwendungen. Wenn deine internen Tools oder Staging-Umgebungen nur während der Geschäftszeiten verwendet werden, gibt es keinen Grund, dass sie 24/7 laufen. Die meisten Cloud-Anbieter bieten native Möglichkeiten, um Instanz-Stromzyklen zu planen, oder du kannst deine eigenen mit serverlosen Funktionen erstellen.
Praktisches Beispiel: AWS EC2 Scheduler mit Lambda
Du kannst eine einfache Lambda-Funktion erstellen, die von CloudWatch-Events (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')
# Definiere Tags, um Instanzen zum Stoppen/Starten zu identifizieren
# Zum Beispiel: 'Schedule': 'business-hours'
# Hole alle laufenden Instanzen mit dem 'Schedule'-Tag, der auf 'business-hours' gesetzt ist
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 Instanzen: {stop_instance_ids}")
ec2.stop_instances(InstanceIds=stop_instance_ids)
else:
print("Keine Instanzen zum Stoppen.")
# --- Ähnliche Logik für den Start von Instanzen zu einem anderen Zeitpunkt ---
# Du würdest ein weiteres Lambda/CloudWatch-Event für den Start haben,
# oder die Logik mit einem 'start'-Tag kombinieren.
return {
'statusCode': 200,
'body': 'EC2-Instanzplanung abgeschlossen.'
}
Du würdest zwei CloudWatch-Event-Regeln einrichten: eine, um dieses Lambda beispielsweise um 18 Uhr UTC zum Stoppen von Instanzen auszulösen, und eine weitere um 7 Uhr UTC, um sie zu starten. Das allein kann die Compute-Kosten für diese spezifischen Ressourcen um über 70% senken.
2. Serverless und Container-Orchestrierung annehmen
Wenn deine Arbeitslast wirklich sporadisch oder ereignisgesteuert ist, ist serverless dein bester Freund. AWS Lambda, Azure Functions, Google Cloud Functions – sie skalieren auf Null, wenn sie nicht in Gebrauch sind, was bedeutet, dass du nur für Compute zahlst, wenn dein Code tatsächlich läuft. Das ist ein massiver Shift von dem “immer-laufend”-Paradigma.
Für komplexere Anwendungen, die noch persistente Dienste benötigen, aber schwankende Nachfrage haben, sind Container-Orchestrierungsplattformen wie Kubernetes (EKS, AKS, GKE) in Kombination mit intelligenter automatischer Skalierung mächtig. Horizontal Pod Autoscalers (HPA) können deine Anwendungs-Pods basierend auf der CPU-Auslastung oder benutzerdefinierten Metriken hoch- und runter skalieren. Cluster-Autoscaler können sogar Knoten von deinem Cluster hinzufügen oder entfernen, wenn sich die Nachfrage ändert.
Mein Kunde hat Teile seines Analyse-Dashboards umgebaut, um Lambda für die Erstellung bestimmter Berichte zu verwenden, die nur ein paar Mal am Tag angefordert werden. Statt einer dedizierten EC2-Instanz, die einen Cron-Job ausführt, wurde eine Lambda-Funktion durch ein S3-Ereignis (neue Daten hochgeladen) oder eine API-Gateway-Anfrage ausgelöst. Die Kosteneinsparungen waren sofort und erheblich.
3. Datenbanken richtig dimensionieren mit Serverless oder automatischer Skalierung
Datenbanken sind oft knifflig, denn Datenpersistenz ist kritisch. Viele moderne Datenbanken bieten jedoch serverlose oder automatische Skalierungsoptionen an, die vor einigen Jahren nicht weit verbreitet waren.
- AWS Aurora Serverless v2: Das ist eine bedeutende Veränderung. Es skaliert die Kapazität basierend auf der tatsächlichen Nutzung, von Bruchteilen einer ACU (Aurora Capacity Unit) bis hin zu Hunderten, und du zahlst nur für das, was du benutzt. Kein Provisionieren mehr für Spitzenkapazität, wenn du die meiste Zeit bei der Grundlast unterwegs bist.
- Azure SQL Database Serverless: Ähnlich wie Aurora Serverless, skaliert es die Compute-Kapazität automatisch und pausiert, wenn es inaktiv ist, was erhebliche Kosten für intermittierende Arbeitslasten spart.
- DynamoDB On-Demand: Für NoSQL-Arbeitslasten bedeutet der On-Demand-Kapazitätsmodus von DynamoDB, dass du pro Anfrage zahlst, ohne dass du Lese-/Schreibkapazitätseinheiten bereitstellen musst. Perfekt für unvorhersehbare Verkehrsströme.
Das Analyse-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 nicht mehr zu Höchstzeiten außerhalb der Arbeitszeiten lief.
4. Unangeschlossenen Speicher und Snapshots bereinigen
Das klingt einfach, ist aber eine ständige Quelle für verschwendetes Geld. Wenn du eine EC2-Instanz beendest, wird ihr zugehöriges EBS-Volume nicht immer standardmäßig gelöscht, insbesondere wenn es sich um ein nicht-stammendes Volume handelt. Das Gleiche gilt für Snapshots – sie sammeln sich schnell an und können teuer werden.
Praktisches Beispiel: Finden und Löschen von unangeschlossenen EBS-Volumes (AWS CLI)
Du kannst die AWS CLI verwenden, um unangeschlossene Volumes zu finden und sie zu löschen. Das 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 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 hoch- und herunterschrauben. Der Kunde fand mehrere Terabyte an alten, nicht angeschlossenen EBS-Volumes und Hunderte veralteter Snapshots. Das Löschen dieser Volumes sparte einige hundert Dollar von ihrer monatlichen Rechnung – nicht viel, aber jeder Cent 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 Kosten und Gebühren für die Datenverarbeitung. Wenn Sie mehrere NAT-Gateways in verschiedenen Verfügbarkeitszonen haben, aber nur eines aktiv genutzt wird, zahlen Sie für redundante.
- NAT-Gateways konsolidieren: Wenn Ihre Architektur es erlaubt, konsolidieren Sie auf weniger NAT-Gateways.
- VPC-Endpunkte: Zum Zugriff auf AWS-Dienste wie S3 oder DynamoDB von innerhalb Ihrer VPC verwenden Sie VPC-Endpunkte. Der Datenverkehr fließt privat innerhalb des AWS-Netzwerks, vermeidet die Kosten für NAT-Gateways und bietet bessere Sicherheit.
Wir stellten fest, dass der Kunde in jeder AZ ein NAT-Gateway hatte, obwohl ihre Hauptanwendung nur in zwei lief. Sie konnten konsolidieren und dort etwas sparen, und später implementierten sie VPC-Endpunkte für den S3-Zugriff, was die Kosten für die Datenverarbeitung über das NAT-Gateway senkte.
Handlungsorientierte Erkenntnisse für Ihr nächstes Sprint
Es geht nicht nur darum, Kosten zu senken; es geht darum, intelligentere, effizientere Systeme aufzubauen, die von Natur aus kostenbewusst sind. Hier ist, was Sie noch heute anfangen können:
- Überprüfen Sie regelmäßig Ihre Cloud-Rechnung: Machen Sie es sich zur Gewohnheit. Nutzen Sie die kostenspezifischen Management-Tools Ihres Cloud-Anbieters. Überlassen Sie es nicht einfach der Finanzabteilung. Verstehen Sie, wohin jeder Dollar fließt.
- Alles taggen: Das ist nicht verhandelbar. Taggen Sie Ressourcen nach Projekt, Besitzer, Umgebung (dev, staging, prod) und ob sie für eine Abschaltung geplant werden können. Dies erleichtert die Identifizierung und Automatisierung ungemein.
- Planung für Nicht-Produktionsumgebungen priorisieren: Staging-, Dev- und QA-Umgebungen sind hervorragende Kandidaten für geplante Abschaltungen außerhalb der Geschäftszeiten. Dies ist normalerweise der einfachste und schnellste Gewinn.
- Bewerten Sie Serverless für neue Workloads: Wenn Sie etwas Neues entwickeln, insbesondere eventgesteuerte Microservices oder Hintergrundaufgaben, ziehen Sie immer zuerst Serverless in Betracht.
- Überprüfen Sie Ihre Datenbankwahl: Wenn Sie Datenbanken haben, die 24/7 mit stark variierenden Lasten laufen, untersuchen Sie Serverless- oder Auto-Scaling-Optionen für Ihre spezifische Datenbanktechnologie.
- Automatisieren Sie die Bereinigung: Implementieren Sie automatisierte Skripte oder serverlose Funktionen, um nicht angeschlossene Speicher-Volumes, alte Snapshots und andere verwaiste Ressourcen zu identifizieren und zu löschen.
- Bildung Ihres Teams: Fördern Sie eine Kultur der Kostenbewusstheit. Stellen Sie sicher, dass Entwickelnde die Kostenimplikationen ihrer Bereitstellungsentscheidungen verstehen. Es ist mittlerweile nicht mehr nur ein Problem der IT.
Das Stoppen des Kostenflusses von „always-on“ Ressourcen ist keine einmalige Lösung; es ist eine fortlaufende Disziplin. Aber durch diese Veränderungen sparen Sie nicht nur Ihrem Unternehmen eine erhebliche Menge Geld, sondern bauen auch eine agileren, widerstandsfähigeren und zukunftssicheren Infrastruktur auf. Und ganz ehrlich, das macht Sie einfach zu einem besseren Akteur im Technologiebereich.
Das war’s diesmal von mir. Bleiben Sie clever beim Bauen, und wir sehen uns beim nächsten Mal!
🕒 Published: