Azure Cloud Adoption Framework: Erfolgreiches Cloud-Management mit der Manage-Phase

Einleitung

In den vergangenen Wochen haben wir im Rahmen der Azure Governance Starter Blog-Reihe die unterschiedlichen Phasen des Azure Cloud Adoption Frameworks behandelt und die jeweiligen Aufgabenfelder, Empfehlungen und Ziele herausgearbeitet. Der nachfolgende Blog-Beitrag ist dabei der letzte Blog-Beitrag dieser Blog-Reihe und fokussiert sich auf die Inhalte der Manage-Phase des Cloud Adoption Frameworks.

Einordnung der Manage-Phase

In den vergangenen Phasen des Cloud Adoption Frameworks haben wir uns mit der Planung, Vorbereitung, Umsetzung und Absicherung Ihrer Cloud-Umgebung beschäftigt. Nun möchten wir das Szenario betrachten, indem Ihre Cloud-Umgebung erfolgreich umgesetzt wurde und fortführend verwaltet werden muss.

An dieser Stelle setzt die Manage-Phase des Cloud Adoption Frameworks zur Erhaltung der Effizienz, Resilienz und Sicherheit Ihrer Cloud-Umgebung an.

Als zentrale Methodik der Manage-Phase empfiehlt Microsoft die Verwendung des RAMP-Ansatzes. Der RAMP-Ansatz hilft Organisationen, die operative Basis zu strukturieren und zu stärken:

• Ready: Teams, Prozesse und Tools aufsetzen, um Cloud-Vorgänge effektiv zu starten.
• Administer: Zentrale und workload-spezifische Verantwortlichkeiten definieren und konsequent ausführen.
• Monitor: Cloud-Zustand, Kosten und Compliance überwachen und aktiv steuern.
• Protect: Risiken minimieren, Sicherheitsstandards etablieren und Notfallwiederherstellung sicherstellen.

Diese Vorgehensweise ähnelt den Inhalten der vorherigen Phasen, fokussiert sich aber hauptsächlich auf die Verwaltung der bestehenden Cloud-Ressourcen.

Ready - Vorbereitung der Cloudvorgänge

Identifizieren von Verwaltungsaufgaben

Die Verwaltung von Azure lässt sich in Plattform- und Workload-Ebene unterteilen.

• Zentrale Verantwortlichkeiten betreffen die gesamte Cloud-Umgebung wie Sicherheitsrichtlinien, Kostenmanagement oder übergreifende Netzwerktopologien.
• Workload-Verantwortlichkeiten beziehen sich auf einzelne Anwendungen oder Services wie Architekturentscheidungen, Kostenoptimierungen oder Performance-Tuning.

Während das Plattformteam Azure-Richtlinien, Identity Governance und Abonnementgrenzen definiert, sorgt das Workload-Team dafür, dass die jeweilige Applikation den bestehenden Cloud Vorgaben entspricht, sicher konzipiert ist und ihre Ressourcen effizient nutzt.

Aufbau eines effektiven Cloud-Betriebsmodells

Um diese Verantwortlichkeiten greifbar zu machen, empfiehlt das CAF ein strukturiertes Vorgehen:

• Cloud-Betriebsmodell wählen: Abhängig von Größe und Reifegrad Ihres Unternehmens sind Ihre Cloud-Teams zentralisiert, dezentral oder hybrid aufgebaut.
• Plattform-Verantwortlichkeiten zuweisen: Ein dediziertes Team übernimmt zentrale Aufgaben wie Governance, Verwaltung der Azure-Subscription oder Netzwerktopologien.
• Workload-Verantwortlichkeiten definieren: Eigenständige Teams kümmern sich um Anwendungen, deren Lebenszyklen und workload-spezifische Sicherheitsmaßnahmen.
• Rollen und Eigentümer festlegen: Jede Aufgabe bekommt einen klar benannten Verantwortlichen von CI/CD-Pipelines bis hin zu Kostenoptimierungsmaßnahmen.

Dokumentation als Rückgrat des Betriebs

Um die Abläufe, Verantwortlichkeiten und Vorgehensweisen effizient zu dokumentieren, empfiehlt das Azure Cloud Adoption Framework die Dokumentation auf den folgenden zwei Ebenen:

• Betriebliche Verfahren wie Änderungsmanagement, Notfallwiederherstellung oder Releaseverfahren.
• Runbooks und Playbooks für häufige Aufgaben wie Skalierungsmaßnahmen bei hoher CPU-Auslastung oder Failover-Szenarien in Azure Site Recovery.

Zentral gespeichert und regelmäßig aktualisiert, stellen sie sicher, dass jeder Vorfall konsistent und effizient bearbeitet werden kann.

Automatisierung als Produktivitätshebel

Moderne Cloud-Vorgänge setzen stark auf Automatisierung. Azure bietet für die Überwachung und Durchsetzung von Security- und Governance-Maßnahmen vielfältige Werkzeuge wie zum Beispiel:

• Azure Policy für Compliance und Governance.
• Microsoft Defender for Cloud und Sentinel für automatisierte Bedrohungserkennung und -reaktion.
• Azure Monitor + Service Health für die Identifikation und Behandlung von Incidents bzw. Störungen.
• Logic Apps und Azure Automation für Workflow- und Änderungsmanagement.

Die Automatisierung von wiederholbaren Aufgaben unterstützt Ihr Team dabei sich auf die strategische Weiterentwicklung Ihrer Azure Cloud zu konzentrieren.

Kontinuierliche Verbesserung im Betrieb

Die Verwaltung schließt dabei auch die Optimierung und Verbesserung der bestehenden Cloud-Architektur ein. Im Cloud Adoption Framework werden dazu folgende Beispiele gelistet:

• Regelmäßige Betriebsüberprüfungen, um Metriken, Vorfälle und Risiken zu bewerten.
• Schulungen und Upskilling der Teams in Themen wie Kostenkontrolle, Security Operations oder Business Continuity and Disaster Recovery.
• Feedbackschleifen, um Learnings aus Vorfällen direkt in Runbooks, Automatisierungen und Architekturen zurückzuführen.

Administer - Verantwortlichkeiten definieren

Verwaltungsumfang bestimmen

Basierend auf den verwendeten Ressourcentypen kann sich die Verantwortlichkeit in Richtung Microsoft oder Teams verschieben. Während Sie On-Premise die volle Verantwortung tragen, können sie stufenweise bei der Wahl von IaaS, PaaS oder SaaS Lösungen immer mehr grundlegende Verantwortlichkeiten an die Verfügbarkeit der grundlegenden Azure Dienste abgeben. Daher sollten Sie die verwendeten Dienste kategorisieren und den jeweiligen Verwaltungsaufwand bestimmen und an die jeweiligen Teams delegieren.

Verwalten von Änderungen

Die häufigste Störquelle in Cloud-Umgebungen sind unkoordinierte Änderungen und Anpassungen. Deshalb braucht es einen robusten Change-Management-Prozess, der Änderungen formal erfasst, nach Risiko bewertet, mit passenden Genehmigungen versieht und anschließend standardisiert bereitstellt. Kritische Änderungen an hochverfügbaren Systemen erfordern mehrstufige Reviews, progressive Bereitstellungsmodelle wie Canary oder Blue/Green und aktives Monitoring.

Geringfügige Anpassungen an unkritischen Diensten dürfen dagegen automatisiert über CI/CD ausgerollt werden, sofern Tests und Validierungen greifen. Nach der Bereitstellung prüfen Health-Checks und Logs die Stabilität, während ein klar definierter Rollback-Pfad die schnelle Wiederherstellung bei Problemen sicherstellt. Nicht autorisierte Änderungen lassen sich mit Azure Policy, der Analyse der Change-History und dedizierten Merge Requests verhindern oder erkennen.

Sicherheitsmaßnahmen verwalten

Microsoft Entra ID dient als einheitliche Plattform für Identity- und Access-Management. Rollenbasierte (RBAC) und attributbasierte (ABAC) Zugriffskontrollen stellen sicher, dass nur die minimal notwendigen Rechte vergeben werden. Just-in-Time-Berechtigungen mit Privileged Identity Management verhindern dauerhaft privilegierte Konten.

Sichere Ressourcenkonfigurationen entstehen ausschließlich aus Code, ergänzt durch Azure Policy und Defender for Cloud. Auf der Authentifizierungsseite sind mehrstufige Verfahren (MFA) und bedingter Zugriff Pflicht. Microsoft Sentinel unterstützt zusätzlich als SIEM/SOAR-Lösung die Sicherheitsüberwachung und Reaktion auf Vorfälle.

Compliance verwalten

Compliance bedeutet, Governance-Regeln nicht nur zu definieren, sondern sie auch durchzusetzen. Azure Policy stellt sicher, dass organisatorische wie regulatorische Vorgaben im Betrieb wirksam werden. Dazu gehören allgemeine Richtlinien wie erlaubte Regionen oder Ressourcentypen ebenso wie branchenspezifische Standards. Wichtig ist ein kontinuierlicher Regelkreis bei dem die Ressourcen und Prozesse definiert, gemessen, Abweichungen erkannt und konsequent korrigiert werden.

Verwalten von Daten

Die Verwaltung von Daten umfasst Klassifizierung, Schutz und Residenz. Microsoft Purview unterstützt bei der Identifikation und Kategorisierung sensibler Daten. Regionen müssen bewusst gewählt und regelmäßig überprüft werden, um Anforderungen an Datenresidenz einzuhalten. Interne und öffentlich zugängliche Workloads sollten strikt getrennt in Management-Gruppen organisiert sein.

Zugriffskontrollen wie RBAC und ABAC knüpfen an die Datenklassifizierung an. Soft Delete, Versionierung und Immutable Policies schützen vor Datenverlust, während Access Policies unbefugte Änderungen blockieren. Ressourcensperren sollten dabei nur in Ausnahmefällen genutzt werden, da sie IaC-Prozesse behindern.

Kosten verwalten

Kostenkontrolle in Azure bedeutet vor allem Transparenz. Microsoft Cost Management liefert Budgets, Warnungen und Reports, während Tagging die Verursacher sichtbar macht. Workload-Teams benötigen Zugriff auf ihre Kostenberichte und sollten die Well-Architected-Empfehlungen zur Optimierung umsetzen. Azure kennt keine festen Kosten-Limits für Subscriptions, deshalb sind Budgets, Alarme und verantwortungsvoller Umgang unverzichtbar.

Verwalten von Code

Code- und Laufzeitverwaltung liegt in den Händen der Workload-Teams. Operative Exzellenz entsteht daher durch CI/CD-Automatisierung, Feature-Flags, resiliente Entwurfsmuster, Telemetrie ab dem ersten Commit und regelmäßige Tests unter Realbedingungen.

Damit Anwendungen robust und steuerbar bleiben, empfiehlt sich die konsequente Orientierung an der Operational Excellence Säule des Well-Architected Frameworks.

Verwalten von Cloud-Ressourcen

Änderungen im Azure Portal sind praktisch für Prototyping, in der Produktion jedoch gefährlich, weil sie Drift erzeugen. Produktive Änderungen sollten ausschließlich aus versionskontrollierten Vorlagen (Bicep, Terraform oder ARM) erfolgen.

CI/CD-Pipelines bauen, prüfen und deployen. Dieses Vorgehen gilt für Anwendungscode als auch Infrastruktur-Anteile. Konfigurationsabweichungen lassen sich durch regelmäßige Vergleiche von Live-Umgebung und gewünschtem Zustand erkennen, während ein last known good-Zustand als Rollback-Referenz dient.

Ressourcenwildwuchs wird idealerweise durch Naming- und Tagging-Standards, Azure Policy und RBAC eingedämmt und durch Aufräumzyklen mit Azure Advisor und Resource Graph ergänzt.

Verlagerung verwalten

Regionswechsel können notwendig sein, um regulatorische Anforderungen einzuhalten, die Performance zu verbessern oder Kosten zu optimieren. Jede Verlagerung ist jedoch ein Unterfangen mit klaren Risiken. Daher müssen akzeptable Downtime-Fenster definiert, Stakeholder informiert und doppelte Umgebungen nach der Migration konsequent abgebaut werden. Kleinere Teams migrieren Workloads sequenziell, große Organisationen orchestrieren mehrere Workloads parallel, um Synergien zu nutzen.

Verwalten von Betriebssystemen

Wer virtuelle Maschinen einsetzt, muss auch Betriebssysteme managen. Automatisierung mit Azure Machine Configuration und Azure Automation sorgt für konsistente Bereitstellung und Wartung.

Patchen ist dabei sowohl auf Gast- als auch auf Host-Ebene Pflicht. Mit Change Tracking & Inventory mit dem Azure Monitoring Agent lassen sich In-Guest-Operationen nachvollziehen, unabhängig davon, ob die VMs in Azure, On-Premises oder in einer anderen Cloud laufen.

Monitor: Cloud-Zustand, Kosten und Compliance überwachen und aktiv steuern.

Identifizieren des Überwachungsumfangs

Welche Komponenten überwacht werden müssen, hängt stark vom Bereitstellungsmodell ab. Während in On-Premises-Umgebungen alle Ebenen von Hardware über Virtualisierung und Betriebssysteme bis hin zu Daten, Sicherheit und Kosten Ihrer Verantwortung unterliegen, reduziert sich dieser Umfang bei IaaS und PaaS.

Azure übernimmt hier wesentliche Plattformdienste, während Sie weiterhin Dienstgesundheit, Sicherheit, Compliance, Daten und Log-Ausgaben im Blick behalten müssen. Auch bei SaaS-Angeboten bleibt das Monitoring von Sicherheit, Kosten und Governance in Ihrer Verantwortung. Entscheidend ist, dass Sie eine vollständige Inventarisierung durchführen.

Mit dem Azure Resource Graph können Sie Ihre Ressourcen systematisch erfassen. Über Azure Arc erweitern Sie diesen Blick, indem Sie lokale Systeme, Edge-Deployments und andere Clouds nahtlos einbeziehen.

Planen Ihrer Überwachungsstrategie

Eine gute Strategie beginnt mit der Wahl des Betriebsmodells. Kleinere Organisationen profitieren oft von einem zentralisierten Monitoring, das Kosten und Governance vereinfacht, aber Engpässe bergen kann. Größere Unternehmen entscheiden sich häufig für ein gemeinsames Modell.

Während ein zentrales Team Querschnittsthemen wie Sicherheit, Compliance oder Kosten überwacht, tragen Workload-Teams die Verantwortung für ihre Anwendungen. Danach definieren Sie, welche Metriken und Protokolle wirklich relevant sind. Anfangs mag es sinnvoll erscheinen, möglichst viele Daten zu sammeln, doch mit zunehmender Reife sollten Sie Sammlungsumfang und Aufbewahrungszeiten optimieren, um Kosten im Griff zu behalten.

Gleichzeitig müssen gesetzliche Vorgaben erfüllt und forensische Analysen möglich sein. Schließlich entwickeln Sie ein Eskalations- und Warnkonzept, das kritische Ereignisse zuverlässig an die richtigen Teams weiterleitet. Diese Strategie sollte regelmäßig überprüft und iterativ angepasst werden, um auf neue Geschäfts- und Sicherheitsanforderungen zu reagieren.

Entwerfen einer Überwachungslösung

Die Architektur Ihrer Monitoring-Lösung bestimmt, wie effizient Sie Daten sammeln, speichern und analysieren können. Ziel ist ein konsolidiertes System, das Azure, On-Premises, andere Clouds und Edge-Umgebungen gleichermaßen abbildet.

Azure Monitor dient hier als zentrale Plattform, ergänzt durch Azure Arc für externe Datenquellen. Die Konsolidierung in wenige Speicherorte erleichtert Korrelation und Governance, auch wenn Anforderungen wie Data Residency oder Mandantentrennung manchmal eine verteilte Speicherung notwendig machen.

Typische Ziele sind Log Analytics für interaktive Analysen, Storage für Langzeitarchivierung, Event Hubs für die Anbindung an externe SIEM-Systeme und Data Explorer für erweiterte Abfragen. Über Data Collection Rules oder Diagnostic-Settings steuern Sie, welche Daten gesammelt und wohin sie geleitet werden. Azure Policy hilft, Standards wie Agent-Installation und Datenerfassung durchzusetzen.

Für größere Umgebungen sollten Sie auf Infrastructure as Code setzen, um Konfigurationen einheitlich auszurollen. Gleichzeitig ist eine Kostenkontrolle entscheidend. Überprüfen Sie regelmäßig, welche Daten Sie sammeln und wie lange Sie sie aufbewahren und löschen Sie ungenutzte Logs, um Budgetverschwendung zu vermeiden.

Konfigurieren der Überwachung

Hierbei geht es um die Erfassung von Service-Health-Informationen, Sicherheitsereignissen, Compliance-Daten, Kostenmetriken sowie Ressourcenauslastung.

Azure Service Health liefert Benachrichtigungen über plattform-seitige Störungen und Wartungen, während Resource Health den Zustand einzelner Ressourcen dokumentiert. Sicherheitsrelevante Daten stammen aus Entra ID, Defender for Cloud, Sentinel oder Network Watcher. Für Compliance sorgen automatisierte Prüfungen über Azure Policy und Microsoft Purview. Kostenmetriken überwachen Sie mit Cost Management, während Application Insights Telemetrie aus dem Code selbst liefert. Ergänzend stellt Azure Monitor Metrics kontinuierliche Leistungsdaten bereit. Alle diese Signale laufen zusammen und ergeben ein ganzheitliches Bild Ihrer Umgebung.

Konfigurieren von Alerts

Alerts übersetzen Monitoring-Daten in konkrete Aktionen. Sie definieren Schwellenwerte für Leistungs- und Sicherheitsmetriken und stellen sicher, dass relevante Personen sofort informiert werden. Dabei ist es wichtig die Alerts nach Schweregrade zu unterscheiden. Kritische Warnungen betreffen zentrale Dienste und müssen sofort eskaliert werden, während weniger dringende Benachrichtigungen an die operativen Teams gehen.

Azure Monitor Alerts bietet dynamische Schwellenwerte, die sich automatisch an den Normalbetrieb anpassen. Jede Warnung sollte einer Action Group zugeordnet sein, die mindestens eine E-Mail-Benachrichtigung enthält. Ergänzend können SMS, Logic Apps oder die Anbindung an ITSM-Systeme die Reaktionsgeschwindigkeit verbessern. Ziel ist eine Balance zwischen Sensibilität und Rauschunterdrückung, da zu wenige Warnungen zu blinden Stellen führen, zu viele jedoch zu Alarmmüdigkeit.

Visualisieren von Überwachungsdaten

Daten entfalten ihren Wert erst, wenn sie verständlich dargestellt werden. Dashboards und Workbooks im Azure-Portal bieten schnelle Einblicke, während detaillierte Analysen über Log Analytics oder Grafana möglich sind. Workbooks sind ideal für tiefgehende Ursachenforschung und komplexe Korrelationen, Dashboards dagegen für eine klare Übersicht im Tagesbetrieb. Wichtig ist, Visualisierungen an Zielgruppen anzupassen, ein technisches Team benötigt detaillierte Abfragen, während das Management eine aggregierte Sicht auf Kosten, Verfügbarkeit und Compliance braucht. So wird Monitoring nicht nur zum operativen Werkzeug, sondern auch zu einer strategischen Informationsquelle.

Protect: Risiken minimieren und Sicherheitsstandards etablieren

Verwalten der Zuverlässigkeit

Zuverlässigkeit entsteht aus klaren Zielen, belastbarer Architektur und geübten Wiederherstellungsabläufen.

Der erste Schritt ist die Priorisierung Ihrer Workloads nach Geschäftswirkung. Aus dieser Priorität leiten Sie Uptime-SLOs, maximal tolerierbare Ausfallzeiten, Wiederherstellungsziele und die nötige Redundanz ab. Ein geschäftskritischer Dienst mit 99,99 % Uptime darf pro Monat nur wenige Minuten ausfallen. Aktive Bereitstellung über mehrere Regionen, zonenübergreifende Redundanz, aktiver Lastenausgleich und eine Replikationsstrategie, die Datenkonsistenz in Echtzeit sicherstellt, sind dann beispielsweise Umsetzungsmöglichkeiten.

Workloads mit mäßiger Kritikalität kommen häufig mit aktiv-passiver Multi-Region-Architektur und asynchroner Replikation aus, während niedrige Prioritäten oft innerhalb einer Region mit Zonenredundanz stabil genug sind.

Service-Level-Indikatoren (SLIs) wie Fehlerraten, Latenzen oder Health-Signale quantifizieren den Ist-Zustand und dienen als Maßstab für den Ideal-Zustand. Das Recovery Time Objective (RTO) begrenzt, wie lange ein Ausfall dauern darf. Das Recovery Point Objective (RPO) begrenzt dabei den Datenverlust. Beides ergibt sich nicht aus einem Bauchgefühl, sondern aus vorhergehenden Analysen, historischen Incident-Daten und Tests.

Ein pragmatischer Ansatz ist, die jährlich zulässige Ausfallzeit des SLOs durch die erwartete Zahl von Störungen zu teilen. So entsteht ein RTO, das Sie mit Failover-Übungen gegen die Realität halten. Für die Architekturplanung rechnen Sie die erwartete Verfügbarkeit entlang des kritischen Pfades.

In einer Einzelregion multiplizieren Sie die SLAs der beteiligten Dienste, existieren unabhängige Pfade, reduziert sich das Gesamtausfallrisiko, weil Ausfälle nicht kumulativ wirken. In Multi-Region-Aufbauten steigt die effektive Verfügbarkeit weiter, weil ein regionaler Ausfall durch die andere Region abgefedert wird. Diese Berechnungen wiederholen Sie bei jeder Design-Änderung, bis die geschätzte Uptime das SLO sicher übertrifft.

Azure liefert eine umfangreiche Auswahl an Tools, um diese Ziele effizient umzusetzen. Für Datenplattformen stellen Dienste wie Azure Cosmos DB, Azure SQL-Datenbank, Azure Blob Storage und Azure Files native Replikations- und Backup-Fähigkeiten bereit. Wenn dies nicht ausreicht oder Systeme außerhalb Azure beteiligt sind, können Azure Backup und Azure Site Recovery zusätzlich eingesetzt werden.

Den geografischen und zonen-übergreifenden Lastenausgleich realisieren Azure Front Door für HTTP-/HTTPS-Workloads und Azure Traffic Manager für nicht-HTTP-Endpunkte. Innerhalb einer Region verteilen Application Gateway (L7) und Azure Load Balancer (L4) den Verkehr über Verfügbarkeitszonen und Instanzen.

Service-Health und Resource-Health liefern den operativen Puls, während Infrastruktur-als-Code die Konsistenz über alle aktiven und passiven Pfade garantiert. Zusammengenommen bilden diese Bausteine die Reliability Rails, auf denen Sie SLOs wirtschaftlich erreichen können.

Zusammenfassung der Phasen des Cloud Adoption Frameworks

Um die Manage-Phase richtig einordnen zu können, möchte ich die Erkenntnisse der vorherigen Blog-Beiträge in einem Rückblick darlegen. Die Erkenntnisse sind dabei in der folgenden Abbildung dargestellt.

Strategy: Die Vorarbeit innerhalb Ihres Unternehmens

Motivation & Cloud-Mission bestimmen: Bevor die Diskussion über konkrete Schritte zur Umsetzung der Cloud Journey starten kann, müssen in Ihrer Organisation konkrete Gründe definiert werden, die den Einsatz von Cloud-Providern erfordert.

Business-Cases definieren: In diesem Schritt müssen klare Vorteile für die Nutzung von Cloud-Providern existieren, um langfristig in Ihrem Unternehmen den Rückhalt für die Migration von Workloads und Rechenzentren zu erhalten.

Relevante Stakeholder identifizieren: Damit Sie das Ausmaß Ihres Vorhabens einschätzen können, sollten Sie alle relevanten Stakeholder Ihrer Systeme identifizieren. Der Umfang einer Cloud-Migration wird leider erst im Nachhinein deutlich, sodass Sie mit der Identifikation der relevanten Stakeholder bereits eine erste Einschätzung erreichen können.

System- & Anwendungslandschaft analysieren: Um den aktuellen Modernisierungsbedarf Ihrer Anwendungslandschaft einschätzen zu können, sollten Sie Ihre Anwendungslandschaft dokumentieren.

Risiken & SLAs bewerten: Wie kritisch sind Ihre Anwendungen und Systeme? Basierend auf vorherrschenden SLAs können Sie in den nachfolgenden Phasen IHre Migrationsstrategie und die damit verbundenen Risiken besser einschätzen.

Cloud Strategy Team / CCoE etablieren: Eine Cloud Migration kann über einen längeren Zeitraum erfolgen, sodass ein dediziertes Cloud Strategy Teams bei der Standardisierung, Umsetzung und Überprüfung Ihrer Cloud-Ziele unterstützen können.

Erstbewertung der Cloud-Readiness Ihrer Organisation durchführen: Um in den nachfolgenden Phasen der Cloud-Einführung nicht auf Schwierigkeiten zu stoßen, sollten Sie bewerten, ob Ihre Organisation die benötigten Ressourcen und Kompetenzen für die Umsetzung der Cloud Journey besitzt. Darauf aufbauend können Sie neues Personal einstelle, bestehendes Personal umschulen oder externe Unterstützung hinzuziehen.

Daraus ergibt sich ein Cloud Strategy Paper, dass alle initialen Erkenntnisse, Ziele und Rahmeninformationen festhält und im Rahmen der darauf aufbauenden Phasen genutzt werden kann.

Plan: Auswahl des passenden Cloud Providers

Ihre Non-Negotiables für die Cloud-Nutzung definieren: Der Wechsel zu einem bestimmten Cloud-Provider erfordert eine langfristige Investition zur Bereitstellung Ihrer Anwendungslandschaft. Aus diesem Grund sollten Sie vor dem Beginn Ihres Migrationsvorhabens anhand ihrer strategischen Ausrichtung, geltenden Richtlinien und Investitionsbudgets Ihre Non-Negotiables definieren.

Den Lebenszyklus Ihrer Systeme bestimmen: Nicht jeder Workload muss in die Cloud migriert werden. Legacy-Software oder geschäftskritische Systeme können in bestimmten Szenarien in Ihrem On-Site Rechenzentrum weiterhin bereitgestellt werden. Aus diesem Grund sollten Sie Systeme identifizieren, die langfristig verwendet werden und durch Modernisierung Ihre Geschäftsziele unterstützen.

Migrationsstrategie einzelner Systeme definieren: Nach der Bestimmung der relevanten Systeme für Ihre Cloud-Journey gilt es nun die einzelnen Modernisierungsmaßnahmen zu bestimmen. Dabei kann es sich um die Anpassung der Hosting-Umgebung, Modernisierung der Anwendungssoftware oder den Einsatz cloud-nativer Technologien handeln.

Personelles Betriebsmodell definieren: Wie auch in Ihrem On-Premises Rechenzentrum müssen im Rahmen der Cloud-Journey dedizierte Teams, Verantwortlichkeiten und klare Prozesse etabliert werden.

Verantwortlichkeiten kommunizieren: Ihr personelles Betriebsmodell sollte anschließend in Ihrer Organisation kommuniziert, diskutiert und iterativ angepasst werden, damit für die erfolgreiche Umstellung jedes Team-Mitglied über die konkreten nächsten Schritte, Cloud-Mission und Ziele informiert ist.

Organisationsstruktur in der Cloud-Umgebung abbilden: Management Groups, Subscriptions und Tagging-Strategien bieten die Möglichkeit Verantwortlichkeiten, Organisationsstrukturen und Zugehörigkeiten abzubilden. Sie sollten bereits vor Ihrem Migrationsvorhaben ein Konzept zur Überführung dieser Abhängigkeiten erstellen.

Architektonische Designprinzipien definieren: Entwicklungsteams benötigen für die Anbindung von Cloud-Diensten einen Leitfaden und Richtlinien. Eine einheitliche architektonische Umsetzung erleichter dadurch die Wiederverwendung, Anpassung und Überwachung von Softwareanpassungen.

Erstellung der Cloud-Roadmap: Wie in jedem Projektvorhaben sollten Meilensteine, Migrationswellen, Abhängigkeiten und Budgetzyklen im Rahmen einer Cloud-Roadmap festgehalten werden. Die Cloud-Roadmap kann dann zusätzlich als Grundlage für die Planung der Implementierungsschritte verwendet werden.

Zum Ende der Plan-Phase können Sie nun Ihre Cloud Strategy Paper mit einem Cloud-Journey detaillierter ausarbeiten und für die weiterführenden Schritte verwenden.

Ready: Technische und providerspezifische Vorarbeit

Providerspezifische Lösungen und Dienste auswählen: Die Dienste der bekanntesten Hyper-Scaler haben sich in den letzten Jahren sehr start angeglichen. Dennoch existieren Unterschiede im Funktionsumfang einzelner Dienste, sodass Sie sich zeitnah mit dem Solution Design befassen müssen.

Organisationsstruktur umsetzen: Nachdem in der Plan-Phase die Organisationsstruktur skizziert wurde, ist nun diese in die Azure Umgebung zu überführen.

Richtlinien für Identity- und Access Management festlegen: Der Einsatz von Entra ID als IDP, Managed Identities oder Role-Based Access-Control muss ebenfalls klar definiert und kommuniziert werden.

Netzwerk-Topologie umsetzen: Basierend auf Ihren Unternehmensstandorten, Kunden-Stamm oder zukünftigen Skalierungszielen kann Ihre Netzwerk-Topologie unterschiedlich umgesetzt werden. Diese Vorarbeit sollte idealerweise bereits in der Ready-Phase geschehen.

Sicherheitsmaßnahmen umsetzen: Bevor Sie Ihre Workloads migrieren, sollten Sie den empfohlenen Schutz Ihrer Identitäten, Workloads und Netzwerke implementieren.

Monitoring-Prozess definieren: Wie wollen Sie die Verfügbarkeit Ihrer Cloud-Infrastruktur und Anwendungssysteme gewährleisten? Aus diesem Grund sollten Sie bereits zu Beginn einen umfangreichen Monitoring-Prozess definieren und umsetzen.

Business Continuity und Disaster Recovery definieren: Der Katastrophen-Fall kann schneller auftreten als Sie es sich wünschen, sodass Sie zeitnah eine fundierte Strategie zur Behebung kritischer Probleme etablieren sollten.

Als Ergebnis der Ready-Phase haben Sie nun die Cloud-Readiness Ihrer Organisation erfolgreich abgeschlossen bevor es mit der konkreten Migration weitergeht.

Adopt: Migration Ihrer Workloads

Technologien zur Datenmigration und Konnektivität definieren: Bevor mit der Migraiton der Workloads begonnen werden kann, sollten die Dienste und Methoden zur Bereitstellung der On-Premises Konnektivität und Datenmigration festegelegt werden.

Priorisierung der Workloads: Am besten lässt es sich mit Workloads beginnen, die nicht unternehmenskritisch sind. Mit diesen Workloads können Sie erste Erfahrungen sammeln und Ihr Vorgehen für die kritischen Systeme verfeinern.

Zeitplan erstellen: Die Migration von einzelnen Workloads kann zu Abhängigkeiten und Down-Time führen. Daher sollten Sie Ihren Zeitplan stets im Blick haben.

Workloads vorbereiten: Wenn Sie bereits vor der Migration wissen, dass die Anwendungssysteme angepasst werden müssen, sollten sie diese zunächst vorbereiten.

Workloads migrieren: Anschließend kann mit der Migration, Modernisierung und Entwicklung neuer Workloads begonnen werden.

Altsysteme abschalten: Sobald Ihre On-Premise Systeme migriert haben, können Sie mit einem guten Gewissen Ihre Altsysteme in Ihrem On-Premises Rechenzentrum abschalten und die Verantwortung an Ihr Cloud-Team übergeben.

Ihre Systeme sind nun in die Cloud migriert und damit ändern sich auch die Verantwortlichkeiten und Ihr Arbeitsmodus im Team. Daher sollten Sie diese Veränderungen auch in Ihre bestehende Betriebsdokumentation abbilden.

Govern: Steuerung und Optimierung Ihrer Cloud-Umgebungen

Governance-Team aufstellen: Damit Ihre Cloud Strategy langfristig erfolgreich umgesetzt wird, sollte ein dediziertes Governance Team die Einhaltung von Richtlinien, Strategien und Maßnahmen überwachen.

Cloud-Risiken bewerten: Die Sicherheit Ihrer Cloud-Umgebung kann nicht nach dem Abschluss einer bestimmten Phase vernachlässigt werden. Daher sollten stets Cloud-Risiken und Audits verwendet werden, um bestehende Schwachstellen aufzudecken.

Dokumentation von Cloud-Richtlinien: Team-Mitglieder wechseln Abteilungen oder Unternehmen. Daher sollten die Cloud-Richtlinien für bestehende und neue Team-Mitglieder leicht zugänglich existieren.

Governance Richtlinien durchsetzen: Währen die Dokumentation und Kommunikation von Governance-Richtlinien essenziell sind, ist dennoch eine strikte Durchsetzung durch Azure Policies und Drittanbieter-Lösungen sinnvoll.

Kontinuierliches Monitoring: Informationen über Ihre Cloud-Umgebungen sind die Grundlage für Verbesserungen und Optimierungen. Daher ist ein effektives Monitoring unerlässlich.

Die Govern-Phase ist damit kein einzelner Schritt, sondern als allgemeingültig zu verstehen. Als Ergebnis dieser Phase existiert idealerweise ein fundiertes Governancebetriebsmodell.

Secure: Cloud-Ressourcen, Infrastruktur und Workloads absichern.

Security-Team etablieren: Ähnlich wie mit der Umsetzung der Governance-Strategie ist ein dediziertes Security-Team sinnvoll, um Penetration-Tests, Schwachstellen-Management und Verbesserungsvorschläge umzusetzen.

Cloud-Sicherheit als Cloud-Akzeptanz Kriterium: Erst wenn Ihre Workloads vor Unbefugten sicher bereitgestellt werden, sollten Sie Ihre Cloud-Journey als vorläufig abgeschlossen einstufen.

Landing Zones als wesentliches Fundament: Mit Landing Zones können Sie Umgebungen standardisieren und für zukünftige Erweiterungen nutzen. Falls diese Bausteine zusätzlich Ihre Sicherheitsanforderungen erfüllen, ist die Wiederverwendung umso einfacher.

Automatisierung und Kontrolle: Menschen machen Fehler. Dieser menschlichen Komponente kann mit Automatisierung und konkreten Kontrollmechanismen entgegengewirkt werden.

Die Secure Phase ist wie auch die Govern-Phase als kontinuierlicher Prozess zu verstehen. Das Ergebnis dabei ist eine sichere und skalierbare Cloud-Infrastruktur.

Manage: Verwaltung von Cloud-Ressourcen und Betriebsmodellen

Die Manage Phase setzt auf die Umsetzung nach dem RAMP Modell, die dabei folgende Bestandteile besitzt.

Ready: Etablieren Sie ein passendes Betriebsmodell, klare Rollen und Entscheidungswege. Standardisieren Sie das eingesetzte Tooling und die Grundrichtlinien für Governance, Identität und Netz.

Administer: Schneiden Sie Verantwortlichkeiten zwischen Plattform- und Workload-Teams sauber zu und setzen Sie sie mit Prozessen für Change, Deployment und Configuration-Management durch. Standards wie Naming/Tagging, RBAC/PIM und Policy sorgen dabei für Konformität und reibungslosen Betrieb.

Monitor: Sammeln und korrelieren Sie Metriken, Logs und Traces aus Azure, Hybrid und Multicloud zentral. Steuern Sie aktiv via Alerts, Dashboards und Kostenreports, um Verfügbarkeit, Sicherheit und Compliance kontinuierlich zu gewährleisten.

Protect: Härten Sie Identität, Plattform und Workloads mit Baselines, MFA/Conditional Access, Defender/Sentinel und Policy-getriebener Compliance. Untermauern Sie das mit Redundanz, Backups sowie regelmäßig geübten DR-Prozessen, damit Ausfälle schnell erkannt, abgefedert und behoben werden.

Fazit

Mit der Manage-Phase schließen wir die Azure Governance Starter Blog-Reihe ab. In den vergangenen Beiträgen haben wir alle wesentlichen Inhalte des Microsoft Cloud Adoption Framework (CAF) von der strategischen Herleitung über Planung und Umsetzung bis hin zu Governance, Sicherheit und dem operativen Betrieb behandelt.

Die Manage-Phase bündelt diese Fäden. Mit RAMP (Ready, Administer, Monitor, Protect) schaffen Sie ein belastbares Betriebsmodell, trennen Verantwortlichkeiten klar zwischen Plattform- und Workload-Teams, automatisieren wiederkehrende Aufgaben, behalten Kosten und Compliance im Blick und erhöhen die Resilienz durch geübte Wiederherstellungsprozesse. Damit verfügen Sie über einen praxisnahen Leitfaden, um Azure-Umgebungen effizient, sicher und skalierbar von der ersten Idee bis zur Umsetzung zu betreiben.

In der folgenden Übersicht findest du alle bisherigen Beiträge der Azure Governance Starter Blog-Reihe von der ersten Strategiephase bis hin zum operativen Management.

• Teil 1 - Governance Starter: Einleitung zum Azure Cloud Adoption Framework
• Teil 2 - Governance Starter: Strategy, Plan & Ready Phase
• Teil 3 - Governance Starter: Adopt Phase
• Teil 4 - Governance Starter: Govern Phase
• Teil 5 - Governance Starter: Secure Phase
• Teil 6 - Governance Starter: Manage Phase
• Ausblick - Governance Audit