terraform-provider-aws: aws_volume_attachment Error waiting for Volume

Terraform Version

Terraform v0.11.7

  • provider.aws v1.20.0

Affected Resource(s)

aws_volume_attachment

Actual Behavior

When running a terraform destroy, in which you want to destroy an aws_instance and it’s aws_volume_attachment, terraform (or the AWS API) will attempt to destroy the volume attachment first, then then instance second. This often fails because Error waiting for Volume (vol-010b3d979b1027867) to detach from Instance.

Expected Behavior

If an aws_volume_attachment was going to be destroyed, and the associated aws_instance was also going to be destroyed, it would make sense to destroy the instance first and then the aws_volume_attachment second, which would never run any risk of timing out.

Steps to Reproduce

  1. Create an aws_ebs_volume, an aws_instance, and a aws_volume_attachment.
  2. terraform destroy

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 80
  • Comments: 33 (1 by maintainers)

Commits related to this issue

Most upvoted comments

Same problem here. Only been a bug 19 months. Could we get Terraform to STOP instances with attached storage, DETACH/DELETE all volumes and then TERMINATE the instance? Seems like a fundamental function fails often in this circumstance.

Same issue for me

image

Facing the same issue here, we worked around it by including skip_destroy = true in resource aws_volume_attachment.

According to the documentation, setting skip_destroy = true will remove resource aws_volume_attachment from the state file, and this will unblock terraform destroy operation.

If we’re listing workarounds, shutting down the instance before the destroy will work as well. The detach will work since the volume would not be “busy” at that point.

persists in

terraform v0.13.0
provider.aws v2.77.0

+1 here Terraform version: 0.12.25 AWS Provider version: 2.65.0

Even I’m facing this issue.

Terraform v0.12.1

  • provider.aws v2.14.0