Information needed for a new spoke
Azure Landing Zone operates a Hub and Spoke architecture. A spoke is a container for one or more workloads. A workload is typically an application or group of related applications. All spokes must have at least one workload and a workload generally maps 1:1 with an Azure subscription.
When requesting a brand new spoke, or expanding an existing spoke with an additional subscription/workload, this page can be used for reference to help you provide all of the relevant information to the ALZ team about this new set of resources.
Checklist
1. High-Level Design Architecture diagram
All new users requesting access to a spoke must collaborate with our ALZ team and provide a High-Level Design (HLD) architectural document. This document should outline the overall architecture and design of the requested spoke. This ensures that your resources are correctly configured and align with the overall Azure Landing Zone (ALZ) architecture.
2. Subscription
Have you already provisioned an Azure Subscription or would you like one to be created for you? If providing your own subscription, please provide the Subscription Name and Subscription ID and we’ll need the correct RBAC assignments for our deployment tool service principals before we can start.
3. Spoke Owners
Two user accounts that are ultimately responsible for this Spoke. These accounts will be given the ability to manage RBAC across the Spoke or Workload
Example
someone@justice.gov.uk
someone_else@justice.gov.uk
4. Location
The region that Spoke resources will be created in.
Example
UK South or UK West
5. Spoke or Workload identifier
A unique short string that identifies the functionality hosted in the new spoke. Could be a specific application or project name. We define and build new spokes using IaC and this value is used to determine the name of a number of resources.
Example
Spoke/Workload identifier: xwc
Resulting resources:
Resouce Group: rg-xwc-core-001
VNET: vnet-xwc-core-001
Keyvault: kv-xwc-coremoj-001
Automation Account: auto-xwc-core-001
etc...
6. Environments
Which environments the resources will be created in, selected from the following:
| Environment |
|---|
| Development |
| NLE/Pre-Production |
| Production |
We require a minimum of Development and Production, but NLE/Pre-Production can be added if required.
7. Tags
Tags are our primary means of identifying the owner and purpose of each resource, as well as feeding in to our cost management and billing logic. At a minimum we require tags for the following:
| Mandatory Tags |
|---|
| application |
| businessunit |
| owner |
8. Network Requirements
Details on the size of the address space you require for the core VNET in the Spoke (We will allocate a specific address space based on your requirements). Also any additional architectural requirement for particular subnetting etc…
Example
- You require a /24 split into 2 separate /25 subnets. Your Spoke would be supplied with the configuration:
| Resource | Address space |
|---|---|
| vnet-xwc-core-001 | 10.0.0.0/24 |
| snet-xwc-core-001 | 10.0.0.0/25 |
| snet-xwc-app-001 | 10.0.0.128/25 |
9. Tooling setup details (Optional!)
Details relating to the provisioning of some build/deployment tooling. Please see this page for full details.
We require:
- Team Name
- Github Project Name (What will your repository be called?)
- Github Project Description (What is your repository for?)
- Github Repository visibility (public or internal)
- Github Team (Github team containing the user accounts that should be repository admins)
Example
Team name: Azure Landing Zone
Github Project Name: staff-infrastructure-azure-landing-zone-print
Github Project Description: Deployment code/resources for ALZ Printer rollout
Visibility: Internal
Github Team: cloud-alz-admins
10. Extras
Anything additional not captured in the above. This is open ended and can include things like:
- Extra VNets and Peerings, for example:
| Source VNET | Destination VNET(s) |
|---|---|
| vnet-xwc-core-001 | vnet-up-app-001 |
- Additional communication/network requirements outside of ALZ: DXC, AWS etc…
- Custom roles
- Specific VNet DNS forwarding (ALZ defaults to DNS servers maintained by Core Network Team)
- Service Accounts
- Policy exemptions
- etc…