DynamoDB backup and restore: snapshots, PITR and AWS Backup

DynamoDB provides on-demand backups for retained recovery points and point-in-time recovery (PITR) for restoring data within a rolling 1 to 35 day window. AWS Backup adds centralized scheduling, lifecycle management, vault controls and cross-account or cross-Region copies. Restoring a DynamoDB backup creates a new table; it does not replace items in an existing table.

Choose the protection that matches the failure

A backup protects a historical state. A replica follows current changes, including mistakes. For regional availability and wider failure scenarios, combine historical protection with an appropriate disaster recovery strategy.

Create an on-demand backup with AWS CLI v2

Use an identity allowed to create a backup of Orders. Capture the returned ARN rather than constructing one from the backup name:

BACKUP_ARN=$(aws dynamodb create-backup \
  --region us-east-1 \
  --table-name Orders \
  --backup-name OrdersBeforeMigration \
  --query 'BackupDetails.BackupArn' \
  --output text)

aws dynamodb describe-backup \
  --region us-east-1 \
  --backup-arn "$BACKUP_ARN" \
  --query 'BackupDescription.BackupDetails'
BACKUP_ARN=$(aws dynamodb create-backup \
  --region us-east-1 \
  --table-name Orders \
  --backup-name OrdersBeforeMigration \
  --query 'BackupDetails.BackupArn' \
  --output text)

aws dynamodb describe-backup \
  --region us-east-1 \
  --backup-arn "$BACKUP_ARN" \
  --query 'BackupDescription.BackupDetails'

Creation is asynchronous. Wait until BackupStatus is AVAILABLE before depending on the backup for a change window. Native backups consume no provisioned table throughput, and there is no daily count limit on on-demand backups, although API rate quotas still apply.

A backup is not an application-wide transaction snapshot

The CreateBackup API documents a capture boundary around the request: data committed more than a minute before the request is included, data committed more than a minute afterward is excluded, and writes in between may be included. It does not provide causal consistency across application activity.

If a migration needs a precisely coordinated state across several tables and external systems, pause writers or implement an application-level checkpoint. A backup request succeeding does not prove that a payment, an order and an external message all represent the same business instant.

Restore the backup into a new table

Use the actual backup ARN captured above:

aws dynamodb restore-table-from-backup \
  --region us-east-1 \
  --target-table-name OrdersRestored \
  --backup-arn "$BACKUP_ARN"

aws dynamodb describe-table \
  --region us-east-1 \
  --table-name OrdersRestored \
  --query 'Table.{Status:TableStatus,Arn:TableArn}'
aws dynamodb restore-table-from-backup \
  --region us-east-1 \
  --target-table-name OrdersRestored \
  --backup-arn "$BACKUP_ARN"

aws dynamodb describe-table \
  --region us-east-1 \
  --table-name OrdersRestored \
  --query 'Table.{Status:TableStatus,Arn:TableArn}'

The target name must not identify an existing table. Wait for ACTIVE, then verify the data and configuration before directing traffic to it. Restore time depends on the data and indexes; there is no universal seconds-long recovery promise.

DynamoDB permits up to 50 concurrent native backup/PITR restores, subject to an aggregate 50 TB in-flight size limit. AWS Backup restores have a separate 50-job, 25 TB aggregate limit. These are concurrency ceilings, not promises about completion time.

You can choose supported restore overrides, such as excluding secondary indexes or changing encryption. AWS also supports restoring a native backup to another Region; check destination permissions and key configuration. The restore tutorial describes these options. Cross-account recovery is a separate workflow, covered below.

AWS SDK for JavaScript v3 examples

Use @aws-sdk/client-dynamodb for backup and restore operations. These are table-management APIs, so the document client is not needed. This example creates a backup and prints its actual identifier:

import {
  DynamoDBClient,
  CreateBackupCommand,
  DescribeBackupCommand,
} from "@aws-sdk/client-dynamodb"

const client = new DynamoDBClient({ region: "us-east-1" })
const created = await client.send(new CreateBackupCommand({
  TableName: "Orders",
  BackupName: "OrdersBeforeMigration",
}))
const backupArn = created.BackupDetails.BackupArn
const description = await client.send(new DescribeBackupCommand({
  BackupArn: backupArn,
}))
console.log({ backupArn, status: description.BackupDescription.BackupDetails.BackupStatus })
import {
  DynamoDBClient,
  CreateBackupCommand,
  DescribeBackupCommand,
} from "@aws-sdk/client-dynamodb"

const client = new DynamoDBClient({ region: "us-east-1" })
const created = await client.send(new CreateBackupCommand({
  TableName: "Orders",
  BackupName: "OrdersBeforeMigration",
}))
const backupArn = created.BackupDetails.BackupArn
const description = await client.send(new DescribeBackupCommand({
  BackupArn: backupArn,
}))
console.log({ backupArn, status: description.BackupDescription.BackupDetails.BackupStatus })

A single describe call may still show CREATING. Persist the ARN and monitor until available. Then run a separate restore step:

import { DynamoDBClient, RestoreTableFromBackupCommand } from "@aws-sdk/client-dynamodb"

const client = new DynamoDBClient({ region: "us-east-1" })
if (!process.env.BACKUP_ARN) throw new Error("BACKUP_ARN is required")

const restored = await client.send(new RestoreTableFromBackupCommand({
  BackupArn: process.env.BACKUP_ARN,
  TargetTableName: "OrdersRestored",
}))
console.log(restored.TableDescription.TableArn)
import { DynamoDBClient, RestoreTableFromBackupCommand } from "@aws-sdk/client-dynamodb"

const client = new DynamoDBClient({ region: "us-east-1" })
if (!process.env.BACKUP_ARN) throw new Error("BACKUP_ARN is required")

const restored = await client.send(new RestoreTableFromBackupCommand({
  BackupArn: process.env.BACKUP_ARN,
  TargetTableName: "OrdersRestored",
}))
console.log(restored.TableDescription.TableArn)

Use normal SDK credential resolution, such as an assumed role, instead of embedding keys. Restrict backup deletion and restore administration separately from the application's item-writing role.

Enable PITR for continuous recovery points

PITR lets you choose the data recovery time rather than relying on a previously scheduled snapshot. Enable it before a problem occurs:

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

The same request and a latest-point restore in SDK v3 are:

import {
  DynamoDBClient,
  UpdateContinuousBackupsCommand,
  RestoreTableToPointInTimeCommand,
} from "@aws-sdk/client-dynamodb"

const client = new DynamoDBClient({ region: "us-east-1" })
await client.send(new UpdateContinuousBackupsCommand({
  TableName: "Orders",
  PointInTimeRecoverySpecification: {
    PointInTimeRecoveryEnabled: true,
    RecoveryPeriodInDays: 35,
  },
}))

// Run the restore later, after a restorable point is available.
// For corruption recovery, choose a verified earlier RestoreDateTime instead.
const restored = await client.send(new RestoreTableToPointInTimeCommand({
  SourceTableName: "Orders",
  TargetTableName: "OrdersPitrRestored",
  UseLatestRestorableTime: true,
}))
console.log(restored.TableDescription.TableArn)
import {
  DynamoDBClient,
  UpdateContinuousBackupsCommand,
  RestoreTableToPointInTimeCommand,
} from "@aws-sdk/client-dynamodb"

const client = new DynamoDBClient({ region: "us-east-1" })
await client.send(new UpdateContinuousBackupsCommand({
  TableName: "Orders",
  PointInTimeRecoverySpecification: {
    PointInTimeRecoveryEnabled: true,
    RecoveryPeriodInDays: 35,
  },
}))

// Run the restore later, after a restorable point is available.
// For corruption recovery, choose a verified earlier RestoreDateTime instead.
const restored = await client.send(new RestoreTableToPointInTimeCommand({
  SourceTableName: "Orders",
  TargetTableName: "OrdersPitrRestored",
  UseLatestRestorableTime: true,
}))
console.log(restored.TableDescription.TableArn)

Inspect DescribeContinuousBackups before restoring. The earliest point cannot predate enablement, and the latest point is typically about five minutes behind now. A shorter recovery window does not lower the PITR price. The PITR guide covers choosing a historical timestamp and all configuration examples.

If a PITR-enabled table is deleted, DynamoDB retains a system backup for 35 days at no additional charge. The older claim that deleted PITR tables cannot be recovered is incorrect. Existing retained on-demand backups also remain useful after source-table deletion, subject to access to their encryption keys.

AWS Backup: plans, vaults and lifecycle controls

Use AWS Backup when you need a common backup policy across resources rather than manual snapshots. A backup plan defines scheduling and retention; resource assignments identify the tables; vaults hold recovery points. Check that advanced DynamoDB backup features are enabled in the account and Region before configuring copies or cold storage.

With advanced DynamoDB backup, new backups can use cross-account and cross-Region copies, independent backup encryption, cost-allocation tags and cold-storage lifecycle rules. Enabling those features does not retroactively convert every old recovery point, so inspect the point you intend to copy.

A practical setup is:

1. Select the tables or an explicitly managed tag-based assignment.
2. Choose a backup schedule based on acceptable data loss, then set retention.
3. Choose the destination vault and backup service role.
4. Add copy rules for required Regions or accounts.
5. Run a backup and restore test, and alarm on failed or missing jobs.

The existing screenshots show an older console workflow; use them to recognize the concepts, not as exact current UI instructions.

Copy a backup across Regions or accounts

For an ordinary AWS Backup cross-account copy, the accounts must belong to the same AWS Organization and the required organization settings must be enabled. Create the destination vault, permit the copy in its access policy and configure the relevant KMS permissions. Advanced DynamoDB recovery points use AWS Backup's encryption management, so inspect the recovery-point type rather than assuming all old native backups have identical key behavior.

Select the completed recovery point, choose Copy, set the destination Region and vault, and configure retention. Wait for the copy job to complete. A submitted job is not yet an independent recovery point. In the destination account or Region, inspect the copied point and perform a restore there.

AWS documents the prerequisites and permission model in cross-account backup copies. A table resource policy by itself does not authorize the entire AWS Backup copy workflow.

For stronger deletion resistance, consider Vault Lock. Governance and compliance modes have different administrative escape paths. Review retention and test the plan before applying an irreversible compliance-mode lock; storage charges continue for retained recovery points.

What a restore does not finish for you

Restore reconstructs data and supported table/index configuration. It does not make the new table an operational replacement automatically. Reapply IAM and resource access, tags, auto scaling, alarms, Streams settings and consumer mappings, TTL, PITR, backup-plan coverage and deletion protection.

Do not treat references to Streams in backup metadata as a promise to resume the old stream or its consumer checkpoint. A new table's change processing needs explicit setup. Also confirm that application configuration points to the new name or ARN and that caches and downstream processors use the intended source.

Retained native backups can still require an old customer managed key after the source table has switched keys. Check encryption dependencies before removing a key or grant. A completed backup that cannot be decrypted is not a usable recovery path.

Backup and restore costs

These DynamoDB rates are for US East (N. Virginia):

For example, retaining a 100 GB native backup for a full month costs about $10; restoring 100 GB costs another $15. Multiple retained backups and destination copies add storage. New table storage, applicable transfer and KMS charges are separate. Check DynamoDB pricing for the relevant Region.

AWS Backup cold storage has a 90-day minimum retention charge, with early deletion charges where applicable. Its storage, retrieval, copy and restore rates belong to the AWS Backup pricing page. Do not assume a cold-storage plan has the same recovery cost and timing as a warm native backup.

Dynobase backups and data exports

The Dynobase backup manager provides an interface for on-demand backups. Use it when you want to inspect and manage those recovery points without repeating CLI commands.

A local JSON or CSV export is a different artifact. It can be useful for an independent data copy or selected-record recovery, but it does not automatically preserve table settings or provide a point-in-time-consistent snapshot. When reimporting, check the destination schema, data types and overwrite behavior. Writing records into an existing table is a migration operation; native backup restore still creates a new table. For large transfers and native S3 import, use the table-copy guide.