What is the ALZ?
The Azure Landing Zone is a space within the wider MoJ’s Azure Enterprise agreement where services can be hosted in a spoke
Our ALZ Strategy has recently been refreshed and updated, click here to view it - The MoJ Azure Landing Zone Strategy 24-26
What is a Spoke?
A spoke in the Azure Landing Zone (ALZ) is a logical container within the Ministry of Justice’s (MoJs) Azure Enterprise Agreement (EA). A spoke contains subscriptions (smaller containers) which run workloads. Workloads are provided with some standard services to reduce lead time.
A spoke is paid for directly by the service/project requesting it i.e. there is no recharging model in place for ALZ Spoke billing so a purchase order (PO) for anticipated spend must be available prior to a spoke being requested
Spokes are created by the ALZ team before being handed over to the spoke owner(s). The ALZ team is available as fourth line support (4LS) for spokes further details on spoke support is available
What are the standard services in a spoke?
A spoke will always contain one workload (plus associated subscription) and network connections set up by the ALZ team. This workload, subscription and network connection cannot be changed or destroyed by spoke owners or accounts they authorise to manage the spoke.
Networking
All workloads within a Spoke are connected to a service managed by the Azure Landing Zone team called ‘The Hub’. This connection is mandatory and enables: 1. Ensure spokes are using allowed and secure connections to the internet and identity management services 2. A route for communication between components running elsewhere in ALZ or in some circumstances the wider MOJ 3. Allows access to some ALZ services such as secure Bastion for server access
A workload can be connected to other destinations in addition to The Hub but this must be requested and approved as part of the demand process for new or significant spoke changes.
Workload Resources
Most of the of the workload resources deployed by the ALZ team are provided to enable easy opt in to the features the ALZ team offer. They are generally built on a Pay As You Go (PAYG) billing model and will incur negligible costs if not utilized (pennies per month).
Once you start using ALZ features, or the resources that we deploy into a Workload, you will see costs for these standard resources increase. At a certain point, you could opt to move various services from PAYG to a reserved/forecasted billing model to help reduce costs.
A list of the main resources that are deployed in a typical ALZ Workload:
Keyvault
An Azure service used for secure storage and management of Secrets, Keys or Certificates. This is utilized by the ALZ Virtual Machine Terraform module to store automatically created server credentials. Costs for Keyvault are based on usage and will be almost zero unless utilized further by Spoke owners.
Log Analytics Workspace
An Azure service used to store and query logs. It is deployed with a PAYG configuration as standard where costs are dependent on the amount of data ingested. By default, ALZ Workloads push a small amount of data into this workspace (less than 1MB per day typically).
Automation Account
Used in ALZ to orchestrate automated Virtual machine on/off and server patching. Both services are opt-in and so by default this resource does not incur cost.
Azure Monitor
A collection of tools for monitoring Azure resources. ALZ provide two pre-configured Workbooks that help visualize monitoring data for Workload resources and VM’s much more detail is available
No alerting or notifications are configured as standard. Alerts and notifications carry a small cost depending on what criteria an alert is looking at and how often your notifications are triggered. Microsoft provide a healthy amount of free usage as well, see here - Pricing - Azure Monitor | Microsoft Azure
Recovery Services Vault
An Azure service for the management of backup and recovery that can be used with Azure Virtual Machines. Costs are incurred for the size of the backups on disk. When empty, no cost will be generated by this resource.
Storage Accounts
ALZ Workloads are provided with two Storage accounts as standard. One is intended for the storage of general diagnostic data (logs etc…) and the other is specifically for Virtual Machine boot diagnostics. As deployed, an ALZ Workload will not push any data into the Storage Accounts, incurring no cost.
What can I do with a Spoke?
Spoke owner(s) can authorise accounts to create, manage or destroy workloads and resources as required. This enables teams to build and host services in a secure Azure environment whilst being compliant to security standards by default. The ALZ also provides connectivity to identity management services for some of the most widely used domains across the MoJ so, when this is a blocker to progress, the ALZ may be able to help.
The team managing the spoke has near total autonomy over what they use the spoke for.
With great autonomy comes great responsibility.
Spend, cost optimisation and general best practice are on the team to manage and maintain. The ALZ team can provide guidance and access to tolls to help manage and maintain best practice but, ultimately, the spoke owner has the authority to follow or not follow that guidance. It is not possible to get around the global policies controlling the security and integrity of the overall ALZ product from within a spoke. Any exceptions that need to be made must be authorised and documented in collaboration with the ALZ team.
You can use as many or as few of the standard feature offers the ALZ team provides to spokes once you start building resources. Further information on how to opt in to using them and their capabilities is available.
The ALZ Hub
The ALZ hub is a set of resources maintained by the ALZ team. It provides services to all Spokes in the ALZ. All Workloads within a Spoke are peered to the hub providing the ability to route network traffic to the Internet, other resources in ALZ (by request) or, in some cases, the wider MOJ. All usage of services in the Hub by Spokes users is transparent and, generally, no additional configuration is needed once a standard Spoke Workload has been deployed.