DynamoDB PITR backup storage cost is the charge for point-in-time recovery while the feature stays enabled. DynamoDB prices that backup from the size of the table, including table data and local secondary indexes. Shortening the recovery window does not shrink the bill. Turning the feature off does. Teams cut the window from the long end of the allowed range toward the short end, refresh the bill, and find the same backup line. The window changed what you can restore. It did not change the meter.
Rutagon sees this on tables that grew after a launch and never had the feature revisited. PITR was enabled because a runbook said to enable it. The table is now many times the size it was. The backup line tracks that size for as long as the status stays on. The capacity mode cost article is about read and write units. This one is the backup storage that sits beside them. Snapshot hoarding on a relational database is a cousin problem, covered in RDS snapshot storage cost. PITR is not a pile of snapshots you can delete one by one.
What DynamoDB PITR backup storage cost measures
The point-in-time recovery page states the rule. DynamoDB charges for PITR based on the size of each table, including table data and local secondary indexes. Changing the recovery window, including from 35 days to 1 day, does not reduce the price. The configured maximum recovery period does not change the price of having PITR on. DynamoDB monitors the size of tables that have PITR turned on, and you are billed until you turn PITR off on that table.
The disaster-recovery comparison in the DynamoDB documentation prices that continuous backup at $0.20 per GB-month, and it says those table figures are N. Virginia prices for on-demand capacity. A worked example on the DynamoDB pricing page uses the same unit: an average table size of 27 GB at $0.20 per GB-month. Do not copy the 27 GB into your forecast. Copy the unit, then multiply by the size of the tables that have PITR on, in the Region you pay. Other Regions are not promised that N. Virginia number. We look up the Region before we tell finance a dollar figure.
On-demand backups are a different line. The same comparison prices them at $0.10 per GB-month in that N. Virginia table, based on backup storage, not on "the feature is on." A restore is another charge in that table, $0.15 per GB, and it is one-time. People add the restore estimate to the monthly PITR number and panic, or they ignore PITR because they have never clicked restore. The monthly cost is the feature staying on. The restore cost arrives the day you use it.
meter: table data plus local secondary indexes, while PITR is on
window: 1 to 35 days, and a shorter window does not lower the price
unit: $0.20 per GB-month in the N. Virginia on-demand table
off_switch: PointInTimeRecoveryEnabled false, not a smaller RecoveryPeriodInDays
restore: a separate per-GB charge, and it creates a new table
ContinuousBackupsStatus is a trap in the API. The documentation says that status is enabled for a table and is not the PITR switch. PointInTimeRecoveryStatus is the switch, and it stays disabled until you enable PITR. A script that alerts on continuous backups status will mark every new table as a PITR cost. It is wrong. We read PointInTimeRecoveryStatus and RecoveryPeriodInDays.
Why shortening the window feels like it should work
The product lets you pick any recovery period from 1 day through 35 days. If you lower it, the earliest restore point moves in, and backups outside the new window are not recoverable. That is a real recovery change. It is not a billing change. The docs repeat the point because the console invites exactly this mistake. An operator tries to save money by sliding the window down and leaves the feature on. The GB-month continues at the size of the table.
Raising the window does not immediately extend the earliest restore point to the new length. The window is rolling. Lowering it does take effect on what you can restore. Write that down before you treat the slider as a cost control. If the business needs a day of recovery, a 35-day window is not buying extra safety that you are paying extra for. You are paying the same either way. The decision is whether PITR should be on, and for which tables.
Large items and local secondary indexes count. A table that looks modest in item count can be large in bytes, and the PITR meter follows bytes. A global secondary index is not what the PITR sentence lists. We do not invent a second copy in the forecast. We sum the table sizes DynamoDB is actually monitoring for tables whose PITR status is on, and we treat anything beyond that sentence as a Region price-list question rather than a guess.
Deleting the table is not the cost plan we recommend, but the docs describe what happens if you do it with PITR on. DynamoDB creates a system backup and retains it for 35 days at no additional cost, under a name that ends in a deleted-table marker. That is a safety copy, not a technique for shrinking the bill. The clean off switch is to disable PITR on the tables that do not need per-second restore.
Exports that read from the PITR window are another meter. Incremental export charges for data processed from those backups. Turning PITR on "so we can export" and leaving it on after the export is the same leak, plus the export's own charge. We split the two in the scorecard.
What we turn off, and what we keep
The inventory is every table, the PITR status, the recovery period, and the table size that feeds the GB-month. Tables that are caches, derived projections, or environments nobody restores can lose the feature. Tables that hold the system of record keep it, at the window the business can actually use, with the understanding that the window is not the price.
We do not disable PITR on a table the recovery runbook names unless the owner signs the recovery change. A shorter window and a disabled feature are different events. The first does not save money. The second does, and it removes per-second restore. The scorecard says which one we are proposing.
Restores always land in a new table. A cost model that assumes an in-place rewind will be wrong operationally and wrong on the one-time restore charge. We note that so a finance model does not hide the restore GB inside the monthly storage line.
AWS cloud infrastructure is where the setting belongs in the template. PointInTimeRecoveryEnabled set true on every table in a module is how the bill arrives in the next account someone stamps out. The module should take the flag from the environment. Production can default on. A scratch table should not inherit production's backup posture and then surprise someone at the size of a load test.
Rutagon's pass is the status, the size, the N. Virginia unit as a labeled example, and the Region's own price before anyone multiplies. We do not tell you to drop PITR on the tables you would actually restore. We tell you that sliding the window is not the savings, and that tables with the feature on are paying for their size until someone turns it off.
Frequently Asked Questions
Does a one-day recovery window cost less than a 35-day window?
No. The point-in-time recovery documentation says changing the window does not reduce the price, and the cost stays the same regardless of the period you choose. You lose the ability to restore to the days you cut, and you do not lose the GB-month. Disable PITR if the goal is to stop the backup storage charge.
What size is the DynamoDB PITR backup storage cost based on?
The size of each table that has PITR on, including table data and local secondary indexes. DynamoDB monitors that size while the feature is on. A pricing example multiplies an average table size by $0.20 per GB-month, and the disaster-recovery table labels that unit as an N. Virginia on-demand price. Use your table's size and your Region's price.
Is the continuous backups status the same as PITR?
No. The API keeps continuous backups status enabled on a table even when point-in-time recovery is off. The field that controls restore, and the charge, is the point-in-time recovery status. Alerting on the wrong field marks every new table as a PITR cost.
How is this different from an on-demand backup?
On-demand backups bill for the backups you keep, and the N. Virginia comparison prices that storage lower per GB-month than PITR. PITR bills because the feature is on, tied to live table size, not because you clicked backup. Deleting old on-demand backups does not turn off the PITR line. They are separate charges and can both be present.
What happens to the bill if we restore?
Restore is a separate per-GB charge in that same N. Virginia table, and the operation creates a new table. It does not replace the monthly PITR charge for having the feature on. Plan the one-time restore when you drill. Do not fold it into the GB-month and then wonder why the monthly line did not move.
Ask for an AWS cost diagnostic that lists tables with point-in-time recovery still on. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.