Problem Description
You may notice unexpectedly high AWS infrastructure costs driven by a large volume of Amazon EBS snapshots prefixed with Phoenix_xxx_....
This article addresses:
Why these snapshots exist in your AWS environment.
How to safely reduce storage costs without impacting the integrity of your Disaster Recovery (DR) capabilities.
Cause
Automated Management: These EBS snapshots are automatically created, managed, and rotated by Druva DRaaS as part of your configured DR plans.
Frequency of Generation: Snapshots are generated regularly based on your DR plan schedules (e.g., immediately after backup, daily, or weekly).
DR Dependency: These snapshots are vital for continuous VM recovery and orchestration.
⚠️ CRITICAL WARNING: Do not manually delete these snapshots directly from the AWS Console. Doing so will corrupt orchestration metadata, break recovery points, and render your DR plans non-functional.
Resolution
To reduce AWS storage costs safely, you must modify your DR coverage directly within the Druva Management Console. When you remove non-critical Virtual Machines (VMs) from a DR plan, Druva automatically triggers a backend cleanup process to safely purge the associated EBS snapshots from AWS.
Steps to Remove a VM from a DR Plan
Log in to the Druva Management Console.
On the top menu bar, click the drop-down next to All Organizations and select the appropriate organization.
Navigate to Disaster Recovery from the main menu.
Select the target DR plan from the DR Plan dropdown list.
In the left navigation bar, click Virtual Machines.
Select the checkbox next to the VM(s) you wish to remove.
Click the More (three dots) icon or the Manage dropdown, and select Unconfigure / Remove from DR Plan.
Confirm the action when prompted.
Post-Change Behavior & Key Notes
Automated Cleanup: Once a VM is unconfigured, Druva initiates an automated background task to delete the corresponding EBS snapshots from your AWS account. Note: It may take up to 24 hours or until the next replication cycle for AWS billing metrics to reflect the storage drop.
Orchestration Data: Do not manually tamper with pre-flight/validation artifacts or metadata (such as VMX files) stored in your S3 buckets, as these are critical for DR recovery execution.
DR Readiness: Ensure that any VM requiring a recovery guarantee remains attached to at least one active DR plan.