Workload betreiben: Backup, Schlüssel, Monitoring, Kontingent

Die Plattform bietet dir einen sicheren Ort zum Betrieb. Dafür zu sorgen, dass dein Workload gesund bleibt, liegt bei dir (Verantwortlichkeiten). Diese Seite listet die Punkte auf, nach denen Teams am häufigsten fragen.

Backup und Wiederherstellung

Die MCP-Spoke-Baseline stellt keinen Backup-Vault und keine Backup-Policies für dich bereit und sichert weder deine VMs, Datenbanken noch Dateifreigaben. Plane das selbst:

• Wähle den Backup-Dienst pro Ressource (zum Beispiel Azure Backup mit einem Recovery Services vault, integrierte Backups von Datenbanken, Blob-Versionierung und Soft Delete).
• Lege Aufbewahrungsdauer, Häufigkeit und Geo-Redundanz anhand deiner Klassifizierung fest.
• Teste Wiederherstellungen regelmäßig. Ein Backup, das du nie wiederhergestellt hast, ist kein Backup.
• Dokumentiere dein Wiederherstellungsverfahren und wer es durchführt.

Deine Plattform kann im Rahmen ihrer Governance eine Backup-Policy ergänzen (zum Beispiel automatisches Backup von getaggten VMs). Frag dein Plattform-Team. Falls ja, sollte es die Standard-Policy, die Aufbewahrungsdauer und die Möglichkeit zum Opt-out (meist ein Ausschluss-Tag) benennen.

Wenn deine Plattform das Managed-VM-Modul anbietet, erhalten damit deployte VMs einen Recovery Services vault, eine Standard-Policy und Fehler-Alerts. Siehe Backup und Wiederherstellung von Managed VMs für die Standardwerte und die Schritte zur Wiederherstellung.

Aus einer Kundenplattform

Eine Kundenplattform hat pro landing zone einen Recovery Services vault bereitgestellt: geo-redundant, Soft Delete aktiv, unveränderlich (immutable), öffentlicher Zugriff deaktiviert, mit einem Customer-managed Key verschlüsselt, mit täglichen Policies für VMs und Dateifreigaben (10 Tage täglich, 4 Wochen wöchentlich) sowie einer Azure Policy, die jede VM und Dateifreigabe ohne Ausschluss-Tag automatisch einbindet. Das ist nicht Teil des MCP-Produkts. Es zeigt, was eine Plattform zusätzlich bieten kann.

Langzeitarchiv

Daten, die du nicht mehr nutzt, aber aus Compliance-, Audit- oder Referenzgründen aufbewahren musst, gehören nicht in einen laufenden Workload. Manche Plattformen bieten dafür einen Archiv-Spoke an: ein Storage Account, das kein anderer Spoke und kein Benutzer erreichen kann, geschützt mit Vaulted Backups. Die Daten werden in einen Backup Vault kopiert, der redundant und über zwei Regionen geo-repliziert ist.

Eine typische Aufbewahrung (ein Beispiel, von deiner Plattform festgelegt): ein Backup pro Tag, 7 Tage aufbewahrt. Ein monatliches Backup wird 90 Tage aufbewahrt und ein jährliches Backup 365 Tage. Soft Delete am Vault ist 14 Tage aktiv. Frag dein Plattform-Team, ob ein Archiv-Spoke existiert, wie lang die Aufbewahrung ist und wie du Daten dorthin bekommst.

Patching und Updates

OS-Updates von VMs liegen bei dir (Verantwortlichkeiten). Azure Update Manager mit Maintenance Configurations ist das übliche Werkzeug: Ein Tag an der VM wählt den Zeitplan, und du prüfst danach das Ergebnis. Siehe Updates und Patching von Managed VMs für die Zeitpläne, die Prüfung und das manuelle Verfahren. Server außerhalb von Azure lassen sich nach dem Onboarding zu Azure Arc auf dieselbe Weise patchen.

Secrets von App Registrations

Client Secrets von App Registrations laufen ab. Siehe Secrets von App Registrations für die Schritte zur Erneuerung und für die Ablaufbenachrichtigungen, die manche Plattformen bieten.

Verschlüsselung und Customer-managed Keys

• Daten im Ruhezustand werden in Azure standardmäßig mit von Microsoft verwalteten Schlüsseln verschlüsselt.
• Die Spoke-Baseline erstellt einen Key Vault (RBAC, Purge Protection, private endpoint) und ein Storage Account, der einen Customer-managed Key aus diesem Key Vault verwendet.
• Für deine eigenen Ressourcen kannst du Customer-managed Keys (CMK) einsetzen, wenn deine Klassifizierung das verlangt. Microsoft Learn beschreibt das pro Dienst: Storage Accounts, VM-Disks (Disk Encryption Sets), SQL Transparent Data Encryption und die Liste der Dienste, die CMK unterstützen.
• Schlüsselrotation und Schlüsselzugriff für deine Ressourcen liegen in deiner Verantwortung.

Logging und Monitoring

Wie die Plattform alarmiert: Monitoring und Alerting.

Was	Wer	Hinweise
Plattform-Health (hub, firewall, Gateways)	Plattform-Team	Azure Monitor Baseline Alerts und Service Health alerts, mit Alert-Routing an das Plattform-Team
Logs deiner Ressourcen	Du	Sende Diagnostic Settings an deinen Log Analytics workspace (der Spoke erstellt standardmäßig einen). Policy kann einige Diagnostic Settings für dich bereitstellen.
Deine Anwendungs-Alerts und Dashboards	Du	Alert-Regeln, Action Groups und Dashboards auf deinem Workspace
Sicherheitsempfehlungen	Du, für deine subscription	Defender for Cloud und Advisor, falls auf deiner Plattform aktiviert
Kosten	Du	Siehe Kosten und Reservierungen

Eine Plattform kann außerdem zentrale Dashboards bereitstellen (zum Beispiel firewall-Logs pro Spoke in einem Managed Grafana). Frag nach, was deine Plattform anbietet. Logs von hub-Komponenten wie dem Application Gateway können dir ebenfalls bereitgestellt werden, siehe Application-Gateway-Logs.

Tägliches Ingestion-Limit prüfen

Ein Log Analytics workspace kann ein tägliches Datenlimit haben, um überraschende Kosten zu vermeiden. Wenn keine Logs mehr ankommen, prüfe das Limit am Workspace.

Kontingent- und Kapazitätsprobleme

Nutze dies, wenn ein Deployment mit QuotaExceeded, OperationNotAllowed, AllocationFailed oder ZonalAllocationFailed fehlschlägt, neue VMs nicht starten oder AKS-Nodes nicht skalieren können.

1. Lies die Fehlermeldung und notiere den Scope: subscription, Region, Ressourcentyp, SKU.
2. Prüfe das Kontingent (Quota): Portal → deine subscription → Usage + quotas, gefiltert nach Region und Provider. Vergleiche Current usage mit Limit.
3. Prüfe über die CLI:

   az account set --subscription "<subscription-id>"
   az vm list-usage --location <region> --output table
   az vm list-skus --location <region> --resource-type virtualMachines --output table
   

4. Interpretiere das Ergebnis:
5. Auslastung nahe am Limit: Beantrage eine Kontingenterhöhung (Quota increase) für diese subscription, Region und diesen Ressourcentyp.
6. Auslastung unter dem Limit, das Deployment schlägt aber fehl: Das Problem liegt in der regionalen oder zonalen Kapazität bzw. der SKU-Verfügbarkeit. Nutze eine andere SKU, eine andere Zone oder (wenn die Policy es erlaubt) eine andere Region.
7. Schließe einen Plattform-Incident aus: Prüfe Azure Service Health und Resource Health.
8. Wiederholungen vermeiden: Prüfe das Kontingent vor großen releases, halte die Mindestkapazität pro Umgebung fest (vCPUs, IPs, Disks), richte Alerts für Auslastung gegenüber Limit ein und nimm eine Kontingentprüfung in deine release-Checkliste auf.

Die Regionswahl ist auf die Regionen beschränkt, in denen dein hub läuft und die deine Policies erlauben.

Ressourcen bereitstellen

Nutze Infrastructure as Code (Terraform ist das Werkzeug der Plattform; Bicep funktioniert ebenfalls für reine Azure-Deployments) aus deinen eigenen pipelines mit dem Spoke Service Principal, idealerweise mit Workload Identity Federation (Spoke nutzen). Vermeide in Produktion manuelle Änderungen im Portal.