Der vollständige Leitfaden für die Migration von AWS zu STACKIT

Die sieben Schritte

Die Reihenfolge entspricht den Wellen und Arbeitspaketen des Laufs.

1. 01

   1. Den Terraform-Code bewerten

   Richten Sie StackToIT auf den Ordner mit Ihrem AWS-Terraform. Es liest Konfiguration und Module offline, baut einen Abhängigkeitsgraphen auf und weist jeder Ressource Klasse und Ziel zu. In AWS oder STACKIT wird nichts aufgerufen.

2. 02

   2. Klassen lesen und Entscheidungen klären

   DIRECT- und RECONFIGURE-Einheiten sind Routinearbeit. REPLATFORM-, CONTAINERIZE- und REDESIGN-Einheiten ändern das Programmiermodell. Kopieren Sie decisions-template.yaml, tragen Sie Ihre Antworten ein und führen Sie die Bewertung mit --decisions erneut aus; der neue Bericht zeigt, welche Antworten übernommen wurden und welche Entscheidungen noch offen sind.

3. 03

   3. Das Fundament bauen

   Legen Sie Projektstruktur, Netzwerke und Security Groups an. Im Lauf ist das Welle 2, nach der VPC-Einheit.

4. 04

   4. Daten- und Messaging-Dienste bereitstellen

   Wenden Sie die Entwürfe für PostgreSQL Flex, Valkey, RabbitMQ, MongoDB Flex und Object Storage an. Sie sind leer, bis Sie die Daten übertragen.

5. 05

   5. Die Daten übertragen

   Der Lauf schreibt je zustandsbehafteter Einheit ein Dokument zur Datenübernahme. StackToIT überträgt keine Daten; Ihr Team führt die Befehle nach einer Generalprobe aus.

6. 06

   6. Producer, Consumer und Clients umstellen

   Die Cutover-Arbeitspakete des Laufs stellen zuerst die Datenkonsumenten, dann die Clients und danach die Workloads samt Nachrichten-Producern und -Consumern um. Diese Nummerierung als Reihenfolge zu lesen, ist unsere Zusammenfassung; verbindlich sind die Vorgängerschritte, die execution/manual/actions.md für jeden Schritt nennt.

7. 07

   7. Prüfen, Rückweg offenhalten, stilllegen

   Führen Sie die Prüfungen aus, halten Sie die Rollback-Grenze fest, behalten Sie die Quelle für die beschlossene Aufbewahrungsdauer und legen Sie sie danach still.

Die Befehle hinter den Schritten

Dies sind die dokumentierten StackToIT-Befehle, jeweils wörtlich zitiert aus der darüber genannten Seite der öffentlichen Dokumentation. Der optionale Schritt discover ergänzt ein schreibgeschütztes AWS-Inventar zum Vergleich mit dem Terraform; explain führt eine Einheit auf ihre Belege zurück; verify prüft einen fertigen Lauf gegen sein Manifest.

stacktoit assess ./aws-terraform

stacktoit discover commands
stacktoit discover aws ./aws-terraform-stacktoit --region eu-central-1
stacktoit assess ./aws-terraform ./aws-terraform-stacktoit

stacktoit explain ./terraform-stacktoit 'UNIT_ADDRESS'

stacktoit verify ./terraform-stacktoit

• Standardmäßig offline

  assess selbst verbindet sich nicht mit einem AWS-Konto. discover aws nutzt Ihre lokalen AWS-CLI-Zugangsdaten und rein lesende Abfragebefehle.

• Ein Entwurf ist keine Freigabe

  Die Dokumentation sagt es ausdrücklich: Das Vorhandensein eines Terraform-Entwurfs ist keine Freigabe zum Anwenden.

Der Lauf: 12 Ressourcen, 11 Einheiten

Eine für diese Seite geschriebene Umgebung, am 4. November 2026 bewertet: eine VPC mit zwei Subnetzen, eine Security Group, eine EC2-Instanz, eine RDS-PostgreSQL-Datenbank, ein S3-Bucket, eine ElastiCache-Gruppe, eine SQS-Queue, eine Lambda-Funktion und eine DynamoDB-Tabelle. Die Klassen stammen aus der assessment.json; die DB-Subnetzgruppe geht in der Datenbank auf.

Nach Klassen: 6 RECONFIGURE, 2 REPLATFORM, 1 DIRECT, 1 CONTAINERIZE, 1 REDESIGN, alle mit mittlerer Konfidenz. Bei keiner der 11 Einheiten sind die kritischen Einstellungen schon geschlossen: 5 kommen dorthin, sobald ihre offenen Punkte beantwortet sind, 6 erfordern in diesem Build Handarbeit.

Fundament: Subnetze werden zu Netzwerken

Links die VPC mit ihren zwei Subnetzen. Rechts die beiden stackit_network-Blöcke des Entwurfs, jeweils mit der Kommentarzeile, die die nicht übernommene Availability Zone nennt; die übrigen Kommentarzeilen der Datei sind ausgelassen. STACKIT kennt kein VPC-Containerobjekt; daher bildet das Projekt, in dem der Entwurf angelegt wird, die Grenze der VPC.

resource "aws_vpc" "main" {
  cidr_block = "10.30.0.0/16"
}

resource "aws_subnet" "private_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.30.1.0/24"
  availability_zone = "eu-central-1a"
}

resource "aws_subnet" "private_b" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.30.2.0/24"
  availability_zone = "eu-central-1b"
}

# NOT CARRIED (aws_subnet.private_a): availability_zone = eu-central-1a — stackit_network has no availability zone (pinned provider): the network serves the region; servers and volumes choose their zone.
resource "stackit_network" "private_a" {
  project_id       = var.project_id
  name             = "private-a"
  ipv4_prefix      = "10.30.1.0/24"
  ipv4_nameservers = var.default_ipv4_nameservers
}

# NOT CARRIED (aws_subnet.private_b): availability_zone = eu-central-1b — stackit_network has no availability zone (pinned provider): the network serves the region; servers and volumes choose their zone.
resource "stackit_network" "private_b" {
  project_id       = var.project_id
  name             = "private-b"
  ipv4_prefix      = "10.30.2.0/24"
  ipv4_nameservers = var.default_ipv4_nameservers
}

• Gleiche Präfixe, keine Zone

  Subnetze behalten ihre IPv4-Präfixe; Adresspläne bleiben damit stabil. Die Availability Zone entfällt: Ein STACKIT-Netzwerk bedient die Region, Server und Volumes wählen ihre Zone selbst.

• Öffentlich oder privat ist keine Subnetz-Eigenschaft

  Auf STACKIT werden Servern öffentliche IP-Adressen explizit zugewiesen. Der Lauf vermerkt, dass sich ausgehender Internetzugang für ein Netzwerk nicht so abschalten lässt, wie er in einem privaten AWS-Subnetz fehlte, und lässt das als offene Entscheidung stehen.

Daten: RDS wird zu PostgreSQL Flex

Links die RDS-Instanz. Rechts die Entwurfsinstanz mit den beiden NOT-CARRIED-Kommentarzeilen, die ihr in der Datei vorangehen; die übrigen Kommentarzeilen sind ausgelassen. Flavor und Speicher werden aus der Quelle abgeleitet: 2.16 steht für 2 vCPU und 16 GiB, den kleinsten Single-Node-Flavor, der db.m6g.large abdeckt. Der Speicher wird von 100 GiB auf 108 aufgerundet, weil STACKIT Gigabyte angibt, ohne die Einheit zu definieren.

resource "aws_db_instance" "main" {
  identifier              = "app-db"
  engine                  = "postgres"
  engine_version          = "16.4"
  instance_class          = "db.m6g.large"
  allocated_storage       = 100
  db_subnet_group_name    = aws_db_subnet_group.main.name
  username                = "app"
  manage_master_user_password = true
  storage_encrypted       = true
  backup_retention_period = 7
}

# NOT CARRIED (aws_db_instance.main): db_subnet_group_name — stackit_postgresflex_instance has no subnet, availability-zone or IP-family attribute (pinned provider): clients reach the instance at the endpoint STACKIT assigns.
# NOT CARRIED (aws_db_instance.main): manage_master_user_password — the master secret in AWS Secrets Manager (managed master password) is not carried: STACKIT generates the credential (pinned provider) and has no rotation schedule; keep the new one in STACKIT Secrets Manager or the application's own store.
resource "stackit_postgresflex_instance" "main" {
  project_id = var.project_id
  name       = "app-db"
  version    = "16"
  flavor_id  = "2.16"
  storage = {
    class = var.postgresflex_storage_class
    size  = 108
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl          = var.relational_database_allowed_cidrs
    access_scope = var.relational_database_access_scope == "SNA" ? "SNA" : null
  }
  retention_days = 32
}

• Zugangsdaten ändern sich

  STACKIT erzeugt das Master-Passwort; die Anwendung erhält das neue. Einen Rotationsplan gibt es nicht zu übernehmen.

• Endpunkt statt Subnetz

  Die Instanz hat einen eigenen Endpunkt und eine Zugriffsliste; die Platzierung der Quelle in einer Subnetzgruppe wird nicht übernommen. Die Erreichbarkeit ist eine Entscheidung.

• Instanzschutz einschalten

  Die PostgreSQL-Flex-Dokumentation von STACKIT warnt: In API v3 führt das Löschen einer Instanz ohne aktiven Instanzschutz zu sofortigem, endgültigem Datenverlust. Aktivieren Sie den Schutz, bevor die Datenbank Produktionsdaten hält.

Die vom Lauf vorgeschlagene Reihenfolge

Wellen werden aus Abhängigkeiten berechnet. Einheiten derselben Welle können parallel umziehen; der Lauf nennt das einen Ausgangspunkt für Ihren Plan, keinen Terminplan.

Das Ausführungspaket enthält 24 automatisierte Schritte (18 Ressourcenblöcke und 6 API-Aufrufe) und 102 manuelle Schritte in 33 Arbeitspaketen. Von den 24 automatisierten Schritten sind 19 frei von Entscheidungen und manuellen Voraussetzungen, warten aber noch auf Werte wie project_id.

Entscheidungen Ihrer Architekten

Das Register dieses Laufs führt 26 Einträge. Diese haben die größte Wirkung.

• DynamoDB

  Auf STACKIT gibt es keinen DynamoDB-kompatiblen Dienst. Der Entwurf schlägt eine MongoDB-Flex-Instanz vor, den verwalteten MongoDB-Dienst von STACKIT, mit je einer Collection pro Tabelle; relationales JSONB auf PostgreSQL Flex ist die andere Option. In beiden Fällen wird die Zugriffsschicht neu geschrieben; Schlüsseldesign, Kapazitätsmodi und bedingte Schreibvorgänge lassen sich nicht übernehmen.

• Lambda

  Der Lauf vermerkt, dass STACKIT keinen allgemein verfügbaren Functions-Dienst hat. Der Handler läuft in einem dauerhaft laufenden Prozess: als Cloud-Foundry-App oder in einem Container. Das Ausführungsmodell wechselt von der Ausführung pro Aufruf zum Dauerbetrieb.

• Boot-Image

  Eine AMI wird durch ein STACKIT-Image ersetzt, das Sie wählen. Bis das beantwortet ist, warten Konnektivitätsprüfung und Cutover-Schritte.

• Egress und Endpunkte

  Der Entwurf hält ausgehenden Verkehr geschlossen und stellt die Datenbanken über einen öffentlichen, per Zugriffsliste beschränkten Endpunkt bereit; beides sind Vorgaben, die Sie bestätigen oder ersetzen. Füllen Sie die Zugriffslisten selbst: Laut RabbitMQ-Dokumentation von STACKIT erhält ein neuer Datendienst eine Standard-Zugriffsliste, die STACKIT-IP-Bereiche enthält.

• Verfahren für den Datenumzug

  Dump und Restore oder logische Replikation für PostgreSQL, Sync-Werkzeuge für Buckets. Die richtige Wahl hängt von Datenmenge und Schreibstopp-Fenster ab, die nicht im Terraform-Code stehen.

Fragen, die Architekten zuerst stellen

Quellen

• STACKIT-Object-Storage-Dokumentation
• STACKIT-RabbitMQ-Dokumentation
• STACKIT-PostgreSQL-Flex-Dokumentation
• STACKIT-MongoDB-Flex-Dokumentation
• StackToIT-Dokumentation: AWS zu STACKIT