v4.9.0のS3リファクタリングの挙動を試してみたv4以前のS3の書き方もオプションとして記述できるようになりました。S3たかくに2022.04.11この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。こんにちは!AWS事業本部コンサルティング部のたかくに(@takakuni_)です。v4.9.0のS3リファクタリングについて挙動を確認してみようと思います。aws_s3_bucketのリファクタリングについて先日、v4のリリースで大きな反響があったaws_s3_bucketのリファクタリングについて変更がありました。v4.9.0では、aws_s3_bucketブロック内にすべて書く方法、aws_s3_bucket_policyなど複数ブロックに分けて書く方法のどちらでも書けるみたいです。注意点として、両方で記述した場合、ドリフト検出の不具合や競合が生じるみたいです。今回はその点も検証してみようと思います。(#23985)v4.9.0リファクタリングは不要になったわけではない今回、v4.9.0でaws_s3_bucket内にプロパティをすべて書き込めるようになりましたが、「リファクタリングが不要になった」と言う意味ではないようです。aws_s3_bucketのリファレンスを確認すると、「非推奨の書き方」として取り上げられています。aws_s3_bucket今後のマイルストーンでも、2022年4月時点ではとくに言及がありませんでしたが、いつ変更になるかわからないため注意が必要です。https://github.com/hashicorp/terraform-provider-aws/milestones検証してみた今回は、以下のコードでバージョンアップデート前後の挙動を確認してみようと思います。バージョンで、コメントアウト部分を変更します。planを実行すると、v4以降のリファクタリングを行なっていないため怒られました。}}v4.9.0ここからが、今回の本題です。-upgradeを実行します。planを実行すると、無事planが通りますが、Warningが表示されました。applyでもリソース作成されましたが、作成後にもWarningが表示される仕様でした。destroyed.リファクタリング後のコード以下のようにコードを変更して、リソースを作成してみました。apply結果の抜粋ですが、Warningも表示されることなくリソースが作成されました。destroyed.競合時のドリフト検出の挙動について今回のアップデートで、両方のパターンで書ける状態になりました。設定値が競合する場合、ドリフト検出がループします。そのため、競合を避ける必要があります。どのような挙動になるか、以下のコードで検証してみました。(S3バケット部分以外は抜粋しています。)暗号化方式の競合が起こるコードになります。初回デプロイ時は、「aws:kms」アルゴリズムでS3バケットは作成されます。厳密には、「AES256からaws:kmsに上書きする挙動」となります。destroyed.デプロイ(2回目)aws_s3_bucketのserver_side_encryption_configurationプロパティのドリフトが検出されます。apply時に、「AES256」に更新されます。destroyed.デプロイ(3回目)aws_s3_bucket_server_side_encryption_configurationのruleプロパティでドリフトが検出されます。apply時に、再度「"aws:kms"」アルゴリズムに更新されます。以降は、デプロイ(2回目)とデプロイ(3回目)をループするため、競合を避ける必要があります。destroyed.まとめ今回は、v4.9.0のS3リファクタリング挙動を試してみました。オプション化で、以前の書き方ができるようになりましたが、引き続きリファクタリングが必要そうです。この記事が、どなたかの参考になれば幸いです。