DynamoDB disaster recovery: backups, replicas and failover

DynamoDB disaster recovery usually combines historical backups for data corruption with global tables for regional availability. PITR restores a past state into a new table, while global tables maintain live replicas in other Regions. Choose the design using your recovery point objective (acceptable data loss) and recovery time objective (acceptable downtime), then test the complete application's recovery.

Start with the failure you need to survive

A single-Region DynamoDB table already has managed resilience across Availability Zones. A regional application outage, account compromise, accidental item deletion and a broken deployment are different failures, and one control does not resolve all of them.

For example, replicating an accidental DeleteItem to another Region makes both replicas current but does not recover the item. A backup can recover its earlier state, but restoring the backup does not immediately make the application available in another Region. Plan historical recovery and traffic failover together.

RPO and RTO are application objectives

Recovery point objective (RPO) expresses how much data loss you can tolerate, usually as a period. A daily snapshot may leave almost a day's changes to reconcile. PITR's latest recoverable timestamp is usually closer to the present, but it is still not “now.”

Recovery time objective (RTO) expresses how long the service may be unavailable. Count detection, decision-making, provisioning, restore, validation, routing changes and backlog processing. A database restore finishing is only one part of that timeline.

Define both values per business capability. A catalog may tolerate stale descriptions while order placement needs stricter handling of acknowledged writes. Document how the application behaves during recovery: read-only service, rejected writes, queued work or complete failover.

Choose an AWS recovery pattern

These patterns describe the whole workload. A global table can support an active/passive application as well as active/active traffic. Increasing readiness generally increases ongoing cost; the benefit must be demonstrated in a drill rather than inferred from a generic recovery-time chart.

Global tables: MREC vs MRSC

Current global tables support multi-Region eventual consistency (MREC) and multi-Region strong consistency (MRSC). Choose the consistency mode when creating the global table; it cannot be changed afterward. The global tables guide provides the detailed design options.

MREC: low replication lag is not a zero-loss guarantee

MREC changes normally replicate quickly, but there is no fixed replication-latency SLA. A write acknowledged in a failed Region may not yet be present in the surviving replica. Monitor ReplicationLatency, design retry and conflict behavior, and decide which Region may write during an evacuation.

If your application requires a single authoritative writer, enforce that at the application-routing layer. Giving every replica write capability does not mean every business workflow can safely accept concurrent conflicting updates. AWS's global-table design guidance connects consistency with routing and evacuation choices.

MRSC: zero RPO does not mean zero RTO

MRSC acknowledges writes after synchronous replication to at least one other Region and provides strongly consistent reads across replicas. It requires exactly three Regions: either three replicas or two replicas and a witness. The witness participates in coordination but is not a table your application can read or write.

The topology starts from an empty table, and the participating Regions must be supported for MRSC. MRSC does not support transactions, TTL or local secondary indexes. Its write and strongly consistent read latency tradeoffs must fit the workload. Review MRSC behavior before choosing it solely for its RPO.

Even with no acknowledged data loss, clients must reach a healthy application and replica. Authentication, queues, secrets, external services and deployment configuration can still prevent recovery. Do not report an “instant” application recovery based on replication alone.

Multi-account global tables

Current-version MREC global tables can place replicas in different accounts. Each account owns its local replica and participates in the replication group. This provides account-level administrative boundaries, but replication still propagates data changes; it is not an immutable backup against a destructive writer.

MRSC remains same-account only. The global-table account comparison describes the ownership and governance differences. Plan permissions, keys, costs and recovery responsibility for each account.

Provision and verify replicas before an incident

For an MREC table, create the source table, configure the intended replicas, and wait for each to become available. Replica creation and initial data backfill take time; do not rely on creating them during the outage. Test the application against each regional table before treating it as a standby.

These older console screenshots illustrate the MREC table-and-replica workflow, not an MRSC topology setup or a guaranteed provisioning time:

Review protection settings on every replica. PITR, deletion protection, tags and resource policies are not simply synchronized with all other global-table settings. A replica's existence does not prove it has equivalent backup or access controls.

PITR recovers from logical corruption

PITR provides a configurable 1 to 35 day window, with 35 days as the default. It cannot recover data from before it was enabled. Enable it in advance and record the available recovery timestamps during an incident:

aws dynamodb update-continuous-backups \
  --region us-east-1 \
  --table-name Orders \
  --point-in-time-recovery-specification \
    PointInTimeRecoveryEnabled=true,RecoveryPeriodInDays=35

aws dynamodb describe-continuous-backups \
  --region us-east-1 \
  --table-name Orders
aws dynamodb update-continuous-backups \
  --region us-east-1 \
  --table-name Orders \
  --point-in-time-recovery-specification \
    PointInTimeRecoveryEnabled=true,RecoveryPeriodInDays=35

aws dynamodb describe-continuous-backups \
  --region us-east-1 \
  --table-name Orders

The old console screenshots below locate the feature; current configuration also supports a recovery-period selection.

Choose a point before the first damaging change, restore into a new table and validate business records. If only a few items were damaged, copying verified records back can preserve valid newer writes. If replacing the table, reapply settings and route the application deliberately. The PITR walkthrough covers the restore and post-restore checklist.

Retained backups and AWS Backup

On-demand backups preserve recovery points outside the PITR window. AWS Backup adds scheduling, lifecycle rules, cross-Region and cross-account copies, and vault protections. Separate backup administration from application administration so a compromised writer cannot delete every recovery point.

These historical screens show creating a backup and moving from an ad hoc backup toward a scheduled plan:

Test restoration in the destination account and Region, not only backup creation in the source. Check vault policies, retained encryption keys and a role that remains usable during the assumed incident. The backup and restore guide covers prerequisites, costs and copy verification.

Enable deletion protection and protect its administration

Deletion protection prevents a table from being deleted while enabled. It does not stop item deletion, and a sufficiently privileged identity can disable it first. Enable it explicitly on production tables, restored tables and each required replica:

aws dynamodb update-table \
  --region us-east-1 \
  --table-name Orders \
  --deletion-protection-enabled
aws dynamodb update-table \
  --region us-east-1 \
  --table-name Orders \
  --deletion-protection-enabled

Restrict who may change that setting, delete backups or schedule key deletion. AWS documents deletion protection under table operations. Pair prevention with independently protected recovery points.

Custom replication and data exports

A Streams consumer can copy changes to another table when you need transformations or a different schema. That pipeline must handle initial loading, retries, duplicates, ordering, deletes and lag. It does not automatically have global tables' consistency behavior, and it is not a substitute for a retained backup.

Dynobase's scheduled local exports can provide accessible data files for a supplementary workflow. Test their completeness and reload procedure. A local export is not automatically a consistent snapshot or a backup of table configuration.

Budget for protection and for recovery

In US East (N. Virginia), native on-demand backup storage costs $0.10 per GB-month, PITR costs $0.20 per GB-month, and restore costs $0.15 per GB. Backup and PITR sizing includes table data plus LSIs. A shorter PITR window does not lower its price.

Global tables add replicated writes, replica storage, reads and applicable transfer. Adding a replica also has a restore charge, so “no upfront commitment” does not mean replica creation is free. AWS Backup copies and cold storage have their own billing details. Use current DynamoDB pricing for your Regions, and include the application standby infrastructure and recovery exercises in the budget.

A recovery runbook to exercise

1. Detect and classify. Identify whether the problem is regional availability, corrupted data or compromised access. Preserve relevant audit evidence.
2. Contain. Stop the bad writer or isolate the failing path. Avoid replaying corruption into the recovery destination.
3. Select a destination and recovery point. Confirm the healthy replica or usable backup and its data-loss implications.
4. Recover configuration. Reapply permissions, tags, keys, capacity, streams, TTL, alarms and protection settings where a restore created a new table.
5. Validate. Read known business records, exercise indexes and confirm the application can perform its critical operations.
6. Cut over. Change application routing or table configuration and monitor errors, capacity and downstream processing.
7. Reconcile and fail back. Resolve queued or divergent work, verify the repaired environment and move traffic only after checks pass.

Measure the time spent in every step and compare it with the objective. Keep the source and recovery artifacts until reconciliation is complete. A drill should end with a working application and an explanation of any lost or replayed work, not merely a green backup job.