Handbuch

Hybride Identitätsauthentifizierung, bei der Passworthashes lokal bleiben müssen, mit Failover.

→Azure AD Connect mit Pass-Through-Authentifizierung (PTA) und aktivierter Kennwort-Hash-Synchronisierung (PHS) als Backup.

Warum: PTA behält Hashes lokal, indem es gegen das lokale AD validiert. PHS bietet Authentifizierungs-Failover, wenn das lokale AD oder der Connect-Agent nicht verfügbar ist.

Referenz↗

Implementieren Sie Zero Trust, indem Sie eine granulare Zugriffssteuerung basierend auf Benutzer, Standort, Gerätezustand und Risiko durchsetzen.

→Microsoft Entra Conditional Access-Richtlinien, die benannte Standorte, Gerätekonformität (Intune) und Anmelderisiko (Identity Protection) mit Zugriffssteuerungen wie MFA kombinieren.

Warum: Conditional Access ist die Durchsetzungs-Engine für Zero Trust, die mehrere Signale pro Anfrage bewertet, bevor der Zugriff gewährt wird. Eine einzelne Richtlinie kann nicht unterschiedliche Kontrollen auf unterschiedliche Bedingungen anwenden.

Referenz↗

Durchsetzung konsistenter Richtlinien (z. B. Tagging, zugelassene Regionen) über Dutzende oder Hunderte von Abonnements hinweg.

→Eine Managementgruppenhierarchie mit Azure Policy-Initiativen, die auf der Ebene der Stamm- oder übergeordneten Managementgruppe zugewiesen sind.

Warum: Managementgruppen bieten einen Governance-Umfang oberhalb von Abonnements, wodurch Richtlinien vererbt werden können. Initiativen bündeln mehrere Richtlinien für eine vereinfachte Zuweisung.

Referenz↗

Administratoren Just-in-Time (JIT) privilegierten Zugriff mit Genehmigungsworkflows und Auditierung bereitstellen.

→Microsoft Entra Privileged Identity Management (PIM), um Benutzer für Rollen berechtigt zu machen, anstatt sie dauerhaft aktiv zu haben.

Warum: PIM erzwingt das Prinzip der geringsten Rechte, indem Benutzer Rollen für einen zeitlich begrenzten Zeitraum aktivieren müssen, mit optionaler MFA, Begründung und Genehmigung, wodurch ein vollständiger Audit-Trail erstellt wird.

Referenz↗

Sammeln Sie Protokolle von allen Azure-Ressourcen über mehrere Abonnements hinweg für eine zentralisierte Analyse und Abfrage.

→Ein einziger, zentralisierter Log Analytics-Arbeitsbereich mit ressourcenkontext-basiertem RBAC für die Zugriffssteuerung.

Warum: Ein zentralisierter Arbeitsbereich ermöglicht Abfragen über Abonnements hinweg, vereinfacht die Verwaltung und vermeidet Datenredundanz. Ressourcenkontext-basiertes RBAC stellt sicher, dass Benutzer nur Protokolle von Ressourcen abfragen, auf die sie Zugriff haben.

Eine Azure-Ressource (z. B. App Service, Function, VM) muss sicher auf andere Azure-Ressourcen (Key Vault, SQL, Storage) zugreifen, ohne gespeicherte Anmeldeinformationen zu verwenden.

→Weisen Sie der Compute-Ressource eine verwaltete Identität (system- oder benutzerzugewiesen) zu und erteilen Sie ihr RBAC-Rollen für die Zielressourcen.

Warum: Verwaltete Identitäten eliminieren die Verwaltung von Anmeldeinformationen (Geheimnisse, Zertifikate), indem sie automatisch die Token-Beschaffung und -Rotation handhaben. Verwenden Sie benutzerzugewiesene Identitäten, um eine Identität über mehrere Ressourcen hinweg zu teilen.

Referenz↗

Vorhandene, nicht konforme Azure-Ressourcen, die durch eine Azure-Richtlinie identifiziert wurden, automatisch korrigieren.

→Verwenden Sie einen "DeployIfNotExists"- oder "Modify"-Richtlinien-Effekt. Für vorhandene Ressourcen muss eine Korrekturaufgabe für die Richtlinienzuweisung erstellt werden, die eine verwaltete Identität mit ausreichenden Berechtigungen erfordert.

Warum: Richtlinien mit diesen Effekten gelten standardmäßig nur für neue/aktualisierte Ressourcen. Eine Korrekturaufgabe ist erforderlich, um vorhandene nicht konforme Ressourcen zu scannen und zu beheben.

Erforderliche Tags für alle Ressourcen erzwingen und Tags (z. B. CostCenter) automatisch von der übergeordneten Ressourcengruppe erben.

→Verwenden Sie eine Azure Policy mit einem "Deny"-Effekt für erforderliche Tags und eine separate Richtlinie mit einem "Modify"-Effekt, um fehlende Tags von der Ressourcengruppe zu erben.

Warum: "Deny" erzwingt die Konformität bei der Erstellung. Der "Modify"-Effekt automatisiert die Tag-Verbreitung, reduziert den manuellen Aufwand und gewährleistet Konsistenz.

Eine mehrschichtige oder Microservices-Anwendung überwachen, um Transaktionen End-to-End zu verfolgen und Leistungsengpässe zu identifizieren.

→Alle Dienste mit Application Insights instrumentieren. Verwenden Sie die Anwendungsübersicht zur Visualisierung von Abhängigkeiten und Distributed Tracing für die End-to-End-Analyse von Anfragen.

Warum: Application Insights ist die native APM-Lösung, die Telemetriedaten über Komponenten hinweg automatisch korreliert, um eine einheitliche Ansicht einer Transaktion zu bieten und Latenzprobleme zu identifizieren.

Zugriff für externe Partner verwalten, einschließlich Anfragen, Genehmigungen, zeitlich begrenzten Zugriff und regelmäßige Überprüfungen.

→Microsoft Entra ID Governance Berechtigungsverwaltung. Erstellen Sie Zugriffspakete, die Ressourcen bündeln, Genehmigungsworkflows definieren, Ablaufrichtlinien festlegen und Zugriffsüberprüfungen planen.

Warum: Bietet einen vollständigen, automatisierten Lebenszyklus für den externen Zugriff, wodurch der Verwaltungsaufwand und das Sicherheitsrisiko im Vergleich zur manuellen Verwaltung von Gastkonten reduziert werden.

Ein Managed Service Provider oder ein zentrales IT-Team muss Ressourcen über mehrere Kunden-/Abteilungs-Azure AD-Mandanten hinweg verwalten.

→Azure Lighthouse. Kundenabonnements einbinden, um dem verwaltenden Mandanten delegierten Zugriff mit spezifischen RBAC-Rollen zu gewähren.

Warum: Lighthouse bietet eine einzige Steuerungsebene für die mandantenübergreifende Verwaltung, ohne Verzeichnisse wechseln oder Gastkonten verwalten zu müssen, während der Kunde die volle Kontrolle und Eigentümerschaft behält.

Sicheren Fernzugriff auf eine lokale Webanwendung für externe Benutzer bereitstellen, ohne VPN oder die Anwendung dem Internet auszusetzen.

→Microsoft Entra Application Proxy.

Warum: Application Proxy verwendet einen leichten lokalen Connector, der eine ausgehende Verbindung zu Azure herstellt. Er fungiert als Reverse Proxy, ermöglicht die Entra ID-Vorauthentifizierung und sicheren Zugriff ohne eingehende Firewall-Regeln oder eine öffentliche IP auf der Anwendung.

Eine global verteilte Anwendung erfordert eine Datenbank mit Lese-/Schreiblatenz unter 10 ms, flexiblem Schema und 99,999 % Verfügbarkeit.

→Azure Cosmos DB mit aktivierten Schreibvorgängen in mehreren Regionen. Der Partitionsschlüssel sollte so gewählt werden, dass die Arbeitslast gleichmäßig verteilt wird.

Warum: Cosmos DB wurde speziell für die globale Verteilung entwickelt und bietet schlüsselfertige Schreibvorgänge in mehreren Regionen, wodurch eine garantierte niedrige Latenz und das höchste Verfügbarkeits-SLA gewährleistet werden. Andere Datenbanken erfordern eine manuelle Replikation und können die Schreiblatenz nicht erreichen.

Erfassen Sie hochvolumige IoT-Telemetriedaten in Cosmos DB, um effiziente Abfragen nach Gerät und die automatische Archivierung alter Daten zu ermöglichen.

→Verwenden Sie `/deviceId` als Partitionsschlüssel. Konfigurieren Sie TTL für den Container, um alte Dokumente automatisch zu löschen. Verwenden Sie Change Feed, um Daten vor der Löschung für die Archivierung im Cold Storage (z. B. Blob Storage) zu erfassen.

Warum: Die Partitionierung nach `deviceId` ordnet Daten für ein einzelnes Gerät zusammen, was Abfragen effizient macht. TTL ermöglicht eine kostenlose, automatische Löschung. Change Feed ermöglicht eine reaktive Archivierungspipeline.

Wählen Sie ein kostengünstiges Azure SQL DB-Preismodell für eine Workload mit unvorhersehbarem, sprunghaftem Datenverkehr und erheblichen Leerlaufzeiten.

→Verwenden Sie das vCore-basierte Modell mit dem Serverless-Computetarif.

Warum: Serverless skaliert die Compute-Leistung automatisch nach Bedarf und pausiert während Leerlaufzeiten, wobei nur die pro Sekunde genutzte Compute-Leistung berechnet wird. Dies ist für intermittierende Workloads weitaus kostengünstiger als bereitgestellte Tarife.

Eine Speicherlösung für eine groß angelegte Datenanalyseplattform, die einen hierarchischen Namespace und ACLs auf Verzeichnis-Ebene erfordert.

→Azure Data Lake Storage Gen2 (ein Konto mit aktiviertem hierarchischem Namespace).

Warum: ADLS Gen2 ist für Big Data Analytics optimiert und kombiniert die Skalierbarkeit von Objektspeicher mit einem echten hierarchischen Dateisystem und POSIX-konformen ACLs für granulare Sicherheit.

Wählen Sie Speicherredundanz basierend auf gestuften Anforderungen: maximale Durabilität mit Lesezugriff, nur DR und Schutz vor Rechenzentrumsausfällen in der Region.

→1. Max. Durabilität/Lesezugriff: RA-GZRS. 2. Nur DR: GRS. 3. In der Region: ZRS.

Warum: Passen Sie die Redundanzoption an die spezifischen RPO/RTO- und Zugriffsanforderungen an. RA-GZRS ist die höchste Stufe. GRS ist nur für Failover. ZRS schützt vor Rechenzentrumsausfällen innerhalb einer Region.

Große strukturierte Daten in einem Data Warehouse und semistrukturierte Daten in einem Data Lake mithilfe einer vereinheitlichten Analyseplattform abfragen.

→Azure Synapse Analytics. Verwenden Sie einen dedizierten SQL-Pool für die strukturierten Daten und einen serverlosen SQL-Pool für Ad-hoc-Abfragen auf dem Data Lake.

Warum: Dieser hybride Ansatz optimiert sowohl Leistung als auch Kosten. Der dedizierte Pool bietet hohe Leistung für das verwaltete Data Warehouse, während der serverlose Pool den Pay-per-Query-Zugriff auf Rohdaten im Lake ermöglicht.

Eine Caching-Lösung für den Sitzungsstatus und Produktdaten, die >100 GB Arbeitsspeicher und Hochverfügbarkeit erfordert.

→Azure Cache for Redis Enterprise oder Premium-Stufe mit aktiviertem Clustering.

Warum: Clustering in den Premium/Enterprise-Tarifen ermöglicht es dem Cache, über die Speichergrenzen eines einzelnen Knotens hinaus zu skalieren, indem Daten über mehrere Knoten verteilt werden, was auch den Durchsatz verbessert.

Eine Datenbankarchitektur für eine SaaS-Anwendung, die Mandanten isoliert und gleichzeitig die Kosten für viele kleine, sprunghafte Workloads optimiert.

→Azure SQL Elastic Pools. Gruppieren Sie Mandanten in Pools, um Ressourcen zu teilen, mit dedizierten Datenbanken für große "Noisy Neighbor"-Mandanten.

Warum: Elastische Pools bieten die Kostenvorteile der Ressourcenfreigabe und erzwingen gleichzeitig Leistungsgrenzen pro Datenbank, wodurch ein Gleichgewicht zwischen dem Noisy-Neighbor-Problem und den hohen Kosten einer Datenbank pro Mandant hergestellt wird.

Eine komplexe lokale SQL Server-Datenbank, die Funktionen wie SQL Agent, datenbankübergreifende Abfragen und CLR verwendet, zu einem PaaS-Dienst migrieren.

→Azure SQL Managed Instance.

Warum: SQL Managed Instance bietet eine nahezu 100%ige Kompatibilität mit der lokalen SQL Server-Engine und unterstützt Instanz-Level-Funktionen, die Azure SQL Database nicht unterstützt. Dies ist ideal für Lift-and-Shift mit minimalen Codeänderungen.

Sicherstellen, dass alle Daten und vom Kunden verwalteten Verschlüsselungsschlüssel innerhalb einer bestimmten geografischen Grenze (z. B. der EU) verbleiben.

→Stellen Sie alle Ressourcen in Regionen innerhalb der Grenze bereit. Verwenden Sie eine Azure Policy mit dem "Allowed locations"-Effekt, um dies durchzusetzen. Speichern Sie kundenseitig verwaltete Schlüssel (CMK) in einem Azure Key Vault, der sich ebenfalls innerhalb der Grenze befindet.

Warum: Eine Kombination aus physischem Bereitstellungsort, richtlinienbasierter Durchsetzung und Schlüsselresidenz ist erforderlich, um strenge Datensouveränitätsvorschriften zu erfüllen.

Daten über eine hybride Datenlandschaft (Azure, On-Prem, andere Clouds) entdecken, klassifizieren und ihre Herkunft verfolgen.

→Microsoft Purview.

Warum: Purview bietet eine einheitliche Data Governance-Lösung mit automatisiertem Scanning, einem Business Glossary, Klassifizierung und Herkunftsverfolgung über eine Vielzahl von Datenquellen hinweg.

Daten (z. B. Finanzunterlagen) für einen definierten Aufbewahrungszeitraum in einem nicht löschbaren, nicht änderbaren (WORM) Zustand speichern.

→Azure Blob Storage mit einer zeitbasierten unveränderlichen Richtlinie für den Container, die dann gesperrt wird.

Warum: Gesperrte unveränderliche Richtlinien verhindern die Löschung oder Änderung von Blobs durch Benutzer, einschließlich Administratoren, bis die Aufbewahrungsfrist abläuft, wodurch strenge Compliance-Anforderungen erfüllt werden.

Entwerfen Sie eine DR-Lösung für eine Web-App (App Service + SQL DB) mit einem RPO von Minuten und einem RTO unter einer Stunde.

→Azure SQL-Datenbank-Auto-Failover-Gruppe, eine sekundäre App Service-Bereitstellung und Azure Front Door oder Traffic Manager für das Routing.

Warum: Dieses Muster adressiert DR für jede Ebene. Die SQL-Failover-Gruppe handhabt Datenreplikation und Failover. Der vorab bereitgestellte App Service vermeidet Bereitstellungsverzögerungen. Ein globaler Router (Front Door/Traffic Manager) leitet den Datenverkehr an die aktive Region weiter.

Das Composite SLA einer seriellen Anwendung (A -> B -> C) ist zu niedrig. Wie verbessern Sie es?

→Identifizieren Sie die Komponente mit dem niedrigsten individuellen SLA (das "schwächste Glied") und machen Sie sie redundant, indem Sie parallele Instanzen bereitstellen (z. B. über Regionen oder Zonen hinweg mit einem Load Balancer).

Warum: Das Composite SLA für eine serielle Kette wird durch Multiplikation der SLAs berechnet (SLA_A * SLA_B * SLA_C). Das Hinzufügen paralleler Instanzen zu einer Komponente verbessert deren effektives SLA, was den größten positiven Einfluss auf das Composite hat.

Die höchstmögliche Verfügbarkeit für VMs innerhalb einer einzelnen Azure-Region erreichen.

→Stellen Sie mehrere VMs über alle verfügbaren Verfügbarkeitszonen in der Region bereit.

Warum: Verfügbarkeitszonen sind physisch getrennte Rechenzentren mit unabhängiger Stromversorgung, Kühlung und Netzwerkinfrastruktur. Dies schützt vor Ausfällen auf Rechenzentrumsebene und bietet das höchste SLA innerhalb der Region von 99,99 %.

Eine Disaster Recovery-Lösung für lokale VMware- oder Hyper-V-Virtual Machines nach Azure bereitstellen.

→Azure Site Recovery (ASR). Konfigurieren Sie die Replikation nach Azure, erstellen Sie Wiederherstellungspläne für orchestriertes Failover und nutzen Sie Test-Failover für nicht-störende DR-Übungen.

Warum: ASR ist der speziell entwickelte Azure-Dienst für die DR-Replikation von lokalen (und Azure) VMs, der kontinuierliche Replikation, orchestrierte Wiederherstellung und isolierte Testmöglichkeiten bietet.

Die höchste Verfügbarkeit innerhalb der Region für Azure SQL-Datenbank mit null Datenverlust (RPO=0) und Lese-Skalierungsfunktion erreichen.

→Verwenden Sie den Business Critical-Diensttarif mit aktivierter Zonenredundanz.

Warum: Der Business Critical-Tarif verwendet eine Always On-Verfügbarkeitsgruppe mit synchroner Replikation über mehrere Replikate, was ein RPO von 0 ermöglicht. Die Zonenredundanz platziert Replikate in verschiedenen AZs für ein SLA von 99,995 %. Sie enthält ein lesbares sekundäres Replikat.

Eine globale Anwendung muss Benutzer aus der nächstgelegenen Region bedienen und automatisch und sofort ein Failover durchführen.

→Verwenden Sie ein aktiv-aktives Bereitstellungsmuster über mehrere Regionen hinweg mit Azure Front Door für latenzbasiertes Routing und Health-Probe-basiertes Failover.

Warum: Azure Front Door bietet globales Anycast-Routing zum Backend mit der geringsten Latenz. Seine Health-Probes erkennen regionale Ausfälle und leiten den Datenverkehr innerhalb von Sekunden automatisch zu gesunden Regionen um, was eine nahtlose aktiv-aktive Architektur ermöglicht.

Zustandsbehaftete Anwendungen auf AKS sichern, einschließlich Kubernetes-Objektdefinitionen und persistenter Volumendaten.

→Verwenden Sie Azure Backup für AKS.

Warum: Azure Backup für AKS ist die native Lösung, die eine integrierte, richtlinienbasierte Sicherung sowohl des Clusterzustands (etcd) als auch persistenter Volumendaten (über CSI-Snapshots) in einem sicheren, zentralisierten Backup Vault bietet.

Sichern Sie Backups vor versehentlicher oder böswilliger Löschung, auch durch Administratoren, zur Einhaltung gesetzlicher Vorschriften.

→Aktivieren Sie unveränderliche Tresore in Azure Backup oder dem Recovery Services-Tresor.

Warum: Unveränderlichkeit ist eine Einstellung auf Tresor-Ebene, die sicherstellt, dass Sicherungswiederherstellungspunkte, sobald sie erstellt wurden, vor ihrem Ablaufdatum von niemandem gelöscht werden können, was den höchsten Grad an Sicherungsschutz bietet.

Eine App Service Environment v3 (ASEv3) hostet eine kritische Anwendung in einer Region und erfordert eine DR-Lösung in einer anderen Region.

→Stellen Sie eine zweite ASEv3 in der DR-Region bereit. Verwenden Sie Azure Front Door für globales Load Balancing und Failover. Replizieren Sie Daten mit der entsprechenden Technologie (z. B. SQL-Auto-Failover-Gruppen).

Warum: ASEv3s sind regionale Bereitstellungen. Für DR müssen Sie eine zweite ASE bereitstellen und einen globalen Router wie Front Door verwenden, um den Datenverkehr zu verwalten. ASR wird nicht für App Service DR verwendet.

Entwerfen Sie ein skalierbares Netzwerk für ein Unternehmen mit zentralisierter Konnektivität (ExpressRoute/VPN), gemeinsam genutzten Diensten und Workload-Isolation.

→Eine Hub-Spoke-Topologie. Das Hub-VNet enthält das Gateway, die Azure Firewall und andere gemeinsame Dienste. Spoke-VNets enthalten Anwendungs-Workloads und sind mit dem Hub gepeert.

Warum: Dies ist das Standard- und empfohlene Unternehmensmuster. Es zentralisiert Sicherheit und Konnektivität, reduziert Kosten und Komplexität, während Spokes eine starke Workload-Isolation bieten.

Eine globale Webanwendung benötigt Layer-7-Lastverteilung, eine Web Application Firewall (WAF), SSL-Offloading und URL-basiertes Routing.

→Azure Front Door (Standard oder Premium).

Warum: Front Door ist ein modernes Cloud-CDN und ein globaler Lastverteiler, der diese Funktionen in einem einzigen Dienst integriert und eine bessere Leistung sowie eine einfachere Verwaltung bietet als die Kombination von Traffic Manager mit regionalen Application Gateways.

Entwerfen Sie einen produktionsreifen AKS-Cluster für mehrere Teams mit unterschiedlichen Workload-Typen (CPU-, GPU-, speicherintensive).

→Verwenden Sie einen dedizierten Systemknotenpool und mehrere Benutzerknotenpools mit verschiedenen VM-SKUs (z. B. F-Serie für CPU, E-Serie für Arbeitsspeicher, N-Serie für GPU). Verwenden Sie den Cluster-Autoscaler und aktivieren Sie den Standard/Premium-Tarif für das Uptime-SLA.

Warum: Mehrere Knotenpools ermöglichen die Zuordnung der richtigen Hardware zur richtigen Workload für Leistung und Kosteneffizienz. Die Trennung von System-Pods verbessert die Stabilität. Der Standard/Premium-Tarif ist für ein finanziell abgesichertes SLA erforderlich.

Ein ereignisgesteuerter serverloser Workflow erfordert Ausführungszeiten, die länger als das 10-Minuten-Limit des Functions Consumption Plans sind.

→Verwenden Sie Azure Functions auf einem Premium-Plan oder einem App Service-Plan, oder verwenden Sie Azure Durable Functions für die Orchestrierung.

Warum: Der Premium-Plan unterstützt Ausführungszeiten von bis zu 60 Minuten (standardmäßig 30) und vermeidet Kaltstarts. Durable Functions sind ideal für die Orchestrierung lang laufender, zustandsbehafteter Workflows, die menschliche Interaktion oder lange Wartezeiten beinhalten können.

Wählen Sie einen Messaging-Dienst für ein Fan-Out-Ereignisbenachrichtigungssystem im Vergleich zu einem zuverlässigen, geordneten Befehlsverarbeitungssystem.

→Verwenden Sie Azure Event Grid für Fan-Out, reaktive Eventing. Verwenden Sie Azure Service Bus Queues (mit Sitzungen zur Sortierung) für zuverlässige, transaktionale Befehlsverarbeitung.

Warum: Event Grid ist ein leichter, push-basierter Ereignisrouting-Dienst, der für reaktive Programmierung optimiert ist. Service Bus ist ein robuster Message Broker mit Funktionen wie FIFO (Sitzungen), Dead-Lettering und Transaktionen für Unternehmens-Messaging.

Eine API, die in einem privaten VNet läuft, sicher externen Partnern zugänglich machen, mit Richtlinien für Ratenbegrenzung und Authentifizierung.

→Azure API Management (APIM) im internen VNet-Modus bereitstellen, vorgelagert durch ein Azure Application Gateway mit WAF für den öffentlichen Ingress.

Warum: Dieses Muster bietet Defense-in-Depth. APIM im VNet kann auf das private Backend zugreifen. Das App Gateway beendet SSL, inspiziert den Datenverkehr mit WAF und leitet ihn an die private APIM-Instanz weiter. APIM-Richtlinien handhaben Authentifizierung, Ratenbegrenzungen usw.

Hunderte von Zweigstellen und VNets global mit automatisierter Any-to-Any-Konnektivität verbinden.

→Azure Virtual WAN.

Warum: Virtual WAN ist die verwaltete Microsoft-Lösung für großflächige, globale Transit-Netzwerke. Es automatisiert komplexe Routings und bietet einen einheitlichen Hub für die Verbindung von VPN-, ExpressRoute- und VNet-Spokes.

Einen groß angelegten, parallelen Batch-Job (z. B. CFD-Simulation) ausführen, der Tausende von Kernen und MPI-Kommunikation mit geringer Latenz erfordert.

→Azure Batch mit einem Pool von InfiniBand-fähigen VMs (z. B. HB-Serie) unter Verwendung von Low-Priority (Spot)-Preisen.

Warum: Azure Batch ist ein Job-Scheduler, der für HPC entwickelt wurde. InfiniBand-fähige VMs bieten die hohe Durchsatz-, niedrige Latenz-RDMA-Netzwerkkonfiguration, die für MPI erforderlich ist. VMs mit niedriger Priorität reduzieren die Kosten für fehlertolerante Workloads drastisch.

Eine Anwendung in einem VNet muss auf PaaS-Dienste (SQL, Storage) zugreifen, ohne dass der Datenverkehr das öffentliche Internet durchquert.

→Erstellen Sie private Endpunkte für die PaaS-Dienste. Dies gibt dem Dienst eine private IP-Adresse innerhalb Ihres VNets.

Warum: Private Endpunkte sind die sicherste Methode für private PaaS-Konnektivität. Sie stellen sicher, dass der Datenverkehr im Microsoft-Backbone verbleibt und ermöglichen es Ihnen, den öffentlichen Endpunkt des PaaS-Dienstes vollständig zu deaktivieren.

Eine moderne Single-Page Application (SPA) mit einem serverlosen API-Backend, CI/CD-Integration und einer benutzerdefinierten Domäne hosten.

→Azure Static Web Apps.

Warum: Dies ist ein speziell entwickelter, optimierter Dienst für genau dieses Muster. Er kombiniert statisches Content-Hosting, integrierte Azure Functions für die API, GitHub/Azure DevOps-Integration und verwaltete benutzerdefinierte Domänen mit kostenlosen SSL-Zertifikaten.

Server, die lokal und in anderen Clouds (z. B. AWS) laufen, von Azure aus verwalten und Governance (Azure Policy) anwenden.

→Installieren Sie den Azure Arc-Agent auf den Nicht-Azure-Servern, um sie als Azure Arc-fähige Server zu projizieren.

Warum: Azure Arc erweitert die Azure-Steuerungsebene auf jede Infrastruktur. Sobald ein Server Arc-fähig ist, kann er mit Azure Policy, Monitor, Defender for Cloud usw. verwaltet werden, genau wie eine native Azure VM.

Funktionalität schrittweise von einer monolithischen Altanwendung zu neuen Microservices migrieren, ohne eine "Big Bang"-Umstellung.

→Wenden Sie das Strangler Fig-Muster mit einem Reverse Proxy wie Azure API Management oder Application Gateway an.

Warum: Der Reverse Proxy fängt Aufrufe an den Monolithen ab und leitet den Datenverkehr für bestimmte Funktionen selektiv an die neuen Microservices weiter. Mit der Zeit "erdrosselt" der Proxy den Monolithen, indem er immer mehr Datenverkehr umleitet, bis das alte System außer Betrieb genommen werden kann.

VMs befinden sich in einem VNet mit erzwungenem Tunneling (der gesamte Internetverkehr wird lokal geroutet), können aber nicht auf Azure PaaS-Dienste zugreifen.

→Erzwungenes Tunneling unterbricht den direkten Zugriff auf öffentliche Azure-Endpunkte. Verwenden Sie Dienst-Endpunkte oder private Endpunkte für den PaaS-Zugriff. Alternativ können Sie UDRs für bestimmte Azure-Dienst-Tags mit einem Next Hop von "Internet" hinzufügen, um den Tunnel zu umgehen.

Warum: PaaS-Dienste haben öffentliche Endpunkte. Erzwungenes Tunneling leitet diesen Datenverkehr lokal weiter. Sie müssen einen Ausnahme-Pfad erstellen, entweder indem Sie den PaaS-Dienst privat machen (Endpunkte) oder indem Sie spezifische Routing-Ausnahmen erstellen (UDRs mit Dienst-Tags).

Ein Hub-Spoke-Netzwerk muss lokale DNS-Namen von Azure und private Azure DNS-Zonen von lokal auflösen können.

→Stellen Sie Azure DNS Private Resolver im Hub-VNet bereit. Konfigurieren Sie einen Inbound-Endpunkt, damit lokale Systeme Azure DNS auflösen können, und einen Outbound-Endpunkt mit Weiterleitungsregelwerken, um lokale DNS-Namen von Azure aus aufzulösen.

Warum: Dies ist die moderne PaaS-Lösung für die hybride DNS-Auflösung, die die Notwendigkeit, benutzerdefinierte DNS-Server-VMs zu verwalten, ersetzt. Sie integriert sich nativ mit privaten DNS-Zonen und lokalen DNS-Forwardern.

Mehrere VNets benötigen eine vorhersagbare, statische öffentliche IP für den gesamten ausgehenden Datenverkehr zur Whitelisting durch externe Dienste.

→In einer Hub-Spoke-Topologie leiten Sie den gesamten ausgehenden Datenverkehr (0.0.0.0/0) von Spokes durch eine Azure Firewall oder ein NAT Gateway im Hub-VNet.

Warum: Die Zentralisierung des ausgehenden Datenverkehrs im Hub stellt sicher, dass der gesamte ausgehende Datenverkehr die öffentlichen IPs der Hub-Firewall/des NAT Gateways verwendet, was die Verwaltung und externe Whitelisting vereinfacht. NAT Gateway ist einfacher für reines SNAT, während Firewall Sicherheitsinspektionen hinzufügt.

Hochsensible Daten so verarbeiten, dass sie selbst während der Nutzung im Arbeitsspeicher verschlüsselt sind, um sie vor dem Cloud-Betreiber zu schützen.

→Verwenden Sie Azure Confidential Computing VMs (DCsv3/ECsv3-Serien) mit Intel SGX oder AMD SEV-SNP, um Code in einer hardwarebasierten Trusted Execution Environment (TEE) oder verschlüsseltem Speicher auszuführen.

Warum: Confidential Computing adressiert die Säule "Daten in Verwendung" der Sicherheit, was traditionelle Verschlüsselung im Ruhezustand und während der Übertragung nicht tun. Es bietet überprüfbare Isolation auf Hardware-Ebene.

Ein SaaS-Anbieter muss seinen Dienst, der in seinem VNet läuft, einem Kunden in dessen VNet vollständig über das private Azure-Netzwerk zugänglich machen.

→Der Anbieter erstellt einen Azure Private Link Service auf seinem Standard Load Balancer. Der Kunde erstellt einen Private Endpoint in seinem VNet, der sich mit dem Dienst verbindet.

Warum: Private Link ist das definitive Muster für die sichere, private, mandantenübergreifende Dienstbereitstellung. Es vermeidet die Exposition gegenüber dem öffentlichen Internet, IP-Überlappungsprobleme und komplexe VNet-Peering-Konfigurationen.