Auf dem AWS Summit Hamburg wurde wieder deutlich, was im Bereich Cloud, KI und Datensouveränität als Nächstes auf die deutsche Industrie zukommt. Im Gespräch mit Industrie-Entscheidern kehren dabei drei Fragen immer wieder — und an ihnen entscheidet sich, ob eine Migration trägt oder im Sand verläuft.
„Migration klingt gut — aber wo fangen wir an?”
Nicht bei der Technologie, sondern bei der Bestandsaufnahme. Welche Workloads tragen das Geschäft? Welche sind eng gekoppelt, welche lassen sich isoliert verschieben? Eine tragfähige Migration beginnt mit einer ehrlichen Einordnung der Anwendungslandschaft und einer Reihenfolge, die mit dem geringsten Risiko startet — nicht mit dem größten System.
„Wie bleiben wir auf AWS compliant und souverän?”
Datensouveränität ist in der deutschen Industrie kein Nice-to-have. Sie wird auf Architekturebene entschieden: Region, Verschlüsselung, Zugriffskontrolle und Nachvollziehbarkeit gehören in das Fundament, nicht in eine nachgelagerte Prüfung. Wer Compliance erst nach der Migration adressiert, baut zweimal.
„Sinken die Kosten wirklich — oder verlagern sie sich nur?”
Beides ist möglich. Eine Migration, die nur verschiebt, was vorher im Rechenzentrum lief, verlagert die Kosten lediglich. Eine Migration, die die Architektur am tatsächlichen Bedarf ausrichtet — elastische Skalierung, passende Instanztypen, abgeschaltete Leerlast — senkt sie. Der Unterschied liegt nicht in der Cloud, sondern im Schnitt der Architektur.
Die richtige Architektur zuerst
Jede dieser Fragen hat eine klare Antwort — vorausgesetzt, man startet mit der richtigen Architektur. Wer eine AWS-Migration plant oder bereits migrierte Workloads optimieren möchte, sollte mit dem Schnitt der Architektur beginnen, nicht mit der Technologie.