Die 10 teuersten Fehler, die ihr bei der Migration eurer DevOps-Tools zu AWS vermeiden solltet

Mein Team hat Unternehmen auf diesem Weg schon oft begleitet und gesehen, welche Fehler dabei gemacht werden.

Damit ihr dieselben Fehler vermeidet, habe ich die häufigsten für euch zusammengefasst – und erklärt, was ihr tun könnt, um sie zu vermeiden. Lest weiter und schützt euch vor Fehlern, die dazu führen, dass ihr:

• für Services bezahlt, die ihr nicht braucht oder nutzt

• später mehr Wartungsaufwand habt

• dieselben alten Ineffizienzen in die Cloud migriert

• Funktionen verpasst, die euch das Leben deutlich erleichtern könnten

• zusätzlichen Aufwand auf euch nehmt, den ihr problemlos als Managed Service erhalten könntet

für Services bezahlt, die ihr nicht braucht oder nutzt

später mehr Wartungsaufwand habt

dieselben alten Ineffizienzen in die Cloud migriert

Funktionen verpasst, die euch das Leben deutlich erleichtern könnten

zusätzlichen Aufwand auf euch nehmt, den ihr problemlos als Managed Service erhalten könntet

Lasst uns einsteigen.

1. Datenbanken zu AWS migrieren, ohne alternative Datenbank-Engines zu prüfen

Die bestehende Datenbank einfach zu AWS zu migrieren, ohne Alternativen zu prüfen, ist bei der Cloud-Migration die einfachste Option. Ihr nehmt eure bestehende Datenbank und verschiebt sie unverändert in die Cloud.

Das kann jedoch ein kostspieliger Fehler sein, denn oft könnt ihr andere Datenbanken ohne Lizenzkosten nutzen.

Ein Beispiel

Angenommen, ihr habt eine Microsoft-SQL-Server-Datenbank. Wenn ihr stattdessen einen AWS-Managed-Datenbankservice namens RDS nutzt, könnt ihr möglicherweise allein bei einem Server Zehntausende Dollar pro Jahr sparen.

Macht stattdessen Folgendes

Prüft, ob ihr eure teure Datenbank auf eine günstigere Alternative migrieren könnt. AWS stellt dafür Tools bereit. Ich persönlich empfehle AWS Babelfish für Aurora PostgreSQL. Mit diesem Tool kann eure Anwendung mit einer AWS-Aurora-PostgreSQL-Datenbank kommunizieren, selbst wenn sie für Microsoft SQL Server entwickelt wurde – mit geringen oder ganz ohne Codeänderungen.

AWS bietet auch weitere Tools für die Datenbankmigration, etwa das AWS Schema Conversion Tool. Die von AWS verwalteten Datenbanken werden vollständig von AWS betreut. Das spart euch Zeit und bringt viele weitere Vorteile.

2. Server einfach als EC2s zu AWS migrieren, ohne zu prüfen, welche AWS-Services genutzt werden können

Migriert nicht zu EC2, wenn ein geeigneter Managed oder serverloser Service dieselbe Aufgabe erfüllt, ohne dass ihr einen Server warten und patchen müsst. Reduziert Komplexität, wo immer es möglich ist.

Ein Beispiel

Wenn ihr eine AWS-RDS-Datenbank nutzt, übernimmt AWS das Patchen und kümmert sich um Redundanz, sofern ihr diese Option aktiviert. Natürlich gibt es Ausnahmen, die ihr prüfen müsst.

Möglicherweise verschwendet ihr Geld und Arbeitskraft, die ihr an anderer Stelle besser einsetzen könntet. Stellt euch vor, ihr hättet einen Service in der Cloud, den ihr nie patchen, aktualisieren oder warten müsst und der seine Aufgabe trotzdem erfüllt.

AWS bietet viele Managed Services, die euch das Leben erleichtern können. Sie nicht zu prüfen, wäre ein Fehler.

Macht stattdessen Folgendes

Um das zu vermeiden, solltet ihr prüfen, welche Managed und serverlosen Services AWS anbietet, die eure Workload einfacher verwaltbar machen könnten. Überlegt zum Beispiel, was es für euch bedeuten würde, Managed Databases von AWS oder einen serverlosen Kubernetes-Cluster von AWS zu nutzen.

Nutzt ihr einen Message-Queuing-Service? AWS bietet einige verschiedene Managed Solutions, die ihr in Betracht ziehen könntet. Damit müsstet ihr dafür keine Server verwalten.

3. Kosten nicht verwalten

AWS kann schnell teuer werden, wenn ihr die Kosten nicht genau überwacht. Vielleicht haben eure Entwickler für einen Test einige teure Server gestartet und vergessen, sie zu beenden. Oder ihr löscht Backups nicht korrekt, sodass sich die Kosten summieren.

Ein Beispiel

Stellt euch vor, ihr stellt nach einigen Monaten fest, dass eure monatlichen Kosten kontinuierlich gestiegen sind, die monatlichen Erhöhungen aber zu gering waren, um sie zu bemerken. Ihr erkennt, dass Ressourcen ungenutzt herumliegen und Kosten verursachen, obwohl sie hätten gelöscht werden sollen.

Dadurch sind eure monatlichen Kosten jetzt deutlich höher als zuvor, weil ihr für Dinge bezahlt, die ihr nicht nutzt.

Macht stattdessen Folgendes

AWS bietet Tools, mit denen ihr eure Kosten überwachen könnt und die euch warnen, wenn etwas ungewöhnlich erscheint. Ihr müsst diese Tools jedoch aktivieren.

Auch Drittanbieter-Tools können eure Cloud-Kosten überwachen, euch Empfehlungen geben und Bereiche aufzeigen, in denen ihr Kosten sparen könnt.

Vielleicht nutzt ihr einige Server nur von Montag bis Freitag. Könnt ihr sie über das Wochenende stoppen, um Geld zu sparen? Denkt daran: Bei AWS bezahlt ihr für die Zeit, in der eure Ressourcen laufen. Wenn ihr einen Server stoppt, zahlt ihr nicht mehr für diese Compute-Zeit.

Ein EC2-Windows-Server ist zudem doppelt so teuer wie ein EC2-Linux-Server, da ihr für eine Windows-Lizenz bezahlt. Vermeidet Windows, wenn möglich, um Kosten zu senken.

Scheut euch nicht, neue Instance-Typen wie AMD-basierte Instances oder AWS Graviton auszuprobieren. AMD ist in der Regel 5–10 % günstiger als Intel. Mit AWS Graviton könnt ihr noch mehr sparen, wenn eure Anwendung auf ARM-CPUs läuft.

Führt mit eurer Anwendung Benchmarks für die verschiedenen Instance-Typen durch und prüft, was für euch am besten funktioniert.

4. Nicht berücksichtigen, dass sich die Anforderungen an die Instance-Größe im Laufe der Zeit ändern können

Einige Anwendungen und Services nutzen kein Auto-Scaling, daher müsst ihr einen Instance-Typ und eine Größe auswählen. Der Compute-Bedarf eines Servers kann sich jedoch im Laufe der Zeit ändern. Vielleicht hatte ein bestimmter Server vor einigen Monaten eine hohe Auslastung, ist inzwischen aber nur noch gering ausgelastet.

Das kann bedeuten, dass ihr für eine große Instance bezahlt, obwohl eine kleinere vollkommen ausreichen würde. Ihr zahlt AWS nun deutlich mehr als nötig, obwohl eine so einfache Maßnahme wie das Verkleinern des Servers eure Serverkosten um die Hälfte oder sogar mehr senken kann!

Ein Beispiel

Vielleicht habt ihr eine AWS-RDS-Datenbank, die ihr verkleinern könnt, oder eine Anwendung, die auf einem EC2-Server läuft und nur 10 % der verfügbaren Ressourcen nutzt.

Macht stattdessen Folgendes

Überprüft eure Instance-Größen mehrmals im Jahr erneut, um sicherzustellen, dass ihr nicht mehr bezahlt als nötig. AWS bietet dafür kostenlose Tools, und auch Drittanbieter-Tools können euch bei der Verwaltung von Instance-Größen unterstützen.

5. Kosten für Datenübertragungen nicht berücksichtigen

Die Datenübertragung in AWS kostet je nach Quelle und Ziel oft Geld. Die Datenübertragung aus dem Internet zu AWS ist kostenlos, aber für das Senden von Daten fallen Kosten an, zum Beispiel:

• von AWS ins Internet

• von einer Availability Zone in eine andere

• in eine andere AWS-Region

von AWS ins Internet

von einer Availability Zone in eine andere

in eine andere AWS-Region

Wenn ihr das nicht berücksichtigt und AWS nutzt, kann euch eure Rechnung unangenehm überraschen.

Ein Beispiel

Wenn ihr beispielsweise einen On-Premise-Server habt, der viele Terabyte an Daten aus AWS abruft, kann das teuer werden.

Macht stattdessen Folgendes

Schätzt eure Netzwerkkosten, bevor ihr mit dem Aufbau beginnt. Vielleicht gibt es eine bessere Architektur für eure Lösung. Möglicherweise lässt sich der Server, der viele Daten von AWS in die On-Premise-Umgebung herunterlädt, in die Cloud verlagern?

6. Entwickler deployen unnötig teure Services und Server

Wenn ihr einen Server oder Service in AWS deployt, ist es sehr wichtig, dass eure Entwickler die Kosten dessen verstehen, was sie deployen.

Ein Beispiel

Wenn ihr einen Microsoft SQL Enterprise Server mit 16 CPU-Kernen deployt, kostet das etwa 5.000 US-Dollar pro Monat. Viele Services lassen sich mit großen Instanzen und kostspieligen Konfigurationsoptionen bereitstellen, etwa mit sehr schnellem, aber teurem Speicher.

Macht stattdessen Folgendes

Stellt sicher, dass eure Entwickler die Kosten dessen verstehen, was sie in AWS deployen. In der Cloud lässt sich die Servergröße später einfach erhöhen. Startet nicht mit einem großen, überdimensionierten Server, wie ihr es möglicherweise On-Premise tun würdet.

Richtet außerdem Warnmeldungen für unerwartete Kostensteigerungen ein, damit ihr Fehler erkennt, bevor sie teuer werden.

7. Keinen soliden und umsetzbaren Plan erstellen

Erstellt einen soliden und umsetzbaren Plan – und hofft auf das Beste, seid aber auf das Schlimmste vorbereitet.

Ein Beispiel

Manche Unternehmen beginnen damit, AWS zu testen, und daraus wird ein POC. Später wird dieser POC zur Produktionsumgebung. Dann sind Entwicklungs-, Validierungs- und Produktionsumgebungen wahrscheinlich vermischt – und ihr habt ein Chaos geschaffen.

Macht stattdessen Folgendes

Erstellt einen Plan und baut eine Landing Zone auf. Ihr braucht ein solides Fundament, um eure Umgebung aufzubauen und weiterzuentwickeln. Das ist anfangs teurer, aber ihr erspart euch, eure Umgebung später neu aufbauen zu müssen. Am Ende spart ihr Geld und verfügt über eine sicherere Umgebung, die Best Practices folgt.

8. Sich in eure Server/Services verlieben

Oft bleiben Server und Services länger bestehen als nötig, weil ihr sie in Zukunft vielleicht noch brauchen könntet.

Dadurch zahlt ihr mehr als nötig. Über ein Jahr hinweg summieren sich diese Kosten meist zu einem beträchtlichen Betrag.

Gebt euren Servern/Services keine Namen und verliebt euch nicht in sie. Sie sind austauschbar. Seid mutig und beendet eure wertvollen Ressourcen.

Macht stattdessen Folgendes

In AWS könnt ihr einen Server schnell aus einem Backup wiederherstellen. Wenn ihr Server löschen möchtet, wartet nicht zu lange damit, ungenutzte Instanzen zu beenden. Erstellt ein Backup und löscht den Server. Für jede Stunde, die euer Server weiterläuft, entstehen unnötige Kosten.

9. Nicht verstehen, dass (fast) alles etwas kostet

Ein kleiner Kostenpunkt mag unbedeutend erscheinen, doch all diese kleinen Kosten summieren sich zu einer hohen Rechnung.

Ein Beispiel

Eine Elastic IP ist kostenlos, wenn sie einer NIC- oder EC2-Instanz zugewiesen ist. Andernfalls entstehen dafür stündlich Kosten.

• Ein paar herumliegende EBS-Volumes

• Ein paar alte Snapshots

… all diese Dinge verursachen einzeln vielleicht keine hohen Kosten, können sich zusammen aber schnell auf Tausende von Dollar summieren.

Macht stattdessen Folgendes

Stellt sicher, dass ihr Ressourcen entfernt, sobald ihr sie nicht mehr benötigt. Auch ein Drittanbieter-Tool kann dabei helfen und euch an ungenutzte Ressourcen erinnern.

10. Nicht erkennen, dass die Migration eine gute Gelegenheit zum Aufräumen bietet

Es mag verlockend (und einfacher) sein, eure bestehende On-Premises-Umgebung unverändert in die Cloud zu verschieben. Doch dies ist die perfekte Gelegenheit, aufzuräumen, unnötige oder überdimensionierte Umgebungen abzuschaffen und zu konsolidieren.

Ein Beispiel

Vielleicht migriert ihr Server, die ihr gar nicht nutzt. Möglicherweise könnt ihr etwas in AWS anders aufbauen und die Kosten dadurch deutlich senken.

Macht stattdessen Folgendes

Nutzt den Umzug in die Cloud, um nicht benötigte Server zu entfernen und eure Umgebung zu optimieren. Das hängt mit einigen der vorherigen Punkte zusammen, verdient aber einen eigenen Platz auf unserer Liste, weil es so wichtig ist und so oft übersehen wird.

Zusammenfassung

Wir haben so vielen Unternehmen dabei geholfen, ihre DevOps-Toolchains zu AWS zu migrieren, dass wir schon alles gesehen haben. Hoffentlich helfen euch diese häufigen Fehler dabei, die entsprechenden Lektionen nicht auf die harte Tour lernen zu müssen.

Mit den Worten von Otto von Bismarck:

„Nur ein Narr lernt aus seinen eigenen Fehlern. Der Weise lernt aus den Fehlern anderer.“

Viel Erfolg bei der Migration!

Hört euch den Podcast hier an