MemoryDB Snapshots for MCP Servers

Automated snapshot configuration

MemoryDB automated snapshots are configured in the cluster definition with two parameters: snapshotRetentionLimit (how many daily snapshots to keep) and snapshotWindow (when the snapshot runs).

const cluster = new memorydb.CfnCluster(this, 'MemoryDbCluster', {
  clusterName: 'mcp-probes',
  // ...other parameters...
  snapshotRetentionLimit: 14,         // keep 14 daily snapshots (0 = disabled)
  snapshotWindow: '05:00-06:00',      // UTC; choose low-traffic period
  maintenanceWindow: 'sun:07:00-sun-08:00',  // must not overlap snapshot window
  finalSnapshotName: 'mcp-probes-final',     // taken on stack delete; omit = no final snapshot
});

Key configuration decisions:

• snapshotRetentionLimit = 0 disables automated snapshots entirely. This is the default. For any production cluster serving MCP server state, set a non-zero value before deploying.
• Snapshot window vs maintenance window: MemoryDB cannot run a snapshot and a maintenance operation simultaneously. If the windows overlap, one defers. Choose a 1-hour snapshot window and a separate 1-hour maintenance window, both during low-traffic periods.
• finalSnapshotName: when CloudFormation deletes a cluster (stack teardown, environment cleanup), a final snapshot is taken only if this parameter is set. Without it, cluster deletion is permanent with no recovery path. Always set finalSnapshotName on production clusters.

Snapshot storage cost

MemoryDB includes free snapshot storage equal to the total cluster data size (one snapshot's worth). Additional snapshot storage is charged at S3 rates (~$0.023/GB-month). For a 100GB cluster keeping 14 daily snapshots, the 13 additional snapshots cost approximately $30/month — modest relative to cluster costs for most MCP backends.

Manual snapshots for pre-maintenance checkpoints

Before a schema migration, a large key deletion job, or a software deployment that modifies probe state, take a manual snapshot:

# Take a manual snapshot before deployment
aws memorydb create-snapshot \
  --cluster-name mcp-probes \
  --snapshot-name mcp-probes-pre-deploy-2026-10-17

# Check snapshot status
aws memorydb describe-snapshots \
  --snapshot-name mcp-probes-pre-deploy-2026-10-17 \
  --query 'Snapshots[0].{Status:Status,CreationTime:CreationTime}'

# Output: {"Status": "Available", "CreationTime": "2026-10-17T10:00:00Z"}
# Status transitions: creating → available (typically 5-15 minutes for 10GB cluster)

Manual snapshots persist until you explicitly delete them — they are not subject to the snapshotRetentionLimit retention policy. Automated snapshots older than the retention window are deleted automatically; manual snapshots are not. For pre-deployment checkpoints, delete the manual snapshot once the deployment is stable to avoid accumulating storage costs.

Snapshot while traffic is live

MemoryDB snapshots are taken from a replica node, not the primary. This means the snapshot operation does not impact primary write performance. Replica reads may experience a brief latency spike while the RDB file is generated, but this is typically under 100ms and invisible to well-designed applications. The snapshot is eventually consistent — it captures a point-in-time state of the replica, which lags the primary by the replication delay (usually milliseconds).

Restoring from a snapshot

MemoryDB snapshot restore creates a new cluster — there is no in-place restore that overwrites an existing cluster's data. The restore process:

1. Provision a new cluster with the same (or compatible) configuration, pointing to the snapshot
2. Update your MCP server's connection endpoint to the new cluster
3. Verify data integrity
4. Delete the old cluster (with a final snapshot as a safety net)

# Restore from a manual snapshot to a new cluster
aws memorydb create-cluster \
  --cluster-name mcp-probes-restored \
  --node-type db.r7g.large \
  --acl-name mcp-probes-acl \
  --subnet-group-name mcp-probes-memorydb \
  --security-group-ids sg-0123456789abcdef \
  --tls-enabled \
  --snapshot-name mcp-probes-pre-deploy-2026-10-17 \
  --num-shards 2 \
  --num-replicas-per-shard 1

# Wait for cluster to be available
aws memorydb describe-clusters \
  --cluster-name mcp-probes-restored \
  --query 'Clusters[0].Status'

Important restore constraints:

• Number of shards: you can restore to a cluster with the same or more shards than the source. Restoring to fewer shards fails — MemoryDB cannot re-shard during restore.
• Engine version: you cannot restore a Redis 7.1 snapshot to a Redis 6.2 cluster. Upgrades are supported; downgrades are not.
• ACL must be pre-existing: the restore operation references an ACL by name. The ACL must exist and be in ACTIVE state before the restore cluster can start. The ACL is not cloned from the source cluster.
• No PITR: MemoryDB does not support point-in-time restore (unlike RDS). You recover to the snapshot time, not an arbitrary minute between snapshots. For workloads requiring finer-grained recovery, consider supplementing with application-level event sourcing or write-ahead logging to S3.

Cross-region snapshot copy for disaster recovery

MemoryDB does not support live cross-region replication (unlike ElastiCache Global Datastore). Cross-region disaster recovery uses snapshot export + import:

# Step 1: copy snapshot to an S3 bucket in the destination region
# (MemoryDB cross-region copy goes via S3 intermediary)
aws memorydb copy-snapshot \
  --source-snapshot-name mcp-probes-daily-2026-10-17 \
  --target-snapshot-name mcp-probes-us-west-2-2026-10-17 \
  --target-bucket arn:aws:s3:::mcp-probes-dr-snapshots-us-west-2 \
  --kms-key-id arn:aws:kms:us-west-2:123456789:key/dr-key

# The target-bucket must be in the destination region
# KMS key must be in the destination region if using CMK encryption

# Step 2: in the destination region, restore from the S3 snapshot
aws memorydb create-cluster \
  --region us-west-2 \
  --cluster-name mcp-probes-dr \
  --node-type db.r7g.large \
  --acl-name mcp-probes-acl \               # this ACL must exist in us-west-2
  --subnet-group-name mcp-probes-memorydb \  # this subnet group must exist in us-west-2
  --security-group-ids sg-abcdef1234567890 \
  --tls-enabled \
  --snapshot-arns arn:aws:s3:::mcp-probes-dr-snapshots-us-west-2/mcp-probes-us-west-2-2026-10-17.rdb \
  --num-shards 2 \
  --num-replicas-per-shard 1

The RTO for cross-region restore depends on cluster size and snapshot size — typically 20–60 minutes for a 10–100GB cluster. For MCP servers requiring sub-5-minute RTO across regions, MemoryDB is not the right primitive — consider DynamoDB Global Tables or a multi-region write architecture with a writable copy in each region.

Migrating from ElastiCache Redis to MemoryDB

Migrating from ElastiCache to MemoryDB is a common upgrade path when an MCP server's probe state or session store grows into a primary database. The migration uses ElastiCache's RDB backup export combined with MemoryDB's snapshot import.

Migration steps (non-zero downtime)

1. Export ElastiCache RDB to S3: ElastiCache supports manual backup and export to S3 for Redis clusters with backup enabled. Enable backup on your ElastiCache cluster, wait for a backup to complete, then note the S3 path of the RDB file.
2. Validate RDB compatibility: MemoryDB requires the RDB file to be from Redis 6.2 or earlier format. If your ElastiCache cluster uses Redis 7.x, check the RDB version compatibility before importing.
3. Restore MemoryDB cluster from the RDB snapshot ARN:

# After ElastiCache exports RDB to s3://my-backup-bucket/elasticache-export/
aws memorydb create-cluster \
  --cluster-name mcp-probes-migrated \
  --node-type db.r7g.large \
  --acl-name mcp-probes-acl \
  --subnet-group-name mcp-probes-memorydb \
  --security-group-ids sg-0123456789abcdef \
  --tls-enabled \
  --snapshot-arns arn:aws:s3:::my-backup-bucket/elasticache-export/my-cluster.rdb \
  --num-shards 2 \
  --num-replicas-per-shard 1

Zero-downtime migration with dual-write

For production MCP servers that cannot tolerate a maintenance window:

1. Import the ElastiCache RDB into a new MemoryDB cluster (catches up to the point of the RDB export)
2. Enable dual-write in your MCP server: all writes go to both ElastiCache and MemoryDB simultaneously
3. Backfill the delta: any writes after the RDB export time replay from your application's write log or event stream to MemoryDB
4. Switch reads to MemoryDB and validate data consistency
5. Remove the ElastiCache write path once read traffic is stable on MemoryDB

The dual-write phase adds latency because both writes must succeed before the operation is acknowledged. Size this window carefully — typically a few hours for an MCP server with moderate write volume.

How AliveMCP monitors snapshot health

A cluster with snapshotRetentionLimit = 0 (no automated backups) is operationally risky for MCP server state stores. AliveMCP's infrastructure health check includes a backup status verification:

• Snapshot staleness alert: if the most recent automated snapshot for your MemoryDB cluster is older than snapshotRetentionLimit + 2 days, AliveMCP raises a warning. This catches situations where the snapshot window conflicts with maintenance operations and snapshots silently stop running.
• Pre-deployment hook: AliveMCP's deployment integration can trigger a manual snapshot via the MemoryDB API before your CI/CD pipeline deploys a new MCP server version. The snapshot name includes the deployment ID, providing a clean rollback point if the new version corrupts state.
• Snapshot-count drift: for clusters with snapshotRetentionLimit = 14, AliveMCP expects to see 14 snapshots after the first two weeks. A sudden drop (to 1 or 0) indicates the cluster was recreated — possibly without finalSnapshotName, meaning a prior state loss event went undetected.

Snapshot monitoring is available on the Team tier as part of the infrastructure health dashboard alongside the MCP endpoint probes.