DynamoDB point-in-time recovery: setup, restore and cost

DynamoDB point-in-time recovery (PITR) continuously backs up a table so you can restore its data to a chosen second within a configurable 1 to 35 day recovery window. The default window is 35 days, and the latest restorable time is typically about five minutes behind the present. A restore creates a new table; it does not rewind or overwrite the original.

What PITR protects against

PITR is useful when an application bug, mistaken batch write or accidental deletion damages data and you know approximately when it happened. Choose a restore point before the first bad change, restore into a separate table, validate the result and decide how to recover the application.

It is not an automatic application rollback. Orders accepted after the chosen restore time, messages already sent and changes in other services do not reverse themselves. For an e-commerce application, for example, recovering inventory to a historical point still requires reconciling orders and payment events created afterward.

The backup process does not consume the table's provisioned throughput. Keep using the source table while a restore runs, but decide how ongoing writes will be reconciled before switching traffic. The broader disaster recovery guide explains why historical recovery and regional failover solve different problems.

Understand the recovery window

Shortening the period removes older restore points from the available window. Increasing it does not immediately recreate history that was discarded or never collected; the history grows as time passes. Disabling and later re-enabling PITR starts a new recovery history, so do not toggle it as a harmless troubleshooting step.

Use the timestamps returned by DynamoDB rather than calculating an assumed window yourself. AWS documents these controls in how PITR works.

Enable PITR in the console

Open the table's Backups tab, edit point-in-time recovery, enable it and choose the recovery period. Confirm the setting after saving. You need permission to update continuous backups on the table.

The screenshots below show the older enablement workflow. Current controls also let you configure the recovery period, so the original checkbox-only screen is not the complete current interface.

Enable and inspect PITR with AWS CLI v2

This example explicitly retains the full 35-day window:

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 \
  --query 'ContinuousBackupsDescription.PointInTimeRecoveryDescription'
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 \
  --query 'ContinuousBackupsDescription.PointInTimeRecoveryDescription'

Inspect PointInTimeRecoveryStatus, RecoveryPeriodInDays, EarliestRestorableDateTime and LatestRestorableDateTime. A successful update request is not a substitute for checking the effective setting and available restore timestamps.

For an intentional shorter retention policy, run the update with the required RecoveryPeriodInDays. Treat that change as data-retention configuration, not a cost optimization.

CloudFormation and Terraform configuration

This complete CloudFormation resource creates an on-demand table with PITR and deletion protection:

Resources:
  Orders:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: Orders
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: pk
          AttributeType: S
      KeySchema:
        - AttributeName: pk
          KeyType: HASH
      PointInTimeRecoverySpecification:
        PointInTimeRecoveryEnabled: true
        RecoveryPeriodInDays: 35
      DeletionProtectionEnabled: true
Resources:
  Orders:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: Orders
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: pk
          AttributeType: S
      KeySchema:
        - AttributeName: pk
          KeyType: HASH
      PointInTimeRecoverySpecification:
        PointInTimeRecoveryEnabled: true
        RecoveryPeriodInDays: 35
      DeletionProtectionEnabled: true

The equivalent table settings in a current Terraform AWS provider are:

resource "aws_dynamodb_table" "orders" {
  name                        = "Orders"
  billing_mode                = "PAY_PER_REQUEST"
  hash_key                    = "pk"
  deletion_protection_enabled = true

  attribute {
    name = "pk"
    type = "S"
  }

  point_in_time_recovery {
    enabled                 = true
    recovery_period_in_days = 35
  }
}
resource "aws_dynamodb_table" "orders" {
  name                        = "Orders"
  billing_mode                = "PAY_PER_REQUEST"
  hash_key                    = "pk"
  deletion_protection_enabled = true

  attribute {
    name = "pk"
    type = "S"
  }

  point_in_time_recovery {
    enabled                 = true
    recovery_period_in_days = 35
  }
}

Do not manage the same table with both examples. Apply the setting through the infrastructure tool that already owns it, and review the plan for unrelated table changes. Keep the recovery period explicit so a later maintainer can distinguish intentional retention from a default.

Restore to a chosen time

First inspect the recoverable interval. Then choose a timestamp inside it, before the corruption occurred. The date below is illustrative and must be replaced with a valid point for your table:

aws dynamodb restore-table-to-point-in-time \
  --region us-east-1 \
  --source-table-name Orders \
  --target-table-name OrdersRecovered \
  --restore-date-time '2026-10-23T08:00:00Z'
aws dynamodb restore-table-to-point-in-time \
  --region us-east-1 \
  --source-table-name Orders \
  --target-table-name OrdersRecovered \
  --restore-date-time '2026-10-23T08:00:00Z'

For a copy at the latest available point, use --use-latest-restorable-time instead of --restore-date-time. Do not supply both. Inspect the destination with describe-table and wait for it to become ACTIVE before reading it.

A restore can take longer for larger tables and more indexes. Excluding unnecessary secondary indexes can help, but changes the destination's query capabilities. Do not plan on “a few seconds regardless of size.” Measure the procedure with production-like data and include validation and traffic cutover in the recovery-time estimate. See the restore procedure.

Cross-Region restoration

PITR also supports restoring into another Region in the same account. Call the restore operation in the destination Region and identify the source by its ARN:

aws dynamodb restore-table-to-point-in-time \
  --region us-west-2 \
  --source-table-arn arn:aws:dynamodb:us-east-1:123456789012:table/Orders \
  --target-table-name OrdersRecovered \
  --use-latest-restorable-time
aws dynamodb restore-table-to-point-in-time \
  --region us-west-2 \
  --source-table-arn arn:aws:dynamodb:us-east-1:123456789012:table/Orders \
  --target-table-name OrdersRecovered \
  --use-latest-restorable-time

Review destination encryption requirements, quotas and permissions first. Restore and applicable data-transfer charges are separate from the ongoing PITR charge. For cross-account copies, use an appropriate AWS Backup workflow or another supported data-copy method rather than assuming this API creates a table in any account.

What comes back, and what you must reconfigure

The restored data reflects the requested historical point. The restore API documents table settings such as indexes, provisioned capacity and encryption as coming from the source's current configuration at restore time, subject to supported overrides. Do not assume PITR is a historical snapshot of every configuration setting.

The restore API reference lists supported overrides and settings that need manual setup. Keep this configuration in a repeatable runbook. In particular, enabling TTL on historical data can make old items eligible for deletion again.

A restored global-table replica is a standalone table. Rebuilding replication is a separate operation; restoring one replica does not roll the entire global table back to a common instant.

PITR pricing

In US East (N. Virginia), PITR costs $0.20 per GB-month based on table data plus local secondary indexes. Restoring costs $0.15 per GB restored. These are separate from table storage and application read/write charges, and prices vary by Region. Check the DynamoDB pricing page for the deployment location.

For a table whose billable PITR size remains 100 GB for a full month, PITR is about $20. Restoring 100 GB is another $15, before destination storage, traffic and other charges. Reducing the window from 35 days to 7 days does not reduce that $20 PITR charge.

PITR vs on-demand backups

PITR provides many possible recovery points within its rolling window. An on-demand backup is a retained recovery point that can outlive that window. Use a backup before a major migration or for long-term retention; use PITR for selecting a point before an unexpected bad write. Scheduling, vault protection and cross-account backup copies are covered in backup and restore.

Neither option automatically merges recovered items into an existing table. For a small accidental deletion, restoring a separate table and selectively copying verified records can avoid discarding valid newer changes. For an entire-table recovery, plan the application configuration change and rollback path before cutover.

Deleted tables and recovery exercises

If a table with PITR enabled is deleted, DynamoDB retains a system backup named with the $DeletedTableBackup suffix for 35 days at no additional charge. That is useful recovery protection, but it should not be your only safeguard against deletion. Restrict destructive permissions and enable deletion protection before an incident.

During exercises, record the chosen recovery point, restore start and finish, settings reapplied, data checks and time until the application works. Verify important business records and index queries, not just the table's ACTIVE status. These observations establish whether PITR meets your application's recovery objectives.