Dev and test DynamoDB tables paying for continuous point-in-time recovery backups
What does ZopNight detect here?
ZopNight flags DynamoDB tables with point-in-time recovery enabled that are tagged or named as dev, test, QA, staging or sandbox. DynamoDB bills PITR on table data plus local secondary indexes, $0.20 per GB-month in us-east-1, so the saving is that size times the regional rate, the whole PITR charge.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-100 |
| Category | rightsizing |
| Severity | low |
| Metric | none — pure configuration read |
| Threshold | PITR enabled and a dev/test tag or name |
| Source | ZopNight |
| Permissions used | dynamodb:ListTables · dynamodb:DescribeTable · dynamodb:DescribeContinuousBackups · dynamodb:ListTagsOfResource |
Where it applies
PITR is billed on the table’s size, whatever the window
Point-in-time recovery keeps continuous backups so a table can be restored to any second in its recovery window. DynamoDB charges for it on the size of each table, including table data and local secondary indexes, and it bills until you turn PITR off. Shortening the recovery period does not help: AWS states that changing the window, for example from 35 days to 1 day, does not reduce the price.
The AWS price list for US East (N. Virginia) sets PITR storage at $0.20 per GB-month. On-demand backups are $0.10 per GB-month and are only kept when you take them. A 500 GB test table with PITR on costs $100 a month for recovery nobody expects to use.
Checking PITR status and billable size
aws dynamodb describe-continuous-backups --table-name orders-dev \ --query 'ContinuousBackupsDescription.PointInTimeRecoveryDescription.PointInTimeRecoveryStatus'
aws dynamodb describe-table --table-name orders-dev \ --query 'Table.[TableSizeBytes,LocalSecondaryIndexes[].IndexSizeBytes]'Add the table size and any local secondary index sizes to get the PITR-billed footprint. Global secondary indexes are not part of it.
How a table is classed as non-production
- PITR is reported as enabled on the table.
- An environment tag (
env,environment,stageortier) says production: the table is never flagged, whatever its name. - Otherwise the table needs positive dev or test evidence, either from that tag or from its name containing dev, test, qa, staging or sandbox.
- The billable size is known and a PITR rate is available for the table’s Region.
Tables left out
A table with no environment signal at all is skipped, because PITR on it may be protecting real data. Missing size, a Region with no PITR rate, and savings below $5 a month also produce nothing. The rule never falls back to a built-in rate. Its RDS counterpart for automated backups is RDS PITR Enabled on Non-Production.
The PITR charge removed in full
PITR size GB = table data + local secondary indexessaving = PITR size GB x regional PITR rate per GB-monthcost after change = 0 for the PITR line itemThe table’s read, write and storage charges are unaffected, so only the PITR line is counted.
Switching PITR off for a dev or test table
- Confirm with the owner that the table can be rebuilt from seed data or a snapshot.
- If you want a safety copy first, take an on-demand backup:
aws dynamodb create-backup --table-name orders-dev --backup-name orders-dev-before-pitr-off - Disable PITR:
aws dynamodb update-continuous-backups --table-name orders-dev --point-in-time-recovery-specification PointInTimeRecoveryEnabled=false - Tag the table with its environment so future scans classify it without relying on its name.