Zum Inhalt

Was du bekommst: ein Spoke

Ein Spoke ist dein Produkt auf der Plattform: eine Azure subscription für einen Workload in einer Umgebung, für dich eingerichtet und angebunden.

Pro Spoke

Du erhältst Details
Eine subscription Auf den vereinbarten Namen umbenannt (zum Beispiel sub-app1-dev), mit Tags versehen und in der richtigen management group platziert (zum Beispiel corp für interne Workloads, online für internetfähige)
Ein Netzwerk Ein virtuelles Netzwerk mit den angefragten Subnets, NSGs und Route Tables, verbunden mit dem hub. Der DNS zeigt auf den zentralen DNS-Resolver, sodass private endpoints automatisch aufgelöst werden.
Ausgehender Internetverkehr über die zentrale firewall Standardmäßig läuft der Internetverkehr über die hub-firewall. Nur Ziele mit einer Firewallregel sind erlaubt.
Zugriffsgruppen Vier Entra-ID-Gruppen: …_Owners, …_Contributors, …_Readers, …_Support. Die bestehende Gruppe deines Teams wird Mitglied, entweder direkt oder über PIM (Just-in-Time).
Ein Service Principal SPN-SPOKE-<workload>-<env> mit Owner auf der subscription, für deine eigenen Deployment-pipelines. Sein Secret liegt in deinem Key Vault, oder er nutzt Federated Credentials. Wie Credentials funktionieren: Spoke canvas.
Ein Key Vault RBAC-Modus, private endpoint (standardmäßig aktiv)
Ein Storage Account Customer-managed Key, private endpoint (standardmäßig aktiv)
Ein Log Analytics workspace Für deine eigenen Logs und Alerts (standardmäßig aktiv)
Optional: ein Azure DevOps Repository und eine Service Connection Auf Anfrage
Optional: Managed virtuelle Maschinen Falls deine Plattform das Managed-VM-Modul anbietet (Managed virtuelle Maschinen)
Optional: eine Daten-, Integrations-, KI- oder Kubernetes-Plattform Falls deine Plattform eine bietet: Base Fabric Data Platform, Integration Platform, KI-Plattform oder AKS Platform
Optional: ein Developer Portal Falls deine Plattform es bietet: das Agentic Developer Portal mit deinen Workloads, Kosten- und Security-Ansichten und KI-Agents
Optional: Shared Services Zugriff auf Shared APIM, ACR, Service Bus oder Event Hub, falls deine Plattform sie bietet

Von der Plattform, für jeden Spoke

Enthalten Was das für dich bedeutet
Security-Baseline Azure-Policy-initiatives (ISO 27001, CIS, Microsoft Cloud Security Benchmark, NIS2) bewerten deine Ressourcen. Einige Policies blockieren nicht konforme Deployments.
Zentraler DNS private endpoints werden per Policy in den zentralen Private DNS zones registriert.
Monitoring-Baseline Azure Monitor Baseline Alerts für Plattformkomponenten; Service Health alerts.
Defender for Cloud Falls auf deiner Plattform für Spokes aktiviert.
Optionale Veröffentlichung Eingehender Web-Verkehr über das zentrale Application Gateway mit WAF, auf Anfrage.
Optionale Hybrid-Konnektivität Zugriff auf On-Premises-Netzwerke über das hub-VPN oder ExpressRoute, mit Firewallregeln.

Spoke-Varianten

Variante Was es ist
Standard-Spoke Der oben beschriebene Standard
Sandbox Eine subscription für Experimente, ohne Verbindung zum hub, zu anderen Workloads oder zu internen Netzwerken. Keine Spoke-Ressourcen. Siehe Neue Sandbox-subscription.
Managed Spoke Ein Standard-Spoke, bei dem das Plattform-Team auch die Ressourcen deines Workloads baut und pflegt, im Rahmen einer separaten Vereinbarung. Geeignet für Teams, die Azure noch lernen oder zu klein sind, um den Workload technisch zu betreiben. Siehe Service-Typen und Managed Spokes.

Dein Workload

Ein Workload ist deine Business-Lösung aus Sicht der Plattform: der Owner, die Gruppen, optional ein Projekt in Azure DevOps und die Spokes für jede Umgebung. Ein Workload hat normalerweise einen Spoke für Produktionsdaten und einen oder mehrere Spokes für Nicht-Produktionsdaten. Siehe Architekturreferenz.

Umgebungen

Normalerweise erhältst du einen Spoke pro Umgebung, zum Beispiel:

Umgebung Verwendung
dev Entwicklung und Experimente
tst Test
acc Abnahme, produktionsähnlich
prd Produktion. Nur hier darfst du Produktionsdaten verarbeiten.
shared Gemeinsame Komponenten, die von mehreren Umgebungen genutzt werden

Jede Umgebung ist eine eigene subscription mit eigenem Netzwerkbereich, eigenen Gruppen und eigenem Key Vault.

Policies können sich je Umgebung unterscheiden

Üblich ist, die Security-initiatives in dev und tst als Audit zuzuweisen, sodass du die Compliance siehst, ohne blockiert zu werden, und in acc und prd als Deny. Prüfe die Compliance in den unteren Umgebungen regelmäßig und behebe Probleme, bevor du promotest. Frag dein Plattform-Team, welcher Effekt wo gilt (Policy und Ausnahmen).

Baseline-Ressourcen sind für die Baseline da

Der Key Vault, der Storage Account und der Log Analytics workspace der Baseline unterstützen den Spoke selbst. Frag dein Plattform-Team, wofür der Storage Account gedacht ist (auf manchen Plattformen enthält er die state-Dateien deiner Infrastructure as Code), bevor du Anwendungsdaten darin ablegst. Deploye Storage für deine Anwendung mit deinem eigenen Code, zusammen mit dem Rest deiner Infrastruktur. Aktiviere einen private endpoint für eine Baseline-Ressource nur, wenn du sie nutzt.

Nicht enthalten