🚨 AWS Error: 'is already attached to an instance' (VolumeInUse) — Cause, Fix, and Troubleshooting Guide

Overview

A standard EBS volume can be attached to exactly one instance at a time. When you try to attach a volume that is already attached (or is mid-detach), EC2 rejects the call with VolumeInUse. The related IncorrectState error appears when the volume isn’t in the available state the operation requires. Both are guardrails against corrupting a filesystem by double-mounting.

You will see it surface from the CLI, an SDK, or Terraform:

An error occurred (VolumeInUse) when calling the AttachVolume operation: vol-0abc123REDACTED is already attached to an instance

It occurs when the volume is still attached elsewhere, a previous detach hasn’t finished, or you attempt to attach a non-Multi-Attach volume to a second instance.

Symptoms

• AttachVolume fails with VolumeInUse or IncorrectState: vol-... is not 'available'.
• Terraform apply fails attaching an aws_volume_attachment that another instance still holds.
• A detach appears to hang; the volume shows in-use with an Attachment.State of detaching.
• Reattaching after an instance replacement fails because the old attachment lingers.

aws ec2 attach-volume --volume-id vol-0abc123REDACTED \
  --instance-id i-0newREDACTED --device /dev/sdf

An error occurred (VolumeInUse) when calling the AttachVolume operation: vol-0abc123REDACTED is already attached to an instance

Common Root Causes

1. The volume is still attached to another instance

The most common cause — the volume was never detached from its previous instance.

2. A previous detach is still in progress or stuck

Detach is asynchronous; if the guest OS hasn’t released the device (filesystem still mounted), the volume sits in detaching.

3. Attaching a non-Multi-Attach volume to a second instance

Only io1/io2 volumes with Multi-Attach enabled can attach to multiple instances; a standard volume cannot.

4. Device name conflict on the target

The chosen device name (e.g. /dev/sdf) is already occupied on the target instance.

5. Terraform managing the same attachment twice

Two aws_volume_attachment resources (or a manual attach plus Terraform) race for the same volume.

How to diagnose

Step 1: Check the volume’s state and current attachment

aws ec2 describe-volumes --volume-ids vol-0abc123REDACTED \
  --query 'Volumes[].[State,MultiAttachEnabled,Attachments[].[InstanceId,Device,State]]' \
  --output json

[["in-use", false, [["i-0oldREDACTED", "/dev/sdf", "attached"]]]]

This tells you which instance holds it and whether Multi-Attach is on.

Step 2: Confirm what the target expects to be free

aws ec2 describe-instances --instance-ids i-0newREDACTED \
  --query 'Reservations[].Instances[].BlockDeviceMappings[].[DeviceName]' --output text

Make sure the device name you’re attaching isn’t already listed.

Fixes

Detach from the current instance, then attach

Unmount inside the guest OS first, then:

aws ec2 detach-volume --volume-id vol-0abc123REDACTED
aws ec2 wait volume-available --volume-ids vol-0abc123REDACTED
aws ec2 attach-volume --volume-id vol-0abc123REDACTED \
  --instance-id i-0newREDACTED --device /dev/sdf

Force-detach a stuck volume (last resort)

If a detach is stuck because the OS never released it (and you accept possible data loss on un-flushed writes):

aws ec2 detach-volume --volume-id vol-0abc123REDACTED --force
aws ec2 wait volume-available --volume-ids vol-0abc123REDACTED

Enable Multi-Attach for genuine multi-writer needs

Only for io1/io2 volumes with a cluster-aware filesystem:

aws ec2 modify-volume --volume-id vol-0abc123REDACTED --multi-attach-enabled

Deconflict Terraform

Ensure only one aws_volume_attachment manages the volume, and set skip_destroy/dependencies so detach precedes reattach on replacement.

What to watch out for

• Always unmount the filesystem in the guest OS before detaching; --force can corrupt un-flushed data.
• wait volume-available before reattaching — detach is asynchronous and the volume briefly stays in-use.
• Multi-Attach requires a clustered filesystem; attaching a normal ext4/xfs volume to two instances will corrupt it even when the API allows it.
• On instance replacement, order the detach of the old attachment before the attach of the new one, or Terraform will race into VolumeInUse.

Related

• AWS Error: ‘DependencyViolation’ — another “resource still in use” guardrail on teardown.
• AWS Error: ‘IncorrectState’ waiter timeout (ResourceNotReady) — waiting for a resource to reach the right state.
• AWS Error: RDS ‘InvalidDBInstanceState’ — the same state-machine pattern for RDS operations.