总之

• みんな大好き AWS CloudTrail

• IasCODE が流行だから CloudTrail も Ansible か Terraform で管理してみよう

• Bucket が多くなると管理が大変だから、terraform の backend と AWS Config と同居させてやろう

• ダメだった。今のところ単独のbucketにしてしまっておくのがよさそう

ってことがどこにも見当たらなかったのでメモとして残す

想要

• Ansible で S3 Bucket A を作成（プライベートバケット１つ）

• terraform で A に対して以下をそれぞれ管理、設定

terraform の backend

prefix に tf
ライフサイクルなし

AWS CloudTrail の出力先

prefix に cloudtrail
ライフサイクル3段（standard->glacier->delete）

AWS Config の出力先

prefix に config
ライフサイクル3段（standard->glacier->delete）

CloudTrail と Config はグローバルイベントも単一のバケットに送れる
terraform も同様に指定したリージョンでどこからでも使える
なので、prefix で分けてあげればバケットが雑多にならなくていいかと思った。ライフサイクルもprefixで分けられるし。

为何不呢

• terraform の backend として S3 を使う場合の Bucket を作成する（ansible）

• 作成した Bucket を CloudTrail 用のリソース一式を管理する backend にする

bucket policy がついてない（ansibleで追加してつけた）

ライフサイクルイベントつけよう

ライフサイクルで31日後に standard 落とし
ライフサイクルで93日後に glacier 落とし
ライフサイクルで365日後に delete
何回やっても３つセットができない

https://github.com/ansible/ansible/issues/30120 おいいいい

じゃあ terraform でつけよう

ライフサイクル後から追加できなくない？

https://github.com/terraform-providers/terraform-provider-aws/issues/283 おおおおおおおい

これじゃあ最初に Ansible で bucket 作って同居させるの無理じゃない？
むしろそれぞれ別に bucket 作って、必要な設定をそれぞれ書いたほうが自由度が高い（そりゃそうか

总结

• terraform backend 用 bucket は ansible で作る

プライベートバケットならそれだけでほぼ問題ない
必要なポリシーは付けられる
ライフサイクルはほぼ必要ない（むしろ移行させない）

AWS CloudTrail 用及び AWS Config 用 bucket はそれぞれ terraform で作る

CloudTrail 用モジュールで自前で bucket を用意する
自前で s3_bucket リソースを用意するので、ライフサイクルも好きに出来る

Ansible でも Terraform でもどっちでもいいので、Lifecycle をちゃんとサポートして欲しい。。。