状況
非公開の S3 を CloudFront(OAC)で配信するサイトを、検証用ディストリビューションから本番用の新しいディストリビューションに切り替えた。本番ドメインで / も /index.html も 403 になり、本文は S3 の AccessDenied の XML。バケットポリシーは検証時のものをそのまま使っている。
原因を調べる順番として、最も適切なものは?
- ARoute 53 のレコードが CloudFront を向いているか
- BS3 のブロックパブリックアクセスを外して試す
- Cバケットポリシーの AWS:SourceArn が本番の配信 ID か
- D本番ディストリビューションのオリジンに OAC が付いているか
正答
- A → D → C → B
- B → C → D → A
- C → D → A → B
- D → A → B → C
解説
本文が S3 の AccessDenied の XML なら、リクエストは DNS と CloudFront を通って S3 まで届いている。だから Route 53(A)は正常と分かり、後回しでよい。/index.html も 403 なので、デフォルトルートオブジェクトの問題でもない。直前に変えたのはディストリビューションで、OAC 用のバケットポリシーは AWS:SourceArn で特定のディストリビューションだけを許可する書き方が一般的。検証用の ID のままなら、本番からの要求は拒否される(C)。次に、本番側のオリジンに OAC が付いていて、署名して S3 に送っているか(D)を見る。ブロックパブリックアクセスを外す(B)は OAC の構成では不要で、バケットを公開してしまう危険な操作。順番の最後に置くというより、本来は行わない。
この問題を含む AWS のテストを制限時間つきで解く
AWSクイズへ