I would say this is working as intended - you're declaring the EBS volume resource and its lifecycle is being managed by Terraform.

Since what you're requested would lead to Terraform leaving unmanaged resources behind, what you may want to do is create the volume manually and use a data source to import its settings and work with it from there.

Looking at the original PR that introduced skip_destroy on the volume attachment resource, the intended use case is not to preserve the volume itself, but to skip the destruction of the actual attachment to the instance so that the filesystem can be left in a consistent state on an externally-managed volume when the instance is destroyed. If you declare the EBS volume as a resource on the same lifecycle then it's going to get destroyed regardless of the setting on the aws_ebs_volume_attachment.

The workaround is a bit cumbersome in my opinion.

In my case I've built a Jenkins server and the separate EBS volume for the data drive using terraform. In the event that we'll need to destroy the Jenkins server but wish to move the data drive to a new machine to be attached there we simply can't do so via Terraform, as the data drive is recommended to be destroyed when the Jenkins server is destroyed, even with skip_destroy=true set on aws_ebs_volume_attachment, and prevent_destroy=true on the aws_ebs_volume:

 terraform plan -destroy -var-file=./dev.tfvars  -target=aws_instance.jenkins-ci
Acquiring state lock. This may take a few moments...

<--snipped-->
Releasing state lock. This may take a few moments...

Error: Error running plan: 1 error(s) occurred:

* aws_ebs_volume.jenkins_data_vol: aws_ebs_volume.jenkins_data_vol: the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag

A solution for this would be good to see. For example, in cloudformation its possible to set a condition for some resources to keep them after a template is deleted.

it makes a lot of sense for ebs volumes, and to be able to maintain the volume id / mount point somewhere so that it can easily be reattached upon the next apply.

could you set the ebs and the instance on their own terraform states and make the ebs volume available to the instance via remote-state ? I will give this a test see if it works

@videte47 did your test work ?

Although this was problematic in my own scenario, ansible solved the problem in my workflow - https://medium.com/faun/attaching-a-persistent-ebs-volume-to-a-self-healing-instance-with-ansible-d0140431a22a

I concur, data IS more important than the Terraform state, you can recreate the resource, but not the data lost, just as AWS allows you to destroy an EC2 it warns volumes will not be destroyed that same behavior should be respected in Terraform.

It all depends on the use case. If you are deploying configuration as code and the instance deployed state is immutable, then you probably do want to delete the EBS volume more often than not.

If its being manually configured or its a remote workstation / cloud9 instance, then preservation of the EBS volume could more often be desirable.

ebs_block_device is capable of data persistence

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!