[cakeface]

Great post! I too had the issue with AWS volume attachments and the need to separate them out. Luckily it happened early during some of my first provisioning and we realized it before standing up more databases. I now have a policy where each server has a separate EBS volume, using a volume attachment Terraform resource, for any data. Inline EBS volumes are just used for the OS.

I've run into another similar type issue now and I think that I'm going to have to do state surgery like you. I want to refactor some of my terraform resources into modules, but this changes the resource names. I can't see any way to do it without either standing up new infrastructure or modifying the state directly.

[sevagh]

We ran into similar issues. From there I went one step further and wrote a tool to do the attachments for me (instead of using Terraform's aws_volume_attachment):

https://github.com/sevagh/goat

This way in Terraform I provision a group of volumes, a group of instances, and rely on `goat` to do the rest.

[kalmar]

That's pretty cool. So is the model that you don't manage the volumes in TF at all?

(Btw I think I know people you know... also in Montreal and I know a couple folks at AdGear!)

[sevagh]

That's cool, I'll ask my coworkers.

And yes this way I keep EBS and the rest of my recipes as far away as possible.

Something like:

``` kafka-volumes/ <ebs volumes> terraform.tfstate kafka/ (use local backend ../kafka-volumes/terraform.tfstate) <ec2 instances> ```