Skip to content

How It Works Behind the Scenes

You don't need this to use your spoke, but it helps to know why some things work the way they do.

Platform team

In this documentation the platform team is XMMS (managed service) or your organisation's own platform team (self-managed). See Operating models.

Your spoke is a file

Each spoke is described in one JSON file in the platform's configuration repository, for example spokes/finance/canvas_invprt_dev.json. It holds your name, environment, subscription, tags, access groups, network and optional resources. The platform team edits that file when you request a change.

A pipeline makes Azure match the file

sequenceDiagram
    participant You
    participant PT as Platform team
    participant Repo as Config repository
    participant Pipe as Spoke pipeline
    participant Az as Azure
    You->>PT: Request (new spoke / change)
    PT->>Repo: Pull request with the spoke file
    Repo->>Repo: Review + automatic validation
    PT->>Pipe: Run for this one spoke
    Pipe->>Az: Plan: what will change?
    PT->>Pipe: Review plan, approve
    Pipe->>Az: Apply
    PT->>You: Confirmation

The pipeline uses Terraform. It compares the file with what exists in Azure and only changes the differences. That is why:

  • manual changes to your baseline are undone on the next run: the file wins;
  • your workload short name and environment can't change: they identify your spoke's state;
  • a change always goes through review and a plan before anything happens in Azure.

Your spoke and the hub

flowchart LR
    subgraph hub["Hub (platform team)"]
        fw["Azure Firewall"]
        dns["DNS resolver + private DNS zones"]
        agw["Application Gateway + WAF"]
    end
    subgraph spoke["Your spoke"]
        vnet["Your VNet"]
        res["Your resources"]
    end
    internet((Internet))
    onprem((On-premises))
    vnet -- "hub connection" --> fw
    fw --> internet
    fw --> onprem
    internet --> agw --> vnet
    vnet -. "DNS" .-> dns
  • Your VNet connects to the hub with a virtual hub connection. Outbound traffic goes through the firewall.
  • Inbound web traffic comes in through the Application Gateway and its WAF, if you requested publishing.
  • Your VNet uses the hub DNS resolver, so private endpoints resolve through the central private DNS zones.

Where your spoke sits: management groups and policy

Your subscription is placed in a management group (for example one for internal workloads and one for internet-facing ones). Policies and role assignments are set on the management group and inherited by your subscription. That is why moving a subscription yourself changes which policies apply, and why you can't do it (Limits). The hierarchy is explained in the Architecture reference.

Name resolution

Your network uses the hub DNS server of your region. A name in a central private DNS zone, such as a private endpoint of a PaaS service, resolves to its private IP address, so the traffic stays inside the network. Names of internal domains that live on-premises are forwarded by the platform's DNS resolver. Details are in DNS design.

Firewall rules: who decides

The central firewall is shared by all workloads, so rules are organised per workload and describe incoming traffic. The owner of the destination decides who may reach it. A rule from your spoke to another workload therefore normally needs the approval of the owner of that workload, and usually your security officer. See Firewall rule organisation for how the rules are structured.

Canary and production

The platform team tests every change to the hub on a separate canary copy of the hub first. Your spokes are hosted in the production hub. Hub changes reach you only after they worked on canary.

Want to know more?

The platform's technical documentation is in the Platform section.