Option to specify ebs volume instead of snapshot - keep volume alive after elastic instance shutdown

It is a critical need for our systems to have EC2 instances to startup, not with a randomly created Volume out of the provided snapshot ID, but instead with a specific volume which ID is known from us.

The scenario is the following.
When we start a cloud instance and perform a builds on it, since instances memory is not persistent, we save all our changes to the attached EBS Volume. As you know the Volume is generated out of a provided snapshot ID but luckily not deleted from the AWS Management console of the Amazon user profile. That mean, changes are kept in the Volumes until they are manually deleted via the AWS Management console.

Here comes the issue that, very often we would like to start an instance later with exactly the status of few days before that is actually the current content of a volume A previously created at that time.

The only way out for us right now, is to start a new instance based on the same configuration that the one of few days ago that we want to replicate. Based on the snapshot ID a new EBS volume is created but absolutely useless for us since we want to be able to get the status of the old attached volume, therefore preceed by:

• login the AWS Management console
• locate the running instance & the volume attached to that instance
• detach the newly created volume
• attach the old volume (which ID remained available in the AWS Management console)
• login via SSH in the cloud instance
• mount the attached old volume back to the /mnt/bamboo-ebs
• start the necessary tools on the instance manually

As you can see this is a great performance issue for us that can be easily solved if there were an option to bind a specific Volume ID in a give instance configuration. This way when starting that instance, that volume only available for that specific user account could be in an automated way attached to the instance and ready to use.

The feature request (to be able to specify a volume that should be mounted to an elastic instance) would go along with the requirement that this volume should be not be deleted when the elastic instance is going to shutdown.