--- title: "Wie bauen wir eine Azure Landing Zone für den Mittelstand?" description: "Wir bauen Ihr gewachsenes Azure-Abonnement zu einer nachvollziehbaren Landing Zone um — in der Größe, die zu Ihrer Firma passt, nicht im Enterprise-Maximum." canonical: "https://demo22.berndt.to/de/use-cases/azure-landing-zone-aufbauen/" lang: de schema_type: Article --- # Wie bauen wir eine Azure Landing Zone für den Mittelstand? Wir bauen Ihr gewachsenes Azure-Abonnement zu einer nachvollziehbaren Landing Zone um — in der Größe, die zu Ihrer Firma passt, nicht im Enterprise-Maximum. ## Das Wichtigste in Kürze - **Was:** Aufbau einer Azure Landing Zone in mittelstandsgerechter Größe: Subscription-Struktur, Naming- und Tagging-Konvention, IaC-Basis, Cost Management und Policy-Baseline. - **Für wen:** Mittelständische Firmen mit gewachsenem Azure-Abonnement, in dem niemand mehr genau weiß, was wo läuft und was es kostet. - **Dauer:** Insgesamt rund 6 bis 10 Wochen — Bestandsaufnahme und Struktur-Design etwa 2 bis 3 Wochen, danach Policies, IaC und Cost Management. - **Ergebnis:** Jede Ressource hat Zweck, Kostenstelle und verantwortliche Person; die Azure-Rechnung lässt sich pro Workload und Kostenstelle aufschlüsseln. Passt, wenn: - Sie haben mehrere Azure-Subscriptions, und niemand kann auf Anhieb sagen, welche wofür ist. - Die Azure-Rechnung wächst monatlich, ohne dass jemand erklären kann, warum. - Eine neue Workload soll nach Azure — und nicht zur nächsten Insel werden. Ihr Azure-Abonnement existiert seit ein paar Jahren. Irgendwann hat jemand das erste Subnetz angelegt, dann kam eine VM für ein Test-System dazu, dann ein Storage-Konto für Backups, dann eine zweite Subscription, weil der Steuerberater das wollte. Heute weiß niemand mehr genau, was wo läuft, was es kostet, und warum die Ressource „vm-test-final-2" produktiv ist. Wir bauen daraus eine Landing Zone, die in der Größe zu Ihrer Firma passt — nicht das Microsoft-Enterprise-Maximum, das niemand mehr versteht. ## Kennen Sie diese Situation? - Sie haben zwei oder drei Azure-Subscriptions, und niemand kann auf Anhieb sagen, welche wofür ist. Eine wurde für das ERP-Test-System angelegt, eine andere für „Cloud-Sachen", die dritte erbte ein ehemaliger Dienstleister. - Die Ressourcen heißen `vm01`, `storagealt`, `rg-neu-final`, `test-bjoern`. Welche Maschine zu welchem Projekt gehört, weiß nur die Person, die sie damals angelegt hat — und die arbeitet seit einem Jahr in einer anderen Firma. - Die Azure-Rechnung wächst monatlich um ein paar hundert Euro, ohne dass jemand erklären kann, warum. Cost Management ist nie eingerichtet worden, Budgets gibt es keine, Alerts auch nicht. - Wenn die Geschäftsführung fragt „Was kostet uns Azure pro Standort?", muss jemand drei Stunden in der Rechnung wühlen — und am Ende ist die Antwort trotzdem geschätzt. - Es gibt keine Vorgabe, wie eine neue Ressource heißt, in welcher Resource Group sie landet, oder welche Tags sie braucht. Jede:r macht es so, wie er oder sie es gerade für richtig hält. ## Warum jetzt — und nicht später Eine ungeordnete Azure-Umgebung kostet auf drei Ebenen: Sie kostet bares Geld durch ungenutzte Ressourcen, falsch dimensionierte VMs und vergessene Test-Umgebungen, die seit Monaten laufen. Sie kostet Zeit, weil jede Änderung Recherche-Arbeit auslöst. Und sie kostet Sicherheit, weil ohne Struktur niemand merkt, wenn eine Ressource außerhalb der Policy entsteht. Typische Auslöser, die jetzt dran sind: - **Microsoft-Enterprise-Agreement-Renewal oder Reseller-Wechsel** — der neue Vertragspartner schaut auf die Subscription-Struktur und stellt unangenehme Fragen. - **Eine neue Workload soll nach Azure** — eine Test-Umgebung für das ERP, eine zweite SQL-Datenbank, ein Web-Backend. Ohne Landing Zone wird das zur nächsten Insel. - **Cyber-Versicherer oder Auditor:in fragt nach Zugriffsstruktur** — wer hat Owner-Rechte auf welcher Subscription? Wenn die Antwort „weiß ich nicht" lautet, ist das ein Befund. - **Cost-Schock im letzten Quartal** — die Rechnung ist plötzlich 40 Prozent höher, und keiner weiß, woher das kommt. ## So sähe das bei Ihnen aus ### Schritt 1 — Bestandsaufnahme und Ist-Diagramm Wir starten damit, dass wir uns einlesen: welche Subscriptions existieren, welche Resource Groups, welche Ressourcen, welche Identitäten, welche Rechte. Dafür reichen Reader-Rechte. Am Ende von Schritt 1 haben Sie ein Diagramm und eine Tabelle, in der jede laufende Ressource einem Zweck zugeordnet ist — oder als „unbekannt" markiert ist, wenn niemand mehr weiß, wofür sie da ist. Allein dieser Schritt deckt häufig spürbares Einsparpotenzial auf — etwa Test-Maschinen aus 2023, die niemand mehr braucht. Stack-Hinweise: Azure Resource Graph für Inventar, Cost-Management-Exporte, Entra-ID-Rollen-Auswertung. ### Schritt 2 — Subscription- und Management-Group-Struktur Wir entwerfen mit Ihnen eine Struktur, die zu Ihrer Firma passt. Für eine 80-Mitarbeitenden-Firma reicht in den meisten Fällen ein flacher Aufbau mit Management Groups für „Produktion", „Test/Entwicklung" und ggf. „Sandbox" — darunter zwei bis vier Subscriptions. Das ist bewusst weniger als das, was die Microsoft-CAF-Dokumentation für Konzerne vorsieht. Wer keine vier Tochterfirmen hat, braucht keine vier Subscriptions pro Workload. Liefer-Ergebnis: eine Struktur, die eine externe Person in 15 Minuten verstehen kann. Stack-Hinweise: Management Groups, Subscription-Vending, Entra ID PIM für privilegierte Rollen. ### Schritt 3 — Naming- und Tagging-Konvention Wir einigen uns mit Ihnen auf ein Schema, das man sich merken kann. Typisches Beispiel: `----`, also `erp-prod-vm-weu-01`. Dazu Pflicht-Tags wie `costcenter`, `owner`, `workload`, `environment`. Wichtig: Die Konvention ist nur dann etwas wert, wenn sie über Azure Policy erzwungen wird — sonst entstehen in drei Monaten wieder Ressourcen ohne Tags. Liefer-Ergebnis: ein Naming- und Tagging-Standard, dokumentiert auf einer Seite, plus Policy-Definitionen, die fehlerhafte Erstellungen verhindern oder kennzeichnen. Stack-Hinweise: Azure Policy (deny/audit), Tag-Inheritance, Initiative-Definitionen. ### Schritt 4 — Infrastructure-as-Code-Basis Statt dass weiterhin jede:r per Portal klickt, definieren wir die wichtigen Ressourcen-Typen einmal als Code. Bicep für Microsoft-native Setups, Terraform, wenn Sie ohnehin mit anderen Clouds arbeiten — beides funktioniert. Liefer-Ergebnis: ein kleines Repository mit Modulen für die häufigsten Bedarfe (VM, Storage-Account, Resource Group mit Standard-Policies, Key Vault), plus eine kurze Anleitung, wie ein Deployment ausgelöst wird. Bewusst kein Über-Engineering: keine 14-stufige Pipeline mit Approval-Gates auf vier Ebenen, sondern etwas, das ein:e IT-Generalist:in in zwei Tagen lernen kann. Stack-Hinweise: Bicep oder Terraform, GitHub Actions oder Azure DevOps Pipelines, Service Principals mit eingeschränkten Rechten. ### Schritt 5 — Cost Management und Policy-Baseline Budgets pro Subscription, Alerts bei Schwellenwert-Überschreitung, monatlicher Cost-Report an die Geschäftsführung. Dazu eine Policy-Baseline: keine VMs in Regionen außerhalb der EU, Storage-Konten ohne öffentlichen Endpoint, Diagnostic Settings als Pflicht. Liefer-Ergebnis: Sie bekommen einmal pro Monat eine Übersicht, was Azure pro Workload und pro Kostenstelle gekostet hat — und die Sicherheit, dass niemand versehentlich eine VM in einer anderen Region anlegt. Stack-Hinweise: Azure Cost Management Budgets, Action Groups, Azure Policy Initiatives, Microsoft Defender for Cloud Free-Tier. ## Worauf Sie achten sollten - **Fragen Sie nach dem Lösch-Plan, nicht nur nach dem Aufbau-Plan.** Eine Landing Zone, die nichts wegwirft, ist keine Landing Zone — sie ist eine Sammlung. Wer nicht erklärt, wie ungenutzte Ressourcen identifiziert und entfernt werden, baut nur eine schönere Müllhalde. - **CAF ist eine Referenz, kein Pflichtprogramm.** Wenn jemand die volle Microsoft Cloud Adoption Framework Enterprise-Scale-Architektur mit fünf Management-Group-Ebenen für Ihre 60-Personen-Firma vorschlägt, ist das nicht falsch — aber overkill. Fragen Sie nach der mittelständischen Variante. - **Lassen Sie das Tagging vor dem Naming definieren.** Tags sind veränderbar, Namen nicht. Wer mit dem Naming anfängt und Tags später nachzieht, hat zwei Konventionen, die nie zueinander passen. - **Klären Sie vorab, wer Owner-Rechte behält.** Wenn der Dienstleister nach Projektende der einzige Owner ist, haben Sie ein Klumpenrisiko. Die Owner-Rolle gehört zu Ihnen, der Dienstleister bekommt im Regelbetrieb Contributor mit klarem Scope. - **IaC braucht einen Code-Review-Pfad.** Wenn jede:r direkt in `main` pushen kann und das Deployment automatisch läuft, fehlt das Vier-Augen-Prinzip. Auch eine kleine Firma kann zwei Personen für einen Pull-Request-Review zusammenbringen. ## Was sich danach realistisch ändert - Jede Ressource in Azure hat einen Zweck, eine Kostenstelle und eine verantwortliche Person — nachschlagbar in 30 Sekunden. - Die Azure-Rechnung lässt sich pro Workload, pro Standort und pro Kostenstelle aufschlüsseln, ohne dass jemand drei Stunden in Excel arbeitet. - Eine neue Workload landet nicht mehr als Insel, sondern in einer definierten Subscription mit Standard-Policies und Standard-Tags. - Ungenutzte Test-Maschinen aus dem letzten Jahr sind weg, und neue entstehen mit Ablaufdatum. - Wenn ein:e Auditor:in fragt „Wer hat Owner-Rechte auf der Produktions-Subscription?", können Sie in einer Minute antworten. ## Was Sie beisteuern - Zugang zum Azure-Portal mit ausreichenden Rechten — Reader für die Bestandsaufnahme, Owner für die Umsetzung in einer dedizierten Phase. - Eine Person bei Ihnen, die das Thema mitträgt und Entscheidungen zu Naming und Tagging mittragen kann. Das ist keine technische Position — die Geschäftsführung muss in der Lage sein, Kostenstellen zu benennen. - Etwa 4 bis 8 Stunden Stakeholder-Zeit verteilt über mehrere Wochen, plus die operativen Termine für die Umsetzungs-Schritte. Mehr braucht es nicht, wenn die Bestandsaufnahme von uns geführt wird. ## Risiken und wann es nicht passt - Wenn Sie aktuell mitten in einer Migration stecken (z. B. ERP-Umzug, Office-365-Einführung) — dann erst die Migration zu Ende, dann die Landing Zone. Zwei große Umbauten gleichzeitig erhöhen das Risiko ohne Mehrwert. - Wenn Ihr Azure-Footprint sehr klein ist (eine VM, ein Storage-Konto, Punkt) — dann reicht eine kleine Aufräum-Aktion, keine Landing Zone. Wir sagen Ihnen das im Erstgespräch. - Wenn die Cloud-Strategie politisch nicht beschlossen ist und intern noch diskutiert wird, ob überhaupt Azure oder lieber AWS — dann erst die Strategie klären. Es ergibt keinen Sinn, eine Landing Zone zu bauen, die in sechs Monaten wieder migriert wird. ## So fängt das Gespräch an - 30 Minuten Erstgespräch, kostenfrei, per Video oder Telefon. - Was wir klären: aktueller Umfang Ihres Azure-Footprints, vorhandene Subscriptions, dringendster Schmerz (Kosten, Struktur, Sicherheit), Zeitfenster für eine Bestandsaufnahme. - Optional vorab nützlich: eine Liste Ihrer aktiven Subscriptions, grobe Vorstellung der monatlichen Azure-Rechnung, Information ob bereits IaC eingesetzt wird. [Erstgespräch buchen](/de/kontakt) ## Häufige Fragen **Brauchen wir wirklich Management Groups, wenn wir nur zwei Subscriptions haben?** Nein, nicht zwingend. Bei zwei Subscriptions reicht oft eine flache Struktur mit Policies direkt auf Subscription-Ebene. Management Groups lohnen sich ab drei bis vier Subscriptions oder wenn Policies vererbt werden sollen. Im Erstgespräch klären wir, was für Ihre Größe sinnvoll ist. **Bicep oder Terraform — was empfehlen Sie?** Bicep, wenn Sie ausschließlich in Azure unterwegs sind und mit dem Microsoft-Toolstack arbeiten. Terraform, wenn Sie ohnehin mehrere Clouds nutzen oder das Tool schon kennen. Beide funktionieren. Wichtiger als die Wahl ist, dass es konsequent eingesetzt wird. **Was passiert mit unseren bestehenden Ressourcen — werden die neu deployed?** Nein, in der Regel nicht. Wir bringen bestehende Ressourcen per Tag-Nachzug und ggf. Verschieben zwischen Resource Groups in das neue Schema. Da sich die meisten Azure-Ressourcen nicht umbenennen lassen, gilt die Naming-Konvention für neu erstellte Ressourcen — der Bestand wird über Tags zugeordnet. Neu-Deployment nur dort, wo es technisch nicht anders geht oder wo die Ressource sowieso erneuert werden soll. **Wie lange dauert das typischerweise?** Bestandsaufnahme und Struktur-Design etwa 2 bis 3 Wochen, Umsetzung der Naming-/Tagging-Policy weitere 2 bis 4 Wochen, IaC-Basis und Cost Management noch einmal 2 bis 3 Wochen. Insgesamt also rund 6 bis 10 Wochen für eine mittelständische Umgebung. Eine ehrliche Spannweite geben wir nach der Bestandsaufnahme. ## Verwandtes - Service: [Cloud Operations (Azure-Hybrid)](/de/leistungen/cloud-operations) - Use Case: [Wie testen wir Restore und Recovery wirklich, statt nur Backups laufen zu lassen?](/de/use-cases/backup-drill-restore-uebung) - Wissen: [Azure Hybrid Cloud im Maschinenbau am Niederrhein](/de/wissen/azure-hybrid-cloud-maschinenbau-niederrhein)