Architectuurreferentie¶
Deze pagina beschrijft hoe het Managed Cloud Platform (MCP) als geheel is georganiseerd: de lagen, de technologiedomeinen, de hiërarchie van management groups en de manier waarop hub en spokes in elkaar passen. Ze legt het waarom uit. Voor de exacte resources, layers en het gedrag van Terraform, zie Platform.
Het platform bestaat om workload teams een fundament te geven dat:
- secure by design is,
- zeer beschikbaar is,
- performant en voorspelbaar is,
- wendbaar en schaalbaar is,
- zoveel mogelijk gestandaardiseerd en geautomatiseerd is.
Teams krijgen wat ze nodig hebben via automatisering of self-service, zodat ze hun tijd kunnen besteden aan de workload en niet aan de algemene voorzieningen eromheen.
Drie lagen¶
Een workload is opgebouwd uit drie lagen. Elke laag heeft een eigen eigenaar.
| Laag | Wat het is | Wie is eigenaar |
|---|---|---|
| Microsoft Azure | De ruwe services: connectiviteit, security, storage, compute | Microsoft |
| Het platform (landing zone) | Een beheerlaag over Azure die de omgeving compliant houdt, de kosten beheersbaar houdt en kant-en-klare services aanbiedt: hub, policies, spoke-baseline | Het platformteam (XMMS of je eigen team) |
| De workload | De bedrijfsoplossing zelf: datgene wat waarde creëert voor de organisatie | Het workload team (afnemer) |
Doordat de workload op het platform is gebouwd, hoeft het workload team de algemene eisen (netwerkisolatie, centrale logging, baseline policies) niet opnieuw op te lossen. Zie Verantwoordelijkheden voor de exacte verdeling.
Technologiedomeinen¶
Het platform combineert vijf technologiedomeinen. Zie ze als de nutsvoorzieningen die nodig zijn om een bedrijfsoplossing te laten draaien.
| Domein | Wat het omvat | Typische technologie |
|---|---|---|
| Identity and access management | Identificatie, authenticatie, autorisatie en verantwoording | Microsoft Entra ID, Privileged Identity Management (PIM) |
| Infrastructuur | Fysieke en virtuele infrastructuur en de softwarecomponenten eromheen | Azure Virtual WAN, Azure Firewall, virtual machines en andere native Azure-resources |
| Security | Bescherming tegen, en weerbaarheid tegen, schade door anderen | Microsoft Defender for Cloud en, optioneel, Microsoft Sentinel |
| Development | Infrastructure as code, gebouwd en uitgerold via pipelines | Azure DevOps of GitHub, Terraform, de Xebia.Mcp-module |
| Governance | Het geheel consistent houden: besluitvorming, afdwingen van policies, uitzonderingenbeheer, compliancemonitoring en rapportage | Azure Policy, management groups, tags, het besluitvormingsproces in Governance |
Het platformteam levert de beheerlaag boven op deze domeinen: de automatisering die ze configureert, en de self-service-ingangen (standaardwijzigingen).
Hiërarchie van management groups¶
De management group-boom geeft een hiërarchie voor toegangsbeheer (RBAC), policy en tags, en isoleert delen van de omgeving van elkaar. Een gangbaar ontwerp heeft deze niveaus:
| Niveau | Doel |
|---|---|
| 1. Tenant root | Door Azure aangemaakt bij elke Entra ID-tenant. Alles hangt eronder. |
| 2. Landing zone (organisatie) | Scheidt dit platform van andere landing zones in dezelfde tenant. Normaal heb je er één. Een tweede kan nodig zijn, bijvoorbeeld wanneer een extern beheerd platform in dezelfde tenant moet leven: het is dan volledig geïsoleerd van de rest. |
| 3. Gebruikstype (canary / productie) | Het platform is infrastructure as code, dus nieuwe code moet worden getest voordat die productie bereikt. Een kopie van de code en, waar nodig, van de hiërarchie wordt gebruikt voor canary. |
| 4. Platformgebied | Scheidt workloads die andere policies, tags en toegang nodig hebben (zie hieronder). |
| 5. Subtype | Staat kleine verschillen in policy of toegang binnen één gebied toe, bijvoorbeeld corp en online onder landing zones. |
| 6. Workload / spoke | De subscriptions van een workload. |
De gebieden op niveau 4:
| Gebied | Bevat |
|---|---|
| Platform | De eigen subscriptions van het platform (management, connectivity, identity) en shared services. Policies mogen soepeler zijn waar een platformresource dat vereist. |
| Landing zones | Alle bedrijfsworkloads. Corp is voor interne workloads, online voor workloads met internetblootstelling; door deze splitsing kun je de corp-spokes isoleren van internettoegang. |
| Shared | Gedeelde componenten die door meerdere workloads worden gebruikt |
| Sandbox | Subscriptions voor experimenten. Standaard geïsoleerd: geen connectiviteit met andere workloads of met interne resources. |
| Decommissioned | Een prullenbak. Subscriptions die uit productie zijn gehaald, worden hierheen verplaatst voordat ze worden opgezegd. |
De boom die MCP aanmaakt, staat in Platform.
Waar de hiërarchie voor wordt gebruikt¶
| Mechanisme | Hoe het wordt gebruikt |
|---|---|
| Toegangsbeheer | Entra ID-groepen krijgen Azure-rollen op management groups, subscriptions of resources. Zie Identiteits- en toegangsmodel. |
| Azure Policy | Standaarden worden afgedwongen en compliance wordt op schaal beoordeeld, met remediation voor bestaande en nieuwe resources. Typisch gebruik: toegestane regio's, consistente tags, diagnostic logs naar Log Analytics. |
| Microsoft Defender for Cloud | Securitypolicies en regelgevingsinitiatives worden toegepast door een subscription onder de juiste management group te plaatsen. |
| Tags | Key-value-metadata voor kostentoewijzing, eigenaarschap en automatisering. Zie Naamgeving en tags. |
| Management groups | Containers die de bovenstaande policy- en RBAC-toewijzingen in één keer naar veel subscriptions brengen. |
Hub en spokes¶
Het netwerk is een hub-and-spoke-ontwerp. Verkeer tussen spokes, naar on-premises netwerken en naar het internet loopt altijd via de hub, waar het kan worden geïnspecteerd en geautoriseerd.
- De hub biedt de gedeelde services: connectiviteit, firewalling, DNS, monitoring en governance.
- Een spoke is een geïsoleerde subscription die één workload in één omgeving host.
- In een secured virtual hub (Virtual WAN met Azure Firewall) is de routering via de firewall geautomatiseerd, dus spokes hebben daarvoor geen eigen user-defined routes nodig.
Zie Servicetypes voor wat de hub aanbiedt en DNS-ontwerp voor naamresolutie. Wat het platform in een spoke bouwt, staat beschreven in Spoke canvas, en waarom een spoke zijn subscription uit een provisioningstap krijgt en niet uit een pool, staat in Subscription provisioning.
Een workload en zijn spokes¶
Een workload identificeert, isoleert en geeft eigenaarschap aan één bedrijfsoplossing. Het is de top van een hiërarchie:
- de Entra ID-groepen en rollen van het team (Identiteits- en toegangsmodel),
- optioneel een project in Azure DevOps,
- één spoke per omgeving, normaal gesproken één voor productiedata en de andere voor niet-productiedata.
Spoke-varianten (standaard, sandbox, managed) worden beschreven in Servicetypes.
Opzet van het IP-plan¶
Alle adresbereiken komen uit één centraal IP-plan, omdat overlappende bereiken de routering breken. Een werkbare opzet is om per Azure-regio één groot blok te reserveren en dat naar doel te verdelen:
| Blok | Gebruik |
|---|---|
| Hub, per platformomgeving (prod, canary) | Connectiviteit (virtual hub, Bastion, build agents, DNS resolver, gateways), management- en identiteitsnetwerken |
| Gereserveerd binnen de hub | Ruimte om te groeien, bijvoorbeeld voor client-adrespools van een point-to-site VPN |
| Sandbox | Een geïsoleerd bereik voor sandbox-subscriptions |
| Workload-spokes | Het grootste deel van het blok, uitgegeven per spoke (een /24 is een gangbare standaard) |
| Core IT / speciale doeleinden | Bereiken voor systemen die aan het platform grenzen |
Houd het plan op één plek
Houd het plan bij als document of tabel in de repository naast de configuratie, en werk het bij in dezelfde pull request die een spoke of regio toevoegt. Vraag je netwerkteam welke bereiken on-premises al gebruikt.
Gerelateerd: Plan je IP-range en subnets en Een regio toevoegen.