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: <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 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
mainpushen 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.
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.