Skip to content

Establish an Azure Recovery Network Foundation

Execution context: Run this procedure from a terminal where hyops --help succeeds. If HybridOps.Core is not installed, complete the Quickstart. For deployment support, use GitHub Discussions.

  • Purpose: Establish the governed network boundary required by later recovery workloads.
  • Owner: Platform engineering / SRE
  • Trigger: Planned recovery preparation, an approved readiness exercise or controlled recovery activation
  • Impact: The selected Azure environment gains an isolated resource boundary and recovery network. No workload is deployed and no production traffic is changed.
  • Severity: P2
  • Pre-reqs: Azure runtime readiness is established in a HybridOps environment dedicated to this recovery network; the location, address range, ownership and lifecycle tags are approved; the target names do not conflict with unmanaged resources.
  • Rollback strategy: Confirm that no workload depends on the network, then remove the blueprint in reverse dependency order.

Operation contract

Blueprint ref: azure/recovery-network-foundation@v1

The blueprint defines one platform-owned lifecycle:

  1. validate the declared recovery target;
  2. establish its resource boundary;
  3. establish the network within that boundary;
  4. retain evidence for each required step; and
  5. remove the network before its resource boundary during teardown.

This operation establishes recovery capacity at the network layer. It does not claim application readiness, data recovery, traffic cutover or service restoration.

The selected HybridOps environment owns the resource-boundary and network state for this lifecycle. Do not use that environment for another blueprint that owns the same capability state.

Set the working values

Set these values once in the shell used for the procedure:

ENV_NAME="recovery"
BLUEPRINT_REF="azure/recovery-network-foundation@v1"

The blueprint reference identifies the shipped operation contract. The environment name selects the operator-owned configuration and retained state.

Initialise the environment contract

Create an environment-owned overlay from the immutable shipped blueprint:

hyops blueprint init \
  --env "$ENV_NAME" \
  --ref "$BLUEPRINT_REF"

hyops blueprint edit \
  --env "$ENV_NAME" \
  --ref "$BLUEPRINT_REF"

Review and set:

  • context_id
  • resource_group_name
  • location
  • vnet_name
  • address_space
  • ownership and lifecycle tags

resource_group_name and location appear in both required steps. Keep the values identical so validation, execution and resulting state refer to one target boundary.

Validate the declared outcome

hyops blueprint validate \
  --env "$ENV_NAME" \
  --ref "$BLUEPRINT_REF"

hyops blueprint plan \
  --env "$ENV_NAME" \
  --ref "$BLUEPRINT_REF"

hyops blueprint preflight \
  --env "$ENV_NAME" \
  --ref "$BLUEPRINT_REF"

Validation must report status=ok, the plan must order recovery_resource_group before recovery_network, and preflight must report preflight_status=ok. Resolve any mismatch before execution.

Establish the boundary

hyops blueprint deploy \
  --env "$ENV_NAME" \
  --ref "$BLUEPRINT_REF" \
  --execute

The operation must stop if either required step fails. Do not bypass a failed preflight or create a parallel target manually.

Verify the resulting state

hyops show module core/azure/resource-group --env "$ENV_NAME"
hyops show module core/azure/vnet --env "$ENV_NAME"

Confirm that the retained state records:

  • the approved resource-boundary name and location;
  • the approved network name;
  • successful completion for both required steps.

Retain the run-record locations printed by the deployment with the change evidence.

Recovery workloads must remain blocked until their own readiness contracts succeed. Network creation is not a workload health signal.

Recover from an interrupted operation

If the resource boundary succeeds but the network step fails:

  1. inspect the failed step's run record;
  2. correct the environment overlay or failed precondition;
  3. rerun validation and preflight; and
  4. redeploy the same blueprint reference.

The successful first step remains part of the declared operation. Reuse it rather than creating another resource boundary outside the blueprint.

Remove the boundary

Confirm that no recovery workload, private endpoint or delegated service still depends on the network, then run:

hyops blueprint destroy \
  --env "$ENV_NAME" \
  --ref "$BLUEPRINT_REF" \
  --execute

Verify that the network is removed before the resource boundary and retain the destroy run record with the change evidence. Confirm the resulting platform state:

hyops show module core/azure/vnet --env "$ENV_NAME"
hyops show module core/azure/resource-group --env "$ENV_NAME"

Both module records must report destroyed before the operation is closed.