ARCHITEKTUR · LANDING ZONE
So bauen Sie eine STACKIT Landing Zone auf
Eine STACKIT Landing Zone besteht aus einer Organisation mit Ordnern und Projekten, der Entscheidung, ob diese Projekte einer Network Area beitreten, einem Adressplan, einer Antwort für DNS und den Identitäten, unter denen Terraform läuft. Quell-Clouds geben Ihnen eine VPC und eine Kontenstruktur vor; bei STACKIT legen Sie zuerst das Projektlayout fest, denn die Grenze Ihrer Netzwerke ist das Projekt und kein VPC-Objekt. Diese Seite zeigt die Layouts, was ein echter StackToIT-Lauf von der Landing Zone verlangt und in welcher Reihenfolge Sie sie aufbauen.
Vier Möglichkeiten, das Ziel aufzuteilen
Die Varianten unterscheiden sich darin, wo die private Netzwerkgrenze liegt und wie viel vom Routing der Quelle sich nachbilden lässt. Angaben mit „Doku“ stammen aus der unten aufgeführten STACKIT-Dokumentation, Angaben mit „Lauf“ aus der weiter unten gezeigten Bewertung.
| Layout | Was Sie gewinnen | Was es Sie kostet |
|---|---|---|
| Ein Projekt, keine Network Area | Die Netzwerke eines Projekts teilen sich den Router des Projekts und erreichen einander; Security Groups gelten projektweit (Lauf). Dass das Standard-Routing von STACKIT einem gerouteten Netzwerk dieselbe Erreichbarkeit gibt wie die NAT-Route der Quelle, belegt der Lauf mit einem Test in einem Projekt außerhalb einer Network Area (eu01, 10. Oktober 2026); ein Projekt innerhalb einer Area wurde nicht getestet. | Keine private Verbindung zu anderen Projekten. Die ausgehende Adresse gehört dem Netzwerk, wird von allen gerouteten Netzwerken des Projekts geteilt und ist weder fest noch einstellbar (Lauf). Ein gemeinsamer Satz Quoten für alles. |
| Projekte in einer Network Area | Eine Area verbindet Projekte innerhalb einer Organisation auf Netzwerkebene und erleichtert die Anbindung von On-Premises-Umgebungen (Doku). Ein Netzwerk erhält seinen Adressbereich aus den Bereichen der Area, und die Routing-Tabellen aller Projekt-Router aktualisieren sich selbst (Doku). | Der Lauf hat die Standard-Routing-Tabelle einer Area nicht gelesen; sein Ersatz für eine NAT-Routing-Tabelle deckt ein innerhalb einer Area angelegtes Projekt daher nicht ab: Dieser Fall ist Ihre Entscheidung. Eigene Routing-Tabellen sind eine Opt-in-Funktion, deren Verhalten sich noch ändern kann: bis zu 20 Tabellen pro Area und 50 Routen pro Tabelle, aktiviert über ein Label beim Anlegen der Area; eine bestehende Area wird über das Help Center umgestellt (Doku). |
| Mehrere Projekte je Umgebung, in Ordnern gruppiert | Ordner gruppieren Projekte und enthalten selbst keine Ressourcen; unterstützt wird eine Ordnerebene (Doku). Quoten gelten pro Projekt und erfassen IaaS- und Cloud-Foundry-Ressourcen, nicht jede Ressource eines Projekts (Doku); ein Workload, der eigene Reserven braucht, kann deshalb ein eigenes Projekt bekommen. | Mehr Objekte, die jemand verantwortet, und mehr Rollenzuweisungen. Projekte sehen sich nicht privat, solange keine Area sie verbindet (vorige Zeile). |
| Area für gemeinsame Dienste, öffentliche Projekte für isolierte Workloads | Die Projektseite nennt zwei Projekttypen, Public und Network Area (Letzteren, sofern freigeschaltet). Beide in einer Organisation zu kombinieren, gemeinsame Dienste über die Area und isolierte Workloads außerhalb, leitet diese Seite daraus ab; als Muster beschreibt die Dokumentation es nicht. | Zwei Netzwerkmodelle im Betrieb, zwei Routing-Regelwerke zu erklären, und die Egress-Entscheidung der ersten Zeile gilt weiter für jedes Projekt außerhalb der Area. |
Der Lauf betrifft eine kleine AWS-Umgebung. Er sagt, was seine eigenen Ressourcen brauchen; ein Layout für Ihre Organisation wählt er nicht.
Eine VPC mit drei Subnetzen, umgesetzt
Eine kleine, für diese Seite geschriebene Umgebung, von StackToIT am 4. November 2026 bewertet. Links: die VPC und zwei ihrer drei Subnetze. Rechts: die zwei STACKIT-Netzwerke, die der Entwurf schreibt (die Prüfkommentare über jedem Block sind ausgelassen). Die VPC selbst erhält keinen Block, keines der Netzwerke übernimmt ihre Zone, und das Flag für öffentliche Adressen von public_a wird nicht übernommen.
resource "aws_vpc" "core" {
cidr_block = "10.40.0.0/16"
enable_dns_hostnames = true
tags = { Name = "core" }
}
resource "aws_subnet" "public_a" {
vpc_id = aws_vpc.core.id
cidr_block = "10.40.0.0/24"
availability_zone = "eu-central-1a"
map_public_ip_on_launch = true
tags = { Name = "public-a" }
}
resource "aws_subnet" "app_a" {
vpc_id = aws_vpc.core.id
cidr_block = "10.40.10.0/24"
availability_zone = "eu-central-1a"
tags = { Name = "app-a" }
}resource "stackit_network" "app_a" {
project_id = var.project_id
name = "app-a"
ipv4_prefix = "10.40.10.0/24"
ipv4_nameservers = var.default_ipv4_nameservers
labels = {
Name = "app-a"
}
}
resource "stackit_network" "public_a" {
project_id = var.project_id
name = "public-a"
ipv4_prefix = "10.40.0.0/24"
ipv4_nameservers = var.default_ipv4_nameservers
labels = {
Name = "public-a"
}
}Das Projekt ist die Grenze
Der Kommentar des Entwurfs sagt es selbst: Das Projekt ist die Grenze der VPC, und die Subnetze werden zu Netzwerken in genau diesem Projekt, geroutet vom Router des Projekts. Eine Routing-Tabelle ist eine Ressource der Area, keine des Projekts.
Gleiches Präfix, keine Zone
Jedes Subnetz wird zu einem stackit_network mit demselben IPv4-Präfix. Die Availability Zone wird nicht übernommen, weil das Netzwerk die Region bedient; Server und Volumes wählen ihre Zone.
„Öffentlich“ ist keine Subnetz-Eigenschaft
map_public_ip_on_launch hat am Netzwerk kein Gegenstück. Ein Server erhält eine öffentliche IP als eigene Ressource; das Flag steht daher als nicht übernommen im Entwurf und wird pro Server entschieden.
Geschlossener Egress ist nicht verfügbar
Der Lauf hält fest, dass STACKIT keine Möglichkeit dokumentiert, ausgehenden Zugriff für ein Netzwerk abzuschalten. Ein Subnetz ohne Internetpfad in der Quelle wird deshalb als aufgeweitet markiert und nicht stillschweigend kopiert.
Was der Lauf von der Landing Zone verlangt
Aus demselben Lauf. Links: die Adressbereiche und die Routing-Voraussetzung, wie migration/landing-zone-requirements.md sie nennt. Rechts: wie assessment.json die private DNS-Zone, die Instanzrolle und die Routing-Tabelle erfasst (ID, Klasse, Konfidenz und Ziel; die Begründungen fasst die Tabelle weiter unten zusammen).
| Resource | Attribute | Prefix |
|---|---|---|
| `stackit_network.app_a` | `ipv4_prefix` | Stated in `terraform/network.tf`: `10.40.10.0/24` |
| `stackit_network.data_a` | `ipv4_prefix` | Stated in `terraform/network.tf`: `10.40.20.0/24` |
| `stackit_network.public_a` | `ipv4_prefix` | Stated in `terraform/network.tf`: `10.40.0.0/24` |
Ranges the security group rules name (the addresses a rule lets in or out, not networks of the target):
- `10.40.0.0/24` (1 rule)
## 5. Routing
- Create the target project outside a Network Area: aws_route_table.app is replaced by STACKIT's default routing, which was observed to give a routed network the same reachability only in a project outside a Network Area (needed before the pilot){
"id": "aws_route53_zone.internal",
"class": "REDESIGN",
"confidence": "MEDIUM",
"target": {
"service": "self-managed internal DNS (e.g. CoreDNS or BIND on servers or SKE)"
}
}
{
"id": "aws_iam_role.deploy",
"class": "MANUAL_REVIEW",
"confidence": "LOW",
"target": {
"service": "STACKIT service account attached to servers"
}
}
{
"id": "aws_route_table.app",
"class": "RECONFIGURE",
"confidence": "LOW",
"target": {
"service": "implicit (STACKIT network default routing)"
}
}Bereiche werden aufgeführt, nicht erfunden
Jedes Präfix stammt aus den Quell-Subnetzen. Offene Präfixe sind markiert, mit der Variable oder Entscheidung, die sie klärt. Gleichen Sie die Liste vor dem ersten Apply mit Ihren On-Premises-Bereichen ab; dieser Überschneidungstest ist Praxis und wird vom Lauf nicht durchgeführt.
Routing ist ein Voraussetzungsschritt
Der Lauf macht aus der NAT-Routing-Tabelle einen Schritt: das Zielprojekt vor dem Pilot außerhalb einer Network Area anlegen. Der Schritt gehört dem Network Architect und steht in der Vorbereitungsphase des Plans, neben der Egress-Entscheidung und vor jedem Netzwerkblock.
Identität und DNS bleiben offen
Der Lauf schreibt keinen Service Account für die Instanzrolle und keine DNS-Zone für die private Zone. Beides wird zu einem manuellen Schritt des Ausführungsplans, und die beiden Einstellungen der privaten Zone stehen als nicht migriert in der Liste: Für keine von beiden gibt es eine 1:1-Ressource bei STACKIT.
Was die Engine klassifiziert und warum
| Quell-Konstrukt | STACKIT-Ziel | Klasse und Begründung aus dem Lauf |
|---|---|---|
| VPC | Netzwerke im Projekt, oder eine Network Area, wenn Netzwerke privat kommunizieren müssen | RECONFIGURE: STACKIT hat in seinem allgemein verfügbaren Modell kein VPC-Containerobjekt; jedes Subnetz wird zu einem Netzwerk in einem Projekt. |
| Subnetze (public, app, data) | Je ein STACKIT-Netzwerk, gleiches IPv4-Präfix | RECONFIGURE: öffentlich oder privat ist keine Subnetz-Eigenschaft. |
| Internet Gateway, NAT Gateway, Elastic IP | Implizit: Standard-Gateway und ausgehendes Source-NAT des Netzwerks | RECONFIGURE: Es gibt keine eigenen Objekte; die feste Egress-Adresse entfällt. |
| Routing-Tabelle mit NAT-Default-Route | Standard-Routing von STACKIT | RECONFIGURE, niedrige Konfidenz: Gleiche Erreichbarkeit wurde in einem Projekt außerhalb einer Network Area beobachtet; Entscheidung zur Egress-Adresse vor dem Pilot. |
| Security Group | STACKIT Security Group mit Regeln | RECONFIGURE: zustandsbehaftete Regelsätze; AWS-interne Bereiche müssen ersetzt werden. |
| Private Hosted Zone | Selbst betriebener DNS-Server, zum Beispiel auf Servern oder SKE | REDESIGN: STACKIT DNS ist ausschließlich öffentliches autoritatives DNS und lässt sich keinem Netzwerk zuordnen. |
| EC2-Instanzrolle | Service Account, am Server angehängt | MANUAL REVIEW, niedrige Konfidenz: Kein Instance Profile der Umgebung übergibt die Rolle an einen Server; der Lauf kann daher nicht erkennen, welche Server sie nutzen, und schreibt keinen Service Account. |
Klassen und Begründungen, wie der Lauf sie entschieden hat. Laut der Einführung zum DNS Resolver ist der volle Funktionsumfang möglicherweise noch nicht umgesetzt, und private Zonen erwähnt sie nicht; planen Sie interne Namen daher um einen DNS-Server, den Sie selbst betreiben.
Die Reihenfolge des Aufbaus
1. Organisation und Rollen
Die Organisation ist der oberste technische Geltungsbereich. Geben Sie dem Migrationsteam die nötigen Resource-Manager-Rollen: Project Creator und Folder Creator gibt es auf Ordnerebene, und die älteren Organisationsrollen vererben nicht nach unten an Ordner oder Projekte (Doku). Der Lauf nennt keine Organisation und nimmt keine an.
2. Ordner und Projekte
Legen Sie zuerst die Ordnerebene an (nur eine Ebene), dann die Projekte: zum Beispiel eines je Umgebung und eines für einen Workload, der eigene Quoten braucht. Der Entwurf übernimmt das Projekt aus der Variable project_id, die keinen Standardwert hat.
3. Area oder keine Area
Nutzen Sie die Tabelle oben. Wenn ein Projekt ein anderes privat erreichen muss oder On-Premises-Systeme es erreichen sollen, planen Sie eine Area. Gilt die Routing-Voraussetzung des Laufs für Sie, halten Sie das Projekt außerhalb oder entscheiden Sie die Routing-Tabelle selbst.
4. Adressplan
Legen Sie die Präfixe aus Abschnitt 4 der Anforderungsdatei fest, beseitigen Sie Überschneidungen und halten Sie die Bereiche in den Regeln Ihrer Security Groups damit im Einklang.
5. DNS und Egress
Stellen Sie den DNS-Server für interne Namen bereit und beantworten Sie die Egress-Entscheidung: die Adresse des Netzwerks akzeptieren oder jedem Server, den eine Freigabeliste nennt, eine eigene öffentliche IP geben.
6. Identitäten
Legen Sie den Service Account an, unter dem Terraform handelt. Die Anforderungsdatei sagt nur, dass die Identität die Rolle braucht, die IaaS-Ressourcen im Projekt anlegen darf. Eine Rolle nennt sie nicht; schlagen Sie sie also nach. Pipelines behandelt der CI/CD-Leitfaden.
7. Dienste und Quoten
Aktivieren Sie die Dienste aus Abschnitt 8 für Projekt und Region und prüfen Sie die Quoten für die Zahlen aus Abschnitt 9. Der Lauf nennt keine Quote und liest keine.
8. Zuerst das Fundament anwenden
Der Ausführungsplan gruppiert Netzwerke und Security Groups vor Workloads und listet die manuellen Voraussetzungen vor tofu apply auf. Führen Sie plan zuerst gegen ein Testprojekt aus.
Entscheidungen, die bei Ihren Architekten liegen
Projektlayout
Ein Projekt, mehrere oder eine Area. Der Lauf kann es nicht wählen; er kann nur berichten, was seine Ressourcen brauchen.
Egress-Adresse
Halten Sie die Antwort auf die Egress-Entscheidung vor dem Pilot fest; in diesem Lauf warten sieben Planschritte darauf.
Interne DNS-Namen
Welcher Server interne Namen beantwortet und wer ihn betreibt.
Boot-Images und Machine Types
Der Entwurf überlässt Image, Machine Type und Größe des Boot-Volumes Variablen, weil die Quelle ein AMI und einen Instanztyp nennt, aber kein STACKIT-Äquivalent.
Wer Projekte anlegen darf
Projekte anzulegen ist eine Rolle. Beschränken Sie sie auf eine kleine Gruppe und schreiben Sie die Regel auf, bevor das erste Projekt existiert.
Fragen zur Landing Zone
Hat STACKIT eine VPC?
Laut Lauf nicht als Containerobjekt im allgemein verfügbaren Modell. Ein Subnetz wird zu einem Netzwerk in einem Projekt, und der Router des Projekts verbindet dessen Netzwerke. Netzwerke verschiedener Projekte verbindet eine Network Area.
Brauche ich eine Network Area?
Nur, wenn Projekte einander privat erreichen sollen oder Sie On-Premises-Umgebungen darüber anbinden. Der Routing-Befund des Laufs spricht dafür, das früh zu entscheiden, denn eine NAT-Routing-Tabelle wird durch Standard-Routing ersetzt, dessen Erreichbarkeit nur in einem Projekt außerhalb einer Area beobachtet wurde.
Wie tief dürfen Ordner verschachtelt sein?
Eine Ebene. STACKIT unterstützt derzeit eine einzige Ordnerebene, und Ordner gruppieren Projekte, ohne selbst Cloud-Ressourcen zu halten.
Legt StackToIT Organisation und Projekte an?
Nein. Der Entwurf braucht ein Projekt und nimmt dessen ID aus einer Variable. StackToIT liest und schreibt Dateien und legt in keinem Cloud-Konto etwas an.
Was ersetzt meine Instanzrollen?
Ein am Server angehängter Service Account, den der Lauf als manuelle Prüfung mit niedriger Konfidenz kennzeichnet. Entscheiden Sie die Berechtigungen selbst und testen Sie sie an einem Server.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.