Long Stopped EBS Volume
AWS Resource Type:
Amazon Elastic Block Store (EBS)
Delete EBS volumes attached to long-stopped EC2 instances
EBS is a relatively expensive storage option (gp3 volumes cost over 3x the price of the equivalent S3 Standard storage capacity), yet many organizations have unused EBS volumes that are accumulating unnecessary costs. This FF identifies EBS volumes that are attached to EC2 instances that have been stopped for a long time, creates a snapshot of the volume, and then deletes the volume.
Criteria for identifying the opportunity:
This FF identifies EBS volumes that are attached to EC2 instances that have been stopped for at least 30 days. Specifically, the EC2 instance must not have logged any CloudWatch CPU utilization metrics for the last 30 days.
Potential savings (range in % on annual basis):
Because it creates a snapshot before deleting the unused volume, the savings realized by this FF are relative to the size of the unused volume that is deleted:
savings = volume_cost - snapshot_cost,
snapshot_cost = volume_size_in_GB * $0.05
and $0.05 per GB-month is the EBS snapshot storage pricing.
What happens when the Fixer is executed?
The Fixer creates a snapshot of the unused EBS volume on Amazon S3 and then deletes the volume. The parameters required to recreate the deleted EBS volume are attached to the volume’s snapshot as tags.
Is it possible to rollback once CloudFix implements the fixer?
Yes. There is no automated rollback, but the rollback can be executed manually by using the AWS CreateVolume API, the AWS CLI create-volume command, or the AWS Console to create an EBS volume using the snapshotId and the parameters specified in the snapshot’s tags. The volume can then be re-attached to the EC2 instance.
The following example shows how the rollback can be achieved using the AWS CLI:
aws ec2 create-volume --volume-type <tag-value:volume-type> --size <tag-value:volume-size> --availability-zone <tag-value:az> aws ec2 attach-volume --volume-id <from-previous-step> --instance-id <tag-value:ec2-instance> --device <tag-value:attachment-path>
Can CloudFix implement the fix automatically once I accept the recommendation?
Does this fix require downtime?