はじめに
Webアプリ運用では、「特設ページやキャンペーン用ページ(LP)を追加したい」という要件がよく発生します。
既存のEC2(アプリケーションサーバー)上に直接ファイルを配置する方法もありますが、アプリケーションと静的コンテンツを同じサーバーで管理することになるため、運用や構成管理の面で考慮が必要です。
今回は、既存のドメイン・SSL証明書・EC2には変更を加えず、既存CloudFrontの設定を拡張することで、S3上の静的コンテンツを特定パス配下で公開する構成を紹介します。
S3はCloudFrontからのみアクセスできるようにOAC(Origin Access Control)を利用し、S3バケット自体は非公開とします。
構成概要
既存の構成
- CDN / Edge:CloudFront
- Origin:EC2(Webアプリケーション)
- Domain:既存ドメイン(例:example.com)
- Behavior:デフォルト(/*) → EC2オリジン
今回構築する構成
既存CloudFrontにS3を第2のOriginとして追加し、/example2026/* に対するリクエストだけS3へルーティングします。
【本記事の構成イメージ】
┌─ Default (/*) ───────────────> EC2(Web App)
User ──> CloudFront ┤
└─ /example2026/* ────────────> S3(Static Content / Private)
↑
│ OAC
│
CloudFrontのみ
この構成では、既存のEC2を停止したり、EC2に静的ファイルを配置したりする必要はありません。
構築手順
1. S3バケットの作成とコンテンツ配置
HTML、CSS、JavaScript、画像などの静的ファイルを格納するS3バケットを作成します。
例えば、以下のようなバケットを作成します。
my-app-example2026-bucket
S3の設定では、「パブリックアクセスをすべてブロック」を有効にしたままにします。
S3を直接インターネットへ公開するのではなく、後ほど設定するCloudFrontのOAC経由でアクセスさせます。
コンテンツ例
今回は、S3バケット内に以下のように配置します。
/
├── example2026/
│ ├── index.html
│ ├── css/
│ │ └── style.css
│ ├── js/
│ │ └── script.js
│ └── images/
│ └── main.jpg
2. S3へのアクセス許可をOACで設定
CloudFrontからS3へアクセスするため、Origin Access Control(OAC)を利用します。
OACを利用することで、S3バケットをパブリック公開せず、CloudFrontから認証付きでアクセスできる構成にできます。
設定手順
- CloudFrontコンソールを開く
- 「オリジンアクセスコントロール」を開く
- 新しいOACを作成
- 対象のS3オリジンで作成したOACを使用
- CloudFrontが提示するS3バケットポリシーを確認
- S3バケットの「アクセス許可」→「バケットポリシー」に設定
バケットポリシーでは、対象のCloudFrontディストリビューションからのアクセスのみを許可します。
S3の「パブリックアクセスをすべてブロック」は有効なままにしておきます。
3. CloudFrontにS3オリジンを追加
既存のCloudFrontディストリビューションに、今回作成したS3バケットを新しいOriginとして追加します。
オリジンの追加
CloudFrontコンソールで対象ディストリビューションを開き、「オリジン」→「オリジンを作成」を選択します。
設定例:
- Origin domain:作成したS3バケット
- Origin access:Origin access control settings
- Origin access control:先ほど作成したOAC
ここでは、S3の静的ウェブサイトホスティング用エンドポイントではなく、通常のS3バケットをOriginとして使用します。
4. CloudFrontにBehaviorを追加
次に、/example2026/* のリクエストだけS3へ送るBehaviorを追加します。
CloudFrontの「ビヘイビア」から「ビヘイビアを作成」を選択します。
設定例
- パスパターン:
/example2026/* - ターゲットオリジン:今回追加したS3オリジン
- Viewer protocol policy:Redirect HTTP to HTTPS
- Allowed HTTP methods:GET, HEAD
- Cache policy:用途に応じて設定
これにより、例えば、https://example.com/example2026/index.html
へのアクセスはS3へルーティングされます。
一方、https://example.com/https://example.com/loginhttps://example.com/news/
など、/example2026/* に該当しないリクエストは、これまで通り既存のEC2へルーティングされます。
5. URLについての注意点
今回はCloudFront Functionsを使用しません。
そのため、S3のWebsite Endpointで利用できるような、/example2026/ から自動的に /example2026/index.html を返す仕組みは使用しません。
そのため、今回の構成では基本的に以下のURLでアクセスします。
https://example.com/example2026/index.html
特設ページのURLとして https://example.com/example2026/ を必須にしたい場合は、別途CloudFront Functionsや別のルーティング方法などを検討する必要があります。
今回の記事では構成をシンプルにするため、index.htmlを明示したURLを利用します。
6. CloudFrontのデプロイ完了を確認
CloudFrontのOriginとBehaviorを変更すると、設定が各CloudFront Edge Locationへ反映されます。
CloudFrontコンソールでディストリビューションのステータスが、Deploying から Enabled など、変更反映済みの状態になることを確認します。
その後、実際にブラウザからアクセスします。
https://example.com/example2026/index.html
動作確認
最低限、以下を確認します。
特設ページhttps://example.com/example2026/index.html
→ S3上のindex.htmlが表示される
CSS・JavaScript・画像https://example.com/example2026/css/style.csshttps://example.com/example2026/js/script.jshttps://example.com/example2026/images/main.jpg
→ S3上の各ファイルが正常に読み込まれる
既存サイトhttps://example.com/
→ 従来通りEC2のWebアプリが表示される
S3への直接アクセス
S3バケットをパブリック公開していないため、S3のURLから直接オブジェクトを取得できないことも確認します。
この構成のメリット
EC2の追加・増強が不要
今回の特設ページのために、新しいEC2を用意したり、既存EC2のスペックを変更したりする必要がありません。
静的コンテンツはS3から配信するため、既存アプリケーションサーバーへの負荷を抑えられます。
既存ドメインをそのまま利用できる
既存CloudFrontを利用するため、新しいドメインを用意する必要がありません。
例えば、https://example.com/example2026/index.html という既存ドメイン配下のURLで公開できます。
既存CloudFrontに設定済みのSSL/TLS証明書もそのまま利用できます。
S3を非公開にできる
S3のパブリックアクセスを許可せず、OACを利用してCloudFrontからアクセスさせることで、S3バケットを直接公開しない構成にできます。
既存EC2への影響を抑えられる/example2026/* のリクエストだけをS3へ振り分けるため、既存のEC2側のアプリケーションやWebサーバー設定を変更する必要がありません。
注意点
今回の構成では、既存CloudFrontの設定変更が必要です。
そのため、「既存環境に一切変更を加えない」という構成ではありません。
変更するのは主に、
- S3バケットの追加
- S3のバケットポリシー
- CloudFrontのOrigin追加
- CloudFrontのBehavior追加
です。一方、以下については基本的に変更する必要はありません。
- 既存EC2
- 既存Webアプリケーション
- 既存ドメイン
- 既存SSL/TLS証明書
また、S3やCloudFrontを利用するため、利用料金が完全にゼロになるわけではありません。
正確には、特設ページのためにEC2を追加・増強する必要がなく、既存インフラを活用して静的コンテンツを配信できる構成です。
まとめ
既存サイトが、
CloudFront → EC2
という構成になっている場合でも、CloudFrontにS3オリジンを追加することで、
CloudFront
├── /* → EC2(既存サイト)
│
└── /example2026/* → S3(特設ページ)
という構成に拡張できます。
この方法なら、既存EC2を停止したり、Webサーバーへ特設ページのファイルを配置したりすることなく、既存ドメイン配下に静的ページを追加公開できます。
また、S3はOACによってCloudFrontからのアクセスに限定できるため、S3バケットを直接パブリック公開する必要もありません。
特設ページや期間限定LPなど、アプリケーションとは分離して配信したい静的コンテンツには適した構成です。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK