大規模なECサイトを構築する際にTerraformを利用したAWS環境自動構築について検討したので、大枠をまとめておきます。
CloudFormationではなく、Terraformを利用した理由は変更時にパラメータ差異まで表示してくれるところが良かったからです。（CloudFormationのVerが上がったら解消されそうですが。。）
TerraformでAWS環境構築される方の参考になれば幸いです。
※でもまだ最適ではないと思います。。
#自動構築の目的
・障害の早期復旧に利用する
・システム再構築やDRにも対応可とするため
#構築方針
・インフラ部分のAWSリソースはTerraformで自動構築（コーディング）する
※利用するAWSリソースはEC2、S3、RDS、EFS、DirectConnect、Route53など一般的（？）に利用されるものが主
・（Terraform未経験の）複数人でコーディングする
#環境
・本番環境、検証環境、接続試験環境、性能試験環境、開発環境がある
・アカウントは本番環境（本番アカウント）とそれ以外（検証アカウント）で分割している
・本番アカウントで３つのVPC（サービス用、運用、CI）に分割
・検証アカウントで２つのVPC（サービス用、運用）に分割
#Terraformの利用ポイント１ Moduleの積極的な利用
HashiCorpが用意してくれているAWS環境を作成するモジュール（Terraform Registry）を利用。
HashiCorpに用意されたモジュールが無いAWSリソースはモジュールを自作。
これでコーディングメンバーはモジュールにパラメータを埋め込むだけで利用できる。
例外でRDSのパラメータグループなどモジュール利用不可なリソースもある。
＜Terraform Registry＞
https://registry.terraform.io/
#Terraformの利用ポイント２ WorkSpace機能
WorkSpace機能を利用すると本番環境と似た検証環境がある場合、
変数を変えるだけで同じコードを利用してAWS構築が可能となり、
うまく使えばコーディング量が少なくなる。
今回は本番環境、検証環境、接続試験環境、性能試験環境、開発環境（の一部）をWorkSpaceを利用して構築した。
が、、利用してみて環境差異が多い場合は利用することで逆に開発効率が落ちる。(考えなければいけないことが増える)
今更やり直せないが、同一の環境のみで利用することを推奨する。
＜WorkSpace＞
https://qiita.com/gamisan9999/items/168ff29be70572de7602
#課題
・テスト
AWSSpec利用してみたかった。
現状はコードと詳細設計書を見比べることをテストとする方針としているが、改善したいところ。
#運用
構築完了後の運用設計は検討中。
理想は毎週自動でTerraformを再実行することだが、Terraformの仕様でNACLやSGの変更に制限があり、
べき等性を保てないと考えている。（provider: aws v1.39利用）
（ルールIDの小さいNACLをTerraformで追加すると大きなIDのNACLが再作成される動きとなり、一時的に全断状態になる。
バグな気もするが、現状は仕様らしい。）
自動化不可なAWSリソースがある。ダイレクトコネクトなど承認が必要なリソースは自動化不可。
こちらの運用回避も検討する。