Meine versteckten Infrastrukturkosten haben mein Budget getötet.

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-Nachbesprechungen gesehen habe, als ich zugeben möchte: die unsichtbare Anhäufung der Kosten für nicht optimierte Infrastruktur. Wir alle wissen, dass wir schnell bauen, schnell skalieren und Funktionen von gestern ausliefern müssen. Aber oft lassen wir in diesem Eifer eine Spur von vergessenen Ressourcen, überdimensionierten Instanzen und Diensten, die im Autopilotmodus laufen, zurück, was Rechnungen anhäuft, die wir kaum vor einem Quartalsbudget-Review ansehen, bevor sie wie ein Stein auf uns fallen.

In diesem Artikel werde ich also tief eintauchen in die Kostenoptimierung, aber aus einem sehr spezifischen und aktuellen Blickwinkel: wie man aufhört, Geld für „immer eingeschaltete“ Ressourcen auszugeben, die „nach Bedarf“ oder „ereignisgesteuert“ sein sollten. Wir sind im Jahr 2026, Leute. Die Zeiten, in denen Server nach Belieben bereitgestellt werden, sind vorbei. Wenn eure Cloud-Rechnung immer noch wie ein Telefonbuch aussieht, ist es Zeit, einzugreifen.

Der stille Killer: Immer Eingeschaltet, wenn es Nach Bedarf Sein Sollte

Seien wir realistisch. Wenn wir unter Druck stehen, ein neues Tool für Agenten oder eine Verbesserung des Kundenservices zu liefern, rückt der Preis oft in den Hintergrund gegenüber Funktionalität und Schnelligkeit. 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 während der Zeitspanne hauptsächlich ungenutzt bleibt. Wir vergessen, angemessene Skalierungsrichtlinien einzurichten, oder lassen die Dinge einfach 24/7 laufen, weil es, nun ja, einfacher ist, sich nicht darum zu kümmern.

Ich habe das vor ein paar Monaten mit dem neuen internen Analytics-Dashboard eines Kunden selbst erlebt. Das Team, Gott segne sie, hatte ein fantastisches System geschaffen, das den Agenten Echtzeit-Einblicke in die Interaktionen mit den Kunden bot. Es war ein riesiger Gewinn für die Leistung. Aber als die erste vollständige Cloud-Rechnung eintraf, wäre der Finanzdirektor fast umgekippt. Sie hatten ein robustes EKS-Cluster, einige hochwertige RDS-Instanzen und eine Vielzahl von Lambda-Funktionen mit großzügig zugewiesenem Speicher, die alle ununterbrochen liefen. Der Clou? 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 Unternehmenskapazität für ein System, das tatsächlich 70 % der Woche inaktiv war. Es ist wie der Kauf eines Formel-1-Autos, um einmal pro Woche zum Supermarkt zu fahren.

Identifiziert die Schuldigen: Wo Ihr Geld Tatsächlich Hin Geht

Bevor ihr irgendetwas reparieren könnt, müsst ihr wissen, was kaputt ist. Die meisten Cloud-Anbieter bieten die Werkzeuge, um eure Ausgaben zu visualisieren, und ihr solltet sie auf jeden Fall nutzen. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing Reports – diese sind nicht nur für die Finanzen. Sie sind eure erste Verteidigungslinie.

Die üblichen Verdächtigen

• Compute-Instanzen (EC2, VMs): Oft sind sie die größten Übeltäter. Sind sie überdimensioniert? Laufen sie, wenn sie nicht sollten? Verwendet ihr die richtige Instanzfamilie für eure Arbeitslast?
• Datenbanken (RDS, Azure SQL, Cloud SQL): Wie beim Compute können Datenbanken für IOPS, CPU oder Speicher überprovisioniert sein. Viele bieten mittlerweile serverlose Optionen, die auf null oder nahezu null sinken, wenn sie inaktiv sind.
• Speicher (EBS-Volumes, nicht angehängte Laufwerke): Habt ihr jemals eine Instanz gestartet, sie beendet, aber das zugehörige Speichervolumen dort gelassen? Das passiert häufiger, als ihr denkt.
• Netzwerk (Datentransfer, NAT Gateways): Die Kosten für den Datentransfer können euch überraschen, besonders zwischen Regionen. NAT Gateways haben auch Kosten pro Stunde, selbst wenn sie nichts tun.
• Untergenutzte Dienste: Zahlt ihr 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 Analytics-Dashboard begann mit dem AWS Cost Explorer. Die größten Ausgabenposten waren, vorhersehbar, EC2 und RDS. Sie fanden auch einige EBS-Volumes, die an beendeten Instanzen angehängt waren, und ein NAT Gateway in einem VPC, das nicht mehr für Produktionstraffik verwendet wurde. Kleine Dinge, aber das summiert sich.

Strategien zum Umwandeln 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ßteil: das Reparieren. Das Ziel ist nicht nur, Geld zu sparen, sondern ein resilienteres und effizienteres System zu schaffen, das nur dann Ressourcen verbraucht, wenn es sie tatsächlich benötigt.

1. Plant das Starten/Stoppen von 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 von Instanzen zu planen, oder ihr könnt eure eigene Lösung mit serverlosen Funktionen erstellen.

Praxisbeispiel: AWS EC2 Scheduler 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 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:', das 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"Stoppen der Instanzen: {stop_instance_ids}")
 ec2.stop_instances(InstanceIds=stop_instance_ids)
 else:
 print("Keine Instanz zu stoppen.")
 
 # --- Ähnliche Logik, um Instanzen zu einem anderen Zeitpunkt zu starten ---
 # Ihr würdet ein weiteres Lambda/CloudWatch-Event zum Starten haben,
 # oder die Logik mit einem 'start'-Tag kombinieren.
 
 return {
 'statusCode': 200,
 'body': 'Planung der EC2-Instanzen abgeschlossen.'
 }

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

2. Nutzt Serverless und Container-Orchestrierung

Wenn eure Arbeitslast wirklich sporadisch oder ereignisgesteuert ist, ist serverless euer bester Verbündeter. AWS Lambda, Azure Functions, Google Cloud Functions – sie reduzieren sich auf null, wenn sie nicht genutzt werden, was bedeutet, dass ihr nur für die Rechenleistung bezahlt, wenn euer Code tatsächlich ausgeführt wird. Das ist ein riesiger Wandel vom „immer eingeschaltet“-Paradigma.

Für komplexere Anwendungen, die immer noch persistente Dienste benötigen, aber eine schwankende Nachfrage haben, sind Container-Orchestrierungsplattformen wie Kubernetes (EKS, AKS, GKE) in Kombination mit intelligenter Skalierung mächtig. Die Horizontal Pod Autoscaler (HPA) können die Größe eurer Anwendungs-Pods basierend auf der CPU-Nutzung oder benutzerdefinierten Metriken variieren. Cluster Autoscaler können sogar Knoten zu eurem Cluster hinzufügen oder entfernen, während sich die Nachfrage ändert.

Mein Kunde hat Teile seines Analytics-Dashboards so umstrukturiert, dass Lambda verwendet wird, um einige Berichte zu generieren, die nur ein paar Mal pro Tag angefordert wurden. Anstatt eine dedizierte EC2-Instanz zu haben, 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. Skalierung eurer Datenbanken richtig mit Serverless oder Auto-Scaling

Datenbanken sind oft problematisch, da die Persistenz von Daten entscheidend ist. Allerdings bieten viele moderne Datenbanken mittlerweile serverlose Optionen oder Auto-Scaling, die vor ein paar Jahren noch nicht weit verbreitet waren.

• AWS Aurora Serverless v2 : Das ist eine signifikante Veränderung. Es passt die Kapazität basierend auf 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. Es ist nicht mehr nötig, für Spitzenauslastung Kapazität bereitzustellen, während Sie die meiste Zeit im Basisbetrieb 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 signifikante Einsparungen für intermittierende Workloads ermöglicht.
• DynamoDB On-Demand : Für NoSQL-Workloads bedeutet der On-Demand-Kapazitätsmodus von DynamoDB, dass Sie pro Anfrage bezahlen, ohne Einheiten für Lese-/Schreibe-capacity bereitstellen zu müssen. Perfekt für unvorhersehbare Verkehrsmuster.

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 sie nicht mehr während der Nebenzeiten mit voller Kapazität liefen.

4. Bereinigen Sie Unbenutzte Speicher und Snapshots

Das mag grundlegend erscheinen, ist aber eine constante 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-Wurzelvolume handelte. Das Gleiche gilt für Snapshots – sie häufen 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. Es ist eine gängige Reinigungsaufgabe.

# Alle unbenutzten 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 erstellen und löschen. Der Kunde stellte mehrere Terabyte veralteter unbenutzter EBS-Volumes und Hunderte veralteter Snapshots fest. Das Löschen dieser hat ihnen geholfen, einige hundert Dollar von ihrer monatlichen Rechnung zu sparen – das ist nicht viel, aber jede kleine Maßnahme zählt.

5. Netzwerk Kosten Optimieren

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 Datenverarbeitungsgebühren. Wenn Sie mehrere NAT Gateways in verschiedenen Verfügbarkeitszonen haben, aber nur eines aktiv genutzt wird, zahlen Sie für Redundanzen.

• 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 Verkehr bleibt privat innerhalb des AWS-Netzwerks, wodurch die Kosten der 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 zweien lief. Sie konnten konsolidieren und dadurch Einsparungen erzielen und implementierten dann VPC Endpoints für den Zugriff auf S3, was die Datenverarbeitungskosten über das NAT Gateway senkte.

Zu Ergreifende Maßnahmen Für Ihr Nächstes Sprint

Es geht nicht nur darum, Kosten zu senken; es geht darum, intelligentere und effektivere Systeme zu schaffen, die intrinsisch kostenbewusst sind. Hier sind einige Schritte, die Sie noch heute unternehmen können :

1. Überprüfen Sie Regelmäßig Ihre Cloud-Rechnung : Machen Sie es sich zur Gewohnheit. Verwenden Sie die Kostenmanagement-Tools Ihres Cloud-Anbieters. Geben Sie es nicht nur an die Finanzen weiter. Verstehen Sie, wohin jeder Dollar fließt.
2. Taggen Sie Alles : Dies 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.
3. Priorisieren Sie das Planen für Nicht-Produktionsumgebungen : Staging-, dev- und QA-Umgebungen sind ideale Kandidaten für geplante Abschaltungen außerhalb der Bürozeiten. Das ist in der Regel der einfachste und schnellste Gewinn.
4. Bewerten Sie Serverless für Neue Workloads : Wenn Sie etwas Neues bauen, insbesondere ereignisbasierte Microservices oder Hintergrundaufgaben, sollten Sie immer zuerst serverless in Betracht ziehen.
5. Überprüfen Sie Ihre Datenbank-Auswahl : Wenn Sie Datenbanken haben, die 24/7 mit sehr variablen Lasten laufen, prüfen Sie die serverless- oder auto-scaling Optionen für Ihre spezifische Datenbanktechnologie.
6. Automatisieren Sie die Reinigung : Implementieren Sie automatisierte Skripte oder serverless Funktionen, um unbenutzte Speicher-Volumes, alte Snapshots und andere verwaiste Ressourcen zu identifizieren und zu entfernen.
7. Bildung Ihrer Team : Fördern Sie eine Kultur des Kostenbewusstseins. Stellen Sie sicher, dass die Entwickler die finanziellen Auswirkungen ihrer Bereitstellungsentscheidungen verstehen. Das ist nicht mehr nur ein Problem der Betriebsabteilung.

Das stoppt die Verluste durch “immer aktive” Ressourcen ist keine einmalige Lösung; es ist eine fortlaufende Disziplin. Aber durch diese Veränderungen werden Sie nicht nur eine signifikante Menge an Geld für Ihr Unternehmen sparen, sondern auch eine agilere, resilientere und zukunftssichere Infrastruktur aufbauen. Und ehrlich gesagt, das macht Sie zu einem besseren Akteur im Technologiebereich.

Das wäre alles von mir für diesmal. Machen Sie weiter, intelligent zu bauen, und ich sehe Sie beim nächsten Mal wieder!

🕒 Published: March 29, 2026