Hallo zusammen, Jules Martin hier, 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 Abhebung von nicht optimierten Infrastrukturkosten. Wir alle wissen, dass wir schnell bauen, schnell wachsen und die Funktionen von gestern liefern müssen. Aber oft lassen wir in dieser Eile eine Spur von vergessenen Ressourcen, überdimensionierten Instanzen und Dienstleistungen, die im Autopilotmodus laufen, zurück, und sammeln Rechnungen an, die wir kaum betrachten, bevor die vierteljährliche Budgetüberprüfung wie ein Sack Ziegelsteine fällt.
Also, für diesen Artikel gehe ich direkt auf die Kostenoptimierung ein, aber mit einem sehr spezifischen und opportunen Blickwinkel: Wie man aufhört, Geld für „immer laufende“ Ressourcen auszugeben, die „nach Bedarf“ oder „ereignisgesteuert“ sein sollten. Wir sind im Jahr 2026, Leute. Die Zeiten, in denen man Server nach Bedarf bereitstellt, sind vorbei. Wenn deine Cloud-Rechnung immer noch wie ein Telefonbuch aussieht, ist es Zeit zu handeln.
Der stille Killer: Immer an, wenn es nach Bedarf sein sollte
Seien wir realistisch. Wenn wir unter Druck stehen, ein neues Werkzeug für die Agenten oder eine Verbesserung des Kundenservice bereitgestellt zu bekommen, rückt die Kostenfrage oft in den Hintergrund hinter die 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 den gesamten Internetverkehr bewältigen könnte, nur damit sie die meiste Zeit über ungenutzt bleibt. Wir vergessen, angemessene Skalierungsrichtlinien zu konfigurieren, oder lassen einfach alles rund um die Uhr laufen, weil es einfacher ist, sich nicht darum zu kümmern.
Ich habe das vor einigen Monaten mit dem neuen internen Analytik-Dashboard eines Kunden selbst gesehen. Das Team, Gott segne sie, hatte ein fantastisches System aufgebaut, das Agenten Echtzeit-Einblicke in die Interaktionen mit den Kunden bot. Das war ein riesiger Sieg für die Leistung. Aber als die erste komplette Cloud-Rechnung ankam, wäre der Finanzdirektor umgekippt. Sie hatten ein robustes EKS-Cluster, einige hochwertige RDS-Instanzen und eine Vielzahl von Lambda-Funktionen mit großzügigen Speicherzuweisungen in Betrieb, die rund um die Uhr liefen. Der Höhepunkt? Das Dashboard wurde hauptsächlich von den Agenten während der Bürozeiten genutzt, von 9 bis 17 Uhr, von Montag bis Freitag. Außerhalb dieser Zeiten war es eine Geisterstadt.
Sie zahlten für Unternehmenslevel-Kapazität für ein System, das effektiv 70 % der Woche inaktiv war. Es ist wie der Kauf eines Formel-1-Autos, nur um einmal pro Woche zum Supermarkt zu fahren.
Identifizieren Sie die Täter: Wohin fließt Ihr Geld wirklich
Bevor Sie irgendetwas reparieren können, müssen Sie wissen, was kaputt ist. 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 Berichte – das sind nicht nur für die Finanzen. Das ist Ihre erste Verteidigungslinie.
Die üblichen Verdächtigen
- Berechnungsinstanzen (EC2, VMs): Das sind oft die größten Tä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 den Berechnungen können auch Datenbanken für IOPS, CPU oder Speicher überprovisioniert sein. Viele bieten mittlerweile serverlose Optionen, die auf null oder nahezu null kosten, wenn sie inaktiv sind.
- Speicher (EBS-Volumes, nicht angeschlossene Disks): Haben Sie jemals eine Instanz gestartet, sie beendet, aber das zugehörige Speichervolumen herumliegen lassen? Das passiert häufiger, als Sie denken.
- Netzwerk (Datenübertragung, NAT-Gateways): Die Kosten für Datenübertragungen können Sie überraschen, insbesondere zwischen Regionen. NAT-Gateways haben auch Kosten pro Stunde, selbst wenn sie nichts tun.
- Unterbenutzte Dienste: Zahlen Sie für einen dedizierten Redis-Cache, der nur ein paar Zugriffe pro Tag hat? Ein verwalteter Kafka-Cluster für einen Nachrichtenstrom?
Mein Kunde aus der Geschichte des Analytik-Dashboards begann damit, seinen AWS Cost Explorer zu betrachten. Die größten Ausgaben 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. Kleine Dinge, aber das summiert sich.
Strategien zur Umwandlung von Immer an in Nach Bedarf (oder außerhalb der Spitzenzeiten)
Okay, Sie haben die Bereiche identifiziert, in denen Sie zu viel ausgeben. Kommen wir zum spannenden Teil: das Reparieren. Ziel ist es nicht nur, Geld zu sparen, sondern auch 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 Maßnahme für viele Anwendungen. Wenn Ihre internen Werkzeuge oder Ihre 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 zur Planung von Instanz-Stromzyklen, 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' 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"Stopping instances: {stop_instance_ids}")
ec2.stop_instances(InstanceIds=stop_instance_ids)
else:
print("No instances to stop.")
# --- Ähnliche Logik zum Starten von Instanzen zu einem anderen Zeitpunkt ---
# Sie hätten eine andere Lambda/CloudWatch-Ereignis, um zu starten,
# oder die Logik mit einem 'start'-Tag kombinieren.
return {
'statusCode': 200,
'body': 'EC2-Instanzenplanung abgeschlossen.'
}
Sie sollten zwei CloudWatch-Ereignisregeln einrichten: eine zum Auslösen dieser Lambda, sagen wir, um 18:00 Uhr UTC, um die Instanzen zu stoppen, und eine andere um 7:00 Uhr UTC, um sie zu starten. Das allein kann die Berechnungskosten für diese spezifischen Ressourcen um über 70 % senken.
2. Setzen Sie auf Serverless 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 Paradigmenwechsel im Vergleich zum „immer an“-Modell.
Für komplexere Anwendungen, die weiterhin persistente Dienste benötigen, aber schwankende Nachfrage haben, sind Container-Orchestrierungsplattformen wie Kubernetes (EKS, AKS, GKE) in Kombination mit intelligenter Skalierung mächtig. Die Horizontal Pod Autoscalers (HPA) können die Größe Ihrer Anwendungs-Pods basierend auf der CPU-Nutzung oder benutzerdefinierten Metriken variieren. Die Cluster Autoscalers können sogar Knoten zu Ihrem Cluster hinzufügen oder entfernen, je nach Nachfrageschwankungen.
Mein Kunde hat Teile seines Analytik-Dashboards umgestaltet, um Lambda zu verwenden, um bestimmte Berichte zu generieren, die nur ein paar Mal am Tag angefordert wurden. Anstelle einer dedizierten EC2-Instanz, die einen Cronjob 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 erheblich.
3. Dimensionieren Sie Ihre Datenbanken korrekt mit Serverless oder Auto-Skalierung
Datenbanken sind oft problematisch, da die Datenpersistenz kritisch ist. Viele moderne Datenbanken bieten jedoch serverlose Optionen oder Auto-Skalierung, die vor ein paar Jahren nicht weit verbreitet waren.
- AWS Aurora Serverless v2 : Das ist eine bedeutende Änderung. Es passt die Kapazität basierend auf der tatsächlichen Nutzung an, von Bruchteilen eines ACU (Aurora Capacity Unit) bis zu Hunderten, und Sie zahlen nur für das, was Sie verwenden. Es ist nicht mehr nötig, für Spitzenkapazitäten zu provisionieren, während Sie die meiste Zeit im Basisbetrieb sind.
- Azure SQL Database Serverless : Ähnlich wie Aurora Serverless passt es sich automatisch an die Rechenkapazität an und pausiert, wenn es nicht aktiv ist, was erhebliche Einsparungen bei intermittierenden Workloads ermöglicht.
- DynamoDB On-Demand : Für NoSQL-Workloads bedeutet der On-Demand-Kapazitätsmodus von DynamoDB, dass Sie pro Abfrage bezahlen, ohne Kapazitätseinheiten für Lese-/Schreiboperationen provisionieren zu müssen. Perfekt für unvorhersehbare Verkehrsmodelle.
Das Analytics-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 Zeiten mit geringer Auslastung im Volllastmodus lief.
4. Bereinigen Sie Unbenutzte Speicher und Snapshots
Das mag grundlegend erscheinen, ist aber eine ständige Quelle für Geldverschwendung. Wenn Sie eine EC2-Instanz beenden, wird das zugehörige EBS-Volume nicht immer standardmäßig gelöscht, insbesondere wenn es sich um ein Nichtstamm-Volume handelte. Das gilt auch für Snapshots – sie häufen sich schnell an und können teuer werden.
Praktisches Beispiel: Finden und Löschen Unbenutzter EBS-Volumes (AWS CLI)
Sie können die AWS CLI verwenden, um ungenutzte Volumes zu finden und zu löschen. Es ist eine gängige Bereinigungsaufgabe.
# Auflisten aller ungenutzten Volumes
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,CreateTime]' --output table
# Um ein spezifisches Volume zu löschen (VORSICHT, DAS IST UNWIDERRUFLICH)
# Ersetzen Sie 'vol-xxxxxxxxxxxxxxxxx' durch die tatsächliche Volume-ID
# aws ec2 delete-volume --volume-id vol-xxxxxxxxxxxxxxxxx
Automatisieren Sie dies mit einer programmierten Lambda-Funktion, wenn Sie häufig Umgebungen erstellen und löschen. Der Kunde entdeckte mehrere Terabyte alter ungenutzter EBS-Volumes und Hunderte von veralteten Snapshots. Das Löschen dieser Ressourcen half, einige Hundert Dollar bei ihrer monatlichen Rechnung zu sparen – das ist nicht viel, aber jede kleine Geste 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 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, konsolidieren Sie auf weniger NAT Gateways.
- VPC Endpoints : Um auf AWS-Dienste wie S3 oder DynamoDB von Ihrem VPC aus zuzugreifen, nutzen Sie VPC Endpoints. Der Datenverkehr verläuft privat innerhalb des AWS-Netzwerks, was die Kosten für NAT Gateways vermeidet und eine bessere Sicherheit bietet.
Wir stellten fest, dass der Kunde in jeder AZ ein NAT Gateway hatte, obwohl seine Hauptanwendung nur in zwei davon lief. Sie konnten konsolidieren und dabei 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 Ihren Nächsten Sprint
Es geht nicht nur um Kostensenkungen; es geht darum, intelligentere und effizientere Systeme zu bauen, die intrinsisch kostenbewusst sind. Hier sind einige Dinge, die Sie sofort beginnen können:
- Prüfen Sie Regelmäßig Ihre Cloud-Rechnung : Machen Sie es sich zur Gewohnheit. Nutzen Sie die Kostenmanagement-Tools Ihres Cloud-Anbieters. Lassen Sie es nicht nur den Finanzen überlassen. 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 stopptauglich sind. Das erleichtert die Identifizierung und Automatisierung erheblich.
- Priorisieren Sie Die Programmierung Für Nicht-Produktive Umgebungen : Staging-, Entwicklungs- 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.
- Bewerten Sie Serverless Für Neue Workloads : Wenn Sie etwas Neues bauen, insbesondere ereignisbasierte Mikrodienste oder Hintergrundaufgaben, sollten Sie immer zuerst serverless in Betracht ziehen.
- Überprüfen Sie Ihre Datenbankentscheidungen : Wenn Sie Datenbanken haben, die rund um die Uhr mit sehr variablen Lasten laufen, prüfen Sie die serverlosen oder auto-skalierenden Optionen für Ihre spezifische Datenbanktechnologie.
- Automatisieren Sie Die Bereinigung : 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 Kultur des Kostenbewusstseins. Stellen Sie sicher, dass die Entwickler die finanziellen Auswirkungen ihrer Provisionierungsentscheidungen verstehen. Es ist nicht mehr nur ein Betriebsproblem.
Das Stoppen von Verlusten im Zusammenhang mit „immer aktiven“ Ressourcen ist keine einmalige Lösung; es ist eine fortlaufende Disziplin. Aber durch diese Änderungen sparen Sie nicht nur eine erhebliche Summe Geld für Ihr Unternehmen, sondern bauen auch eine agilere, widerstandsfähigere und zukunftsfähige Infrastruktur auf. Und ehrlich gesagt, macht das Sie zu einem besseren Akteur im Technologiebereich.
Das war’s für diesmal. Bauen Sie weiter intelligent, und ich sehe Sie beim nächsten Mal!
🕒 Published: