MPC disaster recovery

This page describes how to deploy MPC nodes to a secondary AWS region for disaster recovery (DR) purposes using the MPC Deployer tool.

This guide assumes you have completed the MPC deployment on AWS guide and have a working MPC cluster in your primary region.

Overview

In a disaster recovery scenario, you can deploy your customer MPC nodes (Node 2 and Node 3) to a secondary AWS region to maintain signing availability. The MPC Deployer's --disaster-recovery flag automates this process by:

Reading configuration from AWS Secrets Manager (which replicates to your secondary region)
Provisioning infrastructure in the secondary region
Deploying MPC nodes with the same key material as your primary region

Important

DR mode deploys additional MPC nodes. It does not replace your primary deployment. Both deployments share the same key material stored in AWS Secrets Manager.

Prerequisites

Before deploying to a secondary region, ensure you have:

Prerequisite	Description
Primary MPC deployment	A working MPC cluster deployed using the AWS deployment guide
Secondary region configured	The `secondaryRegion` field set in your Secrets Manager configuration during initial key generation
Secrets Manager replication	Your MPC configuration secret replicated to the secondary region
AWS credentials	Permissions to create resources in the secondary region

Verify Secrets Manager replication

Your MPC configuration secret must be replicated to the secondary region. To verify replication status:

aws secretsmanager describe-secret \
  --secret-id mpc-deployer-<TENANT_ALIAS>-<INSTANCE_CODE> \
  --region <PRIMARY_REGION>

Check that the ReplicationStatus array includes your secondary region with Status: InSync.

AWS Secrets Manager replication is configured automatically during the --keygen phase if you provide a secondary region. If replication is not enabled, contact your Ripple representative.

Pre-configured VPC requirements

If using the --no-create-vpc flag, ensure the following fields are set in your Secrets Manager configuration:

Field	Description
`awsPreconfiguredDrVpcId`	VPC ID in the secondary region
`awsPreconfiguredDrPrivateSubnet1Id`	First private subnet ID (in a different AZ than the second)
`awsPreconfiguredDrPrivateSubnet2Id`	Second private subnet ID (in a different AZ than the first)

The VPC must have:

Private subnets in at least two availability zones
NAT gateway or VPC endpoints for outbound connectivity to AWS services
Security groups allowing outbound HTTPS (443) and the MPC relay port

Deploy MPC nodes to the secondary region

Run the MPC Deployer with the --disaster-recovery flag to deploy nodes to your secondary region.

Step 1: Set environment variables

Configure your AWS credentials and tenant information:

export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"
export AWS_REGION="<SECONDARY_REGION>"
export TENANT_ALIAS="<your-tenant-alias>"
export TENANT_INSTANCE_CODE="<your-instance-code>"

Set AWS_REGION to your secondary region. The deployer reads configuration from the secondary region's Secrets Manager to do the deployment.

Step 2: Run the DR deployment

Option A: Auto-create VPC

The deployer creates all networking resources in the secondary region:

docker run --rm -it \
  -e AWS_ACCESS_KEY_ID \
  -e AWS_SECRET_ACCESS_KEY \
  -e AWS_REGION \
  -e TENANT_ALIAS \
  -e TENANT_INSTANCE_CODE \
  -v $(pwd)/output:/app/output \
  <RIPPLE_REGISTRY>/mpc-deployer:<VERSION> \
  --disaster-recovery --non-interactive

Option B: Use pre-configured VPC

The deployer uses your existing VPC and subnets in the secondary region:

docker run --rm -it \
  -e AWS_ACCESS_KEY_ID \
  -e AWS_SECRET_ACCESS_KEY \
  -e AWS_REGION \
  -e TENANT_ALIAS \
  -e TENANT_INSTANCE_CODE \
  -v $(pwd)/output:/app/output \
  <RIPPLE_REGISTRY>/mpc-deployer:<VERSION> \
  --disaster-recovery --non-interactive --no-create-vpc

Step 3: Verify deployment

After deployment completes, verify the DR nodes are running:

aws ec2 describe-instances \
  --region <SECONDARY_REGION> \
  --filters "Name=tag:Name,Values=*-dr" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Name:Tags[?Key==`Name`].Value|[0]}'

Check CloudWatch logs in the secondary region to confirm the nodes connected to the relay server.

DR mode behavior

Resource naming

All resources created in DR mode are suffixed with -dr to distinguish them from primary resources:

Resource type	Primary name example	DR name example
EC2 instance	`tenant-001-mpc-node-2`	`tenant-001-mpc-node-2-dr`
Security group	`tenant-001-enclave-sg`	`tenant-001-enclave-sg-dr`
IAM role	`tenant-001-enclave-role`	`tenant-001-enclave-role-dr`
CloudWatch log group	`/mpc/tenant-001/node-2`	`/mpc/tenant-001/node-2-dr`

Configuration mapping

The deployer maps configuration fields to the secondary region:

Configuration field	Used in primary mode	Used in DR mode
`region`	✓	—
`secondaryRegion`	—	✓
`awsPreconfiguredVpcId`	✓	—
`awsPreconfiguredDrVpcId`	—	✓
`awsPreconfiguredPrivateSubnet1Id`	✓	—
`awsPreconfiguredDrPrivateSubnet1Id`	—	✓
`awsPreconfiguredPrivateSubnet2Id`	✓	—
`awsPreconfiguredDrPrivateSubnet2Id`	—	✓

AMI selection

AMI IDs are region-specific. DR mode automatically looks up the correct Amazon Linux 2023 AMI in the secondary region using the same AMI name pattern as primary deployments.

Deprovision DR resources

To remove DR resources while keeping your primary deployment intact:

docker run --rm -it \
  -e AWS_ACCESS_KEY_ID \
  -e AWS_SECRET_ACCESS_KEY \
  -e AWS_REGION \
  -e TENANT_ALIAS \
  -e TENANT_INSTANCE_CODE \
  <RIPPLE_REGISTRY>/mpc-deployer:<VERSION> \
  --delete --disaster-recovery --non-interactive

If you used --no-create-vpc during deployment, include that flag when deleting:

docker run --rm -it \
  -e AWS_ACCESS_KEY_ID \
  -e AWS_SECRET_ACCESS_KEY \
  -e AWS_REGION \
  -e TENANT_ALIAS \
  -e TENANT_INSTANCE_CODE \
  <RIPPLE_REGISTRY>/mpc-deployer:<VERSION> \
  --delete --disaster-recovery --non-interactive --no-create-vpc