Euer 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 eine 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 eurer Firma passt — nicht das Microsoft-Enterprise-Maximum, das niemand mehr versteht.

Hast du diese Situation?

Ihr habt 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 das jetzt löst statt verschoben wird

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 euch 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 habt ihr 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 sortiert in einer typischen Mittelstandsumgebung 10 bis 30 Prozent Kosten aus, weil Test-Maschinen aus 2023 entdeckt werden, 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 euch eine Struktur, die zu eurer 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 ein:e externe:r Mensch 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 euch auf ein Schema, das man sich merken kann. Typisches Beispiel: <workload>-<umgebung>-<typ>-<region>-<nr>, 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 ihr ohnehin mit anderen Clouds arbeitet — 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 eine 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: ihr bekommt 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 du dabei achten solltest

Frag 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 eure 60-Personen-Firma vorschlägt, ist das nicht falsch — aber overkill. Fragt nach der mittelständischen Variante.
Lass dir 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ärt vorab, wer Owner-Rechte behält. Wenn der Dienstleister nach Projektende der einzige Owner ist, habt ihr ein Klumpenrisiko. Owner-Rolle gehört zu euch, 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 die zweite Augenpaarung. 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önnt ihr in einer Minute antworten.

Was ihr beisteuert

Zugang zum Azure-Portal mit ausreichenden Rechten — Reader für die Bestandsaufnahme, Owner für die Umsetzung in einer dedizierten Phase.
Eine Person bei euch, 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 ihr aktuell mitten in einer Migration steckt (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 euer Azure-Footprint sehr klein ist (eine VM, ein Storage-Konto, Punkt) — dann reicht eine kleine Aufräum-Aktion, keine Landing Zone. Wir sagen euch 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 eures Azure-Footprints, vorhandene Subscriptions, dringendster Schmerz (Kosten, Struktur, Sicherheit), Zeitfenster für eine Bestandsaufnahme.
Optional vorab nützlich: eine Liste eurer aktiven Subscriptions, grobe Vorstellung der monatlichen Azure-Rechnung, Information ob bereits IaC eingesetzt wird.

Erstgespräch buchen

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 eure Größe sinnvoll ist.

Bicep oder Terraform — was empfehlt ihr? Bicep, wenn ihr ausschließlich in Azure unterwegs seid und mit dem Microsoft-Toolstack arbeitet. Terraform, wenn ihr ohnehin mehrere Clouds nutzt oder das Tool schon kennt. 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 in das neue Schema durch Umbenennung, Tag-Nachzug und ggf. Bewegung zwischen Resource Groups. 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.

Wie bauen wir eine Azure Landing Zone für den Mittelstand?