Follow

In den letzten Wochen mehrfach erlebt, wie gefährlich es ist, auf Cloud Services (AWS, Azure, Google Cloud) die Kosten nicht sehr genau und zeitnah zu beobachten. Durch Falschnutzung kann man mit wenigen Klicks und falsch verstehen von Konstrukturen tausende Euro verbrennen und es erst Wochen später merken. Darum: Regelmäßig reviewen und wenn möglich Limits und Alarme setzen.

Beispiel 1: Ein Cloud-Account eines Kunden wurde gehackt. Per Script wurden dutzende maximale Cloud-Instanzen hochgefahren und zum Monero (eine Cryptocurrency) Berechnen benutzt. Wäre das Script nicht so schlecht geschrieben gewesen, hätten wir es erst Tage später mitbekommen. Möglicher Schaden: fünfstellig.

Beispiel: Mehrere tausend Dollar Schaden, weil ein Entwickler bei einer zu langsamen Datenbank immer manuell Limits hochgesetzt hat während der Entwicklung. Was ihm nicht klar war: Das sind bezahlte reservierte Resourcen. Statt 50USD sind es dann eben 4000. Es ist auch nicht trivial immer gleich zu wissen, ob man pro Nutzung oder pro Reservierung bezahlt.

Die gute Nachricht: Wenn man etwas so schief läuft: Alles prüfen. durchdokumentieren, sich überlegen, wie man das in Zukunft verhindert und freundlich beim Support nach Refunds anfragen. Oft gibt es eine "good will"-Lösung, da die Clound Anbieter auch kein Interesse daran haben, Firmen zu ruinieren.

@leitmedium Jo. "Günstig" sind diese Dienste nur dann, wenn man selbst solide Controlling-Arbeit reinsteckt.

Ein schnöder VPS ist da zwar erheblich weniger hip, für so manchen Anwendungsfall aber trotzdem auf einmal wieder total charmant.

@sr_rolando Ja, die generellen Kosten sind nochmal ein anderes Thema. Selber hoste ich ja immer noch bei Hetzner, mittlerweile nutze ich da die ziemlich preiswerten VPS.

@leitmedium Hetzner ist sehr solide. 👍

(Und langweilig, klar. Mir ist nur schleierhaft, warum das vielfach als Nachteil gilt.)

@leitmedium @sr_rolando kann man denn da mittlerweile auch auf die disk zugreifen? Ich kenne Hetzner VPS nur echt mit FS panic wegen lokalen disk timeouts

@tonnerre @sr_rolando Da habe ich mich nicht weiter mit beschäftigt bisher, da ich kaum disk i/o zu stemmen habe.

@leitmedium
@sr_rolando ist auch keine Frage davon, wieviel man selbst zu stemmen hat, manchmal gab es als ich das probiert habe eben einfach kein disk I/O, egal wie wenig man brauchte. Das führte halt zu I/O-Fehlern auf dem root device und dazu, dass das root device nach ein paar Minuten Timeout für tot erklärt wurde, und dann gab es eine panic.

@tonnerre @sr_rolando Ok, das geht natürlich gar nicht. Also solche Probleme habe ich bisher nicht.

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!