はじめに

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から認証付きでアクセスできる構成にできます。

設定手順

  1. CloudFrontコンソールを開く
  2. 「オリジンアクセスコントロール」を開く
  3. 新しいOACを作成
  4. 対象のS3オリジンで作成したOACを使用
  5. CloudFrontが提示するS3バケットポリシーを確認
  6. 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/login
https://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.css
https://example.com/example2026/js/script.js
https://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

エンジニアと話してみる

関連リンク

AI・クラウド・データ分析のご相談はネクスト株式会社までお問い合わせください。