# Azure Management & Governance Azure Management & Governance

Technische Referenz zu Azure Monitor, Log Analytics, Application Insights, Advisor, Cost Management + Billing, ARM/Bicep, Resource Graph, Azure Policy, Automation, Arc, Lighthouse, Service Health und Managed Grafana. Technical reference for Azure Monitor, Log Analytics, Application Insights, Advisor, Cost Management + Billing, ARM/Bicep, Resource Graph, Azure Policy, Automation, Arc, Lighthouse, Service Health, and Managed Grafana.

13 13
KQL-Beispiele KQL examples
ARM/Bicep ARM/Bicep
Bereitstellungsdisziplin Deployment discipline
Policy Policy
Governance Guardrails Governance guardrails
Arc Arc
Hybrid-Steuerung Hybrid control
Management ist eine Plattformfunktion Management is a platform capability

Reife Azure-Umgebungen entstehen durch konsistente Scopes, Rollen, Richtlinien, Telemetrie, Bereitstellungen und Incident-Prozesse. Einzelne Portalfunktionen bringen erst in diesem Zusammenspiel echten Nutzen. Mature Azure environments come from consistent scopes, roles, policy, telemetry, deployments, and incident processes. Individual portal features create real value only in that combined operating model.

Ohne Logging-Baseline bleibt vieles unsichtbar Without a logging baseline, many things stay invisible

Viele Probleme werden nicht spät erkannt, weil Alerts fehlen, sondern weil Diagnostic Settings, DCRs oder workspace-basierte Telemetrie nie konsequent eingerichtet wurden. Beobachtbarkeit muss vor dem Go-Live beginnen. Many problems are detected late not because alerts are missing, but because diagnostic settings, DCRs, or workspace-based telemetry were never set up consistently. Observability must start before go-live.

Governance-Basis Governance foundation

Scopes, Resource Groups, Tags und Locks. Scopes, resource groups, tags, and locks.

Observability Observability

Azure Monitor, Log Analytics, Application Insights und Grafana. Azure Monitor, Log Analytics, Application Insights, and Grafana.

KQL Playbook KQL playbook

13 KQL-Abfragen für Betrieb und Governance. 13 KQL queries for operations and governance.

Advisor & Kosten Advisor and cost

Empfehlungen, Budgets, Billing und FinOps. Recommendations, budgets, billing, and FinOps.

ARM & Stacks ARM and stacks

What-If, Deployments und Deployment Stacks. What-if, deployments, and deployment stacks.

Automation & Hybrid Automation and hybrid

Automation, Arc, Lighthouse, Service Health und Graph. Automation, Arc, Lighthouse, service health, and graph.

## Governance-Basis: Management Groups, Subscriptions, Resource Groups, Tags und Locks Governance foundation: management groups, subscriptions, resource groups, tags, and locks

Azure trennt Management Plane und Data Plane. Governance-Mittel wie RBAC, Azure Policy, Locks, Tags und Deployments wirken auf der Management Plane und müssen deshalb vor Workload-spezifischen Designentscheidungen geplant werden. Azure separates the management plane from the data plane. Governance tools such as RBAC, Azure Policy, locks, tags, and deployments act on the management plane and therefore must be planned before workload-specific design decisions.

Bewährte Landing-Zone-Modelle gruppieren Subscriptions nach Verantwortung und Lebenszyklus: Plattform, Konnektivität, Identität, Shared Services, Sandbox, Produktion und Nicht-Produktion. Resource Groups bleiben die operative Einheit für Ressourcen mit gemeinsamem Lebenszyklus. Proven landing-zone models group subscriptions by responsibility and lifecycle: platform, connectivity, identity, shared services, sandbox, production, and non-production. Resource groups remain the operational unit for resources with a shared lifecycle.

Scoping zuerst, Rollen danach Scope first, roles afterwards

Rollen bleiben beherrschbar, wenn zunächst Management-Group- und Subscription-Grenzen definiert und erst danach RBAC-, PIM- und Break-Glass-Konzepte darauf abgebildet werden. Roles remain manageable when management-group and subscription boundaries are defined first and RBAC, PIM, and break-glass concepts are mapped afterwards.

Bereich Area | Azure-Mittel Azure means | Gute Praxis Good practice | Häufiger Fehler Common mistake
--- | --- | --- | ---
Hierarchie Hierarchy | Management Groups, Subscriptions Management groups, subscriptions | Organisation, Ownership und Policy-Vererbung sauber trennen Separate organization, ownership, and policy inheritance cleanly | Subscriptions nur nach Projektnamen anlegen Creating subscriptions only by project name
Ressourcenorganisation Resource organization | Resource Groups, Namensstandards Resource groups, naming standards | Lebenszyklus und Deployment-Grenzen deckungsgleich halten Keep lifecycle and deployment boundaries aligned | Dev, Test und Prod mischen Mixing dev, test, and prod
Schutz Protection | Locks, Activity Log, PIM Locks, activity log, PIM | Delete-Schutz auf Shared Services und klare Notfallpfade Delete protection on shared services and clear emergency paths | Locks ohne definierten Unlock-Prozess Locks without a defined unlock process
Metadaten Metadata | Tags, Policy Modify/Append Tags, policy modify/append | Kostenstelle, Owner, Kritikalität und Klassifikation standardisieren Standardize cost center, owner, criticality, and classification | Tags als Sicherheitskontrolle missverstehen Treating tags as a security control
Bereitstellung Deployment | ARM, Bicep, Template Specs ARM, Bicep, template specs | Idempotente Templates und PR-Reviews erzwingen Enforce idempotent templates and PR reviews | Portal-Hotfixes ohne Rückführung in IaC Portal hotfixes not brought back into IaC

- Management Groups dienen Vererbung und Governance, nicht fachlicher Navigation. Management groups serve inheritance and governance, not business navigation.
- Resource Groups sind Ownership-, Deploy- und Löschgrenzen. Resource groups are ownership, deployment, and deletion boundaries.
- Pflicht-Tags sollten per Policy oder IaC erzwungen werden. Mandatory tags should be enforced through policy or IaC.
- Delete Locks gehören auf gemeinsam genutzte oder kritische Ressourcen. Delete locks belong on shared or critical resources.
- Namensstandards müssen Resource-Graph- und KQL-Abfragen unterstützen. Naming standards must support Resource Graph and KQL queries.

### Scopes und Hierarchie praktisch umsetzen Implementing scopes and hierarchy in practice

Management Groups sind die höchste wiederverwendbare Governance-Schicht unterhalb des Tenants. Sie eignen sich für Baseline-Policies, zentrale RBAC-Zuweisungen, Subscription-Moves und die Trennung zwischen Plattform- und Applikationsverantwortung. Management groups are the highest reusable governance layer below the tenant. They are suited for baseline policy, centralized RBAC assignments, subscription moves, and separation between platform and application responsibility.

Azure CLI Azure CLI

    az account management-group create
      --name corp-platform
      --display-name "Corp Platform"

    az account management-group subscription add
      --name corp-platform
      --subscription 00000000-0000-0000-0000-000000000000

### Tags und Locks automatisieren Automating tags and locks

Tags funktionieren operativ nur dann, wenn sie nicht auf freiwilliger Pflege beruhen. Kombinieren Sie Bicep-Defaults mit Azure Policy und vermeiden Sie freie Vokabulare für Kostenstelle, Umgebung oder Datenklassifikation. Tags work operationally only when they do not depend on voluntary maintenance. Combine Bicep defaults with Azure Policy and avoid free-form vocabularies for cost center, environment, or data classification.

Bicep Bicep

    targetScope = 'resourceGroup'

    resource protectRg 'Microsoft.Authorization/locks@2020-05-01' = {
      name: 'can-not-delete'
      properties: {
        level: 'CanNotDelete'
        notes: 'Protect shared monitoring assets'
      }
    }

## Observability mit Azure Monitor, Log Analytics, Application Insights und Managed Grafana Observability with Azure Monitor, Log Analytics, Application Insights, and Managed Grafana

Azure Monitor ist die übergeordnete Observability-Plattform für Metriken, Logs, Traces, Alerts, Action Groups und Dashboards. Log Analytics Workspaces bilden die KQL-Datensenke für Plattform- und Gasttelemetrie, während workspace-basiertes Application Insights Anwendungsdaten im gleichen Analysemodell verfügbar macht. Azure Monitor is the overarching observability platform for metrics, logs, traces, alerts, action groups, and dashboards. Log Analytics workspaces provide the KQL data store for platform and guest telemetry, while workspace-based Application Insights makes application data available in the same analytics model.

Architektonisch entscheidend sind Workspace-Topologie, Region, Datenresidenz, Aufbewahrung, Private Link, Diagnostic Settings und Data Collection Rules. Wenn diese Themen erst nach dem Go-Live besprochen werden, leiden Datenqualität und Kosten fast immer gleichzeitig. Architecturally, workspace topology, region, data residency, retention, private link, diagnostic settings, and data collection rules are decisive. When these topics are discussed only after go-live, both data quality and cost almost always suffer together.

Platform Logs müssen aktiv eingeschaltet werden Platform logs must be explicitly enabled

Metriken existieren oft sofort, Ressourcendiagnosen aber nur nach expliziter Aktivierung. Aktivieren Sie Diagnostic Settings für Firewalls, Application Gateway, Key Vault, Service Bus und Storage standardmäßig per IaC oder Policy. Metrics often exist immediately, but resource diagnostics require explicit activation. Enable diagnostic settings for firewalls, Application Gateway, Key Vault, Service Bus, and Storage through IaC or policy by default.

Dienst Service | Primärdaten Primary data | Designentscheidung Design decision | Betriebsrisiko Operational risk
--- | --- | --- | ---
Azure Monitor Metrics Azure Monitor Metrics | Zeitreihenmetriken pro Ressource Time-series metrics per resource | Near-Real-Time und Metrikalarme Near real time and metric alerts | Nur Metriken ohne Logkontext beobachten Watching only metrics without log context
Log Analytics Log Analytics | KQL-Logs aus Plattform und Gast KQL logs from platform and guest | Workspace-Topologie, Retention, DCR und Kostensteuerung Workspace topology, retention, DCR, and cost control | Zu viele kleine Workspaces ohne Betriebsmodell Too many small workspaces without an operating model
Application Insights Application Insights | Requests, Dependencies, Exceptions, Verfügbarkeit Requests, dependencies, exceptions, availability | Workspace-based Ressourcen und verteiltes Tracing Workspace-based resources and distributed tracing | Legacy-Komponenten ohne Workspace-Anbindung Legacy components without workspace integration
Alerts & Action Groups Alerts and action groups | Metrik-, Log-, Aktivitäts- und Service-Health-Signale Metric, log, activity, and service health signals | On-call-Routing, ITSM und Eskalation On-call routing, ITSM, and escalation | Alerts ohne Ownership oder Severity-Modell Alerts without ownership or a severity model
Managed Grafana Managed Grafana | Azure Monitor, Prometheus, externe Quellen Azure Monitor, Prometheus, external sources | Rollen, Datenquellen und Dashboards als Code Roles, data sources, and dashboards as code | Grafana als Schattenmonitoring Grafana used as shadow monitoring

- Zentrale Operations-Workspaces nur bei echtem Compliance-Bedarf aufspalten. Split central operations workspaces only when there is a true compliance need.
- Data Collection Rules standardisieren Agent-basierte Datenerfassung auf VMs und Arc-Servern. Data collection rules standardize agent-based data collection on VMs and Arc-enabled servers.
- Workspace-basiertes Application Insights erleichtert Korrelation mit Plattformlogs. Workspace-based Application Insights simplifies correlation with platform logs.
- Basic Logs nur für Daten mit klarer Kostenbegründung verwenden. Use Basic Logs only for data with a clear cost rationale.
- Dashboards und Alerts als Code verwalten. Manage dashboards and alerts as code.

### Workspace-Topologie und Datensammlung Workspace topology and data collection

Zentrale Workspaces funktionieren gut für tenantweite Korrelation und einheitliche Berechtigungen. Mehrere Workspaces sind sinnvoll bei rechtlicher Trennung, extremen Volumenunterschieden oder klar getrennten Betriebsdomänen. Central workspaces work well for tenant-wide correlation and consistent permissions. Multiple workspaces make sense for legal separation, extreme volume differences, or clearly separated operating domains.

Azure CLI Azure CLI

    az monitor log-analytics workspace create
      --resource-group rg-monitoring-prod
      --workspace-name law-platform-prod
      --location westeurope
      --sku PerGB2018

### Workspace-basiertes Application Insights Workspace-based Application Insights

Für moderne Azure-Anwendungen ist workspace-basiertes Application Insights der Standard, weil Requests, Dependencies und Exceptions direkt mit Plattformlogs korreliert werden können. Dadurch entstehen Incident-Zeitleisten statt isolierter Tool-Sichten. For modern Azure applications, workspace-based Application Insights is the standard because requests, dependencies, and exceptions can be correlated directly with platform logs. That creates incident timelines instead of isolated tool views.

Bicep Bicep

    resource appi 'Microsoft.Insights/components@2020-02-02' = {
      name: 'appi-orders-prod'
      location: location
      kind: 'web'
      properties: {
        Application_Type: 'web'
        WorkspaceResourceId: law.id
      }
    }

### Managed Grafana als Operations-Cockpit Managed Grafana as the operations cockpit

Managed Grafana ergänzt Azure Monitor dort, wo mehrere Datenquellen, SLO-Dashboards oder Prometheus-Daten zusammengeführt werden müssen. Die Plattformverantwortung bleibt jedoch bei Azure Monitor und nicht bei der Dashboard-Schicht. Managed Grafana complements Azure Monitor where multiple data sources, SLO dashboards, or Prometheus data must be combined. Platform responsibility, however, remains with Azure Monitor rather than the dashboard layer.

Azure CLI Azure CLI

    az grafana create
      --name grafana-platform-prod
      --resource-group rg-monitoring-prod
      --location westeurope
      --zone-redundancy Enabled

## KQL Playbook für Betrieb, Fehleranalyse und Governance KQL playbook for operations, troubleshooting, and governance

KQL ist die gemeinsame Abfragesprache für Log Analytics und Application Insights; Azure Resource Graph verwendet einen ähnlichen Dialekt für tenantweite Inventur. Reife Plattformteams standardisieren deshalb Query-Bibliotheken für Incident Triage, Kapazitätsplanung, Kostenprüfung und Governance-Audits. KQL is the shared query language for Log Analytics and Application Insights; Azure Resource Graph uses a similar dialect for tenant-wide inventory. Mature platform teams therefore standardize query libraries for incident triage, capacity planning, cost review, and governance audits.

Die folgenden Beispiele decken VM-, Anwendungs-, Policy- und Inventarfragen ab. In produktiven Umgebungen sollten zusätzlich Parameterisierung, gespeicherte Abfragen, Workbooks und Alert-Wiederverwendung etabliert werden. The following examples cover VM, application, policy, and inventory questions. In production environments, teams should also establish parameterization, saved queries, workbooks, and alert reuse.

Ressourcen-IDs normalisieren Normalize resource IDs

Viele Korrelationen scheitern an Groß-/Kleinschreibung oder leicht abweichenden Namen. Nutzen Sie tolower(), trim() und konsistente Naming-Standards, damit Joins zwischen Activity Log, Diagnostics und Resource Graph belastbar funktionieren. Many correlations fail because of casing or slightly different names. Use tolower(), trim(), and consistent naming standards so joins between activity log, diagnostics, and Resource Graph stay reliable.

Beispiel Example | Quelle Source | Frage Question
--- | --- | ---
Heartbeat-Lücken Heartbeat gaps | Heartbeat Heartbeat | Welche Maschinen melden sich nicht mehr? Which machines stopped reporting?
Anwendungsfehler Application failures | AppRequests, AppDependencies, AppExceptions AppRequests, AppDependencies, AppExceptions | Welche Endpunkte und Abhängigkeiten erzeugen Fehler oder Latenz? Which endpoints and dependencies cause errors or latency?
Plattformänderungen Platform changes | AzureActivity AzureActivity | Wer hat kritische Änderungen ausgelöst? Who triggered critical changes?
Kosten und Compliance Cost and compliance | Usage, resources, policyresources Usage, resources, policyresources | Welche Tabellen, Ressourcen oder Richtlinien sind auffällig? Which tables, resources, or policies stand out?

### KQL 01: Heartbeat-Lücken auf VMs und Arc-Servern KQL 01: heartbeat gaps on VMs and Arc-enabled servers

Diese Query identifiziert Maschinen, die länger als 15 Minuten keine Heartbeats mehr gesendet haben. Sie ist für Agent-Ausfälle, Netzwerkprobleme und Offline-Erkennung nach Wartungsfenstern nützlich. This query identifies machines that have not sent heartbeats for more than 15 minutes. It is useful for agent outages, network issues, and offline detection after maintenance windows.

KQL KQL

    Heartbeat
    | summarize LastSeen=max(TimeGenerated) by Computer, _ResourceId
    | extend MinutesSinceLastSeen = datetime_diff('minute', now(), LastSeen)
    | where MinutesSinceLastSeen > 15
    | project Computer, _ResourceId, LastSeen, MinutesSinceLastSeen
    | order by MinutesSinceLastSeen desc

### KQL 02: CPU-Hotspots über 15-Minuten-Fenster KQL 02: CPU hot spots over 15-minute windows

Perf-Daten aus AMA oder MMA bleiben für klassische VM-Kapazitätsanalysen relevant. P95-Werte sind meist aussagekräftiger als reine Durchschnittswerte. Perf data from AMA or MMA remains relevant for classic VM capacity analysis. P95 values are usually more useful than plain averages.

KQL KQL

    Perf
    | where ObjectName == 'Processor'
    | where CounterName == '% Processor Time'
    | where InstanceName == '_Total'
    | summarize AvgCpu=avg(CounterValue), P95Cpu=percentile(CounterValue, 95) by Computer, bin(TimeGenerated, 15m)
    | where P95Cpu > 85
    | order by P95Cpu desc

### KQL 03: Destruktive Plattformoperationen KQL 03: destructive platform operations

AzureActivity ist das primäre Kontrollprotokoll für Änderungen auf der Management Plane. Besonders wertvoll ist die Suche nach Löschungen und kritischen Write-Operationen. AzureActivity is the primary control log for changes on the management plane. It is especially valuable for finding deletions and critical write operations.

KQL KQL

    AzureActivity
    | where ActivityStatusValue == 'Success'
    | where OperationNameValue has_any (
        'Microsoft.Compute/virtualMachines/delete',
        'Microsoft.Resources/subscriptions/resourcegroups/delete',
        'Microsoft.KeyVault/vaults/delete'
    )
    | project TimeGenerated, Caller, OperationNameValue, ResourceGroup, ResourceId, CorrelationId
    | order by TimeGenerated desc

### KQL 04: Fehlgeschlagene Requests nach Endpunkt KQL 04: failed requests by endpoint

Application Insights zeigt mit AppRequests Fehlerhäufigkeit, Latenz und Hotspots pro Operation. Die Query eignet sich auch als Basis für SLO-Reviews. Application Insights shows failure rate, latency, and hot spots per operation through AppRequests. The query is also useful as a basis for SLO reviews.

KQL KQL

    AppRequests
    | where Success == false or ResultCode startswith '5'
    | summarize Failures=count(), P95DurationMs=percentile(DurationMs, 95) by Name, bin(TimeGenerated, 15m)
    | order by Failures desc

### KQL 05: Langsame oder fehlerhafte Abhängigkeiten KQL 05: slow or failing dependencies

AppDependencies zeigt, ob Datenbanken, APIs oder Messaging-Backbones das eigentliche Bottleneck darstellen. P95 und Failures trennen Performance- von Verfügbarkeitsproblemen. AppDependencies shows whether databases, APIs, or messaging backbones are the real bottleneck. P95 and failure counts separate performance issues from availability issues.

KQL KQL

    AppDependencies
    | summarize P50=percentile(DurationMs, 50), P95=percentile(DurationMs, 95), Failures=countif(Success == false) by Target, DependencyType, bin(TimeGenerated, 15m)
    | order by P95 desc

### KQL 06: Top Exceptions nach Operation KQL 06: top exceptions by operation

ProblemId und OperationName reichen oft aus, um Hotspots im Anwendungscode oder in Transaktionspfaden zu identifizieren. Bei Bedarf können Joins auf AppRequests ergänzt werden. ProblemId and OperationName are often enough to identify hot spots in application code or transaction paths. Joins to AppRequests can be added when needed.

KQL KQL

    AppExceptions
    | summarize Exceptions=count() by ProblemId, OperationName, bin(TimeGenerated, 1h)
    | order by Exceptions desc

### KQL 07: Verfügbarkeit aus Synthetic Tests KQL 07: availability from synthetic tests

Availability-Tests sind wertvoll, wenn externe Erreichbarkeit und Response-Zeiten unabhängig vom Anwendungsprozess bewertet werden sollen. Daraus lassen sich belastbare SLI-Zeitreihen ableiten. Availability tests are valuable when external reachability and response times must be assessed independently of the application process. They provide reliable SLI time series.

KQL KQL

    AppAvailabilityResults
    | summarize SuccessRate=100.0 * avg(todouble(Success)), AvgDurationMs=avg(DurationMs) by Name, bin(TimeGenerated, 30m)
    | order by TimeGenerated desc

### KQL 08: Ingestion-Kosten nach Datentyp KQL 08: ingestion cost by data type

Die Usage-Tabelle ist essenziell für FinOps im Monitoring. Sie zeigt, welche Tabellen die größten Volumina verursachen und wo DCR-Filter, Sampling oder Basic Logs sinnvoll sein könnten. The Usage table is essential for monitoring FinOps. It shows which tables create the biggest volumes and where DCR filtering, sampling, or Basic Logs could help.

KQL KQL

    Usage
    | summarize IngestedGB=sum(Quantity) / 1024.0 by DataType, bin(TimeGenerated, 1d)
    | order by IngestedGB desc

### KQL 09: Dead-Letter-Trends für Service Bus KQL 09: dead-letter trends for Service Bus

Wenn Service-Bus-Diagnosen in Log Analytics landen, lassen sich Dead-Letter- und Fehlertrends schnell sichtbar machen. Für Integrationsteams ist das oft wertvoller als reine Metrikalarme. When Service Bus diagnostics land in Log Analytics, dead-letter and error trends become visible quickly. For integration teams this is often more useful than metric alerts alone.

KQL KQL

    AzureDiagnostics
    | where ResourceProvider == 'MICROSOFT.SERVICEBUS'
    | where OperationName has 'DeadLetter' or EntityName_s contains '$DeadLetterQueue'
    | summarize DeadLetters=count() by NamespaceName_s, EntityName_s, bin(TimeGenerated, 1h)
    | order by TimeGenerated desc

### KQL 10: Ungetaggte Ressourcen in Resource Graph KQL 10: untagged resources in Resource Graph

Resource Graph eignet sich für tenantweite Inventur ohne Log-Ingestion. Diese Query findet Ressourcen ohne Tags außerhalb der Microsoft.Resources-Steuerobjekte. Resource Graph is ideal for tenant-wide inventory without log ingestion. This query finds resources without tags outside Microsoft.Resources control objects.

KQL KQL

    resources
    | where type !startswith 'microsoft.resources/'
    | extend TagCount = array_length(bag_keys(tags))
    | where isnull(tags) or TagCount == 0
    | project subscriptionId, resourceGroup, name, type, location
    | order by subscriptionId asc

### KQL 11: Public-IP-Inventar KQL 11: public IP inventory

Public IPs sind ein klassischer Governance- und Security-Indikator. Die Query gibt Überblick über SKU, Zuweisungsart und tatsächliche Adressierung. Public IPs are a classic governance and security indicator. The query gives an overview of SKU, allocation method, and actual addressing.

KQL KQL

    resources
    | where type =~ 'microsoft.network/publicipaddresses'
    | project subscriptionId, resourceGroup, name,
              sku=tostring(sku.name),
              allocation=tostring(properties.publicIPAllocationMethod),
              ip=tostring(properties.ipAddress)
    | order by resourceGroup asc

### KQL 12: Nicht konforme Policy-Ergebnisse KQL 12: non-compliant policy results

Policy-States aus Resource Graph sind für Governance-Reviews meist schneller als manuelle Portalansichten. Damit lassen sich Initiativen, Ressourcenbereiche und Problemhäufungen gezielt auswerten. Policy states from Resource Graph are often faster for governance reviews than manual portal views. They help analyze initiatives, resource scopes, and concentrations of non-compliance.

KQL KQL

    policyresources
    | where type =~ 'microsoft.policyinsights/policystates'
    | where tostring(properties.complianceState) == 'NonCompliant'
    | summarize NonCompliant=count() by PolicyDefinition=tostring(properties.policyDefinitionName), SubscriptionId=subscriptionId
    | order by NonCompliant desc

### KQL 13: Aktive Service-Health-Ereignisse KQL 13: active service health events

Service Health kann per Resource Graph in tenantweite Übersichten einfließen. Das hilft zentralen NOCs oder MSPs, mehrere Subscriptions und Regionen übergreifend zu bewerten. Service Health can flow into tenant-wide views through Resource Graph. That helps central NOCs or MSPs assess multiple subscriptions and regions together.

KQL KQL

    servicehealthresources
    | where tostring(properties.Status) !in ('Resolved', 'Closed')
    | project trackingId=name,
              title=tostring(properties.Title),
              eventType=tostring(properties.EventType),
              status=tostring(properties.Status),
              impactedService=tostring(properties.Impact[0].Service)
    | order by title asc

## Azure Advisor sowie Cost Management + Billing Azure Advisor and Cost Management + Billing

Azure Advisor verdichtet technische Empfehlungen zu Reliability, Security, Performance, Operational Excellence und Cost. Er ersetzt keine Architektur- oder Security-Reviews, ist aber ein wertvoller Trigger für Backlog-Pflege und standardisierte Plattform-Checks. Azure Advisor consolidates technical recommendations across reliability, security, performance, operational excellence, and cost. It does not replace architecture or security reviews, but it is a valuable trigger for backlog grooming and standardized platform checks.

Cost Management + Billing deckt den finanziellen Steuerungsraum ab: Budgets, Kostenanalyse, Tag-basierte Zuordnung, Exporte, Reservierungen, Savings Plans und Chargeback-/Showback-Modelle. Gute FinOps verbindet beide Welten statt sie getrennt zu behandeln. Cost Management + Billing covers the financial control plane: budgets, cost analysis, tag-based allocation, exports, reservations, savings plans, and chargeback or showback models. Strong FinOps connects those worlds instead of treating them separately.

Kosten werden früh durch Architektur entschieden Cost is decided early by architecture

Die größten Einsparungen entstehen selten durch späte Portaloptimierung, sondern durch Entscheidungen zu Region, SKU, Autoscaling, Retention, PaaS-Nutzung, Reservierungen und Abschaltfenstern. The biggest savings rarely come from late portal optimization, but from decisions about region, SKU, autoscaling, retention, PaaS usage, reservations, and shutdown windows.

Funktion Function | Nutzen Benefit | Betriebsmuster Operating pattern | Grenze Limit
--- | --- | --- | ---
Advisor Advisor | Technische Empfehlungen nach Kategorie Technical recommendations by category | Review im Plattform-Backlog und Architekturboard Review in platform backlog and architecture board | Kein Ersatz für Business-Priorisierung Not a replacement for business prioritization
Budgets Budgets | Frühe Kostenwarnung auf Scope-Ebene Early spend warning at scope level | Action Groups und klare Reaktionsprozesse Action groups and clear response processes | Stoppen keine Kosten automatisch Do not stop spend automatically
Cost Analysis Cost analysis | Aufschlüsselung nach Service, Tag und Resource Group Breakdown by service, tag, and resource group | Monatliche FinOps- und Team-Reviews Monthly FinOps and team reviews | Fehlende Tags verfälschen Zuordnung Missing tags distort allocation
Exports Exports | Rohdaten für BI, Chargeback und Forecast Raw data for BI, chargeback, and forecast | Tägliche Exporte in Storage oder BI-Pipeline Daily exports into Storage or a BI pipeline | Zusätzliche Datenpipeline nötig Requires an additional data pipeline
Reservations / Savings Plans Reservations / savings plans | Rabatte für planbare Nutzung Discounts for predictable usage | Kapazitätsdaten vor Kauf analysieren Analyze capacity data before purchase | Überkauf bei schlechter Forecast-Qualität Overbuying with poor forecast quality

- Owner-, CostCenter- und Environment-Tags als harte Pflichtfelder definieren. Define owner, cost center, and environment tags as mandatory fields.
- Budgets mit Action Groups, Teams oder Ticketing verbinden. Connect budgets to action groups, Teams, or ticketing.
- Advisor-Empfehlungen regelmäßig bewerten, aber nur kontextuell sinnvoll umsetzen. Review Advisor recommendations regularly, but implement only what is contextually sound.
- Kostenexports in BI oder Data Warehouse überführen, wenn Business Units verrechnet werden. Feed cost exports into BI or a data warehouse when business units are charged back.
- Monitoring- und Retention-Kosten früh in Architekturentscheidungen einpreisen. Factor monitoring and retention cost into architecture decisions early.

### Advisor-Empfehlungen operationalisieren Operationalizing Advisor recommendations

Advisor entfaltet Wirkung erst dann, wenn Empfehlungen mit Owner, Frist, Risiko und erwartetem Nutzen versehen werden. Besonders effektiv ist ein wiederkehrender Review-Termin zwischen Plattformbetrieb, Security und FinOps. Advisor becomes effective only when recommendations are assigned owners, due dates, risk, and expected benefit. A recurring review between platform operations, security, and FinOps is especially effective.

Azure CLI Azure CLI

    az advisor recommendation list
      --category Cost
      --query "[].{Resource:resourceMetadata.resourceId,Impact:impact,ShortDescription:shortDescription.solution}"
      --output table

### Budgets und Benachrichtigungen Budgets and notifications

Budgets sind Signalgeber, keine automatischen Schutzschalter. Hinterlegen Sie deshalb klare Eskalations- und Bearbeitungspfade, damit Budgetüberschreitungen nachvollziehbar bearbeitet werden. Budgets are signals, not automatic circuit breakers. Attach clear escalation and handling paths so budget overruns are processed transparently.

Azure CLI Azure CLI

    az consumption budget create
      --amount 15000
      --budget-name prod-monthly-budget
      --category cost
      --resource-group rg-finops
      --time-grain monthly

## ARM/Bicep: Deployments, What-If und Deployment Stacks ARM/Bicep: deployments, what-if, and deployment stacks

Azure Resource Manager ist die Orchestrierungsschicht für idempotente Bereitstellung, Abhängigkeiten, Policy-Prüfung, Locks, Role Assignments und Deployment-Historie. Bicep reduziert Template-Aufwand, ohne die ARM-Semantik zu verlassen. Azure Resource Manager is the orchestration layer for idempotent deployment, dependencies, policy evaluation, locks, role assignments, and deployment history. Bicep reduces template overhead without leaving ARM semantics.

Für reife Plattformen sind What-If, Template Specs, modulare Bicep-Strukturen, saubere Scope-Wahl und Deployment Stacks zentral. Sie helfen beim Aufbau ebenso wie beim Drift-Management und beim kontrollierten Entfernen nicht mehr referenzierter Ressourcen. For mature platforms, what-if, template specs, modular Bicep structures, clean scope selection, and deployment stacks are central. They help with initial build-out as well as drift management and controlled removal of resources that are no longer referenced.

What-If vor jedem produktiven Deploy Run what-if before every production deployment

What-If ersetzt kein Review, reduziert aber das Risiko ungewollter Deletes, Replacements und Properties erheblich. Gerade bei Netzwerk- und Shared-Service-Änderungen sollte es Pflicht sein. What-if does not replace review, but it significantly reduces the risk of unintended deletes, replacements, and property changes. It should be mandatory especially for network and shared-service changes.

Scope Scope | Typische Inhalte Typical contents | Wann verwenden When to use | Hinweis Note
--- | --- | --- | ---
Management Group Management group | Policy, Role Assignments, Subscription Moves Policy, role assignments, subscription moves | Landing-Zone-Baselines und Organisation Landing-zone baselines and organization | Nur wenige Ressourcentypen unterstützen diesen Scope Only a limited set of resource types support this scope
Subscription Subscription | Resource Groups, Policy Assignments, Budgets Resource groups, policy assignments, budgets | Plattform-Basics und subscriptionweite Artefakte Platform basics and subscription-wide artifacts | Foundation und Workload sauber trennen Keep foundation and workload separate
Resource Group Resource group | Workload-Ressourcen Workload resources | Applikations- oder Service-Deployments Application or service deployments | Lebenszyklus- und Ownership-Grenzen beachten Respect lifecycle and ownership boundaries
Deployment Stack Deployment stack | Kontrolliertes Löschen und Drift-Management Controlled deletion and drift management | Shared Services und wiederkehrende Plattformpakete Shared services and repeatable platform packages | Action on unmanage bewusst wählen Choose action on unmanage deliberately

- Bicep-Module pro Domäne und Scope statt monolithischer Templates verwenden. Use Bicep modules per domain and scope instead of monolithic templates.
- Freigegebene Foundation-Module als Template Specs oder versionierte Repos veröffentlichen. Publish approved foundation modules as template specs or versioned repos.
- What-If in CI/CD und vor manuellen Notfall-Deployments ausführen. Run what-if in CI/CD and before manual emergency deployments.
- Deployment Stacks nutzen, wenn auch das Entfernen kontrolliert werden soll. Use deployment stacks when removal must also be controlled.
- Deployments immer mit Tags, Locks und Diagnostik zusammendenken. Think of deployments together with tags, locks, and diagnostics.

### Die richtige Scope-Wahl Choosing the right scope

Viele Teams deployen zu viel auf Resource-Group-Ebene, obwohl Budgets, Policy Assignments oder Resource Groups selbst bereits Subscription- oder Management-Group-Scopes benötigen. Korrekte Scope-Wahl vereinfacht Ownership und Pipelines. Many teams deploy too much at resource-group scope even though budgets, policy assignments, or resource groups themselves require subscription or management-group scopes. Correct scope selection simplifies ownership and pipelines.

Bicep Bicep

    targetScope = 'subscription'

    param location string = 'westeurope'
    param rgName string = 'rg-orders-prod'

    resource rg 'Microsoft.Resources/resourceGroups@2024-03-01' = {
      name: rgName
      location: location
      tags: {
        environment: 'prod'
        owner: 'platform-team'
      }
    }

### What-If als Pflichtschritt What-if as a mandatory step

What-If zeigt die Unterschiede zwischen gewünschtem und aktuellem Zustand vor der Anwendung. In Kombination mit Pull Requests und Peer Reviews ist das der wichtigste Schutz gegen unbeabsichtigten IaC-Drift. What-if shows the difference between desired and current state before apply. Combined with pull requests and peer review, it is the most important guard against unintended IaC drift.

Azure CLI Azure CLI

    az deployment group what-if
      --resource-group rg-orders-prod
      --template-file main.bicep
      --parameters @prod.parameters.json

### Deployment Stacks für kontrolliertes Aufräumen Deployment stacks for controlled cleanup

Deployment Stacks helfen überall dort, wo Plattformpakete nicht nur erstellt, sondern später auch wieder sauber zurückgebaut werden sollen. Das ist besonders für Shared Services, Demos und Sandboxes interessant. Deployment stacks help wherever platform packages must not only be created, but later removed cleanly as well. That is especially useful for shared services, demos, and sandboxes.

Azure CLI Azure CLI

    az stack group create
      --name monitor-baseline
      --resource-group rg-monitoring-prod
      --template-file monitor.bicep
      --parameters @prod.parameters.json
      --action-on-unmanage detachAll

## Azure Policy, Remediation und Verknüpfung zur Sicherheitsseite Azure Policy, remediation, and linkage to the security page

Azure Policy ist das verbindliche Regelwerk für Ressourcen-Konfigurationen, Tagging, Allowed Locations, SKU-Grenzen, Network Exposure, Backup- und Monitoring-Baselines sowie regulatorische Vorgaben. Initiativen bündeln diese Regeln zu handhabbaren Governance-Paketen. Azure Policy is the mandatory rule system for resource configuration, tagging, allowed locations, SKU boundaries, network exposure, backup and monitoring baselines, and regulatory requirements. Initiatives bundle those rules into manageable governance packages.

Für die technische Vertiefung zu Security-Baselines, Defender for Cloud und Identitätshärtung sollte diese Seite immer zusammen mit der Referenz Azure Security gelesen werden. Policy ist dabei das Governance-Band zwischen Architekturvorgabe und technischem Enforcement. For a deeper look at security baselines, Defender for Cloud, and identity hardening, this page should always be read together with the Azure Security reference. Policy is the governance bridge between architectural intent and technical enforcement.

Deny ist ein starkes Produktionswerkzeug Deny is a strong production tool

Bevor Deny-Effekte aktiviert werden, müssen Break-Glass-Prozesse, genehmigte Ausnahmen, Remediation-Pfade und die Auswirkungen auf CI/CD klar definiert sein. Ein falsches Deny blockiert auch automatisierte Deployments. Before enabling deny effects, break-glass processes, approved exemptions, remediation paths, and the impact on CI/CD must be clearly defined. A wrong deny blocks automated deployments as well.

Effect Effect | Zweck Purpose | Typischer Einsatz Typical use | Besonderheit Special note
--- | --- | --- | ---
Audit Audit | Verstöße sichtbar machen Make violations visible | Einführung neuer Governance-Regeln Introducing new governance rules | Keine automatische Korrektur No automatic correction
Deny Deny | Nicht erlaubte Änderungen blockieren Block disallowed changes | Allowed Locations, verbotene SKUs, öffentliche Exponierung Allowed locations, forbidden SKUs, public exposure | Kann Pipelines komplett stoppen Can stop pipelines entirely
Modify / Append Modify / append | Metadaten oder Properties ergänzen Add metadata or properties | Tagging und Standardwerte Tagging and standard values | Benötigt korrekte Managed Identity und Rollen Requires the correct managed identity and roles
DeployIfNotExists DeployIfNotExists | Fehlende Artefakte nachziehen Deploy missing artifacts | Diagnostic Settings, AMA und Monitoring-Baselines Diagnostic settings, AMA, and monitoring baselines | Erfordert Remediation- und Deploymentrechte Requires remediation and deployment rights

- Policies pro Domäne in Initiativen bündeln statt hunderte Einzelzuweisungen direkt zu verteilen. Bundle policies by domain into initiatives instead of distributing hundreds of individual assignments directly.
- Ausnahmen mit Ablaufdatum und Begründung versehen. Attach expiration dates and justification to exemptions.
- Policy mit Landing-Zone-Modulen und CI/CD-Prüfungen kombinieren. Combine policy with landing-zone modules and CI/CD validation.
- Remediation Tasks regelmäßig für Altbestände einplanen. Plan remediation tasks regularly for existing inventory.
- Azure Security als ergänzende Vertiefung nutzen. Use Azure Security as the complementary deep dive.

### Initiativen und Parameter sauber modellieren Model initiatives and parameters cleanly

Wiederverwendbare Initiativen arbeiten mit Parametern für Allowed Locations, Tag-Werte, Ausnahmelisten oder Workspace-IDs. Dadurch bleiben sie zwischen Plattformen, Regionen und Umgebungen portierbar. Reusable initiatives rely on parameters for allowed locations, tag values, exception lists, or workspace IDs. That keeps them portable across platforms, regions, and environments.

Bicep Bicep

    resource assignment 'Microsoft.Authorization/policyAssignments@2024-04-01' = {
      name: 'pa-monitoring-baseline'
      properties: {
        displayName: 'Monitoring baseline'
        policyDefinitionId: initiativeId
        parameters: {
          logAnalyticsWorkspaceId: {
            value: law.id
          }
        }
      }
    }

### Ausnahmen und Remediation steuern Control exemptions and remediation

Ausnahmen sollten wie Architekturentscheidungen behandelt werden: begründet, genehmigt, befristet und nachvollziehbar. Für Modify- und DeployIfNotExists-Policies gehören regelmäßige Remediation-Runs in den Betriebsplan. Exemptions should be treated like architecture decisions: justified, approved, time-bound, and traceable. For modify and deployIfNotExists policies, regular remediation runs belong in the operating plan.

Azure CLI Azure CLI

    az policy remediation create
      --name rem-monitoring-baseline
      --policy-assignment pa-monitoring-baseline
      --resource-group rg-orders-prod

## Automation, Azure Arc, Lighthouse, Service Health und Resource Graph Automation, Azure Arc, Lighthouse, service health, and Resource Graph

Azure Automation bleibt relevant für Runbooks, wiederkehrende Plattformaufgaben und die Ausführung mit Managed Identities. Azure Arc erweitert dieses Betriebsmodell auf Server, Kubernetes-Cluster und weitere Ressourcen außerhalb nativer Azure-Compute-Dienste. Azure Automation remains relevant for runbooks, recurring platform tasks, and execution with managed identities. Azure Arc extends that operating model to servers, Kubernetes clusters, and other resources outside native Azure compute services.

Azure Lighthouse ergänzt die technische Steuerung um sichere Delegation über Tenant-Grenzen hinweg. Service Health liefert die Provider-Sicht auf Incidents, während Resource Graph tenantweite Betroffenheitsanalysen und Inventur ohne Log-Ingestion ermöglicht. Azure Lighthouse complements technical control with secure delegation across tenant boundaries. Service Health provides the provider view of incidents, while Resource Graph enables tenant-wide impact analysis and inventory without log ingestion.

Provider-Incident ersetzt keine eigene Triage A provider incident does not replace your own triage

Auch wenn Service Health einen Azure-Ausfall bestätigt, müssen betroffene Workloads, Kundensegmente, Fallback-Pfade und Kommunikationsketten intern bewertet werden. Region und Zonenstrategie entscheiden über die tatsächliche Business-Auswirkung. Even if Service Health confirms an Azure outage, affected workloads, customer segments, fallback paths, and communication chains still require internal assessment. Region choice and zone strategy determine the actual business impact.

Dienst Service | Rolle Role | Geeignet für Best suited for | Wichtiger Hinweis Important note
--- | --- | --- | ---
Azure Automation Azure Automation | Runbooks und Schedule-Orchestrierung Runbooks and schedule orchestration | Plattformjobs, Hygiene-Tasks, einfache Remediation Platform jobs, hygiene tasks, simple remediation | Nicht jedes Modernisierungsproblem gehört in Runbooks Not every modernization problem belongs in runbooks
Azure Arc Azure Arc | Hybrid- und Multicloud-Ressourcen an Azure anbinden Bring hybrid and multicloud resources into Azure control | Serverinventar, Policy, Defender, Update und Monitoring Server inventory, policy, Defender, update, and monitoring | Netzwerk, Identität und Agent-Lifecycle sauber planen Plan network, identity, and agent lifecycle carefully
Azure Lighthouse Azure Lighthouse | Delegiertes tenantübergreifendes Management Delegated cross-tenant management | MSP, Shared Services, zentrale Security/Operations MSP, shared services, central security/operations | Rollen und Zugriffsmodell minimieren Minimize roles and access model
Resource Graph Resource Graph | Tenantweite Inventur und Governance-Queries Tenant-wide inventory and governance queries | Betroffenheitsanalyse, Public-IP-Übersicht, Drift-Suche Impact analysis, public IP overviews, drift hunting | Ersetzt keine Laufzeittelemetrie Does not replace runtime telemetry

- Runbooks bevorzugt mit Managed Identity statt mit gespeicherten Secrets bauen. Prefer managed identities over stored secrets in runbooks.
- Arc-Server direkt mit DCR, Defender und Update-Baselines verbinden. Connect Arc-enabled servers directly to DCR, Defender, and update baselines.
- Lighthouse-Delegationen nach Support- oder Betriebsrollen statt nach Maximalrechten modellieren. Model Lighthouse delegations by support or operations role rather than by maximum rights.
- Service-Health-Alerts für kritische Regionen und Subscriptions einrichten. Set up service health alerts for critical regions and subscriptions.
- Resource-Graph-Queries für Public IPs, Key Vaults und Produktionsdatenbanken pflegen. Maintain Resource Graph queries for public IPs, Key Vaults, and production databases.

### Runbooks mit Managed Identity Runbooks with managed identity

Runbooks sollten möglichst wenig lokale Konfiguration benötigen und vollständig über Rollen, Variablen, Key Vault und Managed Identity steuerbar sein. Dadurch bleiben sie reproduzierbar und auditierbar. Runbooks should need as little local configuration as possible and be fully controlled through roles, variables, Key Vault, and managed identity. That keeps them reproducible and auditable.

PowerShell PowerShell

    Disable-AzContextAutosave -Scope Process
    $null = Connect-AzAccount -Identity
    $running = Get-AzVM -Status | Where-Object { $_.PowerState -eq 'VM running' -and $_.Tags['shutdown'] -eq 'true' }
    $running | ForEach-Object {
        Stop-AzVM -ResourceGroupName $_.ResourceGroupName -Name $_.Name -Force
    }

### Arc-Onboarding und Hybrid-Konsistenz Arc onboarding and hybrid consistency

Arc bringt nicht nur Inventar nach Azure, sondern macht Server für Policy, Update Manager, Defender for Cloud und Log Analytics steuerbar. Ohne saubere Rollen und Outbound-Pfade bleibt der Mehrwert jedoch begrenzt. Arc brings not only inventory into Azure, but also makes servers manageable for policy, Update Manager, Defender for Cloud, and Log Analytics. Without clean role assignments and outbound paths, the value remains limited.

Azure CLI Azure CLI

    az connectedmachine connect
      --resource-group rg-arc-prod
      --location westeurope
      --subscription 00000000-0000-0000-0000-000000000000
      --cloud AzureCloud

### Lighthouse und Service-Health-Alerting Lighthouse and service health alerting

Lighthouse trennt Kunden- oder Tochtertenant sauber vom Betreiber und vereinfacht Governance, SOC-Betrieb und Plattform-Support. Ergänzend sollten Service-Health-Alerts und Resource-Graph-Abfragen tenantübergreifend standardisiert werden. Lighthouse cleanly separates customer or subsidiary tenants from the operator and simplifies governance, SOC operations, and platform support. In addition, service health alerts and Resource Graph queries should be standardized across tenants.

Azure CLI Azure CLI

    az monitor activity-log alert create
      --name service-health-prod
      --resource-group rg-monitoring-prod
      --condition category=ServiceHealth

## Begriffe, Merksätze und Betriebscheckliste Terms, reminders, and operating checklist

Die folgende Übersicht fasst zentrale Management-Begriffe und ihre operative Bedeutung zusammen. Sie eignet sich als kompakte Checkliste für Architektur-Reviews, Plattform-Transitions und Betriebsdokumentation. The following overview summarizes key management terms and their operational meaning. It serves as a compact checklist for architecture reviews, platform transitions, and operations documentation.

Begriff Term | Kurzdefinition Short definition | Worauf achten What to watch
--- | --- | ---
Management Group Management group | Hierarchischer Container für Governance und Vererbung Hierarchical container for governance and inheritance | Policy- und RBAC-Vererbung bewusst strukturieren Structure policy and RBAC inheritance deliberately
Resource Group Resource group | Lebenszyklus- und Bereitstellungsgrenze für Ressourcen Lifecycle and deployment boundary for resources | Keine Umgebungen mischen Do not mix environments
Diagnostic Setting Diagnostic setting | Leitet Ressourcendiagnosen an Logs, Event Hubs oder Storage weiter Routes resource diagnostics to logs, Event Hubs, or Storage | Per IaC oder Policy standardisieren Standardize through IaC or policy
DCR DCR | Data Collection Rule für agentbasierte Datenerfassung Data collection rule for agent-based ingestion | Filtering und Ziel-Workspaces definieren Define filtering and destination workspaces
What-If What-if | Simuliert ARM-Änderungen vor Anwendung Simulates ARM changes before apply | Vor produktiven Deployments verpflichtend machen Make mandatory before production deployments
Deployment Stack Deployment stack | Steuert Lifecycle und Entfernen von IaC-Ressourcen Controls lifecycle and removal of IaC resources | Action on unmanage bewusst wählen Choose action on unmanage deliberately
Azure Arc Azure Arc | Bindet Hybrid- oder Fremdcloud-Ressourcen in Azure-Steuerung ein Brings hybrid or other-cloud resources into Azure control | Agent-Lifecycle und Netzpfade überwachen Watch agent lifecycle and network paths
Azure Lighthouse Azure Lighthouse | Delegiertes tenantübergreifendes Management Delegated cross-tenant management | Minimalrechte und klare Rollenmodelle verwenden Use least privilege and clear role models

- Governance beginnt mit Hierarchie- und Scope-Design. Governance starts with hierarchy and scope design.
- Logging-Baselines gehören in IaC oder Policy. Logging baselines belong in IaC or policy.
- FinOps und Observability sind verbunden, weil Telemetrie Kosten erzeugt. FinOps and observability are linked because telemetry creates cost.
- Resource Graph ergänzt Monitor-Logs, ersetzt sie aber nicht. Resource Graph complements Monitor logs but does not replace them.
- Hybridbetrieb wird erst mit Arc und sauberem Identity-Design nachhaltig. Hybrid operations become sustainable only with Arc and clean identity design.