Lastly i've mentioned that terraform is a good choice fo AWS automation. Now i had fist experience and i wan't to share them whit you..
Separation of Environments
Deployment Environments do not require introduction also that non production environments should as far as possible copy production environment. Therefore it's become crucial to have one Infrastructure code for all environments.
terraform env select dev terraform apply -var-file=dev.tfvars -refresh=true
In this excerpt the resource definition uses variables for all changed parts between environments. Separate states are maintained per environment (fist line), but you need apply proper environment variables (second line).
To prevent errors or choosing wrong environment it's better to use predefined scripts that captures that.
Modules are great to capture common set of resources you can reuse. But at beginning do not start with modules. Try to understand how things are working and what belongs together and what not.
Avoid nested modules, because it over complicates variable passing and refactoring.
And be aware of the fact, that it's not easy to define explicit dependencies between modules. It's still very wanted and not implemented feature
You don't need to start with remote states. So i'm still checking local state to git. But as soon several people begin to contribute you need to think about is. Environment States are very fresh and now1 are already supported with AWS S3, but e.g. not with Google Cloud Buckets.
Be careful with state, make sure you don't end up in broken state. I run into stupid issue with local state where i was busy with big refactoring and didn't check that [Ctr+C] can destroy local state with is a bug i reported.
As always feel free to comment ;)
At time where terraform 0.9.4 is most recent released version. ↩