# 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](/products/custody/v1.36/deployment/integrate-kms/mpc/aws-deployment) 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](/products/custody/v1.36/deployment/integrate-kms/mpc/aws-deployment) |
| **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:


```bash
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:


```bash
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:


```bash
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:


```bash
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:


```bash
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:


```bash
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:


```bash
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
```

Important
Deprovisioning removes all DR infrastructure in the secondary region. Your MPC configuration in AWS Secrets Manager is retained, allowing you to redeploy DR nodes if needed.

## Command reference

The following flags are specific to disaster recovery operations:

| Flag | Description |
|  --- | --- |
| `--disaster-recovery` | Deploy to the secondary region specified in your Secrets Manager configuration |
| `--delete` | Remove deployed resources (combine with `--disaster-recovery` to remove only DR resources) |
| `--no-create-vpc` | Use pre-configured VPC instead of creating networking resources |
| `--non-interactive` | Run without prompts (recommended for automated deployments) |


For a complete list of MPC Deployer flags, see [MPC deployment on AWS](/products/custody/v1.36/deployment/integrate-kms/mpc/aws-deployment#command-reference).

## Next steps

- **Verify connectivity**: Contact your Ripple representative to confirm DR nodes can participate in signing operations
- **Set up monitoring**: Configure CloudWatch alarms for DR node health in the secondary region
- **Test failover**: Periodically test your DR deployment by simulating primary region unavailability
- **Review backups**: Ensure you have [MPC backups](/products/custody/v1.36/deployment/integrate-kms/mpc/backups) configured for key shard recovery