A municipality’s AWS Backup plan retains Amazon EBS snapshots forever, and storage costs grow every month even though policy only requires 35 days of operational recovery points. What change best addresses the cost of retention?
Select an answer to reveal the explanation.
Short Explanation
Forever snapshots are a forever bill. If policy says 35 days, right-size AWS Backup retention to 35 days and stop paying for ancient recovery points nobody will use. More forever copies, zero backups, or stuffing snapshots into metric streams don’t solve retention cost sanely.
Full Explanation
Right-sizing AWS Backup retention to the documented 35-day operational recovery requirement stops unbounded growth of forever-retained Amazon EBS snapshot storage. Backup cost scales with how long recovery points are kept and how many copies exist; when policy only needs 35 days, retaining forever is an avoidable municipal cost leak. Creating an additional forever copy of every snapshot in every Region without review multiplies storage spend and does not address the retention mismatch. Turning off all backups permanently eliminates restore capability and violates operational resilience expectations for city systems. Storing snapshot data inside Amazon CloudWatch metric streams only is not a backup mechanism and cannot restore EBS volumes. Exam caveat: distinguish operational retention, for example 35 days, from longer legal or archival requirements; some workloads need separate vault policies, but “forever by default” is rarely the right cost posture. Operational check: inventory Backup plans and vault retention settings, change retention to 35 days or the written policy, verify old recovery points expire as expected, and confirm a test restore still succeeds within the retained window before declaring savings realized.