Cloud Connector+Amazon S3で独自ドメインサイトを公開してみた

2025年9月10日

CloudflareのCloud Connectorと、Amazon S3の静的ウェブサイトホスティングを組み合わせてみる記事です。

数年前に制作させていただいたサイトさんを別環境に移行することになりました。
元々レンタルサーバー（ロリポップ）にファイルを置いて公開していましたが、これをAmazon S3に移行してバケット内にファイルを置き、静的ウェブサイトホスティングで公開するようにしました。

S3の静的ウェブサイトホスティングを使う場合、一般的にはAmazon CloudFrontを組み合わせて公開します。
しかし今回は他の手段で実現しました。

Cloud Connectorは2024年8月にリリースされました。
2025年9月現在、まだCloud Connectorはベータ版という位置づけです。
正式にリリースされる頃には記事の内容と変わっているかもしれませんので、留意ください。

前提

AWSアカウントが登録済み
Cloudflareアカウントが登録済み
独自ドメインを取得している
ドメインのDNSレコードを操作できる

それでは実際に操作していきます。

もし独自ドメインを持っていなければ、この際Cloudflare Registrarで取得してしまいましょう

S3バケットを作成してWebサイトとして公開

AWS側の操作です。
まずはS3バケットを作成し、index.htmlなどのファイルをアップロードしてください。

アップロード後、「静的ウェブサイトホスティング」を有効化します。

Amazon S3の静的ウェブサイトホスティング（有効後） — この「バケットウェブサイトエンドポイント」で接続できる状態にする

有効後に表示される「バケットウェブサイトエンドポイント」は下記のどちらかのドメインです。
※どちらになるかはリージョンによる模様。東京リージョン（ap-northeast-1）は①、大阪リージョン（ap-northeast-3）は②になります

http://【S3のバケット名】.s3-website-【リージョン名】.amazonaws.com
http://【S3のバケット名】.s3-website.【リージョン名】.amazonaws.com

この時点ではまだアクセスできません。
アクセスすると403 Forbiddenになってしまうので、アクセス許可設定も併せて行いましょう。

S3バケットのブロックパブリックアクセスをオフにします。

ブロックパブリックアクセスはオフ — 「パブリックアクセスをすべてブロック」のチェックを外す

さらにバケットポリシーに下記を設定します。
【S3のバケット名】の箇所だけ置換してください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::【S3のバケット名】/*"
        }
    ]
}

設定後、「静的ウェブサイトホスティング」の「バケットウェブサイトエンドポイント」にアクセスしてWebページを閲覧できることを確認してください。
閲覧できればS3側の準備は完了です。

参考ドキュメント：ウェブサイトアクセスのアクセス許可の設定 - Amazon Simple Storage Service

Cloud ConnectorはS3の静的ウェブサイトホスティングが無効でも使える？

Cloud ConnectorでS3を使うとき、4つのドメインを指定できます。

The hostname of your S3 bucket URL must have one of the following formats (where * is a wildcard character):

*s3.amazonaws.com
*s3.<REGION>.amazonaws.com
*s3-website.<REGION>.amazonaws.com
*s3-website-<REGION>.amazonaws.com
Supported cloud providers · Cloudflare Rules docs

3つ目と4つ目が静的ウェブサイトホスティングのドメイン（バケットウェブサイトエンドポイント）です。
静的ウェブサイトホスティングを有効にするとアクセスできるようになるドメインです。

対して、1つ目と2つ目はバケットエンドポイントです。
バケットエンドポイントは静的ウェブサイトホスティングが無効でもアクセスできます。
※もちろんブロックパブリックアクセスをオフ、かつ、バケットポリシーを設定する必要があります

「バケットエンドポイント」と「バケットウェブサイトエンドポイント」は違うので注意です。
ちょっと紛らわしいですね。

つまり、Cloud Connectorは静的ウェブサイトホスティングを無効にしていても使用可能です。

ただし注意点がいくつかあります。
試しにS3のバケットにindex.htmlをアップロードしてバケットエンドポイントにアクセスしてみましょう。

「http://【S3のバケット名】.s3-website.【リージョン名】.amazonaws.com」でアクセス

Access Deniedになってしまいました。
ブロックパブリックアクセスはオフですし、バケットポリシーも設定しています。
なぜでしょうか？

実は「http://【S3のバケット名】.s3.【リージョン名】.amazonaws.com」ではアクセスできません。
S3バケット内のオブジェクト名を指定してアクセスする必要があるので、「http://【S3のバケット名】.s3.【リージョン名】.amazonaws.com/index.html」ならアクセスできます。

これはCloud Connector経由で独自ドメインとしてアクセスした場合も同じです。

バケットエンドポイントにはブラウザでアクセスした際のデフォルトページを指定できないということです。
404などになった場合のエラーページも指定できません。
バケットウェブサイトエンドポイントと違ってhttpとhttpsの両方でアクセスできますが、Webサイトとしての公開は想定されていません。

静的ウェブサイトホスティングを有効にすればデフォルトページもエラーページも指定できます。
それが一番簡単な解決方法です。

それでも静的ウェブサイトホスティングを使いたくない、ということであれば対応は可能です。
Cloud Connectorに通常のバケットエンドポイント「【S3のバケット名】.s3.【リージョン名】.amazonaws.com」を指定してください。
Cloudflare側でURL Rewrite Ruleを使えばデフォルトページやエラーページを指定できます。

Cloudflareと独自ドメインを接続

Cloudflare側の操作です。
※Cloudflare Registrarで独自ドメインを登録した場合はスキップしてください（すでに接続済みなので）

まずはCloudflareと独自ドメインを接続します。
接続する時、特に理由がなければ「DNSレコードを手動で入力する」にしましょう。

Cloudflareにドメインを接続 — 独自ドメインを入力して「DNSレコードを手動で入力する」を選んで続行

プランを選択する画面が現れるので、Freeプランを選択します。
※今回やりたいことはFreeプランで十分です

DNSレコードを登録する画面が現れるので、下記のDNSレコードを保存してください。

タイプ＝CNAME
名前＝ルートドメインでサイトを公開する場合は「@」、サブドメインの場合はホスト名にあたる部分
※分かりやすく例えると「example.com」なら「@」、「sub.example.com」なら「sub」を入力します
ターゲット＝S3のバケットウェブサイトエンドポイント
プロキシステータス＝オン（デフォルトの状態）

入力し終えたら「保存」ボタンを押して、「アクティベーションに進む」を選択してください。

独自ドメインのネームサーバーにCloudflare以外のDNSサーバーを指定していた場合

この場合はアクティベーション時に下記の画面になります。

上記で黒塗りにしている項目は、独自ドメインに現在指定しているネームサーバーです。
今回のケースではお名前.comにロリポップのネームサーバーを指定していたため、それが表示されました。

ですので、お名前.comに指定していたネームサーバーをロリポップからCloudflareに変更しました。
上記画面に表示されている通り2つのネームサーバーを指定します。

elmo.ns.cloudflare.com
zoe.ns.cloudflare.com

お名前.com側でDNSサーバーを指定 — お名前.comのネームサーバー設定画面

上記のように入力して変更したことを確認したら、Cloudflareの画面に戻ります。
下記画面のように反映には時間がかかるのでしばらく待ちましょう。（最大24時間）

しばらく待ってCloudflareの画面に戻ったとき、この表記が表示されなければ反映完了です。

これでCloud Connectorが利用可能な状態になります。

S3とCloud Connectorを接続

Cloudflare側の操作です。
左サイドバーの「ルール」から「Cloud Connector」を選んでください。

クラウドストレージの選択画面になるので、「Amazon S3」を選択します。

S3のバケットウェブサイトエンドポイントを入力して、右下の「次へ」を選びます。
ここで入力するバケットウェブサイトエンドポイントは、DNSレコード作成時に指定したものと同じです。

「Cloud Connector 名」に自身が後で分かるような名前を入力します。
「受信リクエストが一致する場合…」は「すべての受信リクエスト」に変更し、デプロイします。

デプロイ後は下記のページになります。

これで設定は完了です。
独自ドメインでサイトにアクセスできることを確認してください。

アクセスできればまずは安心ですが、一つ注意点があります。
それはバケットウェブサイトエンドポイントと独自ドメインの両方でアクセスできてしまうことです。

canonicalタグを忘れずに

Amazon CloudFrontを使わない場合はAmazon S3のパブリックアクセスブロックを無効にする必要があります。
S3側のエンドポイントでバケット内のリソースに直接アクセスできてしまうことを忘れてはいけません。

アクセス方法その1 （独自ドメインでアクセスしたとき）
[クライアント] <-https-> [Cloud Connector] <-http-> [Amazon S3]
アクセス方法その2（バケットウェブサイトエンドポイントでS3バケットに直接アクセスしたとき）
[クライアント] <-http-> [Amazon S3]
アクセス方法その3（バケットエンドポイントでS3バケットに直接アクセスしたとき）
[クライアント] <-https-> [Amazon S3]
または
[クライアント] <-http-> [Amazon S3]

こうなると意外と盲点になりがちな問題が浮上します。
検索エンジンで検索したときに独自ドメインだけではなくS3バケットの方も出てきてしまう、ということです。

S3のエンドポイントのURLをWeb上に周知しなければOKかというと、そうとも限りません。
検索エンジンは勝手に探してきて掲載してしまいます。

ユーザー目線では検索すると同じページが複数出てきて混乱の元になります。
検索エンジン目線だと別ドメインなのに全く同じページが複数あるので最悪の場合はすべてスパムサイト扱いになり、検索エンジンのページランクが落ちる、ということも起こりえます。

そうなることを防ぐために、HTML内にcanonicalタグを指定しておきましょう。
検索エンジンはcanonicalタグで指定したURLが正規のURLであると認識します。

リダイレクト: リダイレクト先が正規ページになるべきことを強く示すシグナルです。
rel="canonical" link アノテーション: 指定された URL が正規ページになるべきことを強く示すシグナルです。
rel="canonical" などを利用して正規ページを指定する方法 | Google 検索セントラル | Documentation | Google for Developers

※厳密には検索結果が変わることが保証されているわけではありませんが、リダイレクトと同等の効果を持つとても強力なタグです

タグの記述方法について

まずはS3のバケット内にあるindex.htmlのheadタグの中に下記の1行を追記してください。
<link rel="canonical" href="【独自ドメインのトップページのURL】"/>

index.htmlは上記でOKです。
他のHTMLファイルにも同様に追記しますが、index.htmlと同じURLではなく、必ず独自ドメインのそのファイルにアクセスするためのURLを指定するようにしてください。
サイトごとではなくページごとに個別に記述する必要があります。

ここで設定ミスをするとSEO的に非常にもったいないことになります。要注意。

S3バケット側でIPアドレスを制限する方法もある

Cloudflareのサービス側が使うIPアドレス範囲は公開されています。

これを使えば、S3のバケットにアクセスできるIPアドレスをCloudflareのサービスだけに制限できます。
ちなみにここで制限をかける経路は下記の下線の箇所です。

アクセス方法その1 （独自ドメインでアクセスしたとき）
[クライアント] <-https-> [Cloud Connector] <-http-> [Amazon S3]
アクセス方法その2（バケットウェブサイトエンドポイントでS3バケットに直接アクセスしたとき）
[クライアント] <-http-> [Amazon S3]
アクセス方法その3（バケットエンドポイントでS3バケットに直接アクセスしたとき）
[クライアント] <-https-> [Amazon S3]
または
[クライアント] <-http-> [Amazon S3]

制限後はアクセス方法その2とその3が使えなくなり、その1だけに限定できます。
独自ドメイン以外では接続できなくなるので、検索すると同じページが出てくるようなこともありません。

制限する際はバケットポリシーに下記を設定しましょう。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::【S3のバケット名】/*"
        }
        "Condition": {
            "IpAddress": {
                "aws:SourceIp": [
                    "173.245.48.0/20",
                    "103.21.244.0/22",
                    "103.22.200.0/22",
                    "103.31.4.0/22",
                    "141.101.64.0/18",
                    "108.162.192.0/18",
                    "190.93.240.0/20",
                    "188.114.96.0/20",
                    "197.234.240.0/22",
                    "198.41.128.0/17",
                    "162.158.0.0/15",
                    "104.16.0.0/13",
                    "104.24.0.0/14",
                    "172.64.0.0/13",
                    "131.0.72.0/22",
                    "2400:cb00::/32",
                    "2606:4700::/32",
                    "2803:f800::/32",
                    "2405:b500::/32",
                    "2405:8100::/32",
                    "2a06:98c0::/29",
                    "2c0f:f248::/32"
                ]
            }
        }
    ]
}

※2025年9月時点のIPアドレス範囲

設定後はS3バケットに直接アクセスできないことと、独自ドメインではアクセスできることを確認しましょう。

お察しの方もいらっしゃると思いますが、canonicalタグよりもこちらの方が正攻法です。
CloudflareとしてもIPアドレスで制限する方法を推奨しています。

Once you configure Cloud Connector with your storage provider's public bucket, you may wish that only Cloudflare can access the objects in that bucket. To achieve this, check your provider's documentation on how to create a policy that only allows incoming requests from Cloudflare IP addresses ↗.
Supported cloud providers · Cloudflare Rules docs

しかしながら、私はcanonicalタグ派です。
なぜならCloudflareのIPアドレス範囲は変わることがあるからです。
「IP Ranges | Cloudflare」のUpdate Historyを見ると時々更新が入っていることが分かります。

IPアドレスが追加されると、本来許可すべきアクセスを拒否してしまう
IPアドレスが削除されると、本来拒否すべきアクセスを許可してしまう

つまり上記のIPアドレスに変更が入っていないか、監視する必要があります。
手動で監視するなりLambdaなどでスクリプトを組んでバケットポリシーを自動更新するなり、手段はなんでもよいと思いますが、何かしらの策は用意しておく必要があるでしょう。

ちなみにCloudflareではS3へのリクエストヘッダーを改変することも可能です。
Cloudflare側で任意の文字列を入れたrefererをリクエストヘッダーに追加し、S3側のバケットポリシーにaws:Refererを指定してリファラで制限した方が運用上よいかもしれません。

Cloud Connectorって何してるの？

この記事内で何度か登場した下記の図、Cloud Connectorが間に挟まっていますね。
[クライアント] <-https-> [Cloud Connector] <-http-> [Amazon S3]

分かりやすくするためにこういう図にしましたが、実際には少し違います。
最初にDNSレコードを定義するとき、プロキシをオンにして定義したことを思い出してください。

上記画像の「プロキシステータス」に注目です。
オンになっている場合はCloudflareのプロキシが有効になります。
これが有効になっていることがCloud Connectorの動作要件です。

Cloud Connector requires that you proxy the DNS records of your domain (or subdomain) through Cloudflare.
Cloud Connector (beta) · Cloudflare Rules docs

ですので、実際に通信する際にはCloudflareのプロキシが間に入って通信しています。
[クライアント] <-https-> [Cloudflareのプロキシ] <-http-> [Amazon S3]

プロキシの役割はいくつかあります。

Cloud Connector will perform the following configurations automatically, depending on the cloud provider:

Modify the header.Host
Adjust SSL/TLS for bucket-related traffic (AWS S3 website endpoints only).
Cloud Connector (beta) · Cloudflare Rules docs

Hostヘッダーの変更とS3バケット関連のSSL/TLS設定を行っているようですね。
それぞれ見ていきましょう。

Hostヘッダーを変更する意味

CNAMEレコードで独自ドメインとS3のエンドポイントを紐づけただけでは、実はアクセスできません。
独自ドメインでアクセスするとエラー（SignatureDoesNotMatch）になってしまいます。

バケットは、ドメインまたはサブドメインと同じ名前にする必要があります。例えば、サブドメイン acme.example.com を使用している場合、バケットの名前は acme.example.com にする必要があります。
Amazon S3 バケットでホストされているウェブサイトへのトラフィックのルーティング - Amazon Route 53

S3バケットを独自ドメインとして公開する場合、バケット名とドメイン名を同じ名前にする必要があります。

ですので、もしかすると「SignatureDoesNotMatchにならなかった方」もいるかもしれません。
悪魔のような仕様ですがマジです。
S3のバケットを作成するときに独自ドメインと同じ名前で作成しないとエラーになります。

なぜそうなってしまうか、理由を説明します。
ここではCloudflareのプロキシが無いものとします。

まずはバケットウェブサイトエンドポイントにアクセスした場合の話をします。
下記は、S3にアクセスしたときにブラウザから送るリクエストヘッダーの例です。

GET / HTTP/1.1
Host: 【S3のバケット名】.s3-website.【リージョン名】.amazonaws.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: ja,en;q=0.9,en-GB;q=0.8,en-US;q=0.7
Cache-Control: no-cache
Pragma: no-cache
Priority: u=0, i
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36 Edg/140.0.0.0

Amazon S3は2行目のHostヘッダーを参照しており、S3バケットへ内部的にリダイレクトしています。
具体的には、Hostヘッダーの「【S3のバケット名】.s3-website.【リージョン名】.amazonaws.com」の【S3のバケット名】を使ってバケット名にリダイレクトしているのです。

それでは独自ドメインの場合の話をします。
独自ドメインでアクセスしたときのリクエストヘッダーです。

GET / HTTP/1.1
Host: xxxxxxxx.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: ja,en;q=0.9,en-GB;q=0.8,en-US;q=0.7
Cache-Control: no-cache
Pragma: no-cache
Priority: u=0, i
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36 Edg/140.0.0.0

通信経路の間に何もなければ、これがそのままS3側に届きます。
Amazon S3側はバケット名を取得できずにリダイレクトに失敗してしまうので、エラーになってしまいます。

CNAMEレコードだけではエラーになるので、間に何かを挟んでHostヘッダーを書き換える必要があります。
そして今回、間に挟まるのがCloudflareのプロキシです。
そしてCloud Connectorを作成するとHostヘッダーの書き換えを行ってくれるようになるというわけです。

Amazon CloudFrontを使った場合もCloudFrontが同じことを行っています。
※余談ですが、CloudFrontでも無理やりHostヘッダーを書き換えるとSignatureDoesNotMatchが発生します

まずはCloud Connectorに設定できるドメインの再確認です。

*s3.amazonaws.com
*s3.<REGION>.amazonaws.com
*s3-website.<REGION>.amazonaws.com
*s3-website-<REGION>.amazonaws.com

1と2がバケットエンドポイント、3と4がバケットウェブサイトエンドポイントですね。
どちらを設定するかによって選ぶべきCloudflareの暗号化モードが変わります。

暗号化モードとは何か？
Cloudflare管理画面のサイドバー「SSL/TLS」の項目から確認することができます。

暗号化モード＝フレキシブル — バケットウェブサイトエンドポイントなら「フレキシブル」になる

Cloudflareの暗号化モードは5つあります。
それぞれSSL/TLS通信が下記の経路になります。

厳密 (SSL のみの Origin Pull)
[ブラウザ] <-https or http-> [Cloudflare] <-https(検証あり)-> [オリジンサーバー]
フル
[ブラウザ] <-https or http-> [Cloudflare] <-https or http-> [オリジンサーバー]
フル (厳密)
[ブラウザ] <-https or http-> [Cloudflare] <-https(検証あり) or http-> [オリジンサーバー]
フレキシブル
[ブラウザ] <-https or http-> [Cloudflare] <-http-> [オリジンサーバー]
オフ (保護なし)
[ブラウザ] <-http-> [Cloudflare] <-http-> [オリジンサーバー]

※詳細は「暗号化モード ·Cloudflare SSL/TLSドキュメント」参照。1と3の違いがよく分かりませんでしたが、どちらもオリジンサーバー側で自己署名証明書が使えなくなるようです

オリジンサーバーは今回ならAmazon S3のサーバーのことです。
バケットエンドポイントの場合はhttps/httpのどちらでも接続できるので「厳密 (SSL のみの Origin Pull)」「フル」「フル (厳密)」のいずれかになりますが、バケットウェブサイトエンドポイントはhttpのみで接続可能なので「フレキシブル」にする必要があります。

本来であれば、オリジンサーバーのSSL/TLS対応状況を確認して設定を変更する必要があります。

Cloud Connectorを設定すると暗号化モードの選択・設定を自動で行ってくれます。
お話はしましたが、今回は特に意識する必要がないので覚えなくてOKです。

ちなみにこの辺りに関係する設定もあります。
同じくサイドバー「SSL/TLS」の項目にある「エッジ証明書」を確認してください。
「常に HTTPS を使用」をオンにすると上記の通信経路をhttpsオンリーにできます。

「常に HTTPS を使用」設定 — 「フレキシブル」の場合は[ブラウザ]と[Cloudflare]の間だけがhttpsになります

高速化とコストカット

Cloudflareのプロキシというのは、実はキャッシュ機能付きのリバースプロキシです。
アクセス順をおさらいしましょう。

[①クライアント] <-https-> [②Cloudflareのプロキシ] <-http-> [③Amazon S3]

通常は1 > 2 > 3の順番でアクセスされます。
しかしプロキシにS3のコンテンツをキャッシュさせておけば1 > 2だけで済み、3の[Amazon S3]にアクセスすることなくクライアントにコンテンツを配信できます。

サイトの表示速度が上がりますし、S3に対する課金も減らせるので一石二鳥です。
※もちろんCloudFrontでもコンテンツをキャッシュさせることが可能です。同じメリットを享受できます

何もしなくともある程度プロキシにキャッシュされる仕様にはなっています。
ただし、デフォルトでは.htmlがキャッシュ対象外であることに注意です。

Default cached file extensions

Cloudflare only caches based on file extension and not by MIME type. The Cloudflare CDN does not cache HTML or JSON by default. Additionally, by default Cloudflare caches a website's robots.txt.

7Z CSV GIF MIDI PNG TIF ZIP
AVI DOC GZ MKV PPT TIFF ZST
AVIF DOCX ICO MP3 PPTX TTF
APK DMG ISO MP4 PS WEBM
BIN EJS JAR OGG RAR WEBP
BMP EOT JPG OTF SVG WOFF
BZ2 EPS JPEG PDF SVGZ WOFF2
CLASS EXE JS PICT SWF XLS
CSS FLAC MID PLS TAR XLSX

To cache additional content, refer to Cache Rules to create a rule to cache everything.
Default Cache Behavior · Cloudflare Cache (CDN) docs

HTMLが動的に生成されるケースを想定してこのような仕様になっていると思われます。
今回は静的なファイルを配信するだけなので、問答無用でキャッシュさせてしまってOKです。

ということで全ファイルをキャッシュさせるように設定します。

Cache Everythingなキャッシュルールを作成

サイドバーの「Caching」から「Cache Rules」を選択します。

Cache Rulesの画面になるので、画面右の「テンプレート」ボタンを選択してください。

テンプレートがたくさん出てくるので、その中から「Cache Everything」のテンプレートを探してください。
見つけたら「テンプレートのプレビュー」を選択します。

設定項目がたくさん現れますが、変更せずに下までスクロールしてください。
そのまま「デプロイ」します。

これで設定完了です。

本当にキャッシュされているかどうかを検証したい場合はレスポンスヘッダーから確認できます。
開発者ツールを起動したままページを開き、Networkタブの各リソースを確認してください。
「CF-Cache-Status」のステータスがHITになっていればOKです。
※詳細は「Cloudflare cache responses · Cloudflare Cache (CDN) docs」を参照。ちなみに初回アクセス時はCloudflare側にキャッシュがないので必ずMISSになります。クライアント側のブラウザのキャッシュも絡むと検証が面倒なのでCtrl+F5などでスーパーリロードしながら確認しましょう

サイトの軽量化

こちらは余談です。
月額制のレンタルサーバーから従量課金制の静的サイトホスティング（オブジェクトストレージ）に移行するにあたり、サイトを軽量化しました。

転送量削減策
AVIF対応環境の場合は.jpgではなく.avifで配信するように変更
※サイズの削減だけでなく画質も若干良くなりました
リクエスト数削減策
ファビコンをbase64化、外部CSSをインライン化

S3のようなオブジェクトストレージは容量以外にも課金対象があります。
転送量とリクエスト数も対象なので、運営側としてはコストカットに繋がります。

これらの対応によって、トップページの転送量を5分の1以下にできました。
ユーザー側からもメリットがあります。
PC/スマホ両対応のサイトですが、大半のお客様はスマホでアクセスされます。
特に通信制限中はサイト表示が目に見えて速くなります。

AVIFは優秀なのですが、当時は登場したばかりで対応環境が少なく、採用しませんでした。
現在は多くのプラットフォームやブラウザで利用可能です。

このサイトさんはごく小規模なのですが、規模の大きなサイトならその分効果も大きいでしょう。

他の実現方法のおさらいとCloudflare R2について

Amazon S3じゃなくてCloudflare R2が良さそうだよ、という話です。

まずはS3のおさらいから始めましょう。
前述のとおり、S3の静的ウェブサイトホスティングを使ってサイトを公開する場合、index.htmlファイルを置いたS3バケットの「静的ウェブサイトホスティング」を有効にすると公開できます。
※S3バケットの「ブロックパブリックアクセス設定」はオフ、かつ、バケットポリシーの設定を行うこと

Amazon S3の静的ウェブサイトホスティング — S3バケットのプロパティに「静的ウェブサイトホスティング」があり、「編集」を選ぶと次の画像の画面になる

Amazon S3の静的ウェブサイトホスティングを有効化 — 上記のように設定するとhttpでバケットにアクセスできる

調べると真っ先に出てくる方法ですが、実はhttpsとしてサイトを公開することができません。
最も手軽ですが、本番運用には使いがたい方法です。

またS3自体には独自ドメインで公開する機能がありません。
どうにかしてS3バケットと独自ドメインを紐づける必要があります。

そのため、独自ドメインを使いたい場合は下記のいずれかでサイトを公開します。

①CNAMEレコード + Amazon S3で公開する

まずはS3バケットの「静的ウェブサイトホスティング」を有効にします。

有効にするとウェブサイトエンドポイント（ドメイン）がもらえます。
このドメインをDNSサーバー（ネームサーバー）側でCNAMEレコードの値として定義します。

【独自ドメイン名】.	1	IN	CNAME	【バケットウェブサイトエンドポイントのドメイン名】.

DNSサーバーはどれを使っても実現可能です。

同じAWSサービスであるAmazon Route 53を使う必要があるように感じるかもしれませんが、別にRoute 53を使う必要はありません。

ただしルートドメインにCNAMEレコードを定義できないサービス（お名前.comなど）があるので、ルートドメインとしてサイトを公開したい場合はサービス側が対応していることを確認してください。（CloudflareやAmazon Route53は対応しています）

お名前.comではルートドメインを使えない？

下記に当てはまる場合、S3の静的ウェブサイトホスティングは使えません

DNSサーバー（別名ネームサーバー）としてお名前.comを使っている
ルートドメインでサイトを公開したい
※独自ドメインのうち、頭にサブドメインがない独自ドメインそのもの。ネイキッドドメインやAPEXドメインとも呼ばれます

お名前.comの場合、ルートドメインでS3の静的ウェブサイトホスティングを使うことはできません。
CloudFrontを使ってもCloud Connectorを使っても同じです。

理由はCNAMEレコードの制約上、不可能だからです。

ルートドメインにCNAMEレコードを定義することはできません。
これはRFC（インターネットの技術仕様）で決められていることです。
独自ドメインとCloudFrontのドメインをどうにかして紐づける必要がありますが、CNAMEレコードでは仕様上の制約があるため実現不可です。

いやいや、ルートドメインにCNAMEレコードを定義できるサービスあるじゃん……？

ルートドメインに定義できるCNAMEレコードは、厳密にはCNAMEレコードではありません。
ALIASレコードと呼ばれることが多く、これに対応したDNSサーバーなら可能です。
呼び名や扱いは各社微妙に異なっていて、ANAMEレコードやCNAME flatteningとも呼ばれます。

CloudflareでもルートドメインにCNAMEレコードを定義できます。
内部的にはCNAME flatteningという技術で通常のCNAMEとは異なる処理をするようになっており、ALIASレコードと同様の動作をさせることができます。

2025年時点で、お名前.comにはALIASレコードに相当する機能がありません。
ルートドメインにCNAMEを定義できないため、お名前.comを使う場合は要注意です。

今回のサイトさんもお名前.comを使用されています。
ALIASレコードは非標準かつ各社の独自実装なので仕方ないのですが、正直対応していてほしい。
日本最大手なのに……。

ということで、お名前.comを使っている場合はネームサーバーを変更する必要があります。
Amazon Route 53やCloudflare辺りにしましょう。

ただし独自ドメインでアクセスできるようになっただけで、httpsとしてサイトを公開することはできません。
S3のバケット名に制約があり、独自ドメインとして公開する場合はバケット名とドメイン名を同じ名前にする必要があります。

通常はそういった制約のない下記②を使って公開します。
※繰り返しになりますが、お名前.comのネームサーバーを使っている場合は②ももちろん不可能なので注意

②CNAMEレコード + Amazon CloudFront + Amazon S3で公開する

S3バケットの「静的ウェブサイトホスティング」は無効にします。

CloudFrontでディストリビューションを作成します。

CloudFrontのディストリビューション作成 — ディストリビューション作成時にはS3のバケットを指定する

作成後にはドメイン名として「【ランダムな英数字の文字列】.cloudfront.net」がもらえます。
「https://【ランダムな英数字の文字列】.cloudfront.net/」でS3バケットにアクセスできるようになります。

CloudFrontのディストリビューションドメイン名 — 「ディストリビューションドメイン名」から確認可能

DNSサーバー側では上記ドメインをCNAMEレコードの値として定義します。
CloudFrontがhttpsに対応しているのでhttpsとしてサイトを公開できる、というわけです。

【独自ドメイン名】.	1	IN	CNAME	【ディストリビューションドメイン名】.

一般的にはこの方法でサイトを公開することになるでしょう。

さらにCloudFrontはプロキシとしても機能します。
プロキシのキャッシュを使うことでサイトの表示速度が上がり、S3へのアクセスを減らすことでS3に対する従量課金も減らせます。
※CloudFront自体にも従量課金がありますが、こちらは無料利用枠があります。ライトな使い方なら無料枠内で使用できます

③Cloudflare Cloud Connector + Amazon S3で公開する

今回使用した方法です。
CloudflareをDNSサーバー（ネームサーバー）にすることが前提となります。
※パーシャルセットアップを使う場合、かつ、サブドメインの場合は他社のDNSサーバーを使ってもOKらしい

S3バケットの「静的ウェブサイトホスティング」は有効にします。
その後にCloudflareにCNAMEレコードを作成し、S3のウェブサイトエンドポイント（ドメイン）を入力します。
Cloud Connectorの作成時にも同じドメインを入力します。

これだけでhttpsとしてサイトを公開できます。

やっていることは①と同じでCNAMEレコードを使っているのですが、②と同じくプロキシとしても機能するので、CloudFront同様にキャッシュが使うことが可能です。
S3に対する課金を減らせる上、Cloud Connectorは無料で使用できます。

③のデメリット

できることは②③で同じです。
ただし③の注意点が1つ。
②はS3のバケットをインターネットから秘匿できますが、③は公開しなければなりません。

静的ウェブサイトホスティングを有効にする場合はS3のブロックパブリックアクセスを無効にしなければならないので、独自ドメインとS3バケットのエンドポイントの両方でアクセスできてしまいます。

まったく同じコンテンツを2つのドメインでインターネット上に公開しなければならないので、前述の通りcanonicalタグを付けて正しい方のドメインを示すか、IPアドレスを制限する必要があります。

ですので基本的には特別な設定が必要のない②をおすすめします。
③を使うケースは下記でしょう。

元々Cloudflareを使っている
Amazon S3ではなく他のオブジェクトストレージサービスを使用する予定がある
※Cloud ConnectorはAmazon S3だけでなく、Cloudflare R2やGoogle Cloud StorageやAzure Blob Storageにも対応しています
ACMの証明書やCloudFront等、AWS側リソースの利用を避けたい事情がある

私の場合も当初は②のAmazon CloudFront + Amazon S3で実現予定でした。
③のCloud Connector + S3の組み合わせはニッチなケースになると思います。

Cloud Connectorが思いのほか簡単にできたので備忘録として残しましたが、ここで朗報が1つ。
Amazon S3ではなくCloudflare R2を使うと③のデメリットを打ち消すことができます。