GOOGLE CLOUD → STACKIT · LANDING-ZONE-DESIGN
GCP-Projekte und Shared VPC: die STACKIT-Landing-Zone entwerfen
Die Entwurfsfrage lautet nicht, wohin eine einzelne Ressource kommt, sondern wie sich die Projektgrenze verschiebt. Ein Google-Cloud-Projekt wird zu einem STACKIT-Projekt, ein Ordner zu einem Ordner, und eine Shared VPC, in der ein Host-Projekt Subnetze an Service-Projekte verleiht, zu einer Network Area mit einem Netzwerk je Projekt. StackToIT stuft die Shared-VPC-Verbindung als Redesign ein und überlässt die Hierarchie Ihnen.
Was der Entwurf klären muss
Aus einer Google-Cloud-Organisation ergeben sich vier Fragen. Der Lauf stellt jede als Entscheidung, nicht als Vorgabe.
Hierarchie
Welche Ordner und Projekte es auf STACKIT gibt und welche der Quellprojekte sich eines teilen. Der Lauf führt Hierarchie und Projektplatzierung bei jedem Ordner und Projekt als offene Einstellung.
Netzwerkbesitz
Wem die Subnetze gehören, die andere Teams nutzen. In der Shared VPC besitzt das Host-Projekt sie und Service-Projekte nutzen sie; auf STACKIT hat jedes Projekt eigene Netzwerke.
Zugriff
Wer welches Netzwerk nutzen darf. Auf Google Cloud ist das eine Rolle auf dem Host-Projekt oder einem Subnetz; auf STACKIT werden daraus Rollenzuweisungen und Security Groups.
Region und Abrechnung
Der Entwurf legt jede Einheit in eine STACKIT-Region und ein Projekt. Die Verknüpfung mit einem Abrechnungskonto und die im Projekt aktivierten Google-APIs haben im STACKIT-Projekt kein Gegenstück.
Drei Wege, es aufzubauen
Die erste Zeile folgt der Zuordnung, die der Lauf vorschlägt; die anderen sind Alternativen, die Ihre Architekten stattdessen wählen können. Aussagen zu Shared VPC stammen aus der Google-Cloud-Dokumentation, Aussagen zu STACKIT aus deren Netzwerkdokumentation.
| Variante | Was bleibt und was es kostet | Wann sie passt |
|---|---|---|
| Hierarchie spiegeln, Projekte in einer Network Area verbinden | Ordner und Projekte bleiben. Aus Host und Service wird eine Network Area mit einem Netzwerk je Projekt; die Router der Mitgliedsprojekte tauschen Routen aus, Security Groups steuern den Verkehr zwischen Projekten. Wer welches Subnetz nutzen darf, bauen Sie als Projektgrenzen und Rollenzuweisungen nach. | Mehrere Teams, klare Zuständigkeit und Workloads, die über private Adressen miteinander kommunizieren müssen. |
| Ein Projekt je Umgebung zusammenfassen | Die wenigsten beweglichen Teile: Ein Projekt hält Netzwerke und Server einer Umgebung. Die Projektgrenze zwischen Teams entfällt; die Trennung wandert in Security Groups und Rollenzuweisungen. | Kleine Umgebung, ein Plattformteam oder ein erster Pilot. |
| Projekte spiegeln, über Public IPs verbinden | Projekte bleiben standardmäßig isoliert; Verkehr zwischen ihnen braucht dann öffentliche Adressen, denn ohne Network Area verbinden nur Public IPs die Projekte. Sie behalten strikte Trennung und nehmen Wege über das Internet in Kauf. | Projekte, die wenig Verkehr austauschen und harte Isolation brauchen. |
Laut STACKIT-Dokumentation sind Projekte standardmäßig isoliert, und projektübergreifender Verkehr braucht eine Network Area oder Public-IP-Anbindung. Die Architekturseite ergänzt, dass eine Network Area innerhalb einer Region arbeitet; die Konzeptseite beschreibt sie als globale Ressource, die Sie je Region aktivieren, wobei Verkehr zwischen Regionen derzeit über das öffentliche Internet läuft.
Eine Shared-VPC-Umgebung und was der Lauf dafür geschrieben hat
Eine für diese Seite geschriebene Umgebung, am 4. November 2026 von StackToIT bewertet: ein Ordner, ein Netzwerk-Host-Projekt, ein Anwendungsprojekt, die Shared-VPC-Verbindung, ein gemeinsames Subnetz und eine VM im Anwendungsprojekt. Links die Shared-VPC-Blöcke der Eingabe mit dem gemeinsamen Netzwerk und Subnetz, rechts die einzigen Ressourcenblöcke, die der Lauf entworfen hat; die Prüfkommentare über jedem Block sind hier ausgelassen.
resource "google_compute_shared_vpc_host_project" "host" {
project = google_project.net_host.project_id
}
resource "google_compute_shared_vpc_service_project" "app" {
host_project = google_compute_shared_vpc_host_project.host.project
service_project = google_project.app_team.project_id
}
resource "google_compute_network" "shared" {
project = google_project.net_host.project_id
name = "shared"
auto_create_subnetworks = false
}
resource "google_compute_subnetwork" "app" {
project = google_project.net_host.project_id
name = "app"
network = google_compute_network.shared.id
region = "europe-west3"
ip_cidr_range = "10.30.0.0/24"
}resource "stackit_network" "app" {
project_id = var.project_id
name = "app"
ipv4_prefix = "10.30.0.0/24"
ipv4_nameservers = var.default_ipv4_nameservers
}resource "stackit_network_interface" "worker_1" {
project_id = var.project_id
network_id = stackit_network.app.network_id
}
resource "stackit_server" "worker" {
project_id = var.project_id
name = "worker-1"
machine_type = var.worker_machine_type
availability_zone = var.availability_zone
boot_volume = {
source_type = "image"
source_id = var.worker_image_id
size = 50
delete_on_termination = true
}
network_interfaces = [stackit_network_interface.worker_1.network_interface_id]
}Subnetz und VM sind entworfen
Das Subnetz wird zu einem STACKIT-Netzwerk mit demselben Bereich, die VM zu einem Server mit Netzwerkschnittstelle.
Ordner, Projekte und die Shared-VPC-Verbindung nicht
Dafür schreibt der Lauf keinen Block. Jedes ist ein manueller Schritt des Plans, mit den Einstellungen, die darüber entscheiden: Hierarchie, Projektplatzierung, Projektkennung, Host- und Service-Projekt-Identität.
Alles landet in einem Projekt
Der Entwurf legt alle Ressourcen in einem Projekt und einer Region an, gesetzt über Variablen. Der Lauf sagt, dass die Quelle das Projekt aus zwei verschiedenen Stellen setzt und Sie festlegen müssen, wie die Projekte abgebildet werden.
Was der Lauf je Einheit entschieden hat
Zehn Ressourcen wurden gelesen, sieben wurden Migrationseinheiten. Die beiden IAM-Bindungen (Netzwerknutzer auf dem Subnetz, Editor auf dem Anwendungsprojekt) sind Hilfsressourcen, die der Lauf prüfen lässt, aber nicht schreibt; auch die Service-Projekt-Verknüpfung ist keine eigene Einheit.
| Google-Cloud-Ressource | STACKIT-Ziel im Lauf | Migrationsklasse |
|---|---|---|
| Ordner | STACKIT-Ordner, über ein übergeordnetes Element platziert; STACKIT dokumentiert Stand November 2026 eine Ordnerebene, und laut dem Lauf gelten Rollen auf einem Ordner für seine Projekte | Rekonfigurieren |
| Projekte (Host und Anwendung) | STACKIT-Projekt, Labels werden übernommen; Abrechnungskonto und aktivierte APIs haben kein Gegenstück | RECONFIGURE, niedrige Konfidenz |
| Shared-VPC-Host-Projekt | STACKIT Network Area mit einem Netzwerk je Projekt | REDESIGN, niedrige Konfidenz |
| VPC-Netzwerk | Projektnetzwerk; der Lauf braucht dafür keine eigene Ressource | RECONFIGURE, niedrige Konfidenz |
| Subnetz | STACKIT-Netzwerk mit demselben IPv4-Bereich | RECONFIGURE, niedrige Konfidenz |
| VM | STACKIT-Server | RECONFIGURE, niedrige Konfidenz |
Sechs der sieben Einheiten haben niedrige Konfidenz. Jede verweist auf einen Ordner oder ein Projekt, das der Entwurf nicht anlegt, und der Lauf vermerkt, dass nicht bewertet ist, was aus einem solchen Verweis wird; zudem ist der Provider nicht per Lock-Datei festgelegt.
Entscheidungen Ihrer Architekten
Jeder Punkt ist ein manueller Schritt oder eine offene Einstellung in execution/manual/actions.md und engineering/architect-report.md.
Projektzuordnung
Entscheiden Sie, ob die Quellprojekte zu einem oder mehreren STACKIT-Projekten werden, und bestätigen Sie das Projekt, in dem das Netzwerk entsteht. Genau das fragt der Lauf für das Subnetz.
Ordner- und Projektplatzierung
Legen Sie Ordner und Projekte von Hand oder mit eigenem Terraform an; der Entwurf enthält dafür keinen Block.
Umfang der Network Area
Entscheiden Sie, welche Netzwerke einer Area beitreten. Die Bereiche der Netzwerke in einer Area stammen aus den Bereichen der Area; planen Sie den Adressraum zuerst.
Zugriff übersetzen
Im Beispiel hat das App-Team die Netzwerknutzer-Rolle nur auf dem Subnetz app und die Editor-Rolle auf dem eigenen Projekt. Bauen Sie beides als STACKIT-Rollenzuweisungen nach; der Lauf führt Rollenbindungen auf Projektebene als offene Einstellung des Anwendungsprojekts und legt die Subnetz-Bindung zur Prüfung vor.
Ausgangsweg
Der Lauf konnte nicht belegen, wie das Subnetz ins Internet kommt, denn die VM hat keine externe Adresse und es ist kein NAT zu sehen. Legen Sie den ausgehenden Weg für das neue Netzwerk fest.
Region und Datenhaltung
Bestätigen Sie die eine STACKIT-Region für die ganze Umgebung. Der Lauf bildet keine Google-Region auf eine STACKIT-Region ab und lässt eine Person bestätigen, dass die gewählte Region den Datenstandort von europe-west3 hält; Zonen werden ebenso gewählt.
Fragen von Plattformteams
Wird ein Google-Cloud-Projekt zu einem STACKIT-Projekt?
Ja, das ist die Zuordnung, die StackToIT vorschlägt: Ein Projekt wird zum STACKIT-Projekt, ein Ordner zum Ordner. Abrechnungsverknüpfungen und aktivierte APIs werden nicht übernommen, und der Entwurf legt die Projekte nicht an; Sie platzieren sie.
Was ersetzt eine Shared VPC?
Eine Network Area mit einem Netzwerk je Projekt. Auf Google Cloud verleiht das Host-Projekt Subnetze an Service-Projekte; auf STACKIT besitzt jedes Projekt seine Netzwerke, und die Area verbindet sie über ein Transfernetzwerk.
Warum schreibt der Lauf hier so wenig Terraform?
Weil die Landing Zone vor allem aus Entscheidungen besteht. Nur Subnetz und VM wurden entworfen; Ordner, Projekte und die Shared-VPC-Verbindung sind manuelle Schritte, die zuerst Ihre Architekten klären.
Können wir mit einem Projekt beginnen und später teilen?
Ja, als erster Schritt. Die Variante mit einem Projekt je Umgebung hat die wenigsten beweglichen Teile, und der Lauf steht ihr nicht im Weg. Workloads später zwischen Projekten zu verschieben ist Aufwand, den Sie einplanen; wählen Sie die Grenze deshalb mit den Teams im Blick.
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.