Je workload beheren: back-up, sleutels, monitoring, quota¶
Het platform geeft je een veilige plek om te draaien. Je workload gezond houden is aan jou (Verantwoordelijkheden). Deze pagina behandelt de punten waar teams het vaakst naar vragen.
Back-up en herstel¶
De MCP spoke baseline deployt geen backup vault of back-upbeleid voor je en maakt geen back-up van je VM's, databases of file shares. Regel dit dus zelf:
- Kies per resource de back-upservice (bijvoorbeeld Azure Backup met een Recovery Services vault, ingebouwde back-ups van databases, blob versioning en soft delete).
- Bepaal retentie, frequentie en geo-redundantie op basis van je classificatie.
- Test herstel regelmatig. Een back-up die je nooit hebt hersteld, is geen back-up.
- Leg je herstelprocedure vast en wie die uitvoert.
Als je platform de Managed VM-module aanbiedt, krijgen VM's die ermee zijn gedeployd een Recovery Services vault, een standaardpolicy en foutmeldingen via alerts. Zie Back-up en herstel van managed VM's voor de standaardwaarden en de herstelstappen.
Je platform kan als onderdeel van de governance een back-upbeleid toevoegen (bijvoorbeeld automatische back-up van getagde VM's). Vraag het aan je platformteam. Als dat zo is, moet het de standaardpolicy, de retentie en de manier om je uit te sluiten (meestal een exclusion tag) vermelden.
Van een klantplatform
Een klantplatform deployde per landing zone een Recovery Services vault: geo-redundant, soft delete aan, immutable, publieke toegang uit, versleuteld met een customer-managed key, met dagelijkse VM- en file-share-policies (10 dagen dagelijks, 4 weken wekelijks), plus Azure Policy die elke VM en file share zonder exclusion tag aanmeldde. Dat is geen onderdeel van het MCP-product. Het laat zien wat een platform er bovenop kan toevoegen.
Langetermijnarchief¶
Data die je niet meer gebruikt maar wel moet bewaren voor compliance, audits of naslag hoort niet in een draaiende workload. Sommige platformen bieden hiervoor een archive spoke: een storage account dat geen enkele andere spoke en geen enkele gebruiker kan bereiken, beschermd met vaulted backups. De data wordt gekopieerd naar een Backup Vault, die redundant en geo-gerepliceerd is over twee regio's.
Een typische retentie (een voorbeeld, bepaald door je platform): elke dag een back-up, 7 dagen bewaard. Een maandelijkse back-up wordt 90 dagen bewaard en een jaarlijkse back-up 365 dagen. Soft delete op de vault staat 14 dagen aan. Vraag je platformteam of er een archive spoke is, wat de retentie is en hoe je data erin krijgt.
Patching en updates¶
OS-updates van VM's zijn van jou (Verantwoordelijkheden). Azure Update Manager met maintenance configurations is de gebruikelijke tool: een tag op de VM selecteert het schema en je controleert achteraf het resultaat. Zie Updates en patching van managed VM's voor de schema's, de controle en de handmatige procedure. Servers buiten Azure kunnen op dezelfde manier worden gepatcht na onboarding naar Azure Arc.
Secrets van app registrations¶
Client secrets van app registrations verlopen. Zie Secrets van app registrations voor de verlengingsstappen en voor de meldingen over verlopen secrets die sommige platformen bieden.
Versleuteling en customer-managed keys¶
- Data at rest in Azure is standaard versleuteld met door Microsoft beheerde sleutels.
- De spoke baseline maakt een Key Vault (RBAC, purge protection, private endpoint) en een storage account dat een customer-managed key gebruikt uit die Key Vault.
- Voor je eigen resources kun je customer-managed keys (CMK) gebruiken als je classificatie daarom vraagt. Microsoft Learn beschrijft dit per service: storage accounts, VM-disks (disk encryption sets), SQL transparent data encryption en de lijst met services die CMK ondersteunen.
- Sleutelrotatie en sleuteltoegang voor je resources zijn van jou.
Logging en monitoring¶
Hoe het platform alerts afhandelt: Monitoring en alerting.
| Wat | Wie | Opmerkingen |
|---|---|---|
| Platformgezondheid (hub, firewall, gateways) | Platformteam | Azure Monitor Baseline Alerts en Service Health alerts, met alertroutering naar het platformteam |
| Logs van je resources | Jij | Stuur diagnostic settings naar jouw Log Analytics workspace (de spoke maakt er standaard een). Policy kan sommige diagnostic settings voor je deployen. |
| Je applicatie-alerts en dashboards | Jij | Alertregels, action groups en dashboards op je workspace |
| Security recommendations | Jij, voor je subscription | Defender for Cloud en Advisor, als dat op je platform is ingeschakeld |
| Kosten | Jij | Zie Kosten en reserveringen |
Een platform kan ook centrale dashboards bieden (bijvoorbeeld firewall-logs per spoke, in een managed Grafana). Vraag wat je platform aanbiedt. Logs van hubcomponenten zoals de Application Gateway kunnen ook voor je beschikbaar worden gemaakt, zie Application Gateway-logs.
Controleer de dagelijkse ingestielimiet
Een Log Analytics workspace kan een dagelijkse datalimiet hebben om onverwachte kosten te voorkomen. Als er geen logs meer binnenkomen, controleer dan de limiet op de workspace.
Quota- en capaciteitsproblemen¶
Gebruik dit als een deployment faalt met QuotaExceeded, OperationNotAllowed, AllocationFailed of
ZonalAllocationFailed, nieuwe VM's niet starten, of AKS-nodes niet kunnen schalen.
- Lees de foutmelding en noteer de scope: subscription, regio, resourcetype, SKU.
- Controleer de quota: portal → je subscription → Usage + quotas, gefilterd op regio en provider. Vergelijk Current usage met Limit.
- Controleer via de 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 - Interpreteer:
- Gebruik dicht bij de limiet: vraag een quota-verhoging aan voor die subscription, regio en dat resourcetype.
- Gebruik onder de limiet maar de deployment faalt: dan is de regionale of zonale capaciteit of de beschikbaarheid van de SKU het probleem. Gebruik een andere SKU, een andere zone of (als policy dat toestaat) een andere regio.
- Sluit een platformincident uit: controleer Azure Service Health en Resource Health.
- Voorkom herhaling: controleer de quota vóór grote releases, leg de minimale capaciteit per omgeving vast (vCPU's, IP's, disks), stel alerts in op gebruik versus limiet en voeg een quotacheck toe aan je releasechecklist.
De regiokeuze is beperkt tot de regio's waarin je hub draait en die je policies toestaan.
Resources deployen¶
Gebruik infrastructure as code (Terraform is de tool van het platform; Bicep werkt ook voor deployments die alleen Azure betreffen) vanuit je eigen pipelines met de spoke service principal, bij voorkeur met workload identity federation (Je spoke gebruiken). Vermijd handmatige wijzigingen via de portal in productie.