Architecture Reference¶

This page describes how the Managed Cloud Platform (MCP) is organised as a whole: the layers, the technology domains, the management group hierarchy and the way hub and spokes fit together. It explains the why. For the exact resources, layers and Terraform behaviour, see Platform.

The platform exists to give workload teams a foundation that is:

secure by design,
highly available,
performant and predictable,
agile and scalable,
standardised and automated as much as possible.

Teams get what they need through automation or self-service, so they can spend their time on the workload and not on the common plumbing around it.

Three layers¶

A workload is built on three layers. Each layer has its own owner.

Layer	What it is	Who owns it
Microsoft Azure	The raw services: connectivity, security, storage, compute	Microsoft
The platform (landing zone)	A management overlay on Azure that keeps the environment compliant, keeps cost in check and offers ready-to-use services: hub, policies, spoke baseline	The platform team (XMMS or your own team)
The workload	The business solution itself: the thing that creates value for the organisation	The workload team (consumer)

Because the workload is built on the platform, the workload team does not have to solve the generic requirements (network isolation, central logging, baseline policies) again. See Responsibilities for the exact split.

Technology domains¶

The platform combines five technology domains. Think of them as the utilities needed to run a business solution.

Domain	What it covers	Typical technology
Identity and access management	Identification, authentication, authorisation and accountability	Microsoft Entra ID, Privileged Identity Management (PIM)
Infrastructure	Physical and virtual infrastructure and the software components around it	Azure Virtual WAN, Azure Firewall, virtual machines and other native Azure resources
Security	Protection against, and resilience to, harm from others	Microsoft Defender for Cloud and, optionally, Microsoft Sentinel
Development	Infrastructure as code, built and deployed through pipelines	Azure DevOps or GitHub, Terraform, the `Xebia.Mcp` module
Governance	Keeping the whole consistent: decisions, policy enforcement, exception management, compliance monitoring and reporting	Azure Policy, management groups, tags, the decision process in Governance

The platform team provides the management overlay on top of these domains: the automation that configures them, and the self-service entry points (standard changes).

Management group hierarchy¶

The management group tree gives a hierarchy for access control (RBAC), policy and tags, and isolates parts of the environment from each other. A common design has these levels:

Level	Purpose
1. Tenant root	Created by Azure with every Entra ID tenant. Everything is below it.
2. Landing zone (organisation)	Separates this platform from other landing zones in the same tenant. Normally you have one. A second can be needed, for example when an externally managed platform must live in the same tenant: it is then fully isolated from the others.
3. Usage type (canary / production)	The platform is infrastructure as code, so new code must be tested before it reaches production. A copy of the code and, where needed, of the hierarchy is used for canary.
4. Platform area	Separates workloads that need different policies, tags and access (see below).
5. Subtype	Allows small differences in policy or access inside one area, for example corp and online under landing zones.
6. Workload / spoke	The subscriptions of a workload.

The areas on level 4:

Area	Contains
Platform	The platform's own subscriptions (management, connectivity, identity) and shared services. Policies may be less restrictive where a platform resource requires it.
Landing zones	All business workloads. Corp is for internal workloads, online for internet-facing ones; the split lets you isolate the corp spokes from internet access.
Shared	Shared components used by several workloads
Sandbox	Subscriptions for experiments. Isolated by default: no connectivity to other workloads or to internal resources.
Decommissioned	A recycle bin. Subscriptions that left production are moved here before they are cancelled.

The tree that MCP creates is shown in Platform.

What the hierarchy is used for¶

Mechanism	How it is used
Access control	Entra ID groups get Azure roles on management groups, subscriptions or resources. See Identity and access model.
Azure Policy	Standards are enforced and compliance is assessed at scale, with remediation for existing and new resources. Typical uses: allowed regions, consistent tags, diagnostic logs to Log Analytics.
Microsoft Defender for Cloud	Security policies and regulatory initiatives are applied by placing a subscription under the right management group.
Tags	Key-value metadata for cost allocation, ownership and automation. See Naming and tags.
Management groups	Containers that carry the policy and RBAC assignments above to many subscriptions at once.

Hub and spokes¶

The network is a hub-and-spoke design. Traffic between spokes, towards on-premises networks and towards the internet always passes the hub, where it can be inspected and authorised.

The hub offers the shared services: connectivity, firewalling, DNS, monitoring and governance.
A spoke is an isolated subscription that hosts one workload in one environment.
In a secured virtual hub (Virtual WAN with Azure Firewall), routing through the firewall is automated, so spokes do not need their own user-defined routes for it.

See Service types for what the hub offers and DNS design for name resolution. What the platform builds inside a spoke is described in Spoke canvas, and why a spoke gets its subscription from a provisioning step and not from a pool in Subscription provisioning.

A workload and its spokes¶

A workload identifies, isolates and gives ownership to one business solution. It is the top of a hierarchy:

the Entra ID groups and roles of the team (Identity and access model),
optionally a project in Azure DevOps,
one spoke per environment, normally one for production data and the others for non-production data.

Spoke variants (standard, sandbox, managed) are described in Service types.

IP plan structure¶

All address ranges come from one central IP plan, because overlapping ranges break routing. A workable structure is to reserve one large block per Azure region and divide it by purpose:

Block	Use
Hub, per platform environment (prod, canary)	Connectivity (virtual hub, Bastion, build agents, DNS resolver, gateways), management and identity networks
Reserved inside the hub	Room to grow, for example for client address pools of a point-to-site VPN
Sandbox	An isolated range for sandbox subscriptions
Workload spokes	The bulk of the block, handed out per spoke (a /24 is a common default)
Core IT / special purposes	Ranges for platform-adjacent systems

Keep the plan in one place

Keep the plan as a document or table in the repository next to the configuration, and update it in the same pull request that adds a spoke or region. Ask your network team which ranges on-premises already uses.