Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
The continuity patterns described in this guide are intended primarily for online transactional processing (OLTP) systems. The patterns are organized into four families based on the intended steady-state and continuity environments:
Design for continuity within Sovereign Public Cloud by adapting established disaster-recovery patterns to the your identified sovereignty requirements.
Design for redeployment into a prepared, dormant alternative cloud environment following a disruptive event, subject to the availability of required capacity, dependencies, deployment artifacts, data, identities, and connectivity.
Design an extended deployment in which selected workloads or components are intended to operate continuously in an eligible alternative cloud and integrate with workloads in Sovereign Public Cloud. Determine placement through your risk assessment and validate service availability, capacity, eligibility, and operational dependencies in each environment.
Design for a recovery path from an alternative environment into Sovereign Public Cloud for scenarios in which the alternative environment is affected by a disruptive event, subject to the approved region, service availability, capacity, controls, data, identity, key, and tested procedures you define.
Each continuity pattern describes the intended outcome, applicability, key technical considerations, and proposed activation and return conditions. Operating-model and role guidance applies across the patterns. You should assign ownership for cross-environment integration, data and identity continuity, activation, validation, operation during disruption, and return. Diagrams indicate intended continuity paths with solid arrows and intended return paths with dashed arrows. They also identify the planned deployment mode as active, warm/passive, or dormant.
| Scenario | Steady-state environment | Continuity environment | Readiness of the continuity environment |
|---|---|---|---|
| 1 Continuity across approved regions | Sovereign Public Cloud region | Another approved Sovereign Public Cloud region | Active, warm, or dormant, by topology |
| 2 Redeploy to Sovereign Private Cloud | Sovereign Public Cloud | Sovereign Private Cloud (Azure Local) | Dormant: build-ahead prerequisites only |
| 3 Extend with Sovereign Private Cloud | Sovereign Public Cloud; selected workloads also in Sovereign Private Cloud | Sovereign Private Cloud, already running | Active or warm |
| 4 Recover from Sovereign Private Cloud | Sovereign Private Cloud | Sovereign Public Cloud | Dormant: landing zone, tenant, and data path maintained |
| 5 Redeploy to NPC | Sovereign Public Cloud | NPC | Dormant: capacity reserved, tenant prepared |
| 6 Extend with NPC | Sovereign Public Cloud; selected workloads also in NPC | NPC, already running | Active |
| 7 Recover from NPC | NPC | Sovereign Public Cloud | Dormant: deployment artifacts maintained |
In this guide, active denotes an environment configured to serve live traffic; warm denotes an environment configured to run and receive replication without normally serving live traffic; and dormant denotes an environment in which only identified build-ahead prerequisites are maintained. Actual service, replication, activation time, and steady-state effort depend on the selected design, capacity, connectivity, data, identity, and tested operating procedures.
Responsibility model: For each environment, use the Cloud Adoption Framework guidance for sovereignty planning and readiness, including its operating-model and roles-and-responsibilities guidance. For multi-environment continuity, also assign ownership for integration, data and identity continuity, activation, validation, disrupted operations, and return.
Scenario 1: Continuity across approved regions in Sovereign Public Cloud
Pattern family: Design for continuity within Sovereign Public Cloud.
Target outcome: Design and test workloads to support failover to another customer-approved region if a region becomes unavailable. Follow established continuity patterns on Microsoft Learn. Whether failover succeeds, and the availability, recovery time, recovery point, replication, and data-placement outcomes depend on the selected services, topology, capacity, current regional conditions, dependencies, and validated procedures.
Applies when: This pattern applies when a defined set of Sovereign Public Cloud regions meet the workload's requirements and the selected services support the required topology. This pattern doesn't provide a recovery path for loss of access to Sovereign Public Cloud as a whole.
Key technical considerations
Choose active/active, active/passive, or backup and restore from the recovery objectives. See Architecture strategies for disaster recovery.
Confirm that each target region, and any region that a service replicates to by default (such as a paired region), meets your requirements. Replication behavior is service-specific.
Verify current regional and service support for each control the workload requires, including confidential-computing SKUs, key-management services, operator-access controls, and Sovereign Control Panel. Separately validate the supported key availability and recovery design for every target region.
Enforce region placement and replication targets with Azure Policy to detect drift.
Activation and return: If a region is unavailable or no longer meets requirements, your runbook can redirect traffic to a surviving approved region. Where supported and operationally ready, promote replicas or restore backups and validate the required sovereign controls. A return procedure can re-establish replication, reconcile data, and shift traffic back after the source region and dependent services are validated.
Scenario 2: Redeploy from Sovereign Public Cloud to Sovereign Private Cloud
Pattern Family: Design for redeployment into a prepared, dormant alternative cloud.
Target Outcome. Selected workloads that run in Sovereign Public Cloud can be designed for redeployment with data restored from an available and usable copy, into a prepared Sovereign Private Cloud if access to Sovereign Public Cloud is lost. Until activation, the Sovereign Private Cloud maintains only the build-ahead prerequisites you identify. Successful redeployment depends on their availability, compatibility, capacity, and tested procedures.
Applies when. Your assessment requires a continuity environment that you or a partner operate, in addition to Sovereign Public Cloud, and the recovery time objectives (RTO) allow time for redeployment.
Key technical considerations
Where operation without Azure connectivity is needed beyond the tolerances of connected operations, evaluate disconnected operations for Azure Local for the selected release and configuration.
Identify the dependencies that must exist before activation and those that can be recreated within the recovery window based on your validation. Depending on the selected release and configuration, build-ahead dependencies might include capacity, identity, registries, data, observability, networking, compute, Kubernetes, messaging, and database components.
Data infrastructure and seeding. Define the target data infrastructure for each workload, including database engines, storage services, configuration, capacity, and high-availability requirements. Define how data is seeded and refreshed - such as backup and restore, export and import, or supported synchronization technologies like Managed Instance link - and validate that the tested process meets the recovery-point and recovery-time objectives.
Identity continuity. Define the identity population required in the target environment. Document which users, groups, application identities, role assignments, and policies can be synchronized or recreated; which credentials, multifactor authentication methods, and other authentication factors require re-enrollment; and whether the tested process meets the recovery objective.
Close application portability gaps, such as object-storage access without an abstraction, before an event. Use patterns like the Adaptive Apps pattern.
Activation and return. After a recorded activation decision, you might use tested procedures to recreate networks and compute, restore databases from the latest available and validated seeded copy, switch telemetry to local services in the Sovereign Private Cloud, and redirect DNS to the Sovereign Private Cloud. These steps depend on the availability and integrity of deployment artifacts, capacity, data, keys, identities, connectivity, and an authoritative DNS service that remains changeable without access to Sovereign Public Cloud. Return might require redeploying the workload in Sovereign Public Cloud, reconciling data written during the event, validating consistency, and then resuming seeding.
Scenario 3: Extend Sovereign Public Cloud with Sovereign Private Cloud
Pattern family: Design an extended deployment in which select workloads or components operate continuously in an eligible alternative cloud and integrate with workloads in Sovereign Public Cloud.
Target outcome: Design selected workloads or components to run continuously in a Sovereign Private Cloud while other workloads remain in Sovereign Public Cloud. If access to Sovereign Public Cloud is lost, the selected workloads continue at a minimum service level you define, subject to the availability of local capacity, identities, data, keys, connectivity, and other required dependencies.
Applies when: Your assessment requires an environment operated by you or a partner, and recovery objectives that need the continuity environment running before an event.
Key technical considerations
Define the continuity boundary: the components that need to keep working locally when connectivity to Sovereign Public Cloud is lost—such as identity, name resolution, observability, message broker, container registry, and container platform—without runtime dependencies on Sovereign Public Cloud.
Run active/active or warm active/passive, define which environment holds write authority in each mode, and size local capacity from the minimum service level rather than from the Sovereign Public Cloud footprint.
Choose connected or disconnected operations for Azure Local by the required duration of independence from Azure; with disconnected operations, identity, name-resolution, and certificate services need to be available locally.
Integrate the continuity environment in advance. Depending on the selected architecture and current product support, integration options can include:
- Hybrid connectivity
- DNS-based traffic distribution, such as Azure Traffic Manager with external endpoints
- Multi-cluster management and workload placement with Azure Kubernetes Fleet Manager where Arc-enabled cluster support meets the scenario requirements
- Supported database-replication technologies, such as SQL Server Always On availability groups or Managed Instance link Validate feature availability, prerequisites, limitations, topology, capacity, security, and recovery behavior for each selected technology.
Activation and return: If the continuity environment and required dependencies remain operational, activation might primarily involve a traffic-routing change rather than a full rebuild: withdraw Sovereign Public Cloud endpoints from DNS distribution, or promote a validated warm copy. Return might involve re-adding endpoints, re-establishing replication, reconciling and validating available data written during the event, and confirming service health. Regular drills can provide evidence about whether the path meets your objectives.
Scenario 4: Recover to Sovereign Public Cloud from Sovereign Private Cloud
Pattern family: Design for a recovery path into Sovereign Public Cloud.
Target outcome. Workloads that run in a Sovereign Private Cloud can be designed with a recovery path into an approved Sovereign Public Cloud region if the Sovereign Private Cloud location becomes unavailable. Whether recovery succeeds and which recovery objectives can be achieved depend on the availability of the approved region, supported services, capacity, identities, data, keys, connectivity, controls, deployment artifacts, and tested procedures. You document the governance decision and the sovereignty controls required for the recovery environment.
Applies when. Your assessment requires a recovery path for the Sovereign Private Cloud location, and you document that temporary operation in Sovereign Public Cloud is acceptable under its requirements.
Key technical considerations
- Unlike Extend, the Sovereign Private Cloud carries the live load; Sovereign Public Cloud stays dormant, with its landing zone, tenant, and data path maintained.
-Validate the selected environments and services for data protection, identity, key management, connectivity, capacity, observability, activation, disrupted operations, and return. Available capabilities and responsibilities vary by offering, region, service, configuration, terms, and operator model.
Apply the controls that the assessment requires and the region supports, such as region selection as in Scenario 1, confidential computing, Customer Lockbox, Data Guardian, and Sovereign Landing Zone policies. Where a control isn't compatible with a recovery technology you want to apply, recreation of the environment from deployment artifacts through customer-owned deployment procedures might be needed.
Keep the Sovereign Public Cloud tenant current from the same authoritative identity source—for example, with Microsoft Entra Connect Sync—or from identity held as code.
Activation and return. Activation is subject to the your documented governance and risk assessment. Customer-owned recovery procedures should define how required keys might be made available, how policies are validated, how the environment is re-created, how data is restored from available and validated data, and how DNS records are redirected. Return might require redeployment into a rebuilt Sovereign Private Cloud, consistent with Scenario 2, including data reconciliation, validation, and withdrawal of the copies and keys in Sovereign Public Cloud as the governance decision requires.
Scenario 5: Redeploy from Sovereign Public Cloud to NPC
Pattern family: Design for redeployment into a prepared, dormant alternative cloud.
Target outcome. For eligible customers, you can design selected workloads for possible redeployment to an eligible National Partner Cloud whose underlying cloud infrastructure is operated by the partner. Whether redeployment succeeds, and whether the recovery objectives can be achieved, depend on the operator’s then-current catalog, available capacity, terms, identity model, supported data-transfer paths, dependencies, and tested procedures.
Applies when. An NPC is available in the required jurisdiction, you're an eligible customer, and operator dependency is acceptable under your risk assessment.
Key technical considerations
Depending on the applicable National Partner Cloud’s documented capabilities (for example, available services and their API versions), you might be able to reuse selected deployment artifacts. Validate supported services, configurations, interfaces, API versions, and SKUs by using information the operator makes available, and document how you address each gap.
Validate the identity and tenant model documented for the selected National Partner Cloud. Define and test how to establish required users, groups, application identities, role assignments, credentials, and authentication factors before activation when the operator uses a separate tenant or identity environment.
Select and test a customer-controlled data-transfer and key-management approach supported by the source and target environments. Document transfer frequency, achievable recovery point, connectivity dependencies, encryption-key availability, and expected behavior when the transfer path is interrupted.
Activation and return. After a recorded activation decision, you can confirm available reserved capacity with the operator, and use tested procedures to deploy the landing zone and workloads from compatible parameterized templates, restore data from an available usable copy, re-establish required credentials, and redirect DNS. Return might require transferring recoverable data written during the event, redeploying in Sovereign Public Cloud, reconciling the copies, validating consistency, and then resuming seeding.
Scenario 6: Extend Sovereign Public Cloud with NPC
Pattern family: Design an extended deployment in which select workloads or components operate continuously in an eligible alternative cloud and integrate with workloads in Sovereign Public Cloud.
Target outcome. Selected workloads or components run continuously in an eligible National Partner Cloud and integrate with workloads in Sovereign Public Cloud, subject to the availability and compatibility of the operator’s services, capacity, connectivity, identities, data, keys, and integration dependencies. The operator manages the cloud infrastructure according to its offering. Confirm customer and partner responsibilities for workloads, identity, data, integration, security, and continuity in applicable documentation and terms.
Applies when. An NPC is available in the required jurisdiction, you're an eligible customer, operator dependency is acceptable under your risk assessment, and the assessment identifies workloads or components that need to operate in the NPC.
Key technical considerations
Validate the identity and tenant model documented for the selected National Partner Cloud. Define the identity population required in the target environment and document which users, groups, application identities, role assignments, and policies you can synchronize or recreate; which credentials, multifactor authentication methods, and other authentication factors require re-enrollment; and whether the tested process meets the recovery objective.
Determine what data you must store in the NPC, what data you can store and process in Sovereign Public Cloud, and permitted cross-cloud data flows from your own requirements. The application and integration design should enforce the approved data classifications, destinations, and transfer purposes.
Design options for controlling data flows include an inspecting firewall at a customer-controlled hub, allow-listed egress, and asynchronous, schema-controlled integration messages instead of open API access.
Assess components against the operator's published catalog. The operator is responsible for capacity and each environment has its own control plane and observability.
Activation and return. Without connectivity to Sovereign Public Cloud, the customer-owned workload which runs in the NPC might operate in a degraded mode the customer previously tested, subject to the availability of local services and dependencies. When connectivity returns, the customer may validate the governed link, resume permitted data exchange between the workload running in NPC and the ones running in SPC and reconcile data as supported by the application's consistency model and available records.
Scenario 7: Recover to Sovereign Public Cloud from NPC
Pattern family: Design for a recovery path into Sovereign Public Cloud.
Target outcome: Workloads that run in an NPC can be designed with a recovery path into an approved Sovereign Public Cloud region if the NPC becomes unavailable. Whether recovery succeeds and which recovery objectives can be achieved depend on the availability of the approved region, supported services, capacity, deployment artifacts, identities, data, keys, connectivity, controls, and tested procedures. You determine whether this path is permissible and defines the required controls, recovery objectives, and acceptable data loss.
Applies when: Your assessment requires an additional recovery path for NPC workloads, and you determine in advance whether temporary operation in a Sovereign Public Cloud region is permitted.
Key technical considerations
Define which data and control paths are permitted among environments and validate them against applicable requirements. Feasible paths and behavior depend on the selected offerings, services, regions, configurations, connectivity, and operator models.
Hold deployment artifacts (infrastructure-as-code, images, and configuration) outside the NPC, parameterized to deploy into both environments, and prepare the Sovereign Public Cloud tenant to receive identity configuration as code.
Apply the recovered-state controls of Scenario 4.
Activation and return: Activation is subject to your governance and risk assessment. Use tested procedures and compatible deployment artifacts to attempt deployment into prepared recovery subscriptions, subject to available capacity, identities, keys, connectivity, controls, and the accepted data limitations. Return might require redeployment into the NPC when it is available and validated again, consistent with Scenario 5; any transfer of data back remains subject to the same risk assessment and to the availability and integrity of an approved transfer path.