S3 を公開せずに、世界へ速く Web サイトを届ける

手順に迷ったときや、用語の意味を確かめたいときに開きましょう。

※ リンク切れの場合は、ページタイトルで検索してください。

同じ「静的サイトを公開する」でも、S3 を直接公開する方式と、CloudFront を前に置く方式があります。今回は後者を作ります。違いを押さえておきましょう。

どちらが優れているという話ではなく、目的しだいです。今回は「安全・高速・HTTPS」を重視した方式 2 を組み立てます。

以下の要件を満たし、CloudFront のドメインでページが表示されることを確認してください。

「非公開のバケットを用意 → CloudFront を作る → オリジンアクセスコントロールでつなぐ → HTTPS で確認」の順に進みます。バケットを公開しないまま配信できる、という点を意識しながら進めましょう。

1. バケットを作り、index.html を置く（公開はしない）

   S3 コンソールで、東京リージョンにバケットを作成します。「ブロックパブリックアクセス」は有効（すべてブロック）のままにします。次に、トップページの index.html をアップロードします。手元にない場合は、簡単な内容（例：<h1>CloudFront から配信したページ</h1> を含む HTML）を用意します。

   公開しないのが今回のポイント

   S3 を直接公開する方式と違い、ここではバケットを非公開のままにしておきます。アクセスは、このあと作る CloudFront だけに許可します。

2. CloudFront でディストリビューションを作成する

   画面上部の検索バーに CloudFront と入力してコンソールを開き、「ディストリビューションを作成」を押します。オリジン（配信元）に、手順 1 で作った S3 バケットを選びます。

   オリジン＝コンテンツの置き場所

   CloudFront にとって S3 バケットは「オリジン（おおもとの置き場所）」です。CloudFront は、利用者の代わりにここから取得し、各拠点にキャッシュして配信します。

3. オリジンアクセスコントロール（OAC）を設定する

   オリジンの設定で、「Origin access」→「Origin access control settings（推奨）」を選び、オリジンアクセスコントロールを新規作成します。作成後、コンソールに「バケットポリシーを更新してください」という案内と、貼り付け用のポリシーが表示されます（後の手順で適用します）。

   オリジンを作成 — Origin access の選択（イメージ）

   Origin access

   Origin access control settings（推奨）

   CloudFront からのみ S3 を読める

   パブリック

   バケットを直接公開してしまう

   Legacy access identities

   旧方式（OAI）。新規には非推奨

   ↳バケットを非公開のままにするため、推奨の OAC を選びます

   オリジンアクセスコントロールが「CloudFront だけ通す鍵」

   オリジンアクセスコントロールは、S3 へのアクセスをこの CloudFront ディストリビューションからのものだけに限定する仕組みです。これにより、バケットを公開せずに CloudFront 経由でだけ中身を配信できます。

4. デフォルトルートオブジェクトと HTTPS を設定して作成する

   同じ作成画面で、次を設定して「ディストリビューションを作成」を押します。

   ビューワープロトコルポリシー	Redirect HTTP to HTTPS（HTTP は HTTPS に転送）
   デフォルトルートオブジェクト	index.html

   デフォルトルートオブジェクトとは

   ドメインの直下（ファイル名なし）でアクセスされたときに返すトップページの指定です。ここを index.html にしておかないと、トップにアクセスしたときにうまく表示されません。

5. バケットポリシーを適用して、CloudFront からの読み取りを許可する

   手順 3 でコンソールが提示したバケットポリシーを適用します。CloudFront の画面の「ポリシーをコピー」を使い、S3 バケットの「アクセス許可」→「バケットポリシー」に貼り付けて保存します。これで「この CloudFront ディストリビューションからの読み取りだけ」を許可できます。

   許可するのは CloudFront だけ

   このポリシーは、CloudFront のサービスからのアクセスに限って s3:GetObject（読み取り）を許可する内容です。一般の利用者がバケットに直接アクセスすることは、引き続きできません。

6. デプロイ完了を待ち、CloudFront のドメインで確認する

   ディストリビューションの「最終変更日」やステータスが更新され、配信準備が整うまで数分待ちます。準備ができたら、「ディストリビューションドメイン名」（例：d111111abcdef8.cloudfront.net）を、ブラウザで https://<ドメイン名> として開きます。index.html の内容が HTTPS で表示されれば成功です。

   反映には少し時間がかかる

   作成・変更が世界中の拠点に行き渡るまで、少し時間がかかります。すぐ表示されないときは、数分待ってから再読み込みしてみましょう。

初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。

要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。S3・CloudFront コンソールとブラウザを開いて、次を順に確かめましょう。

• S3 バケットの「アクセス」が 「公開されていません」（非公開）のままになっている。
• CloudFront のディストリビューションが 有効（Enabled）で、配信準備が完了している。
• ディストリビューションの設定で、デフォルトルートオブジェクトが index.html になっている。
• S3 のバケットポリシーに、CloudFront のサービスからの s3:GetObject を許可するルールがある。
• https://<CloudFront ドメイン> をブラウザで開くと、index.html が HTTPS で表示される。

手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。

1. 今回はバケットを公開せず、CloudFront だけが読めるようにしました。もしバケットも公開してしまうと、CloudFront を前に置いた意味はどう薄れてしまうでしょうか。
   ヒント

   バケットが公開されていると、利用者が CloudFront を通さずに S3 へ直接アクセスする経路が残ります。すると、キャッシュや HTTPS、各種の保護を通らないアクセスが生まれます。「入口を 1 つに絞る」ことの意味から考えてみましょう。
2. CloudFront は内容を各拠点にキャッシュして速く配信します。この「キャッシュ」は速さに貢献する一方で、運用上の注意も生みます。それはどんなことで、どう対処できるでしょうか。
   ヒント

   キャッシュがあるぶん、元のファイルを更新しても、しばらく古い内容が配信され続けます。更新をすぐ反映したいときは「無効化」でキャッシュを消す、もしくはキャッシュの保持時間（TTL）を意識する、といった対処があります。速さと反映の早さのバランス、という観点で考えてみましょう。
3. 今回のドメインは xxxx.cloudfront.net でした。実際のサービスでは、自分のドメイン名（例：www.example.com）で公開したいことが多いはずです。CloudFront で独自ドメインと HTTPS 証明書を使うには、何を組み合わせればよいか調べてみましょう。
   ヒント

   独自ドメインを使うには、ドメイン名と CloudFront を結び付ける名前解決の仕組みと、その名前用の HTTPS 証明書が必要になります。「代替ドメイン名（CNAME）」「証明書を発行・管理するサービス」といったキーワードで調べてみましょう。

登場人物が複数あるので、順番に片づけます。CloudFront はいったん無効化してからでないと削除できない点に注意しましょう。

1. ディストリビューションを無効化する：CloudFront で対象を選び、「無効化（Disable）」します。反映が完了するまで数分かかります。
2. ディストリビューションを削除する：無効化が完了したら、「削除」します。
3. S3 のオブジェクトとバケットを削除する：index.html を削除し、バケットを空にしてから削除します。
4. オリジンアクセスコントロールを削除する（任意）：使わなくなったオリジンアクセスコントロールは、CloudFront の設定から削除できます。