PATTERN Cited by 1 source

Cloud region migration during conflict¶

Pattern: When a cloud region (or small cluster of regions) is in a geography experiencing active military conflict or sustained kinetic attack, migrate workloads and data to cloud regions in non-conflict geographies, using the current provider's cross-region replication and backup primitives.

The hyperscaler itself may issue this guidance explicitly. Amazon Web Services issued precisely this recommendation on 2026-03-01 for customers running workloads in me-central-1 (UAE) and me-south-1 (Bahrain) following drone strikes on Amazon data-center facilities in both regions:

"AWS urged customers with workloads in the affected regions to back up their data or migrate to other AWS regions."

— the canonical wiki instance of this pattern.

When to apply¶

Apply when multiple signals converge:

The region is in a geography under active military conflict or persistent kinetic threat.
The provider itself has disclosed damage to the region's facilities via status dashboard or equivalent.
Third-party observability (e.g. Cloudflare Cloud Observatory) confirms elevated connection-failure rates sustained for multiple days rather than hours.
The provider has indicated that instability is expected to continue — AWS's framing was that operations are "unpredictable" given the regional security situation.

Any one of these in isolation may not justify migration. The combination of provider disclosure + third-party observability + provider-issued customer guidance is the trigger.

Shape¶

For data¶

Snapshot and export persistent data (databases, block storage, object storage) to a non-conflict region.
Prefer provider's native cross-region replication primitives where they exist:
Amazon S3 Cross-Region Replication (CRR)
RDS / Aurora cross-region read replicas and global clusters
DynamoDB global tables
EBS snapshot cross-region copy
Maintain versioned backups in the destination region with independent retention from the source region — the source region may go offline during the migration window.

For compute¶

Provision equivalent capacity in the destination region ahead of the migration traffic shift — capacity shortages in pre-identified failover regions have historically been a problem during multi-tenant migrations.
Rebuild stateless services in the destination via Infrastructure-as-Code. The deploy artefact should not depend on the conflict region being reachable.
Cut over DNS / load-balancer routing once the destination is warm — progressive (weighted) cutover preferred to hard-switch where applications tolerate multi-region read paths.

For governance¶

Data residency + compliance may restrict which destination regions are legally usable. EU-data me-central-1 workloads may not all be eligible to flow to us-east-1 or ap-south-1 without additional contractual or technical safeguards.
Contractual obligations to customers or regulators about data location may need to be renegotiated or documented as emergency-exemption.

Trade-offs¶

Upside¶

Survives kinetic events that the region itself cannot. The 2026-03 AWS me-central-1 + me-south-1 damage did not take down workloads that had been pre-replicated to eu-west-1 or eu-central-1.
Reduces the provider's post-incident blame vector — AWS explicitly giving this guidance means customers who follow it have a clean audit trail of responsible migration.
Flushes out latent single-region assumptions that the migration process would otherwise never exercise.

Downside¶

Expensive — cross-region data transfer plus doubled compute capacity during the migration window.
Complex — especially for stateful workloads with strong consistency requirements. Migrating a regional database with active writers is non-trivial.
Latency impact on end-users — if the conflict region was chosen for geographic proximity to a user population (e.g. a UAE region serving UAE users), failover to an out-of-region destination introduces a round-trip penalty.
Compliance headwinds — residency and data-sovereignty constraints may block naive migration even during emergency.

Pre-position the migration, don't discover it¶

The AWS guidance — "back up their data or migrate to other AWS regions" — is much easier to execute if the architecture has been pre-built to do this. Designs that are already multi-region (active-active or warm-standby) can execute this pattern in hours. Designs that are single-region discover the pattern at the worst possible moment.

Practical consequence: for any workload in a conflict-exposed geography, the multi-region design work should not be gated on an event — it should be part of the baseline architecture.

Composes with¶

patterns/multi-region-failover — the general case this specialises for conflict contexts.
concepts/static-stability — the destination region's capacity should not depend on traffic from the source region to scale up into.
concepts/blast-radius — conflict treats the region as a single blast-radius unit, collapsing the usual AZ-level blast radius arguments within the region.

Seen in¶

sources/2026-04-28-cloudflare-q1-2026-internet-disruption-summary — canonical wiki instance; following drone strikes on me-central-1 and me-south-1 on March 1-2 2026, AWS publicly urged affected customers "to back up their data or migrate to other AWS regions." A second me-south-1 disruption on March 23 reinforced the guidance. Cloudflare Cloud Observatory connection-failure-rate graphs provided the third-party observability backing the provider disclosure.