Das ist der Teaser für einen Artikel, den ich vor einigen Monaten in meiner Leseliste sah:

Unexpected cloud computing costs cause sticker shock: „The cloud offers easy resource provisioning and flexible pricing, but there are several cloud computing costs beyond…“

(Via.)

Das wurde bestätigt, als ich im Oktober 2016 Gast auf einem AWS-Event für Verlage und Online-Publisher war. Hinter vorgehaltener Hand erzählten einige Vertreter davon, dass die ersten Tage mit AWS zu mehr Ausgaben geführt hatten, als sie geplant hatten. AWS-Accountmanager stimmten in der Lied mit ein. Diejenigen, die dem widersprachen, will ich gar nicht totschweigen – mir ist das auch nicht passiert, natürlich nicht (zwinker). 

Wie kann das passieren? Der einfachste Weg sind überdimensionierte Instanzen. Bevor man das Lastverhalten einer Anwendung noch nicht kennt, weiß man noch nicht, wie man sie sizen musste. Wir haben bei TargetVideo auch erst mal kleinere Instanzen benutzt und sind dann auf m3.medium gegangen, als wir einige Wochen lang Erfahrungswerte hatten. Als wir wussten, wir können uns auf die Grundlast verlassen, habe ich dann für diese Grundlast Reserved Instances gekauft, für 12 Monate. Drei Jahre halte ich für zu lange, da man dann nicht so gut an den nächsten Preissenkungsrunden von Amazon teilnehmen kann. Die erwarte ich nämlich, weil Azure und Google aggressiv nach Europa expandieren.

Der zweite Grund sind Testumgebungen, die nach dem Test – und das heißt oft abends und am Wochenende noch laufen. Allein durch die Anzahl der Instanzenstunden, die man hier sparen kann, sind das locker 30-50 Prozent Ersparnis. Dafür muss aber der Kostenverantwortliche, meist dürfte das der Engineering Manager sein, wissen, welche Systeme gerade was tun. Tagging ist dafür der beste Weg, und direkte Gespräche mit seinem Team. Ich weiß zu jeder Zeit, welche Instanzen laufen, mit der Ausnahme von Auto-Scaling Groups – aber da kann ich zumindest sagen, wie sie dimensioniert sind. Über die Lastspitzen hier bin ich natürlich nicht minütlich im Bilde.

Der dritte Grund sind oft ungenutzte Storages oder Datenbank. Ich habe mit einem der Cloud-Monitoring-Anbieter eine riesige RDS-Instanz gefunden, die wir uns sparen konnten. Eine dreistellige Ersparnis. Pro Monat. Auch bei großen Accounts ist das spürbar. 

Die Kosten in der Cloud laufen nur deshalb leichter davon, weil das Provisionieren schwieriger ist. Und es gibt irgendetwas an der User Experience in der Console von AWS, die den Überblick schwierig macht. In der Command Line ist der Überblick natürlich noch schwieriger. Und Manager können sich hier beweisen, mit dem richtigen Blick fürs Kostenbewusstsein. Das ist auch unsere Aufgabe, nicht nur, unser Team glücklich und produktiv zu machen.