Skip to content
ViganoLabs Dokumentation

Landing Zones

Was ist eine Landing Zone?

Section titled “Was ist eine Landing Zone?”

Eine Landing Zone ist die standardisierte Zielumgebung für Workloads. Sie umfasst nicht nur Netzwerk, sondern auch:

  • Identität und Rollenmodell
  • Policies/Guardrails
  • Logging/Monitoring-Anbindung
  • Namens-/Tagging-Konventionen
  • Bereitstellungsprozesse (IaC, Pipelines)

Wichtig: Eine Landing Zone ist ein Produkt, das weiterentwickelt wird – nicht ein einmaliges Projektartefakt.

Minimaler Umfang (Baseline)

Section titled “Minimaler Umfang (Baseline)”

Ein tragfähiges Minimum beantwortet:

  • Wo wird deployt? (Subscription/RG-Struktur)
  • Wie werden Ressourcen benannt und getaggt?
  • Welche Standards sind verpflichtend? (Locations, SKUs, Public Access, Diagnostics)
  • Wie kommt Telemetrie zentral an? (Log Analytics/DCR)
  • Wie wird Zugriff delegiert? (RBAC/PIM)

Bausteine, die du bewusst entscheiden solltest

Section titled “Bausteine, die du bewusst entscheiden solltest”

Landing Zones werden oft zu “Netzwerkprojekten” reduziert. In der Praxis brauchst du aber eine klare Position zu:

  • Connectivity: zentraler Egress/Inspection vs. dezentrale Patterns
  • Identity: Admin-Modell, PIM, Break-Glass, Workload-Identitäten
  • Betrieb: Logging-Ziele, Alerting-Baseline, Owner/On-Call
  • Kosten: Chargeback/Showback, Budgets, Tagging-Erzwingung

Wenn du diese Bausteine nicht adressierst, “entsteht” später eine implizite Landing Zone – nur ohne Dokumentation und ohne Guardrails.

Corp vs. Online (als häufiges Pattern)

Section titled “Corp vs. Online (als häufiges Pattern)”
  • Corp Landing Zones: Workloads mit zentraler Inspection/Egress, oft mit strikten Netzvorgaben.
  • Online Landing Zones: Internet-facing Workloads, ggf. mehr Autonomie, aber weiterhin Baselines.

Diese Trennung ist nützlich, wenn unterschiedliche Netzwerkpfade und Security Controls sinnvoll sind – nicht, weil “es das Reference Design so sagt”.

Rollout-Strategie

Section titled “Rollout-Strategie”

Bewährt hat sich ein gestufter Rollout:

  1. Baseline definieren (Audit) und mit Pilot-Subscriptions testen.
  2. Standards operationalisieren (DeployIfNotExists/Modify) und Tooling/Runbooks bauen.
  3. Danach Guardrails schärfen (Deny) – erst wenn Deployments stabil sind.

Ein wichtiger Praxistipp: Plane bewusst Ausnahmen als Teil des Rollouts. Nicht um Regeln weich zu machen, sondern um den Prozess sauber zu halten (Exemption mit Begründung + Ablaufdatum + Review).

Ownership und Change

Section titled “Ownership und Change”

Landing Zones scheitern selten an Technik, sondern an Ownership:

  • Wer besitzt die Baseline? (Plattformteam)
  • Wie werden Anforderungen von Workload-Teams integriert? (RFC/Backlog)
  • Wie werden Breaking Changes kommuniziert? (Versionierung, Migrationspfade)

Anti-Patterns

Section titled “Anti-Patterns”
  • Landing Zone = einmaliges Terraform/Bicep Repo ohne Lifecycle/Backlog.
  • Workload-Teams brauchen für jede Kleinigkeit Plattformtickets (dann ist es keine Plattform).
  • Guardrails werden mit Deny “hart” gesetzt, bevor Teams Migration/Remediation leisten konnten.

Weiterführend

Section titled “Weiterführend”