Architekturreferenz¶
Diese Seite beschreibt, wie die Managed Cloud Platform (MCP) als Ganzes organisiert ist: die Ebenen, die Technologiedomänen, die Hierarchie der management groups und das Zusammenspiel von hub und spokes. Sie erklärt das Warum. Die genauen Ressourcen, layers und das Terraform-Verhalten stehen unter Plattform.
Die Plattform soll Workload-Teams ein Fundament geben, das:
- secure by design ist,
- hochverfügbar ist,
- performant und vorhersagbar ist,
- agil und skalierbar ist,
- so weit wie möglich standardisiert und automatisiert ist.
Teams bekommen, was sie brauchen, über Automatisierung oder Self-Service, damit sie ihre Zeit in den Workload investieren können und nicht in die allgemeine Basisinstallation drumherum.
Drei Ebenen¶
Ein Workload ist auf drei Ebenen aufgebaut. Jede Ebene hat ihren eigenen Owner.
| Ebene | Was es ist | Wem sie gehört |
|---|---|---|
| Microsoft Azure | Die Rohdienste: Konnektivität, Security, Storage, Compute | Microsoft |
| Die Plattform (landing zone) | Ein Management-Overlay auf Azure, das die Umgebung compliant hält, die Kosten im Griff behält und einsatzfertige Dienste bietet: hub, Policies, Spoke-Baseline | Das Plattform-Team (XMMS oder dein eigenes Team) |
| Der Workload | Die Business-Lösung selbst: das, was für die Organisation Wert schafft | Das Workload-Team (Nutzer) |
Weil der Workload auf der Plattform aufbaut, muss das Workload-Team die allgemeinen Anforderungen (Netzwerkisolation, zentrales Logging, Baseline-Policies) nicht erneut lösen. Die genaue Aufteilung steht unter Verantwortlichkeiten.
Technologiedomänen¶
Die Plattform kombiniert fünf Technologiedomänen. Stell sie dir als die Versorgungsleistungen vor, die man braucht, um eine Business-Lösung zu betreiben.
| Domäne | Was sie abdeckt | Typische Technologie |
|---|---|---|
| Identity and Access Management | Identifikation, Authentifizierung, Autorisierung und Nachvollziehbarkeit | Microsoft Entra ID, Privileged Identity Management (PIM) |
| Infrastruktur | Physische und virtuelle Infrastruktur und die Softwarekomponenten drumherum | Azure Virtual WAN, Azure Firewall, virtuelle Maschinen und andere native Azure-Ressourcen |
| Security | Schutz vor Schaden durch andere und Widerstandsfähigkeit dagegen | Microsoft Defender for Cloud und optional Microsoft Sentinel |
| Entwicklung | Infrastructure as Code, gebaut und deployt über pipelines | Azure DevOps oder GitHub, Terraform, das Xebia.Mcp module |
| Governance | Das Ganze konsistent halten: Entscheidungen, Durchsetzung von Policies, Ausnahmeverwaltung, Compliance-Überwachung und Reporting | Azure Policy, management groups, Tags, der Entscheidungsprozess unter Governance |
Das Plattform-Team stellt das Management-Overlay über diesen Domänen bereit: die Automatisierung, die sie konfiguriert, und die Self-Service-Einstiegspunkte (Standardänderungen).
Hierarchie der management groups¶
Der Baum der management groups bietet eine Hierarchie für Zugriffskontrolle (RBAC), Policies und Tags und isoliert Teile der Umgebung voneinander. Ein gängiges Design hat diese Ebenen:
| Ebene | Zweck |
|---|---|
| 1. Tenant root | Wird von Azure mit jedem Entra-ID-Tenant erstellt. Alles liegt darunter. |
| 2. Landing zone (Organisation) | Trennt diese Plattform von anderen landing zones im selben Tenant. Normalerweise hast du eine. Eine zweite kann nötig sein, zum Beispiel wenn eine extern verwaltete Plattform im selben Tenant leben muss: Sie ist dann von den anderen vollständig isoliert. |
| 3. Nutzungsart (canary / Produktion) | Die Plattform ist Infrastructure as Code, daher muss neuer Code getestet werden, bevor er die Produktion erreicht. Eine Kopie des Codes und, wo nötig, der Hierarchie wird für canary verwendet. |
| 4. Plattformbereich | Trennt Workloads, die unterschiedliche Policies, Tags und Zugriffe brauchen (siehe unten). |
| 5. Subtyp | Erlaubt kleine Unterschiede bei Policy oder Zugriff innerhalb eines Bereichs, zum Beispiel corp und online unter landing zones. |
| 6. Workload / Spoke | Die subscriptions eines Workloads. |
Die Bereiche auf Ebene 4:
| Bereich | Enthält |
|---|---|
| Platform | Die eigenen subscriptions der Plattform (management, connectivity, identity) und Shared Services. Policies können weniger restriktiv sein, wo eine Plattformressource es erfordert. |
| Landing zones | Alle Business-Workloads. Corp ist für interne Workloads, online für internetfähige; durch die Trennung lassen sich die corp-Spokes vom Internetzugriff isolieren. |
| Shared | Gemeinsame Komponenten, die von mehreren Workloads genutzt werden |
| Sandbox | subscriptions für Experimente. Standardmäßig isoliert: keine Konnektivität zu anderen Workloads oder internen Ressourcen. |
| Decommissioned | Ein Papierkorb. subscriptions, die aus der Produktion genommen wurden, werden hierher verschoben, bevor sie gekündigt werden. |
Den Baum, den MCP erstellt, zeigt Plattform.
Wofür die Hierarchie verwendet wird¶
| Mechanismus | Wie er verwendet wird |
|---|---|
| Zugriffskontrolle | Entra-ID-Gruppen erhalten Azure-Rollen auf management groups, subscriptions oder Ressourcen. Siehe Identitäts- und Zugriffsmodell. |
| Azure Policy | Standards werden durchgesetzt und die Compliance wird im großen Maßstab bewertet, mit Remediation für bestehende und neue Ressourcen. Typische Anwendungen: erlaubte Regionen, konsistente Tags, Diagnoselogs nach Log Analytics. |
| Microsoft Defender for Cloud | Security-Policies und regulatorische initiatives werden angewendet, indem eine subscription unter die richtige management group gelegt wird. |
| Tags | Key-Value-Metadaten für Kostenzuordnung, Ownership und Automatisierung. Siehe Namensgebung und Tags. |
| Management groups | Container, die die obigen Policy- und RBAC-Zuweisungen auf viele subscriptions gleichzeitig übertragen. |
Hub und Spokes¶
Das Netzwerk ist ein Hub-and-Spoke-Design. Verkehr zwischen Spokes, zu On-Premises-Netzwerken und ins Internet läuft immer über den hub, wo er geprüft und autorisiert werden kann.
- Der hub bietet die gemeinsamen Dienste: Konnektivität, Firewalling, DNS, Monitoring und Governance.
- Ein Spoke ist eine isolierte subscription, die einen Workload in einer Umgebung hostet.
- In einem secured virtual hub (Virtual WAN mit Azure Firewall) ist das Routing über die firewall automatisiert, sodass Spokes dafür keine eigenen User-defined Routes brauchen.
Was der hub bietet, steht unter Service-Typen, die Namensauflösung unter DNS-Design. Was die Plattform innerhalb eines spoke aufbaut, beschreibt Spoke canvas, und warum ein spoke seine subscription aus einem Provisioning-Schritt erhält und nicht aus einem Pool, steht unter Subscription-Provisioning.
Ein Workload und seine Spokes¶
Ein Workload identifiziert, isoliert und weist die Ownership einer Business-Lösung zu. Er steht an der Spitze einer Hierarchie:
- die Entra-ID-Gruppen und -Rollen des Teams (Identitäts- und Zugriffsmodell),
- optional ein Projekt in Azure DevOps,
- ein Spoke pro Umgebung, normalerweise einer für Produktionsdaten und die anderen für Nicht-Produktionsdaten.
Spoke-Varianten (Standard, Sandbox, Managed) sind unter Service-Typen beschrieben.
Struktur des IP-Plans¶
Alle Adressbereiche stammen aus einem zentralen IP-Plan, weil sich überschneidende Bereiche das Routing kaputt machen. Eine praktikable Struktur ist, pro Azure-Region einen großen Block zu reservieren und ihn nach Verwendungszweck aufzuteilen:
| Block | Verwendung |
|---|---|
| Hub, pro Plattform-Umgebung (prod, canary) | Konnektivität (virtual hub, Bastion, Build-Agents, DNS Resolver, Gateways), Management- und Identity-Netzwerke |
| Im hub reserviert | Platz zum Wachsen, zum Beispiel für Client-Adresspools eines Point-to-Site-VPN |
| Sandbox | Ein isolierter Bereich für Sandbox-subscriptions |
| Workload-Spokes | Der Hauptteil des Blocks, pro Spoke vergeben (ein /24 ist ein üblicher Default) |
| Core IT / Sonderzwecke | Bereiche für plattformnahe Systeme |
Halte den Plan an einer Stelle
Führe den Plan als Dokument oder Tabelle im Repository neben der Konfiguration und aktualisiere ihn im selben pull request, der einen Spoke oder eine Region hinzufügt. Frag dein Netzwerkteam, welche Bereiche On-Premises bereits verwendet.
Siehe auch: IP-Bereich und Subnets planen und Region hinzufügen.