Azure Compute Azure Compute

Technische Referenz für Azure Virtual Machines, Skalierungsoptionen, PaaS-Compute, Diagnose, Platzierung, Kostenmodelle und Betriebs-Governance. Technical reference for Azure Virtual Machines, scaling options, PaaS compute, diagnostics, placement, cost models, and operational governance.

Compute-Entscheidungsmodell Compute decision model

Azure Compute reicht von klassischen virtuellen Maschinen bis zu stark verwalteten App-Laufzeiten. Der wichtigste technische Unterschied ist die Frage, ob Sie Betriebssystem, Patchregime, Netzwerkgrenzen, Middleware und Skalierung selbst verantworten oder einen Plattformdienst dafür einsetzen. Azure compute spans from classic virtual machines to heavily managed application runtimes. The most important technical distinction is whether you own the operating system, patch regime, network boundaries, middleware, and scaling, or whether a platform service owns them for you.

Entscheidungen sollten anhand von Zustandsbehaftung, Startlatenz, horizontaler Skalierbarkeit, Protokollanforderungen, Betriebsfenstern, Compliance-Anforderungen und Integrationsbedarf getroffen werden. Compute ist in Azure niemals isoliert von Netzwerk, Identität, Speicherung und Monitoring zu betrachten. Decisions should be made based on statefulness, startup latency, horizontal scalability, protocol requirements, maintenance windows, compliance requirements, and integration needs. In Azure, compute is never an isolated topic separate from networking, identity, storage, and monitoring.

• Bewerten Sie zuerst, ob der Workload wirklich ein Betriebssystem benötigt oder nur eine Laufzeitumgebung. Evaluate first whether the workload truly needs an operating system or only a runtime environment.
• Ordnen Sie Compute dem Ausfallmodell zu: einzelne Instanz, skalierte Farm, Zonenarchitektur oder Multi-Region. Map compute to the failure model: single instance, scaled farm, zonal architecture, or multi-region.
• Rechnen Sie Datenlokalität mit ein: VM-nahe Disks, private Endpunkte und intra-regionale Latenz beeinflussen die Wahl. Account for data locality: VM-adjacent disks, private endpoints, and intra-regional latency influence the choice.
• PaaS-Dienste reduzieren Patchaufwand, verschieben aber Debugging und Konfigurationsgrenzen auf Plattformlogik. PaaS services reduce patching effort, but move debugging and configuration boundaries into platform behavior.
• Berücksichtigen Sie Quoten bereits im Landing-Zone-Design, insbesondere für Kerne, GPUs, Scale Sets und Batch-Pools. Consider quotas during landing zone design, especially for cores, GPUs, scale sets, and Batch pools.

Leitfragen für die Plattformwahl Guiding questions for platform choice

Fragen Sie systematisch nach Zustandsbehaftung, Betriebsfenster, Debugging-Tiefe, Host-Zugriff, Compliance-Anforderungen, Geheimnisverwaltung und dem Verhältnis von horizontaler zu vertikaler Skalierung. Diese Leitfragen sind oft aussagekräftiger als Produktnamen oder Teamsympathien. Systematically ask about statefulness, maintenance windows, debugging depth, host access, compliance requirements, secret handling, and the ratio of horizontal to vertical scaling. These questions are often more meaningful than product names or team preferences.

VM-Serien, Größen und Suffixe VM series, sizes, and suffixes

Azure-VM-Größen folgen einer Familienlogik. Die Serien definieren das Grundprofil, während Generationen und Suffixe zusätzliche Eigenschaften wie Premium-Storage-Unterstützung, lokale NVMe-Datenträger, AMD- oder Intel-Prozessoren, Memory-to-Core-Verhältnis oder GPU-Fähigkeiten beschreiben. Azure VM sizes follow a family model. The series define the base profile, while generations and suffixes describe additional characteristics such as premium storage support, local NVMe disks, AMD or Intel processors, memory-to-core ratio, or GPU capabilities.

Ein erfolgreiches Sizing betrachtet CPU-Steal, Arbeitssatz, Netzwerkdurchsatz, IOPS, Latenzziel, NUMA-Verhalten, Lizenzmodell und die Frage, ob Burst-Verhalten oder deterministische Leistung benötigt wird. Der kleinste Preis ist selten die günstigste Architektur. Successful sizing considers CPU steal, working set, network throughput, IOPS, latency objectives, NUMA behavior, licensing model, and whether burst behavior or deterministic performance is required. The lowest price is rarely the cheapest architecture.

Generationen und Suffixe lesen Reading generations and suffixes

• Messen Sie immer CPU, RAM, Datenträgerwartezeiten und Netzwerkdurchsatz gemeinsam, nicht isoliert. Always measure CPU, memory, disk wait times, and network throughput together, not in isolation.
• Bewerten Sie lokale temporäre Disks getrennt von persistenten Managed Disks. Evaluate local temporary disks separately from persistent managed disks.
• Beachten Sie Region, Zone und Verfügbarkeitsrestriktionen einzelner Größen vor dem Rollout. Check region, zone, and availability restrictions for individual sizes before rollout.
• Für GPUs gehören Treiberstrategie, Image-Pflege und Wartungsfenster zum Sizing dazu. For GPUs, the driver strategy, image maintenance, and maintenance windows are part of sizing.
• Führen Sie Rechte-Sizing nach realen Performance-Countern und nicht nach On-Premises-Nostalgie durch. Perform right-sizing using real performance counters rather than on-premises nostalgia.

Resilienz, Skalierung und Einkaufsmodelle Resilience, scaling, and procurement models

Compute-Resilienz in Azure entsteht aus mehreren Ebenen: Platzierung innerhalb einer Region, Fehlerdomänen, Zonenauswahl, horizontale Skalierung, Zustandsentkopplung, Quorum-Design und nicht zuletzt der Fähigkeit, nach Kapazitätsengpässen oder Wartungsereignissen schnell wieder hochzufahren. Compute resilience in Azure emerges from several layers: placement inside a region, fault domains, zone selection, horizontal scaling, state decoupling, quorum design, and the ability to recover quickly after capacity shortages or maintenance events.

Kostenmodelle sind kein Einkaufsthema am Ende des Projekts, sondern beeinflussen das technische Design. Spot-Instanzen, Reservations, Savings Plans und Dedicated Hosts verändern die Frage, wie elastisch, zustandslos oder hostgebunden ein Workload überhaupt gebaut werden darf. Cost models are not a procurement topic at the end of the project; they influence the technical design. Spot instances, reservations, savings plans, and dedicated hosts change how elastic, stateless, or host-bound a workload can safely be designed.

Preismodelle und wirtschaftliches Design Pricing models and economic design

• Zonenarchitektur verlangt zonenfähige Abhängigkeiten, inklusive Disks, Load Balancing und Datenpfaden. A zonal architecture requires zone-capable dependencies, including disks, load balancing, and data paths.
• Spot-Kapazität sollte immer mit Retry-Logik, Queue-Puffern oder Ersatzkapazität kombiniert werden. Spot capacity should always be combined with retry logic, queue buffering, or fallback capacity.
• PPGs helfen nur dort, wo Latenzgewinne den geringeren Platzierungsfreiraum rechtfertigen. PPGs help only where latency gains justify the reduced placement freedom.
• Scale Sets lösen kein Zustandsproblem. Persistenz muss aus dem Compute-Layer heraus entkoppelt werden. Scale sets do not solve state management. Persistence must be decoupled from the compute layer.
• Kostenoptimierung ist erfolgreich, wenn sie SLOs, Kapazität und Bereitstellbarkeit nicht untergräbt. Cost optimization succeeds when it does not undermine SLOs, capacity, or deployability.

Performance, Netzwerk und Storage-Pfade Performance, networking, and storage paths

Performanceprobleme bei Azure-Compute entstehen oft an Grenzflächen: zwischen VM und Managed Disk, zwischen NIC und Host, zwischen Zonen und Latency-Budget oder zwischen Golden Image und laufender Erweiterungskonfiguration. Rechenleistung allein erklärt die meisten Ausreißer nicht. Performance issues in Azure compute often arise at boundaries: between VM and managed disk, between NIC and host, between zones and latency budgets, or between the golden image and runtime extension configuration. Raw CPU alone does not explain most outliers.

Netzwerk- und Platzierungsmerkmale Networking and placement characteristics

• Planen Sie Disk- und NIC-Grenzen immer gegen die gewählte VM-Größe gegen. Always validate disk and NIC limits against the selected VM size.
• Messen Sie Zonenlatenz, wenn Daten und Compute nicht gemeinsam zonal platziert werden. Measure cross-zone latency when data and compute are not placed in the same zone.
• Nutzen Sie Ephemeral OS Disks nur dort, wo Neuaufbau schneller und sicherer als Restore ist. Use ephemeral OS disks only where rebuilding is faster and safer than restoring.
• Bewerten Sie Accelerated Networking als Default für produktive IaaS-VMs auf unterstützten Größen. Evaluate accelerated networking as a default for production IaaS VMs on supported sizes.
• Dokumentieren Sie lokale Temp-Disk-Nutzung explizit, damit keine Geschäftsdaten versehentlich volatil gespeichert werden. Document local temp disk usage explicitly so business data is not accidentally stored on volatile media.

Images, Agent, Extensions und Diagnostik Images, agent, extensions, and diagnostics

Die Betriebsqualität einer VM-Landschaft wird maßgeblich durch ihr Image- und Erweiterungsmodell bestimmt. Wer Images unsauber pflegt oder Extensions ungeordnet stapelt, erzeugt Inkonsistenzen, längere Recovery-Zeiten und kaum reproduzierbare Fehlerbilder. The operational quality of a VM estate is heavily shaped by its image and extension model. Teams that maintain images poorly or stack extensions without discipline create inconsistencies, longer recovery times, and barely reproducible failure modes.

Azure VM Agent, Run Command, Boot Diagnostics und Serial Console sind keine isolierten Komfortfunktionen. Sie bilden zusammen die letzte Rettungslinie, wenn Netzwerkpfade, Login-Mechanismen oder reguläre Managementkanäle gestört sind. The Azure VM Agent, Run Command, boot diagnostics, and the serial console are not isolated convenience features. Together they form the final recovery line when networking, login mechanisms, or normal management channels fail.

Extensions, Boot Diagnostics und Serial Console Extensions, boot diagnostics, and serial console

az vm create \
  --resource-group rg-core-prod \
  --name app01-weu-z1 \
  --image Ubuntu2204 \
  --size Standard_D4ds_v5 \
  --zone 1 \
  --vnet-name vnet-app-prod \
  --subnet snet-app \
  --public-ip-address "" \
  --nsg "" \
  --accelerated-networking true \
  --boot-diagnostics-storage https://stdiagprod.blob.core.windows.net/
        

Get-AzVM -ResourceGroupName rg-core-prod -Name app01-weu-z1 -Status |
Select-Object Name, Location,
    @{Name='PowerState';Expression={$_.Statuses[-1].DisplayStatus}},
    @{Name='Extensions';Expression={$_.ExtensionsText}}
        

• Pflegen Sie Images versioniert und mit Rollback-Strategie, idealerweise über Azure Compute Gallery. Maintain images with versioning and rollback strategy, ideally through Azure Compute Gallery.
• Begrenzen Sie Extensions auf klar definierte Zwecke; überladene VMs sind schwerer zu debuggen. Limit extensions to clearly defined purposes; overloaded VMs are harder to debug.
• Boot Diagnostics und Serial Console gehören in jede Break-Glass-Dokumentation für kritische IaaS-Systeme. Boot diagnostics and the serial console should be part of every break-glass document for critical IaaS systems.
• Beobachten Sie den Zustand des VM Agents aktiv, weil viele Betriebsfunktionen an ihm hängen. Monitor VM Agent health actively because many operational capabilities depend on it.
• Golden Images verkürzen Deployment-Zeiten, ersetzen aber kein sauberes Post-Provisioning und keine Geheimnisverwaltung. Golden images shorten deployment times, but do not replace clean post-provisioning and secret management.

App Service, Functions, Container Instances, Batch und Spring Apps App Service, Functions, Container Instances, Batch, and Spring Apps

Nicht jeder Compute-Bedarf rechtfertigt virtuelle Maschinen. Azure bietet mehrere verwaltete Laufzeitmodelle, die Skalierung, Patchen, Zertifikate, Health, Deployment-Slots oder eventgetriebene Ausführung bereits mitbringen und damit Betriebsrisiken aus dem Anwendungsteam herausnehmen. Not every compute need justifies virtual machines. Azure offers several managed runtime models that already include scaling, patching, certificates, health, deployment slots, or event-driven execution and thereby remove operational risk from the application team.

Hostingoptionen für Azure Functions Azure Functions hosting options

apiVersion: 2021-10-01
location: westeurope
name: aci-import-worker
properties:
  containers:
    - name: worker
      properties:
        image: mcr.microsoft.com/azuredocs/aci-helloworld
        resources:
          requests:
            cpu: 1
            memoryInGb: 2
  osType: Linux
  restartPolicy: OnFailure
        

• App Service ist oft die beste erste PaaS-Wahl für klassische Web-Anwendungen und APIs. App Service is often the best first PaaS choice for classic web applications and APIs.
• Functions lohnen sich besonders, wenn Workloads sauber idempotent und triggergetrieben entworfen werden. Functions shine when workloads are designed to be cleanly idempotent and trigger-driven.
• ACI ist ideal für Hilfsjobs, Imports, Tests oder isolierte Side-Workloads, aber kein Ersatz für eine vollständige Containerplattform. ACI is ideal for helper jobs, imports, tests, or isolated side workloads, but is not a replacement for a full container platform.
• Batch erfordert sauberes Daten- und Quotenmanagement; die Poolgröße allein löst keine Pipelineprobleme. Batch requires disciplined data and quota management; pool size alone does not solve pipeline issues.
• Spring Apps verkürzt den Plattformbetrieb für Spring-Teams, solange Netzwerk, Konfiguration und Secret-Strategie mitgedacht werden. Spring Apps shortens platform operations for Spring teams as long as networking, configuration, and secret strategy are considered.

Azure Virtual Desktop im Compute-Kontext Azure Virtual Desktop in the compute context

Azure Virtual Desktop ist keine isolierte VDI-Insel, sondern ein Azure-Compute-Produkt mit besonderem Fokus auf Benutzererlebnis, Session-Dichte, Profilmanagement, Bildpflege und Netzwerkpfade. Host Pools, Session Hosts und zugehörige Images sollten daher mit denselben Plattformstandards geplant werden wie andere Compute-Farmen. Azure Virtual Desktop is not an isolated VDI island; it is an Azure compute product with a special focus on user experience, session density, profile management, image maintenance, and network paths. Host pools, session hosts, and related images should therefore be planned with the same platform standards as other compute farms.

Zur zukünftigen Detailseite: Azure Virtual Desktop Go to the dedicated reference: Azure Virtual Desktop

• Planen Sie AVD-Host-Pools wie andere Scale-Farmen: Image, Patchen, Monitoring und Rollback eingeschlossen. Plan AVD host pools like other scale farms, including image management, patching, monitoring, and rollback.
• Session-Dichte darf nicht nur rechnerisch, sondern auch anhand echter Profil- und I/O-Last validiert werden. Session density should be validated not only mathematically but also against real profile and I/O load.
• FSLogix- und Storage-Design sind oft entscheidender als die reine CPU-Größe der Session Hosts. FSLogix and storage design are often more decisive than the raw CPU size of the session hosts.
• Zentralisierte Desktop-Workloads profitieren stark von sauberer regionaler Nähe zu Identität, Profilspeicher und Kernanwendungen. Centralized desktop workloads benefit greatly from regional proximity to identity, profile storage, and core applications.

Governance, Sicherheit und Betriebsbaseline Governance, security, and operational baseline

Compute-Governance in Azure verbindet Kostenkontrolle, Sicherheitsgrenzen, Standardisierung und Recovery-Fähigkeit. Eine gute Plattform nimmt Teams Freiheiten nur dort, wo Wildwuchs zu Mehrkosten, Inkonsistenz oder Sicherheitslücken führen würde. Compute governance in Azure combines cost control, security boundaries, standardization, and recovery capability. A good platform removes freedom only where unchecked variation would create extra cost, inconsistency, or security gaps.

az vm extension list \
  --resource-group rg-core-prod \
  --vm-name app01-weu-z1 \
  --query "[].{Name:name,Publisher:publisher,Type:typePropertiesType}" \
  --output table
        

• Standardisieren Sie wenige zugelassene VM-Familien statt beliebiger SKU-Vielfalt. Standardize on a small set of approved VM families instead of allowing arbitrary SKU sprawl.
• Definieren Sie, wann Rebuild bevorzugt wird und wann ein In-Place-Fix legitim ist. Define when rebuild is preferred and when an in-place fix is legitimate.
• Verankern Sie Compute-Telemetrie in FinOps- und Kapazitätsreviews, nicht nur im Incident-Response. Anchor compute telemetry in FinOps and capacity reviews, not only in incident response.
• Verknüpfen Sie Sicherheitsbaseline, Diagnostik und Tagging bereits in Infrastruktur-Code und Policy. Tie security baseline, diagnostics, and tagging together in infrastructure code and policy.
• Planen Sie zonale, regionale und kapazitätsbedingte Failure-Modes bewusst in Runbooks ein. Plan zonal, regional, and capacity-related failure modes explicitly into runbooks.

Begriffe und Merkhilfen Terms and quick reminders

Die folgende Übersicht fasst zentrale Compute-Begriffe zusammen, die in Architektur- und Betriebsdiskussionen häufig vorkommen. The following overview summarizes central compute terms that appear frequently in architecture and operations discussions.

• Compute-Entscheidungen gelingen am besten, wenn Plattformteam, Netzwerk, Security und Anwendung gemeinsam designen. Compute decisions work best when the platform team, networking, security, and application owners design together.
• Zuverlässigkeit entsteht aus Platzierung, Datenstrategie, Telemetrie und Runbooks, nicht nur aus CPU-Kernen. Reliability comes from placement, data strategy, telemetry, and runbooks, not only from CPU cores.
• Der günstigste Preis pro Stunde ist selten der entscheidende KPI; entscheidend sind SLO, Wiederanlauf und Betriebsaufwand. The cheapest hourly price is rarely the decisive KPI; SLOs, recovery, and operational effort matter more.