先日、中規模AWSシステムを０から構築する機会がありました。構築中、コードが長くなったり、ファイルが多くなったり、関数が多くなったり悩みのつきなかったディレクトリ管理でしたが、自分なりに最適解を導いたのでここに記録しておきます
前提
dev（開発）とprd（本番）でわかれてます。環境差異が非常に多く、共通化できる項目が少なかったため、次回も新たにディレクトリをきるほどのモジュール化は不要と考えました。またセキュアな環境のため、サービスによってはコードが非常に長くなりました。そういった項目は２つくらいにならわけてもよさそうなので、ファイル分割の余地がありそうなものには★をつけています。
ディレクトリ
#必須の４ファイル
tfstate.tf
provider.tf
output.tf
terraform.tfvars
#IAM系 セキュアな環境ほどコードが長くなりやすいです。
iampolicy.tf
iamgroup.tf
iamrole.tf
iamuser.tf
#このへんもセキュアな環境ほどコードが長くなりやすいです。
network.tf（VPC、サブネット、ルートテーブル、DHCPオプションセット、ピアリング、エンドポイント）★
securitygroup.tf★
EC2.tf★
#CWも同じくセキュアなほど長くなりやすい。
cloudwatch-event-rule
cloudwatch-metric-filter★
cloudwatch-metric-alarm★
S3.tf
trail.tf
#jsonは下記ディレクトリを作成して格納
bucketpolicy
event_pattern
kmspolicy
inpolicy（インラインポリシー）
mgpolicy（ユーザー管理ポリシー）
設計
一度作りはじめるとディレクトリ構成を修正するは困難です。なので、システムの要件をしっかりと把握した上でディレクトリ構成は検討すべきです。要件から構成をどう考えるかは経験するしかないので、数をこなすことでより理想的なディレクトリ構造を設計できるのかなと思いました
サービスごとのデプロイ
それからコード量があまりにも多い（=デプロイが遅い）＆AWSコンソールを意図しないところ（IAMの範囲内で）から操作される（=Terraform側と差分がでる）可能性があるという環境特有の理由から、一括デプロイのリスクを減らすためにサービスごとにデプロイできないかとかも考えました。ただ、この事象はあまりに環境特有すぎる&コードの管理が複雑になるため、Terraform側の対処するのは相当なレベルの問題になってから考えるでよさそうでした
参考
そもそもterraform自体が
なお方へ
その他、本ディレクトリ構造に関して参考になった記事