CloudFrontのアクセスログ保存用S3バケットにはACL有効化が必要なので注意しよう

CloudFrontのアクセスログ保存用S3バケットにはACL有効化が必要なので注意しよう

ACL無効化を設定したS3バケットは(2021/12/17時点では)CloudFrontのアクセスログ出力先として指定することができません。設定しようとするとエラーとなってしまいます。ACLが有効なS3バケットを指定しましょう。
Clock Icon2021.12.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

清水です。先日、Amazon S3のACL無効化が推奨されたことで、S3のサーバアクセスログ記録保存用のS3バケットの権限設定においてもACLではなくバケットポリシーを使用するようになっていた、というブログを書きました。

re:Invent 2021期間中に発表されたS3のACL無効化機能に伴う変更です。(【アップデート】S3でACLを無効化できるようになりました #reinvent | DevelopersIO)上記エントリではS3のサーバアクセスログ記録保存用となるS3バケットについて確認しましたが、CloudFrontのアクセスログ記録用となるS3バケットについて、ACL無効化の影響(ACLを無効にしたS3バケットをCloudFrontアクエセスログ保存用バケットに指定できるか)を確認する機会がありましたので、まとめてみたいと思います。

なお、結論としては2021/12/17の時点で ACLを無効に設定したS3バケットをCloudFrontアクセスログの保存先に指定することはできません でした。

あくまで2021/12/17時点の状況となります。ACLは無効化が推奨されるということで、今後のアップデートによりACLを無効にしたS3バケットをCloudFrontアクセスログ保存先に指定できるようになることは十分考えられるかと思いいます。適宜最新情報を確認しましょう。

ACL無効にしたS3バケットをCloudFrontのアクエスログ保存時に指定しようとしてみる

まずはACLを無効に設定したS3バケットを作成、こちらをCloudFrontのアクセスログ出力先に指定できるか確認してみます。

「cloudfront-logs-no-acl-1」というS3バケットをACL無効にして作成します。

続いてCloudFrontのディストリビューション作成で、このS3バケットを出力先として標準ログ保存を有効化して[Create distribution]しようとしてみます。

[Create distribution]ボタンを押下すると、 The S3 bucket that you specified for CloudFront logs dones not enable ACL access: cloudfront-logs-no-acl-1.s3.amazonaws.com の表示とともにエラーとなってしまいました。

ドキュメントでCloudFrontアクセスログ保存先のS3バケットの要件を確認してみる

ドキュメント(Amazon CloudFront Developer Guide)を確認してみます。以下の記載がありますね。(2021/12/17現在、日本語版への反映はまだのようです。)

Don’t choose an Amazon S3 bucket with S3 Object Ownership set to bucket owner enforced. That setting disables ACLs for the bucket and the objects in it, which prevents CloudFront from delivering log files to the bucket.

Configuring and using standard logs (access logs) - Amazon CloudFront

「bucket owner enforced」に設定したS3バケット、つまりACLを無効に設定したS3バケットは選択できない、ということになります。

ACLを有効にしたバケットをCloudFrontアクセスログ保存先にしたときの挙動を確認してみる

ドキュメントにも記載がある通り、現時点ではACLを無効に設定したS3バケットはCloudFrontのアクセスログ保存先に設定できないようです。ここではACLを有効にしたバケットでどのようにACLまわりの設定がされているか確認しておきます。

ACLを有効、従来どおりのオブジェクトライターの設定でS3バケット「cloudfront-logs-using-acl-1」を作成します。

先ほどと同様の手順でCloudFrontアクセスログを出力先「cloudfront-logs-using-acl-1」にして有効にします。その後、S3バケット「cloudfront-logs-using-acl-1」のアクセス許可まわりを確認してみましょう。

バケットポリシーは空のままです。

ACL設定について確認してみると、外部アカウントc4c1ede66af53448b93c283ce9448c4ba468c9432aa01d700d3878632f77d2d0からの許可が追加されています。権限はオブジェクトのリストと書き込み、バケットACLの読み取りと書き込み権限ですね。

この外部アカウントは何者だ!?と疑問になるかもしれませんが、調べてみるとawslogsdeliveryのアカウント正規IDであることがわかります。CloudFrontのアクセスログはこのawslogsdeliveryアカウントから書き込まれているというわけですね。

標準ログ (アクセスログ) の設定および使用 - Amazon CloudFront

まとめ

AWS re:Invent 2021期間中にリリースされたAmazon S3の新機能「ACL無効化」を有効にしたS3バケットに対して、(現状では)CloudFrontのアクセスログ出力先として設定できないことを確認してみました。ACL無効は推奨となっているので、S3のサーバアクセスログ記録のようにバケットポリシーに対応してALC無効に設定したS3バケットを出力先として設定できるようになることを期待したいですね。

またS3バケットへの出力のアクセス権限ををACLを使って制御していたものが、S3のサーバアクセスログ記録とCloudFrontのアクセスログである(だった)ということとなります。ほかにACLを使ってそうなものはあるかな、、と思いを巡らせてみたのですが、CLB(当時のELB)のアクセスログ記録はリリース当時から既にバケットポリシーに対応していました。(ELBがアクセスログを出力できるようになりました! | DevelopersIO)アクセスログ出力のS3の権限にACLを使っているとすればこれより古いタイミングでリリースされた機能になると思いますが、、。特には思いつかない感じです。1点だけ、動画変換サービスAmazon Elastic Transocderで出力オプションでACLを操作できるオプションがありましたが、いまから新しく動画変換を行うならAWS Elemental MediaConvertを使うだろうし、影響はほとんどないのでは、と思っています。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.