multi-region-deployment

name	multi-region-deployment
enabled	true
description	Use when performing multi region deployment — multi-region deployment template covering region selection, data replication strategy, traffic routing, failover configuration, consistency models, and operational procedures. Use for expanding to new regions, designing active-active architectures, or implementing global redundancy.
required_connections	[{"prefix":"aws","label":"AWS (or cloud provider)"}]
config_fields	[{"key":"service_name","label":"Service Name","required":true,"placeholder":"e.g., global-api"},{"key":"primary_region","label":"Primary Region","required":true,"placeholder":"e.g., us-east-1"},{"key":"secondary_regions","label":"Secondary Region(s)","required":true,"placeholder":"e.g., eu-west-1, ap-southeast-1"},{"key":"topology","label":"Topology","required":true,"placeholder":"e.g., active-active, active-passive"}]
features	["ARCHITECTURE","DEPLOYMENT","DISASTER_RECOVERY"]

Multi-Region Deployment Skill

Plan multi-region deployment for {{ service_name }} across {{ primary_region }} and {{ secondary_regions }} ({{ topology }}).

Workflow

Step 1 — Region Strategy

REGION ARCHITECTURE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Service: {{ service_name }}
Topology: {{ topology }}
Primary: {{ primary_region }}
Secondary: {{ secondary_regions }}

TOPOLOGY DECISION:
  Active-Active:
    - All regions serve production traffic simultaneously
    - Requires conflict resolution for writes
    - Lowest latency for global users
    - Highest complexity and cost

  Active-Passive:
    - Primary handles all traffic, secondary is standby
    - Simpler data consistency model
    - Higher latency for remote users
    - Lower cost, used primarily for DR

Selected: {{ topology }}
Justification: [why this topology was chosen]

Step 2 — Data Replication Strategy

DATA REPLICATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DATABASE:
[ ] Replication type: [synchronous / asynchronous / semi-sync]
[ ] Replication technology: [Aurora Global DB / DynamoDB Global Tables / CockroachDB / custom]
[ ] Consistency model: [strong / eventual / causal]
[ ] Conflict resolution: [last-writer-wins / region-primary / application-level]
[ ] Expected replication lag: ___ms
[ ] Maximum acceptable lag: ___ms
[ ] Replication monitoring configured

CACHE:
[ ] Cache strategy: [local per-region / replicated / independent]
[ ] Cache invalidation: [event-driven / TTL / hybrid]
[ ] Cache warm-up procedure for new regions

OBJECT STORAGE:
[ ] S3 cross-region replication configured
[ ] Replication scope: [full bucket / prefix-filtered]
[ ] Versioning enabled

MESSAGING / EVENTS:
[ ] Event replication: [Kafka MirrorMaker / SNS fan-out / EventBridge]
[ ] Event ordering guarantees: [per-partition / none]
[ ] Deduplication strategy for cross-region events

Step 3 — Traffic Routing

TRAFFIC ROUTING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ROUTING METHOD:
[ ] GeoDNS (Route53 geolocation / latency-based routing)
[ ] Global load balancer (CloudFront, Global Accelerator)
[ ] Anycast DNS
[ ] Application-level routing

ROUTING RULES:
| User Region | Target Region | Fallback Region |
|------------|---------------|-----------------|
| North America | {{ primary_region }} | [fallback] |
| Europe | [region] | [fallback] |
| Asia Pacific | [region] | [fallback] |
| Default | {{ primary_region }} | [fallback] |

HEALTH CHECKS:
[ ] Health check endpoint per region
[ ] Health check interval: ___ seconds
[ ] Failure threshold: ___ consecutive failures
[ ] Automatic failover on health check failure
[ ] Failover DNS TTL: ___ seconds

Step 4 — Deployment Pipeline

MULTI-REGION CI/CD
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DEPLOYMENT STRATEGY:
[ ] Sequential: deploy to primary, validate, then secondary regions
[ ] Parallel: deploy to all regions simultaneously
[ ] Canary per region: canary in each region before full rollout

DEPLOYMENT ORDER:
1. [ ] {{ primary_region }} (canary -> full)
2. [ ] [secondary region 1] (canary -> full)
3. [ ] [secondary region 2] (canary -> full)

PER-REGION VALIDATION:
[ ] Health checks passing in region
[ ] Latency within SLO for region
[ ] Data replication healthy
[ ] No cross-region errors

ROLLBACK:
[ ] Per-region rollback capability (independent versions temporarily)
[ ] Global rollback procedure
[ ] Database migration rollback across regions

Step 5 — Failover Configuration

FAILOVER PROCEDURES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AUTOMATIC FAILOVER:
[ ] Health check-based DNS failover configured
[ ] Failover triggers defined:
    - Region unreachable for > ___ seconds
    - Error rate > ___% for > ___ minutes
    - Latency > ___ms sustained for > ___ minutes
[ ] Automatic database promotion in secondary region
[ ] Automatic traffic rerouting

MANUAL FAILOVER:
[ ] Runbook for manual failover documented
[ ] DNS override procedure
[ ] Database promotion procedure
[ ] Application configuration switch

FAILBACK:
[ ] Data reconciliation procedure after failback
[ ] Traffic gradual shift back to primary
[ ] Verify data consistency across regions
[ ] Reset secondary to standby mode

TESTING:
[ ] Failover tested quarterly
[ ] Last test date: ___
[ ] Next test date: ___

Step 6 — Operational Considerations

OPERATIONS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
MONITORING:
[ ] Per-region dashboards
[ ] Cross-region replication lag monitoring
[ ] Per-region SLO tracking
[ ] Global aggregate metrics
[ ] Region comparison dashboards (spot regional issues)

ON-CALL:
[ ] Follow-the-sun on-call rotation (if applicable)
[ ] Runbooks cover multi-region scenarios
[ ] Incident response includes region isolation as mitigation

COST:
[ ] Per-region cost breakdown
[ ] Data transfer costs between regions estimated: $___/month
[ ] Cross-region replication costs: $___/month
[ ] Total multi-region premium over single-region: ___% / $___/month

COMPLIANCE:
[ ] Data residency requirements met per region
[ ] GDPR: EU data stays in EU region
[ ] Data sovereignty: [other regional requirements]

Step 7 — Readiness Checklist

MULTI-REGION READINESS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Infrastructure deployed in all regions
[ ] Data replication configured and healthy
[ ] Traffic routing with failover tested
[ ] Deployment pipeline supports multi-region
[ ] Monitoring covers all regions
[ ] Failover procedure documented and tested
[ ] On-call team trained on multi-region procedures
[ ] Cost model reviewed and approved
[ ] Compliance requirements verified per region
[ ] Load testing completed in each region

Counter-Rationalizations

Shortcut	Counter	Why
"We can skip some steps for this case"	Adapt the workflow steps, don't skip them	Skipped steps are where incidents and oversights originate
"The user seems to already know what to do"	Complete all workflow phases with the user	The workflow catches blind spots that experience alone misses
"This is a minor case, full process is overkill"	Scale the process down, don't turn it off	Minor cases become major when unstructured; the process scales, not disappears
"I'll fill in the details later"	Complete each section before moving on	Deferred details are forgotten; real-time capture is more accurate
"The template output isn't necessary"	Always produce the structured output format	Structured output enables comparison, audit trails, and handoff to other teams

Output Format

Produce a multi-region deployment plan with:

1. Architecture overview (topology, regions, data flow)
2. Data replication strategy with consistency model
3. Traffic routing rules and failover configuration
4. Deployment pipeline design with per-region validation
5. Operational runbooks for failover, failback, and monitoring
6. Cost analysis for multi-region premium