Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der AZ-900-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
IT-Ausgaben von großen, einmaligen Hardware-Käufen auf ein Pay-as-you-go-Modell umstellen.
Das verbrauchsbasierte Cloud-Modell nutzen.
Warum: Dies wandelt Investitionsausgaben (CapEx) in vorhersehbare Betriebsausgaben (OpEx) um und eliminiert die Notwendigkeit der Beschaffung und Verwaltung von Rechenzentren.
Die Aufteilung der Sicherheits- und Verwaltungsaufgaben zwischen Cloud-Anbieter und Kunde verstehen.
Der Anbieter ist für die Sicherheit *der* Cloud verantwortlich; der Kunde ist für die Sicherheit *in der* Cloud verantwortlich. Der Kunde besitzt immer seine Daten, Identitäten und Endpunkte.
Warum: In IaaS verwaltet der Kunde das OS und höhere Schichten. In PaaS verwaltet der Anbieter das OS, und der Kunde verwaltet die Anwendung und die Daten. In SaaS verwaltet der Anbieter alles außer Daten und Zugriffskonfiguration.
Ein Bereitstellungsmodell basierend auf Kontrolle, Mandantenfähigkeit und Standortanforderungen auswählen.
Verwenden Sie Public (gemeinsame Infrastruktur), Private (dedizierte Infrastruktur, On-Premises oder gehostet) oder Hybrid (Mischung aus Public und Private).
Warum: Hybrid ist entscheidend, um On-Premises-Systeme für Regulierung/Latenz beizubehalten, während die Public Cloud für Skalierbarkeit und moderne Dienste genutzt wird. Private bietet maximale Kontrolle.
Das passende Cloud-Servicemodell basierend auf dem gewünschten Maß an Verwaltungskontrolle auswählen.
IaaS (z.B. Azure VMs) für maximale Kontrolle über das OS. PaaS (z.B. Azure App Service, Azure SQL), um sich auf Code statt Infrastruktur zu konzentrieren. SaaS (z.B. Microsoft 365) für sofort einsatzbereite Software.
Warum: Der Kompromiss ist Kontrolle vs. Komfort. Wenn Sie von IaaS zu SaaS wechseln, verwaltet der Anbieter mehr vom Stack, was die operative Belastung des Kunden reduziert.
Dynamische, unvorhersehbare Verkehrsspitzen vs. geplantes, nachhaltiges Wachstum bewältigen.
Elasticity für automatische Skalierung (rein/raus) verwenden, um dem Echtzeitbedarf gerecht zu werden. Scalability für geplante Kapazitätserhöhungen (raus/hoch) verwenden, um prognostiziertes Wachstum zu bewältigen.
Warum: Elasticity ist automatisiert und reaktiv, ideal für Workloads mit Spitzenlasten zur Kostenoptimierung. Scalability ist ein breiteres Konzept der Kapazitätserweiterung, das manuell oder automatisiert erfolgen kann.
Schutz vor Komponentenausfällen innerhalb einer Region vs. einem katastrophalen regionalen Ausfall.
High Availability (HA) mithilfe von Availability Zones implementieren, um Rechenzentrumsausfälle zu überstehen. Disaster Recovery (DR) mithilfe von regionenübergreifender Replikation (z.B. GRS) implementieren, um eine regionale Katastrophe zu überstehen.
Warum: HA dient der Aufrechterhaltung des Dienstes mit minimaler Unterbrechung. DR dient der Wiederherstellung des Dienstes nach einem größeren Ausfall. HA ist typischerweise automatisiert mit schnellem Failover; DR beinhaltet oft einen formalen Wiederherstellungsprozess.
Ressourcen für eine Regierungseinheit bereitstellen, die spezifische Compliance- und Datenresidenzanforderungen hat.
Eine souveräne Cloud wie Azure Government nutzen.
Warum: Dies sind physisch isolierte Instanzen von Azure, die von geprüftem Personal verwaltet werden und darauf ausgelegt sind, strenge staatliche Compliance-Standards (z.B. FedRAMP, DoD) zu erfüllen.
Eine resiliente Anwendung entwerfen, die einen Rechenzentrumsausfall überstehen kann.
Ressourcen über mehrere Availability Zones innerhalb einer einzelnen Azure Region verteilen.
Warum: Availability Zones sind physisch getrennte Rechenzentren mit unabhängiger Stromversorgung, Kühlung und Netzwerkanbindung. Dies bietet Hochverfügbarkeit innerhalb einer Region ohne die Latenz von regionenübergreifenden Bereitstellungen.
Zugehörige Azure-Ressourcen für eine einheitliche Verwaltung, Zugriffskontrolle und Abrechnung gruppieren.
Alle Ressourcen einer Anwendung in einer einzelnen Azure Resource Group platzieren.
Warum: Resource Groups sind Container für Metadaten. Das Löschen einer Resource Group löscht alle darin enthaltenen Ressourcen, was sie zu einer kritischen Grenze für das Lifecycle-Management macht.
Den passenden Compute-Dienst für eine Workload auswählen.
VMs (IaaS) für volle Kontrolle. App Service (PaaS) für Web-Apps/APIs. Azure Functions für ereignisgesteuerten Serverless-Code. AKS für Container-Orchestrierung. ACI für einfache Container-Instanzen.
Warum: Die Wahl hängt vom Kompromiss zwischen Kontrolle, Verwaltungsaufwand und Architekturmuster (z.B. Monolith, Microservices, ereignisgesteuert) ab.
Eine komplexe, containerisierte Microservices-Anwendung ausführen, die Auto-Scaling, Service Discovery und Rolling Updates erfordert.
Azure Kubernetes Service (AKS) verwenden.
Warum: AKS ist das verwaltete Kubernetes-Angebot für umfassende Container-Orchestrierung. Verwenden Sie dies gegenüber ACI, wenn Sie Cluster-Management und komplexe Dienstinteraktionen benötigen.
Einen einzelnen, einfachen Container für eine kurzlebige Aufgabe (z.B. einen Batch-Job) ohne Infrastrukturverwaltung ausführen.
Azure Container Instances (ACI) verwenden.
Warum: ACI ist der schnellste und einfachste Weg, einen Container in Azure auszuführen. Es ist serverlos und wird pro Sekunde abgerechnet, ideal für Aufgaben ohne Orchestrierungsbedarf.
Eine dedizierte, private Hochgeschwindigkeitsverbindung von einem On-Premises-Rechenzentrum zu Azure herstellen.
Azure ExpressRoute verwenden.
Warum: ExpressRoute durchläuft NICHT das öffentliche Internet und bietet so eine höhere Zuverlässigkeit, Sicherheit und geringere Latenz als ein VPN Gateway, das über das Internet tunnelt.
Verkehr an Backend-VMs basierend auf Netzwerk- vs. Anwendungsebene-Regeln verteilen.
Azure Load Balancer für Layer 4 (TCP/UDP) Verteilung verwenden. Azure Application Gateway für Layer 7 (HTTP/HTTPS) Funktionen wie SSL Offloading und URL-basiertes Routing verwenden.
Warum: Wählen Sie Application Gateway, wenn Sie Routing-Entscheidungen basierend auf HTTP-Headern, Pfaden oder Hostnamen treffen müssen. Load Balancer ist einfacher und schneller für Nicht-HTTP-Verkehr.
Globalen Web-Verkehr zum optimalen Backend leiten, CDN-Caching bereitstellen und mit einer WAF schützen.
Azure Front Door verwenden.
Warum: Front Door ist ein globaler Eintrittspunkt, der auf Layer 7 arbeitet und globales Load Balancing, CDN, WAF und DDoS-Schutz in einem einzigen Dienst kombiniert.
Massive Mengen unstrukturierter Daten wie Bilder, Videos, Backups und Logdateien speichern.
Azure Blob Storage verwenden.
Warum: Blob Storage ist hoch skalierbar und kostengünstig für Objektdaten. Es unterscheidet sich von Azure Files (für SMB-Dateifreigaben) und Azure Disk Storage (für VM-Disks).
Speicherkosten für Daten basierend auf deren Zugriffshäufigkeit minimieren.
Blob Storage-Zugriffsebenen verwenden: Hot (häufiger Zugriff), Cool/Cold (seltener Zugriff) und Archive (sehr seltener Zugriff, Langzeitaufbewahrung).
Warum: Die Archive-Ebene hat die niedrigsten Speicherkosten, aber die höchsten Zugriffskosten und die größte Latenz (Stunden zur Rehydrierung). Lebenszyklusmanagementrichtlinien verwenden, um die Tiering-Automatisierung zu steuern.
Eine Datenreplikationsstrategie wählen, um sich vor Hardware-, Rechenzentrums- oder regionalen Ausfällen zu schützen.
LRS (einzelnes Rechenzentrum), ZRS (über AZs in einer Region), GRS (zu einer sekundären Region), GZRS (ZRS in primär + LRS in sekundär).
Warum: ZRS schützt vor einem Rechenzentrumsausfall. GRS/GZRS schützt vor einer regionalen Katastrophe. Der Kompromiss sind höhere Kosten für größere Resilienz.
Einer VM in einem VNet den Zugriff auf einen PaaS-Dienst (wie Azure SQL oder Storage) ermöglichen, ohne dass der Datenverkehr das Microsoft-Netzwerk verlässt.
Einen Private Endpoint für den PaaS-Dienst innerhalb des VNet der VM erstellen.
Warum: Ein Private Endpoint weist dem PaaS-Dienst eine private IP-Adresse aus Ihrem VNet zu, wodurch sichergestellt wird, dass der gesamte Datenverkehr über das private Microsoft-Backbone fließt und nicht über das öffentliche Internet.
Einen On-Premises Windows Dateiserver zu einem verwalteten Cloud-Dienst migrieren, der über das SMB-Protokoll zugänglich ist.
Azure Files verwenden.
Warum: Azure Files bietet vollständig verwaltete Dateifreigaben, die von Cloud- oder On-Premises-VMs gemountet werden können und als direkter Ersatz für herkömmliche Dateiserver dienen.
Governance (Richtlinien, RBAC) anwenden und den Zugriff über zahlreiche Azure-Abonnements hinweg verwalten.
Abonnements in einer Management Group-Hierarchie organisieren.
Warum: Management Groups sind ein Bereich oberhalb von Abonnements. Richtlinien und Rollenzuweisungen, die auf Management Group-Ebene angewendet werden, werden von allen darin enthaltenen Abonnements geerbt.
Organisatorische Standards durchsetzen, wie die Beschränkung von Bereitstellungen auf bestimmte Regionen oder die Anforderung von Tags für alle Ressourcen.
Azure Policy verwenden.
Warum: Policy erzwingt Regeln für Ressourcenkonfigurationen. Dies dient der Governance, während RBAC Benutzerberechtigungen (Aktionen) steuert.
Unterscheiden zwischen der Steuerung von Benutzeraktionen und der Steuerung von Ressourceneigenschaften.
Role-Based Access Control (RBAC) verwenden, um zu definieren, welche Aktionen ein Benutzer ausführen kann (z.B. "Mitwirkender" kann VMs erstellen). Azure Policy verwenden, um zu definieren, welche Konfigurationen zulässig sind (z.B. "VMs dürfen nur D-Serien-Größe haben").
Warum: RBAC geht es darum, "wer was tun kann". Policy geht es darum, "was erlaubt ist". Sie arbeiten zusammen für eine umfassende Governance.
Eine kritische Produktionsressource vor versehentlichem Löschen schützen, selbst durch Administratoren.
Eine `CanNotDelete` Resource Lock auf die Ressource oder ihre Ressourcengruppe anwenden.
Warum: Ressourcensperren überschreiben RBAC-Berechtigungen. Ein Besitzer kann eine gesperrte Ressource erst löschen, wenn die Sperre explizit entfernt wurde. Eine `ReadOnly`-Sperre verhindert jegliche Änderungen.
Ressourcen logisch für Kostenverfolgung, Automatisierung oder Eigentumsidentifikation organisieren.
Tags (Schlüssel-Wert-Paare) auf Ressourcen anwenden.
Warum: Tags sind Metadaten, die zum Filtern und Gruppieren von Ressourcen über Ressourcengruppen hinweg verwendet werden und eine leistungsstarke Kostenanalyse und -verwaltung ermöglichen.
Ein auf eine Ressourcengruppe angewendeter Tag wird nicht auf den darin enthaltenen Ressourcen angezeigt.
Tags werden nicht automatisch von Ressourcengruppen geerbt. Jede Ressource muss explizit getaggt werden.
Warum: Um die Tag-Vererbung zu erzwingen, verwenden Sie eine Azure Policy mit einem "Modify"- oder "DeployIfNotExists"-Effekt, um Tags von der übergeordneten Ressourcengruppe anzuhängen.
Zukünftige Azure-Kosten schätzen vs. Einsparungen durch eine On-Prem-Migration berechnen.
Den Pricing Calculator verwenden, um die Kosten spezifischer Azure-Dienste zu schätzen. Den Total Cost of Ownership (TCO) Calculator verwenden, um On-Prem-Kosten mit Azure-Kosten zu vergleichen.
Warum: Der Pricing Calculator ist für Greenfield-Bereitstellungen oder das Hinzufügen neuer Dienste gedacht. Der TCO Calculator dient dazu, einen Business Case für die Migration zu erstellen.
Aktuelle Azure-Ausgaben verfolgen, Ausgabenwarnungen einrichten und Einsparmöglichkeiten finden.
Azure Cost Management verwenden. Budgets erstellen, um Warnungen auszulösen, wenn Ausgabenschwellenwerte erreicht werden.
Warum: Budgets bieten eine proaktive Benachrichtigung über Ausgaben und helfen, Kostenüberschreitungen zu vermeiden. Die Kostenmanagement-Analyse hilft, Ausgabenanomalien und Trends zu identifizieren.
Kosten für vorhersehbare, kontinuierlich laufende Workloads wie VMs oder Datenbanken reduzieren.
Azure Reserved Instances oder Savings Plans für eine Laufzeit von 1 oder 3 Jahren erwerben.
Warum: Reservierungen bieten erhebliche Rabatte (bis zu 72%) gegenüber Pay-as-you-go-Preisen im Austausch für eine langfristige Verpflichtung. Ideal für stabile Workloads.
Azure-Infrastruktur wiederholbar, konsistent und unter Versionskontrolle bereitstellen.
Deklaratives Infrastructure as Code (IaC) mit ARM-Templates (JSON) oder Bicep verwenden.
Warum: Bicep ist eine einfachere, prägnantere domänenspezifische Sprache (DSL), die zu ARM JSON transkompiliert wird und eine bessere Erstellungserfahrung und Lesbarkeit bietet.
Server, die On-Premises oder in anderen Clouds laufen, mit Azure-Tools verwalten und steuern.
Die Nicht-Azure-Server in Azure Arc aufnehmen.
Warum: Azure Arc projiziert externe Ressourcen in Azure Resource Manager, sodass Sie Azure Policy, RBAC und Monitoring für Hybrid- und Multi-Cloud-Assets über eine einzige Steuerungsebene nutzen können.
Eine einzige, Cloud-basierte Identitäts- und Zugriffsmanagementlösung für alle Anwendungen bereitstellen.
Microsoft Entra ID (ehemals Azure AD) verwenden.
Warum: Entra ID ist die Identitätssteuerungsebene, die Single Sign-On (SSO), Multi-Factor Authentication (MFA) und Conditional Access für Cloud- und On-Prem-Apps bietet.
MFA für Benutzer anfordern, die sich von einem nicht vertrauenswürdigen Netzwerk aus anmelden, aber nicht vom Unternehmensbüro.
Eine Microsoft Entra Conditional Access-Richtlinie konfigurieren.
Warum: Conditional Access fungiert als "Wenn-Dann"-Richtlinien-Engine. Wenn eine Benutzer-/Standort-/Gerätebedingung erfüllt ist, wird eine Zugriffskontrolle (z.B. die Anforderung von MFA) durchgesetzt.
Einer Azure-Ressource (wie einer VM oder App Service) ermöglichen, sich bei einem anderen Azure-Dienst (wie Key Vault) zu authentifizieren, ohne Geheimnisse im Code zu speichern.
Eine Managed Identity der Ressource zuweisen und ihr RBAC-Berechtigungen für den Zieldienst erteilen.
Warum: Azure verwaltet den Lebenszyklus der Anmeldeinformationen automatisch und eliminiert so das Risiko, dass Geheimnisse aus Konfigurationsdateien oder Code verloren gehen.
Anwendungsgeheimnisse, Schlüssel und Zertifikate sicher speichern und verwalten.
Azure Key Vault verwenden.
Warum: Key Vault bietet ein zentralisiertes, hardwaregesichertes und geprüftes Repository für Geheimnisse, wodurch verhindert wird, dass diese in Anwendungen fest codiert werden.
Die Sicherheitslage von Cloud-Workloads kontinuierlich bewerten, einen Secure Score erhalten und Bedrohungsschutz erhalten.
Microsoft Defender for Cloud verwenden.
Warum: Defender for Cloud bietet Cloud Security Posture Management (CSPM) und Cloud Workload Protection (CWP) in Azure-, Hybrid- und Multi-Cloud-Umgebungen.
Netzwerkverkehr auf Subnetz-/NIC-Ebene vs. zentral für das gesamte VNet filtern.
Network Security Groups (NSGs) für grundlegende Layer 3/4 Stateful-Paketfilterung verwenden. Azure Firewall für eine zentralisierte, vollständig zustandsbehaftete Firewall-as-a-Service mit Layer 7-Filterung und Threat Intelligence verwenden.
Warum: NSGs sind einfach und dezentral. Azure Firewall bietet erweiterte Funktionen und ein zentralisiertes Richtlinienmanagement, oft in einer Hub-Spoke-Topologie eingesetzt.
Die Angriffsfläche von VMs reduzieren, indem Management-Ports (RDP/SSH) standardmäßig geschlossen bleiben.
Just-In-Time (JIT) VM-Zugriff in Microsoft Defender for Cloud aktivieren.
Warum: JIT gewährt temporären On-Demand-Zugriff auf Management-Ports für eine begrenzte Zeit und schließt diese danach automatisch. Dies ist sicherer, als Ports dauerhaft offen zu lassen.
Den Zustand der Azure-Infrastruktur vs. die Leistung des Anwendungscodes überwachen.
Azure Monitor für Plattformmetriken und -protokolle verwenden. Application Insights (ein Feature von Azure Monitor) für Application Performance Management (APM) verwenden.
Warum: Azure Monitor sammelt Infrastrukturdaten (CPU, Speicher). Application Insights bietet tiefgreifende Diagnosen auf Code-Ebene (Antwortzeiten, Abhängigkeiten, Ausnahmen).
Personalisierte Warnungen über Azure-Dienstausfälle, geplante Wartungsarbeiten und Gesundheitsberatungen erhalten.
Azure Service Health verwenden.
Warum: Service Health ist personalisiert für Ihre Abonnements, Regionen und Dienste, im Gegensatz zur öffentlichen Azure Status-Seite. Es ist für Azure-Plattformprobleme gedacht, nicht für den Zustand Ihrer eigenen Ressourcen.
Personalisierte, umsetzbare Empfehlungen zur Optimierung von Azure-Ressourcen erhalten.
Azure Advisor-Empfehlungen prüfen.
Warum: Advisor analysiert Ihre Konfiguration und Nutzungs-Telemetriedaten und gibt Empfehlungen in fünf Bereichen: Zuverlässigkeit, Sicherheit, Leistung, Kosten und Operative Exzellenz.
Eine standardisierte, gesteuerte und skalierbare Grundlage für alle Azure-Workloads in einem Unternehmen schaffen.
Eine Azure Landing Zone-Architektur implementieren.
Warum: Landing Zones bieten einen präskriptiven Rahmen aus dem Cloud Adoption Framework, einschließlich Management Group-Struktur, Netzwerk, Identität und Governance-Richtlinien, um die sichere Cloud-Einführung zu beschleunigen.