Einleitung#
Das Nutzen von Cloud-Infrastruktur fühlt sich manchmal schon fast wie Magie an. Ein paar Klicks in der Cloud-Konsole oder ein terraform apply im Terminal, und schon stehen uns nahezu unbegrenzte Ressourcen für unser Projekt zur Verfügung. Am Monatsende folgt dann aber oft das Erwachen: Die Rechnung von AWS ist mal wieder höher als erwartet.
Der Klassiker: Man braucht eine Test-Instanz für ein kurzes PoC und hat sie dann vergessen, oder uralte Backups sammeln sich unbemerkt im S3 an.
Die gute Nachricht ist: Man muss nicht direkt die gesamte Architektur auf den Kopf stellen oder ewig Microservices umbauen und optimieren, um Geld zu sparen. Oftmals reichen schon kleine, unscheinbare Änderungen, die in der Summe einen großen Unterschied machen.
Mit den folgenden fünf einfachen Quick-Wins, kannst du deine AWS-Rechnung (und die bei jedem anderen Cloud-Anbieter) sofort minimieren und das ohne Kopfschmerzen oder Ausfallzeiten.
1. Die Leichen im Keller: Verwaiste EBS-Volumes & Elastic IPs#
Es ist der wohl häufigste Kostentreiber in Dev-Accounts: Man löscht eine EC2-Instanz, übersieht aber das Häkchen für “Delete on termination” beim genutzten EBS-Volume. Die VM ist weg, aber das Volume bleibt. Es tut nichts, liegt aber auf kostenintensivem SSD-Speicher und kostet jeden Monat unnötig Geld.
Ähnlich verhält es sich mit Elastic IPs (statischen IPv4-Adressen). Sie werden beim Cleanup vergessen und kosten auch, wenn sie nicht aktiv mit einer laufenden Instanz verknüpft sind. Damit soll verhindert werden, dass knappe IPv4-Adressen gehortet werden.
So räumst du auf:#
- Öffne das EC2 Dashboard in der AWS Konsole.
- Klicke auf Volumes und filtere nach dem Status
State = available. Alles, was hier auftaucht, ist nicht in Benutzung und kann gelöscht werden (vorher evtl. einen Snapshot zur Sicherheit machen). - Klicke auf Elastic IPs und suche nach Adressen, die keine Verknüpfung zu einer Instanz oder einer Netzwerkkarte aufweisen. Wähle diese aus und klicke auf Release Elastic IP addresses.
Ist das auch auf andere Clouds übertragbar? Absolut. Sowohl Azure (Orphaned Disks) als auch GCP (Unattached IPs & Disks) berechnen dir ungenutzte Speicher- und Netzwerkressourcen. Ein regelmäßiger Blick in diese Sektion lohnt sich allemal.
2. Der einfachste Speicher-Rabatt: Ein Upgrade von gp2 auf gp3#
Nutzt du für deine EC2-Instanzen noch EBS-Volumes vom Typ gp2? Falls ja, schenkst du AWS ohne Grund Geld.
Schon vor geraumer Zeit hat AWS die neue Speicherklasse gp3 eingeführt. Diese bietet ein wesentlich besseres Preis-Leistungs-Verhältnis. Während bei gp2 die Performance (IOPS) direkt an die Größe des Volumes gekoppelt ist (wodurch man oft zu große Volumes mieten musste, nur um mehr Speed zu bekommen), kann man bei gp3 die Performance unabhängig von der Kapazität skalieren.
Das Beste: gp3 ist auf das Gigabyte gerechnet rund 20 % günstiger als gp2.
flowchart LR
gp2["EBS gp2 (Veraltet)"] -->|20% Ersparnis & getrennte IOPS-Skalierung| gp3["EBS gp3 (Empfohlen)"]
style gp2 fill:#f97316,stroke:#ea580c,color:#fff
style gp3 fill:#10b981,stroke:#059669,color:#fff
So einfach ist das Upgrade:#
Du musst den Server dafür nicht einmal stoppen oder neu starten. Das Upgrade erfolgt im laufenden Betrieb:
- Im EC2-Dashboard das gewünschte Volume auswählen.
- Auf Modify Volume klicken.
- Den Typ von
gp2aufgp3ändern. - (Optional) IOPS und Durchsatz anpassen – die Standardwerte (3000 IOPS, 125 MB/s) sind bereits meist besser als das alte gp2-Äquivalent.
- Speichern. AWS migriert die Daten im Hintergrund, während der Server munter weiterläuft.
In Terraform muss man sogar nur eine einzelne Zeile anpassen:
resource "aws_ebs_volume" "example" {
availability_zone = "eu-central-1a"
size = 100
- type = "gp2"
+ type = "gp3"
}
3. Dev-Umgebungen müssen nicht rund um die Uhr laufen#
Hand aufs Herz: Arbeitet dein Team nachts um 3 Uhr oder am Sonntagnachmittag auf Staging oder in der Entwicklungsumgebung? In 99 % der Fälle lautet die Antwort: Nein.
Ein Monat hat 720 Stunden. Wenn die Dev-Instanzen nur während der regulären Arbeitszeit laufen (z.B. Montag bis Freitag, 8:00 bis 18:00 Uhr), werden sie nur ca. 200 Stunden pro Monat tatsächlich benötigt. Die restlichen 520 Stunden laufen sie komplett umsonst. Das ist ein Einsparpotenzial von über 70 %!
So setzt du es um:#
Es gibt in AWS interne Lösungen wie den AWS Instance Scheduler, aber es reicht oft schon eine einfache Automatisierung mit dem AWS Systems Manager (SSM) oder ein kurzes Python-Skript in einer AWS Lambda-Funktion, die per Amazon EventBridge (Cron-Job) getriggert wird.
Ein einfaches Beispiel für ein Lambda-Skript zum Stoppen von EC2-Instanzen mit dem Tag Environment = Dev:
import boto3
ec2 = boto3.client('ec2', region_name='eu-central-1')
def lambda_handler(event, context):
# Finde alle Dev-Instanzen, die gerade laufen
# Die Tag-Namen sind natürlich individuell gewählt
filters = [
{'Name': 'tag:Environment', 'Values': ['dev']},
{'Name': 'instance-state-name', 'Values': ['running']}
]
instances = ec2.describe_instances(Filters=filters)
instance_ids = []
for reservation in instances['Reservations']:
for instance in reservation['Instances']:
instance_ids.append(instance['InstanceId'])
if instance_ids:
ec2.stop_instances(InstanceIds=instance_ids)
print(f"Stopping instances: {instance_ids}")
else:
print("Did not find any running instances.")
Richte einfach zwei EventBridge-Regeln ein: Die erste triggert dieses Skript von Montag bis Freitag um 19:00 Uhr um die Instanzen zu stoppen, und die zweite führt ein entsprechendes Start-Skript um 7:30 Uhr morgens aus. Auch für verwaltete Datenbanken wie Amazon RDS kann man dieses Prinzip hervorragend verwenden.
4. S3 beim Aufräumen helfen: Lifecycle-Policies#
Objektspeicher wie Amazon S3 ist schnell einzurichten und billig zu betreiben. So billig, dass man oft dazu verleitet, alles hineinzuwerfen und nie wieder anzusehen. Doch über Monate und Jahre sammeln sich Terabytes an Logs, temporären CSV-Exporten und täglichen Datenbank-Backups an.
Warum sollte man den vollen Preis für Backups aus dem Jahr 2023 zahlen, die gesetzlich vielleicht gar nicht mehr aufbewahrt werden müssen oder die ohnehin niemand mehr braucht?
So löst du das Problem:#
Nutze S3 Lifecycle Rules. Damit können Regeln definieren werden, die Objekte nach einem bestimmten Zeitraum automatisch in die günstigeren Speicherklassen verschieben oder endgültig löschen.
Ein Lifecycle-Workflow für Backups könnte so aussehen:
- Tag 0 bis 30: S3 Standard (Schneller Zugriff für den Notfall).
- Ab 30 Tagen: Verschiebung nach S3 Standard-IA (Infrequent Access) oder S3 One Zone-IA. Der Speicherpreis halbiert sich nahezu.
- Ab 90 Tagen: Verschiebung ins Archiv Amazon S3 Glacier Flexible Archive oder Glacier Deep Archive (bis zu 95 % günstiger als S3 Standard).
- Ab 1 Jahr: Automatisches Löschen (sofern Compliance-Regeln dem nicht widersprechen).
Man kann diese Regeln in der AWS-Konsole unter dem Reiter Management des S3-Buckets mit wenigen Klicks anlegen.
5. Das Sicherheitsnetz: AWS Budgets & Anomaly Detection#
Die größte Angst jedes Cloud-Nutzers ist die exorbitant hohe Rechnung am Ende des Monats, weil ein Bug eine Endlosschleife in einer Lambda-Funktion erzeugt hat, eine Terraform-Definition versehentlich 100 statt 10 Instanzen gestartet hat oder ein API-Schlüssel geleakt wurde und Krypto-Miner die AWS-Konten übernommen haben.
Wer erst am 30. des Monats in den Abrechnungsbereich schaut, hat verloren. Dafür sind Frühwarnsysteme gedacht.
Zwei Tools, die du heute einrichten solltest:#
- AWS Budgets: Erstelle ein einfaches Budget für die erwarteten monatlichen Kosten (z.B. 500 €). Richte Alarme ein, sobald die tatsächlichen oder prognostizierten Kosten 80 % und 100 % dieses Betrags überschreiten. Die Benachrichtiung kommt sofort per E-Mail.
- AWS Cost Anomaly Detection: Dieses Tool nutzt klassisches Machine Learning, um die täglichen Ausgaben zu analysieren. Weichen die Kosten an einem Tag plötzlich vom normalen Muster ab (z.B. weil ein S3-Sync-Skript Amok läuft), bekommst du sofort eine E-Mail oder eine Nachricht per Slack oder in MS-Teams. Das Tool von AWS ist komplett kostenlos und in zwei Minuten schnell eingerichtet.
Fazit#
Die Optimierung von Cloud-Kosten (oder neudeutsch “FinOps”) muss kein Mammutprojekt sein. Beginne mit den einfachen Dingen: Lösche die verwaisten Ressourcen, wechsele auf moderne Volume-Typen wie gp3, schalte die Dev-Umgebungen nachts und am Wochenende aus und sichern dich mit Anomaly Detection ab.
Schon diese einfachen Handgriffe reduzieren die monatlichen Kosten oft spürbar und verschaffen dir die Ruhe, sich wieder dem Tagesgeschäft zu widmen.
Wenn Fragen zur Umsetzung auftauchen oder du Unterstützung bei der Optimierung der Cloud-Infrastruktur benötigst, kontaktiere uns gerne über die unten genannten Kanäle!
