CloudFrontがバケットポリシーでアクセス制御されたS3を見に行く時にまれに403エラーになる（未解決）

概要

CloudFrontを使ってS3のファイルを配信する時にS3のバケットポリシーとCloudFrontのオリジンアクセスアイデンティティ（OAI）を使ってS3へのアクセスを厳格に制御する方法があり、これを使うと「たまに403になる」現象に遭遇した。

結論、未解決なので別の方法でアクセス制御を行ったのですが該当の現象に関してがググっても見つからなかったのでトラブルシューティングの履歴だけ書いておきます。

CloudTrailでS3のgetObjectに関する詳細ログを見る

403を返してるのはCloudFrontですが、実際にどこで403が発生するかというとS3なのでCloudTrailログでS3の該当バケットに対するイベントログをCloudWatch Logsから見れる状態にする。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/cloudtrail-logging.html

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "AWSAccount",
        "principalId": "",
        "accountId": "ANONYMOUS_PRINCIPAL"
    },
    ...略...
    "userAgent": "[Amazon CloudFront]",
    "errorCode": "AccessDenied",
    "errorMessage": "Access Denied",
    ...略...
}

CloudTrailでS3に関するgetObjectのログを見ると確かに userIdentity.accountId の箇所が ANONYMOUS_PRINCIPAL になってる。

 "userIdentity": {
        "type": "AWSAccount",
        "principalId": "xxxxxxxxxxxxxxxxxxx",
        "accountId": "CloudFront"
    },

正常に処理された場合はちゃんとprincipalIdが乗る。 userAgent は間違いなく両者ともCloudFrontからのリクエストであることを証明しているのでCloudFrontの動きが怪しい、という所にアタリを付ける。

わかっていること

• 再現が難しい
  • 数百～数千リクエストに1回程度の頻度で、トラフィックのスパイクも関係なく起こる。
• 「OAIがリクエストに乗らない」という現象を制御するための方法が無い

取った対応

• CloudFront Distributionの再作成
  • CloudFrontのよくわからないエラーに関しても「作り直したら治った」という例がいくつかあるので、再生成して様子見
  • →ダメでした…
• Origin Custom Headersで適当なヘッダーをS3に送るようにして、バケットポリシーでゆるく制御する
  • CloudFrontからS3に送られるヘッダーはCloudFrontやS3の設定値を見られない限り漏れないので適当なハッシュを乗せる。（予定）
• サポートに連絡
  • そもそもこれバグじゃない？っていう報告はしています。