example.com (Zone Apex、ネイキッドドメイン）で運用しているサービスにwww.example.comのようなサブドメイン宛てのアクセスがあった場合にも応答するには、どのような方法が考えられるでしょうか。1つの方法はDNSで以下のようなCNAMEを作成することで、これでwww.example.comでもexample.comでもアクセス可能になりますが、同じエントリを指すURLが(www有りと無しで）2種類できてしまいます。

www CNAME example.com.

example.comの方に集約したい場合は、HTTPでリダイレクトする必要があります。リダイレクトはHTTPレスポンスコード(301, 302等)をブラウザに返すことで実現できるので、設定はWebサーバで行うのが一般的ですが（例えばApache HTTP Serverならvirtual hostで実現できます）、Webサーバ側での設定をしたくない場合はAmazon S3＋Amazon Route 53の組み合わせでHTTPのリダイレクトを実現するのが簡単です。HTTPSでのアクセスに対応したい場合であってもAmazon CloudFrontで簡単に設定できます。

このブログも以前サブドメイン(www.)で（リダイレクトせず）アクセスできていたのですが、今回サイトをHTTPS化するのと合わせてサブドメインをZone Apexにリダイレクトする設定にしたので、そのメモを残します。

ところでWebサーバ側でリダイレクト設定を行うのは比較的簡単なので、あえてWebサーバの外で設定したい理由をあげるとすると、以下のような感じでしょうか。

• 自由にWebサーバの設定が替えられない環境（レンタルサーバ等）である
• できるだけ与えられた環境をカスタマイズせず使うことで、運用管理を楽にしたい

私の場合は後者で、今使っているAmazon Lightsailのデフォルト環境をできるだけそのまま使うことで、環境を更新・移行にかかる負担を増やさないようにしたいというのが理由です。今回利用するS3、Route 53やHTTPS対応のために必要となるCloudFront等も、一度設定すればメンテナンスの必要がほとんどありません。

Amazon S3静的ウェブサイトホスティングのリダイレクト機能

Amazon S3には静的(Static)ウェブサイトホスティング機能があり、メンテナンス不要で静的ウェブサイトを公開することができます。色々な機能があるのですが、ホスティングタイプとして「ウェブサイトエンドポイントに対するリクエストをリダイレクトする」という機能があり、今回はそれを利用しました。

S3でのリダイレクト機能としては、リダイレクトのルールを設定する事も可能です。詳細はドキュメントに譲るとして、簡単に違いをまとめると以下のような感じです。

1)を使うかどうかの確認ポイントはリダイレクトコードとして301 Moved Permanentlyが適切かという点です。名前のとおり永続的に移動したという意味で、これによりリダイレクトの情報がWebブラウザ側でもキャッシュされる、点には注意が必要です。再度サブドメインで別コンテンツをホストしようとしてもブラウザ側にキャッシュが残っている間はリダイレクトが続くことになります。一方で、私のように今後はwww側でアクセスされる必要が無い場合は、アクセス速度アップにもつながりますしSEO的なメリットもあります（リダイレクト前の情報がそのまま引き継がれるため）。

また、1)はS3バケットがブロックパブリックアクセス設定のままでも使えるというのも場合によってはメリットになりますね。

S3でリダイレクトを設定する

1)の設定はシンプルです。まずS3にバケットを作成します。バケット名は何でも良いのですが、www.example.com等利用したいドメインそのままの名前が分かりやすいでしょう。バケット作成時の設定はすべてデフォルトのままで大丈夫です。ブロックパブリックアクセスが有効のままで問題ありません。

バケットが作成できたら、プロパティのページから静的ウェブサイトホスティングを有効にします。この時ホスティングタイプを「オブジェクトのリクエストをリダイレクトする」にし、ホスト名にリダイレクト先ホスト名を指定します。これで設定完了です。

プロパティページの一番下の方にバケットウェブサイトエンドポイント (例： http://www.example.com.s3-website-ap-northeast-1.amazonaws.com)が表示されますので、それにアクセスしてリダイレクトされることを確認してください。

リダイレクトのURLがhttpだけで良い、つまりhttp://wwwだけ考慮すればよく、https://wwwからのアクセスは考慮不要という場合は、あとはRoute 53側でリダイレクト元サブドメインのAレコードにエリアスとして上記パブリックウェブサイトエンドポイントを設定するレコードを追加するだけで設定完了です。

---

CloudFrontでHTTPS対応する

https://www.example.comへのアクセスもリダイレクトしたい場合、CloudFrontを組み合わせて使うのが便利です。CloudFrontはCDN（コンテンツ配信）サービスですが、例えば以下のようにCloudFront側でHTTPSを終端し、オリジンに手をいれずにサービスをHTTPS化する事にも利用できます（この方法については別途書くつもりです）。最近（2021/11/26）、CloudFrontの無料枠が大きく拡大され、1テラバイトのデータ転送と1,000万回の HTTP(S)リクエストまで毎月無料で使えるようになった事もあり、より気軽に利用できるようになりました。

クライアント -(HTTPS)- CloudFront -(HTTP)- オリジン

HTTPSを終端させるため、CloudFrontにはSSL証明書を入れる必要がありますが、証明書はAWS Certificate Manager (ACM)で無料で発行できます。

CloudFrontでHTTPS終端するためのSSL証明書を発行する場合、ACMで必ずバージニア北部リージョンでパブリック証明書を作成してください。これはCloudFrontに設定できるACMの証明書はバージニア北部リージョンのものに限定されるためです。検証方法はDNS検証を選択するのが簡単です（この後の画面でワンクリックでRoute 53に検証用レコードを追加できるため）。

---

ACMでSSL証明書が発行できたら、CloudFrontでHTTPSアクセス用のディストリビューションを作成します。

CloudFrontの画面で、ディストリビューション作成をクリックします。

オリジンドメインには先に作成したリダイレクト用の バケットウェブサイトエンドポイント (www.example.com.s3-website-ap-northeast-1.amazonaws.com) を指定します。GUIのS3バケット名ではなく、s3-website-..が含まれたドメイン名を指定してください。

ビヘイビア（挙動）の設定は基本的にはデフォルトのままで良いですが、自動圧縮はNoにしても良いでしょう（Yesでも問題はないです）。

また、キャッシュポリシーもデフォルトのCachingOptimizedで問題ありません。とはいえリダイレクトのレスポンスを返すだけですし、前述のように一度アクセスするとブラウザ側でキャッシュされるので、CachingDisabledを選択しても問題はないでしょう。

最後の設定項目では、代替ドメイン名を必ず設定してください（ディストリビューション作成後でも追加、変更できます）。あわせてカスタムSSL証明書として先ほどACMで作成した証明書を設定します。その他はデフォルトのままで問題ありません。

ディストリビューションのデプロイには少し時間がかかります。完了したらディストリビューションのURL（xxxxx.cloudfront.net）にブラウザでアクセスしてリダイレクトされることを確認してみてください。

無事リダイレクトできたら、あとはHTTPの時と同様にRoute 53でwwwサブドメインのエリアスに xxxxx.cloudfront.netを指定すれば完了です。

curl等で確認するとステータスコード301でリダイレクトされているのが確認できます。

$ curl -I https://portablecode.info/
HTTP/2 301
content-length: 0
location: https://portablecode.info/

まとめ

図を入れたことでちょっと長くなってしまいましたが、作業自体はシンプルです。今回のようなAliasの使い方ではRoute 53の料金はかかりません（料金はこちらを参照）。すでにRoute 53を利用している人であれば短い時間で設定できますので、私と同じようなシチュエーションの方は試してみてください。