This chapter covers DynamoDB Point-in-Time Recovery (PITR), a critical feature for building resilient architectures on AWS. PITR provides continuous, automatic backups of your DynamoDB tables, enabling you to restore to any point within the last 35 days with second-level granularity. For the SAA-C03 exam, this topic appears in roughly 5-10% of questions related to DynamoDB, often in scenarios involving accidental data deletion, compliance requirements, or disaster recovery. You must understand when to use PITR versus on-demand backups, how to enable it, its limitations, and the exact restoration process.
Jump to a section
Imagine a massive library with millions of books, constantly being checked in and out, moved between shelves, and even pages being rewritten. The library maintains a card catalog that records every single change: every book moved, every page edited, every checkout. But this catalog is huge and changes every second. The head librarian, concerned about accidents, decides to keep a special 'time capsule' version of the entire catalog every 5 minutes. She installs a machine that, once a day, takes a snapshot of the entire current catalog and stores it in a vault. But she also has a magical device that can look back in time: it can reconstruct the exact state of the catalog as it was at any moment in the past 35 days, by replaying the recorded changes from the last daily snapshot. If a patron accidentally deletes all books on a certain topic, the librarian can use the device to restore the catalog to exactly 10 minutes before the deletion, without affecting any other changes made after that point. The machine works by starting from the most recent daily snapshot before the target time, then applying all the recorded changes (additions, removals, modifications) in order until it reaches the exact timestamp requested. This process is invisible to patrons and doesn't interrupt normal operations. The library can even test the restoration on a separate table to verify it before making it live. This is DynamoDB Point-in-Time Recovery: continuous backups that allow you to restore your table to any second within the last 35 days, with no performance impact and no downtime.
What is DynamoDB Point-in-Time Recovery?
DynamoDB Point-in-Time Recovery (PITR) is a fully managed, continuous backup feature that automatically backs up your table data with per-second granularity. When enabled, DynamoDB maintains a rolling 35-day window of backup data, allowing you to restore your table to any specific second within that window. PITR is designed to protect against accidental writes or deletes, and it operates without any performance impact or downtime on your table.
PITR is distinct from on-demand backups. On-demand backups are full snapshots that you trigger manually or via automation. They persist until you delete them, and they have no retention limit. PITR, on the other hand, is continuous and automatically managed, with a fixed retention period of 35 days. You cannot extend this window. After 35 days, the backup data is permanently discarded.
How PITR Works Internally
When you enable PITR on a DynamoDB table, DynamoDB begins recording every single write operation (PutItem, UpdateItem, DeleteItem) to the table at the storage layer. This is not a separate process that consumes read/write capacity; it is integrated into the storage engine. DynamoDB captures a change log that records the before-and-after image of each item modification. This log is stored durably across multiple Availability Zones, just like the table data itself.
To enable point-in-time recovery, DynamoDB periodically takes incremental backups. These are not full copies of the table; rather, they are checkpoints that, combined with the change log, allow reconstruction of the table state at any point. The exact internal mechanism is proprietary, but the key behavior is:
DynamoDB continuously streams changes to an internal change log.
It maintains periodic snapshots (at least every 5 minutes) that serve as recovery bases.
When you request a restore to a specific timestamp, DynamoDB selects the most recent snapshot before that timestamp, then replays all changes from the change log up to the exact second requested.
This means the earliest point you can restore to is within the last 35 days, and the latest point is typically within the last 5 minutes (due to snapshot granularity). You cannot restore to a time less than 5 minutes ago because there might not be a snapshot covering that exact moment.
Key Components, Defaults, and Timers
Retention Period: Fixed at 35 days. Cannot be changed. After 35 days, backup data is automatically deleted.
Earliest Restorable Time: This is the earliest point in the 35-day window for which a restore is possible. It is automatically calculated and displayed in the DynamoDB console (e.g., "Earliest restore time: 2024-12-01 15:20:34 UTC"). It is typically the time when PITR was enabled, or 35 days ago, whichever is later.
Latest Restorable Time: Usually within the last 5 minutes. There is a small delay (up to 5 minutes) between when a write occurs and when it becomes restorable.
Backup Storage: PITR backup data is stored in the same AWS Region as the table. It does not count toward your table's provisioned capacity or storage limits. There is no additional charge for storage; you pay only for the PITR feature itself (per GB per month of backup data).
Cost: PITR pricing is based on the amount of backup data stored, which is roughly the size of the table plus the change log. As of the exam, it is $0.20 per GB per month (subject to change). This is separate from on-demand backup costs.
Configuration and Verification
You can enable PITR via the AWS Management Console, AWS CLI, or SDK. The CLI command to enable PITR on an existing table is:
aws dynamodb update-continuous-backups \
--table-name MyTable \
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=TrueTo check if PITR is enabled:
aws dynamodb describe-continuous-backups \
--table-name MyTableThe response includes a ContinuousBackupsDescription object with a PointInTimeRecoveryDescription that shows the status (ENABLED or DISABLED) and the earliest restorable time.
To restore a table to a point in time:
aws dynamodb restore-table-to-point-in-time \
--source-table-name MyTable \
--target-table-name MyTableRestored \
--use-latest-restorable-timeOr specify an exact timestamp:
aws dynamodb restore-table-to-point-in-time \
--source-table-name MyTable \
--target-table-name MyTableRestored \
--restore-date-time 2024-12-15T10:30:00ZInteraction with Related Technologies
DynamoDB Streams: PITR is independent of DynamoDB Streams. Streams capture changes in near real-time for event-driven processing, while PITR is for backup and restore. Both can operate simultaneously without conflict.
On-Demand Backups: You can use both PITR and on-demand backups. On-demand backups are useful for long-term retention beyond 35 days. PITR provides fine-grained recovery within the 35-day window.
Global Tables: PITR is supported on global tables, but you must enable it separately on each replica table. When you restore a global table, the restored table is a standalone table in the same region; it is not automatically part of the global table configuration. You would need to add it back to the global table if needed.
AWS Backup: AWS Backup can manage DynamoDB on-demand backups but does not manage PITR. PITR is a DynamoDB-native feature and cannot be controlled via AWS Backup.
TTL (Time to Live): PITR respects TTL deletions. If an item is deleted by TTL, that deletion is recorded and can be restored as part of the backup. However, if you restore a table to a point before the TTL deletion, the item will reappear.
Limitations
PITR cannot be disabled and re-enabled on the same table within 30 minutes. There is a cooldown period.
You cannot restore to a time within the last 5 minutes (approximately).
The restored table is always a new table; you cannot restore in-place. You must then rename or switch your application to point to the new table.
Secondary indexes (GSI and LSI) are restored automatically, but they may take some time to backfill. The restore process creates the indexes and then populates them asynchronously.
Encryption at rest (AWS KMS) settings are preserved: the restored table uses the same KMS key as the source table.
Auto Scaling settings are not restored; you must reconfigure them on the new table.
The restored table has the same provisioned capacity (read/write capacity units) as the source table at the time of restore, but if you use on-demand capacity, the restored table will also be on-demand.
Exam-Relevant Details
PITR is enabled at the table level, not the account level.
You can have PITR enabled on up to 100 tables per account (soft limit, can be increased).
The restore process is asynchronous. You can monitor the table status via the console or CLI.
The restored table has a new ARN. Your application must be updated to use the new table name or ARN.
PITR does not protect against accidental table deletion. If you delete the table, all PITR data is also deleted. To protect against table deletion, use deletion protection or AWS Backup.
PITR is available in all AWS Regions, including China and GovCloud.
The backup data is stored in the same region as the table. For cross-region disaster recovery, you must use on-demand backups and copy them to another region.
Summary of Internal Mechanism
DynamoDB continuously logs all write operations to an internal change log.
Periodic snapshots (at least every 5 minutes) are taken to create recovery points.
When a restore is requested, DynamoDB selects the nearest snapshot before the target time.
It replays the change log from that snapshot up to the exact second requested.
A new table is created with the reconstructed data.
The process is fully managed and does not affect the source table.
Enable PITR on the table
The first step is to enable PITR on your DynamoDB table. You can do this via the AWS Management Console (under the 'Backups' tab), the AWS CLI (`update-continuous-backups`), or an SDK. Once enabled, DynamoDB immediately begins recording all write operations. There is no downtime or performance impact. You can verify the status using `describe-continuous-backups`. Note that there is a 30-minute cooldown if you disable and re-enable PITR on the same table.
Wait for backup data accumulation
After enabling PITR, DynamoDB starts building the change log and periodic snapshots. The earliest restorable time will be the time when PITR was enabled (or 35 days ago if it was enabled earlier). Over time, the window extends to cover the last 35 days. The change log grows, but storage costs are incurred. You cannot restore to a time before PITR was enabled or to a time less than 5 minutes ago due to snapshot granularity.
Initiate a point-in-time restore
When you need to recover data, you initiate a restore using the `restore-table-to-point-in-time` API. You specify the source table and a target table name (must be unique in the region). You can choose either the latest restorable time or a specific timestamp within the 35-day window. The restore is asynchronous and creates a new table. The source table remains fully available.
DynamoDB reconstructs the table state
DynamoDB internally selects the most recent periodic snapshot before the target timestamp. It then replays the change log from that snapshot forward, applying all writes (Put, Update, Delete) in chronological order until it reaches the exact target time. This process reconstructs the exact state of every item at that moment. The reconstructed data is written to a new table. Secondary indexes are also created and populated asynchronously.
Verify and point application to restored table
Once the restore completes, the new table appears in the console with a status of ACTIVE. You should verify the data integrity by querying the table. Then, update your application configuration to point to the new table name or ARN. The restored table has the same provisioned capacity as the source at the time of restore, but you may need to adjust capacity or re-enable auto-scaling. Finally, consider deleting the old table if it is no longer needed, but be careful not to delete it prematurely.
Enterprise Scenario 1: Accidental Bulk Deletion
A large e-commerce company uses DynamoDB to store user shopping carts. A developer accidentally runs a script that deletes all cart items for users in a certain region. The company has PITR enabled on the Carts table. The operations team identifies the exact time of the deletion (14:32:15 UTC). They restore the table to 14:32:00 UTC, just before the deletion. The restore takes about 10 minutes for a 100 GB table. After verification, they update the application's DynamoDB endpoint to point to the new table. The company avoids a major customer impact. They also implement stricter IAM policies to prevent similar accidents.
Enterprise Scenario 2: Compliance and Auditing
A financial services firm must retain transaction data for 7 years to comply with regulations. They use PITR for operational recovery (35-day window) and combine it with on-demand backups that they copy to an S3 bucket using AWS Backup for long-term retention. They schedule a daily on-demand backup and copy it to a separate region for disaster recovery. PITR allows them to recover from accidental changes within the last 35 days, while the on-demand backups satisfy the 7-year retention requirement. They also enable DynamoDB Streams to feed into a separate audit table for real-time monitoring.
Scenario 3: Testing with Production Data
A gaming company needs to test a new feature against production data without risking the live environment. They use PITR to restore a copy of their PlayerScores table to a point in time (e.g., last night at midnight). They create a new table named PlayerScoresTest and run their performance tests against it. Since the restored table is isolated, they can safely experiment. After testing, they delete the test table. This approach is faster and cheaper than restoring from a full on-demand backup because PITR restore is incremental and doesn't require storing a separate backup file.
Common Pitfalls
Restoring to a time within the last 5 minutes: The restore will fail or return a table that is not up to date. Always use the latest restorable time or a timestamp at least 5 minutes old.
Forgetting to update application config: The restored table has a new name and ARN. If you don't update your application, it will still point to the old (corrupted) table.
Not re-enabling auto-scaling: The restored table inherits the provisioned capacity of the source at the time of restore, but auto-scaling settings are not preserved. You must reconfigure them to avoid throttling.
Assuming PITR protects against table deletion: It does not. If you delete the table, all PITR data is deleted. Use deletion protection or separate backups.
SAA-C03 Exam Focus on DynamoDB PITR
The SAA-C03 exam tests your understanding of PITR primarily in the context of disaster recovery and data protection. The relevant objectives are:
Domain 2: Resilient Architectures, Objective 2.3: Implement a disaster recovery strategy.
Domain 3: High-Performance Architectures, Objective 3.1: Determine high-performing and/or scalable storage solutions.
The exam expects you to know:
PITR retention is exactly 35 days (cannot be changed).
The granularity of restore is per second.
The latest restorable time is within the last 5 minutes.
PITR is enabled per table, not per account.
Restored tables are new tables; you cannot restore in-place.
PITR does not protect against table deletion.
For cross-region DR, use on-demand backups with cross-region copy, not PITR.
Common Wrong Answers and Traps
"PITR can restore to any point within the last 35 days, including the current moment." This is wrong because the latest restorable time is about 5 minutes behind real time.
"PITR can be used to restore a table in-place (overwrite)." Wrong. You must create a new table and then switch your application.
"PITR is enabled by default for all DynamoDB tables." Wrong. You must explicitly enable it.
"You can extend the PITR retention period to 90 days." Wrong. It is fixed at 35 days. For longer retention, use on-demand backups.
"PITR backs up data to a different region automatically." Wrong. PITR data is stored in the same region. Cross-region requires manual copy of on-demand backups.
Exam Tips
If a question asks for a solution to recover from accidental data modification within the last hour, PITR is the best answer. If the question asks for long-term retention (e.g., 1 year), choose on-demand backups with AWS Backup.
When comparing PITR to on-demand backups, remember: PITR is continuous and automatic with a 35-day limit; on-demand backups are manual and persistent.
PITR can be combined with DynamoDB Streams for real-time event processing, but they serve different purposes.
The exam may ask about restoring a global table. Remember that PITR on a global table restores only that replica; the restored table is standalone.
Know the CLI commands: update-continuous-backups, describe-continuous-backups, restore-table-to-point-in-time.
Cost: PITR costs per GB of backup data per month; on-demand backups cost per GB of backup storage per month (similar pricing).
DynamoDB PITR provides continuous backups with per-second granularity and a fixed 35-day retention period.
PITR must be explicitly enabled per table; it is not on by default.
The latest restorable time is typically within the last 5 minutes; you cannot restore to a time less than 5 minutes ago.
PITR creates a new table on restore; you cannot restore in-place.
PITR does not protect against table deletion; use deletion protection or on-demand backups for that.
PITR is region-specific; for cross-region disaster recovery, use on-demand backups with cross-region copy.
PITR costs $0.20 per GB per month of backup data (pricing subject to change).
PITR is independent of DynamoDB Streams; both can be used simultaneously.
When restoring a global table, the restored table is standalone and not part of the global table.
Auto Scaling settings are not preserved on restored tables; you must reconfigure them.
These come up on the exam all the time. Here's how to tell them apart.
Point-in-Time Recovery (PITR)
Continuous, automatic backups with per-second granularity
Retention period fixed at 35 days
Restore to any second within the retention window
No manual intervention required after enabling
Cannot protect against table deletion; backup data deleted with table
On-Demand Backups
Full snapshots triggered manually or via automation
Retention is indefinite until you delete the backup
Restore only to the exact time the snapshot was taken
Requires scheduling or manual triggers
Backup persists even if the table is deleted (unless you delete the backup)
Mistake
PITR is enabled by default on all DynamoDB tables.
Correct
PITR is not enabled by default. You must explicitly enable it per table. The exam often tests this: if a question assumes PITR is on, that is incorrect unless the scenario states it was enabled.
Mistake
PITR can restore a table to any second within the last 35 days, including the current second.
Correct
The latest restorable time is typically up to 5 minutes behind the current time. You cannot restore to a time within the last 5 minutes. The exam may present a scenario where data is corrupted 2 minutes ago and ask if PITR can recover it; the answer is no because it's within the 5-minute window.
Mistake
PITR protects against accidental table deletion.
Correct
PITR does not protect against table deletion. If you delete a table, all PITR backup data is also deleted. The exam tests this: to protect against deletion, you need deletion protection or on-demand backups stored in a separate account/region.
Mistake
You can restore a table in-place using PITR.
Correct
PITR always creates a new table. You cannot overwrite the existing table. You must then point your application to the new table. The exam may ask about the steps after restore; the correct answer includes updating application configuration.
Mistake
PITR retention period can be increased beyond 35 days by contacting AWS Support.
Correct
The 35-day retention period is fixed and cannot be changed. For longer retention, you must use on-demand backups or export to S3. The exam may present a scenario requiring 1-year retention; PITR alone is insufficient.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The maximum retention period is fixed at 35 days. You cannot extend it. For longer retention, you must use on-demand backups or export data to S3. The exam often tests this fact, so remember that 35 days is the limit.
No, the latest restorable time is typically up to 5 minutes behind the current time. This is due to the periodic snapshot mechanism (at least every 5 minutes). If you need to recover data from just a few minutes ago, you may need to use DynamoDB Streams or another mechanism. The exam may present a scenario where data is corrupted 2 minutes ago and ask if PITR can recover it; the correct answer is no.
No, PITR backup data is stored in the same region as the source table. For cross-region disaster recovery, you need to use on-demand backups and copy them to another region. The exam may ask how to achieve cross-region recovery; the answer is on-demand backups with cross-region copy, not PITR.
All PITR backup data is deleted along with the table. PITR does not protect against table deletion. To protect against accidental deletion, you should enable deletion protection on the table or use on-demand backups stored separately. The exam may test this distinction.
Yes, you can enable PITR on each replica table independently. However, when you restore a global table replica, the restored table is a standalone table in that region; it is not automatically part of the global table. You would need to add it back to the global table configuration if needed. The exam may ask about the implications of restoring a global table.
You can enable PITR via the AWS Management Console (under the Backups tab), the AWS CLI using `update-continuous-backups`, or the SDK. The CLI command is: `aws dynamodb update-continuous-backups --table-name YourTable --point-in-time-recovery-specification PointInTimeRecoveryEnabled=True`. There is no downtime or performance impact.
No, enabling PITR has no impact on the read/write performance or latency of your table. The backup process happens at the storage layer and does not consume provisioned capacity. This is a key advantage of PITR over manual backup processes.
You've just covered DynamoDB Point-in-Time Recovery — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?