Microsoft Azure Services

Beschreibung

Azure Virtual Machines stellt skalierbare Windows- und Linux-Server bereit, wenn du Betriebssystem, installierte Software oder spezielle VM-Größen selbst steuern musst. Du wählst Region, VM-Familie, Datenträger, Netzwerk und Verfügbarkeitsmodell passend zur Workload. Der Dienst ist sinnvoll für Migrationen und Spezialsoftware, bringt aber weiterhin Verantwortung für Patches, OS-Härtung, Backup und Betrieb mit.

Wichtige Hinweise

• VM-Größen sind je Region und Zone unterschiedlich verfügbar; SKU, Kontingent und tatsächliche Kapazität vor Projektstart prüfen
• Managed Disks, Public IPs, Bandbreite/Egress, Backups und Lizenzen separat kalkulieren
• Für produktive Systeme Availability Zones, Availability Sets, VM Scale Sets oder Site Recovery bewusst planen
• Temporärer lokaler Speicher ist nicht dauerhaft und eignet sich nur für Cache oder temporäre Daten
• VM-Größenfamilie nach Workload wählen: General Purpose, Compute, Memory, Storage, GPU oder HPC

Typische Einsatzszenarien

• Lift-and-Shift bestehender Server und Fachanwendungen
• Windows- oder Linux-Workloads mit OS-Zugriff
• Datenbank-, SAP-, GPU- oder HPC-nahe Spezialworkloads
• Entwicklungs-, Test- und Schulungsumgebungen

Links

Beschreibung

AKS ist Microsofts verwalteter Kubernetes-Dienst für containerisierte Anwendungen und Plattformen. Azure übernimmt Control-Plane-Betrieb, Wartung und Integrationen, während du Workloads, Knotenpools, Netzwerk, Identität, Richtlinien und Release-Prozesse steuerst. AKS passt, wenn dein Team Kubernetes-Funktionen, Portabilität und klare Plattformstandards braucht, statt nur einen einfachen Container-Host.

Wichtige Hinweise

• Free eher für Tests ohne SLA; Standard für produktive Workloads mit SLA; Premium für Long-Term Support planen
• Kosten entstehen vor allem durch Knoten-VMs, Storage, Netzwerk, Cluster-Tier und ggf. AKS Automatic
• Kubernetes-Minor-Versionen können beim Upgrade nicht übersprungen werden
• Vor Upgrades Compute-Quota und verfügbare Zielversionen prüfen
• Azure Linux 2.0 Knotenimages nicht neu einplanen; Migration auf unterstützte Versionen oder AzureLinux3 vorbereiten

Typische Einsatzszenarien

• Microservices- und Plattform-Engineering-Umgebungen
• Modernisierung containerisierter Bestandsanwendungen
• CI/CD- und GitOps-basierte Deployments
• Windows- und Linux-Container in einem Kubernetes-Betriebsmodell

Links

Beschreibung

Azure Functions ist eine serverlose Lösung für kleine, ereignisgesteuerte Codeeinheiten, die über Trigger und Bindings mit HTTP, Timern, Storage, Queues, Event Hubs, Service Bus und weiteren Diensten verbunden werden. Du konzentrierst dich auf die Geschäftslogik; Azure übernimmt Hosting, Skalierung und Laufzeitumgebung. Der passende Hostingplan entscheidet über Kaltstart, Netzwerkzugriff, Timeout, Skalierung und Abrechnung.

Wichtige Hinweise

• Flex Consumption für neue serverlose Apps bevorzugen; klassischer Consumption-Plan ist veraltet beziehungsweise eingeschränkt
• Linux Consumption wird am 30. September 2028 eingestellt; Functions v3 auf Linux Consumption läuft nach dem 30. September 2026 nicht mehr
• HTTP-getriggerte Funktionen haben ein Antwortlimit von 230 Sekunden; lange Verarbeitung asynchron auslagern
• Planwahl beeinflusst Kaltstart, VNet, Timeout, Skalierung, Slots und Kostenmodell
• Storage Account, Monitoring, Ausführungen, GB-Sekunden und Always-ready Instanzen in der Kalkulation berücksichtigen

Typische Einsatzszenarien

• Webhooks und leichte APIs
• Zeitgesteuerte Automatisierung und Datenbereinigung
• Queue-, Event-Hub- und Service-Bus-Verarbeitung
• Serverlose Workflows mit Durable Functions

Links

Beschreibung

Azure Container Apps ist eine serverlose Plattform für containerisierte APIs, Worker, Jobs und Microservices. Du bringst Containerimages mit; Azure übernimmt viele Infrastruktur-, Ingress-, Revisions-, Skalierungs- und Betriebsdetails. Der Dienst basiert auf Kubernetes-nahen Konzepten und Open-Source-Technologien wie KEDA, Dapr und Envoy, ohne dass du die Kubernetes-API direkt betreibst.

Wichtige Hinweise

• Skalierung über HTTP, TCP oder KEDA; Scale-to-zero ist möglich, aber nicht bei CPU-/Memory-basierten Regeln
• Ohne Ingress brauchst du minReplicas ab 1 oder eine eigene Skalierungsregel, sonst kann die App auf null bleiben
• Kein direkter Kubernetes-API-Zugriff; für vollständige Clusterkontrolle AKS prüfen
• Revisionen, Traffic-Splitting, Secrets, Managed Identity, Registry, VNet und Logging früh planen
• Kosten entstehen je nach Plan durch aktive Ressourcen, Leerlaufreplikate, Anforderungen und ggf. Dedicated Workload Profiles

Typische Einsatzszenarien

• APIs und Web-Backends als Container
• Background Worker und ereignisgetriebene Verarbeitung
• Microservices mit Dapr und Service Discovery
• Scheduled, manuelle oder eventbasierte Container Apps Jobs

Links

Beschreibung

Azure Container Registry ist die verwaltete private Registry für Containerimages und OCI-Artefakte in Azure. Der Dienst passt, wenn Du Images nah an Azure-Workloads speichern, mit Microsoft Entra ID absichern und in Build- oder Deployment-Pipelines integrieren willst. Basic, Standard und Premium unterscheiden sich bei Speicher, Durchsatz, Replikation, Private Link und erweiterten Sicherheitsfunktionen. Für große Plattformen sind Retention, Image Signing, Scans, Geo-Replikation und Netzwerkzugriff zentrale Betriebsfragen.

Wichtige Hinweise

• Basic für kleine Szenarien, Standard für mehr Durchsatz und Speicher, Premium für Geo-Replikation, Private Link und höhere Limits
• Geo-Replikation reduziert Pull-Latenz, erzeugt aber Speicher- und Replikationskosten je Region
• ACR Tasks können Images bauen, patchen und automatisieren, verursachen je nach Nutzung zusätzliche Laufzeit
• Admin User möglichst deaktivieren und Zugriff über Entra ID, Managed Identity oder Service Principal steuern
• Image-Aufbewahrung, Quarantäne, Content Trust oder Signierung und Defender-Scans früh einplanen

Typische Einsatzszenarien

• Private Registry für AKS, Container Apps und App Service
• CI/CD-Pipelines mit Build, Push und Deployment
• Geo-nahe Image-Verteilung für mehrere Azure-Regionen
• Basisimages zentral versionieren und aktualisieren
• OCI-Artefakte und Helm-Charts für Plattformteams verwalten

Links

Beschreibung

Azure Virtual Desktop ist ein DaaS-Dienst für virtuelle Desktops und Remote-Apps auf Azure-VMs. Du steuerst Hostpools, Pooled oder Personal Desktops, Images, Profile, Netzwerk, Identität und App-Bereitstellung. Der Dienst passt, wenn Du flexible Windows-Arbeitsplätze, Remote-Apps oder saisonale Kapazität auf eigener Azure-Infrastruktur betreiben willst. Wenn Du stärker produktisierte Cloud-PCs mit Benutzerlizenz und weniger Infrastruktursteuerung suchst, ist Windows 365 oft passender.

Wichtige Hinweise

• Benutzer benötigen passende Windows-, Microsoft 365- oder Remote-Desktop-Lizenzen; Azure-Compute, Storage und Netzwerk kommen separat dazu
• Pooled spart Kosten durch Mehrbenutzersitzungen, Personal bietet dedizierte Desktops pro Benutzer
• FSLogix-Profile brauchen performanten SMB-Speicher, oft Azure Files oder Azure NetApp Files
• Autoscale, Reserved Instances, Start VM on Connect und Image-Management sind zentrale Kostenhebel
• Identität, Conditional Access, Netzwerk, Drucker, Teams-Optimierung und Datenresidenz früh testen

Typische Einsatzszenarien

• Remote-Arbeitsplätze für Mitarbeitende, Partner und Auftragnehmer
• Pooled Desktops für Callcenter, Schulungen oder Schichtbetrieb
• Remote-Apps für einzelne Fachanwendungen
• Sichere Arbeitsumgebungen für regulierte Daten
• Migration klassischer RDS- oder VDI-Umgebungen nach Azure

Links

Beschreibung

Azure Batch eignet sich für rechenintensive Jobs, Simulationen, Rendering, Datenverarbeitung und HPC-nahe Workloads, die in viele Tasks zerlegbar sind. Du definierst Pools, VM-Größen, Images, Starttasks, Jobs und Tasks, während Batch die Ausführung und Skalierung koordiniert. Der Dienst ist kein interaktiver Cluster und keine dauerhafte App-Plattform. Kosten und Laufzeit hängen stark von VM-SKU, Poolgröße, Autoscale, Storage, Datenbewegung und Fehlertoleranz der Anwendung ab.

Wichtige Hinweise

• Batch selbst hat keine separate Servicegebühr; berechnet werden VMs, Storage, Netzwerk und abhängige Ressourcen
• Spot- oder Low-Priority-Knoten sparen Kosten, können aber jederzeit verdrängt werden
• Pools, Quotas, VM-Familien und regionale Kapazität vor großen Läufen prüfen
• Jobdaten in Storage planen, weil Datenbewegung und Egress Laufzeit und Kosten prägen
• Tasks müssen Wiederholungen, Teilfehler und Checkpointing sauber unterstützen

Typische Einsatzszenarien

• Rendering, Medienverarbeitung und Bildkonvertierung
• Monte-Carlo-Simulationen, Risikoanalysen und technische Berechnungen
• Genomik, Forschung und HPC-nahe Stapelverarbeitung
• Parallele ETL- und Datenaufbereitungsjobs
• Skalierbare Test-, Build- oder Validierungsläufe

Links

Beschreibung

Azure Blob Storage ist Microsofts hochskalierbarer Objektspeicher für unstrukturierte Text- und Binärdaten. Der Dienst eignet sich für Browser-ausgelieferte Medien, verteilten Dateizugriff, Streaming, Logdaten, Backup, Archivierung und Analytics-Daten. Zugriff ist per HTTP/HTTPS, REST, SDKs, SFTP oder NFS 3.0 möglich; mit Data Lake Storage Gen2 kann Blob Storage auch als Big-Data-Dateisystem genutzt werden.

Wichtige Hinweise

• Zugriffsebenen Hot, Cool, Cold, Archive und Smart Tier passend zu Nutzung und Aufbewahrung wählen
• Cool, Cold und Archive haben niedrigere Speicherkosten, aber höhere Zugriffs-/Abrufkosten und Mindestaufbewahrungen
• Archive ist offline; Rehydration auf eine Online-Ebene kann bis zu 15 Stunden dauern
• Lifecycle Management verschiebt oder löscht Blobs regelbasiert nach Erstellungs-, Änderungs- oder Zugriffszeit
• Schutzoptionen wie Soft Delete, Versioning, Snapshots, Point-in-Time Restore, Immutability und Azure Backup einplanen

Typische Einsatzszenarien

• Medien- und Dokumentenbibliotheken für Websites oder Portale
• Backup, Disaster Recovery und langfristige Archivierung
• Data-Lake-Rohdaten für Analytics- und KI-Plattformen
• Log-, Telemetrie- und Exportdaten aus Anwendungen
• SFTP- oder NFS-basierter Datenaustausch über Storage Accounts

Links

Beschreibung

Azure Files bietet serverlose Dateifreigaben in Azure, die über SMB, NFS und die Azure Files REST API erreichbar sind. Der Dienst kann klassische File-Server oder NAS-Systeme ersetzen, Hybrid-Szenarien mit Azure File Sync unterstützen und Lift-and-Shift-Anwendungen einen vertrauten Dateipfad bereitstellen. Je nach Workload wählst du SMB oder NFS, SSD oder HDD, Redundanz, Identität, Netzwerkzugriff und Abrechnungsmodell.

Wichtige Hinweise

• SMB- und NFS-Protokolle verfügbar; eine einzelne Freigabe unterstützt nicht beide Protokolle gleichzeitig
• SMB unterstützt identitätsbasierte Authentifizierung über AD DS, Microsoft Entra Domain Services oder Microsoft Entra Kerberos
• Port 445 und NFS-Netzwerkzugriff früh prüfen; für On-Prem-Zugriff oft VPN, ExpressRoute oder Private Endpoint nötig
• SSD für niedrige Latenz und I/O-intensive Workloads, HDD für kostengünstige allgemeine Dateifreigaben
• Azure File Sync kann SMB-Freigaben zentralisieren und lokale Windows Server als Cache nutzen

Typische Einsatzszenarien

• Ersatz oder Ergänzung lokaler File-Server und NAS-Systeme
• Lift-and-Shift-Anwendungen mit gemeinsamem Dateispeicher
• FSLogix-Profile und Benutzerdateien in Azure Virtual Desktop
• Gemeinsame Konfigurations-, Diagnose- und Tool-Freigaben für Cloud-Apps
• Hybrid-Standorte mit lokalem Cache über Azure File Sync

Links

Beschreibung

Azure Managed Disks sind von Azure verwaltete Blockspeichervolumes für virtuelle Maschinen. Du wählst Datenträgertyp, Größe, Performance, Redundanz und Verschlüsselungsoptionen; Azure übernimmt Bereitstellung, Replikation und Integration in VM-Verfügbarkeit. Je nach Workload stehen Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD und Standard HDD für Daten-, OS- und Spezialworkloads zur Verfügung.

Wichtige Hinweise

• Fünf Datenträgertypen: Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD und Standard HDD
• Ultra Disk und Premium SSD v2 erlauben getrennte Anpassung von Kapazität, IOPS und Durchsatz, sind aber nicht als OS-Datenträger nutzbar
• Managed Disks nutzen standardmäßig serverseitige Verschlüsselung mit AES-256; kundenseitig verwaltete Schlüssel und Hostverschlüsselung sind möglich
• Snapshots, Images, Azure Backup, Wiederherstellungspunkte und Azure Site Recovery für Backup/DR planen
• Kosten hängen von Typ, bereitgestellter Größe, IOPS/Durchsatz, Snapshots, Transaktionen, Shared Disks und Egress ab

Typische Einsatzszenarien

• Datenbank-VMs mit SQL Server, Oracle, SAP HANA oder MongoDB
• Persistente Datenlaufwerke für geschäftskritische IaaS-Anwendungen
• Cluster-Szenarien mit Shared Disks und Failover-Software
• Dev/Test-, Web- und wenig genutzte Workloads mit Standard SSD oder HDD
• Hochleistungs-Blockstorage für transaktionsintensive Workloads

Links

Beschreibung

Azure NetApp Files ist ein Enterprise-Dateidienst für NFS- und SMB-Workloads mit niedriger Latenz und hoher Performance. Er passt für SAP, Datenbanken, VDI-Profile, HPC, Analytics und Anwendungen, die klassische NAS-Eigenschaften in Azure brauchen. Du arbeitest mit NetApp-Konten, Kapazitätspools, Volumes, Service Levels und Netzwerkdelegation. Für kleine einfache Dateifreigaben ist Azure Files meist günstiger und einfacher.

Wichtige Hinweise

• Service Levels Standard, Premium und Ultra bestimmen Durchsatz pro bereitgestelltem TiB
• Kapazitätspools werden mit Mindestgrößen geplant und abgerechnet, auch wenn Volumes nicht voll belegt sind
• Subnetzdelegation, regionale Verfügbarkeit und Quotas vor Projektstart prüfen
• Snapshots, Backup, Replikation und Protokollwahl NFS oder SMB gehören ins Design
• Nicht jede Funktion ist in jeder Region oder für jede Protokollkombination verfügbar

Typische Einsatzszenarien

• SAP HANA, Oracle und andere performancekritische Datenworkloads
• FSLogix-Profile und Home-Laufwerke für Azure Virtual Desktop
• NFS-Dateispeicher für Linux- und HPC-Anwendungen
• SMB-Freigaben mit Enterprise-Performance
• Migration bestehender NetApp- oder NAS-Workloads nach Azure

Links

Beschreibung

Azure Backup ist der verwaltete Sicherungsdienst für Azure- und Hybrid-Workloads. Er passt, wenn Du Backups zentral steuern, Aufbewahrung definieren, Wiederherstellungen testen und lokale Backup-Infrastruktur reduzieren willst. Je nach Workload nutzt Du Recovery Services Vaults, Backup Vaults, Backup Policies, Agenten oder Workload-Erweiterungen. Backup ersetzt kein vollständiges DR-Konzept, weil RTO, Netzwerk, Abhängigkeiten und Failover-Orchestrierung separat geplant werden müssen.

Wichtige Hinweise

• Abrechnung kombiniert geschützte Instanzen und genutzten Backup-Speicher je nach Workload
• Vault-Redundanz, Soft Delete, Immutable Vaults, Multi-User Authorization und Private Endpoints vor Produktivstart festlegen
• Aufbewahrung, tägliche Änderungsrate und langfristige Retention treiben Speicherverbrauch und Kosten
• Wiederherstellungen regelmäßig testen, inklusive Datei-, VM-, SQL- und Cross-Region-Szenarien
• Azure Backup ist Sicherung, Azure Site Recovery ist DR-Orchestrierung; beides nicht verwechseln

Typische Einsatzszenarien

• Sicherung von Azure VMs und einzelnen Dateien
• Backup von Azure Files, SQL Server und SAP HANA
• Langfristige Aufbewahrung für Compliance und Ransomware-Schutz
• Zentrale Backup-Policies für Landing Zones
• Hybrid-Backup für ausgewählte On-Premises-Workloads

Links

Beschreibung

Azure SQL-Datenbank ist eine vollständig verwaltete relationale PaaS-Datenbank auf Basis der SQL Server Engine. Microsoft übernimmt Patching, Backups, Hochverfügbarkeit, Monitoring-Grundlagen und Plattformwartung, während du Schema, Datenmodell, Sicherheit, Performance und Kosten steuerst. Für neue Workloads sind vCore-Modelle mit General Purpose, Business Critical und Hyperscale relevant; Single Databases, Elastic Pools und Serverless oder Provisioned Compute müssen passend zu Lastprofil und Mandantenmodell gewählt werden.

Wichtige Hinweise

• vCore-Modell empfohlen; DTU nur bei einfachen vorkonfigurierten Ressourcenkategorien prüfen
• Hyperscale ist für viele Business-Workloads die empfohlene Ebene und skaliert Speicher deutlich größer als klassische Ebenen
• Serverless eignet sich für variable Einzel-Datenbanken; Provisioned Compute für planbare Dauerlast
• Zonenredundanz, Failovergruppen, aktive Georeplikation und Point-in-Time Restore früh nach RTO/RPO planen
• Compute, Speicher, Backup-Aufbewahrung, Replikate, Egress und ggf. Lizenzvorteile separat kalkulieren

Typische Einsatzszenarien

• Cloudnative Web- und Geschäftsanwendungen mit relationalem Datenmodell
• SaaS-Anwendungen mit Single Databases oder Elastic Pools
• SQL Server Modernisierung ohne eigenen Serverbetrieb
• Transaktionssysteme mit hohen Verfügbarkeits- und Sicherheitsanforderungen
• Read-Scale-, Reporting- und Geo-DR-Szenarien mit Replikaten

Links

Beschreibung

Azure Cosmos DB unterstützt Betriebsdatenmodelle wie Dokument, Schlüsselwert, Graph, Tabelle und Vektor sowie APIs wie NoSQL, MongoDB, Cassandra, Gremlin und Table. Der Dienst ist auf niedrige Latenz, globale Verteilung, automatische Indizierung, Multi-Region-Lesen und -Schreiben sowie skalierbare Durchsatzmodelle ausgelegt. Kosten und Architektur hängen stark von Partitionierung, Request Units, Konsistenzmodell, Regionen, Speicher, Sicherung und gewähltem Compute- oder Durchsatzmodell ab.

Wichtige Hinweise

• RU/s sind zentrale Kapazitäts- und Kosteneinheit; Itemgröße, Indexierung, Abfragen und Konsistenz beeinflussen Verbrauch
• Provisioned Throughput, Autoscale und Serverless bewusst nach Lastprofil wählen
• Globale Verteilung repliziert Durchsatz und Speicher pro Region; Multi-Region-Write erhöht Verfügbarkeit und Kosten
• Partitionsschlüssel früh sauber modellieren, weil er Skalierung, Hot Partitions und Abfragekosten prägt
• Nicht ideal für stark relationale OLTP-Modelle oder klassische OLAP-Analysen; dafür eher Azure SQL oder Analytics-Plattform prüfen

Typische Einsatzszenarien

• Globale Web-, Commerce-, Gaming- und Personalisierungsanwendungen
• IoT-/Telemetrie-Daten mit hohem Schreibdurchsatz
• KI-/RAG-Anwendungen mit operativen Daten und Vektorsuche
• Event-getriebene Architekturen mit Change Feed
• Hochverfügbare Anwendungen mit Multi-Region-Lesen oder -Schreiben

Links

Beschreibung

Azure Database for PostgreSQL – Flexible Server ist Microsofts verwalteter PostgreSQL-Dienst auf Basis der Community-Version. Du behältst PostgreSQL-Kompatibilität, Konfigurationsparameter und Erweiterungen, während Azure Patching, automatische Backups, Verschlüsselung, Monitoring-Integration und Betriebsfunktionen bereitstellt. Für produktive Workloads sollten Compute-Tier, Speicher/IOPS, Wartungsfenster, private Netzwerkanbindung, HA-Modell und Backup-/DR-Strategie bewusst festgelegt werden.

Wichtige Hinweise

• Flexible Server ist der relevante Standard; Single-Server-Workloads auf Flexible Server migrieren
• Compute-Tiers Burstable, General Purpose und Memory Optimized passend zur Last wählen
• Burstable eher für Dev/Test oder unregelmäßige geringe Last; für 24/7-Produktion General Purpose oder Memory Optimized bevorzugen
• Zonenredundante HA benötigt General Purpose oder Memory Optimized und erzeugt Kosten für Standby-Ressourcen
• Automatische Backups standardmäßig 7 Tage, bis 35 Tage konfigurierbar; langfristige Sicherung und Geo-DR separat planen

Typische Einsatzszenarien

• PostgreSQL-Web-Backends und Fachanwendungen
• Modernisierung bestehender PostgreSQL-Workloads aus On-Premises, VM oder anderen Clouds
• Datenbank für Open-Source-Stacks, PHP-, Python-, Node.js- und .NET-Anwendungen
• Produktionsdatenbanken mit privaten Netzwerken, HA und automatischen Backups
• KI-nahe Anwendungen mit PostgreSQL-Erweiterungen, Vektor- oder Suchszenarien

Links

Beschreibung

Azure SQL Managed Instance ist der Sweetspot, wenn Du SQL-Server-Workloads nach PaaS migrieren willst, aber mehr Instanzfunktionen brauchst als Azure SQL Database bietet. Der Dienst unterstützt viele SQL-Server-Features, automatische Patches, Backups, Hochverfügbarkeit und VNet-Isolation. Er passt für Migrationen mit SQL Agent, Cross-Database-Abfragen, Service Broker oder instanznahen Anforderungen. Für einzelne cloudnative Datenbanken ohne Instanzabhängigkeiten ist Azure SQL Database oft schlanker.

Wichtige Hinweise

• Tiers General Purpose und Business Critical nach Latenz, IO, HA und Kosten wählen
• Managed Instance benötigt eigenes Subnetz und hat Netzwerk-, DNS- und Routinganforderungen
• Nicht alle SQL-Server-Funktionen sind vollständig identisch; Kompatibilität mit Data Migration Assistant prüfen
• Compute, Speicher, Backup-Retention, Lizenzmodell und Azure Hybrid Benefit beeinflussen Kosten stark
• Startzeit, Skalierung und Wartungsfenster sind nicht wie bei einer selbstverwalteten VM zu behandeln

Typische Einsatzszenarien

• Migration bestehender SQL-Server-Anwendungen mit Instanzfunktionen
• Modernisierung von SQL-VMs ohne kompletten App-Umbau
• Geschäftsanwendungen mit SQL Agent und mehreren Datenbanken
• Private PaaS-Datenbanken in VNet-nahen Architekturen
• SQL-Konsolidierung mit weniger Betrieb als auf VMs

Links

Beschreibung

Azure Database for MySQL Flexible Server ist der verwaltete MySQL-Dienst für Anwendungen, die MySQL-Kompatibilität ohne eigenen Datenbankserver brauchen. Azure übernimmt Plattformbetrieb, Patching, Backups, Verschlüsselung und Hochverfügbarkeitsoptionen. Der Dienst passt für Web-Backends, CMS, Fachanwendungen und Open-Source-Stacks. Für Spezialfeatures, Root-Zugriff oder stark angepasste Datenbankserver kann eine VM weiterhin nötig sein.

Wichtige Hinweise

• Tiers Burstable, General Purpose und Business Critical passend zu Lastprofil und SLA wählen
• Burstable eignet sich eher für Dev/Test und kleine variable Last, nicht für dauerhaft hohe Produktion
• Speicher, IOPS, Backup-Aufbewahrung und HA-Konfiguration treiben Kosten
• Private Access oder Public Access, Firewall und TLS vor App-Anbindung sauber planen
• Single Server ist der alte Pfad; neue und migrierte Workloads auf Flexible Server ausrichten

Typische Einsatzszenarien

• MySQL-Backends für PHP-, Java-, Node- und .NET-Anwendungen
• CMS- und Commerce-Systeme mit verwaltetem Datenbankbetrieb
• Migration bestehender MySQL-Server aus VMs oder On-Premises
• Produktionsdatenbanken mit automatischen Backups und HA
• Open-Source-Anwendungen in privaten Azure-Netzen

Links

Beschreibung

Redis in Azure ist sinnvoll, wenn Anwendungen sehr schnelle Lesezugriffe, Session State, Caching, Rate Limiting oder Pub/Sub-nahe Muster brauchen. Azure Cache for Redis ist der etablierte Dienst, Azure Managed Redis ist der neuere Nachfolgepfad für viele neue Szenarien. Der Dienst ist kein Ersatz für eine dauerhafte relationale Datenbank, auch wenn Persistenz und Replikation verfügbar sein können. Architektur und Kosten hängen stark von Tier, Speichergröße, Clustering, Netzwerk, Verfügbarkeit und Datenpersistenz ab.

Wichtige Hinweise

• Azure Managed Redis als Ziel für neue Planungen prüfen; bestehende Azure Cache for Redis Umgebungen nach Migrationspfad bewerten
• Tiers unterscheiden sich bei SLA, Clustering, Replikation, Persistenz, Enterprise-Funktionen und Netzwerkoptionen
• Cache-Größe, Eviction Policy, TTLs und Serialization bestimmen Stabilität und Kosten
• Persistenz und Replikation reduzieren Datenverlust, ersetzen aber kein Primärdatenmodell
• Private Link, Firewall, TLS und Entra-Integration je Dienst und Tier prüfen

Typische Einsatzszenarien

• Read-through- und Write-through-Caching für Web-Apps und APIs
• Session State und Warenkorb-Daten mit niedriger Latenz
• Rate Limiting, Locks und kurzlebige Koordinationsdaten
• Pub/Sub- und Event-nahe App-Muster
• Beschleunigung von Datenbank- und Suchzugriffen

Links

Beschreibung

Microsoft Foundry bündelt Modellkatalog, Azure OpenAI-/Foundry-Modelle, Agent Service, Foundry Tools, Evaluation, Tracing/Observability und Guardrails in Projekten unter einer Foundry-Ressource. Teams können Prompts, RAG, Agents und Modellbereitstellungen entwickeln, überwachen und governancenah betreiben. Die Plattform ist kein einzelner Pauschaldienst: Kosten, Verfügbarkeit und Datenverarbeitung hängen von den verwendeten Modellen, Deploymenttypen, Tools, Regionen und abhängigen Azure-Diensten ab.

Wichtige Hinweise

• Neues Ressourcenmodell mit Foundry-Ressource und Projekten; ältere Azure AI Foundry/Azure AI Studio-Bezeichnungen können noch in Doku und Portalen auftauchen
• Modell-, Agent- und Tool-Verfügbarkeit variiert je Region, Modell, Deploymenttyp und Kontingent; Zielregion vor Produktivstart prüfen
• Kosten entstehen über genutzte Modelle, Azure OpenAI, Foundry Tools, Agenten, Evaluation, Monitoring und abhängige Ressourcen; Preisrechner dienstweise verwenden
• Foundry-RBAC-Rollen wurden umbenannt; Rollen-IDs und Kernberechtigungen bleiben laut Microsoft erhalten
• Upgrade von Azure OpenAI auf Foundry ist opt-in und behält Endpunkt, Keys und Konfigurationen, hat aber Einschränkungen bei CMK, Private Link/DNS und Feature-/Regionverfügbarkeit

Typische Einsatzszenarien

• Enterprise-Copilots und KI-Agenten mit Governance
• RAG-Anwendungen mit Evaluierung und Observability
• Modellkatalog-, Prompt- und Deployment-Management
• KI-Plattform für mehrere Teams, Projekte und Kostenstellen
• Prototyping bis Produktionsbetrieb generativer KI-Lösungen

Links

Beschreibung

Azure OpenAI Service beziehungsweise Azure OpenAI in Microsoft Foundry Models bietet Zugriff auf von Azure gehostete OpenAI-Modelle für Text, Code, Reasoning, Embeddings, Bild, Audio und Realtime-Szenarien. Modelle werden als Deployments bereitgestellt; Bereitstellungstypen wie Global Standard, Data Zone, Regional, Provisioned und Batch bestimmen Datenverarbeitung, Latenz, Durchsatz und Kosten. Für produktive Lösungen sind Modellversionen, Content Filter, Quotas, Rate Limits, Datenzonen, Monitoring und Kostensteuerung zentrale Architekturentscheidungen.

Wichtige Hinweise

• Modellverfügbarkeit, Kontextlängen und Features variieren nach Region, Deploymenttyp und Modellversion; Vorschau-Modelle nicht ungeprüft produktiv nutzen
• TPM/RPM-Kontingente gelten pro Abonnement, Region, Modell und Deploymenttyp; 429-Fehler trotz scheinbar freiem Tokenbudget einplanen
• Deploymenttypen Global, Data Zone, Regional, Provisioned und Batch unterscheiden Datenverarbeitung, SLA, Latenz, Durchsatz und Preis
• Content Filtering, Prompt Shields, geschütztes Material, PII- und Abuse-Monitoring in App-Design und Fehlerbehandlung berücksichtigen
• Kosten entstehen token-, batch-, PTU-, Fine-Tuning-, Tool- oder Audio/Bild/Video-spezifisch; Modellmix und Caching/Batches aktiv optimieren

Typische Einsatzszenarien

• Chatbots und interne Wissensassistenten
• Text-, Code-, Bild-, Audio- und Realtime-Generierung
• RAG mit Azure AI Search und Unternehmensdaten
• Automatisierung mit Function Calling, Tools und Agents
• Embedding-Pipelines, Klassifikation, Extraktion und Zusammenfassung

Links

Beschreibung

Azure AI Search verbindet Unternehmensdaten mit klassischen Suchanwendungen, Chatbots und generativen KI-Lösungen. Der Dienst indexiert JSON-Dokumente aus Push- oder Pull-Pipelines, unterstützt Volltextsuche, Vektorsuche, Hybridsuche, semantische Rangfolge, KI-Anreicherung und agentischen Abruf für komplexe RAG-Szenarien. Für sichere Enterprise-Lösungen sind Indexdesign, Chunking, Vektorisierung, SKU/Suchunits, regionale Featureverfügbarkeit, Private Link, Entra ID/RBAC und Security Trimming entscheidend.

Wichtige Hinweise

• Volltext-, Vektor-, Hybrid-, multimodale und semantische Suche; Vektorsuche selbst ist kostenlos, Embeddings/KI-Anreicherung können extra kosten
• Semantischer Ranker rerankt nur die Top-50-Ergebnisse und erzeugt keine neuen Inhalte; Captions/Answers stammen wortgetreu aus dem Index
• Agentic Retrieval nutzt Wissensquellen, Knowledge Bases und optional LLM-gestützte Query-Planung; Abrechnung kann Search- und Modellkosten kombinieren
• Grenzwerte hängen stark von SKU, Region, Erstellungsdatum, Partitionen, Replikaten und Vektorquoten ab; ältere Dienste ggf. upgraden oder neu erstellen
• TLS, AES-256, Datenresidenz, Private Link, Entra ID/RBAC, CMK und Security Trimming für geschützte Inhalte einplanen

Typische Einsatzszenarien

• Enterprise Search für Portale, Apps und Intranets
• RAG-Grounding für Copilots, Agents und Chatbots
• Dokumenten-, SharePoint-, Blob-, Cosmos-DB- und OneLake-Suche
• Vektor- und Hybridsuche über Wissensdatenbanken
• Sicherheitsgetrimmter Zugriff auf vertrauliche Inhalte

Links

Beschreibung

Azure AI Services passt, wenn Du Funktionen wie Bilderkennung, Spracherkennung, Übersetzung, Textanalyse, Dokumentverarbeitung oder Content Safety nutzen willst, ohne eigene Modelle von Grund auf zu trainieren. Viele Dienste lassen sich einzeln oder über eine Multi-Service-Ressource bereitstellen. Der Dienst ist für produktive App-Integration geeignet, wenn Region, Datenverarbeitung, Authentifizierung, Quotas und Kosten pro Transaktion sauber geplant werden. Für eigene Modelltrainings, Pipelines und MLOps ist Azure Machine Learning passender.

Wichtige Hinweise

• Multi-Service-Ressource vereinfacht Keys und Abrechnung, aber nicht jeder Dienst und jede Region passt zu jedem Szenario
• Kosten entstehen meist transaktions-, seiten-, minuten-, zeichen- oder tokenbasiert je Dienst
• Free-Tiers sind für Tests hilfreich, aber nicht für produktive Last und SLA zu verplanen
• Datenresidenz, Logging, Content Safety und Responsible-AI-Anforderungen je Dienst prüfen
• Quota, Rate Limits und Modellversionen vor Rollout und Lasttest absichern

Typische Einsatzszenarien

• Dokumentenerkennung mit Azure AI Document Intelligence
• Speech-to-Text, Text-to-Speech und Übersetzung in Apps
• Bildanalyse, OCR und Moderation von Uploads
• Sprach- und Textanalyse für Support, Tickets und Suche
• Content Safety für generative KI und Benutzerinhalte

Links

Beschreibung

Azure Machine Learning ist die Plattform für klassischen Machine-Learning-Lifecycle und MLOps in Azure. Du verwaltest Workspaces, Compute, Datastores, Environments, Jobs, Pipelines, Modellregistrierung, Endpunkte und Monitoring. Der Dienst passt, wenn eigene Modelle trainiert, reproduzierbar betrieben und in CI/CD-Prozesse integriert werden sollen. Für reine GenAI-App-Entwicklung mit Modellkatalog und Agenten ist Microsoft Foundry oft der passendere Einstieg.

Wichtige Hinweise

• Kosten entstehen vor allem durch Compute, Storage, Managed Online Endpoints, Netzwerke und abhängige Dienste
• Compute Instances nicht dauerhaft laufen lassen; Auto-Shutdown und Quotas nutzen
• Training, Batch Inference und Online Inference haben unterschiedliche Betriebs- und Kostenmodelle
• Private Link, Managed VNet, Datenzugriff und Identitäten früh in die Plattformarchitektur aufnehmen
• MLOps braucht Versionierung von Daten, Code, Environments, Modellen und Pipelines, sonst wird Betrieb schwer prüfbar

Typische Einsatzszenarien

• Training klassischer ML-Modelle mit skalierbarem Compute
• MLOps-Pipelines für Build, Test, Registrierung und Deployment
• Batch Scoring und Online Endpoints für Vorhersagen
• Feature Engineering und Experimenttracking für Data-Science-Teams
• Governance von Modellen, Datenzugriff und Produktionsfreigaben

Links

Beschreibung

Microsoft Entra ID ist der zentrale Cloud-Identitätsdienst für Benutzer, Gruppen, Geräte, Anwendungen und Workloads. Der Dienst passt, wenn Du Anmeldung, MFA, Conditional Access, Rollen, App-Registrierungen und Identitätsbetrieb über Microsoft Cloud und eigene Apps zentralisieren willst. Er ersetzt kein klassisches Active Directory für Legacy-Protokolle wie LDAP oder Kerberos, dafür brauchst Du weiter AD DS oder Microsoft Entra Domain Services. Für DACH-Umgebungen sind Mandantenregion, Protokolldaten, Gastzugriff, Adminrollen und Lizenzabdeckung vor dem Rollout sauber zu klären.

Wichtige Hinweise

• SKUs Free, P1 und P2 bewusst planen; Conditional Access und viele Risiko- und Governance-Funktionen brauchen P1 oder P2
• Microsoft 365 enthält Entra ID, aber nicht jede Microsoft 365 Lizenz enthält alle Entra Premium-Funktionen
• Break-Glass-Konten, MFA-Methoden, Security Defaults oder Conditional Access vor produktiver Erzwingung testen
• Legacy Authentication, App-Registrierungen, Consent und privilegierte Rollen sind zentrale Angriffsflächen
• Für klassische Domänenfunktionen wie LDAP, Kerberos, GPO oder Domain Join ist Entra ID allein nicht der richtige Dienst

Typische Einsatzszenarien

• Zentraler Login für Microsoft 365, Azure und SaaS-Anwendungen
• MFA und Conditional Access für Admins, Geräte und risikobasierte Zugriffe
• App-Registrierungen, Enterprise Apps und Single Sign-On für interne Anwendungen
• Gast- und Partnerzugriff über B2B-Kollaboration
• Identitätsbetrieb mit Rollen, Protokollen und Zugriffsauswertungen

Links

Beschreibung

Microsoft Defender for Cloud ist Microsofts CNAPP-Plattform für Sicherheitsstatus, DevSecOps und Workload Protection. Der Dienst passt, wenn Du Azure-, Arc-, AWS- oder GCP-Ressourcen zentral bewerten, priorisieren und mit Defender-Plänen schützen willst. Der kostenlose Foundational-CSPM-Teil liefert Inventar, Empfehlungen und Secure Score, während Defender CSPM und die Workload-Pläne erweiterte Funktionen und Schutz pro Ressourcentyp abrechnen. Für produktive Umgebungen musst Du Pläne, Auto-Provisioning, Agenten, Log Analytics und Datenregionen bewusst konfigurieren.

Wichtige Hinweise

• Foundational CSPM ist kostenlos; Defender CSPM und Workload-Pläne werden zusätzlich berechnet
• Defender-Pläne gelten je nach Ressourcentyp, zum Beispiel Server, Storage, Container, Datenbanken, App Service, Key Vault oder APIs
• Aktivierung kann automatisch Ressourcen registrieren; Planumfang und Ausnahmen vorab prüfen
• Kostenfallen entstehen durch breite Planaktivierung, Malware Scanning, Log Analytics und Multicloud-Anbindung
• Portal- und Betriebsmodell verschiebt sich schrittweise Richtung Microsoft Defender Portal

Typische Einsatzszenarien

• Secure Score und Empfehlungen für Azure- und Arc-Ressourcen betreiben
• Defender for Servers, Storage, Container und Datenbanken gezielt aktivieren
• Angriffspfade, Schwachstellen und Fehlkonfigurationen priorisieren
• Security-Alerts an Sentinel, ITSM oder SOC-Prozesse anbinden
• DevSecOps-Erkenntnisse aus Repositories und Pipelines einbeziehen

Links

Beschreibung

Microsoft Sentinel ist ein cloudnatives SIEM/SOAR für Security Operations über Microsoft, Azure, Multicloud, SaaS und On-Premises. Der Dienst passt, wenn Du Logs, Alerts, Threat Intelligence, Hunting, Analytics Rules, Workbooks und Playbooks zentral betreiben willst. Sentinel ist kein Ersatz für sauberes Log-Design, weil Datenquellen, Tabellen, Retention, Normalisierung und Alertqualität direkt über Kosten und Nutzen entscheiden. Neue und bestehende Umgebungen sollten den Übergang zum Microsoft Defender Portal früh einplanen.

Wichtige Hinweise

• Abrechnung hängt vor allem von Datenaufnahme, Log Analytics, Retention, Archivierung und optionalen Commitment Tiers ab
• Data Connectors, Analytics Rules, Watchlists, Workbooks, Hunting und Playbooks müssen aktiv kuratiert werden
• Playbooks nutzen Azure Logic Apps und können eigene Kosten verursachen
• Nach dem 31. März 2027 wird Microsoft Sentinel im Azure-Portal nicht mehr unterstützt
• Datenresidenz, Workspace-Region, Aufbewahrung und Export sind für DACH/DSGVO vorab festzulegen

Typische Einsatzszenarien

• Zentrales SIEM für Microsoft 365, Entra ID, Azure, Firewall, Endpoint und Drittanbieter
• Incident-Triage mit Analytics Rules, MITRE-Zuordnung und Entity Investigation
• Threat Hunting mit KQL, Watchlists und Threat Intelligence
• Automatisierte Reaktion über Playbooks und ITSM-Anbindung
• MSSP- und Mehrmandantenbetrieb über Azure Lighthouse

Links

Beschreibung

Azure DevOps ist eine integrierte Entwicklungsplattform für Enterprise-Teams, die Arbeit planen, Quellcode verwalten, Builds automatisieren, Releases steuern, Tests nachverfolgen und Pakete verteilen müssen. Azure Boards, Repos, Pipelines, Test Plans und Artifacts greifen ineinander, bleiben aber einzeln nutzbar. Für regulierte Umgebungen sind Organisationsgeographie, Microsoft Entra ID, Berechtigungen, Branch Policies, Pipeline-Sicherheit und Paralleljobs die zentralen Planungsgrößen.

Wichtige Hinweise

• Azure DevOps Services speichert Kundendaten grundsätzlich in der gewählten Geographie; Token-Daten liegen laut Microsoft in den USA, macOS-Agenten können Daten in ein GitHub-Rechenzentrum in den USA übertragen
• Öffentliche Projekte werden eingestellt: neue öffentliche Projekte sind nicht mehr möglich, bestehende werden 2027 in private Projekte konvertiert
• Pipeline-Kapazität hängt von Paralleljobs ab; kostenlose Kontingente können bei neuen Organisationen nicht automatisch aktiv sein und müssen ggf. beantragt werden
• Basic enthält die ersten 5 Benutzer kostenlos; Test Plans, zusätzliche Paralleljobs, Artifacts-Speicher über 2 GiB und GitHub Advanced Security werden separat bewertet
• Für Automatisierung Microsoft Entra OAuth, Dienstprinzipale oder verwaltete Identitäten bevorzugen; PATs nur kontrolliert und mit Richtlinien nutzen

Typische Einsatzszenarien

• CI/CD für Azure, Multicloud und On-Premises mit Genehmigungen
• Agile Planung, Backlogs, Boards und Release-Transparenz
• Private Git-Repositories mit Pull Requests und Branch Policies
• Paketfeeds für NuGet, npm, Maven, Python und interne Komponenten
• Manuelle und explorative Tests mit Rückverfolgbarkeit zu Anforderungen

Links

Beschreibung

Microsoft Dev Box gibt Entwicklern über ein Portal Zugriff auf vorkonfigurierte Windows-Cloud-Workstations, die aus Dev Box-Pools mit definiertem Image, Compute, Speicher und Netzwerk entstehen. Plattformteams steuern Dev Center, Projekte, Pools, Kataloge, Image-Definitionen, Netzwerke und Rollen; die Dev Boxes werden über Microsoft Intune verwaltet und über Azure Virtual Desktop-Konnektivität erreicht. Der Dienst ist weiterhin unterstützt, befindet sich laut Microsoft aber im Wartungsmodus ohne geplante neue Features, daher sollte Windows 365 für neue strategische Entwickler-Cloudumgebungen geprüft werden.

Wichtige Hinweise

• Stand/Hinweis: Microsoft Dev Box ist im Wartungsmodus; für neue virtualisierte Entwicklerumgebungen nennt Microsoft Windows 365 als empfohlenen Pfad
• Benutzer benötigen passende Windows Enterprise-, Microsoft Intune- und Microsoft Entra ID P1-Lizenzen; viele Microsoft 365-Pläne enthalten diese Voraussetzungen
• Geschäfts- und Schulkonten werden unterstützt; Gastzugriff über Microsoft Entra B2B wurde eingestellt
• Die Netzwerkverbindung bestimmt die Hosting-Region: Microsoft-gehostet für reine Cloud-Szenarien, Azure-Netzwerkverbindung für eigenes VNet, Hybrid Join oder Zugriff auf Unternehmensressourcen
• Abrechnung kombiniert Lizenzvoraussetzungen, Speicher pro Dev Box und aktive Compute-Stunden bis zum monatlichen Maximalpreis; Autostopp und Ruhezustand konsequent nutzen

Typische Einsatzszenarien

• Standardisierte Entwicklerumgebungen für neue Mitarbeitende und Projektteams
• Isolierte Workstations für Auftragnehmer, sensible Repositories oder Kundensysteme
• Regionale Cloud-Workstations für verteilte Entwicklerteams mit niedrigerer Latenz
• Mehrere getrennte Arbeitsumgebungen pro Entwickler für parallele Projekte
• Reproduzierbare Toolchains über Image-Definitionen, Kataloge und Intune-Richtlinien

Links

Beschreibung

Azure App Service ist sinnvoll, wenn Du Web-Apps und APIs schnell betreiben willst, ohne VMs, IIS, Nginx oder Betriebssystempatching selbst zu verwalten. Der Dienst unterstützt .NET, Java, Node.js, Python, PHP sowie eigene Container auf Windows oder Linux. Er passt für klassische Web-Backends, interne Portale, APIs und viele Modernisierungen, aber nicht für Workloads mit voller OS-Kontrolle oder speziellen Kernelabhängigkeiten. Für Enterprise-Betrieb sind App Service Plan, Slots, Skalierung, VNet Integration, Zertifikate, Managed Identity und Observability entscheidend.

Wichtige Hinweise

• Free und Shared sind nicht für Produktion gedacht; Basic, Standard, Premium v3/v4 und Isolated nach SLA, Netzwerk und Last wählen
• Deployment Slots sind erst ab Standard relevant und können zusätzliche App-Instanzen im Plan belegen
• VNet Integration steuert ausgehenden Zugriff; Private Endpoint und Access Restrictions für eingehenden Zugriff getrennt planen
• Kosten entstehen auf Planebene, auch wenn einzelne Apps gestoppt sind
• App Service Environment v1 und v2 sind eingestellt; alte isolierte Umgebungen auf aktuelle Modelle migrieren

Typische Einsatzszenarien

• Web-Apps und REST APIs für Fachanwendungen
• Lift-and-Shift von IIS-, PHP-, Java- oder Node-Websites
• Backend für Portale, mobile Apps und Integrationen
• Staging und Blue-Green-Deployments mit Slots
• Containerisierte Webanwendungen ohne AKS-Betrieb

Links

Beschreibung

Azure Static Web Apps passt für Frontends mit Angular, React, Vue, Svelte, Blazor, Hugo oder ähnlichen Frameworks, wenn die App als statische Dateien ausgeliefert wird. Die Plattform baut und veröffentlicht aus dem Repository, erzeugt Vorschauumgebungen für Pull Requests und verteilt statische Inhalte global. Für dynamische Serverlogik nutzt Du integrierte Functions oder angebundene Backends. Nicht passend ist der Dienst für klassische serverseitige Webanwendungen, lange Backendprozesse oder volle Kontrolle über Webserver und Laufzeit.

Wichtige Hinweise

• Free eignet sich für kleine Projekte und Tests; Standard für Produktion, SLA, eigene Authentifizierung und höhere Kontingente
• Integrierte verwaltete Functions sind begrenzt; bei regionalen oder größeren API-Anforderungen eigene Functions oder Backends anbinden
• Build, Routing, Auth und Rollen werden über Repository und Konfigurationsdatei gesteuert
• Bandbreite, Speicher, benutzerdefinierte Domänen und Front-Door-Optionen beeinflussen Kosten und Architektur
• Serverseitiges Rendering und Framework-Sonderfälle vorab gegen aktuelle Static-Web-Apps-Unterstützung prüfen

Typische Einsatzszenarien

• Statische Websites, Landingpages und Dokumentationsportale
• Single Page Applications mit API-Backend
• Pull-Request-Vorschauumgebungen für Frontend-Teams
• Blazor WebAssembly und moderne JavaScript-Frameworks
• Kleine Portale mit Authentifizierung und Rollenmodell

Links

Beschreibung

Azure Front Door ist der globale Einstiegspunkt für internetbasierte Web- und API-Workloads. Der Dienst kombiniert Layer-7-Routing, CDN-Funktionen, TLS, WAF, Health Probes, Regeln und globales Load Balancing über Azure- oder externe Ursprünge. Er passt, wenn Nutzer weltweit niedrige Latenz und ein einheitliches Security-Frontend brauchen. Für rein regionale interne Lastverteilung sind Application Gateway oder Load Balancer meist passender.

Wichtige Hinweise

• Tarife Standard und Premium unterscheiden sich bei Private Link, WAF-Funktionen, Bot-Schutz und Sicherheitsanalysen
• Abrechnung erfolgt über Grundgebühr, Anforderungen sowie ausgehende Daten vom Edge zum Client und zum Ursprung
• WAF und Private Link sind bei Premium enthalten, CAPTCHA und weitere Add-ons separat prüfen
• Origins, Health Probes, Caching-Regeln und TLS-Zertifikate sauber modellieren, sonst entstehen Routingfehler
• Klassische CDN- und Front-Door-Modelle nicht mehr als Zielarchitektur für neue Projekte einplanen

Typische Einsatzszenarien

• Globaler Einstieg für Webanwendungen und APIs
• CDN und Beschleunigung statischer und dynamischer Inhalte
• WAF-Schutz und Bot-Schutz am Edge
• Aktiv-aktiv-Routing über mehrere Regionen oder Ursprünge
• Private Origin-Anbindung über Private Link im Premium-Tarif

Links

Beschreibung

Azure Application Gateway ist ein regionaler Layer-7-Load-Balancer für Webanwendungen und APIs in Azure. Er unterstützt TLS-Terminierung, URL-basiertes Routing, Hostnamen, Redirects, Session Affinity, Autoscaling und optional WAF. Der Dienst passt für regionale Hub-Spoke-, Private-App- und Ingress-Szenarien, bei denen Du mehr HTTP-Logik brauchst als ein Layer-4-Load-Balancer bietet. Für globale Edge-Beschleunigung und CDN ist Azure Front Door die bessere Einstiegsschicht.

Wichtige Hinweise

• Für neue Bereitstellungen v2-SKUs nutzen; v1 bietet kein Autoscaling und weniger aktuelle Funktionen
• WAF_v2 getrennt planen, weil Regeln, Ausschlüsse, Prevention-Modus und False Positives Betrieb brauchen
• Abrechnung umfasst Gateway-Stunden, Kapazitätseinheiten und ausgehende Daten
• Subnetz, Private IP, Public IP, Zertifikate, Backend Health und DNS früh festlegen
• Application Gateway for Containers ist ein eigenes modernes Modell für Kubernetes-nahe Szenarien

Typische Einsatzszenarien

• Regionaler HTTPS-Einstieg für interne und externe Web-Apps
• WAF-Schutz für App Service, VMs, AKS oder private Backends
• Pfad- und hostbasiertes Routing für mehrere Anwendungen
• TLS-Offload und zentrale Zertifikatsverwaltung
• Hub-Spoke-Application-Delivery in Landing Zones

Links

Beschreibung

Azure Load Balancer ist die richtige Wahl, wenn Du robuste Layer-4-Verteilung ohne HTTP-Features brauchst. Der Dienst arbeitet mit Frontend-IP, Backend-Pool, Health Probes und Load-Balancing-Regeln für öffentliche oder interne Szenarien. Er passt für VM-basierte Plattformen, NVAs, Datenbank-Cluster und einfache hochverfügbare Dienste. Für Webrouting, TLS-Logik oder WAF brauchst Du Application Gateway oder Front Door.

Wichtige Hinweise

• Basic Load Balancer wird abgekündigt; Standard Load Balancer für neue und bestehende Zielarchitekturen verwenden
• Standard unterstützt Zonenredundanz und ist sicherer, benötigt aber explizite NSG-Regeln für eingehenden Traffic
• Abrechnung bei Standard umfasst Regeln und verarbeitete Daten, Basic war kostenlos
• Health Probes und Floating IP bei HA-Clustern sorgfältig konfigurieren
• Kein Layer-7-Routing, keine TLS-Terminierung und keine WAF-Funktion

Typische Einsatzszenarien

• Hochverfügbarkeit für VM- und VM-Scale-Set-Backends
• Interne Lastverteilung zwischen Anwendungsschichten
• TCP-/UDP-Dienste ohne HTTP-Routing
• NVA- und Firewall-HA-Designs
• Cluster-Szenarien mit Floating IP und Health Probes

Links

Beschreibung

Azure DNS stellt DNS-Zonen auf Microsofts globaler Infrastruktur bereit. Du kannst öffentliche Zonen für Internetdomänen und private Zonen für Namensauflösung innerhalb virtueller Netzwerke betreiben. Der Dienst passt, wenn DNS-Zonen, Private Endpoints und Hub-Spoke-Namensauflösung zentral und IaC-fähig verwaltet werden sollen. Für komplexe hybride DNS-Szenarien brauchst Du zusätzlich DNS Private Resolver, Forwarding-Regeln und saubere On-Premises-Integration.

Wichtige Hinweise

• Öffentliche und private DNS-Zonen werden getrennt geplant und abgerechnet
• Azure DNS ist kein Domain-Registrar für alle TLDs; Registrierung und Delegation separat prüfen
• Private DNS Zones sind zentral für Private Endpoints und VNet-Namensauflösung
• DNS Private Resolver ersetzt eigene DNS-Forwarder-VMs in vielen Hybrid-Szenarien, kostet aber separat
• TTL, Split-Horizon, Delegation und Namenskonventionen vor Migration festlegen

Typische Einsatzszenarien

• DNS-Hosting für öffentliche Azure- und Unternehmensdomänen
• Private Namensauflösung für Hub-Spoke-Netzwerke
• Private Endpoint DNS für PaaS-Dienste
• Hybrid-DNS mit Forwarding zwischen Azure und On-Premises
• IaC-gesteuerte DNS-Zonen und Records

Links

Beschreibung

Azure Bastion reduziert den Bedarf an öffentlichen VM-IP-Adressen und offenen RDP- oder SSH-Ports. Der Dienst wird in einem eigenen Subnetz bereitgestellt und vermittelt Zugriff über das Azure-Portal oder native Clients. Er passt für Adminzugriffe auf Azure-VMs, Jump-Host-Ablösung und kontrollierte Betriebszugriffe. Für dauerhafte App-Verbindungen, VPN-Ersatz oder umfangreiche PAM-Prozesse ist Bastion allein nicht genug.

Wichtige Hinweise

• SKUs Developer, Basic, Standard und Premium unterscheiden sich bei VNet-Support, Skalierung, nativen Clients, Session Recording und Private-only-Funktionen
• AzureBastionSubnet muss korrekt dimensioniert und exklusiv für Bastion reserviert werden
• Kosten entstehen pro Bastion-Instanz und zusätzlich für ausgehende Datenübertragung
• Keine öffentlichen IPs auf Ziel-VMs nötig, aber RBAC, NSGs und Just-in-Time-Zugriffe weiter planen
• Developer-SKU ist für einfache Dev/Test-Szenarien gedacht und nicht für zentrale Produktion

Typische Einsatzszenarien

• Adminzugriff auf Windows- und Linux-VMs ohne Public IP
• Ablösung klassischer Jump-Hosts in Azure-Netzen
• Temporärer Zugriff für Betrieb, Migration und Troubleshooting
• Kontrollierter Zugriff in Hub-Spoke- oder Landing-Zone-Umgebungen
• Premium-Szenarien mit Session Recording und stärkerer Zugriffskontrolle

Links

Beschreibung

Azure DDoS Protection schützt internetexponierte Azure-Ressourcen gegen Netzwerkangriffe auf Layer 3 und Layer 4. Der Dienst passt, wenn öffentliche IPs, Web-Einstiege, Application Gateways, Firewalls oder Load Balancer geschäftskritisch sind und Angriffe messbar abgefedert werden müssen. Network Protection schützt aktivierte VNets, IP Protection schützt einzelne öffentliche IPs. Für Layer-7-Angriffe brauchst Du zusätzlich WAF über Front Door oder Application Gateway.

Wichtige Hinweise

• Network Protection wird pro geschütztem VNet geplant; IP Protection pro öffentlicher IP
• DDoS Protection ersetzt keine WAF, keine Bot-Abwehr und keine App-Härtung
• Kostenmodell zwischen VNet-basiertem Schutz und IP-basiertem Schutz bewusst wählen
• Telemetrie, Metriken, Alerts und Angriffsauswertungen in Azure Monitor einbinden
• DDoS Rapid Response und Kostenabsicherung sind an passende Pläne und Bedingungen gebunden

Typische Einsatzszenarien

• Schutz öffentlicher Web- und API-Einstiege
• Absicherung von Application Gateway, Load Balancer, Firewall und Public IPs
• DDoS-Telemetrie und Alerting für SOC und Betrieb
• Schutz kritischer Landing-Zone-Hubs und DMZ-Netze
• Kombination mit WAF für Layer-7-Webschutz

Links

Beschreibung

Azure Virtual Network ist die private Netzwerkbasis in Azure. Du definierst IP-Adressräume, Subnetze, Routing, Netzwerksicherheitsgruppen und Verbindungen zu anderen VNets, Azure-Diensten oder lokalen Netzwerken. Der Dienst selbst ist kostenlos, aber Peering, ausgehender Datenverkehr, Flow Logs, Private Link, Gateways und verbundene Dienste können kostenrelevant werden.

Wichtige Hinweise

• VNet selbst ist kostenlos; Peering wird für eingehenden und ausgehenden Datenverkehr berechnet
• Subnetze früh planen: kleinster Bereich /29, Azure reserviert mehrere Adressen pro Subnetz
• Peering nutzt das Microsoft-Backbone, ersetzt aber keine saubere IP-Adressplanung und keine Firewall-Strategie
• NSG-Regeln sind zustandsbehaftet; Standardregeln bleiben vorhanden und werden über Prioritäten überschrieben
• NSG Flow Logs werden abgelöst; für neue Projekte VNet Flow Logs mit Network Watcher planen

Typische Einsatzszenarien

• Landing Zones und Hub-Spoke-Netzwerke
• App-, Datenbank- und Plattformsegmentierung über Subnetze und NSGs
• Hybridkonnektivität über VPN Gateway oder ExpressRoute
• Private Endpoints und Dienstendpunkte für PaaS-Zugriff
• Netzwerkflussanalyse mit VNet Flow Logs und SIEM-Anbindung

Links

Beschreibung

Azure Firewall schützt virtuelle Netzwerke mit zentralen Regeln, Threat Intelligence, Protokollierung und integrierter Hochverfügbarkeit. Basic, Standard und Premium unterscheiden sich deutlich bei Durchsatz, DNS Proxy, FQDN-/Webkategorie-Filterung, TLS Inspection, IDPS und URL Filtering. Für produktive Architekturen musst du SKU, Routing, AzureFirewallSubnet, SNAT-Kapazität, Logging und Kosten vorab sauber dimensionieren.

Wichtige Hinweise

• SKUs bewusst wählen: Basic für kleine Szenarien, Standard für L3-L7-Filterung, Premium für TLS Inspection, IDPS und URL Filtering
• AzureFirewallSubnet mindestens /26 planen; Netzwerksicherheitsgruppen auf diesem Subnetz werden nicht unterstützt
• Hub-Spoke pro Region bevorzugen; globales Peering über Regionen kann Latenz, Performance und Kosten verschlechtern
• DNAT mit erzwungenem Tunneling und IPv6 sind laut aktuellen Hinweisen nicht unterstützt
• Preise bestehen aus Bereitstellungsstunden, verarbeitetem Datenvolumen und optionalen Kapazitätseinheiten

Typische Einsatzszenarien

• Zentraler Internet-Egress für Azure-Workloads
• Hub-Spoke-Segmentierung zwischen VNets und Subnetzen
• Regulierte Umgebungen mit zentralen Firewall Policies und Logs
• Threat-Intelligence-basierte Warnung oder Blockierung
• Premium-Szenarien mit TLS Inspection, IDPS und URL Filtering

Links

Beschreibung

Azure Key Vault speichert und verwaltet Secrets, kryptografische Schlüssel und Zertifikate für Anwendungen und Plattformdienste. Für normale Vaults kannst du software- oder HSM-geschützte Schlüssel, Secrets und Zertifikate verwenden; Azure Key Vault Managed HSM ist ein Single-Tenant-HSM-Dienst für HSM-geschützte Schlüssel. Plane Identitäten, Azure RBAC, Netzwerksicherheit, Soft Delete, Purge Protection, Rotation, Monitoring und Throttling, bevor Anwendungen produktiv abhängig werden.

Wichtige Hinweise

• Managed Identities und Azure RBAC bevorzugen; Access Policies sind Legacy und können Contributor-Risiken erzeugen
• Ein Vault pro Anwendung, Region und Umgebung planen; Objektbereich-Rollen nur in Sonderfällen nutzen
• Soft Delete ist für neue Vaults standardmäßig aktiv; Purge Protection für produktive Verschlüsselungsszenarien aktivieren
• Firewall, Private Endpoint oder deaktivierter öffentlicher Zugriff schützen die Datenebene; Azure DevOps ist kein pauschal vertrauenswürdiger Dienst
• Transaktionslimits, Versionen, Backupgrenzen und Rotation beachten; Key Vault nicht als allgemeinen Konfigurations- oder Kundendatenspeicher verwenden

Typische Einsatzszenarien

• App-Secrets ohne Geheimnisse im Code oder in CI/CD-Variablen
• TLS-Zertifikatslebenszyklus und automatische Erneuerung
• Customer-managed keys, BYOK und Verschlüsselung ruhender Daten
• Geheimnis- und Schlüsselrotation mit kontrolliertem Rollout
• HSM-/Compliance-Szenarien mit Azure Key Vault Managed HSM

Links

Beschreibung

Azure API Management ist eine hybride Multi-Cloud-Plattform für interne und externe APIs. Du stellst APIs über Gateways bereit, steuerst Authentifizierung, Quotas, Rate Limits, Transformationen und Caching per Policies und gibst Entwicklerteams ein Portal für Dokumentation und Abonnements. Der Dienst passt, wenn APIs nicht nur erreichbar, sondern kontrolliert, messbar und produktfähig betrieben werden müssen.

Wichtige Hinweise

• Developer-Tarif ist nicht für Produktion gedacht und hat keine SLA
• Consumption ist serverlos und nutzungsbasiert, unterstützt aber nicht alle Funktionen der dedizierten Tarife
• VNet, Private Endpoints, Multi-Region, Availability Zones, Self-hosted Gateway und Workspaces hängen vom Tarif ab
• Policies können Authentifizierung, Ratenbegrenzung, Transformation, Caching, Logging und Backend-Routing direkt im Gateway erzwingen
• API-, Operationen-, Produkt-, Abonnement- und Portalgrenzen je Tarif vor Migration prüfen

Typische Einsatzszenarien

• Partner- und Kunden-APIs sicher veröffentlichen
• Microservice-Gateways mit zentralen Policies betreiben
• Legacy-Backends über moderne REST- oder SOAP-APIs kapseln
• API-Produkte mit Abonnements, Quotas und Developer Portal anbieten

Links

Beschreibung

Azure Logic Apps ist eine Cloudplattform für Workflows, mit der du SaaS-, Azure-, On-Premises- und B2B-Systeme ohne eigenen Orchestrator verbindest. Ein Workflow startet mit einem Trigger und führt Aktionen aus, zum Beispiel Genehmigungen, Dateiverarbeitung, EDI/XML, API-Aufrufe oder Nachrichtenübergaben. Consumption und Standard unterscheiden sich deutlich bei Hosting, Netzwerk, Datenhaltung, Skalierung und Kostenmodell.

Wichtige Hinweise

• Consumption rechnet pro Ausführung ab und enthält pro Ressource einen Workflow; Standard nutzt einen Workflow Service Plan und kann mehrere stateful oder stateless Workflows enthalten
• Standard bietet mehr Kontrolle für VNet, Private Endpoints und regionale Datenhaltung; verwaltete Connectoren werden separat als Azure-Dienst betrieben
• Grenzen wie 500 Aktionen pro Workflow, 90 Tage Run History bei stateful Workflows und kurze stateless Laufzeiten einplanen
• HTTP-Timeouts und Nachrichtengrößen begrenzen synchrone Integrationen; lange Prozesse asynchron oder eventbasiert modellieren
• Connector-Typen, Integrationskonten, Storage und Netzwerkanbindung können Zusatzkosten verursachen

Typische Einsatzszenarien

• Genehmigungs- und Eskalationsprozesse über Microsoft 365, Dynamics und Drittanbieter
• Daten-Synchronisation zwischen SaaS, Azure-Diensten und On-Premises-Systemen
• B2B-Integration mit EDI, XML und Integrationskonten
• Eventbasierte Automatisierung rund um Dateien, Tickets, APIs und Nachrichten

Links

Beschreibung

Azure Service Bus entkoppelt Anwendungen über Queues, Topics und Subscriptions, damit Sender und Empfänger unabhängig voneinander arbeiten können. Der Dienst bietet Funktionen wie Dead Letter Queues, Sessions, Duplicate Detection, Transaktionen, geplante Nachrichten und Filterregeln. Er ist sinnvoll, wenn Geschäftsnachrichten zuverlässig verarbeitet werden müssen und Consumer mit Wiederholungen, Sperren und möglichen Duplikaten umgehen können.

Wichtige Hinweise

• Basic unterstützt keine Topics, Transaktionen, Sessions, Duplicate Detection oder Forwarding; für Enterprise Messaging meist Standard oder Premium prüfen
• Premium bietet isolierte Ressourcen über Messaging Units, Netzwerksicherheitsfunktionen, CMK und größere AMQP-Nachrichten bis 100 MB
• Standard und Basic sind bei einzelnen Nachrichten typischerweise auf 256 KB begrenzt; große Payloads besser in Storage ablegen und Referenzen senden
• Peek-Lock arbeitet mit mindestens einmaliger Zustellung; Consumer müssen idempotent sein und Duplikate sauber behandeln
• Alte SDKs und das SBMP-Protokoll werden am 30. September 2026 eingestellt; auf aktuelle Azure SDKs und AMQP migrieren

Typische Einsatzszenarien

• Auftrags-, Bestell- und Zahlungsprozesse asynchron absichern
• Fachsysteme über Queues ohne direkte Kopplung verbinden
• Pub/Sub-Verteilung von Ereignissen an mehrere Backend-Systeme
• Fehlerhafte Nachrichten über Dead Letter Queues analysieren und erneut verarbeiten

Links

Beschreibung

Azure Event Grid ist der Event-Router für reaktive Architekturen. Er passt, wenn Systeme auf Zustandsänderungen reagieren sollen, zum Beispiel Blob erstellt, Ressource geändert oder eigenes Domänenereignis veröffentlicht. Event Grid transportiert Ereignisse, speichert aber keine langen Nachrichtenströme wie Event Hubs und ersetzt keinen Enterprise-Broker wie Service Bus. Für zuverlässige Verarbeitung musst Du Retry, Dead Lettering, Idempotenz und Event-Schema bewusst planen.

Wichtige Hinweise

• Abrechnung erfolgt pro Operation, zum Beispiel Veröffentlichung, Zustellung, Filterung und Managementvorgang
• System Topics, Custom Topics, Domains und Partner Topics nach Mandanten- und Betriebsmodell wählen
• Event Grid ist für Ereignisse gedacht, nicht für große Payloads oder lang laufende Streams
• Dead Lettering, Retry Policy und idempotente Consumer für produktive Verarbeitung einplanen
• MQTT und Namespace-Funktionen haben eigene Limits, Preis- und Architekturdetails

Typische Einsatzszenarien

• Reaktion auf Storage-, Resource- oder App-Ereignisse
• Serverlose Automatisierung mit Azure Functions und Logic Apps
• Entkopplung von Microservices über Ereignisse
• Event-Verteilung an mehrere Subscriber
• IoT- oder MQTT-nahe Event-Ingestion über Event Grid Namespaces

Links

Beschreibung

Azure Event Hubs ist für hohe Streaming-Datenraten aus Anwendungen, Geräten, Logs und Plattformen gedacht. Der Dienst passt, wenn viele Events aufgenommen und von mehreren Consumern verarbeitet werden sollen. Er ist Kafka-kompatibel, aber kein vollständiger Kafka-Cluster mit beliebiger Brokerkontrolle. Architekturentscheidend sind Partitionen, Consumergruppen, Retention, Capture, Throughput Units, Processing Units oder Dedicated Capacity.

Wichtige Hinweise

• Basic, Standard, Premium und Dedicated unterscheiden sich bei Features, Isolation, Skalierung und Kosten
• Throughput Units, Processing Units oder Capacity Units bestimmen Durchsatz und Preis je Tier
• Partitionenzahl nach Parallelität und langfristigem Wachstum wählen, weil Änderungen eingeschränkt sein können
• Capture schreibt Streams nach Storage oder Data Lake und verursacht zusätzliche Speicher- und Transaktionskosten
• Consumer müssen Checkpointing, Reihenfolge pro Partition und Wiederholungen sauber behandeln

Typische Einsatzszenarien

• Log- und Telemetrie-Ingestion für Analytics und SIEM
• IoT- und Gerätedatenströme mit hohem Durchsatz
• Kafka-kompatible Event-Ingestion für Cloud-Apps
• Streaming in Azure Stream Analytics, Functions, Databricks oder Fabric
• Event Capture für Rohdatenablage im Data Lake

Links

Beschreibung

Azure Communication Services ist passend, wenn Anwendungen selbst SMS, E-Mail, Chat, Telefonie oder Video bereitstellen sollen. Der Dienst liefert APIs, SDKs und Integrationen, übernimmt aber nicht automatisch komplette Contact-Center- oder Compliance-Prozesse. Du musst Identitäten, Einwilligungen, Rufnummern, Zustellbarkeit, Missbrauchsschutz und regionale Verfügbarkeit selbst planen. Kosten entstehen nutzungsbasiert je Kanal, Ziel, Dauer oder Nachricht.

Wichtige Hinweise

• SMS-, Telefonie- und E-Mail-Verfügbarkeit unterscheiden sich nach Land, Nummerntyp, Regulatorik und Absenderanforderungen
• Abrechnung ist nutzungsbasiert und kanalabhängig, zum Beispiel Nachricht, Minute, Teilnehmer oder E-Mail-Volumen
• Für E-Mail sind Domains, DNS-Records, Reputation und Bounce-Verarbeitung entscheidend
• Notruf, Aufzeichnung, Datenschutz, Consent und Aufbewahrung je Szenario rechtlich prüfen
• Teams-Interoperabilität, Telefonnummern und direkte Routingoptionen vor Architekturentscheidung validieren

Typische Einsatzszenarien

• SMS-Benachrichtigungen und Verifizierungscodes
• E-Mail-Versand aus Anwendungen und Portalen
• Chat, Voice und Video in Kunden- oder Supportprozessen
• Termin-, Service- und Field-Worker-Kommunikation
• Integration von Kommunikationsfunktionen in eigene Apps

Links

Beschreibung

Azure IoT Hub verbindet IoT-Geräte, Edge-Komponenten und Backend-Anwendungen sicher und skalierbar. Der Dienst unterstützt Geräteidentitäten, SAS- oder X.509-Authentifizierung, Geräte- und Modulzwillinge, direkte Methoden, Dateiuploads, Nachrichtenrouting und Monitoring. Er eignet sich für Geräteflotten, bei denen Telemetrie, Befehle, Konfiguration und Routing zuverlässig zusammengeführt werden müssen.

Wichtige Hinweise

• Basic unterstützt Geräteidentität, Geräte-zu-Cloud und Routing, aber keine Cloud-to-device-Kommunikation, Device Twins, IoT Edge und Gerätemanagement; für bidirektionale Flotten Standard wählen
• Geräteauthentifizierung über SAS oder X.509 planen; für Massenbereitstellung Device Provisioning Service einbeziehen
• Pro Hub maximal 1.000.000 Geräte oder Module; pro Abonnement 50 IoT Hubs und ein Free Hub beachten
• D2C-Nachrichten maximal 256 KB, C2D maximal 64 KB; Routing und Zielendpunkte auf Durchsatz dimensionieren
• Nach Microsoft werden Kundendaten nicht außerhalb der Geografie der bereitgestellten Dienstinstanz gespeichert; Region für DACH/DSGVO bewusst wählen

Typische Einsatzszenarien

• Maschinen-, Sensor- und Anlagenflotten sicher anbinden
• Telemetrie in Event Hubs, Storage, Service Bus, Cosmos DB oder Analytics-Dienste routen
• Gerätekonfiguration über Device Twins und direkte Methoden steuern
• Industrie-, Gebäude- und Field-Service-Szenarien mit IoT Edge erweitern

Links

Beschreibung

Azure Digital Twins ist ein PaaS-Dienst für digitale Modelle ganzer Umgebungen wie Gebäude, Fabriken, Energieverteilnetze oder Anlagen. Du definierst Modelle mit DTDL, erstellst daraus digitale Zwillinge und verbindest sie über Beziehungen zu einem Graphen, der Livezustände und Kontext abbildet. Daten kommen häufig aus Azure IoT Hub, Geschäftssystemen oder APIs und werden über Abfragen, Ereignisrouten, Azure Functions, Event Hubs, Event Grid, Service Bus oder Azure Data Explorer weiterverarbeitet.

Wichtige Hinweise

• Modelle werden in DTDL definiert; DTDL v3 ist empfohlen, aber Azure Digital Twins Explorer unterstützt v3 nur eingeschränkt
• DTDL-Befehle sowie writable, minMultiplicity und maxMultiplicity werden von Azure Digital Twins nicht erzwungen
• Instanzlimits wie 2.000.000 Twins, 20.000.000 Beziehungen und 10.000 Modelle sowie 32 KB Twin-Payload beachten
• Ereignisrouten unterstützen Event Hubs, Event Grid und Service Bus; Dead Lettering muss explizit eingerichtet werden
• Kosten entstehen über Nachrichten, Vorgänge und Abfrageeinheiten; Graph-Abfragen und Routenaufkommen vorab modellieren

Typische Einsatzszenarien

• Smart Buildings mit Räumen, Etagen, Sensoren und Anlagen modellieren
• Fertigungs- und Anlagenzustände im Kontext von Beziehungen analysieren
• IoT-Hub-Telemetrie mit Geschäftsobjekten und Standortdaten verbinden
• Betriebsdaten über Event Routes und Azure Data Explorer historisieren

Links

Beschreibung

Azure Synapse Analytics ist ein integrierter Analysedienst für Data Warehousing, Data-Lake-Abfragen, Spark-basierte Datenverarbeitung und ETL/ELT-Pipelines. Du kannst Daten über dedizierte SQL-Pools mit reservierter Leistung oder serverlose SQL-Endpunkte für ad-hoc-Analysen abfragen. Synapse Studio bündelt Entwicklung, Monitoring, Zugriffskontrolle und Integration mit Power BI, Azure Machine Learning und weiteren Azure-Diensten.

Wichtige Hinweise

• Dedizierte SQL-Pools, serverlose SQL-Pools, Spark-Pools und Pipelines haben unterschiedliche Abrechnungs- und Betriebsmodelle
• Dedizierte SQL-Pools verursachen Compute-Kosten, solange sie laufen; Pausieren, Skalieren und reservierte Kapazität bewusst planen
• Serverlose SQL-Abfragen werden nach verarbeiteten Daten berechnet; Dateiformate, Partitionierung und Abfragefilter beeinflussen Kosten stark
• Spark-Pools brauchen passende Node-Größen, Auto-Scale, Auto-Pause und Bibliotheksverwaltung, sonst entstehen unnötige Laufzeitkosten
• Data Explorer in Synapse wird in der Doku weiterhin als Vorschau beschrieben; für produktive Protokoll- und Zeitreihenanalyse Status und Zielarchitektur prüfen

Typische Einsatzszenarien

• Enterprise Data Warehouse mit SQL-Pools und Power-BI-Anbindung
• Ad-hoc-Analyse von Parquet-, CSV-, JSON- oder Delta-Daten im Data Lake
• ETL- und ELT-Orchestrierung über Synapse-Pipelines und Data-Factory-Engine
• Spark-basierte Datenaufbereitung, Feature Engineering und ML-nahe Verarbeitung

Links

Beschreibung

Azure Data Factory ist ein verwalteter Dienst für Datenintegration und Pipeline-Orchestrierung. Du verbindest Quellen über verknüpfte Dienste, bewegst Daten mit Copy-Aktivitäten, transformierst sie über Mapping Data Flows oder externe Compute-Dienste und steuerst Abläufe über Trigger, Parameter und Monitoring. Der Dienst eignet sich besonders für hybride Datenplattformen, bei denen Cloud- und On-Premises-Daten zuverlässig operationalisiert werden müssen.

Wichtige Hinweise

• Stand/Hinweis: Microsoft nennt Data Factory in Microsoft Fabric als nächste Generation; neue Integrationsarchitekturen sollten Fabric Data Factory mitprüfen
• Pipelines, Aktivitäten, Trigger, Datasets, verknüpfte Dienste und Integration Runtimes sauber trennen, sonst werden Betrieb und Migration schnell unübersichtlich
• Self-hosted Integration Runtime ist für lokale oder private Quellen nötig und muss gepatcht, überwacht und hochverfügbar geplant werden
• Kosten entstehen durch Orchestrierung, Aktivitätsausführung, Integration-Runtime-Stunden, Data-Flow-vCore-Stunden, Debugging und Monitoring-Vorgänge
• Bei Migration zu Fabric ändern sich Architekturdetails wie Verbindungen, Datasets, globale Parameter, Identität, Zeitpläne und nicht unterstützte Aktivitäten

Typische Einsatzszenarien

• Tägliche oder ereignisbasierte ETL-/ELT-Pipelines aus ERP, SQL, SaaS und Dateien
• Datenmigrationen zwischen On-Premises, Azure Storage, Synapse, SQL und Lakehouse-Zielen
• Hybrid-Datenintegration über Self-hosted Integration Runtime und private Netzwerke
• Betrieblich überwachbare Ladeprozesse mit Alerting, Parametern und CI/CD

Links

Beschreibung

Azure Databricks kombiniert die Databricks Data Intelligence Platform mit Azure-Integration für Identität, Abrechnung, Netzwerk und Speicher. Teams nutzen Notebooks, Jobs, SQL Warehouses, Delta Lake, Unity Catalog, MLflow, Lakeflow-Pipelines und serverlose oder klassische Compute-Optionen für Daten- und KI-Plattformen. Der Dienst ist stark, wenn Data Engineers, Analysten und Data Scientists gemeinsam auf einem governed Lakehouse arbeiten sollen.

Wichtige Hinweise

• Stand/Hinweis: Azure Databricks Standard-Tier läuft aus; neue Standard-Workspaces sind ab 1. April 2026 nicht mehr vorgesehen und bestehende Standard-Workspaces müssen bis 1. Oktober 2026 auf Premium wechseln
• Kosten setzen sich aus Azure-VMs beziehungsweise serverlosem Compute und Databricks Units zusammen; Jobs, All-Purpose, SQL, ML und serverlose Workloads getrennt kalkulieren
• Unity Catalog für Governance, Berechtigungen, Lineage und sichere Datenfreigabe früh einplanen; Premium-Funktionen und Compliance-Add-ons können kostenrelevant sein
• VNet Injection, Private Link, Managed Identities, Storage-Credentials und Exfiltration-Schutz vor Produktivstart klären
• Cluster Policies, Auto-Termination, Jobs Compute, Serverless und Reserved/Commit-Optionen aktiv nutzen, sonst laufen Kosten schnell aus dem Ruder

Typische Einsatzszenarien

• Lakehouse-Plattform für Data Engineering, BI und Data Science
• Batch- und Streaming-Pipelines mit Delta Lake, Auto Loader und Lakeflow
• SQL Analytics und Dashboards auf Data-Lake-Daten
• ML-/KI-Training, Feature Engineering, MLflow und generative KI auf Unternehmensdaten

Links

Beschreibung

Microsoft Fabric ist Microsofts SaaS-Analytics-Plattform für Datenintegration, Lakehouse, Warehouse, Echtzeitdaten, Data Science und BI. Der Dienst ist strategisch der neue Zielpfad für viele Analytics-Szenarien, die früher mit Synapse und Data Factory einzeln gebaut wurden. Fabric passt, wenn Teams eine einheitliche SaaS-Erfahrung mit OneLake, Workspaces, Kapazitäten und Governance suchen. Für tief Azure-native Spezialarchitekturen, bestehende Spark-Setups oder harte Netzwerkisolation müssen Synapse, Databricks oder Azure-Dienste weiter geprüft werden.

Wichtige Hinweise

• Abrechnung erfolgt über Fabric-Kapazitäten mit F-SKUs, Power BI Kapazitäten oder Trial-Modellen je Tenant und Region
• OneLake, Shortcuts, Workspaces, Domains und Berechtigungen sauber governancenah modellieren
• Nicht jede Synapse- oder Data-Factory-Funktion ist 1:1 in Fabric identisch; Migration pro Pipeline und Workload prüfen
• Kapazitätsauslastung, Autoscale, Pausieren und Monitoring entscheiden über Kosten und Performance
• Datenresidenz, Tenant-Einstellungen und externe Freigaben für DACH/DSGVO vor Produktivstart klären

Typische Einsatzszenarien

• Lakehouse und Warehouse auf OneLake für BI und Analytics
• Ablösung oder Ergänzung von Synapse- und Data-Factory-Strecken
• Self-Service-BI mit zentraler Governance
• Real-Time Intelligence für Event- und Logdaten
• Data Science und ML-nahe Analysen in einer SaaS-Plattform

Links

Beschreibung

Azure Stream Analytics ist ein verwalteter Dienst für kontinuierliche Stream-Verarbeitung. Du schreibst SQL-ähnliche Abfragen, liest Daten aus Event Hubs, IoT Hub oder Blob Storage und schreibst Ergebnisse in Ziele wie SQL, Data Lake, Event Hubs, Power BI oder Functions. Der Dienst passt, wenn Echtzeitfilter, Aggregationen, Fensterfunktionen und einfache Anreicherungen ohne eigenes Streaming-Cluster benötigt werden. Für komplexe Stateful-Processing-Frameworks oder Spark-Streaming ist Databricks oder Fabric Real-Time Intelligence zu prüfen.

Wichtige Hinweise

• Streaming Units bestimmen Durchsatz, Parallelität und Kosten
• Partitionierung von Input, Query und Output muss zusammenpassen, sonst skaliert der Job nicht sauber
• Späte, ungeordnete und doppelte Events über Zeitrichtlinien und Query-Design behandeln
• Reference Data eignet sich für kleine Anreicherungen, nicht für beliebig große Lookups
• Kompatibilitätslevel, Funktionen und Outputs vor Migration oder CI/CD festlegen

Typische Einsatzszenarien

• IoT-Telemetrie in Echtzeit filtern und aggregieren
• Anomalien, Schwellenwerte und Alarme aus Event Hubs erkennen
• Live-Dashboards und Power-BI-Streamingdaten speisen
• Datenströme in Storage, SQL oder Data Lake schreiben
• Einfache Echtzeit-ETL ohne eigenes Cluster betreiben

Links

Beschreibung

Azure Data Explorer ist für schnelle Ad-hoc-Analysen über Logs, Telemetrie, Metriken, Zeitreihen und Security-Daten optimiert. Der Dienst arbeitet mit Clustern, Datenbanken, Tabellen, Ingestion-Pipelines und KQL. Er passt, wenn Daten mit hoher Schreibrate aufgenommen und sehr schnell explorativ abgefragt werden müssen. Für klassische relationale Transaktionen oder allgemeines Data Warehousing sind Azure SQL, Fabric Warehouse oder Synapse passender.

Wichtige Hinweise

• Kosten entstehen vor allem durch Cluster-Compute, Storage, Markup, Ingestion und Datenaufbewahrung
• Clustergröße, Autoscale, Hot Cache, Retention und Update Policies prägen Performance und Preis
• Ingestion über Event Hubs, IoT Hub, Event Grid, Kafka, Storage oder Pipelines sauber entkoppeln
• KQL-Modellierung, Materialized Views und Partitionierung beeinflussen Abfragekosten stark
• Datenexport, RBAC, Private Endpoints und kundenseitig verwaltete Schlüssel für Enterprise-Betrieb prüfen

Typische Einsatzszenarien

• Log- und Telemetrieanalyse für Plattformen und Anwendungen
• Zeitreihenauswertung für IoT, Industrie und Monitoring
• Security Hunting und KQL-basierte Untersuchungen
• Clickstream-, Nutzungs- und Betriebsdaten interaktiv analysieren
• Near-Real-Time-Analytics mit hoher Ingestion-Rate

Links

Beschreibung

Azure Arc erweitert Azure-Management, Governance und Sicherheitsfunktionen auf lokale Rechenzentren, Edge-Standorte und andere Clouds. Ressourcen werden als Azure-Ressourcen sichtbar und können über Azure Portal, Azure Policy, Azure Monitor, Defender for Cloud, Tags, RBAC, Resource Graph, Erweiterungen und Automatisierung verwaltet werden. Damit eignet sich Arc für konsistente Betriebsstandards, ohne alle Workloads direkt nach Azure zu migrieren.

Wichtige Hinweise

• Die Arc-Steuerungsebene für Inventar, Organisation, RBAC, Tags und viele Verwaltungsfunktionen ist kostenlos; aktivierte Azure-Dienste wie Monitor, Defender, Sentinel, Update Manager oder Policy-Gastkonfiguration werden separat berechnet
• Connected Machine Agent, ausgehende Konnektivität, Identität, Proxy, Firewallfreigaben und Netzwerkanforderungen vor Rollout prüfen
• Stand/Hinweis: Der indirekt verbundene Modus für Arc-fähige Datendienste wird laut Microsoft ab September 2025 eingestellt
• Windows Server Pay-as-you-go, SQL Server Pay-as-you-go und Extended Security Updates über Arc können Lizenz- und Kostenmodell verändern
• Für DACH/DSGVO die gewählte Azure-Region, Log-Workspace-Region, Defender/Sentinel-Datenflüsse und Aufbewahrung bewusst festlegen

Typische Einsatzszenarien

• Zentrales Inventar und Governance für Windows-/Linux-Server in Rechenzentren, Filialen und anderen Clouds
• Patch-, Sicherheits- und Compliance-Management über Azure Policy, Update Manager und Defender for Cloud
• Kubernetes-Cluster über GitOps, Policy und Cluster-Erweiterungen einheitlich betreiben
• SQL Server außerhalb von Azure inventarisieren, lizenzieren, überwachen und über Arc absichern

Links

Beschreibung

Azure Local ist Microsofts verteilte Infrastrukturlösung für lokale, Edge- und souveräne Standorte. Du betreibst Workloads auf eigener Hardware, verwaltest Infrastruktur und Workloads aber cloudnah über Azure Arc, Azure Portal, Azure CLI, ARM-Vorlagen und integrierte Dienste wie Azure Monitor, Azure Policy und Defender for Cloud. Der Dienst passt, wenn Daten, Latenz, Verfügbarkeit oder Standortvorgaben gegen eine reine Public-Cloud-Bereitstellung sprechen.

Wichtige Hinweise

• Azure Local wird pro physischem Kern der lokalen Computer abgerechnet; nach Registrierung gibt es laut Preisseite eine kostenlose 60-Tage-Testphase
• Ein Azure-Abonnement ist für Einrichtung und cloudverbundene Verwaltung erforderlich; validierte Partnerhardware oder kompatible Hardware nach Azure-Local-Katalog einplanen
• Azure Kubernetes Service aktiviert durch Azure Arc ist in Azure Local ab Version 2402 ohne zusätzliche AKS-Gebühr enthalten, verbrauchsbasierte Azure-Dienste können trotzdem kostenpflichtig sein
• Windows-Server-Gastlizenzierung, Azure-Hybridvorteil und optionale Workloads getrennt prüfen, weil Hostdienstgebühr, Gastrechte und Zusatzdienste unterschiedlich wirken
• Für getrennte Betriebsmodi, SAN-attach, sehr große Multi-Rack-Szenarien oder lokal gehostete Control Plane empfiehlt Microsoft direkte Abstimmung mit dem Account-Team

Typische Einsatzszenarien

• Produktions-, Logistik- oder Filialstandorte mit niedriger Latenz und lokalem Weiterbetrieb bei WAN-Ausfall
• Regulierte Workloads, bei denen Daten lokal gehalten und trotzdem zentral verwaltet werden sollen
• Edge-KI-Inferenz, industrielle Qualitätssicherung und lokale Datenvorverarbeitung
• Modernisierung lokaler Virtualisierung und Containerplattformen mit Azure-Managementmodell

Links

Beschreibung

Azure Migrate hilft Dir, Server, Datenbanken, Web-Apps und virtuelle Desktops zu inventarisieren, zu bewerten und nach Azure zu migrieren. Der Dienst passt für strukturierte Migrationsprogramme, weil Abhängigkeiten, Sizing, Readiness, Kostenabschätzung und Migrationswellen zentral sichtbar werden. Er ersetzt aber keine fachliche Migrationsplanung, Tests oder Zielarchitektur. Die Bewertung ist kostenlos, die Zielressourcen, Replikation, Storage, Netzwerk und Drittanbieter-Tools können Kosten erzeugen.

Wichtige Hinweise

• Azure Migrate selbst ist grundsätzlich kostenlos; Zielressourcen und abhängige Dienste werden separat berechnet
• Discovery Appliance, Credentials, Netzwerkzugriff und Datensammlung früh mit Security und Betrieb abstimmen
• Assessments sind nur so gut wie Laufzeitdaten, Abhängigkeitsanalyse und korrekte Zielannahmen
• Server-, SQL-, Web-App- und VDI-Migrationen haben unterschiedliche Tools und Grenzen
• Cutover, Testmigration, Rollback, DNS, Identität und Betriebsübergabe pro Welle planen

Typische Einsatzszenarien

• Discovery und Assessment von VMware-, Hyper-V- und physischen Servern
• Sizing und Kostenabschätzung für Azure-VM-Zielumgebungen
• Migrationswellen für Rechenzentrums- oder Standortablösungen
• Bewertung von SQL Server und Web-Apps vor Modernisierung
• Projektsteuerung für Lift-and-Shift und Modernisierungspfade

Links

Beschreibung

Azure Database Migration Service ist ein verwalteter Dienst für Datenbankmigrationen mit Online- oder Offline-Ansätzen. Er passt, wenn Datenbanken nach Azure SQL, SQL Managed Instance, PostgreSQL, MySQL oder andere unterstützte Ziele migriert werden sollen und Du einen geführten Migrationsdienst brauchst. Der Dienst ersetzt nicht die Schema-, Code- und Kompatibilitätsanalyse, die vorab mit passenden Tools erfolgen muss. Bei vielen modernen Pfaden empfiehlt Microsoft inzwischen zielnative Migrationserfahrungen, deshalb solltest Du DMS und native Werkzeuge je Quelle vergleichen.

Wichtige Hinweise

• Online-Migration reduziert Downtime, braucht aber Replikation, Netzwerkstabilität und sauberen Cutover
• Offline-Migration ist einfacher, erzeugt aber längere Ausfallzeit
• Unterstützte Quellen, Ziele und Features unterscheiden sich je Datenbankengine
• Schema-Konvertierung, inkompatible Features, Logins, Jobs und Berechtigungen separat behandeln
• Kosten und Verfügbarkeit hängen vom gewählten DMS-Modell, Zielressourcen und Datenbewegung ab

Typische Einsatzszenarien

• SQL Server zu Azure SQL Managed Instance oder Azure SQL Database migrieren
• PostgreSQL- oder MySQL-Migrationen zu verwalteten Azure-Diensten
• Minimierung von Downtime über Online-Migration
• Testmigrationen und Cutover-Proben für kritische Datenbanken
• Datenbankmodernisierung im Rahmen größerer Azure-Migrationen

Links

Beschreibung

Azure Monitor ist Microsofts zentrale Observability-Plattform für Anwendungen, Infrastruktur, Netzwerke, Kubernetes, virtuelle Maschinen und hybride Ressourcen. Der Dienst bündelt Metriken, Logs, Traces und Events in Azure Monitor- und Log-Analytics-Arbeitsbereichen, macht sie über Dashboards, Workbooks, Grafana, Metrik-Explorer und KQL-Abfragen auswertbar und reagiert über Alerts, Action Groups, Autoscale und Insights. Für produktive Umgebungen sind Datenquellen, Arbeitsbereichsstrategie, Datenaufbewahrung, Alert-Design und Kostenkontrolle genauso wichtig wie die eigentliche technische Aktivierung.

Wichtige Hinweise

• Azure Monitor nutzt getrennte Plattformen für Log Analytics-Arbeitsbereiche mit KQL und Azure-Monitor-Arbeitsbereiche für Prometheus/OpenTelemetry-Metriken; Arbeitsbereichstyp und Abfragesprache bewusst wählen
• Kosten entstehen vor allem durch Log-Erfassung, Aufbewahrung, Export, Plattformprotokollstreaming, Warnungen, Webtests und einzelne Zusatzfeatures; Standardmetriken und Aktivitätsprotokolle sind grundsätzlich ohne Zusatzkosten verfügbar
• Analytics-, Basic- und Auxiliary-Protokollpläne unterscheiden sich bei Kosten, Aufbewahrung, Abfragefunktionen und Alerting; Tabellenstrategie vor großem Rollout planen
• Azure Monitor Agent und Data Collection Rules bevorzugen, um VM- und Serverdaten granular zu filtern und doppelte Datensammlung zu vermeiden
• Für Kostenkontrolle Sampling, Datenfilterung, Tageslimits mit Warnungen, Arbeitsbereichseinblicke, Advisor-Empfehlungen und passende Retention konsequent nutzen

Typische Einsatzszenarien

• Zentrales Betriebsmonitoring für Azure-Ressourcen, VMs, AKS, Netzwerke und hybride Systeme
• Application Performance Monitoring mit Application Insights, OpenTelemetry, Traces, Abhängigkeiten und Fehlerraten
• KQL-basierte Fehleranalyse in Log Analytics, Workbooks und Dashboards für Operations-Teams
• Alerting, Eskalation, Autoscale und Automatisierung über Action Groups und Metrik-/Logregeln
• Kosten- und Datenvolumensteuerung für Log-Analytics-, Sentinel- und Application-Insights-Workspaces

Links

Beschreibung

Azure Policy hilft dir, organisatorische Standards in Azure konsistent umzusetzen. Richtliniendefinitionen beschreiben in JSON, welche Ressourceneigenschaften erlaubt, erforderlich oder zu korrigieren sind; Initiativen bündeln mehrere Definitionen zu einem Governance-Ziel. Zuweisungen gelten auf Verwaltungsgruppen, Abonnements, Ressourcengruppen oder einzelnen Ressourcen. Je nach Effekt kann Azure Policy nur auditieren, Bereitstellungen verweigern, Tags oder Einstellungen ändern, verwandte Ressourcen bereitstellen oder vorhandene Ressourcen über Remediation Tasks korrigieren.

Wichtige Hinweise

• Mit audit/auditIfNotExists starten und deny, modify oder deployIfNotExists erst nach Auswirkungsprüfung scharf schalten, damit Automatisierungen und Deployments nicht unerwartet brechen
• Initiativen vereinfachen Landing-Zone-, Sicherheits-, Tagging-, Regionen- und Compliance-Standards; Richtlinien als Code versionieren und reviewed ausrollen
• Compliance wird bei Ressourcenerstellung/-änderung, Policy-Änderungen und regelmäßig etwa alle 24 Stunden neu bewertet
• Remediation für modify und deployIfNotExists benötigt eine verwaltete Identität mit passenden RBAC-Rollen; bei SDK/IaC-Zuweisungen Berechtigungen manuell prüfen
• Azure Policy für Azure-Ressourcen ist gebührenfrei; Azure Automanage-/Maschinenkonfiguration für Server kann separat pro registriertem Server berechnet werden

Typische Einsatzszenarien

• Landing-Zones mit erlaubten Regionen, Ressourcentypen, SKUs, Tags und Diagnoseeinstellungen standardisieren
• Compliance-Dashboard für Managementgruppen, Abonnements und Ressourcengruppen bereitstellen
• Nicht konforme Ressourcen erkennen, Berichte erstellen und Remediation Tasks ausführen
• Kosten-Governance durch Pflicht-Tags, erlaubte SKUs und Budget-/Monitoring-nahe Standards unterstützen
• Hybrid- und Multicloud-Governance über Azure Arc und Maschinenkonfiguration erweitern

Links

Beschreibung

Microsoft Cost Management ist die FinOps- und Kostensteuerungsschicht für Microsoft-Cloud-Ausgaben. Du analysierst Kosten nach Bereichen, Diensten, Ressourcengruppen, Regionen, Tags oder eigenen Filtern, richtest Budgets und Warnungen ein, exportierst Kostendetails in Storage oder externe Systeme und nutzt Empfehlungen aus Advisor, Reservierungen, Savings Plans und Hybridvorteil zur Optimierung. Die Daten sind betriebsnah, aber während des laufenden Monats geschätzt und hängen von Abrechnungsmodell, Dienstmeldung, Tags und Datenaktualisierung ab.

Wichtige Hinweise

• Microsoft Cost Management ist ohne zusätzliche Kosten verfügbar; die eigentlichen Azure-, Marketplace-, Reservierungs-, Savings-Plan- und Support-/Steuerpositionen folgen den jeweiligen Abrechnungsregeln
• Kosten des laufenden Monats sind Schätzwerte und können sich bis zur Rechnungsstellung ändern; EA- und MCA-Daten sind meist nach 8 bis 24 Stunden verfügbar, nutzungsbasierte Abonnements können bis zu 72 Stunden benötigen
• Tags werden nicht automatisch von Ressourcengruppen geerbt, gelten nicht rückwirkend und erscheinen erst nach Datenaktualisierung; Taggingstrategie und ggf. Tagvererbung früh planen
• Kostenanalyse zeigt im Portal typischerweise die letzten 13 Monate, während Daten länger aufbewahrt und für ältere Zeiträume per Export/API benötigt werden können
• Budgets, Anomalieerkennung, geplante Warnungen, Exporte, Kostenanalyse, Advisor-Empfehlungen, Reservierungen und Savings Plans gemeinsam als FinOps-Prozess betreiben

Typische Einsatzszenarien

• Kostenanalyse nach Abonnement, Ressourcengruppe, Dienst, Region, Tag, Kostenstelle oder Projekt
• Budgetwarnungen und geplante Kostenberichte für Fachbereiche, Plattformteams und Finanzen
• Chargeback und Showback über Tags, Abrechnungsprofile, Rechnungsabschnitte und Kostenzuteilung
• Automatisierte Exporte für BI, Data Warehouse, ERP, Ticketsysteme oder interne FinOps-Dashboards
• Optimierung über Reservierungen, Azure Savings Plans, Azure Hybrid Benefit, Advisor-Empfehlungen und Rechte-Sizing

Links

Beschreibung

Azure Site Recovery ist der DR-Dienst für geplante und ungeplante Ausfälle von VMs und Servern. Er passt, wenn Du Replikation, Recovery-Pläne, Test-Failover, Netzwerkzuordnung und Failback zentral steuern willst. Der Dienst ist kein Backup-Ersatz, weil er Wiederanlauf und Replikation adressiert, nicht langfristige Aufbewahrung. RPO, RTO, App-Abhängigkeiten, Netzwerk, DNS, Identität und Runbooks müssen vor dem Ernstfall getestet werden.

Wichtige Hinweise

• Abrechnung erfolgt pro geschützter Instanz nach kostenloser Testphase, Ziel-Compute und Storage kommen separat dazu
• RPO und RTO hängen von Workload, Bandbreite, Änderungsrate, Zielregion und Tests ab
• Test-Failover regelmäßig isoliert durchführen, sonst bleibt der DR-Plan Theorie
• Nicht jede VM-, Disk-, Region- oder Plattformkombination ist unterstützt
• Azure Backup und Site Recovery gemeinsam planen, weil Sicherung und DR unterschiedliche Ziele haben

Typische Einsatzszenarien

• DR für Azure-VMs zwischen Regionen
• Migration und Schutz von VMware- oder physischen Servern
• Regelmäßige Notfalltests mit isolierten Netzwerken
• Recovery-Pläne für mehrstufige Anwendungen
• Standortablösung mit kontrolliertem Failover

Links

Beschreibung

Azure Automation ist passend, wenn wiederkehrende Betriebsaufgaben als PowerShell- oder Python-Runbooks zentral laufen sollen. Der Dienst kann Azure-Ressourcen, externe APIs und Hybrid Worker ansprechen. Er ersetzt keine moderne CI/CD-Plattform und kein komplettes Konfigurationsmanagement, ist aber stark für Betrieb, Scheduling und kontrollierte Administrationsabläufe. Für Updates ist Azure Update Manager der neuere Zielpfad.

Wichtige Hinweise

• Process Automation wird nach Jobausführungsminuten abgerechnet, Freikontingente und Hybrid Worker prüfen
• Run As Accounts sind Legacy; Managed Identities für neue Runbooks bevorzugen
• Module, Runtime-Versionen, Credentials, Zertifikate und Secrets aktiv pflegen
• Hybrid Runbook Worker braucht Netzwerk, Agent, Identität und Monitoring
• Update Management in Automation wurde durch Azure Update Manager als Zielmodell abgelöst

Typische Einsatzszenarien

• Geplantes Starten, Stoppen und Skalieren von Ressourcen
• Betriebsrunbooks für Wartung, Cleanup und Reporting
• Automatisierte Reaktion auf Alerts und Tickets
• Hybrid-Automatisierung über Runbook Worker
• Sichere Ausführung wiederkehrender Admin-Aufgaben

Links

Beschreibung

Azure Update Manager ist der zentrale Dienst für Patch-Assessment, Updateplanung und Wartungsfenster über Azure-VMs und Arc-fähige Server. Er passt, wenn Du Updates nach Zeitplänen, dynamischen Bereichen, Compliance-Sichten und Wartungskonfigurationen steuern willst. Der Dienst ersetzt nicht Anwendungs-Releaseprozesse oder vollständiges Vulnerability Management. Für Hybridserver müssen Azure Arc, Agenten, Netzwerk und Abrechnung sauber eingeplant werden.

Wichtige Hinweise

• Azure-VMs sind im Dienst enthalten; Arc-fähige Server außerhalb Azure können pro Server berechnet werden
• Maintenance Configurations, dynamische Scopes und Reboot-Verhalten vor Rollout testen
• Linux- und Windows-Paketquellen bleiben relevant, Update Manager ersetzt keine Repository-Strategie
• Azure Automation Update Management ist nicht der Zielpfad für neue Designs
• Patch-Compliance mit Defender for Cloud, Policy und Change-Prozessen verbinden

Typische Einsatzszenarien

• Patch-Orchestrierung für Azure-VMs in Landing Zones
• Zentrales Update-Management für Arc-fähige Windows- und Linux-Server
• Wartungsfenster für produktive Systeme steuern
• Compliance-Reporting für Betrieb und Security
• Ablösung alter Automation-Update-Management-Setups

Links

Beschreibung

Azure Lighthouse ist für MSPs, Konzern-IT und zentrale Plattformteams gedacht, die mehrere Tenants oder Kundenumgebungen verwalten. Kunden delegieren Abonnements oder Ressourcengruppen über Azure Resource Manager, danach arbeiten Admins aus dem eigenen Tenant mit definierten Rollen. Der Dienst passt, wenn Betrieb ohne Gastkonten, Tenantwechsel und manuelle Einzellösungen skalieren soll. Er ersetzt keine saubere Vertrags-, Rollen- und Prozessdefinition zwischen Betreiber und Kunde.

Wichtige Hinweise

• Azure Lighthouse selbst ist kostenlos; verwaltete Azure-Dienste in Kundenumgebungen bleiben kostenpflichtig
• Delegation erfolgt über ARM-Templates, Managed Service Offers oder Service Provider Registration
• RBAC-Rollen, Gruppen, PIM, JIT und Least Privilege vor Onboarding festlegen
• Nicht jede Azure-Funktion unterstützt delegierte Verwaltung vollständig
• Offboarding, Audit, Activity Logs und Zuständigkeiten je Kunde dokumentieren

Typische Einsatzszenarien

• MSP-Betrieb mehrerer Kundenumgebungen aus einem Tenant
• Zentrale Konzernverwaltung mehrerer Azure-Tenants
• Delegierte Security-, Monitoring- und Governance-Aufgaben
• Skalierbares Onboarding von Abonnements und Ressourcengruppen
• Betrieb ohne dauerhafte Gastadmin-Konten im Kundentenant

Links

Beschreibung

Bicep ist die domänenspezifische Sprache für Azure Resource Manager und vereinfacht ARM-Templates deutlich. Der Ansatz passt, wenn Azure-Ressourcen wiederholbar, versioniert und reviewed bereitgestellt werden sollen. ARM bleibt die Bereitstellungsschicht, Bicep kompiliert in ARM-Templates und lässt sich über CLI, PowerShell, Pipelines oder GitHub Actions ausführen. Es ist kein Konfigurationsmanagement für Betriebssysteme und ersetzt keine Governance über Policy, Rollen und Landing-Zone-Standards.

Wichtige Hinweise

• Bicep und ARM verursachen keine eigene Servicegebühr; bereitgestellte Ressourcen werden normal berechnet
• What-If vor produktiven Änderungen nutzen, aber Ergebnis trotzdem fachlich prüfen
• Module, Parameter, Outputs und Naming-Standards früh definieren
• Secrets nicht im Template speichern, sondern Key Vault, Parameter Stores oder Pipeline-Secrets nutzen
• Role Assignments, Locks, Policy Assignments und Deployment Scopes brauchen klare Berechtigungen

Typische Einsatzszenarien

• Landing-Zone- und Plattformmodule versioniert bereitstellen
• Wiederholbare Deployments für Apps, Netzwerke, Datenbanken und Monitoring
• Reviewbare Infrastrukturänderungen über Pull Requests
• What-If-Prüfung vor produktiven Deployments
• Standardisierte Umgebungen für Dev, Test und Produktion

Links