Cloud-Frühjahrsputz: AWS-Kosten sparen

1 Kommentar

Frühling! Die Temperaturen steigen langsam, das Leben in der Natur beginnt sich wieder zu regen und die meisten Menschen machen in ihren Haushalten klar Schiff. Aber wieso sollte man den Frühjahrsputz auf den eigenen Keller oder Schuppen beschränken? Da aktuell das Büro für die meisten keine Option ist, haben wir uns mal angeschaut, wie man die eigenen AWS-Accounts wieder auf Vordermann bringt und ganz nebenbei noch einiges an AWS-Kosten sparen kann.

Sofortmaßnahmen

Solch eine Aufräumaktion startet man am besten durch die Prüfung der teuersten Ressourcen beim Cloud-Anbieter. Erste wichtige Anhaltspunkte kann dabei ein Blick in den AWS-Kosten-Explorer liefern. Dort kann man sehen, welche Dienste welche Kosten verursacht haben.
AWS Kosten Explorer
Einen Klassiker unter den unnötigen Kosten bilden dabei unnötig laufende EC2-Instanzen im AWS-Umfeld. Die virtuellen Maschinen sind schnell erstellt und können je nach gewählter Ausstattung schnell signifikante Kosten erzeugen. Einer der Spitzenreiter hierbei ist aktuell die p2.16xlarge-Instanzgröße, die bei einem Dauerbetrieb über 15.000 Dollar pro Monat kostet. Hierbei kann neben der Löschung unnötiger Instanzen auch das Reduzieren der Instanzgröße eine Einsparung bringen.

Dieselben Maßnahmen können natürlich auch für andere Instanz basierte Angebote wie zum Beispiel den relationalen Datenbank-Service RDS durchgeführt werden. Dort kann man ebenfalls die nicht genutzten Instanzen löschen oder andere Instanzen auf ein vernünftiges Maß eindampfen.

Ein weiterer potentieller Treiber können die automatischen Datenbank-Backups sein. Diese werden nach genutztem Speicherplatz bepreist. Und mal ehrlich: Brauchen wir wirklich die Historie der Backups des ganzen letzten Jahres?

Ebenso lohnt sich oft ein Blick in Richtung selbsterstellter Artefakte. Für die Erstellung von EC2-Instanzen wird oft ein spezifisches AMI mit der benötigten Anwendung und allen Abhängigkeiten auf Betriebssystemebene kreiert. Hier stellt sich ebenfalls die Frage, ob alle jemals erstellten Images aufgehoben werden müssen. Selbst in regulierten Umgebungen ist oft nur die Aufbewahrung von Images vorgeschrieben, die auch in Produktion genutzt wurden. Ein weiterer Dienst, der erstellte Artefakte beinhalten kann, ist zudem mit dem Elastic Container Registry für Container Images vorhanden.

Neben dem durch Entwicklungsartefakte belegten Speicherplatz kann es sich auch lohnen, den Storage für Produktionsumgebungen unter die Lupe zu nehmen. Vor allem virtuelle EBS-Festplatten können hier schnell zu Buche schlagen. Von diesen können wiederum ebenfalls Snapshots erstellt werden, die ebenfalls begutachtet werden sollten. Eine Betrachtung der S3 Buckets kann sich hier ebenfalls lohnen.

Weitere Potenziale gibt es auf Netzwerkebene im Bereich der Load Balancer und Elastic IPs, deren Ausführung an dieser Stelle zu weit führen würde.

Organisatorische Maßnahmen

Die laufenden AWS-Kosten von allen Accounts sollten überwacht werden. Das ist die erste Regel, die Unternehmen und Privatpersonen auf AWS beachten sollten. Trotzdem werden Billing Alerts, obwohl Teil aller grundlegenden AWS-Zertifizierungen, gerne vergessen. Vor allem, wenn es den Entwickler*innen freisteht, in ihren Firmenaccounts zu testen und zu experimentieren, sollte ab einer gewissen Grenze eine Benachrichtigung bei den Verantwortlichen eingehen. Oft deuten hohe Rechnungen in einzelnen Entwickleraccounts schlicht auf vergessene Test-Infrastruktur hin und die verantwortlichen Entwickler*innen drehen die Kostenquelle von selbst ab, wenn sie benachrichtigt werden.

Ein weiterer wichtiger Schritt, um seine AWS-Kosten unter Kontrolle zu bekommen, ist, jede Ressource in jedem AWS-Account der Organisation zuordenbar zu machen. Neben der grundlegenden Sortierung in getrennte AWS-Accounts für verschiedene Projekte empfiehlt AWS die Nutzung von Tags an jeder erstellten Ressource, um sie zu einem Projekt oder einer Kostenstelle zurückverfolgen zu können. Diese Tags lassen sich auch im Cost Explorer und den monatlichen Kostenreports darstellen. Gleichzeitig stellen veraltete Tags an einem abgeschlossenen Projekt oder gar die komplette Abwesenheit von solchen einen starken Indikator für die Überflüssigkeit einer Ressource dar.

Unsere Empfehlung: So gefundene Ressourcen mit “Obsolete: Datum” taggen und eine Rückmeldung an die für den Account verantwortlichen Personen geben, zusammen mit einem Ultimatum, nach dem diese Ressourcen gelöscht werden, sollte das Tagging nicht korrigiert worden, d. h. die Nutzung der Ressource klargestellt sein. Diese Behandlung von Ressourcen lässt sich auch mit Tools wie etwa Swabbie lösen, das Netflix intern verwendet, um mit Spinnaker deployte AWS-Ressourcen wieder aufzuräumen.

Zuletzt ein gerne vergessener Aspekt der AWS-Organisation: Offboarding. AWS-Accounts von abgeschlossenen Projekten oder ausscheidenden Mitarbeiter*innen bleiben erst einmal unangetastet stehen, wenn die Löschung nicht Teil des Offboardingprozesses oder gar automatisiert erfolgt. Damit bleibt alle in jenen Accounts befindliche Infrastruktur erst einmal erhalten und verursacht weiter Kosten. Sollten dort gar von außerhalb erreichbare Komponenten deployed sein, ist dies zusätzlich auch ein Sicherheitsrisiko. Daher sollte die Löschung überflüssig gewordener Accounts zu einem Prozess werden, der zeitnah und systematisch verfolgt wird, nach Möglichkeit noch mit den Accountverantwortlichen zusammen, um sicherzustellen, dass keine noch irgendwo benutzten Ressourcen mit dem Account abgeräumt werden.

Fazit: Nachhaltiges AWS-Kosten-Management ist unverzichtbar

Die hier geschilderten Maßnahmen können natürlich nur an der Oberfläche der über 160 AWS-Services kratzen. Wer seine Cloud-/AWS-Kosten aber langfristig reduzieren will, kommt um ein nachhaltiges Kostenmanagement nicht herum.

Nicolas Byl

Nicolas Byl sammelte bereits während des Studiums der Medizinischen Informatik erste Erfahrungen im Umfeld Java-basierter Webportale und entdeckte seine Leidenschaft für verteilte Systeme. Bei der codecentric AG beschäftigt er sich mit mit cloud-nativen Infrastrukturen und deren kosteneffizienter Nutzer.

Avatar

Sebastian Jackel ist IT-Consultant mit dem Schwerpunkt DevOps. Wenn er nicht an Continuous-Delivery-Pipelines, Container-basierter Infrastruktur oder Monitoring von Services arbeitet, beschäftigt er sich gerne mit funktionaler Programmierung und Typsystemen.

Über 1.000 Abonnenten sind up to date!

Die neuesten Tipps, Tricks, Tools und Technologien. Jede Woche direkt in deine Inbox.

Kostenfrei anmelden und immer auf dem neuesten Stand bleiben!
(Keine Sorge, du kannst dich jederzeit abmelden.)

* Hiermit willige ich in die Erhebung und Verarbeitung der vorstehenden Daten für das Empfangen des monatlichen Newsletters der codecentric AG per E-Mail ein. Ihre Einwilligung können Sie per E-Mail an datenschutz@codecentric.de, in der Informations-E-Mail selbst per Link oder an die im Impressum genannten Kontaktdaten jederzeit widerrufen. Von der Datenschutzerklärung der codecentric AG habe ich Kenntnis genommen und bestätige dies mit Absendung des Formulars.

Kommentare

  • Fabian Lange

    13. Mai 2020 von Fabian Lange

    Guter Artikel! Wir bei Instana haben kürzlich auch „geputzt“.
    Gerade die von euch angesprochenen EBS Volumes waren bei uns enormes Sparpotential. Wir haben darüber auch geblogged:
    https://www.instana.com/blog/reducing-aws-ebs-volume-cost-lessons-from-an-instana-sre/

    Für uns hat am meisten gefehlt dass an AWS Resourcen nicht dransteht welcher IAM User die eigentlich gestartet hat. Etwas was wir jetzt manuell auch mit-taggen. Denn die Frage ob etwas noch gebraucht wird oder geändert werden kann klärt man am besten mit demjenigen der es gestartet hat.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.