Wie erfahrene IT-Fachkräfte sichere, skalierbare und wirtschaftliche Cloud- und Hybridlösungen mit Microsoft Azure planen
Cloudarchitektur gehört zu den anspruchsvollsten Aufgaben in modernen IT-Organisationen. Unternehmen nutzen Microsoft Azure für Anwendungen, Datenbanken, virtuelle Maschinen, Netzwerke, Identitäten, Sicherheitsdienste und digitale Plattformen. Dabei reicht es nicht aus, einzelne Azure-Dienste zu kennen oder technische Ressourcen bereitzustellen. Eine belastbare Cloudlösung muss sicher, skalierbar, verfügbar, wirtschaftlich und langfristig wartbar sein.
Die Prüfung AZ-305 richtet sich an erfahrene IT-Fachkräfte, die Microsoft-Azure-Lösungen auf Architektur- und Designebene planen möchten. Im Mittelpunkt steht die Fähigkeit, geschäftliche und technische Anforderungen zu analysieren und daraus geeignete Infrastruktur-, Daten-, Governance-, Sicherheits- und Business-Continuity-Lösungen abzuleiten.
Ein Azure Solutions Architect arbeitet dabei nicht ausschließlich mit einem einzelnen Produkt oder einem klar abgegrenzten technischen Bereich. Die Rolle verbindet Identität, Netzwerke, Compute, Storage, Monitoring, Governance, Sicherheit, Migration und Kostenmanagement. Eine Entscheidung in einem dieser Bereiche beeinflusst häufig mehrere andere Komponenten der Gesamtarchitektur.
Wird beispielsweise eine Anwendung über mehrere Azure-Regionen verteilt, verbessert dies möglicherweise die Verfügbarkeit. Gleichzeitig steigen jedoch Komplexität, Datenübertragung und Kosten. Wird ein Dienst ausschließlich über private Netzwerke erreichbar gemacht, erhöht dies die Sicherheit, kann aber zusätzliche Anforderungen an Namensauflösung, Routing und Betrieb erzeugen. Architektur bedeutet daher immer, unterschiedliche Ziele und Einschränkungen gegeneinander abzuwägen.
AZ-305 ist aus diesem Grund keine reine Produktprüfung. Kandidaten müssen verstehen, warum eine bestimmte Azure-Lösung für ein Szenario geeignet ist und welche Alternativen bestehen. Technisches Detailwissen bleibt wichtig, doch im Mittelpunkt steht die Qualität der Architekturentscheidung.
Was eine Azure Solutions Architect Schulung vermittelt
Eine Azure Solutions Architect Schulung vermittelt die Fähigkeit, komplexe Cloud- und Hybridlösungen strukturiert zu planen. Teilnehmende lernen, Anforderungen aufzunehmen, technische Abhängigkeiten zu erkennen und passende Azure-Dienste zu einem zusammenhängenden Lösungsdesign zu verbinden.
Ein wichtiger Ausgangspunkt ist die Analyse der Geschäftsanforderungen. Eine Organisation möchte möglicherweise eine Anwendung modernisieren, ein lokales Rechenzentrum reduzieren oder neue digitale Dienste bereitstellen. Der Architekt muss verstehen, welche Ziele tatsächlich verfolgt werden. Geht es vor allem um Kostenreduzierung, höhere Verfügbarkeit, bessere Skalierbarkeit oder schnellere Entwicklung?
Danach werden die technischen Anforderungen betrachtet. Dazu gehören erwartete Benutzerzahlen, Datenvolumen, Antwortzeiten, Sicherheitsniveau, Wiederherstellungsziele und regulatorische Vorgaben. Auch bestehende Systeme und Kompetenzen spielen eine Rolle. Eine technisch moderne Lösung ist wenig wert, wenn das Unternehmen sie nicht zuverlässig betreiben kann.
Der Kurs behandelt deshalb nicht nur Azure-Produkte, sondern auch Designprinzipien. Dazu gehören hohe Verfügbarkeit, Fehlertoleranz, lose Kopplung, Automatisierung und das Prinzip der geringsten Berechtigung. Diese Prinzipien helfen, Entscheidungen auch dann zu treffen, wenn sich einzelne Dienste und Produktnamen später verändern.
Ein weiterer Schwerpunkt ist die Dokumentation von Architekturentscheidungen. Diagramme, Entscheidungstabellen und Architekturaufzeichnungen helfen dabei, Lösungen für Entwickler, Administratoren, Management und Security-Teams verständlich zu machen. Eine gute Architektur muss nicht nur technisch sinnvoll sein, sondern auch kommuniziert und umgesetzt werden können.
Fallstudien sind für eine solche Schulung besonders wertvoll. Teilnehmende können anhand realistischer Szenarien bewerten, welche Identitäts-, Speicher-, Netzwerk- oder Compute-Lösung geeignet ist. Dabei lernen sie, dass mehrere technisch mögliche Antworten existieren können, aber nicht jede Lösung gleichermaßen gut zu den Anforderungen passt.
Identität, Governance und Monitoring richtig entwerfen
Identität bildet eine der wichtigsten Grundlagen moderner Cloudarchitektur. Benutzer, Anwendungen, Dienste und automatisierte Workloads benötigen kontrollierten Zugriff auf Ressourcen. Microsoft Entra ID stellt dafür zentrale Funktionen für Authentifizierung, Autorisierung und Identitätsverwaltung bereit.
Ein Solutions Architect muss entscheiden, wie Benutzer und Gruppen organisiert werden, welche Rollen notwendig sind und wie privilegierter Zugriff geschützt wird. Administratorrechte sollten nicht dauerhaft und unkontrolliert vergeben werden. Zeitlich begrenzte Rollen, starke Authentifizierung und regelmäßige Access Reviews reduzieren das Risiko kompromittierter Konten.
Auch Workload-Identitäten müssen berücksichtigt werden. Anwendungen und Dienste benötigen häufig Zugriff auf Datenbanken, Speicher oder APIs. Managed Identities können helfen, statische Zugangsdaten zu vermeiden. Dadurch müssen Secrets nicht direkt im Quellcode oder in Konfigurationsdateien gespeichert werden.
Governance sorgt dafür, dass eine Azure-Umgebung langfristig kontrollierbar bleibt. Management Groups, Subscriptions, Ressourcengruppen, Tags und Azure Policy bilden dafür wichtige Bausteine. Ein Architekt muss entscheiden, wie die Organisation strukturiert wird und welche Regeln für neue Ressourcen gelten.
Eine größere Unternehmensgruppe kann beispielsweise verschiedene Subscriptions für Produktion, Entwicklung, Abteilungen oder Regionen verwenden. Management Groups ermöglichen die zentrale Anwendung von Richtlinien über mehrere Subscriptions hinweg. Dadurch lassen sich Sicherheits-, Compliance- und Kostenanforderungen konsistenter durchsetzen.
Azure Policy kann verwendet werden, um bestimmte Konfigurationen zu verlangen oder zu verhindern. Eine Richtlinie kann beispielsweise festlegen, dass Ressourcen nur in genehmigten Regionen erstellt werden dürfen oder dass bestimmte Speicherressourcen keinen öffentlichen Netzwerkzugriff erlauben. Solche Richtlinien sollten sorgfältig getestet werden, da zu strenge Regeln den Betrieb beeinträchtigen können.
Monitoring gehört ebenfalls zur Architektur. Systeme müssen genügend Telemetrie liefern, damit Leistung, Verfügbarkeit und Sicherheit bewertet werden können. Logs, Metriken und Traces sollten nicht erst nach einem Vorfall eingerichtet werden. Sie müssen von Beginn an Teil des Designs sein.
Azure Monitor, Log Analytics und Application Insights können unterschiedliche Signale sammeln. Der Architekt muss entscheiden, welche Daten benötigt werden, wie lange sie aufbewahrt werden und wer darauf zugreifen darf. Zu wenig Telemetrie erschwert Fehlerbehebung und Security Operations. Zu viele unstrukturierte Daten erhöhen dagegen Kosten und Analyseaufwand.
Datenspeicherlösungen passend zum Anwendungsfall auswählen
Azure bietet zahlreiche Speicher- und Datenbankdienste. Die richtige Auswahl hängt nicht allein vom Datenformat ab. Konsistenz, Skalierbarkeit, Abfragemuster, Latenz, Verfügbarkeit, Sicherheit und Kosten müssen gemeinsam betrachtet werden.
Relationale Datenbanken eignen sich für strukturierte Daten und Transaktionen mit klaren Beziehungen. Azure SQL Database bietet eine verwaltete Plattform für viele klassische Unternehmensanwendungen. Azure SQL Managed Instance kann interessant sein, wenn eine stärkere Kompatibilität mit bestehenden SQL-Server-Umgebungen erforderlich ist.
NoSQL-Datenbanken wie Azure Cosmos DB eignen sich für flexible Datenmodelle, globale Verteilung und hohe Skalierbarkeit. Die Vorteile entstehen jedoch nur bei einem geeigneten Partitionsdesign. Eine schlecht gewählte Partitionierung kann Performanceprobleme und unnötige Kosten verursachen.
Azure Storage bietet verschiedene Dienste für Objekte, Dateien, Warteschlangen und Tabellendaten. Blob Storage eignet sich unter anderem für Dokumente, Medien, Backups und Data-Lake-Szenarien. Architekten müssen Speicherklassen, Redundanz und Lebenszyklusregeln berücksichtigen.
Die Wahl der Redundanz hängt von den Anforderungen an Verfügbarkeit und Datenresilienz ab. Lokale Redundanz schützt vor bestimmten Hardwarefehlern innerhalb eines Rechenzentrums. Zonen- oder georedundante Varianten bieten weitergehenden Schutz, verursachen jedoch höhere Kosten und können zusätzliche Architekturentscheidungen erfordern.
Sicherheit spielt bei Datenspeicherung eine zentrale Rolle. Daten sollten verschlüsselt und Zugriffe kontrolliert werden. Private Endpoints können verhindern, dass ein Dienst unnötig über das öffentliche Internet erreichbar ist. Managed Identities und rollenbasierte Berechtigungen helfen, Zugangsschlüssel zu reduzieren.
Auch Datenaufbewahrung und Löschung müssen berücksichtigt werden. Nicht alle Informationen sollten unbegrenzt gespeichert werden. Lifecycle Management kann Daten automatisch in günstigere Speicherklassen verschieben oder nach einer definierten Frist löschen.
Ein Azure Solutions Architect bewertet daher nicht nur, welcher Dienst technisch funktioniert. Entscheidend ist, welcher Dienst die Anforderungen mit angemessener Komplexität und wirtschaftlich sinnvoll erfüllt.
Business Continuity und Disaster Recovery planen
Geschäftskontinuität bedeutet, dass kritische Dienste auch bei Störungen verfügbar bleiben oder innerhalb eines definierten Zeitraums wiederhergestellt werden können. Dafür müssen Unternehmen zunächst verstehen, welche Systeme geschäftskritisch sind und welche Ausfallzeiten akzeptiert werden können.
Zwei wichtige Kennzahlen sind Recovery Time Objective und Recovery Point Objective. Das Recovery Time Objective beschreibt, wie schnell ein System nach einem Ausfall wieder verfügbar sein soll. Das Recovery Point Objective bestimmt, wie viel Datenverlust maximal akzeptiert werden kann.
Diese Werte beeinflussen das Architekturdesign direkt. Eine Anwendung mit sehr kurzen Wiederherstellungszielen benötigt möglicherweise redundante Ressourcen, automatisches Failover und kontinuierliche Replikation. Für ein weniger kritisches System kann ein regelmäßiges Backup ausreichend sein.
Hohe Verfügbarkeit und Disaster Recovery sind dabei nicht identisch. Hohe Verfügbarkeit schützt vor lokalen Fehlern und hält einen Dienst möglichst ohne längere Unterbrechung verfügbar. Disaster Recovery konzentriert sich auf schwerwiegendere Ausfälle, etwa den Verlust einer Region oder einer vollständigen Umgebung.
Availability Zones können Ressourcen über getrennte physische Standorte innerhalb einer Azure-Region verteilen. Multi-Region-Architekturen bieten zusätzlichen Schutz, erhöhen jedoch die Komplexität. Datenreplikation, Traffic Routing und Konsistenz müssen sorgfältig geplant werden.
Azure Site Recovery kann bei der Replikation und Wiederherstellung bestimmter virtueller Maschinen und Workloads helfen. Azure Backup bietet Schutz für verschiedene Daten- und Ressourcentypen. Der Architekt muss entscheiden, welche Kombination für das jeweilige System geeignet ist.
Backups sollten nicht nur erstellt, sondern auch regelmäßig getestet werden. Eine Sicherung besitzt nur dann echten Wert, wenn sie innerhalb der erforderlichen Zeit erfolgreich wiederhergestellt werden kann. Wiederherstellungstests, dokumentierte Runbooks und klare Verantwortlichkeiten gehören daher zur Business-Continuity-Planung.
Auch Abhängigkeiten müssen berücksichtigt werden. Eine Anwendung kann technisch wiederhergestellt sein, aber dennoch nicht funktionieren, wenn DNS, Identitätsdienste, Netzwerkverbindungen oder externe APIs fehlen. Disaster-Recovery-Planung muss deshalb den vollständigen Dienst und nicht nur einzelne Ressourcen betrachten.
Compute, Anwendungen und Netzwerke architektonisch verbinden
Azure bietet verschiedene Compute-Modelle. Dazu gehören virtuelle Maschinen, App Service, Azure Functions, Container Apps, Kubernetes und weitere Plattformdienste. Die Auswahl sollte sich an Betriebsmodell, Skalierung, Kontrolle und Entwicklungsanforderungen orientieren.
Virtuelle Maschinen bieten umfangreiche Kontrolle über Betriebssystem und Laufzeitumgebung. Gleichzeitig entsteht mehr Aufwand für Updates, Sicherheit und Betrieb. Plattformdienste reduzieren diesen Aufwand, setzen jedoch bestimmte technische Rahmenbedingungen voraus.
App Service eignet sich für viele Webanwendungen und APIs. Azure Functions unterstützt ereignisgesteuerte und serverlose Architekturen. Container bieten Portabilität und standardisierte Laufzeitumgebungen. Kubernetes kann komplexe Containerlandschaften orchestrieren, ist jedoch nicht automatisch für jedes Projekt die beste Wahl.
Ein guter Architekt wählt nicht die technisch anspruchsvollste, sondern die angemessenste Lösung. Wenn eine Anwendung problemlos auf einem verwalteten Plattformdienst betrieben werden kann, ist ein komplexer Kubernetes-Cluster möglicherweise unnötig.
Anwendungsarchitektur umfasst auch Integration und Kommunikation. Azure Service Bus kann zuverlässige Nachrichtenübertragung zwischen Diensten ermöglichen. Event Grid unterstützt ereignisgesteuerte Architekturen. API Management kann APIs absichern, veröffentlichen und überwachen.
Lose Kopplung verbessert häufig Skalierbarkeit und Fehlertoleranz. Wenn ein Dienst vorübergehend nicht erreichbar ist, können Nachrichten später verarbeitet werden. Gleichzeitig müssen Entwickler mit doppelten Nachrichten, Verzögerungen und Fehlerzuständen umgehen können.
Netzwerke verbinden alle diese Komponenten. Virtuelle Netzwerke, Subnetze, Routing, Firewalls, Load Balancer und private Endpunkte müssen so gestaltet werden, dass Sicherheit und Erreichbarkeit zusammenpassen.
Ein Hub-and-Spoke-Modell kann zentrale Netzwerk- und Sicherheitsdienste von einzelnen Workloads trennen. In größeren Umgebungen kann Azure Virtual WAN eine alternative oder ergänzende Rolle spielen. Die richtige Wahl hängt von Größe, Regionen, Konnektivität und Betriebsmodell ab.
Hybride Verbindungen können über VPN oder ExpressRoute aufgebaut werden. ExpressRoute bietet private Konnektivität über einen Netzwerkprovider, ist jedoch mit höherem Aufwand und Kosten verbunden. VPN-Verbindungen sind oft schneller einzurichten, nutzen aber eine andere technische Grundlage.
Namensauflösung wird in Hybrid- und Private-Endpoint-Szenarien häufig unterschätzt. Eine technisch korrekte Netzwerkverbindung hilft wenig, wenn Ressourcen nicht über die richtigen Namen erreichbar sind. DNS muss deshalb frühzeitig in das Design einbezogen werden.
Migration und Modernisierung vorhandener Systeme
Viele Azure-Projekte beginnen nicht mit einer vollständig neuen Anwendung. Unternehmen möchten bestehende Server, Datenbanken und Anwendungen migrieren oder schrittweise modernisieren. Ein Solutions Architect muss dafür den aktuellen Zustand analysieren und einen realistischen Zielzustand entwickeln.
Eine Migration kann unterschiedliche Formen annehmen. Beim Rehosting wird eine Anwendung weitgehend unverändert in die Cloud verschoben. Dieser Ansatz kann schnell sein, übernimmt jedoch häufig bestehende technische Altlasten.
Beim Replatforming werden einzelne Komponenten auf verwaltete Azure-Dienste umgestellt, ohne die Anwendung vollständig neu zu entwickeln. Eine lokale SQL-Server-Datenbank könnte beispielsweise auf eine verwaltete Azure-Datenbank migriert werden.
Refactoring oder Rearchitecting geht weiter. Die Anwendung wird verändert, um cloudnative Funktionen wie automatische Skalierung, Messaging oder serverlose Verarbeitung zu nutzen. Dieser Ansatz kann langfristig größere Vorteile schaffen, benötigt aber mehr Zeit, Budget und Entwicklungskompetenz.
Nicht jede Anwendung sollte in gleicher Weise modernisiert werden. Manche Systeme sind stabil, werden nur noch begrenzt verändert und eignen sich für eine einfache Migration. Andere Anwendungen profitieren stark von einer neuen Architektur. Eine strukturierte Bewertung verhindert, dass Modernisierung zum Selbstzweck wird.
Azure Migrate und weitere Werkzeuge können bei Inventarisierung, Bewertung und Planung unterstützen. Dennoch bleibt Architekturentscheidung eine fachliche Aufgabe. Technische Abhängigkeiten, Lizenzierung, Datenmengen, Ausfallfenster und organisatorische Fähigkeiten müssen berücksichtigt werden.
Eine Migration sollte außerdem in Wellen geplant werden. Weniger kritische Workloads eignen sich oft als frühe Pilotprojekte. Die gewonnenen Erfahrungen können anschließend in komplexere Migrationen einfließen.
Nach der Migration beginnt die Optimierung. Ressourcen, Kosten, Sicherheit und Performance sollten überprüft werden. Eine erfolgreiche technische Verschiebung ist noch keine erfolgreiche Cloudtransformation, wenn die Umgebung anschließend wie ein ineffizientes lokales Rechenzentrum betrieben wird.
Kosten, Sicherheit und Betriebsfähigkeit ausbalancieren
Cloudarchitektur muss wirtschaftlich sein. Azure ermöglicht flexible Skalierung, kann aber bei unkontrollierter Nutzung schnell hohe Kosten verursachen. Ein Solutions Architect sollte deshalb Kosten bereits in der Designphase berücksichtigen.
Reservierungen, Savings Plans und passende Ressourcengrößen können Kosten reduzieren. Automatische Skalierung hilft, Ressourcen an die tatsächliche Nachfrage anzupassen. Entwicklungs- und Testumgebungen können außerhalb der Nutzungszeiten teilweise heruntergefahren werden.
Tagging und Kostenstellen erleichtern die Zuordnung. Budgets und Warnungen schaffen Transparenz. FinOps-Prinzipien verbinden technische Nutzung mit finanzieller Verantwortung und helfen Teams, die wirtschaftlichen Auswirkungen ihrer Architekturentscheidungen zu verstehen.
Sicherheit darf dabei nicht allein als zusätzlicher Kostenfaktor betrachtet werden. Fehlende Sicherheitskontrollen können deutlich größere wirtschaftliche Schäden verursachen. Gleichzeitig ist nicht jede maximal strenge Lösung für jeden Workload erforderlich. Schutzmaßnahmen sollten sich am Risiko orientieren.
Betriebsfähigkeit ist ein weiterer Faktor. Eine Architektur muss vom vorhandenen Team verstanden und betreut werden können. Zu viele unterschiedliche Dienste, individuelle Sonderlösungen und komplexe Abhängigkeiten erhöhen den Betriebsaufwand.
Standardisierung und Automatisierung helfen dabei, Komplexität zu reduzieren. Infrastructure as Code ermöglicht wiederholbare Bereitstellungen. Referenzarchitekturen und Plattformstandards schaffen konsistente Lösungen für mehrere Teams.
Ein guter Architekt berücksichtigt deshalb nicht nur die technische Zielarchitektur, sondern auch Organisation, Kompetenzen und Betriebsmodell. Die beste Lösung ist diejenige, die langfristig sicher und zuverlässig betrieben werden kann.
Vorbereitung auf AZ-305 und berufliche Perspektiven
Die Vorbereitung auf AZ-305 sollte auf praktischer Azure-Erfahrung aufbauen. Kandidaten sollten Compute, Netzwerk, Storage, Identität, Monitoring und Sicherheit bereits kennen. Die Prüfung konzentriert sich stärker auf Designentscheidungen als auf einzelne Administrationsschritte.
Ein sinnvoller Lernplan beginnt mit den vier großen Themenbereichen: Identität, Governance und Monitoring, Datenspeicherung, Business Continuity sowie Infrastruktur. Für jeden Bereich sollten Kandidaten Azure-Dienste vergleichen und typische Entscheidungskriterien verstehen.
Fallstudien sind besonders wichtig. Kandidaten können beispielsweise eine weltweit genutzte Anwendung entwerfen, die geringe Latenz, Datenschutz und hohe Verfügbarkeit benötigt. Anschließend werden Datenbank, Compute, Netzwerk, Identität und Disaster Recovery gemeinsam geplant.
Architekturdiagramme helfen, Abhängigkeiten zu erkennen. Ebenso sinnvoll ist es, Entscheidungen schriftlich zu begründen. Warum wurde eine bestimmte Datenbank gewählt? Warum ist eine Multi-Region-Lösung notwendig oder nicht notwendig? Welche Risiken bleiben bestehen?
Praktische Erfahrung mit Azure erleichtert die Vorbereitung erheblich. Wer Ressourcen selbst bereitgestellt, Netzwerke konfiguriert oder Monitoring eingerichtet hat, kann die Konsequenzen von Designentscheidungen besser beurteilen.
AZ-305 richtet sich vor allem an erfahrene Administratoren, Entwickler, Cloud Engineers und technische Berater. Die Zertifizierung kann den Weg in Rollen wie Azure Solutions Architect, Cloud Architect, Infrastructure Architect oder Technical Consultant unterstützen.
Für Unternehmen bietet zertifizierte Architekturkompetenz mehrere Vorteile. Cloudprojekte können konsistenter geplant, Risiken früher erkannt und Kosten realistischer bewertet werden. Gleichzeitig verbessert sich die Zusammenarbeit zwischen Fachbereichen, Entwicklung, Betrieb und Security.
Von einzelnen Azure-Diensten zur belastbaren Gesamtarchitektur
Die zentrale Herausforderung moderner Cloudarchitektur besteht nicht darin, möglichst viele Azure-Dienste einzusetzen. Entscheidend ist, die richtigen Dienste so miteinander zu verbinden, dass eine sichere, skalierbare und wirtschaftliche Lösung entsteht.
AZ-305 vermittelt dafür einen strukturierten Kompetenzrahmen. Die Prüfung verbindet Identität, Governance, Monitoring, Datenspeicherung, Business Continuity und Infrastruktur. Kandidaten müssen technische Möglichkeiten kennen und zugleich ihre Auswirkungen auf Betrieb, Kosten und Risiko bewerten.
Eine Azure Solutions Architect Schulung hilft dabei, den Blick von einzelnen Konfigurationen auf vollständige Systeme zu erweitern. Fachkräfte lernen, Anforderungen zu analysieren, Alternativen zu vergleichen und Architekturentscheidungen nachvollziehbar zu dokumentieren.
Für Unternehmen bedeutet gute Azure-Architektur, dass Cloudressourcen nicht unkoordiniert wachsen. Identitäten, Netzwerke, Daten und Anwendungen werden nach gemeinsamen Prinzipien gestaltet. Dadurch lassen sich Sicherheit und Governance verbessern, ohne Innovation unnötig zu behindern.
Für Fachkräfte bietet AZ-305 die Möglichkeit, vorhandene Azure-Erfahrung auf ein strategischeres Niveau zu bringen. Die Zertifizierung ist besonders wertvoll, wenn sie mit realen Projekten, praktischer Erfahrung und kontinuierlicher Weiterbildung verbunden wird.
Wer Azure-Lösungen professionell entwerfen möchte, sollte Architektur nicht als einmalige Planungsphase betrachten. Anforderungen, Technologien und Risiken verändern sich. Eine belastbare Architektur muss deshalb regelmäßig überprüft und weiterentwickelt werden. Genau diese langfristige Perspektive macht die Rolle des Azure Solutions Architect zu einer der wichtigsten und anspruchsvollsten Aufgaben in modernen Cloudorganisationen.
