AWS S3とCloudFrontによるモダン静的サイトホスティング構築 ~ Dev.

序章：なぜ今、静的サイトホスティングなのか？

現代のウェブ開発において、動的なコンテンツを生成するサーバーサイドアプリケーションが主流である一方、静的ウェブサイトの重要性と利便性もまた再評価されています。静的ウェブサイトとは、HTML、CSS、JavaScript、画像ファイルなど、あらかじめ作成された固定のファイル群で構成されるウェブサイトです。サーバー側での複雑な処理やデータベースへのアクセスを必要としないため、そのシンプルさがもたらす恩恵は計り知れません。主なメリットとしては、圧倒的な表示速度、堅牢なセキュリティ、そして非常に低い運用コストが挙げられます。特に、ブログ、ポートフォリオサイト、製品のランディングページ、ドキュメントサイトなど、コンテンツの更新頻度が比較的低い用途において、静的サイトはその真価を発揮します。

この静的サイトをホスティングする上で、Amazon Web Services (AWS) が提供する二つのサービス、Amazon S3 (Simple Storage Service) と Amazon CloudFront の組み合わせは、業界のデファクトスタンダードとも言える強力なソリューションを提供します。Amazon S3は、その名の通りシンプルなオブジェクトストレージサービスですが、静的ウェブサイトのホスティング機能を備えています。一方、Amazon CloudFrontはグローバルなコンテンツ配信ネットワーク（CDN）であり、世界中に配置されたエッジロケーションにコンテンツをキャッシュすることで、ユーザーに最も近い場所から高速にコンテンツを配信します。この二つを組み合わせることで、スケーラビリティ、高可用性、そしてグローバル規模での低レイテンシーを実現した、プロフェッショナルなウェブサイトを驚くほど低コストで構築・運用することが可能になるのです。

本稿では、単に手順をなぞるだけでなく、AWS S3とCloudFrontを用いた静的サイトホスティングのアーキテクチャの根底にある概念を深く掘り下げ、初心者から中級者までが実践できる、詳細かつ体系的な構築プロセスを解説します。S3バケットの基本的な設定から、カスタムドメインの適用、そしてCloudFrontによるパフォーマンスとセキュリティの最大化まで、各ステップの「なぜ」を理解しながら、最適な設定を目指します。

第1章：基盤となるAWS S3の核心を理解する

1.1 Amazon S3とは何か：単なるストレージを超えて

Amazon S3は、AWSが提供するオブジェクトストレージサービスです。多くの開発者が最初に触れるAWSサービスの一つであり、そのシンプルさと強力な機能から、データのバックアップ、ビッグデータ分析のデータレイク、そしてもちろんウェブホスティングまで、多岐にわたる用途で利用されています。S3を理解する上で重要な概念は以下の通りです。

オブジェクトストレージ: S3はファイルシステムのように階層構造を持つのではなく、フラットな構造でデータを「オブジェクト」として保存します。各オブジェクトは、データ本体（ファイル）、一意のキー（ファイル名/パス）、そしてメタデータ（コンテンツタイプ、最終更新日など）で構成されます。
バケット: オブジェクトを格納するための最上位コンテナが「バケット」です。バケット名は全世界のAWSアカウントを通じて一意である必要があります。これは、バケットがDNS名としても機能するためです。
高い耐久性と可用性: S3は「99.999999999% (イレブンナイン)」という驚異的なデータ耐久性を誇るように設計されています。これは、アップロードされたオブジェクトが複数の物理的に離れたデータセンター（アベイラビリティゾーン）に自動的に複製されることで実現されており、データ損失のリスクを極限まで低減します。また、高い可用性も保証されており、いつでもデータにアクセスできます。
スケーラビリティ: S3にはストレージ容量の制限が事実上ありません。数キロバイトの小さなファイルから、数テラバイトの巨大なオブジェクトまで、必要に応じて無制限にデータを保存でき、パフォーマンスが低下することもありません。

これらの特性により、S3は静的サイトの構成ファイルを安全かつ確実に保管し、世界中からのアクセス要求に応えるための完璧な基盤となります。

1.2 静的ウェブホスティングの仕組みとS3の役割

前述の通り、静的ウェブサイトはサーバーサイドのプログラミング言語（PHP, Python, Rubyなど）やデータベースを必要としません。ユーザーがブラウザでウェブサイトにアクセスした際、サーバーは要求されたHTML、CSS、JavaScriptファイルをそのままクライアントに送信するだけです。この単純な仕組みが、高速表示とセキュリティの高さに直結します。

AWS S3には、この静的ウェブホスティングを簡単に行うための機能が組み込まれています。特定のS3バケットに対してこの機能を有効にすると、AWSはそのバケットをウェブサーバーのように振る舞わせることができます。具体的には、以下のようなプロセスで機能します。

ユーザーがウェブサイトのURLにアクセスします。
DNS（後述するAmazon Route 53など）が、そのドメインをS3バケットに関連付けられた特定のウェブサイトエンドポイントに解決します。
S3はリクエストを受け取り、URLパスに対応するオブジェクト（HTMLファイルなど）を検索します。
オブジェクトが見つかれば、S3はHTTPレスポンスとしてそのオブジェクトの内容をユーザーのブラウザに返します。

この機能により、開発者は仮想サーバー（EC2インスタンスなど）をプロビジョニングしたり、ウェブサーバーソフトウェア（Apache, Nginxなど）をインストール・管理したりする手間から完全に解放されます。必要なのは、S3バケットを作成し、ファイルをアップロードし、いくつかの設定を有効にするだけです。このサーバーレスのアプローチは、インフラ管理のオーバーヘッドを劇的に削減し、開発者がコンテンツそのものに集中できる環境を提供します。

第2章：S3バケットの作成と基本設定

理論を学んだところで、いよいよ実践的な構築作業に入ります。最初のステップは、ウェブサイトのファイルを格納するためのS3バケットを作成し、適切に設定することです。この段階での設定が、後のパフォーマンスとセキュリティに大きく影響します。

2.1 AWSアカウントと前提条件

作業を開始する前に、AWSアカウントが必要です。まだお持ちでない場合は、AWS公式ウェブサイトからサインアップしてください。多くの場合、無料利用枠が適用されるため、小規模なサイトであればほとんどコストをかけずに試すことができます。また、ホスティングする静的サイトのファイル（最低でも `index.html`）を手元に用意しておきましょう。

2.2 S3バケットの作成：細部に宿る重要性

AWSマネジメントコンソールにログインし、サービス検索バーで「S3」と入力してS3のダッシュボードに移動します。「バケットを作成」ボタンをクリックして、作成プロセスを開始します。

バケット名: ここで指定する名前は、全世界で一意でなければなりません。また、後でカスタムドメイン（例: `www.example.com`）を接続する予定がある場合、バケット名をそのドメイン名と完全に一致させることが、一部の古い設定方法では推奨されていましたが、CloudFrontを前面に配置する現代的なアプローチでは必須ではありません。しかし、管理のしやすさからドメイン名に関連した名前（例: `example-com-static-site`）を付けるのが一般的です。バケット名の命名規則（小文字の英数字とハイフンのみ使用可など）にも注意してください。
AWSリージョン: バケットを作成する地理的な場所を選択します。ウェブサイトの主要なターゲットオーディエンスに最も近いリージョンを選択することで、レイテンシーを低減できます。例えば、日本のユーザーが中心であれば「アジアパシフィック (東京) `ap-northeast-1`」を選択するのが最適です。ただし、最終的にはCloudFrontがグローバルな配信を行うため、この選択の重要度は相対的に下がります。
オブジェクト所有者: 「ACL無効（推奨）」を選択します。これにより、バケットとそのオブジェクトへのアクセス制御がIAMポリシーとバケットポリシーに一元化され、管理が簡素化されます。
このバケットのブロックパブリックアクセス設定: ここが非常に重要なセキュリティ設定です。デフォルトでは、「パブリックアクセスをすべてブロック」が有効になっています。これは、意図しない情報漏洩を防ぐためのフェイルセーフ機能です。現時点では、この設定をデフォルトのまま（すべてブロック）にしておきます。後ほど、CloudFrontからのアクセスのみを許可する安全な方法で公開設定を行います。安易にこのチェックを外してバケット全体を公開することは、セキュリティ上のリスクを伴うため避けるべきです。
その他の設定（バージョニング、タグ、暗号化など）: これらは必要に応じて設定します。バージョニングを有効にすると、誤ってファイルを上書き・削除した場合でも以前のバージョンに復元できます。デフォルトの暗号化を有効にしておくこともセキュリティのベストプラクティスです。

すべての設定を確認したら、「バケットを作成」をクリックします。これでウェブサイトのコンテンツを格納する器が準備できました。

2.3 ウェブサイトファイルのアップロード

作成したバケットを選択し、「アップロード」ボタンをクリックします。ローカルマシンに用意しておいた静的サイトのファイル（`index.html`, `error.html`, CSSフォルダ, JSフォルダなど）をドラッグ＆ドロップするか、「ファイルを追加」または「フォルダを追加」で選択します。すべてのファイルがリストに追加されたことを確認し、「アップロード」をクリックします。アップロードはAWS CLIを使用するとより効率的に行うこともできます。


# AWS CLI を使用したアップロード例
# ./site/ 以下のファイルを my-unique-bucket-name バケットに同期する
aws s3 sync ./site/ s3://my-unique-bucket-name

第3章：静的ウェブホスティングの有効化とアクセス権の設定

ファイルをアップロードしただけでは、ウェブサイトとして機能しません。次に、S3バケットにウェブサーバーとしての役割を割り当て、外部からアクセスできるように設定します。

3.1 S3静的ウェブサイトホスティング機能の有効化

作成したバケットの詳細ページに移動し、「プロパティ」タブをクリックします。ページの一番下までスクロールすると、「静的ウェブサイトホスティング」というセクションがあります。ここの「編集」ボタンをクリックします。

静的ウェブサイトホスティング: 「有効にする」を選択します。
ホスティングタイプ: 「静的ウェブサイトをホストする」が選択されていることを確認します。
インデックスドキュメント: ウェブサイトのルート（例: `http://example.com/`）やサブディレクトリ（例: `http://example.com/about/`）にアクセスがあった場合に表示するデフォルトのファイル名を指定します。通常は `index.html` を指定します。
エラードキュメント: 存在しないページ（404 Not Foundなど）にアクセスがあった場合に表示するカスタムエラーページのファイル名を指定します。例えば `error.html` を指定することで、ユーザーフレンドリーなエラー表示が可能になります。

設定を終えたら、「変更の保存」をクリックします。保存後、再び「静的ウェブサイトホスティング」セクションに戻ると、バケットウェブサイトエンドポイントという形式のURLが表示されます（例: `http://my-unique-bucket-name.s3-website-ap-northeast-1.amazonaws.com`）。このURLが、S3によってホストされているウェブサイトの直接の入り口となります。しかし、この時点ではまだパブリックアクセスがブロックされているため、アクセスしても「403 Forbidden」エラーが表示されるはずです。次のステップで、このアクセス権を正しく設定します。

3.2 バケットポリシーによる安全な公開設定

S3バケットのコンテンツをインターネットに公開するには、誰が（Principal）、どのリソース（Resource）に対して、何を（Action）許可するかを定義したバケットポリシーを設定する必要があります。個別のオブジェクトACLを変更するよりも、バケットポリシーで一元管理する方がはるかに安全で効率的です。

バケットの詳細ページから「アクセス許可」タブを選択し、「バケットポリシー」セクションの「編集」をクリックします。以下のJSONをポリシーエディタに貼り付けます。`YOUR_BUCKET_NAME` の部分を、ご自身のバケット名に書き換えてください。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"
        }
    ]
}

このポリシーの意味を分解してみましょう。

`"Effect": "Allow"`: このポリシーが許可を与えるものであることを示します。
`"Principal": "*"`: アクセスを許可する対象を指定します。`*` は「不特定多数の誰でも」を意味します。つまり、インターネット上の誰からでもアクセスを許可します。
`"Action": "s3:GetObject"`: 許可する操作を指定します。`s3:GetObject` は、S3オブジェクト（ファイル）を読み取る権限です。
`"Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"`: 操作の対象となるリソースを指定します。`YOUR_BUCKET_NAME` バケット内のすべてのオブジェクト（`/*` がそれを意味します）が対象となります。

ポリシーを貼り付けて保存しようとすると、「このバケットにはパブリックアクセスをブロックする設定がありますが、このポリシーを保存するとバケットはパブリックになります」という警告が表示される場合があります。これは、先ほどブロックパブリックアクセス設定を有効にしたためです。静的サイトホスティングのためには、この公開設定が必要です。ポリシーを保存した後、「アクセス許可」タブの「ブロックパブリックアクセス」設定に戻り、「パブリックアクセスをすべてブロック」のチェックを外し、「変更の保存」を行う必要があります。

注意: この設定はバケット内の全オブジェクトを公開するものです。CloudFrontを導入する最終的な構成では、このポリシーをさらに制限し、CloudFrontからのアクセスのみを許可するように変更します。

設定完了後、先ほど確認したS3のウェブサイトエンドポイントにブラウザでアクセスしてみてください。今度は `index.html` が正しく表示されるはずです。存在しないURLにアクセスして、`error.html` が表示されることも確認しましょう。

第4章：カスタムドメインの接続とDNS設定

S3のエンドポイントURLでウェブサイトを公開できましたが、このままではURLが長すぎて覚えにくく、プロフェッショナルではありません。次に、独自のドメイン（例: `www.example.com`）をこのウェブサイトに接続します。このプロセスには、AWSのDNSサービスであるAmazon Route 53を使用するのが最も簡単で効率的です。

4.1 Amazon Route 53の準備

カスタムドメインをまだ持っていない場合は、Route 53や他のドメインレジストラ（GoDaddy, Namecheapなど）で取得してください。Route 53でドメインを取得すると、後の設定が自動化される部分があり便利です。

ドメインを取得したら、Route 53のダッシュボードで「ホストゾーン」を作成します。ホストゾーンは、特定のドメインに関するDNSレコードを管理するためのコンテナです。

Route 53のダッシュボードで「ホストゾーンの作成」をクリックします。
「ドメイン名」に、使用したいドメイン名（例: `example.com`）を入力します。
「タイプ」として「パブリックホストゾーン」を選択します。
「ホストゾーンの作成」をクリックします。

ホストゾーンが作成されると、NS（ネームサーバー）レコードがいくつか表示されます。Route 53以外でドメインを取得した場合は、ドメインを取得したレジストラの管理画面で、ネームサーバーの情報をこのRoute 53のNSレコードの値に更新する必要があります。この変更がインターネット全体に反映される（DNS伝播）には、数時間から最大48時間かかる場合があります。

4.2 エイリアスレコードの作成：S3エンドポイントへの接続

ホストゾーンの準備ができたら、ドメイン名をS3のウェブサイトエンドポイントに向けるためのDNSレコードを作成します。ここで使用するのが、Route 53の強力な機能であるエイリアスレコードです。エイリアスレコードは、CNAMEレコードと似ていますが、より高機能で、ルートドメイン（`example.com`のような`www`なしのドメイン）に対しても設定できるという大きな利点があります。

ここでは、ルートドメイン（`example.com`）と`www`サブドメイン（`www.example.com`）の両方でアクセスできるように設定します。

1. ルートドメイン (`example.com`) のレコード作成

作成したホストゾーンの詳細ページで、「レコードを作成」をクリックします。
「レコード名」は空欄のままにします（これによりルートドメインが対象になります）。
「レコードタイプ」は「A - IPv4アドレスへのトラフィックをルーティングします」を選択します。
「エイリアス」のトグルをオンにします。
「トラフィックのルーティング先」で、ドロップダウンから「S3ウェブサイトエンドポイントへのエイリアス」を選択します。
次のドロップダウンで、先ほどS3バケットを作成したリージョンを選択します。
S3のエンドポイント（`s3-website.ap-northeast-1.amazonaws.com` のような形式）が自動的に表示されるので、それを選択します。
「レコードを作成」をクリックします。

2. `www`サブドメイン (`www.example.com`) のレコード作成

一般的に、`www`ありと`www`なしのどちらか一方を正規のURLとし、もう一方からはリダイレクトさせることがSEO上推奨されます。S3単体でもリダイレクト設定は可能ですが、CloudFrontを導入するとより柔軟に対応できます。ここでは単純に両方からアクセスできるように、もう一つレコードを作成します。

再び「レコードを作成」をクリックします。
「レコード名」に `www` と入力します。
「レコードタイプ」は同様に「A」を選択し、「エイリアス」をオンにします。
ルーティング先も、ルートドメインの時と全く同じS3ウェブサイトエンドポイントを選択します。
「レコードを作成」をクリックします。

これらの設定が完了し、DNSが伝播すると、ブラウザで `http://example.com` や `http://www.example.com` にアクセスして、S3でホストされているウェブサイトが表示されるようになります。ただし、この時点ではまだ `http` でのアクセスであり、セキュリティで保護された `https` 接続ではありません。これを解決するのが、次の章で導入するAmazon CloudFrontです。

第5章：CloudFrontによるパフォーマンスとセキュリティの強化

現在、私たちのウェブサイトはS3から直接配信されています。これは機能的には問題ありませんが、パフォーマンスとセキュリティの観点からはまだ最適化の余地があります。ここで登場するのが、CDNサービスであるAmazon CloudFrontです。CloudFrontを導入することで、以下の大きなメリットが得られます。

グローバルな高速配信: 世界中に存在するエッジロケーションにウェブサイトのコンテンツがキャッシュされます。ユーザーは物理的に最も近いエッジロケーションからコンテンツを受け取るため、表示速度が劇的に向上します。
無料のSSL/TLS証明書: AWS Certificate Manager (ACM) と連携することで、カスタムドメインに対して無料でSSL/TLS証明書を発行し、HTTPS通信を簡単に有効化できます。これにより、通信が暗号化され、サイトの信頼性が向上します。
オリジンサーバーの保護: S3バケットへの直接アクセスを禁止し、CloudFront経由でのみアクセスを許可する設定（Origin Access Identity/Control）が可能です。これにより、S3バケットを非公開に保ち、セキュリティを強化できます。
コスト削減: 多くのリクエストがCloudFrontのキャッシュから処理されるため、S3へのリクエスト数とデータ転送量が削減され、結果的にS3の利用料金を抑えることができます。

5.1 CloudFrontディストリビューションの作成

AWSマネジメントコンソールで「CloudFront」を検索し、ダッシュボードに移動します。「ディストリビューションを作成」をクリックして設定を開始します。

オリジンドメイン: ここにはコンテンツの元となる場所を指定します。ドロップダウンリストにS3バケット（`my-unique-bucket-name.s3.ap-northeast-1.amazonaws.com`のような形式）が表示されるので、それを選択します。注意：ここでS3の「ウェブサイトエンドポイント」ではなく、「REST APIエンドポイント」を選択することが重要です。
オリジンアクセス: ここがセキュリティの要です。「Origin access control settings (recommended)」を選択し、「コントロール設定を作成」をクリックします。適当な名前を付けて作成すると、新しいOrigin Access Control (OAC)が設定されます。これにより、S3バケットは指定されたこのCloudFrontディストリビューションからのアクセスのみを許可するようになります。
デフォルトのキャッシュビヘイビア:
- ビューワープロトコルポリシー: 「Redirect HTTP to HTTPS」を選択します。これにより、すべてのHTTPリクエストが自動的にHTTPSにリダイレクトされ、常時SSL化が実現します。
- 許可されたHTTPメソッド: 「GET, HEAD」のままで通常は問題ありません。
- キャッシュキーとオリジンリクエスト: 「CachingOptimized」ポリシーのままで良いでしょう。
設定:
- 代替ドメイン名 (CNAME): 「項目を追加」をクリックし、ウェブサイトで使用するドメイン名（`example.com` と `www.example.com` の両方）を登録します。
- カスタムSSL証明書: ここでHTTPSを有効にします。事前にACMで証明書を発行しておく必要があります。
  - 「証明書をリクエスト」ボタンをクリックするとACMの画面に遷移します。
  - `example.com` と `*.example.com` の両方を対象とする証明書をリクエストし、DNS検証を選択するのが簡単です。
  - 検証用のCNAMEレコードをRoute 53に作成するよう指示されるので、ボタン一つで作成します。
  - 数分で証明書が発行されたら、CloudFrontの画面に戻り、ドロップダウンから作成した証明書を選択します。
- デフォルトルートオブジェクト: `index.html` と入力します。これにより、ルートURLへのアクセス時に `index.html` が返されるようになります。

すべての設定を確認し、「ディストリビューションを作成」をクリックします。ディストリビューションの作成とグローバルなデプロイには10分から20分程度かかります。ステータスが「デプロイ中」から「有効」に変わるのを待ちます。

5.2 S3バケットポリシーの更新（OAC対応）

CloudFrontのディストリビューション作成画面でOACを設定すると、「バケットポリシーをコピー」というボタンと、S3バケットポリシーを更新する必要がある旨のメッセージが表示されます。このポリシーをコピーし、S3バケットの「アクセス許可」 -> 「バケットポリシー」を編集して、以前設定した公開ポリシーをこの新しいポリシーに置き換えます。

新しいポリシーは以下のようになります。`YOUR_BUCKET_NAME`と`YOUR_DISTRIBUTION_ID`は自動的に設定されます。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::YOUR_AWS_ACCOUNT_ID:distribution/YOUR_DISTRIBUTION_ID"
                }
            }
        }
    ]
}

このポリシーは、`Principal`（アクセス元）をCloudFrontサービスに限定し、さらに`Condition`で特定のディストリビューションからのみのアクセスに絞り込んでいます。これにより、S3バケットへの直接のパブリックアクセスは完全にブロックされ、CloudFrontを経由した安全なアクセスのみが許可されるようになります。

5.3 Route 53 DNSレコードの最終更新

最後のステップです。Route 53のホストゾーンに戻り、以前作成した2つのエイリアスレコードを編集します。トラフィックのルーティング先をS3エンドポイントから、新しく作成したCloudFrontディストリビューションに変更します。

`example.com` と `www.example.com` の各レコードを編集します。
「トラフィックのルーティング先」で、「CloudFrontディストリビューションへのエイリアス」を選択します。
ドロップダウンから、作成したディストリビューションのドメイン名（例: `d12345abcdef.cloudfront.net`）を選択します。
変更を保存します。

このDNS変更が反映されると、カスタムドメインへのアクセスはすべてCloudFrontを経由するようになります。`https://www.example.com` にアクセスし、サイトが正しく表示され、ブラウザに鍵マーク（セキュアな接続）が表示されることを確認してください。

第6章：高度な設定と運用ベストプラクティス

基本的な構築は完了しましたが、よりプロフェッショナルな運用を目指すための高度なトピックをいくつか紹介します。

6.1 CI/CDパイプラインによるデプロイの自動化

ウェブサイトのコンテンツを更新するたびに手動でS3にファイルをアップロードするのは手間がかかり、ヒューマンエラーの原因にもなります。GitHub ActionsやAWS CodePipelineなどのCI/CDツールを導入することで、コードをリポジトリにプッシュするだけで自動的にビルドとデプロイが行われるように設定できます。

以下は、GitHub Actionsを使用したデプロイの簡単なワークフロー例です。


name: Deploy to S3 and Invalidate CloudFront

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-1

      - name: Deploy static site to S3 bucket
        run: aws s3 sync ./public/ s3://YOUR_BUCKET_NAME --delete

      - name: Invalidate CloudFront cache
        run: aws cloudfront create-invalidation --distribution-id YOUR_DISTRIBUTION_ID --paths "/*"

このワークフローは、`main`ブランチにプッシュがあるたびに、指定したフォルダの内容をS3バケットに同期し、さらにCloudFrontのキャッシュを無効化（Invalidation）して、最新のコンテンツが即座に反映されるようにします。

6.2 シングルページアプリケーション（SPA）への対応

ReactやVue、Angularなどで構築されたSPAでは、クライアントサイドでルーティングが行われます。そのため、ユーザーが直接 `/about` のようなサブページにアクセスしたり、ページをリロードしたりすると、S3には対応する `/about/index.html` というファイルが存在しないため、404エラーが返されてしまいます。これを解決するには、CloudFrontが403や404エラーを受け取った際に、単にエラーページを返すのではなく、常に `/index.html` を返し、HTTPステータスコードを200に変更するよう設定します。

CloudFrontディストリビューションの「エラーページ」タブで、「カスタムエラーレスポンスを作成」をクリックし、以下の設定を行います。

HTTP エラーコード: 403 (Forbidden) または 404 (Not Found)
エラーレスポンスをカスタマイズ: はい
レスポンスページのパス: `/index.html`
HTTP レスポンスコード: 200 (OK)

この設定により、すべてのパスへのリクエストが `index.html` に集約され、React Routerなどのクライアントサイドルーターが正しく処理できるようになります。

6.3 コストの監視と最適化

このアーキテクチャは非常に低コストですが、それでも利用状況を把握しておくことは重要です。AWS Cost ExplorerやAWS Budgetsを使用して、S3のストレージ料金、データ転送料金、CloudFrontの料金などを監視し、予期せぬコスト増を避けるために予算アラートを設定しておきましょう。特に、CloudFrontのキャッシュ無効化（Invalidation）は、月に1000パスまでは無料ですが、それを超えると有料になる点に注意が必要です。

結論：無限の可能性を秘めたサーバーレスアーキテクチャ

本稿では、AWS S3とCloudFrontを組み合わせた静的サイトホスティングの構築方法を、基本的な概念から実践的な設定、そして高度な運用テクニックまで網羅的に解説しました。このアーキテクチャは、個人ブログから企業のマーケティングサイトまで、幅広い用途に対応できる柔軟性と堅牢性を備えています。

サーバーのプロビジョニングやOSのパッチ適用といったインフラ管理の煩わしさから解放され、コンテンツの創造に集中できる環境。世界中のユーザーに高速かつ安定してコンテンツを届けられるパフォーマンス。そして、従量課金制による圧倒的なコスト効率。これらすべてが、S3とCloudFrontが提供する価値です。静的サイトジェネレーター（Hugo, Jekyll, Next.jsなど）やCI/CDツールと組み合わせることで、その可能性はさらに広がります。ぜひこの強力なサーバーレスアーキテクチャを活用し、あなたのアイデアを世界に発信してください。

Thursday, July 20, 2023

AWS S3とCloudFrontによるモダン静的サイトホスティング構築