この記事の内容はあまり参考になりません…(2021-01-31 追記)

• new Bucket(...) でS3バケットが毎度作成されると勘違いしていたせいで、変な記事を書いてしまいました…
• 普通に「new Bucket(...) で作成したS3バケットに addToResourcePolicy でバケットポリシーを付与したり、その他変更を行っていく」ようにすれば、cdkで毎度差分をチェックしてくれるので、S3バケットが毎度作成されることもなく、普通に権限の更新ができました…
• よって、下記はベストプラクティスにはなり得ないと思います。が、戒めのために残しておきます…

ハマった流れ

1. CDKでのインフラ構成に初挑戦
2. S3バケットを作成、別のAWSアカウントからの書き込みを許可したい
3. できたと思ったら、別アカウントからアクセスできない事態が発生
   • ブロックパブリックアクセスをオフにした→アクセスできたが、セキュリティ面に不安
   • 公式doc見る限り、ブロックパブリックアクセスをオンにしたままクロスアカウントアクセス許可できるはず…
4. バケット作成した→できた。
5. そのS3バケットを Bucket.fromBucketName(...) で利用し、別サービスをデプロイしたら、クロスアカウントアクセスがまた不可に。
   • 見ると、バケットポリシーが消えている
6. addToResourcePolicyで再付与 → できない
7. 混乱

ブロックパブリックアクセスをオンにしたままクロスアカウントアクセス許可する方法

• ブロックパブリックアクセスについては、全てオンでOK（CDKだと BlockPublicAccess.BLOCK_ALL は設定してOK）
• バケットポリシーでクロスアカウントアクセスを許可するのだが、公式ドキュメントの「パブリック」の意味にしたがって、「非パブリックのポリシー」とみなされる書き方をしないと、ブロックパブリックアクセスが優先されてアクセス不可になるので注意。

というわけで今回はここの問題ではなかった。

CDKによるS3バケットの作成と利用について

• new Bucket(...) で作成したS3バケットに addToResourcePolicy でバケットポリシーを付与可能
• Bucket.fromBucketName(...) で呼び出したS3バケットには addToResourcePolicy等の操作ができないが、2020/11/24現在エラーは出ない。（対応するGitHubのissue）
  • 別スタックやCloudFormationで管理されていないリソースの改変を防ぐための仕様、とのこと

そのため、既存のS3バケットを利用する際、同じStackで作成済みのS3バケットを利用するとクロスアカウントアクセス可能なバケットポリシー設定がうまくいかない。

• Bucket.fromBucketName(...) で呼び出したS3バケットに addToResourcePolicy で権限設定
  • 不可。.fromBucketName(...)で呼び出すとaddToResourcePolicyが使えない。
• new Bucket(...) でバケット作成した時点で addToResourcePolicy で権限設定済みのバケットを Bucket.fromBucketName(...) で呼び出す。
  • できそうだが不可。同じスタック内でバケットポリシーを付与していて、その記述がコードから消えるので、スタックで管理されているバケットポリシーが消される。

じゃあどうするか？

• S3バケットのスタックだけ分ける
  • アリだが、そもそも分けたスタック内でのアップデートがうまく行かないならCDKでやるメリットってないような。
• S3は手動で管理する
  • 一旦、これに落ち着きました。
  • CDKによる柔軟なアップデートとS3のデータストレージとしての活用方法（消さないし、作り変えたりも頻繁ではない）が、そこまでマッチしないかな、と。
  • もし良い活用方法を知っている方が居たら教えてほしいです。