Azure für AWS-Ingenieure: Wie sich Ihre AWS-Instinkte übertragen lassen (und wo sie versagen)

Wenn Sie mit AWS vertraut sind und nun Azure betrachten, ist die gute Nachricht, dass sich ~80 % Ihrer Instinkte direkt übertragen lassen: Es gibt eine Hierarchie zur Organisation von Ressourcen, eine rollenbasierte Methode zur Zugriffsvergabe, eine OIDC-Lösung für schlüsselloses CI und einen Bootstrap-Prozess zum "Kaltstart Ihres State-Backends". Die schlechte Nachricht sind die restlichen 20 % – und diese konzentrieren sich auf einige stark frequentierte Bereiche, in denen das Vorgehen nach AWS-Manier eher zu einer verwirrenden Ablehnung als zu einem offensichtlichen Fehler führt. Dieser Beitrag dient als Übersetzungsebene: dieselben Aufgaben, die Sie in AWS erledigen, in Azure ausgeführt, mit hervorgehobenen Fallstricken.

Kurz gesagt, wenn Sie nur einen Absatz lesen: AWS verfügt im Wesentlichen über eine Berechtigungsebene (IAM), Azure hat drei, die nicht miteinander kommunizieren; AWS-Konten sind Azure-Abonnements, aber die Abrechnung befindet sich an einem völlig anderen Ort; und Azure fügt einen obligatorischen Container (die Resource Group) hinzu, für den AWS kein wirkliches Äquivalent besitzt. Alles Folgende führt dies weiter aus.

Die größte Umstellung: Aus einer Berechtigungsebene werden drei

In AWS ist IAM im Grunde die einzige Instanz. Ein einziger Dienst regelt, wer Ihre Identitäten sind, was sie mit Ressourcen tun dürfen und – über Organizations – wie Konten erstellt und gruppiert werden. Berechtigungen fließen auf eine Weise zusammen, die man wahrscheinlich erst bemerkt, wenn sie nicht mehr vorhanden ist.

Azure teilt diese einzige Ebene bewusst in drei separate Ebenen auf, mit drei Rollensystemen, drei Zuweisungsmechanismen und fast keiner automatischen Übertragung. Allmächtig in einer Ebene zu sein, gewährt nichts in den anderen. Dies ist das Wichtigste, was man verinnerlichen muss, da es die Ursache für fast jeden Moment ist, in dem man sich fragt: "Ich bin doch Administrator, warum wird das verweigert?"

Die Regel, die Ihnen hilft: Wenn Azure etwas verweigert, das "funktionieren sollte", fragen Sie zuerst: "Mit welcher Ebene spreche ich?" – und überprüfen Sie dann die Rollen dieser Ebene. Die meisten mysteriösen Ablehnungen (Abonnement kann nicht gelesen werden, Management Groups können nicht aufgelistet werden, Abrechnung kann nicht eingesehen werden) sind keine fehlende Berechtigung innerhalb einer Ebene – sondern Sie sprechen mit der falschen Ebene.

Ebene 1 — Entra ID directory roles (Identität)

Diese Ebene regelt Verzeichnisobjekte: Benutzer, Gruppen, Service Principals / App Registrations, Conditional Access, MFA-Richtlinien, Lizenzen. Sie regelt nicht die Ressourcen, die Sie bereitstellen.

• Rollen hier sind z. B. Global Administrator, User Administrator, Application Administrator. Sie werden in Entra ID zugewiesen und ausgewertet und über die Microsoft Graph API verfügbar gemacht.
• Global Administrator ist ein Verzeichnis-Gott, kein Ressourcen-Gott. Das verwirrt jeden: Ein Global Admin kann problemlos jeden Benutzer und jede App in der Organisation verwalten und erhält dennoch einen Autorisierungsfehler, wenn er versucht, lediglich ein Abonnement zu lesen. Die nächste AWS-Analogie ist "die Person, die das IAM Identity Center und das Verzeichnis selbst verwaltet" — aber sie ist unvollkommen, eben weil AWS die Verzeichnisverwaltung mit der Ressourcenautorisierung verschmilzt und Azure dies verweigert.

Ebene 2 — Azure RBAC (Ressourcen)

Dies ist die Ebene, in der man sich am häufigsten aufhält, und die vom azurerm Terraform-Provider gesteuert wird. Sie regelt alles, was Sie bereitstellen: VMs, virtuelle Netzwerke, Storage, AKS und so weiter.

• Eine Zuweisung ist ein Dreiergespann: (Principal, Rollendefinition, Bereich), wobei Bereich ein Knoten in der Kette root → management group → subscription → resource group → resource ist, und er vererbt sich nach unten. Integrierte Rollen sind Owner, Contributor, Reader, plus alle benutzerdefinierten Rollendefinitionen, die Sie schreiben.
• Hier ist die Falle für AWS-erfahrene Köpfe: Es gibt keine identitätsgebundenen Richtlinien. In AWS weist man eine Richtlinie einem Benutzer oder einer Rolle zu, und die Berechtigung reist mit der Identität. In Azure ist "Rolle-in-einem-Bereich" das einzige Modell. Die ähnlichste AWS-Mentalität ist "eine IAM-Richtlinie, die an eine Organizations OU angehängt ist" — die Zuweisung befindet sich am Baumknoten, nicht am Principal.
• Die einzige sanktionierte Brücke zwischen Ebene 1 und 2 ist ein bewusster "Break-Glass"-Vorgang: Ein Global Administrator kann "Zugriffsverwaltung für Azure-Ressourcen" (die Operation elevateAccess) aktivieren, um sich selbst die Rolle User Access Administrator auf Root-Ebene zu gewähren. Dies ist auffällig, umkehrbar und kein Standard — man verwendet es einmal während des Bootstrappings, um sich selbst Owner auf Tenant-Root-Ebene zuzuweisen, was dann in jedes Abonnement vererbt wird.

Ebene 3 — Abrechnung / Handel (Geld)

Diese Ebene regelt Abrechnungskonten, Abrechnungsprofile, Rechnungsabschnitte, Zahlungsmethoden — und, entscheidend, die Erstellung von Abonnements.

• Sie verfügt über eigene Rollen (Billing account owner, Billing profile owner, Azure subscription creator, …), die innerhalb des Abrechnungskontos zugewiesen und im Abrechnungssystem gespeichert werden. Diese Rollen erscheinen nicht in az role assignment list oder den Entra-Rollen-Blades. Sie sind eine völlig separate Welt.
• Man kann an diese Grenze von beiden Seiten stoßen. Maximale Identitäts- + Ressourcenrechte (Global Admin + User Access Administrator auf Root-Ebene + Owner auf der Root Management Group) führen immer noch zu einer leeren Liste von az billing account list und keiner Möglichkeit, ein Abonnement zu erstellen. Umgekehrt kann ein Abrechnungsinhaber Abrechnungsrechte mit einem Klick gewähren.
• Der heimtückischste Teil: Die Abrechnung wird über ARM-ähnliche REST-URLs (Microsoft.Billing/...) bereitgestellt, sodass sie wie die Ressourcenebene aussieht — aber die Autorisierung wird anhand von Abrechnungsrollen bewertet. Dieselbe Tür, anderer Türsteher.

Eine konkrete Konsequenz, über die man in AWS nie nachdenken muss: Ob Sie Abonnements überhaupt programmatisch erstellen können, hängt von Ihrem Abrechnungsvereinbarungstyp ab. Legacy Pay-as-you-go / Web-Direct-Konten können Abonnements nur manuell im Portal, durch die ursprüngliche Anmeldeidentität, erstellen — diese Eigentümerschaft ist nicht einmal übertragbar. Das moderne Customer Agreement unterstützt eine API zur Abonnementerstellung (mit Einzelhandelsbeschränkungen für Self-Service-Konten – eine Handvoll Abonnements insgesamt und ein Tageslimit) und Unternehmens-/Partnervereinbarungen heben die Beschränkungen auf. In AWS funktioniert CreateAccount einfach vom Management Account aus; in Azure ist "Kann ich dieses Konto mit Code erstellen?" eine Frage der Abrechnungsebene, die man zuerst beantworten muss. Deshalb behandeln viele Azure-Umgebungen Abonnements als in Terraform importiert, niemals durch Terraform erstellt.

Wie sich die Ebenen in der Praxis überschneiden

Die meisten Aufgaben betreffen genau eine Ebene, und einige umfassen mehrere — was der eigentliche Grund ist, warum die Aufteilung wichtig ist:

• Einen Benutzer, eine Gruppe oder eine App Registration erstellen → Nur Entra.
• Eine VM / ein VNet / ein Storage Account bereitstellen → Nur Ressourcen (Azure RBAC).
• Ein Abonnement erstellen → Billing erstellt es, es gehört zu einem Entra-Tenant, und es wird zu einem Azure RBAC-Bereich. Drei Ebenen für eine Aktion.
• Verzeichnis-Audit-Logs in einen Log Analytics Workspace exportieren → Entra (Quelle) plus Ressourcen (Ziel).
• Terraform azurerm vs azuread → die Ressourcen-API vs. die Graph-API — unterschiedliche Endpunkte, unterschiedliche Token-Audiences.

Dieser letzte Punkt hat eine echte operative Konsequenz: Ein einzelner Login erzeugt separate Tokens pro Audience (einen für den Resource Manager, einen für Graph, einen für Key Vault). Ein Token, das für die API einer Ebene erstellt wurde, ist für die einer anderen Ebene wertlos. Wenn Ihr Tooling nur einen Token abruft, wird die Hälfte Ihres Terraforms mysteriös einen 401-Fehler aufweisen.

"Entra ID", "Tenant" und "Directory" sind (größtenteils) dasselbe

Drei Wörter für ein Objekt, aus verschiedenen Blickwinkeln betrachtet, plus eine Umbenennung, um Sie zu verwirren:

• Entra ID ist das Produkt – der Identitätsdienst. Bis 2023 hieß es Azure Active Directory (Azure AD / AAD), und der alte Name ist überall zu finden: der azuread Terraform-Provider, AADSTS… Fehlercodes, "AAD auth" in der Dokumentation. Dasselbe.
• Ein Tenant ist die dedizierte Instanz Ihrer Organisation von Entra ID — der Container und die Vertrauens-/Isolationsgrenze, identifiziert durch eine GUID und eine primäre Domäne. Benutzer, Gruppen, Apps, Conditional Access und Lizenzen sind alle pro Tenant vorhanden und überschreiten keine Tenant-Grenzen.
• Das Directory ist der Inhalt eines Tenants — die Datenbank von Identitätsobjekten. Ein Tenant entspricht einem Directory, daher werden die Wörter austauschbar verwendet; die Schaltfläche "Switch directory" im Portal wechselt tatsächlich Tenants.

Die folgenden Regeln sind der Punkt, an dem die AWS-Analogie locker wird:

1. Ein Abonnement gehört genau zu einem Tenant. Dieser Tenant ist sein Authentifizierungsbereich und stellt seine RBAC-Principals bereit. (Abonnements können zwischen Tenants übertragen werden; die Abrechnung ist eine separate Zuordnung.)
2. Eine Organisation kann mehrere Tenants besitzen. Ein gängiges Muster ist ein abgesicherter Produktions-Tenant plus ein vollständig isolierter Sandbox-Tenant — separate Identitätswelten, in denen nichts, was man in der einen tut, die andere berühren kann. Es gibt kein AWS-Äquivalent zu "einem zweiten, völlig separaten Identitätsuniversum unter demselben Unternehmen".
3. Benutzer haben einen Home Tenant und können Gäste (B2B) anderswo sein. Ein Gast erhält eine lokale Objekt-ID im Gast-Tenant, während er seine Heimat-Identität behält. AWS kennt kein erstklassiges Konzept eines "Gastbenutzers aus dem Verzeichnis einer anderen Organisation".

Die lockerste AWS-Analogie: Ein Tenant ist ungefähr "eine AWS Organization, die mit ihrem Identity Center Directory verschmolzen ist" — außer dass Abonnements nur für die Identität an einen Tenant gebunden sind, während die Zahlung an ein Abrechnungskonto gebunden ist und organisationsübergreifende Gäste ein natives Konzept sind.

Resource Groups: der Container, den AWS nicht hat

Eine Resource Group (RG) ist ein obligatorischer Container innerhalb eines Abonnements — jede einzelne Ressource lebt in genau einer. Dies ist das Element, für das es kein AWS-Äquivalent gibt (AWS "resource groups" sind nur gespeicherte Tag-Abfragen; ignorieren Sie die Namenskollision).

Eine RG ist vier Dinge gleichzeitig:

• Ein RBAC-Bereich — gewähren Sie Reader auf einer RG, und Sie haben den Zugriff genau auf diese Workload beschränkt.
• Ein Policy-Bereich — Governance-Regeln auf RG-Ebene anwenden.
• Eine Lebenszykluseinheit — löschen Sie die RG, und alles darin wird mitgelöscht.
• Eine Kostenbegrenzung — ein natürlicher Posten für Ausgaben.

Das idiomatische Muster ist eine RG pro Workload (oft pro Region), sodass eine RG zu "dem Ordner für diese App in dieser Region" wird. Eine RG hat einen Standort, aber dieser sagt nur aus, wo ihre Metadaten leben — ihre Ressourcen können in anderen Regionen liegen, daher sollte man sich nicht zu sehr auf den RG-Standort versteifen.

Resource IDs tragen Kontext, daher müssen Namen dies nicht tun

Jede Azure-Ressource hat eine vollständige Resource ID wie /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.App/containerApps/<name>. Das Abonnement und die RG reisen mit jedem Log-Eintrag, Audit-Ereignis und API-Aufruf mit — dieselbe Aufgabe, die ein ARN-Konto und eine Region in AWS erfüllen.

Die Namenskonsequenz ist das Gegenteil Ihrer AWS-Gewohnheit. In AWS ist der Name oft der einzige Kontext, den man erhält, daher stopft man alles hinein. In Azure sollten Namen weglassen, was der Bereich bereits kodiert: Ein Cluster namens aks-quest innerhalb von rg-quest innerhalb des qa-Abonnements ist bereits vollständig eindeutig, und dieselben RG-/Ressourcennamen können sicher über Dev-/QA-/Prod-Abonnements hinweg wiederholt werden. Nur global eindeutige Ressourcentypen (Storage Accounts, Container Registries, Key Vaults) zwingen Organisation/Umgebung/Region zurück in den Namen — und diese kommen mit strengen Längen- und Zeichenbeschränkungen, weshalb man komprimierte Namen wie stcwtfstateplatformcus sieht.

(Dieses cus-Suffix ist übrigens nicht erfunden — es ist Microsofts eigener Geo-Code für Central US, aus derselben offiziellen Tabelle, die Azure zum Erstellen von Private-Endpoint-DNS-Zonen verwendet. eus/eus2 sind East US und East US 2. Das frühzeitige Erlernen der Geo-Code-Tabelle zahlt sich aus.)

Die AWS → Azure Schnellübersicht

Halten Sie dies im ersten Monat griffbereit:

• Organization → ein Entra Tenant plus Management Groups. Identität (der Tenant) und Struktur (Management Groups) sind in Azure separate Dinge, nicht ein und dasselbe.
• Account → Subscription. Gehört zu einem Tenant für die Identität; wird von einem separaten Billing Account abgerechnet.
• SCP (Guardrail) → Azure Policy auf Ebene einer Management Group — mit reichhaltigeren Effekten als nur Ablehnen (audit, deny, modify, deployIfNotExists).
• IAM role/policy → RBAC role assignment — (Principal, Rolle, Bereich). Denken Sie daran: keine identitätsgebundenen Richtlinien.
• Root-Account-Superpowers → dreifach aufgeteilt: Global Admin (Identität) + elevateAccess (Ressourcen) + Billing Owner (Geld). Kein einzelner Principal beginnt mit allen dreien.
• Organizations CreateAccount → die Subscription Aliases API + ein Billing Scope — und nur bei den Abrechnungsvereinbarungstypen, die dies zulassen.
• IRSA (IAM Roles for Service Accounts) → workload identity federation — dieselbe OIDC-Idee.
• Tag-based grouping → die Resource Group — strukturell und obligatorisch, keine Tag-Abfrage.
• ARN in logs → die Resource ID (_ResourceId column) — Kontext des Bereichs ist strukturiert, nicht namenstkodiert.

Terraform-Zustand bootstappen, übersetzt

Hier ist ein Bereich, in dem Ihr AWS-Runbook fast funktioniert, dann aber bei Schritt Null scheitert.

Der AWS-Bootstrap, den Sie kennen: einen State-Backend im Management Account kaltstarten (lokaler Zustand, dann das Backend in sich selbst migrieren), den Zustand der Backends pro OU in diesem Root-Backend halten und Member Accounts mit ihren eigenen Backends erstellen. Die Invariante, die dies sauber macht, ist, dass man immer vom Root Account aus bootstrappen kann, weil dieser immer existiert und einen S3-Bucket enthalten kann.

Azure bricht diese Invariante bereits am Anfang. Das immer existierende Objekt ist der Tenant — aber ein Tenant kann keine Ressourcen halten. Storage Accounts leben in Abonnements, und Abonnements entstehen aus der Billing Plane. Azures "Root Account" ist also das Abonnement, das Sie zum Root-Abonnement erklären, und Sie müssen eines bewusst dazu ernennen. In der Praxis erhalten die meisten Tenants bei der Anmeldung ein Abonnement, sodass die Parallele größtenteils zutrifft: AWS gibt Ihnen einen Management Account, Azure gibt Ihnen ein erstes Abonnement.

Der übersetzte Ablauf, wenn Abonnements bereits existieren (der Regelfall):

1. Ein Kaltstart, einmalig: Stellen Sie den State-Backend in Ihrem designierten Root-Abonnement mit lokalem Zustand bereit, dann init -migrate-state in sich selbst ausführen.
2. Backends pro Abonnement, Zustand im Root-Backend gespeichert: Die Backend-Komponente jedes weiteren Abonnements bindet ihren eigenen Zustand an das Root-Backend, sodass deren Einrichtung ein normaler Apply-Vorgang ist — keine weiteren Kaltstarts.
3. Alles andere in jedem Abonnement verwendet das eigene Backend dieses Abonnements.

Von Grund auf (Abonnements mit Code erstellen) ist die Reihenfolge erzwungen — Root-Abonnement zuerst, Root-Backend zweitens — weil ein Backend ein Storage Account ist und ein Storage Account ein Abonnement benötigt, um zu existieren. Beachten Sie ein Henne-Ei-Problem: Der azurerm-Provider selbst benötigt einen Abonnement-Kontext, so erstellt man bei null Abonnements das allererste Abonnement mit einem imperativen Aufruf (der CLI oder dem azapi-Provider) und importiert es dann anschließend in Terraform.

Und hier ist Azure tatsächlich einfacher als das AWS-Muskelgedächtnis: Backend-in-Root plus Ressourcen-in-Member benötigt keine der AWS Hub-and-Spoke-Vertrauensmechanismen — kein Backend role_arn, kein Provider assume_role, keine zweiseitigen Trust-Policies. Owner auf der Tenant-Root-Management-Group erbt in jedes Abonnement, sodass ein Token tenant-weit funktioniert; der Provider "springt" zwischen Abonnements, indem er einfach subscription_id setzt; und das Backend ist lediglich der Datenzugriff auf Blobs, autorisiert durch eine Storage Blob Data Contributor-Zuweisung. Cross-Subscription ist ein Parameter, keine Vertrauensverhandlung. (Dies wird später mit Custom Roles, PIM und dedizierten CI-Identitäten verschärft — aber selbst dann sind es Rollenzuweisungen in Bereichen, niemals ein Trust-Policy-Handshake.) Wenn Sie tiefer in die Kodifizierung einer der beiden Seiten eintauchen möchten, ist die Prüfung HashiCorp Terraform Authoring & Operations Pro genau auf diese State- und Provider-Muster ausgelegt.

Die vier Stellen, an denen Ihre AWS-Instinkte Sie aktiv in die Irre führen werden

Wenn Sie alles andere vergessen, merken Sie sich diese Punkte:

1. "Admin" ist nicht global. Global Administrator ist nur für Identitäten zuständig; es kann ein Abonnement nicht lesen, bevor ihm nicht jemand eine Ressourcenrolle zuweist. Es gibt keinen einzelnen "Root"-Principal.
2. Berechtigungen sind an Bereiche gebunden, nicht an Identitäten. Suchen Sie nicht nach der Richtlinie beim Benutzer — suchen Sie nach der Rollenzuweisung auf der Management Group, dem Abonnement, der Resource Group oder der Ressource.
3. Die Abrechnung ist ein separates Universum von Ressourcen. "Ich kann alles bereitstellen" sagt nichts darüber aus, ob ich ein Abonnement erstellen kann. Andere Ebene, andere Rollen, unsichtbar für az role assignment list.
4. Die Resource Group ist tragend. Es ist kein Tag — es ist ein RBAC-Bereich, ein Policy-Bereich und eine Löschgrenze. Gestalten Sie Ihr RG-Layout bewusst.

Welche Zertifizierungen die jeweilige Seite vertiefen

Cloud Governance – Hierarchie, Identität, Guardrails und Zustand – ist das Rückgrat der Architektur- und Administrationsprüfungen in beiden Clouds, daher ist das Studium dafür auch der schnellste Weg, die oben genannten Konzepte zu verankern. Wenn Sie bereits die AWS-Zertifizierung besitzen, ist die Azure-Zertifizierung in derselben Reihe Ihr natürlicher nächster Schritt.

Auf der AWS-Seite (das Wissen, von dem Sie übersetzen):

• AWS Certified Cloud Practitioner (CLF-C02) — die Grundlagen von Accounts, IAM und Organizations.
• AWS Certified Solutions Architect – Associate (SAA-C03) — IAM, Multi-Account-Struktur und Kernarchitektur.
• AWS Certified Solutions Architect – Professional (SAP-C02) — Multi-Account Organizations, SCPs und Cross-Account-Zugriff im großen Maßstab.
• AWS Certified Security – Specialty (SCS-C03) — IAM-Tiefe, SCPs und Schlüsselverwaltung.

Auf der Azure-Seite (das Wissen, in das Sie übersetzen):

• Microsoft Certified: Azure Fundamentals (AZ-900) — Tenants, Abonnements, Resource Groups und die Grundlagen von RBAC.
• Microsoft Certified: Azure Administrator Associate (AZ-104) — die tägliche Ebene: RBAC, Resource Groups, Abonnements und Entra-Grundlagen.
• Microsoft Certified: Azure Solutions Architect Expert (AZ-305) — Management Groups, Governance und Landing-Zone-Design.
• Microsoft Certified: Azure Security Engineer Associate (AZ-500) — Entra ID, RBAC, Azure Policy, Conditional Access und Key Vault.

Ein pragmatischer Weg, wenn Sie heute AWS-zertifiziert sind: Beginnen Sie mit AZ-900, um das Vokabular zuzuordnen, springen Sie dann zu AZ-104 (das in der Ressourcenebene angesiedelt ist, die Sie am häufigsten verwenden werden), und fügen Sie AZ-305 oder AZ-500 hinzu, je nachdem, ob Ihre Arbeit architektur- oder sicherheitslastig ist.

Das Fazit

Azure ist nicht schwieriger als AWS – es ist anders strukturiert. AWS fasst Identitäts-, Ressourcen- und Abrechnungsautorität in einer Ebene zusammen und gibt Ihnen einen Management Account, der alles tun kann. Azure trennt diese drei Anliegen bewusst, was am ersten Tag wie Reibung wirkt und nach drei Monaten wie klare Grenzen. Übersetzen Sie die Konzepte einmal — eine Ebene wird zu drei, Accounts werden zu Abonnements, die anderswo abgerechnet werden, Richtlinien werden an Bereiche statt an Identitäten gebunden, und die Resource Group ist eine echte Struktur — und der Rest ist Vokabular. Üben Sie es mit den oben genannten Zertifizierungen, und die Teile, die sich wie willkürliche Ablehnungen anfühlten, beginnen sich als kohärentes, bewusstes Design zu lesen.