S3+CloudFrontでの配信基盤の構築で詰まったポイント
まえがき
とあるサービスをクローズする案件で、既存のサイトから固定のクローズページへと切り替える案件がありました。
既存のサイトはECSで動いていましたが、クローズページを表示するためだけの利用だとオーバースペックになってしまうため、S3に配置したHTMLをCloudFrontで表示させることになりましたが、実際の構築にあたりいくつか詰まったポイントがあったため記載しておきます。
詰まったポイント
アクセスコントロール周りの不備
バケットポリシーの不備
CloudFrontからS3のオブジェクトを参照する場合は、バケットポリシーで特定のディストリビューションを許可してあげる必要がありましたが、こちらの設定が漏れており表示までに時間を食ってしまいました。
公式ドキュメントを参考に、下記のように記述することで解決しています。
例:
{
"Version": "2012-10-17",
"Statement": {
"Sid": "AllowCloudFrontServicePrincipalReadOnly",
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::<S3 bucket name>/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
}
}
}
}
Amazon Simple Storage Service オリジンへのアクセスを制限する - Amazon CloudFrontAmazon Simple Storage Service オリジンへのアクセスを制限する - Amazon CloudFront
OAI→OACへの移行
別プロジェクトのTerraformの記述を参考にリソースを作成していた所、CloufFront+S3の連携で使っていた、OAIというアクセスコントロールがレガシーになっているという警告が発生していました。
こちらも最新のアクセスコントロールであるOAC
に切り替えてリリースしました。
Amazon CloudFront オリジンアクセスコントロール(OAC)のご紹介 | Amazon Web Services ブログ
証明書のリージョンがバージニア北部しか使えない問題
サイトで元々使われていた証明書(東京リージョンに存在)を使おうとした所、CloudFrontと紐づけるにはバージニア北部で発行された証明書を使う必要がありました。
AWS Certificate Manager (ACM) の証明書を使用して、ビューワーと CloudFront との間で HTTPS を必須にする場合は、米国東部 (バージニア北部) リージョン (us-east-1) の証明書をリクエスト (またはインポート) していることを確認します。
CloudFront で SSL/TLS 証明書を使用するための要件 - Amazon CloudFront
そのため東京リージョンで使っていた証明書は再利用せず新たにバージニア北部で証明書を発行してそちらを利用するよう切り替えました。
S3にアクセスログを保存する場合、ACLを有効化しないといけない問題
CloudFrontのアクセスログをS3に保存する場合、ACLを有効化する必要があることに気づけずハマりました。
↓の記事を参考にバケットの設定を変えて作成し直して解決しています。
CloudFrontのアクセスログ保存用S3バケットにはACL有効化が必要なので注意しよう | DevelopersIO
感想
- S3のアクセスコントロールが思っていた倍ぐらい複雑だった
- これまでは既存のバケットを少し触る、くらいの機会しかなかったので、今回は学ぶいいきっかけになった
- ↓の記事がとても参考になりました
- S3のアクセスコントロールが多すぎて訳が解らないので整理してみる | DevelopersIO
- あるあるな設計とはいえ、複数サービスが絡むとハマりどころが増えて大変
- 事前にある程度ハマりどころなどは調査して抑えておきたい
Discussion