![\"AWS-Cloud-Migration:](\"https:\/\/www.sigmainfo.net\/wp-content\/uploads\/2026\/08\/AWS-Cloud-Migration_-What-Getting-It-Wrong-Actually-Costs.webp\" "\\"AWS-Cloud-Migration:")
<\/p>\n<\/p>\n
Die Migration wurde termingerecht abgeschlossen, es gab keine Ausf\u00e4lle und dennoch ist die monatliche Rechnung h\u00f6her als die Kosten des zuvor genutzten Rechenzentrums. Dies ist ein typisches Ergebnis einer <\/span>AWS-Cloud-Migration<\/b> die als reines Infrastrukturprojekt durchgef\u00fchrt wurde \u2013 und es handelt sich dabei nicht um ein technisches Versagen. Jeder Workload wurde erfolgreich migriert. Was jedoch nicht \u00fcbertragen wurde, war ein Mechanismus zur Steuerung der Kosten jedes einzelnen Workloads. Dadurch hat das Unternehmen kontrollierte Investitionsausgaben, die zuvor \u00fcber den Einkauf gesteuert wurden, gegen Betriebsausgaben eingetauscht, die niemand genehmigt, bevor sie entstehen. Die hier beschriebenen Kosten sind keine Migrationskosten. Es sind die Kosten einer Migration, die technisch erfolgreich war, bei der jedoch niemand die Verantwortung f\u00fcr die wirtschaftlichen Auswirkungen \u00fcbernommen hat. <\/span><\/p>\n <\/p>\n AWS-Cloud-Migration<\/b> bezeichnet die Verlagerung von Anwendungen, Daten und Infrastruktur aus einer bestehenden Umgebung zu AWS unter Verwendung einer der von AWS in seinen Migrationsrichtlinien beschriebenen Strategien. Diese reichen vom Rehosting ohne \u00c4nderungen \u00fcber Replatforming bis hin zu einer vollst\u00e4ndigen Neugestaltung der Architektur. Die technischen Aufgaben sind gut verstanden und zunehmend automatisiert. Entscheidend f\u00fcr den langfristigen Erfolg des Business Case ist jedoch die organisatorische Frage, wer Ausgaben verursachen darf. <\/span><\/p>\n On-Premises ist die Bereitstellung zus\u00e4tzlicher Kapazit\u00e4t ein Beschaffungsvorgang. Jemand fordert Hardware an, jemand genehmigt die Bestellung und ein bereits bestehender Finanzprozess setzt die entsprechenden Grenzen. Bei AWS kann zus\u00e4tzliche Kapazit\u00e4t dagegen durch einen API-Aufruf bereitgestellt werden. Ein Entwickler, der nachts um zwei Uhr ein berechtigtes Problem l\u00f6st, kann dadurch wiederkehrende Kosten f\u00fcr das Unternehmen verursachen, ohne dass zuvor eine Genehmigung erforderlich ist \u2013 und diese Kosten werden m\u00f6glicherweise erst Wochen sp\u00e4ter sichtbar. Eine Migration ohne Ersatz dieses Genehmigungsmechanismus beseitigt eine Kontrolle, deren Bedeutung zuvor kaum noch wahrgenommen wurde. Deshalb k\u00f6nnen Rechnungen steigen, obwohl jede einzelne Entscheidung f\u00fcr sich genommen nachvollziehbar war. <\/span><\/p>\n \u00dcberprovisionierung ist der erste und gr\u00f6\u00dfte Kostenfaktor. Instanzgr\u00f6\u00dfen werden h\u00e4ufig entsprechend den zu ersetzenden On-Premises-Servern gew\u00e4hlt. Diese Server wurden jedoch m\u00f6glicherweise f\u00fcr Lastspitzen dimensioniert, die nie eingetreten sind, zus\u00e4tzlich mit Sicherheitsreserven und aus Sorge vor einer zu geringen Dimensionierung. Diese \u00fcber Jahre entstandenen Reserven werden unver\u00e4ndert in die Cloud \u00fcbertragen und anschlie\u00dfend stundenweise abgerechnet. <\/span><\/p>\n Daten\u00fcbertragung ist der zweite Kostenfaktor und f\u00fcr Finanzteams h\u00e4ufig der \u00fcberraschendste, da es daf\u00fcr kein direktes On-Premises-\u00c4quivalent gibt. Datenverkehr zwischen Availability Zones, zwischen Regionen und ins Internet wird nutzungsabh\u00e4ngig abgerechnet. Architekturen, die ohne Ber\u00fccksichtigung dieser Grenzen entwickelt wurden, k\u00f6nnen daher Kosten verursachen, die in keiner Prognose ber\u00fccksichtigt wurden. Die entscheidende Kontrollma\u00dfnahme ist eine Architekturpr\u00fcfung vor dem Cutover statt einer nachtr\u00e4glichen Analyse, da eine sp\u00e4tere \u00c4nderung der Datenpfade \u00c4nderungen an der Anwendung erfordern kann. <\/span><\/p>\n Verwaiste Ressourcen sind der dritte Kostenfaktor. Migrationen erzeugen Testinstanzen, duplizierte Volumes, Snapshots und Load Balancer, und h\u00e4ufig endet das Projekt, bevor gepr\u00fcft wurde, welche davon weiterhin ben\u00f6tigt werden. Der vierte Faktor ist die schleichende Nutzung ungeeigneter Speicherklassen, bei der sich Logs und Backups unbegrenzt in kostenintensivem Speicher ansammeln, weil keine Lifecycle-Richtlinie definiert wurde. Der f\u00fcnfte Faktor ist die Lizenzierung und zugleich das gr\u00f6\u00dfte Einzelrisiko, da bestimmte kommerzielle Lizenzen auf virtualisierter Infrastruktur anderen Bedingungen unterliegen und daraus resultierende Verpflichtungen m\u00f6glicherweise erst bei einem Audit sichtbar werden. <\/span><\/p>\n Die rechte Spalte verdeutlicht, warum Programme zur Kostenoptimierung nach einer Migration h\u00e4ufig hinter den Erwartungen zur\u00fcckbleiben. Jede dieser Kontrollma\u00dfnahmen l\u00e4sst sich vor der Migration eines Workloads deutlich kosteng\u00fcnstiger implementieren als danach, und einige lassen sich im Nachhinein nur mit erheblichem Aufwand nachr\u00fcsten. Tagging ist das deutlichste Beispiel: Wird es bereits bei der Account-Erstellung eingef\u00fchrt, verursacht es praktisch keinen zus\u00e4tzlichen Aufwand. In einer bereits laufenden Umgebung muss dagegen anhand der Deployment-Historie und des Wissens von Mitarbeitern, die m\u00f6glicherweise inzwischen das Team gewechselt haben, rekonstruiert werden, wem welche Ressource geh\u00f6rt. <\/span><\/p>\n Machen Sie Kosten-Governance zu einem festen Migrationsergebnis statt zu einem sp\u00e4teren Projekt.<\/b><\/p>\nDie wichtigsten Erkenntnisse<\/h3>\n
\n
Eine AWS-Cloud-Migration ist im Kern ein Kosten-Governance-Projekt im Gewand eines Infrastrukturprojekts<\/h2>\n
![\"Nachhaltige](\"https:\/\/www.sigmainfo.net\/wp-content\/uploads\/2026\/08\/Sustainable-Cloud-Financial-Governace.webp\" "\\"Nachhaltige")
<\/p>\nF\u00fcnf Gr\u00fcnde, warum die Kosten nach einer erfolgreichen Migration steigen<\/b><\/h2>\n
\n\n
\n Fehlermodus<\/b><\/td>\n Warum er auftritt<\/b><\/td>\n Kontrollma\u00dfnahme zur Vermeidung<\/b><\/td>\n Wann sie implementiert werden sollte<\/b><\/td>\n<\/tr>\n \n \u00dcberprovisionierung<\/span><\/td>\n Unver\u00e4nderte \u00dcbernahme der On-Premises-Dimensionierung<\/span><\/td>\n Nutzungsbasiertes Right-Sizing pro Workload<\/span><\/td>\n W\u00e4hrend der Wellenplanung, vor dem Cutover<\/span><\/td>\n<\/tr>\n \n Daten\u00fcbertragungskosten<\/span><\/td>\n Zonen- und Regionsgrenzen wurden bei der Architektur nicht ber\u00fccksichtigt<\/span><\/td>\n Architekturpr\u00fcfung der Datenpfade<\/span><\/td>\n Vor dem Cutover, nicht danach<\/span><\/td>\n<\/tr>\n \n Verwaiste Ressourcen<\/span><\/td>\n Das Projekt endet vor der abschlie\u00dfenden Bereinigung<\/span><\/td>\n Verpflichtendes Tagging mit einem Verantwortlichen pro Ressource<\/span><\/td>\n Bei der Einrichtung des Accounts<\/span><\/td>\n<\/tr>\n \n Abweichung bei der Speicherklasse<\/span><\/td>\n Keine Lifecycle-Richtlinie definiert<\/span><\/td>\n Aufbewahrungsregeln gemeinsam mit dem Workload definieren<\/span><\/td>\n W\u00e4hrend der Migration dieses Workloads<\/span><\/td>\n<\/tr>\n \n Lizenzrisiken<\/span><\/td>\n Abweichende Lizenzbedingungen f\u00fcr virtualisierte Infrastruktur<\/span><\/td>\n Lizenzpr\u00fcfung im Rahmen der Bewertung<\/span><\/td>\n Bevor ein Workload ausgew\u00e4hlt wird<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n