InvalidRestoreTimeException

TL;DR — The RestoreDateTime you asked for is outside this table's point-in-time-recovery window. PITR lets you restore to any second within the recovery period (configurable between 1 and 35 days, at most the last 35 days) — but the window also can't start before PITR was enabled. Read the table's actual window from DescribeContinuousBackups and pick a time inside it, or pass UseLatestRestorableTime for "as recent as possible".

What it means

InvalidRestoreTimeException: An invalid restore time was specified.
RestoreDateTime must be between EarliestRestorableDateTime and
LatestRestorableDateTime.

Every PITR-enabled table carries a rolling window bounded by EarliestRestorableDateTime (up to the recovery period back, but never before PITR was switched on) and LatestRestorableDateTime (typically about 5 minutes before the current time). A restore request outside those bounds — too old, or too close to now — fails with this exception.

Why it happens

• The time is older than the recovery period — the incident you're recovering from happened before the window (35 days at most, less if a shorter period is configured).
• PITR was enabled recently — the window starts at enablement; you can't restore to before that moment even within 35 days.
• The time is too recent — LatestRestorableDateTime trails real time by ~5 minutes; "restore to 30 seconds ago" isn't in the window yet.
• Timezone/format slips — a local-time timestamp sent where UTC epoch seconds were intended lands outside the window without you noticing.

How to fix it

1. Read the actual window first:

   aws dynamodb describe-continuous-backups --table-name orders
   # ...PointInTimeRecoveryDescription:
   #    EarliestRestorableDateTime, LatestRestorableDateTime

2. Pick a RestoreDateTime inside it (epoch seconds, UTC), or take the newest available state without naming a time:

   aws dynamodb restore-table-to-point-in-time \
     --source-table-name orders --target-table-name orders-recovered \
     --use-latest-restorable-time

3. Need data older than the window? PITR can't reach it — fall back to an on-demand backup or a table export taken in that era, if one exists.

4. Remember what a restore doesn't carry — the new table gets data, indexes, capacity and encryption settings, but you must re-create auto scaling policies, IAM policies, CloudWatch alarms, tags, stream settings, TTL, and PITR itself.

After the restore lands, verify the recovered data before switching traffic — the DynoTable desktop app makes diffing the recovered table against expectations a browsing task, and the DynamoDB pricing calculator sizes the new table's capacity cost.

Related errors

• PointInTimeRecoveryUnavailableException — PITR isn't enabled at all.
• Export requires PITR — the export-time cousin of this window.
• Table already exists — the target name is taken.
• Learn: Backups & point-in-time recovery

References

• RestoreTableToPointInTime — Amazon DynamoDB API Reference
• DescribeContinuousBackups — Amazon DynamoDB API Reference
• Enable point-in-time recovery in DynamoDB — Amazon DynamoDB Developer Guide

Last verified 2026-07-13 against the official AWS documentation linked above.