CLOUD SECURITY LAB

CloudFront + S3、その警告メッセージは無視しても大丈夫？🤔 — エンドポイントの選択がサービス品質を決定する

—

by

cslab
in

“このS3バケットはウェブサイトとして設定されています。バケットエンドポイントの代わりにウェブサイトエンドポイントを使用することをお勧めします。”

この一行の警告、見過ごすと後で必ず後悔します。

>

🎯 この記事で扱うこと

  • CloudFrontオリジン設定時に表示される警告メッセージの正確な意味
  • S3 バケットエンドポイント vs ウェブサイトエンドポイントの核心的な違い
  • 各エンドポイントを選択すべき状況別の基準
  • OAC(Origin Access Control)使用時に必ず知っておくべき制約
  • 実務で即座に使えるCloudFront + S3構成パターン

📌 導入 / 背景

AWSコンソールでCloudFrontディストリビューションを作成し、S3バケットをオリジンとして指定すると、次のような黄色の警告が表示されることがあります。

このS3バケットはS3ウェブサイトとして設定されています。

このディストリビューションをウェブサイトとして使用する場合、バケットエンドポイントの代わりにS3ウェブサイトエンドポイントを使用することをお勧めします。

初めて見る人は「何か問題があるのか？」と戸惑い、慣れている人は習慣的に見過ごします。しかし、この警告を無視しても良いかどうかは状況によって全く異なります。

この記事では、警告の意味から、各エンドポイントの違い、そしてどのような状況で何を選択すべきかを明確に整理します。

🔍 S3オリジンエンドポイント、二種類あります

S3バケットをCloudFrontオリジンとして設定する際に選択できるエンドポイントは二種類です。

1️⃣ S3バケットエンドポイント (REST APIエンドポイント)

bucket-name.s3.ap-northeast-2.amazonaws.com
  • S3の基本APIエンドポイント
  • CloudFrontコンソールでバケット名で自動補完されるまさにそのアドレス
  • OAC(Origin Access Control)またはOAI(Origin Access Identity)適用可能 → バケットを完全に非公開に保つことが可能
  • ❗ サブディレクトリインデックスドキュメント非対応 → /blog/へのリクエスト時にblog/index.htmlを自動的に返さない

2️⃣ S3ウェブサイトエンドポイント

bucket-name.s3-website.ap-northeast-2.amazonaws.com
  • S3の静的ウェブサイトホスティング機能有効時に使用するエンドポイント
  • インデックスドキュメント(index.html)、エラードキュメント(404.html)の自動処理
  • サブディレクトリインデックス対応 → /about/へのリクエスト時にabout/index.htmlを自動応答
  • ❗ OAC/OAI非対応 → バケットのパブリックアクセスブロックを解除しなければ動作しない
  • ❗ HTTPS非対応 (エンドポイント自体はHTTPのみ対応、CloudFrontでHTTPS処理)

🤔 警告メッセージ、無視しても大丈夫？

結論から言うと：「状況による」
状況 推奨選択 警告無視の可否
静的ウェブサイト (React, Vue, Next.js静的ビルドなど) ウェブサイトエンドポイント ❌ 無視禁止
バケット非公開維持 + OACセキュリティ構成 バケットエンドポイント ✅ 無視可能
単純ファイル配信 (画像、CSS、JS CDN用途) バケットエンドポイント ✅ 無視可能
SPA (Single Page Application) + サブパスルーティング バケットエンドポイント + CF Functions ✅ 無視可能 (ただし、追加作業が必要)

—

💡 核心的な違い：サブディレクトリインデックス処理

警告を無視した際に最も頻繁に発生する問題がこれです。

例えば、S3に次の構造でファイルがあると仮定します。

/index.html
/about/index.html
/blog/index.html

バケットエンドポイントを使用した場合：

  • → index.html ✅ 正常応答
  • → ❌ 403または404エラー発生

ウェブサイトエンドポイントを使用した場合：

  • → index.html ✅
  • → about/index.html ✅

この違いのため、Next.js、Gatsby、Hugoのような静的サイトジェネレーターで作成されたサイトをデプロイする際に、バケットエンドポイントをそのまま使用すると、サブページへのアクセス時にエラーが発生します。

🔐 セキュリティ優先なら：OAC + バケットエンドポイント

セキュリティを重視する環境（ほとんどのプロダクション環境）では、バケットをパブリックに公開するのは負担です。このような場合、OACを使用してバケットを完全に非公開に保ちながら、CloudFrontのみアクセスを許可することができます。

OAC設定フロー：

사용자 → CloudFront → (OAC 서명 요청) → S3 버킷 (비공개)

この場合、必ずバケットエンドポイントを使用する必要があり、ウェブサイトエンドポイントではOACは動作しません。

S3バケットポリシー例 (OAC許可)：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/DISTRIBUTION_ID"
        }
      }
    }
  ]
}

💻 サブディレクトリ問題の解決：CloudFront Functionsの活用

OACを使用しながらサブディレクトリインデックスも処理したい場合は？CloudFront Functionsで解決できます。

// CloudFront Functions — Viewer Request トリガーに接続
function handler(event) {
  var request = event.request;
  var uri = request.uri;

  // パスが / で終わる場合、index.html を追加
  if (uri.endsWith('/')) {
    request.uri += 'index.html';
  }
  // 拡張子のないパスの場合、/index.html を追加
  else if (!uri.includes('.')) {
    request.uri += '/index.html';
  }

  return request;
}

この関数をCloudFrontディストリビューションのViewer Requestイベントに接続すると、バケットエンドポイントを使用しながらも/about/ → about/index.htmlの処理が可能になります。

⚠️ 注意事項 / よくある間違い

1. ウェブサイトエンドポイント = バケットのパブリック公開必須 ウェブサイトエンドポイントでCloudFrontを構成する場合、バケットのパブリックアクセスブロックを解除する必要があります。OACが動作しないため、バケットが外部に直接露出する可能性があります。CloudFront経由でのみアクセスを強制するには、Refererヘッダーベースのバケットポリシーを別途構成する必要がありますが、これは完全なセキュリティではありません。

2. SPAルーティングエラー React Router、Vue Routerなどクライアントサイドルーティングを使用するSPAは、リロード時にサーバーに直接パスをリクエストします。このとき、S3に該当パスのファイルがないと403/404が発生します。CloudFrontのエラーページ設定で、403/404をindex.htmlにリダイレクトするように構成する必要があります。

3. HTTPS設定の混同 ウェブサイトエンドポイント自体はHTTPSをサポートしていません。しかし、CloudFront ↔ オリジン間の通信をHTTPに設定し、ユーザー ↔ CloudFront間のみHTTPSで処理すれば問題ありません。Origin Protocol PolicyをHTTP Onlyに指定すれば正常に動作します。

✅ まとめ / 締めくくり

警告メッセージを無視しても良いかどうかは、単に「はい/いいえ」ではなく、使用目的とセキュリティ要件によって決定する必要があります。
目的 選択
静的サイト (サブディレクトリルーティングが必要) ウェブサイトエンドポイント
セキュリティ強化 (OAC適用、バケット非公開維持) バケットエンドポイント + CF Functions
単純ファイルCDN配信 バケットエンドポイント (警告無視可能)

実務では、OAC + バケットエンドポイント + CloudFront Functionsの組み合わせが、セキュリティと機能性の両方を満たす最も推奨されるパターンです。警告メッセージは「無視するのではなく、理解せよ」という信号として受け止めるのが良いでしょう。

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です