---
title: "Google-Cloud-Beratung und GCP-Migration | SKAFFON"
description: "Google-Cloud-Beratung von SKAFFON: Landing Zone mit Ressourcenhierarchie, Shared VPC und VPC Service Controls, GKE, Migration und Betrieb."
url: https://skaffon.de/cloud/google-cloud-beratung/
---
![Weitläufige Rechenzentrumshalle mit Doppelboden, Serverschränken und blau gebündelten Netzwerkkabeln unter der Decke](/_astro/rechenzentrum-halle-doppelboden.CatmWoCO_Z1kKYxg.jpg) 

1. [Startseite](/)
2. [Cloud](/cloud/)
3. Google-Cloud-Beratung und GCP-Migration

Google Cloud

# Google-Cloud-Beratung und GCP-Migration

Ob Sie Workloads nach Google Cloud verlagern oder eine gewachsene Projektlandschaft ordnen wollen: SKAFFON entwirft die Landing Zone, migriert und betreibt, von Organisation und Netzwerk bis GKE und Cloud SQL.

[Projekt anfragen](/projekt-anfragen/) [Landing-Zone-Workshop ansehen](/cloud/google-cloud-beratung/#sieben-entscheidungen-bis-zur-landing-zone) 

- Landing Zone als Code (Terraform oder OpenTofu)
- Entscheidungen vorab als Workshop-Ergebnis dokumentiert
- Betrieb auf Wunsch aus einer Hand

Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 

Für CTOs und Platform-Teams

## Google Cloud lohnt sich bei Containern, Daten und Google-Diensten

Die Plattform passt, wenn Ihre Workloads stark auf Container und Datenverarbeitung ausgerichtet sind, wenn bestimmte Google-Dienste benötigt werden oder wenn Landschaft und Team schon dort liegen. Typisch sind Daten- und Container-Workloads, die auf Google Kubernetes Engine (GKE) und verwalteten Datenbanken wie Cloud SQL laufen sollen.

Bei strengen Vorgaben zu Datenstandort und Betreiberkontrolle vergleichen Sie zuerst Alternativen: [Cloud-Übersicht](/cloud/), [STACKIT](/stackit/), [souveräne Cloud](/infrastruktur/souveraene-cloud/).

Rechtsfragen zum Anbieterkonzern

Diese bewertet Ihr Datenschutz, gegebenenfalls mit Rechtsberatung. Sie sind nicht Teil unserer Leistung.

Beispielstruktur

## Organisation, Ordner, Projekte und Netz auf einen Blick

Die Ressourcenhierarchie mit Organization Policies und das Shared-VPC-Netz je Umgebung samt VPC-Service-Controls-Perimeter um sensible Projekte.

 Beispielstruktur, im Workshop an Ihre Organisation anzupassen. 

 Beispielstruktur, im Workshop an Ihre Organisation anzupassen. 

Workshop-Katalog

## Sieben Entscheidungen bis zur Landing Zone

Google nennt in der Dokumentation zum [Landing-Zone-Design](https://docs.cloud.google.com/architecture/landing-zones) vier Kernelemente: Identitätsbereitstellung, Ressourcenhierarchie, Netzwerk und Sicherheitskontrollen. Eine einzige Standardumsetzung gibt es laut Google nicht; die Entscheidungen hängen von Branche, Organisation, Compliance, Workloads und Bestand ab. Unser Workshop arbeitet die Felder in dieser Reihenfolge ab, jeweils mit einem Ergebnisartefakt.

1. 01  
### Wer darf was, auf welcher Ebene?  
Identität  
Wie werden Ihre Benutzer und Gruppen bereitgestellt (Cloud Identity, Synchronisation mit Ihrem bestehenden Identitätsanbieter)? Wer erhält welche IAM-Rollen auf welcher Ebene? Ergebnis: Rollenmodell mit Gruppen statt Einzelrechten.
2. 02  
### Wie schneiden wir Organisation, Ordner und Projekte?  
Hierarchie  
Umgebungen, Teams und Anwendungen bekommen ihren Platz; dazu klären wir, wo Organisationsrichtlinien (Organization Policies) greifen. Ergebnis: Hierarchieentwurf mit Richtlinienzuordnung je Ebene.
3. 03  
### Adressplan und Anbindung an Ihr Netz  
Netzwerk  
IP-Adressbereiche je Umgebung, Shared VPC und die Verbindung zu Ihrem Standort oder Rechenzentrum. Ergebnis: Adressplan und Konnektivitätskonzept (Details im Abschnitt zur Anbindung).
4. 04  
### Braucht Ihr Datenschutz-Ziel einen Perimeter?  
Sicherheit  
Perimeter mit VPC Service Controls schützen gegen Datenabfluss. Ergebnis: Perimeter-Entwurf und Ausnahmeprozess.
5. 05  
### Monitoring, Backup und Kosten im Blick  
Betrieb  
Monitoring und Logging, Backup und Wiederherstellung, Kostenkontrolle. Ergebnis: Betriebskonzept.
6. 06  
### Eine Landing Zone oder mehrere, und womit beginnen?  
Umfang  
Braucht es mehr als eine Landing Zone, und welche Elemente teilen sich? Welche Workloads kommen zuerst, was folgt später? Ergebnis: priorisierte Roadmap.
7. 07  
### Beispielaufbau oder maßgeschneidert bauen  
Bereitstellung  
Google nennt als Optionen unter anderem das Terraform-Beispiel „example foundation“ (ein bewusst stark vorgegebener Landing-Zone-Aufbau), Terraform-Blueprints (Module für Google-Cloud-Ressourcen) und die Konsolenanleitung. Wir empfehlen Infrastructure as Code mit CI/CD und GitOps und wählen mit Ihnen, ob wir mit dem Beispielaufbau starten oder maßgeschneidert bauen. Ergebnis: Repository-Struktur und Pipeline.

Netzwerk und Konnektivität

## Ihr Netz und Google Cloud sauber verbinden

Das Netzwerk ist die Entscheidung, die sich später am schwersten ändern lässt. Im Workshop legen wir fest:

- **Shared-VPC-Netze** je Umgebung (Produktion, Entwicklung, Test)
- **VPC-Firewall-Regeln**, Cloud NAT und Cloud DNS
- **Anbindung an Ihr Netz** über Cloud Interconnect (Dedicated oder Partner) oder Cloud VPN

[Mehr zu Cloud Security](/cybersecurity/cloud-security/)

![Türkisfarbene Glasfaser-Patchkabel mit LC-Steckern an einem Netzwerkgerät in einem Rechenzentrum](/_astro/tuerkisfarbene-glasfaser-patchkabel-steckern.CE_LJkRZ_ZValh6.jpg) 

GKE-Betriebsmodus

## Autopilot oder Standard: Wer steuert was?

Laut [GKE-Dokumentation](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/choose-cluster-mode) gibt es zwei Betriebsmodi. Google empfiehlt Autopilot für die meisten Produktionsworkloads, sofern Ihre Anwendung nicht Rechte oder Konfigurationen braucht, die Autopilot einschränkt.

__Vergleich der GKE-Betriebsmodi Autopilot und Standard nach Google-Dokumentation__
| Aspekt                            | Autopilot                                                           | Standard                                                      |
| --------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------- |
| Infrastruktur und Pod-Platzierung | GKE verwaltet den Großteil                                          | Sie steuern Node-Pools, Skalierung und Pod-Platzierung selbst |
| Pod-Konfiguration                 | Best Practices als Standard, zum Beispiel keine privilegierten Pods | Pods frei konfigurierbar                                      |
| Workloads im Cluster              | Autopilot-Workloads laufen auch in Standard-Clustern                | Standard-Workloads laufen nur in Standard-Clustern            |

Modellwahl

## Drei Fragen entscheiden den GKE-Modus

Unsere Prüfreihenfolge, bevor wir Cluster zuschneiden:

1. 01  
### Privilegierte Container, Spezial-Treiber oder Knotenzugriff?  
Dann Standard, oder gemischter Betrieb über Compute Classes (siehe Google-Dokumentation).
2. 02  
### Soll Ihr Team keinen Knotenbetrieb übernehmen?  
Dann Autopilot.
3. 03  
### Lässt sich der Bedarf trennen?  
Autopilot-Workloads können auch in Standard-Clustern laufen, Standard-Workloads nur in Standard-Clustern. Das beeinflusst, wie wir Cluster zuschneiden.

Verantwortung

## Google betreibt die Plattform, Sie behalten die Hoheit

Google betreibt die Plattform, Sie verantworten Konfiguration, Identitäten, Daten und Anwendungen. Wir arbeiten mit rollenbasiert und zeitlich begrenzten Rechten. Anwendungslogik und Fachdaten verändern wir nicht ohne eigenen Auftrag.

![Nahaufnahme von Serverlüftern und Kühlleitungen in einem Rechenzentrum](/_astro/serverluefter-kuehlung-nahaufnahme.DM_N3EOx_ZhkSBQ.jpg) 

Umsetzung

## Von der Landing Zone bis zum laufenden Betrieb

Alle Ressourcen beschreiben wir als Code (Terraform oder OpenTofu): [Infrastructure as Code](/leistungen/infrastructure-as-code/).

- ### Architektur und Landing Zone  
Identität, Hierarchie, Netzwerk und Sicherheitskontrollen nach dem Workshop-Katalog oben.
- ### [Migration nach GCP](/leistungen/cloud-migration/)  
Vorgehen wie in der [Cloud-Migration](/leistungen/cloud-migration/); Datenbanken ergänzend: [Datenbankmigration](/daten/datenbank-migration/).
- ### GKE einführen  
Einführung und Betriebsmodell: [Kubernetes-Beratung](/leistungen/kubernetes-beratung/); Betrieb optional über [Managed Kubernetes](/managed-services/managed-kubernetes/).
- ### [Betrieb](/managed-services/cloud-betrieb/)  
Überwachung, Updates, Wiederherstellung: [Cloud-Betrieb](/managed-services/cloud-betrieb/).
- ### IAM, Perimeter, Datenabfluss  
Rollenmodell, Perimeter und Schutz vor Datenabfluss: [Cloud Security](/cybersecurity/cloud-security/).

Kosten und Aufwand

## Was Ihre Google-Cloud-Kosten und unseren Aufwand bestimmt

Google weist in der Moduswahl darauf hin, dass der Modus die Abrechnung beeinflusst; Details stehen auf der GKE-Preisseite des Anbieters. In der Beratung bewerten wir diese Kostentreiber:

- Zahl der Projekte und Umgebungen
- Zahl der Cluster
- Netzwerk-Egress
- Datenbanken
- Auslastung und Reservierungen
- Hybrid-Anbindung
- Sicherheits- und Nachweisanforderungen
- Zahl und Art der Workloads
- Anteil von Beratung, Umsetzung und Betrieb

Abgrenzung

## Wofür Sie uns beauftragen und wofür nicht

### Das bekommen Sie von SKAFFON

- Architektur, Landing Zone und Migration auf Google Cloud.
- Kubernetes-Einführung mit GKE, auf Wunsch mit Betrieb.

### Das bekommen Sie nicht

- Lizenzwiederverkauf.
- Eine Preisbewertung ohne Architektur.
- Eine Lösung, wenn Datenstandort und Betreiberkontrolle einen US-Anbieterkonzern ausschließen.
- Plattformaufbau für eine einzelne kleine Anwendung ohne Plattformbedarf.

Anfrage

## Ihre Workloads, Projekte und Randbedingungen

Beschreiben Sie Ihre Workloads, vorhandene Projekte und die wichtigsten Randbedingungen.

[Projekt anfragen](/projekt-anfragen/) [Cloud-Übersicht](/cloud/)
