Azure compute selection is an architecture decision first, shaped by workload requirements, operating model, scalability, resilience, and governance. Service features matter, but they should be evaluated in the context of how the workload must run and be managed.
Für AZ-305 und für reale Architekturarbeit greift das zu kurz: Entscheidend sind Workload-Verhalten, Betriebsmodell, Resilienzanforderungen, Kostenmuster, Identität und Governance.
Zuletzt aktualisiert: 2026. Die folgenden Erläuterungen orientieren sich an allgemein verfügbaren Azure-Diensten; regionale Verfügbarkeit, SKU-Details, SLA-Bedingungen und Preview-Funktionen sollten vor einer Architekturentscheidung stets in der offiziellen Microsoft-Dokumentation geprüft werden.
AZ-305 und die Rolle von Compute-Entscheidungen
Die Prüfung AZ-305: Designing Microsoft Azure Infrastructure Solutions bewertet nicht, ob Kandidaten einzelne Azure-Dienste auswendig beschreiben können. Sie prüft, ob sie Infrastrukturentscheidungen unter Architekturbedingungen treffen: Verfügbarkeit, Sicherheit, Kosten, Skalierung, Migration, Betrieb und Integration.
Compute ist dabei ein Kernbereich, weil jede Anwendung irgendwo ausgeführt werden muss. In der Praxis stehen häufig vier Optionen im Vordergrund: virtuelle Maschinen, Azure Kubernetes Service, Azure App Service und Azure Functions. Für die Prüfung ist weniger wichtig, jeden Parameter zu kennen, sondern zu erkennen, welche Option zu welchem Szenario passt und welche Nebenwirkungen die Entscheidung erzeugt.
Eine häufige Fehlannahme betrifft virtuelle Maschinen. Azure-VMs bedeuten nicht automatisch dedizierte physische Hardware; sie laufen standardmäßig virtualisiert auf gemeinsam genutzter Azure-Infrastruktur. Dedizierte physische Hosts sind ein separates Architektur- und Compliance-Instrument, etwa über Azure Dedicated Host, und sollten nur dort eingeplant werden, wo Isolation, Lizenzierung oder regulatorische Anforderungen dies rechtfertigen.
Die wichtigsten Azure-Compute-Optionen im Architekturkontext
Virtuelle Maschinen sind sinnvoll, wenn eine Anwendung starke Betriebssystemkontrolle benötigt, spezielle Agents oder Treiber voraussetzt, Legacy-Abhängigkeiten besitzt oder zunächst per Lift-and-Shift migriert werden soll. Sie bieten große Flexibilität, verschieben aber viel Verantwortung auf das Betriebsteam: Patching, Hardening, Backup, Monitoring, Skalierung und Hochverfügbarkeit müssen bewusst entworfen werden.
Azure Kubernetes Service eignet sich für containerisierte Anwendungen, Microservices, portable Deployments und Teams mit ausgereifter CI/CD-Praxis. AKS reduziert den Aufwand für die Kubernetes-Control-Plane, beseitigt aber nicht die Komplexität von Containerbetrieb. Cluster-Upgrades, Node-Pools, Ingress, Netzwerkmodelle, Secrets, Observability und Readiness- beziehungsweise Liveness-Probes bleiben Architekturthemen.
Azure App Service passt zu Webanwendungen und APIs, bei denen ein verwaltetes Hosting-Modell wichtiger ist als Betriebssystemkontrolle. Deployment Slots, integrierte Skalierung, TLS-Verwaltung und Plattform-Patching vereinfachen den Betrieb erheblich. Dafür müssen Anwendungen in das Plattformmodell passen, etwa bei Runtime-Versionen, Dateisystemannahmen, Netzwerkzugriff und Hintergrundverarbeitung.
Azure Functions ist vor allem dann stark, wenn Code ereignisgesteuert ausgeführt wird: Nachrichtenverarbeitung, Automatisierungen, Integrationslogik, geplante Jobs oder Reaktionen auf Storage-, Event- oder HTTP-Ereignisse. Der serverlose Ansatz kann Kosten senken, wenn Last unregelmäßig ist. Gleichzeitig müssen Start-up-Latenz, Laufzeitgrenzen, Zustandsverwaltung und idempotente Verarbeitung sorgfältig berücksichtigt werden.
Ein praktischer Entscheidungsrahmen für VMs, AKS, App Service und Functions
In AZ-305-Szenarien ist die richtige Antwort selten der Dienst mit der längsten Featureliste. Häufig entscheiden weniger sichtbare Faktoren: Ist die Anwendung zustandsbehaftet oder zustandslos? Wie schnell muss sie nach einem Ereignis starten? Wie vorhersehbar ist die Last? Gibt es ein Team, das Kubernetes stabil betreiben kann? Wie reif sind Build-, Test- und Deployment-Pipelines?
| Compute-Option | Typischer Einsatz | Architektur-Trade-off |
|---|
| Virtuelle Maschinen | Legacy-Workloads, spezielle Betriebssystemanforderungen, Lift-and-Shift | Hohe Kontrolle, aber mehr Betriebsverantwortung für Patching, HA und Sicherheit |
| AKS | Containerisierte Anwendungen, Microservices, portable Plattformen | Starke Orchestrierung, aber höhere Anforderungen an Plattform- und DevOps-Reife |
| App Service | Web-Apps, APIs, standardisierte Plattform-Deployments | Weniger Infrastrukturaufwand, aber stärkere Bindung an das verwaltete Laufzeitmodell |
| Functions | Ereignisverarbeitung, Automatisierung, kurzlebige Aufgaben | Feine Skalierung und mögliches Skalieren auf null, aber besondere Anforderungen an Zustands- und Fehlerbehandlung |
Aus Kostensicht ist die Laufzeitform oft wichtiger als der Listenpreis eines Dienstes. Eine dauerhafte Webanwendung in App Service verursacht ein anderes Kostenmuster als eine selten ausgelöste Function. VM-Reservierungen, Azure Hybrid Benefit, Spot-VMs, VM Scale Sets und AKS-Node-Autoscaling können die Total Cost of Ownership erheblich beeinflussen, wenn sie zum tatsächlichen Lastprofil passen.
Governance begrenzt die theoretisch ideale Lösung oft stärker als erwartet. Landing Zones, Core-Quotas, Netzwerkrichtlinien, Azure Policy, Namensstandards und Tagging-Vorgaben bestimmen, ob ein Dienst in einer Organisation operativ tragfähig ist. Ein AKS-Cluster kann technisch passend sein, aber unpraktisch werden, wenn Betrieb, Netzwerkfreigaben, Container Registry, Image-Scanning und Cluster-Upgrades nicht geregelt sind.
Resilienz ist kein Haken in der Konfiguration
Hochverfügbarkeit und Disaster Recovery werden in Compute-Designs häufig vermischt. Hochverfügbarkeit reduziert Ausfälle innerhalb des normalen Betriebs, etwa durch Availability Zones, mehrere Instanzen, Load Balancing und automatisches Healing. Disaster Recovery beschreibt dagegen, wie ein System nach einem größeren Ausfall wiederhergestellt wird, einschließlich RPO, RTO, Datenreplikation, Failover-Prozessen und Tests.
Bei virtuellen Maschinen sind Zonen, Availability Sets, VM Scale Sets, Backup und Update-Strategien zentrale Bausteine. Ein einzelner Server bleibt auch in der Cloud ein einzelner Fehlerpunkt, wenn Anwendung, Datenhaltung und Netzwerkpfade nicht redundant entworfen sind. Wartungsfenster und Patching müssen genauso geplant werden wie in klassischen Rechenzentren, nur mit anderen Werkzeugen.
Bei AKS verändert Kubernetes die Fehlerbilder. Readiness-Probes verhindern, dass Traffic zu nicht bereiten Pods geleitet wird; Liveness-Probes können fehlerhafte Container neu starten. Das ersetzt keine Anwendungsresilienz, hilft aber, Ausfälle schneller einzugrenzen. Node-Pools über Zonen hinweg, Pod Disruption Budgets und kontrollierte Rollouts sind typische Architekturthemen, die in szenariobasierten Prüfungsfragen relevant werden können.
App Service bietet mit Deployment Slots eine praktische Grundlage für Blue-Green- oder Canary-ähnliche Deployments. Slot-Swaps können Risiken bei Releases reduzieren, sofern Konfiguration, Datenbankmigrationen und Session-State sauber behandelt werden. Azure Functions benötigt dagegen besondere Aufmerksamkeit bei Wiederholungen, Dead-Letter-Queues und Durable Functions, wenn Workflows über mehrere Schritte hinweg zuverlässig laufen sollen.
Sicherheit und Identität im Compute-Design
Compute-Design ohne Identitäts- und Sicherheitsmodell bleibt unvollständig. Microsoft Entra ID sollte als zentrale Identitätsplattform betrachtet werden, während Managed Identities in vielen Fällen den Umgang mit Geheimnissen ersetzen. Anwendungen greifen dann auf Key Vault, Storage, Datenbanken oder andere Dienste zu, ohne Credentials im Code, in Konfigurationsdateien oder in Pipelines zu speichern.
Microsoft Defender for Cloud unterstützt die Bewertung und Absicherung von Workloads. Der Dienst ist besonders nützlich, wenn Empfehlungen und Alerts nicht isoliert bleiben, sondern in Betriebsprozesse einfließen. In reifen Umgebungen werden Findings aus Defender for Cloud mit Ticketing, CI/CD-Qualitätskontrollen, Image-Scanning oder Policy-Ausnahmen verbunden, damit Sicherheitsprobleme nicht erst nach dem Deployment sichtbar werden.
Für VMs reduziert Just-in-Time-Zugriff die Angriffsfläche administrativer Ports. Für AKS zählen zusätzlich Container-Image-Herkunft, Runtime-Hardening, Netzwerksegmentierung und Secret-Management. Für App Service und Functions sind Private Endpoints, eingeschränkter öffentlicher Zugriff, verwaltete Zertifikate, minimale Berechtigungen und saubere Trennung von App-Einstellungen entscheidende Kontrollpunkte.
Kurzfallstudie: vom Monolithen zur hybriden Azure-Architektur
Ein typisches Migrationsszenario beginnt mit einer monolithischen Webanwendung, die auf mehreren Windows-Servern läuft und eine relationale Datenbank nutzt. Der erste Schritt kann eine Migration auf Azure-VMs sein, weil dadurch Betriebssystemabhängigkeiten, Installationsroutinen und bestehende Monitoring-Agenten zunächst erhalten bleiben. Diese Entscheidung ist nicht elegant, aber oft risikoarm, wenn ein Rechenzentrum zeitnah verlassen werden muss.
Nach der Stabilisierung kann der Webanteil in App Service verschoben werden, sofern Runtime und Konfiguration kompatibel sind. Deployment Slots erleichtern kontrollierte Releases, und das Betriebsteam muss weniger Zeit in Betriebssystempflege investieren. Hintergrundjobs, die bisher als Windows-Dienst liefen, können je nach Muster entweder als Container in AKS oder als Azure Functions neu gestaltet werden.
Im nächsten Reifegrad werden einzelne Komponenten containerisiert, etwa ein rechenintensiver Dokumentverarbeitungsdienst, der unabhängig skaliert werden muss. AKS ist hier sinnvoll, wenn das Team Containerbetrieb, Observability und Rollout-Strategien beherrscht. Ereignisgesteuerte Benachrichtigungen oder Integrationsaufgaben können parallel in Functions ausgelagert werden, wenn sie kurzlebig, wiederholbar und lose gekoppelt sind.
Diese hybride Zielarchitektur ist oft realistischer als ein vollständiger Plattformwechsel in einem Schritt. Sie zeigt auch, warum AZ-305-Fragen selten nach einer isolierten Ressource fragen. Die bessere Architektur entsteht durch schrittweise Entkopplung, klare Verantwortungsgrenzen und ein Betriebsmodell, das zum Team passt.
AZ-305-Vorbereitung mit Compute-Szenarien
Eine sinnvolle Vorbereitung auf AZ-305 verbindet offizielle Prüfungsziele mit praktischen Architekturentscheidungen. Kandidaten sollten sich nicht nur fragen, was ein Dienst kann, sondern welche Entscheidung unter bestimmten Einschränkungen am wenigsten Betriebsrisiko erzeugt. Die Skills der Prüfung umfassen unter anderem das Entwerfen von Compute-, Storage-, Netzwerk- und Sicherheitslösungen; Compute-Fragen erscheinen deshalb häufig im Zusammenspiel mit Identität, Kostenoptimierung und Verfügbarkeit.
Typische Lernfehler entstehen, wenn Dienste nach Bekanntheit statt nach Workload-Muster gewählt werden. Stateful Workloads in AKS, VM Scale Sets für kontrollierbare horizontale Skalierung, App Service für standardisierte Web-Workloads und Functions für Ereignisverarbeitung haben jeweils ihren Platz. Ebenso wichtig sind Reservierungen, Azure Hybrid Benefit, Quoten, regionale Verfügbarkeit und die Trennung von Identität über Microsoft Entra ID.
Wer strukturierte Übung mit szenariobasierten Entscheidungen sucht, kann ein AZ-305 Training von Readynez als Ergänzung zu Microsoft Learn und praktischen Azure-Labs nutzen. Der größere Lerngewinn entsteht jedoch aus dem bewussten Vergleichen von Optionen: Warum nicht App Service? Warum nicht AKS? Welche Betriebsannahme macht eine VM in diesem Fall akzeptabel?
FAQ
Welche Azure-Compute-Dienste sind für AZ-305 besonders wichtig?
Besonders relevant sind virtuelle Maschinen, Azure Kubernetes Service, Azure App Service und Azure Functions. Je nach Szenario können außerdem VM Scale Sets, Azure Virtual Desktop, Container Apps oder spezialisierte Plattformdienste eine Rolle spielen, doch die Prüfung konzentriert sich stark auf Architekturentscheidungen und Trade-offs.
Wann sollte eine virtuelle Maschine statt App Service oder Functions gewählt werden?
Eine VM ist sinnvoll, wenn Betriebssystemkontrolle, Legacy-Abhängigkeiten, spezielle Software, bestimmte Agents oder ein schneller Lift-and-Shift im Vordergrund stehen. Sie ist weniger passend, wenn das Ziel primär geringer Betriebsaufwand, automatische Plattformpflege oder ereignisgesteuerte Skalierung ist.
Ist AKS für jede containerisierte Anwendung die richtige Wahl?
Nein. AKS lohnt sich vor allem, wenn Orchestrierung, mehrere Services, flexible Rollouts, Portabilität und ein reifes Plattformteam benötigt werden. Für einfachere Web-Apps oder APIs kann App Service oft weniger Betriebsaufwand verursachen.
Welche Kostenaspekte sind bei Compute-Entscheidungen wichtig?
Wichtig sind Laufzeitmuster, Skalierungsverhalten, Reservierungen, Azure Hybrid Benefit, Spot-Optionen, Storage- und Netzwerknebenkosten sowie Betriebsaufwand. Functions können bei unregelmäßigen Ereignissen vorteilhaft sein, während Always-On-Dienste bei konstanter Last planbarer sein können.
Wie wichtig ist Hands-on-Erfahrung für AZ-305?
Praktische Erfahrung ist sehr wichtig, weil die Prüfung szenariobasierte Entscheidungen testet. Wer selbst Deployments, Skalierung, Managed Identities, Monitoring, Slots oder AKS-Rollouts eingerichtet hat, erkennt die Konsequenzen einer Architekturentscheidung schneller.
Compute-Entscheidungen sicherer treffen
Azure Compute für AZ-305 lässt sich am besten als Architekturthema verstehen, nicht als Dienstkatalog. Virtuelle Maschinen, AKS, App Service und Functions lösen unterschiedliche Probleme, und jede Option bringt eigene Annahmen zu Betrieb, Kosten, Sicherheit und Resilienz mit.
Die stärkste Vorbereitung besteht darin, Szenarien durchzuspielen und jede Entscheidung zu begründen: Workload-Verhalten, Skalierung, Zustandsverwaltung, Identität, Compliance, Recovery-Ziele und Teamfähigkeit. Readynez kann dabei als strukturierter Lernrahmen unterstützen, doch die eigentliche Kompetenz entsteht durch wiederholtes Entwerfen, Vergleichen und Verwerfen von Alternativen.
