Meine versteckten Infrastrukturkosten belasteten mein Budget.

Hallo zusammen, hier ist Jules Martin, zurück auf agntmax.com. Ich hoffe, es läuft bei euch gut. Heute möchte ich über etwas sprechen, das mich in letzter Zeit beschäftigt, etwas, das ich in mehr Gesprächen und Projektanalysen gesehen habe, als ich zugeben möchte: die unsichtbaren Kosten einer nicht optimierten Infrastruktur. Wir alle wissen, dass wir schnell bauen, schnell skalieren und Funktionen von gestern liefern müssen. Aber oft lassen wir in diesem verrückten Wettlauf eine Spur von vergessenen Ressourcen, überdimensionierten Instanzen und Diensten, die im Autopilot-Modus laufen, zurück, und sammeln Rechnungen an, die wir kaum beachten, bis die vierteljährliche Budgetüberprüfung wie ein Donnerschlag kommt.

Für diesen Artikel tauche ich tief ein in die Kostenoptimierung, aber mit einem sehr spezifischen und zeitgemäßen Ansatz: wie man aufhört, Geld für „immer aktive“ Ressourcen auszugeben, die „nach Bedarf“ oder „ereignisgesteuert“ sein sollten. Wir sind im Jahr 2026, Freunde. Die Tage, an denen man Server im „einrichten und vergessen“-Modus provisioniert, sind vorbei. Wenn eure Cloud-Rechnung immer noch wie ein Telefonbuch aussieht, ist es Zeit zu handeln.

Der stille Killer: Immer aktiv, obwohl es nach Bedarf sein sollte

Seien wir realistisch. Wenn wir unter Druck stehen, ein neues Tool für Agenten oder eine Verbesserung des Kundenservice herauszubringen, nimmt die Kostenfrage oft einen Platz im Hintergrund im Vergleich zu Funktionalität und Geschwindigkeit ein. Wir provisionieren eine EC2-Instanz, die „groß genug“ ist, vielleicht sogar „ein bisschen größer für den Fall der Fälle.“ Wir starten eine Datenbank mit provisionierten IOPS, die das gesamte Internet bewältigen könnte, nur damit sie während der Nebensaison hauptsächlich ungenutzt bleibt. Wir vergessen, geeignete Skalierungsrichtlinien einzurichten, oder lassen einfach alles 24/7 laufen, weil es nun mal einfacher ist, nicht darüber nachzudenken.

Ich habe das vor ein paar 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-Einblicke in die Interaktionen mit den Kunden gab. Es war ein riesiger Erfolg für die Performance. Aber als die erste Cloud-Rechnung kam, hätte der CFO fast einen Herzinfarkt bekommen. Sie hatten ein robustes EKS-Cluster, einige hochpreisige RDS-Instanzen und eine ganze Reihe von Lambda-Funktionen mit großzügigen Speicherkapazitäten provisioniert, die alle ununterbrochen liefen. Der Haken? Das Dashboard wurde hauptsächlich von 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 eine Unternehmenskapazität für ein System, das effektiv 70 % der Woche inaktiv war. Es ist, als würde man ein Formel-1-Auto kaufen, um einmal pro Woche zum Supermarkt zu fahren.

Die Schuldigen identifizieren: Wo geht Ihr Geld wirklich hin

Bevor Sie irgendetwas reparieren können, müssen Sie wissen, was nicht stimmt. Die meisten Cloud-Anbieter bieten Tools an, um Ihnen zu 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 für die Finanzen. Sie sind Ihre erste Verteidigungslinie.

Die typischerweise beteiligten Verdächtigen

• Recheninstanzen (EC2, VMs): Diese sind oft die größten Übeltäter. Sind sie überdimensioniert? Laufen sie, wenn sie nicht laufen müssen? Verwenden Sie die richtige Instanzfamilie für Ihre Arbeitslast?
• Datenbanken (RDS, Azure SQL, Cloud SQL): Wie beim Rechnen können auch Datenbanken in IOPS, CPU oder Speicher überprovisioniert sein. Viele serverlose Optionen sind mittlerweile verfügbar, die auf null oder fast null sinken, wenn sie inaktiv sind.
• Speicher (EBS-Volumes, abgetrennte Festplatten): Haben Sie jemals eine Instanz gestartet, sie beendet, aber das zugehörige Speichervolumen herumliegen lassen? Das passiert öfter, als Sie denken.
• Netzwerk (Datenübertragung, NAT-Gateways): Die Kosten für die Datenübertragung können Sie überraschen, besonders 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 eine Nachrichtenwarteschlange?

Mein Kunde aus der Geschichte des Analyse-Dashboards begann damit, seinen AWS Cost Explorer zu überprüfen. Die größten Posten waren, wenig überraschend, EC2 und RDS. Sie fanden auch einige EBS-Volumes, die an beendete Instanzen angehängt waren, und ein NAT-Gateway in einem VPC, das nicht mehr aktiv für den Produktionsverkehr genutzt wurde. Kleine Dinge, aber es summiert sich.

Strategien zur Transformation von Immer-Aktiv in Nach Bedarf (oder außerhalb der Spitzenzeiten)

Okay, Sie haben die Bereiche identifiziert, in denen Sie zu viel ausgeben. Jetzt kommt der spaßige Teil: es zu reparieren. Das Ziel ist nicht nur, Geld zu sparen, sondern ein widerstandsfähigeres und effizienteres System zu schaffen, das Ressourcen nur dann verbraucht, wenn es sie tatsächlich benötigt.

1. Planen Sie das Starten/Stoppen von Instanzen

Das ist wahrscheinlich die am leichtesten erreichbare Frucht für viele Anwendungen. Wenn Ihre 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 Sie können Ihre eigene Lösung mit serverlosen Funktionen erstellen.

Praktisches Beispiel: AWS EC2 Scheduler 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 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' gesetzt 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"Stoppe die Instanzen: {stop_instance_ids}")
 ec2.stop_instances(InstanceIds=stop_instance_ids)
 else:
 print("Keine Instanz zu stoppen.")
 
 # --- Ähnliche Logik zum Starten der Instanzen zu einem anderen Zeitpunkt ---
 # Sie hätten eine andere Lambda-Funktion/CloudWatch-Ereignis zum Starten,
 # oder kombinieren Sie die Logik mit einem Tag 'start'.
 
 return {
 'statusCode': 200,
 'body': 'Planung der EC2-Instanzen abgeschlossen.'
 }

Sie würden zwei CloudWatch-Ereignisregeln einrichten: eine, um diese Lambda-Funktion beispielsweise um 18 Uhr UTC zum Stoppen der Instanzen auszulösen, und eine andere um 7 Uhr UTC, um sie zu starten. Dies kann die Rechenkosten für diese spezifischen Ressourcen um mehr als 70 % senken.

2. Nutzen Sie Serverless und Container-Orchestrierung

Wenn Ihre Arbeitslast wirklich sporadisch oder ereignisgesteuert ist, ist serverlos Ihr bester Freund. 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 zahlen, wenn Ihr Code tatsächlich ausgeführt wird. Das ist ein riesiger Unterschied zur Vorstellung von „immer aktiv“.

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. Horizontale Pod-Autoscaler (HPA) können Ihre Anwendungs-Pods basierend auf der CPU-Nutzung oder benutzerdefinierten Metriken hoch- oder herunterskalieren. Cluster-Autoscaler können sogar Knoten zu Ihrem Cluster hinzufügen oder entfernen, je nach Nachfrage.

Mein Kunde hat einige Teile seines Analyse-Dashboards umgestaltet, 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 Daten) 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 ein heikles Thema, da die Datenpersistenz entscheidend ist. Viele moderne Datenbanken bieten jedoch serverlose oder automatisch skalierbare Optionen, die vor einigen Jahren nicht weit verbreitet waren.

• AWS Aurora Serverless v2: Das ist eine bedeutende Veränderung. Sie passt ihre Kapazität basierend auf der tatsächlichen Nutzung an, von Bruchteilen einer ACU (Aurora Capacity Unit) bis hin zu Hunderten, und Sie zahlen nur für das, was Sie nutzen. Es ist nicht mehr nötig, für eine Spitzenkapazität zu provisionieren, während Sie die meiste Zeit mit Grundlast arbeiten.
• Azure SQL Database Serverless: Ähnlich wie Aurora Serverless passt sie automatisch die Rechenleistung an und pausiert, wenn sie inaktiv ist, wodurch erhebliche Kosten für intermittierende Arbeitslasten eingespart werden.
• DynamoDB On-Demand: Für NoSQL-Arbeitslasten bedeutet der On-Demand-Kapazitätsmodus von DynamoDB, dass Sie pro Anfrage bezahlen, ohne Kapazitätseinheiten für Lese-/Schreibvorgänge provisionieren zu müssen. Perfekt für unvorhersehbare Verkehrsmuster.

Das Analyse-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 während der Nebenzeiten mit voller Kapazität lief.

4. Bereinigen Sie Unbenutzten Speicher und Snapshots

Das mag grundlegend erscheinen, ist aber eine ständige Quelle unnötiger Ausgaben. 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-Root-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 Unbenutzten EBS-Volumes (AWS CLI)

Sie können die AWS CLI verwenden, um unbenutzte Volumes zu finden und zu löschen. Das ist eine gängige Bereinigungsaufgabe.

# Liste aller nicht angehängten Volumes
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,CreateTime]' --output table

# Um ein bestimmtes Volume zu löschen (SEIEN SIE VORSICHTIG, 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 erstellen und löschen. Der Kunde entdeckte mehrere Terabyte alter unbenutzter EBS-Volumes und Hunderte veralteter Snapshots. Das Löschen reduzierte seine monatliche Rechnung um mehrere Hundert Dollar – nicht riesig, aber jede kleine Maßnahme 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 Gateways.

• Konsolidieren Sie NAT-Gateways: Wenn Ihre Architektur es zulässt, reduzieren Sie die Anzahl der 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 die Kosten für NAT-Gateways vermieden und eine bessere Sicherheit geboten wird.

Wir stellten fest, dass der Kunde ein NAT-Gateway in jeder AZ hatte, obwohl seine Hauptanwendung nur in zwei lief. Sie konnten konsolidieren und an dieser Stelle etwas sparen und implementierten dann VPC-Endpunkte für den Zugriff auf S3, was die Datenverarbeitungskosten über das NAT-Gateway senkte.

Maßnahmen für Ihren nächsten Sprint

Es geht nicht nur darum, Kosten zu senken; es geht darum, intelligentere und effizientere Systeme zu bauen, die intrinsisch kostenbewusst sind. Hier sind einige Dinge, die Sie noch heute beginnen können:

1. Überprüfen Sie regelmäßig Ihre Cloud-Rechnung: Machen Sie es sich zur Gewohnheit. Nutzen Sie die Kostenmanagement-Tools Ihres Cloud-Anbieters. Überlassen Sie es nicht einfach der Finanzabteilung. Verstehen Sie, wohin jeder Dollar fließt.
2. 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. Das macht die Identifizierung und Automatisierung unendlich einfacher.
3. Priorisieren Sie die Planung für Nicht-Prod-Umgebungen: Staging-, Dev- und QA-Umgebungen sind ideale Kandidaten für geplante Abschaltungen außerhalb der Arbeitszeiten. Das ist in der Regel der einfachste und schnellste Gewinn.
4. Bewerten Sie Serverless für neue Arbeitslasten: Wenn Sie etwas Neues bauen, insbesondere ereignisbasierte Microservices oder Hintergrundaufgaben, ziehen Sie immer zuerst Serverless in Betracht.
5. Überdenken Sie die Datenbankauswahl: Wenn Sie Datenbanken haben, die 24/7 mit stark variablen Lasten laufen, prüfen Sie die serverlosen oder automatisch skalierbaren Optionen für Ihre spezifische Datenbanktechnologie.
6. Automatisieren Sie die Bereinigung: Implementieren Sie automatisierte Skripte oder serverlose Funktionen, um unbenutzte Speichervolumes, alte Snapshots und andere verwaiste Ressourcen zu identifizieren und zu löschen.
7. 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 Betriebsthema.

Das Stoppen des Lecks von “immer aktiven” Ressourcen ist keine einmalige Lösung; es ist eine kontinuierliche Disziplin. Aber durch die Umsetzung dieser Änderungen werden Sie nicht nur eine beträchtliche Menge Geld für Ihr Unternehmen sparen, sondern auch eine agilere, widerstandsfähigere und nachhaltigere Infrastruktur aufbauen. Und ganz ehrlich, es macht Sie einfach besser im Technologiebereich.

Das war’s für mich diesmal. Machen Sie weiter mit intelligentem Bauen, und wir sehen uns beim nächsten Mal!

🕒 Published: March 29, 2026