A parks department DynamoDB table accumulates ephemeral push-notification receipts that are useless after a few days and keep growing storage cost. Which control best limits that spend?

Parks department push-notification receipts that become useless after a few days are ephemeral items: they create storage growth and backup/restore bloat if retained forever. DynamoDB Time to Live (TTL) lets the team set an expiration attribute (for example, receipt timestamp plus retention days) so DynamoDB deletes expired items automatically in the background. That controls table size and storage cost without writing custom Lambda sweepers or scheduled DELETE fleets, and it keeps the notification audit trail aligned to the business retention policy for short-lived delivery receipts.

Converting the table to an unpartitioned Amazon RDS Multi-AZ deployment for cheaper ephemeral rows fails by concept: Multi-AZ relational HA and instance hours typically cost more for simple receipt key-value data, and RDS does not magically make ephemeral cleanup free. Nightly cross-Region replication of every receipt increases storage and inter-Region transfer charges while keeping expired data longer. Storing receipts only on an EC2 instance store volume with no backups forever fails durability and manageability—instance store is host-local ephemeral disk, not a departmental notification system of record.

Exam caveat: TTL deletes are eventually processed and are not a substitute for immediate cryptographic erasure SLAs when policy requires synchronous purge; also TTL is not a backup tool—items expire from the table.

Operational check: add a numeric epoch expiry attribute, enable TTL on that attribute, sample item age versus table size in CloudWatch (ItemCount, TableSizeBytes), confirm notification consumers tolerate missing expired receipts, and verify month-over-month DynamoDB storage cost declines as the parks campaign backlog ages out.