Design Guidance

These pages turn design decisions of managed platforms into guidance that you can reuse. Two of them record decisions of the spoke canvas: how subscriptions are provided and how drift is reported. Each page explains the problem, a recommended approach, the consequences, and how it maps to the MCP configuration. They are guidance, not part of the product baseline: the platform stays the same, and what changes is how you organise your configuration and your processes.

Examples, not rules

The numbers (priority ranges, port lists, time windows) are examples. Pick values that fit your platform, write them down, and record the decision in your governance process.

Topic	Page	Use it when
Firewall rule files, priorities, naming, IP groups	Firewall rule organisation	The number of workloads grows and rules become hard to trace
Network access for pipeline agents	Build agent access to spokes	Teams wait for firewall rules before they can deploy
Choosing and adding a region	Region expansion	You hit capacity limits or need more redundancy
Team-managed private DNS zones	DNS subdomain delegation	DNS changes through central IT slow teams down
A service without an owner that needs private data	Decentralised data gateway	Teams need a gateway and no team can own a central one yet
Engineers reaching private resources	Developer access with point-to-site VPN	Resources have no public endpoint but engineers need access
Getting a subscription for a spoke	Subscription provisioning	You wonder whether to keep a pool of free subscriptions
Seeing manual changes in spokes	Configuration drift detection	Workload teams can change the spoke baseline and you want a regular report

For what the spoke canvas deploys see Spoke canvas: what a deployment creates. For the concepts behind the pages see the Architecture reference and Design principles. For consumers: Limits.