WordPressからS3にオフロードしたメディアファイルをCloudFrontで配信する方法

WordPressで開設したサイトにおいて、画像・動画ファイル(以下、メディアファイル)の容量は大きな問題となります。

画像圧縮プラグインを用いることもファイル容量解決のひとつの手ですが、サイトの規模が大きくなりメディアファイルが増えると、サーバーのデータ保存容量が圧迫されてサイト表示速度があきらかに遅くなります。

Webサイト表示速度が遅いと、せっかく訪問したユーザーが待ち切れずに離脱してしまうため、大きな機会損失となるでしょう。

そこで、WordPressでアップロードしたメディアファイルをAWSのS3バケットにオフロード(自動保存)し、Cloudfrontを通じてCDN配信する方法を解説します。これさえできれば、メディアファイルでサイトが重くなる問題を一発解決

少し複雑に感じるかもしれませんが、記事に書かれている通りに進めれば問題ありません。

タップできる目次

WordPress・S3・Cloudfrontを連携する流れ

WordPress・S3・Cloudfrontの連携イメージ図
WordPress・S3・Cloudfrontの連携イメージ図

WordPressとAWS(S3とCloudfront)を連携して、メディアファイルをサイトにCDN配信するおおまかな流れは、以下の通りです。

  • Amazon Web Services(AWS)のアカウントを開設
  • メディアファイルを保存するAmazon S3のバケットを作成
  • Amazon S3とCloudfrontを紐付けてCDN配信する準備
  • WordPressの「WP Offload Media」をインストールしてメディア配信設定

AWSのアカウント開設は、AWSのホームページにある「今すぐ無料サインアップ」から流れに沿っておこなうだけ。アカウント開設で迷うことはないので、この記事では詳細を省略します。

AWSのアカウントを無料開設する

Amazon S3のバケットを作成

S3バケットのイメージ図
S3バケットのイメージ図

Amazon S3のバケットとは、メディアファイルやPDFなど各種ファイルを格納する場所のこと。

まず、WordPressのメディアライブラリに保存する画像や動画といったメディアファイルを、S3にオフロードするためのバケットを作成します。

すでにWordPressにアップロードしている既存ファイルをS3にオフロードすることはできません。既存のファイルをS3に格納するには、FTPソフトを利用してメディアファイルをS3にアップロードする必要があります。

メディアファイルをアップロードするときには、メディアファイルのディレクトリ構造に沿ってファイルをアップロードしないと、Webサイト上でうまく表示されないので注意しましょう。

STEP

AWSのS3にアクセスする

AWSのS3の表示画面

AWSのコンソールから「サービス」を選択し、サービス内から「S3」を選択します。

※上の画像では最近アクセスしたサービスとして表示されていますが、初めてアクセスする場合はすべてのサービス内から検索してください。

STEP

バケット名を入力する

S3バケット作成の流れ①

任意のS3バケット名を入力します。バケット名はなんでも良いですが、サイト名など、どこに使用しているバケットかわかりやすいような名前にしましょう。

STEP

オブジェクトの所有者を選択する

S3バケット作成の流れ②

オブジェクトの所有者はデフォルトで「ACL無効(推奨)」となっているので、そのままでOK。

ACL(Access Control List)とは、アクセスが許可されるAWSアカウントまたはグループと、アクセスの種類を定義することができるアクセスコントロールリストのことです。

オブジェクト(メディアファイル)を個別でコントロールする必要があるような特殊ケースをのぞいて、ACLは無効にしておいて問題ありません。

STEP

パブリックアクセスの設定をする

S3バケット作成の流れ③

デフォルトで、「パブリックアクセスをすべてブロック」にチェックが入っているので、そのままの設定でOK

パブリックアクセスは、不正アクセスから保護するための設定であり、セキュリティ対策として大切です。

パブリックアクセスブロックをオフにしないと、「Cloudfront」との紐つけや「WP Offload Media」との連携がうまくいかないとする情報も散見しますが、パブリックブロックはオンで問題ありません

むしろセキュリティ面からパブリックブロックはオンにしておくべきです。

STEP

バージョニング・タグ設定をする

S3バケット作成の流れ④

バージョニングはデフォルトで「無効にする」が選択されているので、そのままでOK

タグオプションは、バケットを複数作成し、管理しやすくしたい場合にはタグを設定しておくと便利ですが追加しなくても問題ありません

バージョニングとは、バケットに保存されたすべてのオブジェクト(メディアファイル)のすべてのバージョンを、保存・取得・復元することができる手段のこと。いわゆる「バージョン」管理のことです。

STEP

暗号化の設定をする

S3バケット作成の流れ⑤

サーバー側の暗号化タイプは、デフォルトで「SSE-S3」が選択されており、特別な事情がなければそのままでOK。バケットキーについても操作する必要はなく、デフォルトのままでOKです。

設定が完了したら、「バケットを作成」をクリックしてバケットを作成します。

Amazon S3とCloudfrontの紐付け

Amazon S3のバケットを作成したら、Clodfrontと紐付ける設定をおこないます。

Cloudfrontとは、Amazonが提供しているCDN(Content delivery Network)のこと。画像・動画・アプリケーションなどを、オリジンサーバー(契約しているホスティングサーバー)を介さず負荷をかけずに配信することで、サイト表示を高速化することができます。

Cloudfrontのメカニズムのイメージ図
Cloudfrontのメカニズムのイメージ図

ここでは、S3に保存したメディアファイルを、Cloudfrontをとして配信するための紐付けをおこないます。

STEP

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

ディストリビューション一覧画面
ディストリビューション一覧画面

コンソールのサービス画面から「Cloudfront」を検索して開き、「ディストリビューションを作成」をクリックします。

ディストリビューションは、CloudfrontでメディアファイルをCDN配信するために必須の設定です。

STEP

オリジンドメインの設定をする

オリジンドメインの設定
オリジンドメインの設定

Origin domain

オリジンドメインは、Cloudfrontに参照するオリジンドメインを指定する設定です。Cloudfrontには、S3のメディアファイルを参照して出力してほしいので、先ほど作成したS3バケットを指定します。

名前は任意のものでかまいませんが、こだわりがなければデフォルトのままでOK

オリジンアクセス

オリジンドメインへのアクセス許可設定で、「Origin Access Contorol setting(recommended)」を選択してオリジンドメインを指定し、「Create new OAC」をクリックします。

その後、ダイアログにて以下の画面が表示されます。

新規OAC作成画面
新規OAC作成画面

特に細かな設定をすることなく、デフォルトのままで「Create」をクリックすればOK。

元のページに戻ると以下のような画面が表示されているので、「ポリシーをコピー」をクリックしたのち、「S3バケットアクセス許可に移動」をクリックします。

S3バケットポリシーの設定移行画面
S3バケットポリシーの設定移行画面

バケットポリシーに移動し、コピーしたポリシーをペーストすると以下のような画面になります。

バケットポリシーの設定画面
バケットポリシーの設定画面

バケットポリシーは、S3バケットへのアクセス許可設定です。

上記画像はコピペしたものではないので表示は異なりますが、コピペで問題ありません。

Enable Origin Shield

Enable Origin Shieldは、オリジンの負荷を最小限に抑える設定です。

デフォルトでは「いいえ」が選択されており、そのままでも問題ありませんが、「はい」を選択してオリジンのリージョン(場所)を指定しておくと良いです。ここでは「アジアパシフィック(東京)」を選択しています。

オリジンシールド設定画面
オリジンシールド設定画面
STEP

ビヘイビアの設定をする

ビヘイビアとは、キャッシュやセキュリティの設定です。

オリジンドメインを指定して、以下のように設定すればOK。

ビヘイビアの設定画面
ビヘイビアの設定画面

設定

  • オブジェクトを自動的に圧縮:Yes
  • ビューワープロットコルポリシー:Redirect HTTP to HTTPS
  • 許可されたHTTPメソッド:GET,HEAD
  • ビューワーのアクセスを制限する:No

キャッシュキーとオリジンリクエスト

キャッシュキーとオリジンリクエストを制限する設定です。

本来は上記画像のように「Cache policy and origin request policy(recommended)」を設定することが推奨されます。自分でカスタムのものを設定しても問題ありませんが、面倒なのでデフォルトのキャッシュポリシーを選択すれば問題ありません。

STEP

関連付けのオプション設定をする

オプション設定画面
オプション設定画面

オプションは特に設定する必要がありません。必要があれば有効にし、こだわりがなければ有効にしなくてOK

STEP

代替ドメイン名とカスタムSSL証明書の設定をする

カスタムSSL証明書の設定
カスタムSSL証明書の設定

料金クラス

料金クラスは「すべてのエッジロケーションを使用する(最高のパフォーマンス)」がデフォルトで選択されています。配信地域を限定するのであれば、メディアをCDN配信する地域を選択しますが、基本的にはそのままでOK

ジオロケーションを絞ってサイト運営しているのであれば、コスト面で地域を絞ることも有効でしょうが、それほど膨大なコストがかかるわけではありません。こだわりがなければ、デフォルト設定のままにしておきましょう。

代替ドメイン(CNAME) – オプション

代替ドメイン名は指定しなくても問題はありませんが、メディアファイルをCDN配信するときのURLのこと。例えば、当サイトのメディアファイルの代替ドメイン名(CNAME)は、「image.chiyo-blog.com」です。

CNAMEは任意のものに設定してOKですが、「storage」や「media」など、わかりやすいものを設定しておいた方がいいかもしれません。

カスタムSSL証明書 – オプション

代替ドメイン名を指定してCDN配信するためには、SSL証明書を発行する必要があります。

各種設定が完了してからSSL証明書を選択するので、「カスタム証明書-オプション」の項目にある「証明書をリクエスト」をクリックし、ひとまず先に進みます。

STEP

カスタムSSL証明書を発行する

カスタムSSL証明書の発行画面
カスタムSSL証明書の発行画面
  • ドメイン名
    SSL証明書を発行したいドメイン(任意で設定したCNAME)を指定します。当サイトでは「image,chiyo-blog.com」が完全修飾ドメイン名です。
  • 検証方法
    DNS設定を選択します。DNS設定はサーバー側で操作する必要があるので、後述します。
  • キーアルゴリズム
    デフォルトで選択されている「RSA 2048」でOKです。
  • タグ
    証明書の管理に役立つタグです。最初は設定しないでも問題ありません。

すべての項目の設定が完了したら「リクエスト」をクリックすると、証明書の一覧にドメイン名が表示されます。

以下の画像では「発行済み」となっていますが、設定前では「保留中の検証」と表示されていればOKです。

SSL証明書の一覧
SSL証明書の一覧

CNAMEをサーバーのDNSに設定する

ドメイン名の「証明書ID」をクリックすると、ドメインの項目で以下のような「CNAME」を見つけることができます。

カスタム証明書を発行するCNAME
カスタム証明書を発行するCNAME

上記のCNAMEを契約しているサーバーのDNSに設定します。

CNAME設定画面
CNAME設定画面

サーバーによって「CNAME名 = ホスト名」「CNAME値 = 内容」などと表現が違うことがあります。表現が違くても焦らずに設定しましょう。

設定を終えてしばらくすると、Cloudfront側のドメイン認証ステータスが「発行済み」と表示されます。

CloudfrontのCNAME名の最後に「. (ドット)」がついていますが、サーバーによっては認証されないので、もしエラーが出たら「. (ドット)」を削除します。

また、CNAME値の最初にある「_ (アンダーバー)」や最後のある「. (ドット)」でもエラーが出る可能性があります。エラーが出たら、必要に応じて削除するようにしてください。なお、CNAME名の最初にある「_ (アンダーバー)」は問題ありません。

STEP

ディストリビューションの作成を完了する

先に発行したSSL証明書を選択して、そのほかの項目を埋めていき、「ディストリビューションを作成」をクリックします。

ディストリビューション作成の最終項目
ディストリビューション作成の最終項目
  • セキュリティーポリシー:
    デフォルトのTLSv1.2_2021(推奨)でOK
  • サポートされているHTTPバーション:
    デフォルトではHTTP/2のみが選択されていますが、必要に応じてHTTP/3もチェックを入れましょう。
  • デフォルトルートオブジェクト:
    指定したいオブジェクト名がなければ空白のままでOK
  • 標準ログ記録:
    デフォルトのオフのままでOK。ログを取得したければオンを選択します。
  • IPv6:
    IPvの設定です。デフォルトでIPv6がオンになっているので、そのままでOK
STEP

ディストリビューションとカスタムドメインをCNAMEで紐付ける

作成したディストリビューションを確認すると、「×××××××××××.cloudfront.net」というドメイン名が確認できます。

ディストリビューションのドメイン名
ディストリビューションのドメイン名

このドメイン名をCNAMEとして、カスタムドメイン名に紐付けます。※ここでは「image.chiyo-blog.com」

カスタムドメインのDNS設定画面
カスタムドメインのDNS設定画面

以上で、Amazon S3とCloudfrontの紐付けとカスタムドメインの設定が完了しました。カスタムドメインを設定しない場合は、カスタムドメイン周りの設定を飛ばせるので、もう少し簡単におこなえます。

最後に、WordPressとAWS(Amazon S3とCloudfront)を紐つけるだけです。

WordPessとAWSの紐付け

WordPress・S3・Cloudfrontの連携イメージ図
WordPress・S3・Cloudfrontの連携イメージ図

WordPressとAWSを紐付けるためには、WordPressプラグイン「WP Offload Media Lite for Amazon S3」を利用します。

WordPressメディア内にアップロードしたメディアファイルをAmazon S3にオフロードして、Cloudfrontを通してCDN配信できるようにするために、プラグインにAWSへのアクセス権を付与する設定をします。

STEP

AWSでIAMユーザーを作成する

AWSのコンソール画面のサービスから「Identity and Access Management (IAM)」を検索して開き、ユーザー作成をクリックします。

IAMユーザー作成
IAMユーザー作成

任意のユーザー名を入力して「次へ」をクリックします。

IAMユーザー名の入力画面
IAMユーザー名の入力画面

S3のアクセス権を設定します。

WP Offload Media Lite for Amazon S3 公式サイトにあるように、AmazonS3FullAccessを選択すればOKです。

S3へのアクセス権の付与
S3へのアクセス権の付与
  • ポリシーを直接アタッチするを選択する
  • S3を検索して、「AmazonS3FullAccess」を選択する
  • 次へをクリックする

もし、フルアクセスは権限が強すぎると感じる場合は「ポリシーの作成」から、直接アクセスポリシーを作成して、アクセス権限をコントロールすることもできます。

最後に確認画面が表示されるので、問題なければ「ユーザーの作成」をクリックして、IAMユーザー作成を完了します。

IAMユーザー作成の最終確認画面
IAMユーザー作成の最終確認画面

IAMユーザー作成が完了すると、アクセスIDとシークレットアクセスキーが表示されます。後で使用するものなので、必ず控えを取っておくようにしましょう。

STEP

wp-config.phpにアクセスキーを埋め込む

サーバーのファイルマネージャーから、ドメインのルート直下にある「wp-config.php」を編集して以下のコードを埋め込みます。「<?php」から始まるので、その直下に埋め込めば問題ありません。

/** WP Offload Media Lite AWS Access Key **/
define( 'AS3CF_SETTINGS', serialize( array(
    'provider' => 'aws',
    'access-key-id' => '********************',
    'secret-access-key' => '****************************************',
) ) );

access-key-idには取得したアクセスIDを、secret-access-keyには取得したシークレットアクセスキーをそれぞれ入力してください。

以上で、WordPressとAWSの紐付け設定が完了しました。最後に、プラグインの設定をすればすべての工程が完了です。

プラグイン「WP Offload Media Lite for Amazon S3」の設定方法

WordPressプラグイン「WP Offload Media Lite for Amazon S3」をインストールして有効化してください。

WP Offload Media Lite for Amazon S3の設定や使い方はシンプルでかんたんですが、設定を失敗するとあとでかなり大変になるので、以下で説明している内容を確認しながら慎重に進めてください。

Storage Settingsの設定

WP Offload Mediaプラグインの設定画面
WP Offload Mediaプラグインの設定画面

Storage Provider(ストレージプロバイダー)

Storage Provider(ストレージプロバイダー)は、初回設定時のみに必要な項目です。

Amazon S3アクセスキーの設定場所(wp-config.php)を選択します。

Offload Media(オフロードメディア)

新規で追加したメディアファイルを、Amazon S3にオフロードするかどうかの設定です。

設定は必ずオンにしましょう。

Remove Local Media(リムーブローカルメディア)

ローカルに保存されているメディアファイルを削除するかどうかの設定です。

自分で追加するメディアだけを考えれば設定をオンにしても問題ありませんが、一部プラグインやWordPressテーマではローカルメディアを参照してる場合があります。

ローカルメディアを削除するとプラグインやWordPressテーマがうまく機能しなくなる可能性があるので、慎重に選択します。問題が起こったときに対処する自信がなければオフのままにしておきましょう。

Add Prefix to Backet Path(アッドプレフィックスバケットパス)

メディアファイルを保存するプレフィックスパスです。

サイトのディレクトリ構造にあわせたパスにしないと、メディアファイルが正しく保存されないだけでなく表示もされず、あとで修正するのもかなり大変です。必ず、サイト構造に合わせたパスを指定するようにしましょう。

Add Year & Month Backet Path(アッドイヤー&マンスバケットパス)

プレフィックスと同様にメディアファイルを保存するパスです。

サイトの設定で「年」や「月」をメディアファイルのパスに指定しているかどうか確認をして、指定しているのであればオンに、指定していないのであればオフにします。

Add Object Version Backet Path(アッドオブジェクトバージョンバケットパス)

メディアファイルを保存するパスに、オブジェクトバージョンを追加するかどうかの設定です。

プレフィックスやイヤー&マンスと同様に、サイトの設定でオブジェクトパスを指定しているかどうか確認をして、指定していればオンに、指定していないのであればオフにします。

URL Preview

パスの設定がURLプレビューに反映されます。

パスを間違えるとうまくオフロードできないだけでなく、メディアファイルが表示されないといった事態になります。サイト内に保存されているメディアファイルのURLを確認して、パスに間違いがないか必ず確認をしましょう。

Delivery Settingsの設定

WP Offload Mediaプラグインのdelivery settingの設定画面
WP Offload Mediaプラグインのdelivery settingの設定画面

Delivery Provider

Delivery Settingsのページ先頭にプロバイダー設定があるので、Amazon Cloudfrontを選択します。そうすることで、メディアファイルの配信時にCloudfrontを経由したCDN配信が可能になります。

Delivery Offloaded Media

S3にオフロードしたメディアファイルを配信するかどうかの設定です。

S3に保存したメディアファイルをCloudfrontを通じてCDN配信したいので、この項目はオンにします。

User Custom Domain Name(CNAME)

代替ドメイン名を作成してカスタムSSL証明書を発行した人は、代替ドメイン名を入力しましょう。

代替ドメインを作成していない人は、こちらの項目は空欄でOKです。

Force HTTPS

HTTPSを強制するかどうかの設定です。

オリジンドメインでHTTPからHTTPSへのリダイレクトを設定しているのであれば、オフにしても問題ありません。とはいえ、オフにしなければいけないわけではないので、オンにしておきましょう

既存のメディアファイルをCloudfrontで配信するには

WP Offload Media Lite for Amazon S3を設定すると、WordPressサイトにアップロードしたメディアファイルがS3にオフロードされますが、プラグインの設定前にWordPressサイトへ追加したメディアファイルはS3に保存されません

既存のメディアファイルをCloudfrontで配信するには、FTPソフトを用いてメディアファイルをS3バケットにアップロードしましょう。URLパスをあわせてS3にアップロードすることで、Cloudfrontで既存のメディアファイルを配信できるようになります。

FTPソフトは、FilezillaWinSCPなどのソフトを利用しましょう。

サーバーのファイルマネージャーでもメディアファイルをダウンロードできますが、メディアファイルのような大きなサイズのファイルをサーバーのファイルマネージャーで処理しようとするとエラーを起こす可能性が高いです。

メディアファイルのダウンロードは、必ずFTPソフトを使用しましょう。

WordPressとAWSを連携してサイトを高速化

WordPressサイトにおけるメディアファイルのサイズ問題は、永久の課題ではないでしょうか。

LCP(Large Contentful Paint )やFID(First Input Delay)といったコアウェブバイタルやTTFBといった反応速度を改善し、サイト表示速度を高速化するために、さまざまなメディア最適化プラグインや画像圧縮ソフトがリリースされています。

プラグインはお手軽にメディアを最適化できる一方で、ほかのプラグインとの互換性の問題からエラーが発生してしまうことがあります。また、画像圧縮ソフトは、ソフトによって圧縮率や圧縮後の画素が大きく違ってきます。

AWSのS3とCloudfrontは、少し設定が複雑なので慣れていないとハードルが高いかもしれませんが、一度設定をしてしまえばWP Offload Media Lite for Amazon S3プラグインで自動でサイト外にメディアを保存して、CDN配信できます。

メディアファイルを直接いじるわけではなく、プラグインも軽量化されているので、エラーを起こす心配やプラグインそのもので動作が重くなる心配もありません

メディアファイル問題で頭を抱えているサイト運営者は、WordPressとS3、Cloudfrontを連携してメディアファイルをオフロード配信することを検討してみてはいかがでしょうか。

役に立った!と思ったら他の人にシェアしよう
  • URLをコピーしました!

記事の内容についてご意見をお聞かせください

コメントする

このコメントを送信することにより、当サイトの個人情報保護方針に同意したことになります。

タップできる目次